Tod Kurt knows a thing or two about IoT devices. As the creator of blink(1), he’s shipped over 30,000 units that are now out in the wild and in use for custom signaling on everything from compile status to those emotionally important social media indicators. His talk at the 2016 Hackaday SuperConference covers the last mile that bridges your Internet of Things devices with its intended use. This is where IoT actually happens, and of course where it usually goes astray.
I think this device is a good reference for thinking conceptually about Internet of Things. It’s dead-simple hardware: a thumbnail-sized PCB with a USB connector hosts two WS2812 RGB LEDs and a microcontroller. The enclosure is a little metal frame with a plastic diffuser that completes the look. You need to give it connectivity (and power) through the USB connection for it to work.
Does this qualify as IoT? Absolutely. Think of IoT as anything that brings data into the real world (or vice versa). LEDs have been on face plates of computers forever, but since the day that panel-programmed machines were put to rest, those LEDs have rarely ever conveyed meaningful data. Blink(1) can be set up through just about any API you can imagine to tell you something meaningful at a glance and at a distance. But that “last mile” is where the magic actually happens.
Cost and Complexity
Users need a way to interact with connected devices. But without a sizeable screen and multiple inputs that is a daunting task. Also, these devices often lack some important stuff like encryption (think SSL) and the ability to know when a device needs to be upgraded, plus an easy mechanism to do so. Tod contends that for a large swath of use cases, the best thing you can do is to make the device a computer peripheral.
This is most obviously done in the case of USB devices. The computer is the gatekeeper of that USB port and provides a direct and easy connection for software access to it. This can be true of wireless devices as well, but your best bet on that front is devices that are LAN only and depend on another gatekeeper to regulate access to them.
Lacking One OS to Rule Them, Tod Looks to Node
Tod heralds the many benefits of including a computer in the deal. You get a robust and continuously modern way for the user to interact using a GUI. And these central devices come with heavy lifting capabilities, like the option to handle encryption and orchestrate firmware upgrades when necessary. You will even have a mechanism to alert users when an upgrade is necessary.
This is no small thing. We are in the pit of despair with botnets right now because of early devices that didn’t think deeply about security and upgrades. Households that include devices in these botnets are completely unaware that their device is up to no good, and even if we found every device that has been pwned there’s no way to notify the owners. But I digress.
Of the myriad options to explore for cross-platform apps, Tod is preaching for Electron, a browser-based framework that uses Node.js for your every whim. This last part isn’t hyperbole. One of the chief benefits of Node.js is the extremely widespread adoption that means if you can think of a use, a library probably already exists. There are numerous examples of support for common hardware (from ESP8266 to Sphero BB-8 toy robots). Even if your programming chops can’t keep up with the new hotness there are tools like Node-RED which help you stomp out complexity with a graphic programming flow.
Think Security, Think User, Then Think Product
This is not a sales pitch for Blink(1) — although you find it in the Hackaday store — but a proven example of the way we need to be thinking about building up the Internet of Things. The default has been to build it and think about everything else if it turns out someone wants to buy it. We’re eating our humble pie for the hubris of early designers. Only a paradigm shift in thinking about these issues early will make future IoT devices secure, but also deliver on the promise that has so far failed to materialize. We’ve been told that IoT will be awesome, fixing the last mile will let you deliver on that by making users love what you build.
I used to like node.js. But after examining ‘callback hell’ and promises…..I decided to avoid node.js altogether. Golang or python (& micropython) are much better alternatives.
The node.js non-blocking stuff drove me a bit nuts. Took me a while to get it into my head how to think non-blocking. Still learning promises. I had problems with early Python (it’s indentation is a bit crazy) but I’ve gotten over it.
I’ve built dynamically configured devices but I have it signing into my MQTT config topic (which looks it up on a db). The updated firmware issue I haven’t solved (but I’ll work on that). The Blink-Ms still have me confused (BlinkMs? Why?). I’m pretty sure I can dynamically config an ESP8266 (would need to start up in ad-hoc). Probably get it to support Bonjour (I prefer it talking to my MQTT server). I think with a SEEPROM upgrade you can do OTA firmware upgrades.
Now having said all that I haven’t thought through the later parts of the security question (how do you trust the server/service you are talking to?), I know we can do the secure login to a cloud based
The updating firmware OTA on esp8266 has already been solved. You could solve it again if you’d like. See ‘rboot’.
Yes, sorry, I had heard that but wasn’t sure of it’s states. Very good to know. :-)
Thanks for the information, I’ll take a look at that shortly
Im confused (and maybe Mike too), how is 50MB of server side .js garbage going to help with SSL on 20KB ram IoS device?
I personally have not much love for node.js, but smarter people than me are happily using it ( and they can keep it ;-) )
Pete Scargill has developed an ESP8266/node.js on Raspberry Pi system that he’s open-sourced. HaD blocked the link but google “scargill home automation|”. He’s using node-red.
I love reading about Pete’s stuff. I can’t use it directly as I have a bit of a different approach but I always get a few tips and ideas from his pages.
Absolutely adore Node-Red.
Installed it as a test bed for home automation, but now has permanent residence.
At work I setup another instance that emulates services that I’m testing against (sometimes we can only get limited access, so now we can fake it when testing other platforms)
“Cost and Complexity
Users need a way to interact with connected devices. But without a sizeable screen and multiple inputs that is a daunting task. Also, these devices often lack some important stuff like encryption (think SSL) and the ability to know when a device needs to be upgraded, plus an easy mechanism to do so. Tod contends that for a large swath of use cases, the best thing you can do is to make the device a computer peripheral.
This is most obviously done in the case of USB devices. The computer is the gatekeeper of that USB port and provides a direct and easy connection for software access to it. This can be true of wireless devices as well, but your best bet on that front is devices that are LAN only and depend on another gatekeeper to regulate access to them.”
Good luck to you sir. You’re methods are too expensive for me.
“Users need a way to interact with connected devices. But without a sizeable screen and multiple inputs that is a daunting task.”
I believe a border router hosting a web page would be more than enough screen.
“Also, these devices often lack some important stuff like encryption (think SSL) ”
No, instead think AES.
“and the ability to know when a device needs to be upgraded,”
Why would this not be a part of your protocol, identify the device’s firmware version?
” plus an easy mechanism to do so.”
A device level bootloader with enough memory for 2 images?
“Tod contends that for a large swath of use cases, the best thing you can do is to make the device a computer peripheral.”
If a computer is available why wouldn’t you do this through a border router?
You burden the cost of each device with a USB PHY, and microcontroller with a USB stack, just for firmware upgrades?
I am totally missing something here, but I’m in my own cheap IoT sensor device world. Maybe the rules that apply to me are different.
You made all the right points. Especially on AES encryption. I like the idea of network obfuscation using a gatekeeper IP. I like the home control solutions like https://home-assistant.io to track and manage devices. This whole state of iot is a mess right now.