I get your more general point, but as to this toothbrush, not so difficult really. Electric toothbrushes out there today sit on a charger dock, which plugs into the bathroom electrical outlet. So the problem is much like the refrigerator. You build the smarts into the charger pod thing, and then that can access the toothbrush via something like Bluetooth.

Yes, the easy approach now is HTTP, in large part because it avoids the user, or the dentist in your example, having to install anything new in his PC or handheld.

But really, this is my point. I keep seeing articles that try to make broad brush general statements about "the IoT." The problem is, you can't. A whole lot of IoT applications would not require anything new or revolutionary at all.

The refrigirator case is simple: there's plenty of power , plenty of space, cost is not so constrained(maybe),

Let's talk about something different. A connected tooth brush that due(maybe connection for the dentist is important) to some reason you really need for it to be connected to the internet , not just to a smartphone. And you want it to have an easy to use API because all kinds of interesting apps could be developed , and you want other companies which are better than your hardware company in things like health,behaviour change and gaming. And it's very price sensitive.

Since it's power limited, you have to optimize yoour communication protocol. WIFI isn't good enough. Bluetooth isn't good enough because you need direct net connection. What do you use ? you can use zigbee but then you need some server.more money. It's possible , but not ideal.

And how do you create a simple API for someone who can create javascript games ? You need some standard. Currently it's done using HTTP, you could start a webserver for it, But that's relativley large and power consuming . So a standard like COAP would really help.

I'm kind of with Kris on this. The problem is, it seems like everyone is saying something or other about this IoT, but no one is defining what THEY mean by the term. You need to get specific enough about A problem you want to solve, before you can say anything intelligent about this amorphous concept IoT.

Let's say you feel the urge to know the temperature of every item in your refrigerator at home, even while you're somewhere else. That's not so difficult to do. You furnish each smart refrigerator with a gaggle of probes to poke into or wrap around every item, hardwire the probes to a central processor in the refrigerator, have that refrigerator processor request an IP address from your home modem/gateway via DHCP, build a web server in that processor, and now the owner can access his refrigerator from anywhere, with a standard web browser. (You probably have to dedicate a TCP port in the NAT, if using IPv4, but even that's a well-known technique by now.) Perhaps in Version 2, you use Bluetooth to connect each probe to the refrigerator processor.

There. You don't need any new industry-wide standards for that problem. All the standards you need exist already, and every refrigerator manufacturer is free to organize his own refrigerator web site as he pleases. But that's AN example. There are countless ways you can use a global network to provide access to gizmos. And too, just because something CAN be done doesn't mean it needs to be done.

I don't think the problem is skillset of embedded engineers...the problem is definition of the problems they are asked to solve...checking my fridge whether the milk is going bad is not useful...connecting trillions of sensors to predict weather locally is...we just solve the wrong problems

If the skillset of embedded engineers is the speed bump in developing next-generation embedded devices, then they need to either retrain or get out of the way. I have long said that embedded systems is developing a real application layer, particularly when you have powerful 32/64 bit computing capability, full operating systems, now networking. Back in the day of the Internet toaster I was very skeptical of most embedded network devices because the infrastructure simply was not there to support them, but that is no longer the case. Embedded teams creating IoT devices should include application-level engineers that can professionally take advantage of that power.