Application developers may question initially if Zigbee is the right solution for their application This article explores various characteristics of Zigbee that can be helpful in determining if this is the right technology for your application or not.
Zigbee Characteristics
Here are some basic characteristics of Zigbee that should be considered.
| Metric | Description |
| Network Topology | Point-to-point, point-to-multipoint, mesh.Self-forming, self-healing. |
| Number of Devices | Up to 65,000 in some cases |
| Data Rate | 250kbps RF data rateEffective data throughput is lower and depends on various factors (number of hops, level of encryption, acknowledgments enabled or disabled, etc) |
| Encryption | AES-128 |
| Range | Up to 300 meters line-of-sightUp to 100 meters non-line-of-sight |
Given these metrics, if an application requires streaming video or audio, then Zigbee may not be the best solution. A higher bandwidth technology such as Wi-Fi or Bluetooth might be better suited to those requirements. If the application will send shorter bursts of data, then Zigbee might be the right solution.
What has already been done?
The Zigbee Alliance maintains a listing of about 2000 certified products that can be found here. This list includes lights, thermostats, gateways, on/off switches, door locks, sensors (motion, temperature, open/close, etc), outlets, switches, meters, remote controllers, smoke detectors, green-power devices, etc. If a product in the listing is similar to your application, then Zigbee may be the right solution.
Network Topology
Zigbee deployments require at least one coordinator and possible some routers. If battery-powered end devices are needed, then there must be enough routers to support the expected number of end devices. Can the application support a mains-powered coordinator and mains-powered routers? Zigbee does not support an entire network of battery powered devices. Each network must have a coordinator and an adequate number of routers to support battery powered end devices.
Regarding the number of routers – routers and coordinators are able to store data packets for end devices that may be sleeping. When an end device joins the network, it associates to a single router or coordinator and that router or coordinator becomes the end device’s parent. When an end device wakes up from sleep, it lets its parent know it is awake and the parent router or coordinator can finally deliver any stored data packets to the end device. However, each coordinator and router can only support a finite number of end devices. The number of end devices that each coordinator or router can support depends on the Zigbee stack, and on the implementation. This number could vary from a couple up to around 30 end device children per router or coordinator. The routers and coordinator also have a finite space for storing data packets for end devices. This also depends on the implementation.
Power Requirements
As noted above, each Zigbee network requires a mains-powered coordinator and mains-powered routers to support battery powered end devices. To improve battery life, most Zigbee systems are designed for the sensor to sleep and wake periodically or when a certain event happens (button press, sensor trips, sample ready to be transmitted etc). Data commands can be pushed out to the sleepy end devices, but at a slow rate since routers can only buffer a finite number of packets. There are ways to design the application that can send large amounts of data or commands to a sleepy node if necessary.
Interoperability
Does your application stand on its own, or will it need to interoperate with other devices? Would interoperability bring added benefits to your solution? For example, if you are developing a light and you choose to make it work with Zigbee, then your light will be able to interact with lights, switches, gateways, and other technology from other manufacturers, including the Amazon Alexa.
If your product does not need to interoperate with products from other vendors, Zigbee can accommodate this as well using a private manufacturer-specific profile and encryption (if desired). This allows you to develop your own data packet format on your own profile such that public interoperable products will not interoperate with your products. This allows you to still leverage the mesh routing and security capabilities of the Zigbee standard while designing for the specific requirements of your application.
Mesh Routing
How will the devices in your system be deployed? Will all devices be in direct range of one another, or is it possible that devices may need to use mesh routing (multi-hop) in order to send packets through the network? If mesh routing is not required, perhaps an 802.15.4 MAC layer solution would be adequate. (For data intensive applications, an 802.15.4 based-solution has a higher effective data rate since it is a simpler stack and does not have the added delays, retries, and backoffs of the Zigbee network and APS layers.)
Application Messaging
If your application needs to support basic commands like reading a sensor, setting an on/off or output level setting, setting a color, sending a message, etc., then the Zigbee application layer may have existing messaging to accomplish those requirements. These can be leveraged in your application to interoperate with devices from other vendors that run in the same environment.