This sounds wonderful for a) people who want to run said service and charge you money for something you don't need and b) people engaged in mass surveillance.

And for people who get paid to hack cloud-based servers so they can control the domestic appliances of entire countries.

Sounds comical, but turning up a few million fridge or aircon thermostats would cause serious load issues on most local and/or national power grids.

... or flush every toilet in New York at once. Barrels of fun.

So, will all of my light bulbs poll that server to see whether they need to execute a state change? Will my doorbell poll the server to check whether it has to ring? Will my fridge poll the server for spot electricity prices and the weather forecast so that it can decide whether to raj the freezer now or in 5 minutes? Will the fire alarm poll the server to check whether one of the heat and smoke detectors triggered?

Some of these will have to poll fairly frequently. For example, users expect lights to go on the moment they flip a switch, not 0.1 seconds later.

Possible? Yes, but taking duty cycle into account, that 5W lightbulb may use more power while switched off than while switched on.

This problem has been solved for a long time. You can use long polling, websockets, server sent events or some of the older hacks that preceded those mechanisms. Heck, you don't have to use HTTP, you can just use a long lived TCP connection.

Maybe if your fridge has a touchscreen that will work. But how on earth can the user configure a client light bulb? (More realistically, a client light fixture, but TFA seems focused on bulbs...) Don't tell me that the bulb will just connect to the bulb company's server, because then I have to choose between buying bulbs from only one company or having to deal with nine different light bulb servers. My choice will be bulbs from a different light bulb company.

For initial setup, there's tons of different methods, though I don't know about light bulbs specifically, but the different IoT devices I've set up have included:

* WiFi direct

* Setup over Bluetooth

* Device broadcasts for autoconfig, get settings from a gateway or local master node.

* Static configuration entered in the IoT gateway based on the physical port the device is plugged into.

* Dip switches

* Initial configuration needs to plug into a PC via USB or serial port and a custom windows program.

* Cryptic sequence entered via IRDA remote control.

Thanks, I can see these would be relevant for many different devices. Actually you've reminded me how many VoIP phones use DHCP for this, which would be great for any device that supported it.