Use of CRC16 class encoded messages



I am currently a little bit wondering about the use of CRC16. As described in the specification, the device must answer with a CRC16 encoded message if the request was CRC16 and vice versa. But how does a node decide to send unsolicited messages e.g. after a temperature threshold was exceeded or a door was opened? Currently my device is answering the requests as expected, but the unsolicited messages are all without CRC16 encoding?

So how can I change the behavior of a node so that it uses CRC16 also for unsolicited messages? Is there some controller capability that has to present or something in the NIF of the controller that need to announced to the device during the include process?

I hope someone can share some insights here…

Thank you in advance,


A sending node should normally read the NIF of the receiver in order to ensure that it can handle the CRC-16 encapsulated commands. It can then subsequently decide to use CRC-16 for unsolicited traffic.

Slave nodes or nodes issuing commands via Association Groups do not read the NIFs of other nodes before transmitting and there is no other mechanism allowing a node to start issuing commands with the CRC-16 encapsulation, at the moment.


so if I understood you correctly, that means a normal node will never send CRC16 encoded unsolicited messages at all.
That makes the class not very helpfull… Most of the problems I currently see is during the unsolicited messages. The weak checksum allows a lot of broken messages to be accepted, resulting in some very interesting readings, especially for the meter class…



Hi Andreas,

There is no official way to do it, but it is still legal to implement a method for having a device use CRC-16. A node must not be using CRC-16 by default, but for example it is allowed to have a configuration parameter (Configuration Command Class) enabling the use of CRC-16 on association groups. However, this is optional and therefore you may not have such implementation in your devices.



Hi Nicolas,
yes, there is no such configuration available, so we can implement CRC16 encoding and decoding for normal messages, but the unsolicited messages will not be protected. Unfortunately we have some users that seems to have transmission problems and are using 40kBaud transmission and report a lot of “funny” readings in the system due to broken messages with “correct” checksum.

Ok, we can only hope that the internal CRC16 checksum with 100kBaud transmissions in newer devices will prevent this. And in the future all new device should support security which has a strong checksum in the authentification code.