Posted on

Deep Dive into Zigbee for Home Automation

Illustration: © IoT For All

There are many different choices for IoT devices these days, and there are many different ways to connect to these devices, such as WiFi, Bluetooth, Z-Wave, etc. In this post, I discuss Zigbee—its advantages, disadvantages, and applications in home automation.

What Is Zigbee?

Zigbee is a network protocol based on the IEEE.802.15.4 specification, a standard for low-rate wireless personal area networks (WPANs). Zigbee expands on the IEEE specification by “adding mesh network and security layers along with an application framework to become a full-stack, certifiable, interoperable solution.”

A Zigbee device typically has four layers—the IEEE.802.15.4 Radio, Zigbee Pro, Zigbee Cluster Library and Zigbee Certification (see below). Zigbee Pro is the network infrastructure, implementing features ranging from communication band specification and pair mechanisms to security key generation and power saving. The Zigbee Cluster Library is the application layer, which is used to define clusters that are standard sets of messages/device behaviors to allow Zigbee devices to behave in a standard manner across devices. This helps with interoperability, so Zigbee devices from different manufacturers can work with each other.

Zigbee devices typically communicate over 2.4GHz, but they can also communicate in sub-GHz bands, which are region-specific. Zigbee can transmit anywhere from 10 to 100 meters over 2.4GHz. It can transmit up to 1km on the sub-GHz bands. Since WiFi also uses 2.4GHz, Zigbee devices handle interference over 2.4GHz by having 16 separate channels of communication. They also automatically retransmit data as well as send a low number of data packets, making transmission failure unlikely.

Zigbee is interoperable, which means that if I buy two different Zigbee devices, they’re capable of communicating with each other over the Zigbee network. While there are limits to interoperability due to multiple application profiles, such as Home Automation and Smart Energy, Zigbee’s device interoperability is still a very useful feature.

Zigbee is capable of forming various arrangements of networks, or network topologies, between its devices. The most common network topologies are shown below—star, cluster tree, and mesh. Each Zigbee network can consist of three types of devices: end device, router, and coordinator. A coordinator is responsible for creating the network as well as routing traffic through it. A network can only have one coordinator. A router is responsible for routing traffic, and an end device does not route traffic through the network. (Silicon Labs and Elprocus).

Image Credit: Elprocus

Finally, Zigbee’s main advantage over another network protocol like WiFi is that it’s very low-power. This is a result of it being IEEE.802.15.4 standard plus the Zigbee protocol itself mandating lower power operation. While this does mean that Zigbee devices may not have a high range or push through much data, they do save power, money and maintenance work. Zigbee even has a Green Power feature, which allows battery-less devices to join the network. According to the Zigbee Alliance, “Green Power [can take] advantage of the energy used to flip a typical light switch via common energy harvesting techniques, which is powerful enough send commands through a Zigbee PRO network.”

Credit: Elprocus

Home Automation

Now that we have understood what Zigbee is at a high level, let’s look into Zigbee’s application for Home Automation. Zigbee is ideal for the home environment becomes out of the box with a mesh network and most devices should be within the 10 to 100 meter range of each other. It is nice to know that you can go to the store to buy an entirely new Home Automation Zigbee device and it will connect into your existing mesh network. Currently, the Zigbee Alliance site lists about 400 devices for Home Automation. The Home Automation Zigbee Devices are all the common IoT Home devices such as light bulbs, switches, locks, motion sensors, and thermostats.

There are major companies with Zigbee products including Samsung, Bosch, Honeywell, Texas Instruments and Amazon. In fact, Amazon’s Echo Plus came with a built-in Zigbee hub to control Zigbee devices. Samsung’s SmartThings devices use Zigbee as well to communicate (they also support Z-wave). It’s good to see that Zigbee has support from big-name companies and a wide range of devices.


In conclusion, Zigbee is a low-power low-data network protocol. Zigbee devices can easily be added to a network, such as a mesh network, to communicate with each other. It’s ideal for applications such as home automation, where devices don’t communicate frequently and are in close range of each other. Zigbee’s built-in power saving is a great feature that allows devices to last on battery much longer than other network protocols. I hope you all try Zigbee devices to automate your homes!

Looking for more on network protocols? Check out this overview of smart home network protocol options.

Source: IoT For All

Posted on

Why You Need Contextual IoT Device Management

Illustration: © IoT For All

In my previous post, I gave an explanation of basic IoT device management and why it’s insufficient for certain kinds of massive-scale IoT deployments. In addition to basic IoT device management, contextual IoT device management is necessary to ensure success when dealing with IoT solutions involving thousands to millions of devices.

