Is Google and Nest’s Thread a ZigBee Killer?
- Published
- in Wireless
Today Google and Nest launched the Thread Group – a new wireless network for home automation. It’s not the first and it won’t be the last, but it has some important names behind it. The big two are Google and Nest, not least because Nest’s products may already be using it. But others in the consortium are interesting. ARM is there. Today they power most of our mobile phones, providing the IP behind the processors in billions of chips. But they have a vision of being the microprocessor architecture of choice for the Internet of Things. They processors will be smaller, cheaper and lower powered, but will provide the first opportunity for chip vendors to think about trillions. ARM’s inclusion in the group is an obvious step in their process of acquisition and investment in IoT companies.
Samsung are there (aren’t they always), but so are some very large names in home automation, such as Big Ass Fans and Chubb. And what must be worrying the ZigBee community is that Freescale and Silicon Labs complete the list of founder members.
The important point here is that Thread is not ZigBee. It works in the same spectrum and can use the same chips. It is also a mesh network. But it is not compatible. As the Thread technology backgrounder says, they looked at other radio standards and found them lacking, so they started working on a new wireless mesh protocol. To put it more crudely, it’s Google and Nest saying “ZigBee doesn’t work”.
This isn’t the first time that Google has proposed a wireless standard. Back in 2011 they used their I/O conference to announce an initiative with Lighting Science Group to produce a home automation wireless mesh standard operating at 868 – 915MHz. I didn’t think that would shake the world and it didn’t. This time around is different. Nest is not Lighting Science Group. To many people, even before their acquisition by Google, Nest were home automation. They’ve released the API to their products and built up an impressive roll-call of partners, including Mercedes-Benz, Whirlpool, Jawbone, Logitech, Chamberlain and LIFX. Now that they have the resources of Google, it’s clear that Nest are not going to stand still. They’re already calling for interest from other companies and plan to release a specification for Thread later in 2014*.
My guess is they may miss that date, not least because every other wireless standard I’m aware of has been late. Wireless is difficult and as more partners come on board they will find bugs which need to be corrected. But the release will happen. The Thread site says that it is already in products, which answers a long-standing question about Nest devices.
When the Nest thermostat was first launched, teardowns reported that it contained a Texas Instruments CC2530 chip. That a 2.4GHz chip which is normally used for running ZigBee. However, Nest never announced ZigBee compatibility or showed this working with any ZigBee device.
There was speculation that it had been included in case energy utilities wanted to connect the thermostats to smart meters, not least because Nest was wooing them to be part of their demand response programs. Other theories were that it was included in case it might be needed, but in that case, why populate the board and increase the cost? That theory was dispelled when the second generation thermostat come out and teardowns discovered that the TI chip had been replaced by an Ember EM357. You don’t do a chip change unless you’re using it. And the same EM357 duly appeared in the Protect smoke alarm. The inference was that Nest was using these chips for something else. But what?
Today we can assume that something else is Thread. So far I’ve never seen anyone claim that they’ve seen any activity from these chips, but if it is low power, it would be very intermittent and difficult to see within the Wi-Fi activity. If it is in use, that will provide a very useful experience base for the Thread partners to help hone their standard.
The ZigBee community will be alarmed. Silicon Labs acquired Ember last year. Ember was very much the founder and poster child of ZigBee mesh, which as a standard has struggled to get a hold in any market other than smart meters. Within that market manufacturers have used the older non-IP version of the ZigBee standard. Although ZigBee 2.0 has moved to support 6LoWPAN, the Thread announcement has probably killed it at birth. Freescale is another ZigBee provider. The fact that they and Silicon Labs are working on Thread has a serious consequence for ZigBee. The basic chips these companies make work with many wireless standards; what differs is the protocol stacks which can require hundreds of man years of development. Although the chips may work with any standard, only those which are showing commercial promise will be given the resource to develop the protocol stacks. My guess is that the ZigBee teams within Silicon Labs and Freescale have been moved to Thread development and without that engineering effort the ZigBee stacks, which still have work to be completed, will wither and die.
This is also a very bitter pill for smart meter manufacturers and utilities. If the market stops supporting ZigBee and moves to Thread, then it means that utilities have chosen an obsolete technology to put in their smart meters. Any plans they had to connect to home devices for demand response will need to be scrapped and rewritten. In the utility world that means a delay of several years and an ever greater distrust of the wireless industry.
Nest’s move to the Ember EM357 may give us a clue about the size of the Thread stack. The website shows us the basic architecture of Thread, which is a lot cleaner than the SEP2.0 approach which ZigBee ended up with. That was heavily influenced by utilities and Government sponsored academics, resulting in a stack that was a rather bloated committee job and too big to fit into most existing ZigBee chips. As a result chip companies came out with newer, more expensive chips with much more memory.
Thread talk about their clean piece of paper approach to the design. My guess is that they wanted something that would fit into an existing chip without the need for external flash or a more expensive chip. Their move from the CC2530F256 to the EM357 contradicts the industry trend by shrinking the flash memory from 256k to 192k, suggesting that they already knew the size of the Thread stack and were cost reducing. If they’ve staked their product design on the 192k limit of the EM357, it suggests we’re going to be shown a very efficient protocol stack when the Thread documentation is released.
This may all be a good thing for those involved with ZigBee, if not for ZigBee itself. Over the years ZigBee has been rather promiscuous in allowing its name to be associated with anything that used an 802.15.4 chip, regardless of what sort of stack it had. In much of the Far East 802.15.4 is synonymous with the word ZigBee and universities have been complicit in churning out graduates with “ZigBee” experience who think that a standard is something you can rip up and rewrite, rendering them largely unemployable. As a result ZigBee has achieved a reputation for minimal or no interoperability. Even in smart metering, where it has had most success, there are over half a dozen different versions of the Smart Energy Profile and limited interoperability between manufacturers, even within any one of the versions.
Thread gives the industry players a phoenix opportunity – the chance to walk away from the mess and start afresh, taking the best bits and discarding the albatrosses. But to do that cleanly they probably need to euthanise the ZigBee Alliance.
So where does this put Bluetooth? Bluetooth has been less than successful at penetrating the home automation market than other low power standards, allowing ZigBee and Z-Wave make most of the running (although crawling might be more accurate – this sector has not taken off). In recent months that’s started to turn around, largely because of the widespread implementation of Bluetooth Smart (the standard formerly known as low energy) in tablets and smart phones. It also appears to be the connectivity standard of choice for in-home connections within Android TV. (Incidentally it seems very strange that Thread was not announced at Google I/O last month, when ATV was very much the main theme. If Thread was just a way of getting back at Apple for their HomeKit announcement you would have expected it to be a highlight of the I/O event.) The two wireless standards can certainly co-exist, but Nest will need to persuade smartphone vendors to incorporate it into their devices, which may be an uphill struggle, particularly with Apple. And it’s important that any home control technology is in every smartphone and tablet, as the lifetime of home automation products will span many changes of phone and tablet.
Bluetooth is not standing still. Cambridge Silicon Radio has demonstrated a mesh network for Bluetooth, and the Bluetooth SIG is working on IPv6 support and longer range. It’s too early to say whether there is an opportunity for Thread and Bluetooth to come together? It would not be the first time such a thing has happened and large manufacturers can exert a surprising amount of pressure. The home automation market needs consolidation in standards, particularly in terms of interoperability and device management. Whilst it is fragmented, nobody is likely to win.
Z-Wave will also feel threatened. I imagine they will continue to promote the advantage of being a sub-GHz product, which will translate into easier installations. 2.4GHz is not the best frequency for the home as range is a challenge, particularly for the first few devices deployed. Mesh alleviates that, but needs multiple devices to be deployed before it can compete on range. That in itself would argue for a Bluetooth / Thread conflation to push up the number of routing nodes in any home. However Z-Wave have other issues in getting to scale, not least the limited number of component suppliers and no prospect of support in a smartphone or tablet.
There are still many unanswered questions abut Thread, so I’d recommend signing up for their newsletter. Why is the smart tap on their website still dripping? Surely it should have asked for a new washer by now? Why is their logo an ampersand rolling downhill? Maybe “and over and over again” is a metaphor for home automation. Why is it called Thread? I’m sure these will be answered. But all of a sudden, the presence of Thread makes the prospect of home automation becoming a reality look a lot more possible.
* As always, wireless standards take longer to emerge than predicted, not least because they’re difficult. I suspect we won’t see the first release until the end of summer 2015.
I don’t think anything will unite the IoT, but that’s another story. At the end of the day the connectivity is a very small part of a much bigger puzzle. Still, it’s good to see some consolidation.
Given the news, Thread is not killing ZigBee. Seems quite the opposite actually.
http://www.fiercewireless.com/tech/zigbee-alliance-thread-group-to-showcase-interoperability-at-ces
The question should be, will or could ZigBee unite the IoT?
I suspect that smart meters could be upgraded, but it’s more questionable whether any devices connected to them using ZigBee could be. Rolling out updates to sleepy mesh devices without stranding some of them may be a step too far for most utilities. The other question is whether it can be done without breaking the overall security model. As you say, we need to wait for more details.
What is exciting is that it’s enabled the industry to go back to a clean sheet of paper, using the best features and learning of a current standard. It’s the same approach that happened in the Bluetooth community when low energy was designed – using ten years of experience, but not being constrained by a need for backwards compatibility.
Late to the party here, but just wanted to say that, as a developer working on Smart Meters and Zigbee, I don’t see Thread as a problem for existing meters. They stuck with 802.15.4. It’s hard to say for sure until more Thread info comes out, but I’m betting that all our products can be upgraded over the air to Thread. Zigbee brought a lot of problems on itself so Thread is really exciting for some of us in this community.
So many standards forget about provisioning, which ends up being their downfall. I’ve explored that in a more recent post on the Infrastructure of Things.
There was a company, Tendril that had Zigbee based devices for the home.
https://api.tendrilinc.com/
They don’t do devices any more. I worked there for two years.
Tendril had a Zigbee Thermostat, remote plugs with usage monitoring, and devices to connect to Zigbee and chirp meters. The data collected was sent to the cloud, then displayed nicely for users interested in their energy usage, yes even your phone. This was all working 2 years before Nest entered the market.
The devices worked, but working with Zigbee was ugly. Zigbee is doing the Smart Energy 2.0 specification. The problem is they want to do a big protocol, with XML and bells and whistles, that will not work with older, installed equipment. So existing Zigbee implementers are stalling.
The other really ugly part was connecting and provisioning devices. It was a procedure only an engineer could love. Nest’s success came from making this easy and usable for a non-technical user.
I would not shed a tear if there was a Zigbee killer. In fact, I would cheer and say “good riddance”.
These chips are almost universally used for ZigBee, but they can be used with any other stack as well. They are essentially 802.l5.4 transceivers with an application processor and flash memory. I probably wasn’t clear enough when I talked about the move from the TI chip to the EM357. The EM357 has a smaller flash memory than the TI chip. To the best of my knowledge it is not large enough to accommodate the ZigBee IPv6 based SEP2.0 stack. Therefore my conclusion is that Nest had already decided that:
i) they would not use the ZigBee IPv6 solution, and the corollary that
ii) their own, alternative IPv6 mesh network has a much smaller footprint that ZigBee.
The second conclusion also means that Thread is likely to be cheaper to implement, giving it yet another advantage over ZigBee.
A quick Google search for Ember EM357 gives me “The EM35x and EM358x Ember® ZigBee® chips are the industry’s leading ARM® Cortex®-M3 based family of ZigBee SoCs”. So where do you get the info that the chip change meant dropping ZigBee ?
Note that I don’t question the “death of ZigBee”, but I don’t see the chip change link.
I’m not forgetting that there are 10 million meters in California, nor have I forgotten the fact that only around 45,000 of them use the ZigBee connection. That’s nothing to do with the merit of ZigBee SEP x.y, but about the fact that neither customers nor utilities are very interested in the SM HAN. The reality is that utilities were mugged by technology.
What this has proven is that utilities don’t have the ability to engage with customers. Companies that set out to make HAN products have run out of money waiting for the market to happen. Will they give up on ZigBee for the chance to eat the scraps dropped from the Nest / Google table? Of course they will. It’s their only hope of survival. Which is why ZigBee SEP 1.x will wither and 2.x atrophy. It’s not about technical merit, it’s about market reality.
Nick, interesting article. However, you forget that in the state of CA, there are 10 million smart meters with a ZigBee SEP 1.1 integrated HAN. No way ZigBee is going away any time soon. Hard to believe also that a brand new standard is going to blow away ZigBee, even if google is behind it.
All light switches in new build houses are in the wrong place. It’s legally mandatory: a crippled midget has to be able to reach them. This annoys 6′ tall adults enough to consider moving the switch right up to the moment they find out how much work is involved. A cover plate and a remote switch are worth money.
The builder probably couldn’t be bothered to add 2/3/4 way switching everywhere it would have been useful. Switches are often on the wrong side of the door or the door hinges the wrong way and wants to be flipped. Perhaps some cowboy builder has moved a few partition walls about or added an extension without adequate consideration for switches.
I’ll be this applies to almost every home but the value is £100 and 2 hours not 2 days of rewire/plastering faff and £250.
It’s *extremely* rare to find 5A lighting sockets for up-lighters, furniture, bedside lights and suchlike that are connected to the wall switches. people do this very often indeed and this is frustrating. Moving a bed or bedside table about is common.
As you get a larger number of individual lights you’ll son want to set “scenes” that are an inconvenience to achieve with switching.
Perhaps they’re annoyed by CFLs and LEDs that flash due to capacitive coupling in the switch wire runs.
You’ll want quiet (touch) switches for that midnight pee. Your bathroom light shouldn’t go from zero to 100% output instantly when it’s 3 am and you just want to pee, and nor should the extract fan buzz into life at full pelt. That’ll be some form of IoT switch/bulb.
Plenty of applications become annoying enough for Mr and Mrs Home Counties to act upon when it’s below that £99.99 psychological threshold.
I think they make little sense for most new build: developers are fabulously mean because new build house buyers (the bottom end of the market on the outskirts of town; not the older properties in valuable/desirable locations and plots) aren’t prepared to pay any extra for it. Retrofit all the way to overcome extant infrastructure limitations.
If there’s a plug (or battery and solar panel?) now there’s an addressable lamp. Great. Make it all LED and 12V DC so that it’ll run (along with internets and other essential services) off the car battery when the smart grid goes down. I can live without laundry and cooking facilities for longer.
More recent switchplates in the UK are similar to that. That’s not my issue. It’s why should I change a mechanical system that works so well? I can see why it makes sense for new build, but that’s a very small proportion of the market in most countries. It also makes sense when you’re adding new light pendants which you want to control separately – I used wireless switches for that in my previous house. The practical problem is that it’s generally not the switch that drives the change, but adding more lights, where wireless saves you having to install new switching wiring. But again, most people don’t do that very often. So I have some difficulty believing a lot of the market size predictions.
I you’ll have a smart bulb with a mechanical switch sooner than that Nick.
An always-on, momentary action, mechanical switch. Interruptions to the power supply to the smart bulb override any (non resilient) wireless smartness. You can do much with single-tap and double-tap.
The bulbs get replaced but your in-home fixed infrastructure stays. Intelligence at the node.
The switch backplate probably has the mains wiring in it and you screw a consumer ‘overlay plate’ over the top that contains all decorative elements and unreliable/non-future-proof/proprietary/iSwitch type nonsense.
See euro-style switches and socket outlets for inspiration: the mains/switchgear is built into the wall and you swap decorative backplates rather than having it all-in-one per the UK market, or a surround (with fixed switch poking through) per the US market.
I agree with the plug-n-play requirement. It’s the one that is so often overlooked as engineers get agitated about comparing protocol specifications. However, it goes deeper than that, which is where a hub may be useful.
For most smart home products, their working life will encompass multiple changes of phone, tablet and potentially hub. A real challenge is device management across these changes, so that security credentials and network configurations can be seamlessly transferred to the new device. Until I can be guaranteed that exists, will work and will continue to work for the next 20 years I’m going to stick with mechanical light switches, as I suspect will the vast bulk of potential customers.
6LoWPAN is dead. It was created to overcome 802.15.4’s (aka Zigbee’s) crippling small packet size that prevented IPv6 usage. Pretty much every other competing protocol lacks this limitation.
That combined with the fact every 802.15.4 device needs a gateway of some kind to talk to user devices obviates it for anything but uber-nerds who like to fiddle with things.
Jane consumer won’t jump en masse until it is plug-n-play direct to her smartphone.
Thanks – I’m glad you enjoyed it.
The perversity comes from the fact that the smart metering architecture and technology has been constructed by people largely ignorant of consumer technology. That was made worse by a fear that consumers might be able to connect into it – the Smart Metering HAN is conceived as a very secure walled garden.
In theory a consumer can buy a Consumer Access Devices (CAD), which acts as a one-way bridge between the HAN and their smartphones, but there is little evidence that anyone will make such as device, particularly given the direction in which home automation standards are moving. So the only way to get data to a smartphone is for your electricity supplier to retrieve it from your meter via the DCC and then send it over a broadband link back to your home or phone. However, most of the communications contracts have been heavily restricted to get the cost down, so the latency of a request to your meter is around 12 hours. Which is not a wonderful experience when you want to see how much it cost to make a cup of tea.
Sadly, this hasn’t just been architected by monkeys, it’s been architected by technically illiterate, nineteenth century monkeys. The only surprise is that they didn’t choose steam driven semaphore as the communications standard.
Nick – great to read an article with some real content! I’m interested in the point you raise about smartphone connectivity. While many use cases will not require direct phone to device connection (but go indirectly via the Cloud) is seems a little perverse to have several billion smart phones using one protocol, and (maybe) several billion connected home devices using another, precluding direct connection between the two worlds. Do you see a good technical justification for this?
Cliff
Thanks for confirming Robert!
I am part of the Internet WG in the SIG so I have some insight :).
Niclas
Niclas, it IS what the IETF are doing. This is similar to what the ZigBee Alliance did with the development of the IP stack for SEP 2.0, i.e. based on existing IETF standards with nothing really new and guidance for implementers to make sure platforms can interoperate. The main difference is that Thread is not driven by utility-led energy management-specific SEP 2.0, just more general home applications.
As Nick says, Bluetooth is also looking towards IP with the BTLE draft. If everything is IP based, in theory it shouldn’t matter what radio/powerline/cable it communicates on and all these network segments should be able to come together (better than they do now) and provide internet connectivity all the way to the end devices.
Nice description and analysis.
As a colleague asked, “I wonder who’s going to run the ‘God-servers’ behind this system”. So called Experience Improvement information being sent and accumulated by whom.
Difficult to feel excited about this initiative, another one again. This was some time ago
http://www.openinterconnect.org/
Reading a bit deeper it seems to build on 6lowpan, I wonder how it is actually different from what IETF is doing. I guess the mesh could be different and it defines profiles for data. Too many to choose between! I stick with Bluetooth, there are my friends.
Niclas Granqvist