- Written by Akiba
One clear thing is that Zigbee now has two large markets under its belt and that’s important because it’s pretty much the only standard wireless sensor networking protocol that can claim this. This makes it king of the hill, only it’s members shouldn’t be too complacent because that hill is still really small. Being an industry leader has its advantages such as having a greater chance of survival but unfortunately doesn’t necessarily mean that consumers will adopt it. Sure, it can be forced down people’s throats by having a Zigbee enabled meter or a Zigbee/RF4CE remote control to come with your Sony Bravia, but if the Zigbee Alliance isn't careful, that’s pretty much where it’ll end. The real danger for Zigbee is in assuming that because they have the largest potential markets, that consumers will flock to the technology. The true test for any technology is in adoption.
This is where 6LoWPAN has the advantage. If you don’t know, 6LoWPAN is an IETF draft standard that specifies how IPv6 frames will be carried over the 802.15.4 wireless protocol. The benefit that this protocol, or actually I would be more correct in saying header compression scheme, has over Zigbee is that you can use TCP/IP as the communications mechanism. Notice I didn’t mention anything about 6LoWPAN being better than Zigbee, or more efficient, faster, lower power, tastes great, or less filling. Those would be fighting words and I don’t want to set off a religious war. The truth is that technological superiority doesn’t really matter in terms of adoption except for technical purists, aka geeks. What really matters is that 6LoWPAN uses TCP/IP and TCP/IP doesn’t have an adoption curve. There is a huge amount of existing infrastructure, developers, software, standards, and knowledge that people just kind of accept it like air. It’s what most of the world uses on a daily basis, whether they know it or not.
The weakness of 6LoWPAN is that they don’t have a real market for the protocol at the moment and it’s mostly because of some technical issues. The main problem lies in the fact that they don’t have any standards in place to govern device interoperability of each wireless sensor node. Zigbee spent a lot of time on device interoperability for the nodes and defined standard device profiles that behave in well documented ways. This means that one node can discover what services another node provides, and access those services in a standardized way. They also set up the test labs with testing equipment, checklists, training, certification procedures, and pass/fail criteria to ensure that the devices that make it through the testing and get the Zigbee certified logo adhere to these profiles. Although many people will probably bash me and say that it still doesn’t guarantee interoperability, it’s still better than anything that 6LoWPAN currently has.
Well, I’d better make my point quickly or else I’m going to end up being hated by both groups. My point is that Zigbee has the device interoperability specification and testing infrastructure in place and it also has access to two potentially large markets that are gateways into the consumer home. 6LoWPAN has access to a huge amount of infrastructure, a disgustingly large pool of protocol developer geeks, and TCP/IP which is the lingua franca of communications all over the world. When I said that something felt like it was missing, I really meant that Zigbee needs 6LoWPAN and conversely, 6LoWPAN needs Zigbee. If they could somehow put aside their ideological differences and pointless debates on protocol efficiency, and somehow combine their strengths, this could be a rare case where the sum is exponentially greater than its parts. Not only would something like this re-define how people think of the internet and interact with it, it would also bring some really huge guns into the game…like on the order of Cisco, Microsoft, Google, and Intel. This would be on top of companies like Sony, Samsung, Panasonic, and Philips that came along with RF4CE. It would also bring a shower of media interest, funding, and most importantly, excitment back into the tech industry which, in this humble open-source developer’s opinion, is something that it is desperately in need of.
So yes, the Zigbee and RF4CE tie up is great, but the real holy grail is if Zigbee and 6LoWPAN could settle their differences and work together to really create…dare I say it…the “Internet of Things”.
- Written by Akiba
This was all possible due to a very generous sponsorship into the Zigbee Alliance by SmartLabs .
SmartLabs LLC is a Russian company that develops and delivers software solutions for service provider content delivery platforms (IPTV, DVB-S/C/T/H), NGN voice service platforms, OSS/BSS systems, and other innovative solutions for service providers and enterprises.Zigbee certified stack...here I come!...
- Written by Akiba
All of the hype surrounding the smart grid and the proposed overhauls to it in the US has generated a lot of buzz on the internet. With the Obama administration, the US financial stimulus package, and now Google throwing their hat in the ring, it's unleashed a torrent of publicity on an industry that was actually less exciting than watching the paint oxidize on your '91 Honda Accord DX. (Disclaimer: I've never owned a '91 Honda Accord DX, just a '89 Accord LX-i and the paint job was pristine).
As I read a lot of the articles, one thing that kind of irked me was that many claim that open standards such as TCP/IP must be used for the smart meter communications. To top it off, it seems that this statement was also mandated in the US financial stimulus wording (I haven't actually read it, but all the articles would state this as a source) which was extremely bizarre. So I decided to take it upon myself to try and clear up some of the air about this issue before the Zigbee and metering company marketing executives poop their pants.
Anyone in the WSN industry could tell you that TCP/IP would probably be the long haul communications method, but the local communications in the home area network will not be TCP/IP. The reason is that even though TCP/IP is an open standard, the interaction between devices isn't specified. In other words, there is no smart energy device profile for TCP/IP. The protocol was originally designed to communicate data reliably and higher layer applications would dictate how that data would be formatted and processed. Even for you to be reading this post, along with TCP/IP you still need HTTP to talk to the server, HTML to format the text, CSS to specify the page styling, and a compatible browser that adheres to the W3C standards that were created to make sure you can read this post. All of those standards are required because it specifies the behavioral interaction between two devices, in this case, a browser and a web server. The vehicle to communicate the data is TCP/IP, but you also need all the other standards in place as well and they need to be accepted by all companies. Otherwise, I'd have to state that my site can only be viewed by your Gopher client and other sites would have to state that they were only compatible with IE v3.6.
For these web sites or the financial stimulus package to state that an open standard like TCP/IP would be needed for the energy companies to receive "a chunk of that cheddar" is actually ironic. Since TCP/IP doesn't specify the device interaction, each vendor would need to implement their own protocol to talk to and control devices such as thermostats or smart energy appliances. This would then have the opposite effect of keeping things open because you would have a bunch of proprietary protocols to display things like real-time electricity prices that can calculate how much it costs you to play World of Warcraft at noon vs midnight.
So for those marketing people involved in Zigbee that are worried that TCP/IP or 6LoWPAN might steal their cheese, the truth is that both Zigbee and TCP/IP will be needed. Zigbee will still have the very important task of handling the home area communications such as the real-time pricing, demand response, energy usage data, and dimming the lava lamps during peak hours. This is because the Zigbee Alliance lucked out and hit a home run with the Smart Energy Profile right when the world collapsed and we got a black president that is environmentally conscious. And most likely there will be some kind of TCP/IP enabled gateway which will take your Zigbee Smart Energy Profile energy usage data, translate it to TCP/IP, and transmit it for the world to see on the Google Power Meter app so that people can create a mashup that paints your house red on Google Street View for consuming a lot of electricity playing World of Warcraft at noon while your lava lamps are still on.
- Written by Akiba
Well, I finally got my arms around the Zigbee Cluster Library. I received some example code that I was able to study, went through some vendor code that was available online for download, and built a small software test bed that I could prototype different methods of setting up the ZCL architecture. Now I realize what had me confused. The ZCL is basically an exercise in managing data structures. If you have your data structures set up properly, then the architecture kind of reveals itself. But to get to that point is pretty difficult, since they kind of just throw a bunch of abstract data concepts at you without a lot of explanation on how they are organized and fit into each other.
My simple brain has a hard time organizing and visualizing a bunch of abstract data elements and functions which was why the ZCL design (and the Zigbee stack design) didn't just leap out at me. So I decided I needed a test bed so that I could get some hard experience on trying out different ZCL architectures. I couldn't tell from the spec whether the ZCL is above the applications, below them, or just off to the side in terms of the stack. Aside from the nice block diagrams that the Alliance uses for their Open House presentations, an actual implementation of the ZCL is quite different. After I iterated a couple times on the prototype architecture, I could see why some elements were needed and where they would fit into the ZCL design. I'm slowly converging on a ZCL architecture that I think will work. Once I get it down, then I'm going to try and integrate it into the stack.
Well, enough about me...was that a crazy week in the Zigbee world or what? First, Atmel put the last nail in the coffin of Meshnetics by buying up their IP . Now they finally have a complete solution to compete against the likes of TI, Ember, and Freescale. It's good because I always thought the Atmel radios had nice specs but the lack of software that they could give out for free was really killing them.
Also, with DistribuTech going on, there was a torrent of smart energy articles featuring Zigbee and other technologies being integrated into smart meters. The smart meter industry is like sharks circling around a big bucket of (stimulus) chum that's about to be dumped into the ocean. Obama may have done more for Zigbee than he did for the Blackberry.
One other interesting thing I've been noticing is the lack of Z-Wave news after the purchase of Zensys by Sigma Designs. Other than some product announcements during CES, it's been pretty quiet from the Z-Wave camp...
That's it for now. My dog is subtly informing me that she wants me off the computer and to take her for a walk. So in order to avoid a pile of shit in my lab, I'd better heed nature's call...
- Written by Akiba
Yes, the Zigbee Cluster Library (ZCL) is the final obstacle standing between me and a semi-decent Zigbee stack. Of course there are still a lot of loose ends that need to be tied up on the other layers of the stack, but getting past the ZCL would give me a compatible stack from the top of the Zigbee spec down to the 802.15.4 radio driver. Uhhh...minus security. But that Zigbee Cluster Library wall is pretty high...
It's not so much that the ZCL is difficult to implement. It's more like it's really bizarre. For Zigbee, each endpoint houses one application. So if you want a dimmable light, that would take up one endpoint. If you wanted a second dimmable light, that would take up a second endpoint. If you also wanted a thermostat control (even though I don't know why you'd want to have a hybrid thermostat/dual dimmable light switch), that would take up a third endpoint. That part, I'm okay with.
If it were up to me to write the spec, I would have just specified the commands that went over the air to handle a dimmable light and a thermostat. The spec already handles the endpoint addressing and identification so the endpoint can decode the command and make the light brighter or less bright or turn the heater on. The commands and the behavior that each command implies are the domain of the spec, and the handling of the commands are the domain of the programmer.
However for some reason, the Zigbee Alliance decided to make an abstract library to handle all the possible commands used by all the possible profiles and device types. It grouped the behavior into things called clusters which contain attributes and commands. For those that are versed in object oriented programming, the metaphor seems to be the same as the classes, where the cluster is the class, the attributes are the class variables, and the commands are the class methods.
On paper, this seems like a good approach. Abstract the behavior of all possible profiles into a generic library and each profile and device type uses a subset of the library to implement standardized functionality. I get it. But the problem is that it's just plain weird to implement it.
First of all, C isn't too friendly with this approach because it's a bitch to implement class-like behavior in that language. I mean, that's why C++ came into being, right? But if you used C++ or any other OO-language for the stack, your binary would be a fat mofo that would need to run on an ARM9 or something.
Luckily, a lot of the vendor stacks expose the source code of their ZCL since it's so close to the application. And of course you can't enclose an application into a binary since this is what your customers need to modify and tune for their product. And from what I've seen, most of the ZCL implementations are pretty complex.
For example, if I wanted to create an on/off light switch, my normal instinct would be to pass an incoming frame to a handler. The handler would parse the payload of the frame and decide if the light should be on or off. Ba-da-bing, ba-da-boom, there's your Zigbee RF mesh networked light and light switch.
But in ZCL vocabulary, I would need to create the ZCL foundation classes, excuse me...clusters, and implement the cluster attribute read/write/discovery commands. Then I would need to implement the basic, scenes, groups, identify, and on/off clusters. And of course I would need structures to handle the attributes, attribute lists, and cluster lists. And finally, when I tie everything together, I'm able to turn a light on and off.
Don't get me wrong. I'm sure that the ZCL is a wonderful thing, and that abstraction kicks ass. And I can't wait for virtual clusters to be implemented along with encapsulation and UML cluster diagrams. But in my opinion, I think that the spec writers could have simplified Zigbee a lot by just defining the commands and the behavior instead of providing an abstract architecture and library that, although designed to save space and reduce repetition, actually ends up taking more space and adding complexity.
Just my $0.02. Gotta go...that ZCL ain't gonna write itself...
Updated 2009-02-05: Someone suggested that the ZCL can also be used to specify standardized device profiles for other networking protocol stacks such as 6LoWPAN due to its abstraction. So I guess I can see the benefit of architecting it in that way. Although I'm sure the Zigbee Alliance never meant it for that purpose.