In this post, I explore some of the key aspects of contextual IoT device management, with real examples that demonstrate why you need to manage devices contextually if you’re building, buying, and/or implementing massive-scale IoT solutions.

Identify and Address Issues

When building, buying and/or implementing IoT solutions, it’s critical to assume that devices are going to experience issues. The world is imperfect. Trying to make an IoT solution perfect is an impossible and foolhardy endeavor. If you have one million devices, all it takes is a failure rate of 0.1 percent, and you already have 1000 devices that will fail. For IoT solutions with devices expected to last for years in harsh conditions, the percentage of devices that will experience issues at some point increases dramatically.

Issues with devices can take many forms, including hardware defects in manufacturing, firmware bugs, device failures due to extreme temperatures or weather conditions, degraded performance from wear-and-tear, dying batteries—the list goes on. It’s therefore essential first to be able automatically to identify, and then be equipped to address issues, with IoT devices.

Let’s look at an example in which you have thousands to millions of devices in an agricultural setting. What happens when a device stops communicating? If there’s an issue with the device, you’ll want to replace that device with a new device. Alternatively, if the device’s battery is simply drained, you’ll want to replenish the battery in that device.

In either case, you’ll first need to know where the device is located. If the devices don’t have a GPS module, this means that when the devices are installed out in the fields, you’ll probably need to record their coordinates (latitude/longitude) as part of the installation process, so that you can visualize them in a user interface (UI). These installation and visualization capabilities would need to be included as part of the IoT solution.

In addition, it would be costly to replace or replenish individual devices, so instead, you should probably hunt down and address multiple devices at a time. Rather than replenishing drained batteries after they’ve already died (and thus have ceased to provide you with data), you’ll want to know which devices are getting close to being fully drained. But what does “close” mean? Where’s the threshold? Devices may be able to report the percentage of battery life remaining, but what does “10 percent battery life” translate into? A year? A few months? A few weeks? A day?

The rate of battery drain depends on usage, and usage depends on the use case. For a use case like agricultural IoT, the battery usage will likely be relatively consistent and, therefore, predictable. However, in asset tracking use cases, the usage can be dependent on how much the assets are moving, which is inherently difficult to predict with high accuracy. To make such a prediction, the IoT solution will need to determine what usage is “normal” and use that as a baseline for predicting battery life remaining for devices.

As you can see, the ability to automatically identify and then be equipped to address potential issues with devices is heavily dependent on the context of the use case and the business needs that inspired it. This is why you need contextual IoT device management.

Classify Devices into Contextual States

The previous section focused on issues with devices, whether that’s an issue such as a defect that prevents a device from communicating, or simply that the device’s battery has drained and is in need of replacement/replenishment. However, there can be situations in which a device is operating as expected without any issues, but there’s certain information that’s important to highlight for users.

Let’s return to the agricultural example, in which you might have devices attached to mobile agricultural equipment (e.g. a tractor) that enable that equipment to be tracked. The devices will likely be using GPS to get location data for the tractor, but unfortunately, GPS doesn’t work effectively when vehicles are inside buildings (here’s how GPS works). If all you show on the UI is the last known location of the tractor, and that tractor is now being stored inside a building, the GPS location won’t reflect the actual location of the tractor and can confuse users and/or geofences.

In this scenario, there are no issues with the device itself. However, the contextual state that the device is in (i.e. inside a building) is important to the functionality of the IoT solution. Therefore, you can use contextual data to classify the device—and by extension, the tractor—into a state (e.g. “indoors”) that provides helpful information to users so they’re not confused when the device can’t get an accurate GPS position inside a building.

However, the device itself can’t tell when it’s inside. All the device knows is that it isn’t getting a good signal from GPS satellites and therefore can’t acquire an accurate GPS position. Is it because the GPS satellite constellation just happens to be in a bad position at this particular moment? Is it because of adverse weather conditions? Both? Or maybe neither, and the vehicle is in fact indoors?


The above example from an agricultural IoT scenario is just one of many. The key takeaway is that contextual IoT device management is both essential and difficult. It’s essential because every IoT solution is different, and even the same IoT solution can be different when implemented within different businesses and contexts. It’s therefore difficult because this means that there isn’t a one-size-fits-all answer for effectively managing devices when you’re dealing with devices numbering in the thousands to millions.

I’m optimistic though! While we’ll never find a one-size-fits-all answer, we’ll continue to build the platforms and tools that will enable us to adapt IoT solutions quickly to varying businesses and contexts, unlocking the true potential of the Internet of Things.

Source: IoT For All