The Internet of Things is supposed to describe a world where connected devices improve our lives. But an embedded engineer finds crippling tradeoffs in every solution today.
Here's a brief assessment of the technologies I've had hands-on experience with:
Bluetooth and Bluetooth Low Energy (BTLE) require a smartphone and/or an always-on base station that communicates to a server. That likely means an app on the major smartphone platforms and a service/daemon on the base-station OSs. Plus, to collect and act upon the device's data will probably require a cloud server. On the plus side, configuration is relatively simple -- as long as you have a display on the device. Battery usage is minimal, which makes this a good choice for pedometers and other pocket devices.
Connecting to a WiFi processor using a TCP/IP stack on your processor makes for a reasonably complex system requiring an RTOS. It also can drive up the cost of the MCU by moving the application from a Cortex-M0 to a Cortex-M3 with the associated battery drain. Configuration is very difficult, usually requiring the user to switch to the device-as-a-server (a.k.a. device-as-an-access-point) to set the SSID and password. Also, the quality team (if you have one) is going to need to verify functionality with a wide range of home routers and (seemingly standard) web browsers. The battery usage is high when the radio is on, which means that intelligent local processing is needed, along with some message batching if possible. This option works well for printers (plugged in) and scales (which spend most of their time sleeping).
Connecting to a WiFi processor via serial means the processor can remain smaller, which is a cheaper and more power-efficient option. However, configuration is still difficult, probably even worse since the setup will not be as customizable as running a local stack. There are often fewer power optimizations for the WiFi processor so, oddly enough, limiting connectivity is often a priority for developers.
Electric Imp provides an interesting configuration option for 802.11 WiFi. It requires a smartphone, blinking the screen to send the SSID and password to a receiver on the device. It also takes some of the burden from the device developers by creating a WiFi + system cloud solution. However, it still requires many parts: device software (developed in Squirrel), a monitoring agent on the software (also Squirrel), and a web interface (Ajax, HTML5, etc.). The power levels are in line with other often-asleep devices, so batteries will do fine if you use enough of them. This option is great for the home hobbyist hacking together a monitor to see if the stove has been turned off. But using the Electric Imp in large scale means letting someone else store your data and working with them to connect users with devices in manufacturing.
Cell data modems are easier for the user, but they require coverage and are expensive (who needs another cell plan?). Connecting to the user account is still non-trivial, particularly if the user doesn't have a keyboard. Note that Amazon did cell modems for the initial Kindles (though the current Kindles are WiFi instead of cell modem now -- it is much cheaper for the OEM). Battery usage is higher than on WiFi, though the distance is greater. This option is excellent for devices that need to always be available, even when WiFi coverage is unlikely, such as traffic light cameras, cars, and smartphones.
Some products create their own wireless networks, running a base station or small server. This makes configuration much easier. However, the server likely has to use one of the above options or a wired connection to get to the Internet. And creating a device solely to communicate with other devices is expensive; it is primarily an option for systems with lots of little devices (such as home lighting). This option isn't scalable to true connectivity, rather it is a stopgap along the path to true device connectivity.
The Internet of Things is supposed to describe a world where connected devices improve our lives: The refrigerator tells the phone to put a needed item on the shopping list; the house detects there is no one home and turns off unneeded appliances (especially the oven!); the car tells the thermostat that it is 15 minutes from home arrival, to make for efficient climate control; the possibilities are endless and endlessly amazing. But we aren't there yet.
Too many connected devices cause more headaches than help. They are unreliable, too difficult to use, dangerously insecure, or impossible to configure. I know what I'm asking -- security and ease-of-use are natural enemies. But I'm tired of being the target audience, using my engineering skills to make not-quite-there products work for my home.
Let me know when your four-year-old and my grandma, working together, can put the device on the Iinternet. Then tell me again about the Internet of Things.
Just one note to your post. Most people do have a bar code scanner. It is called a cell phone wth a camera and any one of a dozen or more apps that read bar codes. I use mine quite a bit.
I agree that IoT is not here yet in terms of ease of use, but complaining about it is not going to make it happen. As developers, WE need to make it easy to configure and use. It is going to happen, it is already happening. I have an app on my phone that lets me turn my home security system on and off from anywhere in the world. It was easy to install and it is easy to use.
You are right, but if the communication is confined to plain text and only one language it will make the communication and collaboration of the devices over IoT more simpler but the world never goes to be like that, as the demand comes from the application layer and the implementations goes from the below layer, that too is crowded with many languages and technologies, so ultimately this will be going to increase the connectivity issues, just if I say plain hard words.
I have begun to evaluate the IoT cloud platform from Ayla Networks (www.aylanetworks.com) and I really like what I see so far. The founders include the Amazon development team that developed the entire connectivity platform for the Kindle. They have a well thought out architecture and cohesive approach with the wireless chip/module/controller vendors. It looks like next gen platform solutions are hitting the market now to overcome the challenges that this author has well articulated.
@Doug: Yes, it's like the early days of WiFi when finding a net SSID and logging on to it securely was an arcane, painful manual process for the user. Slooowly Msoft realized it needed to fix that in Windows to enable WiFi to take off.
IoT is the next big thing, millions of devices and dollars, hype, hype, hype. But in reality it is not happening. Why?
As programmers and engineers we can not see the forest for the trees. My everyday experience is to install something new, configure it, find the wrong character or miss typed licence key and get it working.
YOU ARE NOT YOUR CUSTOMER.
People are being bombarded with dire warnings about security and protecting their Wifi and personal networks. A secure solution is needed.
At the same time, no average consumer is willing to spend time typing in 128 bit HEX numbers to enable a thermostat. The problem is really terrible for a device without a display. So horrible, people simplely return the device, or don't buy.
At a past company we tried to setup Zigbee secure networks over a web interface. How did our installers and service people do this? They brought along a bar-code scanner rather than type the code for the device from the label. Most customers don't have a bar code scanner. Sending people to every home does not scale.
There is no standard for setting up wireless devices. WPS is not supported on older routers, so it is hit and miss. Everything else is proprietary.
As a builder, to use USB and copy network settings (my Brother printer with Wifi worked like this, very nicely) now we have to add a Windows XP, 7, 8 installer, and one for MAC. (Linux is coming soon, and always will be.)
Wait, everyone has a smart phone now, right? (not really, but...) Which phone do I build an app for? iPhone (old an iOS7), which fragmented Android device, or maybe Windows phone. Do we need to ship a cable too? The costs added for these one time use setup applications is huge.
The cost and complexity of configuring the IoT device is killing consumer adoption. This keeps IoT a business or industrial application and until this is fixed IoT will not live up to the hype.
If we start with the electric imp , it's not hard to surpass it's limitations:
1.Data storage not at your server:
Just write a bit of code , to use the imp servers as a transparent bridge to the server you are using. Verify with the imp providers no storage happens at their servers, or encrypt everything( i believe it's possible to add c code to the squirrel in imp, espcially if you're doing volume).
There might be simpler server/website dev tools than electric imp. For industrial applications and maintenece , thingworx seems powerfull and easy. Microsoft lightswitch is another usefull , easy to use option , just use it's REST service api , i believe. Alpha everywhere by alpha software can might give similar level of simplicity , but i haven't looked on the details.
For consumer facing apps, if you really want want custom beautifull interface , i'm not sure what's the easiest way is,but maybe asking this at quora, news.ycombinator.com , or reddit.com/r/programming would offer good answers.
The IoT is sure going to make the life of Embedded developers complicated till the time some standards get evolved on how the gadgets connected as Things on the Internet would talk to each other and how and in what format they will exchange information - command as well as responses.
In one of the previous blogs on this subject I had suggested an implementation of a high level command interface like those AT commands for good old modems.
Also there is a need to have some kind of device classification so that the devices which are dissimilar in their functionality need not communicate with each other ( because it will be meaningless and unnecessary burden on the network traffic)
IoT will be a new paradigm that the Embedded developers will have to shift to .
What do you think of the IPv6 embedded MAC implications to IoT?
Which way should the industry go with IPv6 (local hidden networks with random MACs that require a Proxy to access the home or business) or IPv6 direct to each device in the home and business?
Background:IPv6 has the promise of removing the need for a Proxy to gain access to the IoT in a home or business. Because the IPv6 address is so large there is no longer a need for net local addresses used in IPv4. Our industry has a choice with IPv6 of either using local addresses and hiding all the devices from direct remote access or exposing every device directly to the Internet. The addition of the MAC address into the IPv6 address makes device level direct access for IoT very easy to do. Using IPv6 for direct access to IoT devices will make it much easier for everyone to use their IoT devices but it will also make it much easier for governments and criminals to easily learn a great deal about us and even gain access to controlling our lives. For example exposing MAC numbers in the IoT provides a great deal of information about who we are, what we own, how big our home is, how much we earn, how many people are in our family, what we eat..... The embedded MAC also makes it easy for governments to track us any where we go. In countries that restrict their citizens these are big issues to consider and we engineers are the only ones that understand the issues well enough to speak out.
Privacy v.s. Easy Access to IoT: I believe IPv6 with a directly exposed IoT MACs provides the stairway to "1984" and "Atlas Shrugged" -> not a good idea. Instead we should use link-local IPv6 and create standards for Free Proxies that provide access to our devices through the Googles, Bings, and for pay private Proxies.
January 2016 Cartoon Caption ContestBob's punishment for missing his deadline was to be tied to his chair tantalizingly close to a disconnected cable, with one hand superglued to his desk and another to his chin, while the pages from his wall calendar were slowly torn away.122 comments