Post Category →Z-Wave

In today’s typical smart home, you do not find gesture sensors connected to HA controller. Gesture recognition technology exists, but it’s still too expensive for wide deployments. Some of the examples would be Microsoft Kinect or perhaps Flutter acquired by Google.

For a while, I was experimenting with several ideas on how to add gesture recognition to my sensor’s portfolio. I believe that such sensor could be valuable not only for home automation systems but also for commercial deployments. For instance, in a hospital, if one need to adjust the light level while wearing surgical gloves, gesture would be preferred over dimmer touch.

Inexpensive, embedded gesture sensor technology could replace dimmers and fan controllers but more sophisticated versions could also provide functionality to actually control more than one end-point. Imagine that horizontal gestures will allow selection of devices to be controlled while vertical gestures will actually allow control of the selected device. So, if I wave my hand down the light will slowly dim, until I generate another gesture to stop that action (or until the light would be completely off).

The initial proof of concept was build using optical gesture sensor connected to CC3200 board over the I2C bus. The CC3200 was connected over WiFi to the IP network and the MQTT protocol was used to report events. Actually, there are two ways to interpret gestures; CC3200 could decode detected sequence and interpret the event locally and then send it using MQTT to the HA controller. Alternatively, RAW events could be send over MQTT and then a server would interpret them using it’s more powerful CPU. In case of MQTT, or IP connectivity, both options work well, and either one could be selected.

In order to connect to an ordinary HA system, z-wave communication is required. Because of latency of the z-wave network, only local interpretation mechanism is acceptable. In case of z-wave, since we do not need IP connectivity any more, CC3200 is also too much for this system and a smaller processor can be used. Interpreted results will be send over the SPI bus to a z-wave module (radio) and then to your HA controller.

Initially, it will present itself to your HA controller as a light dimmer, but at later point, unique specification will be created in order to allow for wider scope of operation.

As I mentioned in my last blog, I became familiar with Z-wave after I already had my Zigbee solution fully operational. It’s not that I did not hear about Z-wave but I could easily obtain Zigbee hardware and build something quickly.

Zigbee standard is controlled by Zigbee consortium, anyone can become a member of that group, however the membership is not free. In order to display Zigbee logo on your products one must be a member of Zigbee Consortium. I believe, that members also have access to sample code and some additional documentation on top of what is available to general public. On the hardware or silicon side, you have plenty of choices, starting with Texas Instrument you can also select MircroTec makers of AtMega or the chip used on your favored Arduino device. Each Zigbee silicon vendor provides also it’s respective stack, working on their and only their chips. Pricing models are different, in case of Ti, you pay a premium for Silicon, but the actual stack is free, in case of MicroTec, the Silicon is less expensive but you need to purchase a stack ( one time fee of $1k USD), in any case, those amounts are easily affordable by any commercial entity.

In case of Z-wave, you have one single company Zensys, standing behind it. Zensys is a division of Sigma Designs, so sometimes you could hear that name as a z-wave vendor. That obviously has some pros and cons. Having monopoly, Zensys can dictate the price being as high as they want it. On the other hand, interoperability is not an issue. Single vendor issues Z-wave approval stamps and since all the code is based on the same SDK coming from a single vendor, interoperability is not so much of a challenge.

Z-wave is intended for Home Automation, all features are well defined and relatively easy to implement. In case of Zigbee, you have additional logical layer, called profile, which basically describes what Zigbee product family your product belongs to. One of those profiles is called Home Automation and that profile would be an equivalent to z-wave. If you look at some very popular products such as Hue Lights by Philips, they also use Zigbee but they are in a different space or using different profile called Lighting profile.

Each profiles defines its respective clusters which have similar equivalent in z-wave called commands class. Above clusters you also have endpoint type (like a light or a switch) and Zigbee standard defines mandatory and optional clusters for input and output communication. For example, the light will have light on/ off cluster define as its input as it should receive such command from its controller. Light switch will have the same cluster define as its output, as it will send such command to its controller once you press a physical switch on a wall. Optional clusters are for descriptions or additional functionality such as battery status and such.

As you can see both protocols are very similar from the high level view or at the conceptual level. Knowing Zigbee, I did not have any problems understanding Z-wave concepts

Reading this you could ask, why would one even look at Zigbee, after all Z-wave is all you want. Well, Zigbee supports two frequencies, but really only one, 2.4GHz is popular. The same frequency is used globally!!! This is critical, because one device can be sold globally!!!. In case of Z-wave, you need to deal with multiple frequencies designated for different geographic regions, even the physical micro modules you purchase from Digikey are designated for North America and the rest of the World ( actual very specific frequency can be controlled at the firmware level).

So, you have much easier interoperability vs. a single module operating globally, what is better? You should also consider fact that with the same Zigbee chips you could potentially, use different profiles for Building Automation for example. But you can not underestimate variety of choices for z-wave controllers in the Home Automation World. Zigbee choices are very limited at this point. Also, seamless interoperability between Z-wave devices can not be underestimated and this is why I would strongly recommend Z-wave over Zigbee for home automation devices.

At the beginning, I started playing as hobbyists with technologies like Zigbee and Z-wave, adding Bluetooth Low Energy to the equation shortly after.

Very quickly, I understood of all challenges and shortcomings, problems related to interoperability between vendors and types of devices ..

Let me step back to the beginning, several years ago, in my first project, I planned on integrating telephony with Home Automation. Imagine being able to call your small Asterisk PBX and using DTMF (tones) control your door lock, or perhaps water your garden. All that just by calling your home and sending some digits from your DTMF keypad. I have decided to use Zigbee as communication protocol between a telephony device (home automation controller) and all our end points. You may ask, why Zigbee? Well, I could get all necessary software from Ti without spending a fortune, so, why not. In a couple of evenings, we designed tiny module for my IP04 and wrote a driver to control it using SPI, just to make it compatible with standard telephony modules used in IP04. For Zigbee chip, I decided on CC2530 by Ti. Together with a friend, we created a Zigbee controller to parse and interpret Zigbee messages and to control our end points. All running on a Blackfin based IP04 PBX. Quickly, we understood that this is not the right way, hard coded rules to open my door were working just fine, but this is not what Home Automation is about.

Our first disappointment? Our Zigbee module would not communicate with commercially available Zigbee controllers. Sounds familiar? If you are involved with Zigbee you probably know what I am talking about.

The actual remedy was “simple”, we just had to change the firmware to use Home Automation profile instead of a private profile we defined initially to communicate with our own controller running on the IP04. To get to that point, wasn’t however easy, as early SDK from Ti did not explain it clearly, and we end up spending countless hours sniffing and comparing our modules to commercially available ones.

To be honest, once we figured out that profile definition was causing our pain, we fixed it in a couple of hours. In the meantime, we have learnt that Zigbee is not yet very popular in Home Automation world and if we want to have access to variety of inexpensive devices we need to look at another technology, and this is how we started looking at Z-wave…

See my next blog for description of differences between those two great wireless protocols and pros and cons from our perspective.