5 Best Zigbee 3.0 Practices for Developers

Zigbee is already a trusted, market-proven, and secure low-power mesh solution, but even mature and widely-used technologies can present a challenge if developers do not follow best practices. In this blog, our experts will provide 5 tips to help Zigbee developers clear up any documentation misunderstandings. We will focus on:

1. Manufacturer Specific Flags
2. Attribute Semantics
3. Poll Control 
4. OTA Packets
5. Reportable Attributes

We will begin at the application layer, where clusters and profiles are integrated. Clusters allow us to customize our solution to fit our specific needs, however it also presents opportunities for developers to make mistakes.

Best Practices for Manufacturer Specific Flags 

One of the first issues that developers often encounter is the “Manufacturer-Specific” flag in the ZCL (Zigbee Cluster Library) header. When the flag is configured incorrectly, a host of different problems can occur. Because the manufacturer-specific code is unable to be discovered during the standard enrollment process, developers often will try to set standard attributes and commands for manufacturer-specific code. The correct approach calls for extending the functionality of the standardized data model by adding attributes or entire clusters that are not officially provided by Zigbee. For example, if you’re working on a Zigbee-based pet tracking system, there will not be an “Animal tracker” cluster in any specification, meaning manufacturer-specific code will need to be implemented by developers. 

This mistake is amplified when the device confuses ZDP (Zigbee Device Profile) discovery tools.  a cluster is not discovered in the simple or match descriptor response. However, some commands may be supported, but are manufacturer-specific. In this case, discovery does not work, so you will either need to contact technical support or set custom commands.

Attribute Semantics

The next area we will focus on is attribute semantics. When the number of attributes exceeds two or three,the cluster logic becomes complicated. In this case, developers will often assign a custom meaning to an existing attribute. Depending on the command mode and the current system mode, this action can change the meaning of standard commands, which will naturally cut the existing logic. For example, the misuse of attribute semantics can disrupt something as simple as changing the temperature on a thermostat because the standard units of measurement have been mistakenly changed during the attribute update. That’s why it is critical that developers correctly implement custom attributes so that standard commands are unaffected. 

Poll Control 

Keeping our focus on clusters, our next concern is Poll Control. It’s one of the most impactful, but misused Zigbee features. Although the best practice is to implement poll control it is often ignored. Problems will occur when the device has its own poll interval that is longer than the default one. In this case, a user may either miss messages for a sleepy device or experience an overflow in their indirect message queue. While the first problem can be easily discovered during testing phases, the second problem will most likely appear as the network scales. Implementing Poll Control ensures messages are not missed and overflows are avoided.

OTA Packets

Moving away from clusters, our next best practice will cover Over-the-Air (OTA) upgrades.When updating an embedded system using) OTA programming upgrades, it is important to set standardized times to send the updates. If done incorrectly, some devices will send OTA packets, like Image Block Request or OTA End Upgrade Response, at random intervals. This leads to an mistimed update, which causes the coordinator to behave incorrectly. An update that does not deliver enhancements seamlessly can cause problems with a solution, sometimes leaving a system with poorer performance than before the upgrade. This is why getting OTA upgrades right the first time is critical for developers working with embedded systems.

Reportable Attributes 

Lastly, our final tip covers reportable semantics. Although it is often a common mistake that will not break interoperability, incorrect reportable attributes can be frustrating to experience. The Zigbee standard specifies whether or not an attribute is reportable. A cluster may have up to 20 attributes, whose status is automatically reported to a host. Often, developers do not have as many attributes reportable as they would like, especially for manufacturer-specific commands. If an attribute is not reportable, the value either goes unreported or developers must customize the reportable attributes. Because these reports must be manually set up, the configure/bind logic can be broken, which is why it is essential to understand what attributes are reportable for a specific cluster before sending. 

The Value of Best Practices

As you can see, most interoperability problems at the application layer occur due to incorrect development. As Zigbee technology grows and the number of well-designed devices increases, these mistakes can cause products to become uncompetitive and not supported, requiring a deep knowledge of Zigbee development. 

DSR IoT teams specialize in complex problem solving and project rescue, helping to overcome interoperability, performance, and security challenges. Learn more about DSR’s IoT Services at https://dsr-iot.com/services/