There's been more and more attention being focused on wireless home automation recently and the two biggest candidates for it is Zigbee and Z-Wave.

Readers of this blog probably don't need much of an introduction to Zigbee because this blog is basically about it, or at least my adventures diving into Zigbee as I write my software. You're also probably aware that there has been a lot of mudslinging (ie: shit talking) between both camps, Zigbee and Z-Wave, as well as an ongoing flame war. So in an interest to educate myself on the real issues behind the talk, I decided to do some research and comparison between Z-Wave and Zigbee. I should note that a lot of the information was just pieced together via the internet since the Z-Wave specification is not public. A lot of the material in this post borrowed heavily from the information found in this article. Since there is not a lot of technical data publicly available for Z-Wave, I recommend perusing this article in Dr. Dobbs Journal since it's an excellent introduction.

Z-Wave and the Z-Wave Alliance is a group that was established around the proprietary wireless networking protocol developed by a Danish company called Zensys. The Z-Wave protocol was designed to be a lightweight protocol for home automation that would be low cost yet still could support mesh networking.

Lets begin with a look at the device types specified by Z-Wave...

• Portable Controller: 
• These are like your standard remote control and are meant to be moved around the house. These are typically used to provision the node since they can be brought near the node and the "join network" button on the controller can be pushed to include the device. Since they are portable, they constantly need to ping the surrounding devices to know who their neighbors are so that they can send messages. especially since they are the only ones that can send messages.
• Static Controllers:
  
• As their name implies, these controllers are well… static. They must be at fixed locations in the network and are always on and listening.

• Slave:
  
• This is the generic slave. It cannot do any routing, and only responds to transmissions that it receives.
• Routing Slave: 
  
• Yeah, yeah. I said that slaves can't contain any routing tables. Routing slaves are assigned predefined routes from  the controller. Interestingly enough, these are called "controller-defined routes".
• Enhanced Slaves:
  
• These are slaves with extra hardware peripherals, probably using a more advanced chip from Zensys. They have software support for external EEPROMs and RTC so that they can have more functionality.
  

The protocol structure itself is similar to Zigbee in that it consists of four layers: PHY, MAC, Networking, and Application.

PHY Layer
The PHY layer consists of radio technology that is proprietary to Zensys. It uses either 868 MHz (Europe) or 908 MHZ (US) frequencies, both of which are ISM bands and are free for public usage. In both of these frequencies, the data rate is 40 kbps using a single channel with FSK (frequency shift keying) modulation. In their next generation chips, Zensys mentioned that they will also be supporting 2.4 GHz operation, although the details are not yet public.

MAC Layer
The MAC layer supports acknowledge and retransmissions, however they seem to be
application level ACKs and retries versus MAC level. In order to clarify that statement, Zigbee has two levels of ACKs and retries, one on the 802.15.4 MAC layer and one on the Application SubLayer. The MAC retry is part of the 802.15.4 spec and is usually hardware generated upon successful receipt of a packet and sent only to the node that directly sent the frame. The Application level ACK in Zigbee is software generated, signals successful reception and processing by the APP layer, and is sent back to the original sending node, even if it was multiple hops away.

A node is addressed by using two IDs: a home ID and a node ID. The home ID is like a PAN ID in 802.15.4 and the node ID is like a short address. The Home ID is 32-bits wide and is unique to the home, although multiple home IDs (ie: networks) can exist in the same home. The node ID is 8 bits wide. Both are assigned by the primary controller when it joins the node to the network.

There are four types of frames in Z-Wave: Unicast, Multicast, Broadcast, and ACK. All frames use a similar structure, consisting of header, payload, and checksum. They are sent using a simple collision avoidance mechanism that just listens for traffic. If traffic is detected, then it will do a random backoff and try again.

NWK Layer
The primary controller controls the routing table and builds it based on the devices that it joins to the network. Upon being joined to the network, the primary controller will request the node's neighbor list which consist of all node's within broadcast range. The primary controller uses this information to build the routing table.

The routing table is maintained as a binary bitmap. This means that it is a table with all joined device IDs on the row and column header. If a device A is part of device B's neighbor list, then there will be a 1 in row A, column B. Otherwise it will be a zero. The good thing about a binary bitmap is that it is simple and also easily compressible. Thus it requires little RAM to hold the routing table. Even if the maximum table size of 232 x 232 nodes is reached, the routing table will be what's called a sparse matrix so various methods of compression can be used on it to make it small.

