This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Zigbee messaging cluster

Hello Development team!

First off, many thanks for all the help provided so far.

I'm trying to add the ZCL messaging cluster to the multi sensor example, how could I go about do this? Examples?

How long of a string can I send (how much data)? Also how to control the period that the data is sent?

Thanks!

  • Hi,

    We do not have any examples using the messaging cluster, but we do have a guide for implementing a Zigbee end product with ZCL, where you can see how to declare attributes for each cluster, clusters, cluster lists, endpoints etc. I would also recommend looking at how similar clusters are declared and used in other examples, as well as the Zigbee Cluster Library specification to see how the messaging cluster is defined. This cluster can be found in chapter 10.5 in revision 6 of the ZCL spec. This cluster is a part of Zigbee Smart Energy, so you can also read about it in the Zigbee Smart Energy Specification Standard here in chapter D.5. The documentation for the cluster in our SDK can be found here, and you can find the implementation in /external/zboss/include/zcl/zb_zcl_messaging.h

    The messaging cluster does not have any attributes, so you do not need to declare that or anything related to attributes. This can be seen from the ZCL spec. There you will also find that the cluster has four commands, two by the messaging server cluster and two by the messaging client cluster: Display Message, Cancel Message, Get Last Message and Message Confirmation. The specification also contains information about the different commands, such as payload, when they are generated, effect on receipt etc. From my understanding, the server, or the ESI (Energy Service Interface), sends messages to all client devices with the messaging cluster implemented, using the Display Message command. However, I have asked our developers to confirm this and to clarify how to use this cluster.

    I have also asked our developers to clarify the maximum bytes of data the message can be, as well as how to control the period. The payload length of the Display Message command is restricted to 79 bytes, where 11 of these are used for the additional fields, such as message ID, message control, etc. You can see this in the specification for the cluster. This leaves 68 bytes for the message. However, I have not been able to confirm this yet, and there might be additional things impacting the maximum size. I will let you know when I hear back from our developers.

    Best regards,

    Marte

  • Hi,

    I have a clarification regarding message size. The Message field is limited to 59 bytes, which gives 58 bytes to the message itself. However, our SDK has support for APS fragmentation, which can be used to send longer messages. See the Buffer API for max_size argument.

    Best regards,

    Marte

  • Thank you Marte for the detailed and helpful answer!

    I have some other questions:

    I'm using the the multi_sensor example with the CLI example as demonstrated in the SDK, but I want to modify both so that I can send and array of values from the multi_sensor to the CLI.

    As of now the CLI only reports the first value of the array from the multi sensor (although the value is not correct).

    My questions are:

    1. How can I send an array of values from the multi_sensor.

    2. Where in the CLI example are these values received and stored (so I can check).

    3. How can I modify both examples so that they can both send and receive data, are where is that data stored?

    Originally I though to use the messaging cluster (hence my original question), but now I'm trying to define my own custom cluster to handle the task.

    Thanks in advance!

  • Would the Multistate Value (Basic) cluster be able to implement the required task?

  • Hi

    I am sorry for the delayed answer. 

    I believe the multistate clusters could be possible if your project are using multistate values. However, I am uncertain if the multistate value cluster is the best if your goal is to send an array of values, i.e. an array of multiple sensor values from the multi sensor. Is the attribute StateText the reason you thought of this cluster, as the data type is an array? This attribute is not for sending different measurements as they are measured, as the multi sensor example does with the temperature and pressure measurement, and you should not use it in this way. This attribute is used to hold the descriptions of the possible states of a multistate value. So if you for example have a temperature measurement that can be in multiple different states (different temperatures), then this attribute will hold all the possible values it can be.

    One possible solution would be to splitting the array of values into multiple packets and send them, and then handle it on the application side. Another could be creating a custom cluster with one attribute for each of the values you want to send.

    In the multi sensor example, the CLI agent subscribes to the attribute reporting of the multi sensor. You can see that this is handled in components/zigbee/cli/zigbee_cli_cmd_attr_report.c. The macro ZB_ZCL_GENERAL_GET_NEXT_REPORT_ATTR_REQ is used to parse report attribute command and returns the next attribute report, so this is what you have to use to get the payload of the report attribute command. In the case of CLI, the function cli_agent_ep_handler_report() handles the incoming reports. However, you can find more information about parsing report attribute commands here.

    How to modify the examples so both can send and receive data depend on what type of data and how it is sent. However, for attributes you can take a look at some of the subcategories of ZCL commands shared by all clusters. In the case of the multi sensor example if you test it as explained in the examples documentation, then the data sent is the MeasuredValue attribute, both from the Temperature cluster and Pressure cluster. This is sent using attribute reporting, where the attribute reporting device automatically report the values of the attributes after the CLI agent sent a configure reporting command. Attributes can also be read using the read attribute command, where the device (here CLI agent) send a read attributes request to the device with attribute reporting (multi sensor), and it sends the attribute as a response. To know whether an attribute supports attribute reporting or attribute read, you can check the attribute in the Zigbee Cluster Library specification. You can find more information about attribute reporting and read attribute command in the link I shared above.

    Best regards,

    Marte

Related