Read Zigbee attribute directly into a state (zha-toolkit)

[le_top]

I just updated zha_custom - now zha-toolkit - to request a Zigbee Attribut read and get it directly into a Home Assistant state or state attribute without too much hassle:

"zha-toolkit" - a big set of Zigbee commands on top of ZHA/zigpy

Ok, this is something that will be useful to those that want to avoiding reading zigbee attributes from the database. The zigbee attributes you read or write (and read back) can now be written directly to home assistant states or state attributes For instance, I want to read apparent power from my electrical meter and it’s not available through the standard functionnallity, I can now call this service repeatedly: service: zha_custom.execute data: command: attr_read ieee: sensor.my_smarten…

Gone the days of writing stuff like:

- platform: sql
  db_url: sqlite:////config/zigbee.db
  scan_interval: 10
  queries:
    - name: current_demand
      query: "SELECT value FROM attributes_cache_v7 where ieee = '00:12:b1:30:01:01:1e' and cluster = 2820 and attrid = 1295"
      column: "value"

Write:

service: zha_toolkit.execute
data:
  command: attr_read
  ieee: sensor.my_smartenergy_metering
  cluster: 0xb04
  attribute: 0x50f
  state_id: sensor.current_demand
  allow_create: True

instead!

No more worries about database table changes from attributes_cache_v7 to attributes_cache_v8 to attributes_cache_v9 … .

[mbnielsen]

Hi @le_top,

This is a great feature, thank you for this.

However, if I’m concerned about power consumption (using battery powered Zigbee devices), should I rather stick with the SQL method? I’m assuming that when executing attr_read, zha_toolkit sends a request to the device which will have to use power responding with the attribute?
Whereas the SQL method just reads from a database to which the desired attribute has already been pushed along with other attributes on a regular schedule (as far as I understand), thus not requiring any additional communication with the device?

I’m rather new to HA and ZHA, so please let me know if I’m totally off-field

[le_top]

I recently estimated the impact on increasing the number of requests to a zigbee device.
According to that computation it turned out that 1500 data requests per day represent only about 1% of the power consumption. There is a higher impact from the delay between the device wakeup times.

Basically when you make a request to the device, the request can only be made when the device is awake and checks if there is any pending request using a data request message (some documentation.
All then happens very quickly after that and the device will go to sleep again. The extra consumption from extra requests is fairly low according to the computations I used.

1500 requests is about 1 request every minute.

There is another method which is to set a reporting configuration for the attributes that you need, and - if not already supported natively in HA - add a listener for the ZHA events and get the data from the report packets. But that is harder to implement.

[AlfonsoGarcia (Alfonso)]

Good solution, but I have the problem that the value is multiplied by 10 or that the decimal point is missing, can it be solved in any way?

[le_top]

I am thinking about adding a scale_zb2ha or multiplier parameter to zha_toolkit.attr_read/write but that’s not done yet.

In the mean time you can create a template sensor for instance.

[claudegel (Claude Gelinas)]

For sleepy devices this won’t work ?

[le_top]

This works the same for sleepy devices when the attribute is considered “read”. If there is no reply, you will not get a value. There is the possibility to use the cache.

So there are two ways to read an attribute:

1. Through actual reads - with sleepy devices you need to set “tries” high enough so that the read requests are repeated until they succeed;
2. Use the “read from cache” feature (use_cache option), and ensure that the sleepy devices report changes by themselves. The first example in the documentation sets ‘use_cache’ to true.

[claudegel (Claude Gelinas)]

Thanks I’ll try that way

[micvadeg (Michiel van der Geest)]

Great tool and clear explanation but…are stumbling into a message “Failed to call service zha_toolkit.attr_read. Service response data expected a dictionary, was <class ‘NoneType’>”. Perhaps somebody has experienced the same.

The case appears to be straightforward; floor heating thermostat with two temperature sensors. The standard ZHA integration only provide one of the two and I like to use the second. Using the “Manage zigbeee device” menu in the standard ZHA integration, I can read the value. Ref two screendumps below.

Any good ideas to help me out?

[le_top]

Hi

• The home-assistant.log file will have more information about this - in particular the stack trace.
• I suspect that you should not provide the manf value - when you provide it the request is made in the manufacturer attribute space while the attribute you are showing is in the standard name space.

[micvadeg (Michiel van der Geest)]

Thanks for the quick reply. I start to wonder if I´ve made an error in configuration of the customer component (basically I just copied-pasted the custom component directory to my hass configuration folder structure) - and therefore it fails to call the service.
Let me dive into the github install instructions to check further.

[le_top]

You can copy zha-toolkit to the custom_component directory, but to enable it you currently need to add “zha_toolkit:” to your configuration.yaml and restart.

As the services show up in your UI, I think you did that.

Just remove “manf: 4512” from your service call.

[micvadeg (Michiel van der Geest)]

Thanks for the confirmation.
Removed the "manf: " line but still no result.
Could it be I should include the attr_type value??

[le_top]

• Is the result the same as before?

• What information can you find in the home-assistant.log?

• You can increase debugging dynamically by calling a service - you can start with:

  service: logger.set_level
  data:
      custom_components.zha_toolkit: debug
      zigpy.zcl: debug
  

  This will log more detailed messages from the toolkit and from zigpy.

  The zigpy debug is quite verbose, so you can redo this command with “warning” instead of debug.

[micvadeg (Michiel van der Geest)]

Thanks for your dedication to get this solved. Really appreciated.
Bit busy with normal life the coming 2 weeks so let me follow-up and check your suggestions a bit down the line.
Thanks again

[Vex (Marcin Bielecki)]

@le_top this toolkit is great
Could you give me a hint on what to do to make the data automatically updated?

[le_top]

@Vex

@le_top this toolkit is great

I could not do without it…

@Vex

Could you give me a hint on what to do to make the data automatically updated?

1. Most of the time you can configure the devices to report on values according to your wishes. For instance, I override the default reporting period set by ZHA on temperature sensors using this script: zha-toolkit/blueprints/script_Thermometer_setReporting.yaml at ec3c571d6fab25e172de5025692c656763c816ed · mdeweerd/zha-toolkit · GitHub .

2. A value that is reported is not automatically stored to a state. Some will be stored to a state because they are part of the values that are tracked through ZHA./zigpy settings, but most are not (especially if you want to track something “unusual”).
   One method is to read the value on a regular basis from zigbee cache and update a state from it. The following yaml configuration does not serve that purpose, but it does have the same effect:

mdeweerd/zha-toolkit/blob/ec3c571d6fab25e172de5025692c656763c816ed/blueprints/danfoss_ally_remote_temperature_min_delay.yaml#L73-L84

3. In some case, the entity will already have a state attribute value and you can make a normal state from it (with recorded history for instance) by using a the sensor template. Here ‘pi_heating_demand’ is already available as a state attribute:

File: sensors.yaml:

- platform: template
  sensors:
    home_office_heating_demand:
      friendly_name: Heating demand
      unit_of_measurement: percent
      value_template: "{{ state_attr('climate.radiateur_bureau_thermostat_5',\
        \ 'pi_heating_demand') }}"

In configuration.yaml:

sensor: !include sensors.yaml

4. I think that the quirks/zha_device_handlers now allow indicating which state attribute values should be set, but I am not sure about that.