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

Developer Programs Writing Edge Drivers
1

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:

image
image1074×443 29.3 KB

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.

image
image1076×450 34.6 KB

< snipped >

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

image
image1076×428 29.7 KB

< 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
2

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

@nayelyz

1 Like
3

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.

4

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.