In contrast, Zigbee requires a routing table entry for each routing node, which consists of the destination address (the entry just points to the first hop towards the destination), status of the route, and various other fields. There is almost no way to calculate how big your routing tables are going to be in Zigbee, since it's possible that each node in the network will require its own entry. At 65k max nodes, this is a bit daunting.

 To send the frame, the Z-Wave controller accesses its routing table and calculates a path from it to the destination. It then embeds this path into the frame and sends out the frame to the first hop in the path. The nodes then successively forward the frame based on the path embedded inside it. This method of routing is called source routing, as opposed to table-based routing methods such as AODV.

APP Layer
The application layer is responsible for decoding and executing commands in a network. It accomplishes this using command classes and application frames. Command classes are similar to Zigbee profiles. They are a group of related commands for a certain application. Some examples are: advanced light control, thermostat, or garage control. They mostly consist of GET/SET/REPORT functions.

Application frames are embedded inside the Z-Wave frames and are decoded to send commands to the application layer. These frames carry information about the command class, the command, and the command parameters.

There is also a special frame called the node information frame. It carries all the information about the node and is used for the node discovery process.

Well, that about sums up my research on Z-Wave. So what are my conclusions regarding Z-Wave versus Zigbee?

Lets start with the good:
Z-Wave is much simpler than Zigbee. Truth be damned, I cannot lie. I can already hear the Zigbee Alliance sharpening their knives. The Z-Wave protocol is actually all that you need for a home automation protocol, as long as there are no high-reliability constraints such as a medical alert system.. This simplicity allows it to be much smaller than a full Zigbee implementation, so it would require less flash and RAM than Zigbee.

Now for the bad:
The first problem is that Zensys isn't in the business of selling software, or even protocol standards. They're in the business of selling radios. Their current radio covers 868 and 908 MHZ frequencies with plans to include 2.4 GHz in the future. Uhhh…802.15.4 already covers that. Plus, IEEE 802.15.4 is accepted as a true industry standard meaning that there is an independent governing body that controls the specification. On top of that, its popularity is only increasing which means that the price will be heading downward. Pretty soon, Zensys will be competing with just about every wireless sensor protocol out. Already 6LowPAN, Synkro, MiWi, SP100, Wireless HART, and many other protocols have pledged their loyalty. In this matter, their ongoing war with Zigbee is a bit trivial since they should be concentrating their efforts on 802.15.4.

The second problem is that the Z-Wave feature set is a subset of the Zigbee features set. Yes, Zigbee is the fat pig of wireless sensor networking, however it can also be trimmed. In fact, there are a number of ways trim it to maintain compatibility. Here's one:

Its possible to have a Zigbee router that does not use routing tables yet still maintain compatibility with the spec. You just need to support tree routing for compatibility which is very inexpensive. From there, you can just implement source routing similar to Z-Wave and yes, source routing is part of the Zigbee 2006 specification. Nobody seems to know that. Getting rid of the AODV routing removes the routing tables, route discovery tables, discover route service, and the buffer queue and logic required to hold frames while their routes are being discovered. This alone is a huge savings in flash and RAM size.

I could go on and on about different ways to hack the stack and still be compatible. Why haven't other Zigbee  companies done this? Because you limit the target market by making these modifications. Currently software is deliberately general because semiconductor companies need to appeal to the broadest customer base possible. If an individual or company wanted to do this, they would need access to the source code to make the necessary cuts. Unfortunately, you rarely get access and you can't hack a binary lib file.

The third problem I have is that their protocol is proprietary. In general, it's dangerous to adopt a proprietary technology because it can disappear if anything happens to the company. The software and API is all property of Zensys and completely closed. Even if the software is in escrow, if something happens to the company, nobody will be maintaining it. Source code is overvalued because it has no use without developers supporting and maintaining it. The recent news that they just accepted another round of funding doesn't help. Companies that require more funding send out the following messages:

1. They're not profitable. Otherwise, they'd be supporting themselves off their own revenue.
2.  They're running low on funds. Very few companies would dilute their ownership if they didn't need the money.
3. They don't control the direction of the company; the board does. They just accepted a loan with some very harsh terms on who calls the shots. My experience with VC funded companies is that the CEO doesn't call all the shots. A lot of his/her time is spent just fielding calls from their investors and flying around for monthly board meetings.
   

Anyways, that's about it for me and my opinions. Let me know if there's a mistake in this post or if you think I'm full of sh*t.

TrackBack URI for this entry

Comments (1)

Subscribe to this comment's feed

...
written by Brant, May 12, 2009

Excellent commentary. The it's hard to find such concise and fruitful discussions. Thanks to Peter for his defense of Z-wave, it helps. I design homes that have complex lighting, media, environmental and security systems and advise my clients on contractors that do media integration/installation. Very helpful. Thanks.

report abuse

vote down

vote up

Votes: +2

Show/Hide comment form

Name

Email

Website

Title

Comment

smaller | bigger

Subscribe via email (Registered users only)

I have read and agree to the Terms of Usage.

Add Comment