[EDGE] Zigbee - unable to read multiple attributes from a cluster

As of 0.43 and 0.44 lua API there does not appear to be a way provided to create a Zigbee ReadAttribute message with multiple attributes from a cluster.

ReadAttribute accepts a table of attribute IDs:

But when using cluster_base_index.read_attribute() to create a ZigbeeMessageTx, it expects a single attribute which it then wraps in a table. No way to pass in a table of attributes.


< snipped >

To work around this, I created my own version of cluster_base.read_attribute() and removed the table wrap:


< snipped >

This workaround is functional, but it would be helpful to have multi attribute support added by one or more of the following suggestions:

  1. Add a new ‘read_attributes’ function to cluster_base_index to handle a table of attributes.
  2. Make cluster_base_index.read_attribute detect a single or table of attribute id’s. Wrap singles for backwards compability.
  3. Extend generated cluster definitions to include a “generate read attributes” method, something like:
    device:send(zcl_clusters.PowerConfiguration:read(device, {list of attributes}))
  4. Even nicer would be to add multiple attributes into a per cluster ReadAttribute when performing ZigbeeDevice:refresh().

Supporting multiple attribute reads into a single message definitely helps with bandwidth and battery usage. zigbee_test_utils.build_attribute_read() is a test harness to create them, there just doesn’t appear to be a way to create them for normal use.

2 Likes

I’ve also reported other issues with parsing multiple attributes received from the device

@nayelyz

1 Like

Hi, @csstup
I already shared your comment with the engineering team.

As Ramit mentioned, he already presented this special case which is now a feature request and has been moved to the backlog for the team to analyze later on.
In his case, he used a combination of the default and custom handlers to get those attributes processed but:

When the message is processed, the most specific handler is selected. The custom one or a subdriver is first in the order of preference. Once that handler is found, the attributes are processed within.
If that handler only processes only two attributes, the search for a handler for the remaining attributes doesn’t continue.
This means, the custom handler won all the time and it processed only one attribute.

Thanks for the update.

Also note with the team that I have at least one device that will return multiple encoded attributes in a single ReadResponse, even when not queried as multiples. For instance, if you setup read reporting on multiple attributes in a cluster (for example, battery voltage and percentage remaining) to be sent every 5 minutes, it will coalesce any updates that are within some time interval (say, due in the next 10 seconds) into a single ReadResponse. Im guessing to optimize battery life and radio time. My point is even if we’re not requesting mutliple attributes in a single Read, the devices can always return them as such. Edge should be able to process them even if the handlers are at different subdriver levels.