Reporting integer and octet string attributes on value change

RE: Reporting integer and octet string attributes on value change

Marte Myrvold — Fri, 21 May 2021 10:33:50 GMT

Hi,

I am not certain about this, as there are no attributes in the Zigbee cluster library specification that are of the type octet string that are reportable. All the clusters that are octet strings are only readable and/or writable, so following this specification, there should be no need to support octet strings when it comes to attribute reporting. However, as far as I know, there are no character string reportable attributes either, so I cannot think of any reason why octet string should cause problems, but not character string.

One suggestion is to look at how read attribute value is done in CLI, and compare that to attribute reporting, as the read attribute should at least have support for octet strings, as all attributes of that type in the ZCL spec are readable. You can find the CLI library for attribute reporting in the file components/zigbee/cli/zigbee_cli_cmd_attr_report.c, and for attribute read/write in components/zigbee/cli/zigbee_cli_cmd_attr.c. The relevant functions would be cli_agent_ep_handler_report() and cli_agent_ep_handler_attr(), which are handlers to intercept the frames for attribute reporting and read attribute respectively, and the print functions for the two, print_attr_update() and print_read_attr_response(), which are called in the handlers. Please be aware that the print function for zcl attr read command will print out the received response, while the print function for attribute reporting it will add the attribute value to the log, and it will only be printed if you enable displaying of reports.

Best regards,

Marte

RE: Reporting integer and octet string attributes on value change

vilpih — Thu, 20 May 2021 09:16:48 GMT

Is there anywhere I need to add support for reporting octet strings in CLI example?

Reporting works fine when I change from ZB_ZCL_ATTR_TYPE_OCTET_STRING to ZB_ZCL_ATTR_TYPE_CHAR_STRING

I previously added support for printing reading of octet strings in the example..

RE: Reporting integer and octet string attributes on value change

Marte Myrvold — Wed, 19 May 2021 11:30:22 GMT

Hi,

Good to hear that you are able to report on status change!

I am afraid there is no way to increase this as far as I know. Most of the actions related to the attribute reporting configuration are implemented as internal parts of the ZBOSS stack, and thus not visible to or configurable by the application.

Best regards,

Marte

RE: Reporting integer and octet string attributes on value change

vilpih — Wed, 19 May 2021 07:26:28 GMT

Thanks, I have modified the CLI example and reporting on status change works fine.
It's a little bit weird that there is an error message, but the reporting seems to work anyway and attrib read works without any issues.

By the way, is there a way to increase the number of "message buffers" for reporting. Quite often the events are over written before they are sent.

RE: Reporting integer and octet string attributes on value change

Marte Myrvold — Wed, 12 May 2021 14:25:25 GMT

Hi,

In order to configure attribute reporting for status change you need to modify the CLI example. One of my colleagues did this in the comment here in another case. There they tested it using the multi sensor example and configured it to report after a button press, but you should be able to use this and change it to report on value change. Could you take a look at how he implemented this and see if you are able to use this in your project?

Additionally, there seem to be something wrong with the implementation of your attribute, or the command you are using to subscribe to that attribute, since you are getting an error. Status 134 is ZB_ZCL_STATUS_UNSUP_ATTRIB, which is unsupported attribute. I cannot see anything wrong in the code where you define the attributes. Did you look at the multi sensor example and the pressure measurement cluster when creating your custom cluster? If not, I recommend checking it out, as the pressure measurement is implemented in the application, available as a reference when implementing a custom cluster.

Best regards,

Marte