editor's blog
Subscribe Now

The Case for Zigbee

Not long ago I did a piece on wireless technologies. It was stimulated by the fact that BlueTooth Low Energy (BT-LE) seems to be on everyone’s “new support” list. While I didn’t pan Zigbee per se, it also didn’t figure in my analysis, and, frankly, it came up only with respect to complaints some folks had had about how hard it was to use.

Since then, I’ve had some discussion with the good folks from Zigbee, and they make a case for a scenario involving WiFi, BT-LE, and Zigbee as complementary technologies sharing the winnings, as contrasted with the two-protocol scenario I posited.

The challenges I raised included the ease-of-use thing and the fact that Zigbee wasn’t making it onto phones, and phones seemed to be figuring pretty prominently in most home networking scenarios. We talked about both of these.

With respect to Zigbee being hard to use, they don’t really dispute that. Actually, “hard” is a relative term – they see it as a comparison with WiFi, which can be easier to implement (at the cost of higher power, of course). Their primary point here is that WiFi implements only the bottom two layers of the ISO stack, relying on other standards like IP, TCP, and UDP for higher-level functionality.

Zigbee, by contrast, covers the first five ISO stack layers. So when you implement it, you’re not just getting the low-level stuff going; you have to deal with network-level and session-level considerations. Now… you could argue that you still have to implement all five layers with WiFi; it’s just that you’re going outside the WiFi standard to do so.

Add to this the details of specific types of devices, and it would seem the complexity goes up – yet perhaps not. Neither Zigbee nor BT-LE is generic enough to allow simple swapping of devices. Zigbee has device type profiles to account for this: these are essentially device-level semantics that standardize how a particular device type interacts with the network.

Their claim is that BT-LE has the same kind of device-dependency, only there are no established profiles yet. Each pairing essentially gets done on its own. So Zigbee might look more complex due to all the extra profiles – while, in fact, that’s actually a benefit, since BT-LE doesn’t have them but needs them.

I don’t know if these explanations any consolation to folks struggling with the tough task of implementing Zigbee; if the benefits are there, then the effort will be rewarded. If not, then it becomes a target for something less painful.

So what would those benefits be? The one clear thing is that Zigbee has far greater range than BT-LE. But it also supports much larger networks, and ones that can change dynamically. And this is where the whole phone thing comes in. They see BT as largely a phone-pairing protocol. One device, one phone. Like a wearable gadget or a phone peripheral. Not a full-on network.

How does that play into home networking and the Internet of Things? Here’s the scenario they depict: Within the home, the cloud connection comes through WiFi, and in-home communication happens via WiFi (to the phone) and Zigbee (between devices and to whatever acts as the main hub). Outside the home, the phone becomes critical as the way to access the home, but then it uses the cellular network.

In other words, for home networking, they see no real BT-LE role. They divide the world up as:

  • WiFi for heavy data and access to the cloud;
  • Zigbee for home and factory networks; and
  • BT-LE for pairing phones with individual gadgets like wearables.

This is consistent with the fact that Zigbee isn’t prevalent on phones, since phones typically don’t participate in Zigbee networks. In their scenario, the phone component of the home network happens outside the home on the cellular network.

Obviously Zigbee has been around for much longer and has an established position in home and factory networking. The question has been whether they would hold that position against other standards that are perceived as easier to use.

Their rationale makes sense, but designers aren’t always well-behaved. Even though, for example, BT-LE might not have the same full-on networking capabilities as Zigbee, some stubborn engineers might, say, implement in-home BT-LE as pairings between a hub and devices, letting the hub manage the devices rather than having a distributed network. And they might also stubbornly have devices connect directly to a phone within the home directly, rather than having the phone use WiFi to talk to a hub that uses something else to talk to the device.

Kludges? Bad design decisions? Who knows. There are so many considerations that determine winners and losers – and, so often, non-technical ones like ecosystems and who played golf with whom can have an outsized impact. If a less elegant approach is perceived to be easier to implement, it could win.

That said, Zigbee has made a cogent case for their role. Will designers buy in?

Leave a Reply

featured blogs
Nov 19, 2018
At the Linley Fall Processor Conference recently, the keynote on the second day was by Cliff Young of Google titled Codesign in Google TPUs: Inference, Training, Performance, and Scalability . The TPU is Google's Tensor Processing Unit. It is actually a family, since, as...
Nov 16, 2018
If you aren'€™t from the packaging world, then chances are likely you might think '€œpacking'€ refers to objects being placed in to a box instead of packaging integrated circuits (IC'€™s) on a substrate. Packaging has advanced since it began, and as with many areas i...
Nov 14, 2018
  People of a certain age, who mindfully lived through the early microcomputer revolution during the first half of the 1970s, know about Bill Godbout. He was that guy who sent out crudely photocopied parts catalogs for all kinds of electronic components, sold from a Quon...
Nov 13, 2018
Podcast Interview with the authors of The Hitchhikers Guide to PCB Design eBook by Mike Beutow with PCB Chat....