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

Zigbee Reporting Attribute size bug?

I have an application where I have configured a reporting attribute which reports on update. It works as expected - until the amount of data you want to send exceeds 8 bytes. 

The is ZB_ZCL_ATTR_TYPE_CHAR_STRING. In this type the first byte is a length character, and a \0 (zero termination) has to be included. That leaves a payload of 6 chars. In my case I need to send a variable sized sting between 11 and 25 char long. 

Due to the limitation I have run into, it has to be sent in chunks of 6 chars, but what is the reason for this limitation? I can't find anything about it in the ZBOSS doc or ZB spec. 

Is it a bug?

How can I fix this?

Parents
  • I am no zigbee expert, but I will try to see if there are any coding hiccups here.

    I do not see any limitations of 8 bytes on that buffer either. What is the error you are getting. These buffers seems to be allocated in the application. Can you check to see in your application which buffer it think is not enough? Probably start your application in debugger and put a breakpoint where it shows fails with error when the size exceeds 8 and if you can show me the function call stack then probably it will give us more context on the nature of this error.

Reply
  • I am no zigbee expert, but I will try to see if there are any coding hiccups here.

    I do not see any limitations of 8 bytes on that buffer either. What is the error you are getting. These buffers seems to be allocated in the application. Can you check to see in your application which buffer it think is not enough? Probably start your application in debugger and put a breakpoint where it shows fails with error when the size exceeds 8 and if you can show me the function call stack then probably it will give us more context on the nature of this error.

Children
  • There is actually an other post with the exact same problem:

    https://devzone.nordicsemi.com/f/nordic-q-a/59987/problems-with-zigbee-attribute-reporting-octet-string-size

    I do this call

    sts = ZB_ZCL_SET_ATTRIBUTE_EXT(HA_SENSOR_ENDPOINT,
    cluster_id, ZB_ZCL_CLUSTER_SERVER_ROLE,
    attr_id, (uint8_t*)p_val,
    ZB_FALSE);

    Where 

    #define ZB_ZCL_SET_ATTRIBUTE_EXT(ep, cluster_id, cluster_role, attr_id, value_ptr, check_access) \
    zb_zcl_set_attr_val(ep, cluster_id, cluster_role, attr_id, value_ptr, check_access)

    The call always returns 0 (ZB_ZCL_STATUS_SUCCESS) so there is no indication there of an error.

    As I said, the only difference is that I increase the size from 7 to 8 bytes in the ZB String, and i no not even change the payload. The paylaod is no a 7 char string with \0 inlcuded. 

    So the only change I do, is from 7 to 8 bytes. I have also tried to increase the string from 6 to 7 chars when changing from size from 7 to 8, so the payload specified by the length would only contain one \0, but it had no effect. 

    Basically

    char pl[] = {6, 'a', 'b', 'c', 'd', 'e', '\0'}; is ok

    char pl[] = {7, 'a', 'b', 'c', 'd', 'e', 'f', '\0'}; is ok

    char pl[] = {8, 'a', 'b', 'c', 'd', 'e', 'f', '\0', '\0'}; not ok

    char pl[] = {8, 'a', 'b', 'c', 'd', 'e', 'f', 'g', '\0'}; not ok

    Some context

    /*! @brief Sensor cluster attribute identifiers
    */
    enum zb_zcl_sensor_attr_e
    {
    /*! @brief Sensor Custom Name attribute */
    ZB_ZCL_ATTR_SENSOR_NAME_ID = 0x0000,
    /*! @brief Sensor Custom description attribute */
    ZB_ZCL_ATTR_SENSOR_DESC_ID = 0x0001,
    /*! @brief Sensor Data attribute */
    ZB_ZCL_ATTR_SENSOR_DATA_ID = 0x0003,
    /*! @brief Sensor Config attribute */
    ZB_ZCL_ATTR_SENSOR_CONFIG_ID = 0x0004,
    };

    #define ZB_SET_ATTR_DESCR_WITH_ZB_ZCL_ATTR_SENSOR_NAME_ID(data_ptr) \
    { \
    ZB_ZCL_ATTR_SENSOR_NAME_ID, \
    ZB_ZCL_ATTR_TYPE_CHAR_STRING, \
    ZB_ZCL_ATTR_ACCESS_READ_ONLY, \
    (zb_voidp_t) data_ptr \
    }

    #define ZB_SET_ATTR_DESCR_WITH_ZB_ZCL_ATTR_SENSOR_DESC_ID(data_ptr) \
    { \
    ZB_ZCL_ATTR_SENSOR_DESC_ID, \
    ZB_ZCL_ATTR_TYPE_CHAR_STRING, \
    ZB_ZCL_ATTR_ACCESS_READ_ONLY, \
    (zb_voidp_t) data_ptr \
    }

    #define ZB_SET_ATTR_DESCR_WITH_ZB_ZCL_ATTR_SENSOR_DATA_ID(data_ptr) \
    { \
    ZB_ZCL_ATTR_SENSOR_DATA_ID, \
    ZB_ZCL_ATTR_TYPE_CHAR_STRING, \
    ZB_ZCL_ATTR_ACCESS_READ_ONLY | ZB_ZCL_ATTR_ACCESS_REPORTING, \
    (zb_voidp_t) data_ptr \
    }
    // ZB_ZCL_ATTR_TYPE_CHAR_STRING, ZB_ZCL_ATTR_TYPE_OCTET_STRING \
    //ZB_ZCL_ATTR_TYPE_ARRAY, ZB_ZCL_ATTR_TYPE_U16 \

    #define ZB_SET_ATTR_DESCR_WITH_ZB_ZCL_ATTR_SENSOR_CONFIG_ID(data_ptr) \
    { \
    ZB_ZCL_ATTR_SENSOR_CONFIG_ID, \
    ZB_ZCL_ATTR_TYPE_ARRAY, \
    ZB_ZCL_ATTR_ACCESS_READ_ONLY, \
    (zb_voidp_t) data_ptr \
    }

    #define ZB_ZCL_DECLARE_SENSOR_ATTRIB_LIST_EXT( \
    attr_list, name, desc, data, config \
    ) \
    ZB_ZCL_START_DECLARE_ATTRIB_LIST(attr_list) \
    ZB_ZCL_SET_ATTR_DESC(ZB_ZCL_ATTR_SENSOR_NAME_ID, (name)) \
    ZB_ZCL_SET_ATTR_DESC(ZB_ZCL_ATTR_SENSOR_DESC_ID, (desc)) \
    ZB_ZCL_SET_ATTR_DESC(ZB_ZCL_ATTR_SENSOR_DATA_ID, (data)) \
    ZB_ZCL_SET_ATTR_DESC(ZB_ZCL_ATTR_SENSOR_CONFIG_ID, (config)) \
    ZB_ZCL_FINISH_DECLARE_ATTRIB_LIST

  • One thing I forgot to mention, if i do an attribute read, then I get the correct value. It is just when it is reporting on update that it does not work. 

    zcl attr read f4ce36549f80187e 8 0xFC00 0x0104 0x0003

    works just fine for all of the examples above.

  • This smells like a bug to me. I need to confirm this with Marjeris but she is on vacation so unfortunately we need to wait. Sorry for the inconvinience.

  • Hi Glen I am sorry for the lack of progress here, I am picking up on this ticket.

    Do you think you can provide some sniffer logs when the reporting takes place if you had from when you tested?

    It sounds like a bug so I have made a potential internal bug report so our stack developers can take a closer look.

  • Any updates on this one?

    It is straight forward to test, so there is not need for sniffer logs. Anyone can reproduce this.

    Is it possible to get an intermediate update with a fix?

Related