Nordic Chooses DSR & Wins

Nordic Chooses DSR & Wins

DSR Corporation announces its partnership with Nordic Semiconductor. DSR’s ZBOSS 3.0 Zigbee 3.0 software stack is part of the Nordic offering for the multiprotocol nRF53840 SoC.  ZBOSS software was formally certificated by the Zigbee Alliance in September of 2018 as a Zigbee 3.0 compliant platform.

Satisfied Clients

“We are very satisfied with the choice of the Zigbee 3.0 solution vendor for our nRF52840 multiprotocol System-on-Chip (SoC),” says Nordic’s Pär Håkansson, Strategic Marketing Manager. “DSR Corporation has proven itself as a highly reliable partner, working closely with Nordic to make joint production quality software. We appreciate DSR’s professionalism, teamwork and extensive experience in software engineering and Zigbee to help us deliver a new solution to the market that will broaden Zigbee reach around the world.”

What`s Inside

nRF52840 is designed around an Arm® Cortex-M4 CPU with floating Point unit (FPU) and provides the ability to support complex and demanding applications as a single chip solution. Implementation of Zigbee in the nRF52840 SoC expands Nordic’s already broad portfolio of mesh networking solutions for smart home, industrial, and enterprise industry.

DSR’s ZBOSS 3.0 is a cross-platform, high-performance Zigbee 3.0 software protocol stack implementing Zigbee 3.0. ZBOSS 3.0 is highly interoperable and has been used as a Zigbee Pro compliant platform for several chipset solutions. ZBOSS 3.0 is a market-proven product that is used to provide interoperability between 200+ products at more than 40 companies.  ZBOSS 3.0 allows all devices roles and provides extensive support for various cluster libraries.  User-friendly, high-level APIs support fast creation of applications on a predictable budget.  Built with a fixed memory footprint, ZBOSS does not use dynamic memory allocation, which leads to predictable memory budgeting.  Lastly, an important stack feature is optimized power consumption: ZBOSS interrupt-driven I/O improves battery consumption and excludes polling. Additionally, ZBOSS utilizes low RAM capacity on the target device with a special technique in handling data structures.

Worldwide Acceptance

Following the launch of this product, we are happy to announce that Nordic’s advanced Bluetooth® 5/Thread 1.1/Zigbee PRO solution won “2018 Product of the Year”. The nRF52840 chip was named winner of the “RF/Microwave” category by Electronic Products Magazine, which has been an industry icon for more than 40 years. We are both excited for Nordic and honored that they selected us as a trusted technology partner.

ZigBee 3.0 Evolution of Things

Another CES has come and gone. The wheels have touched down, and you are likely back home. You and your team have refueled with a few well deserved, solid nights of sleep and it’s now time to reflect on what made CES 2016’ special. Let’s highlight one of the exciting moments; the ZigBee Alliance announcement of ZigBee 3.0.

With ZigBee 3.0, there is no reinvention of standard, sudden updates, or unpredictable changes – we are looking at the refinement of a proven technology. Using natural selection as an example, we are watching the substantial evolution and adaption of ZigBee with the IoT market confirming the technology maturity. Observing changes in the wireless technologies and connected IT business environments, we are tracking the reactions of the ZigBee standard in response to this.

The key features of ZigBee 3.0 include dramatically improved interoperability and strengthened security. DSR has been continuously involved in the implementation of ZigBee Pro since the 2006’ standard and we can confirm that the new features in ZigBee 3.0 are a real game changer, especially the convergence of the application profiles to a unified base device implementation. At first glance, this change is the kind of revolution in ZigBee that casts doubt on the previous specification. We do not view it this way.

Earlier, when the profiles were developed, the market was a union of isolated areas. Which areas, you might ask? Well, let me challenge you to quickly recite the ZigBee profile names. If you’re like us, you don’t like separate smart home, light control, or energy measurement functions. We want the Internet of Things and we now have extremely inexpensive, more powerful microcontrollers to build it with. We don’t need profiles anymore. We need the unified implementation enabled by ZigBee 3.0.

Structural consequence of the profile evolution into a base device approach is strengthening the role of a cluster as a unified application building block (clusters were developed for this, of course). ZigBee Alliance goes further and standardizes device types. For us, this approach becomes quickly rudimentary because all the tools are ready for dynamic discovering of devices. We’re talking about EZ-mode commissioning that is now able to discover all the features of the added device right at the commissioning step. After finding and binding, the application has full details about the joined device and bound clusters, so the device type information could be used only for predictions. What we would like to see instead of standardized devices is the strict, “survival recommendation” list for different groups of devices. For example, recommendations for implementing optional attributes/commands or, more specially, having poll control cluster for sleepy end devices, etc. (see our previous blog post).

Overall, a transformation of the profiles multiplies many times the core and indisputable advantage of ZigBee – mesh networks. Devices that previously joined the different networks will truly co-exist now. The new standard allows ZigBee to keep their status as one of the most energy saving choices. Moreover, with the Green Power feature in ZigBee 3.0, devices without batteries can operate in the network.

In conclusion, to all the benefits of ZigBee 3.0 painless backward compatibility and OTA Upgrade feature guarantee, that neither user nor developer will have trouble with switching to the new standard or supporting old devices. What is the best, now only a ZigBee sign on the device’s box makes sense: not profile, even not ZigBee PRO or ZigBee 3.0. For example, how often do you care about 1.1, 2.0 or 3.0 USB device you buy? That is the same.

What do we have as a result? The mesh self-healing network of green, low-power devices with the unified easy installation mechanism, growing community, and continuous evolution. Isn’t that a synonym of IoT?

The Real Reasons Behind Most ZigBee Interoperability Problems

Interoperability is a buzzword that we hear often when talking about wireless protocols, including ZigBee. Being an already trusted but still young standard, ZigBee itself can raise many questions when reading the official documentation. However, that is not the topic of this blog. With over a decade of experience in wireless communications software development and 7 years working closely with ZigBee, we have seen many cases where although the specification gives adequate description, developers invent their own bicycle. Our extensive experience integrating and working with a large number of sensors from different manufacturers provided us the valuable insight we are sharing in this blog.

The field where there is so much space for creativity and hence mistakes, is the application layer, when profiles join the game.

Let us start with one simple flag – “Manufacturer specific” flag in ZCL header, invalid usage of which may cause a variety of problems. The right way of using it is extending the functionality of ZCL (HA), adding attributes or whole clusters that are not provided officially. For example, we cannot guess, why “Temperature measurement” cluster has a “tolerance” attribute, while the “Humidity measurement” does not. It is about the fact that if you want “Tolerance” attribute in your humidity sensor, you need to make a manufacturer specific attribute. Or, in another example, let’s say you are working on a ZigBee-based pet tracking system. We promise there is no “Animal tracker” cluster in any specification. You will need to implement it yourself and, yes, it will be manufacturer-specific.

The common mistake of using this flag is marking general attributes and commands with it. We faced it while working with IAS sensors and made us wonder why the standard enrollment procedure needs any manufacturer code. Do developers really consider their manufacturer code safer from intruders than the entire ZigBee security system?

Anyway, it can be easily debugged, because the only thing we need to know in this case is the manufacturer code. There is a way to obtain it using only ZigBee tools: the code is placed into the node descriptor. If the node descriptor does not work, it can be requested from the manufacturer. And, when there are no contacts, ZigBee sniffer can help too. If there is a coordinator that the intended device successfully enrolls with, then with the proper enrollment procedure caught by the sniffer, we will get the code. Another way to achieve this is by writing any attribute in the intended cluster and probably getting the response with the code. Moreover, configuring and binding the intended cluster may cause some manufacturer-specific attribute to be reported with the code. So, they key is just to be patient.

This mistake may be worse when the device confuses ZDP discovery tools: for example, the cluster is not returned in a simple or match descriptor response, but some commands are supported and they are manufacturer-specific. In this case, discovery does not work and you will need either a technical contact or a lot of time to experiment.

In this case all we know is that the device in our hands is a ZigBee device and what it is used for. So we can predict its cluster list. The only thing we can do without manufacturer help is to send commands to the predicted cluster waiting for the response with some status.

The next issue has to do with attribute semantics misunderstanding. When the number of attributes exceeds two-three and cluster logic becomes complicated, this can lead to misunderstanding of an existing attribute’s meaning . Just imagine the situation when you try to set temperature on a thermostat but it is still too cold or hot in the room. Now we take this HVAC system and try to guess, which setpoint the “Setpoint Raise/Lower” command operates with? It depends on the command’s mode as well as current system’s mode. But some developers may like only one clear attribute and of course it will cut the existing logic. In this case, specification misunderstanding can even cause attribute duplication.

One of the last common problems has to do with a very useful HA extension – poll control. Even though it is strongly recommended to implement it, it is often ignored. However, real problems come, when the device has its own long poll interval that is much longer than the default one. If we leave the situation as is we will for sure have many packets lost for such a sleepy device. Therefore, we should increase the timeout for deleting expired indirect packets. This does come with a risk: if the interval is too high, the queue most likely will got overflowed. That is why when increasing the indirect queue timeout, updated coordinator should be tested in a large network with a lot of sleepy devices connected.

To close, we want to add a few words about the mistake that will not break interoperability, but can be frustrating and easily avoided. Unfortunately, as of today we do not have as many reportable attributes as we may want. And everybody who faces this problem solves it in his or her own way. We have seen “Write attributes” sent to the client cluster and even reports that were not configured. It is the only problem described here that can be attributed to by the lack of functionality in the official specifications. We are sure this will be addressed in one of the next updates. But we are sure that the devices that skip the configure/bind logic before sending reports will not disappear for many years.

We hope this blog gave enough examples to show that most interoperability problems at the application layer appear because of not completely understanding ZigBee Alliance documents. With the growth of ZigBee technology and the number of well-designed devices, such misunderstanding may make the product less competitive and supported. It is key to take time to understand and follow the standard to avoid these issues and ensure the success of your products.