From last week: “Chipmakers can’t afford to wait on the sidelines, hoping their standard fare gets picked up and fits in with one of these [#IoT]teams.” This week, it’s ARM, Freescale, and Silicon Labs joining with Google and others on Thread. Yet another consortium? A lot more to this story.
You read that right, this one is Google. First we have to dig back through a bit of history to remember the push Google made in 2011 touting “the connected lightbulb”. They had put up a concept called Android@Home, and the protocol inside those demonstrations was 6LoWPAN.
At this year’s Google IO 2014 event, there was more than one Twitter question about what ever happened to the Android@Home initiative – it pretty much went dark, and the developer conference didn’t give any new info on it. Presumed dead, cause: mostly a crappy, misleading name and a confusing metaphor. How do you run Android on a lightbulb, again? And why do we need another home wireless protocol when we have protocols like, oh, say ZigBee?
If you have to explain any concept in more than a few seconds to the average bear on the street, it’s too complicated.
It’s a lot easier to show the average bear on the street. Google has put all its home automation chips in the Nest basket, and as we mentioned last week spent a fair amount of effort at IO describing their Nest Developer Program and opening their API. People get Nest, and that it connects over … wait a minute, I thought Nest was Wi-Fi?
Absolutely, that’s how it connects to the cloud. Inside a Nest 2nd generation thermostat, there is a TI Sitara AM3703 SoC with an ARM Cortex-A8 core, and a TI WL1270 Wi-Fi interface. But there is something else there: an Ember EM357 and its ARM Cortex-M3 core with a Skyworks SE2436L high power 802.15.4 front end.
Nest gen 2 internals, teardown courtesy iFixit
That prompted a lot of folks to ask: why isn’t ZigBee turned on in the Nest? The hardware is there for the taking – it seems silly to ship extra parts and sustain a significant BOM cost in every unit shipped. Really silly. And it would also seem like a no-brainer to just turn on ZigBee. It’s pretty popular in smart home appliance circles – at least Whirlpool keeps telling us that.
Unless, of course, those goodies are in the Nest picnic basket for another reason.
A lot of things can run on an MCU with an 802.15.4 radio. ZigBee. 6LoWPAN. Other protocols. It is all just a matter of what software stack is loaded. And, consider the Nest can update its software over the air – a critical feature for any IoT device worth its salt, by the way.
Now remember the ARM purchase of Sensinode, one of the leaders in optimized 6LoWPAN stacks for low power MCUs. This is starting to sound like Google and ARM actually planned things well in advance, and have just been hibernating, waiting for the right time to let Boo Boo run wild all over ZigBee. (Somewhat obscure reference. Google it, it’s funny.)
Thread is actually a new mesh networking protocol designed for the 802.15.4 radios prevalent in many microcontrollers. It is IP-based, built on learning from use of 6LoWPAN and UDP in IoT applications. The opening statement from the Thread Group says a lot:
There needs to be a low power mesh network in addition to Wi-Fi in your home.
We’ve known that for a while. It is downright expensive, both from a cost and power consumption perspective, to put Wi-Fi in everything – like maybe a ceiling fan, or a door lock, or a washer. Other charter members of Thread? Big Ass Fans (and I thought my company name was creative), Yale, and Samsung.
The thing about Thread is by opening up the protocol – read those words “legacy free” again, and give the ZigBee folks my condolences – every 802.15.4 radio sitting on an MCU is a candidate. That is billions of parts, not just those from Freescale and Silicon Labs. But they were very smart to jump in with this bunch. (Note to TI: come out, with your hands up …)
Now we know what Google has been up to for three years, and how ARM wants to play in home automation. Well played. Is ZigBee now doomed in consumer markets? Is Thread enough to dislodge INSTEON and Z-Wave with a pretty huge head start? What about Bluetooth and a built in connection to every smartphone? How about a middleware strategy along the lines of AllSeen for software-powered discovery? Lots of questions yet to be answered.