Report Configuration of a Sleepy device with zha-toolkit

le_top · May 3, 2022, 10:00pm

On the device’s case, the tempeerature sensor indicates SNZB-02, but it’s reported as a TH01.

As far as I observed, the min/max intervals and the reportable change values are correctly used.
Setting a min_interface lower than 20s is in practice 20s as the values do not seem to be measured more often.

DomoAI · January 14, 2023, 9:21am

Hello,

I tried the below setting , with aqara lumi temp sensor.
service: zha_toolkit.execute
data:
ieee: sensor.principal_temperature
command: conf_report
endpoint: 1
cluster: 0x402
attribute: 0
min_interval: 5
max_interval: 300
reportable_change: 10
tries: 100
event_done: zha_done

Here the full log

2023-01-14 10:04:28.581 DEBUG (MainThread) [custom_components.zha_toolkit.default] Trying to import custom_components.zha_toolkit.zcl_attr to call conf_report

2023-01-14 10:04:28.586 DEBUG (MainThread) [custom_components.zha_toolkit.zcl_attr] Try 1/100: configure report(0,5,300,10,None)

2023-01-14 10:04:56.622 DEBUG (MainThread) [custom_components.zha_toolkit.zcl_attr] Try 2/100: configure report(0,5,300,10,None)

2023-01-14 10:05:24.676 DEBUG (MainThread) [custom_components.zha_toolkit.zcl_attr] Try 3/100: configure report(0,5,300,10,None)

2023-01-14 10:05:52.740 DEBUG (MainThread) [custom_components.zha_toolkit.zcl_attr] Try 4/100: configure report(0,5,300,10,None)

2023-01-14 10:06:20.774 DEBUG (MainThread) [custom_components.zha_toolkit.zcl_attr] Try 5/100: configure report(0,5,300,10,None)

2023-01-14 10:06:48.823 DEBUG (MainThread) [custom_components.zha_toolkit.zcl_attr] Try 6/100: configure report(0,5,300,10,None)

2023-01-14 10:07:16.861 DEBUG (MainThread) [custom_components.zha_toolkit.zcl_attr] Try 7/100: configure report(0,5,300,10,None)

2023-01-14 10:07:44.900 DEBUG (MainThread) [custom_components.zha_toolkit.zcl_attr] Try 8/100: configure report(0,5,300,10,None)

2023-01-14 10:08:12.943 DEBUG (MainThread) [custom_components.zha_toolkit.zcl_attr] Try 9/100: configure report(0,5,300,10,None)

2023-01-14 10:08:40.991 DEBUG (MainThread) [custom_components.zha_toolkit.zcl_attr] Try 10/100: configure report(0,5,300,10,None)

2023-01-14 10:09:09.032 DEBUG (MainThread) [custom_components.zha_toolkit.zcl_attr] Try 11/100: configure report(0,5,300,10,None)

2023-01-14 10:09:37.064 DEBUG (MainThread) [custom_components.zha_toolkit.zcl_attr] Try 12/100: configure report(0,5,300,10,None)

2023-01-14 10:10:05.109 DEBUG (MainThread) [custom_components.zha_toolkit.zcl_attr] Try 13/100: configure report(0,5,300,10,None)

2023-01-14 10:10:33.162 DEBUG (MainThread) [custom_components.zha_toolkit.zcl_attr] Try 14/100: configure report(0,5,300,10,None)

2023-01-14 10:11:01.221 DEBUG (MainThread) [custom_components.zha_toolkit.zcl_attr] Try 15/100: configure report(0,5,300,10,None)

2023-01-14 10:11:08.442 INFO (MainThread) [custom_components.zha_toolkit.zcl_attr] Configure report result: Default_Response(command_id=6, status=<Status.UNSUP_GENERAL_COMMAND: 130>)

2023-01-14 10:11:08.443 DEBUG (MainThread) [custom_components.zha_toolkit.zcl_attr] Configure report exception ‘uint8_t’ object is not subscriptable,0,5,300,10,None

2023-01-14 10:11:08.443 DEBUG (MainThread) [custom_components.zha_toolkit] event_data {‘zha_toolkit_version’: ‘v0.8.28’, ‘zigpy_version’: ‘0.53.0’, ‘zigpy_rf_version’: ‘0.19.2’, ‘ieee_org’: ‘sensor.lumi_lumi_weather_temperature_2’, ‘ieee’: ‘00:15:8d:00:08:30:11:d6’, ‘command’: ‘conf_report’, ‘command_data’: None, ‘start_time’: ‘2023-01-14T09:04:28.570920+00:00’, ‘errors’: [], ‘params’: {‘endpoint_id’: 1, ‘cluster_id’: 1026, ‘attr_id’: 0, ‘min_interval’: 5, ‘max_interval’: 300, ‘reportable_change’: 10, ‘dir’: 0, ‘tries’: 100, ‘expect_reply’: True, ‘args’: [], ‘event_done’: ‘zha_done’, ‘read_before_write’: True, ‘read_after_write’: True}, ‘success’: False, ‘result_conf’: Default_Response(command_id=6, status=<Status.UNSUP_GENERAL_COMMAND: 130>)}

What could be the reason? Any help will be very appreciated.

le_top · January 14, 2023, 11:48am

It looks like on try 15, the Aqara sensor replied with the indication that it does not support this command.
Which means that it does not support modifying the report configuration of that attribute - unless the command that was sent is wrong (but this has been used quite often already).

The zha-toolkit code tries to analyze the response not expecting this type of reply so that explains the “uint8_t” message.

You could try a scan_device which I just updated to use the “tries” parameter. But if you have a lumi.weather/LUMI it’s not going to provide further information. And from experience I know it doesn’t allow a lot of configuration.

DomoAI · January 14, 2023, 4:06pm

Hi le top,

thanks a lot for the quick answer. So looks like the aqara lumi is not able to receive any new settings.
Thats is a a shame because I just switch from zwave fibaro multi sensor to those temp sensor to use as thermostat. Problem is the refresh rate sometime isn’t like it should be.
I will tried the scan_device hopping for the best.
I pretty sure it must be a way to overwrite these settings…

Thanks again i will let know my update asap.

Playfulls2221 · November 8, 2023, 7:17pm

Any news on the aqara WSDCGQ11LM sensors? I’ve got a bunch of them and i’m really disappointed of the reporting interval.
Is there any possibility to change this? Or is it possible to change the needed amount of a temperature change?

le_top · November 9, 2023, 8:21pm

You can use this script and adapt the values to your needs.
It’s a configuration I use on my sensors.
In some rare cases it had to be adjusted because some sensors have a lot of “noise” on the temperature measurement, and to limit the number of packets I increased the minimum change.

github.com

mdeweerd/zha-toolkit/blob/e320f98ae4f643efef5679d0b3fb91c9ad8dd5c5/examples/script_Thermometer_setReporting.yaml

---
alias: Zigbee Thermometer Configure Reporting
fields:
  entity_name:
    name: entity_name
    description: A Zigbee Entity (all entities of the device resolve to the same address)
    required: true
    selector:
      entity:
        integration: zha
sequence:
  - alias:
      Configure the temperature cluster of the device so that it reports every
      0.2°C every 19 seconds at most, or sends a report at least every 5 minutes
    service: zha_toolkit.conf_report
    data:
      ieee: "{{ entity_name }}"
      cluster: 1026
      attribute: 0
      tries: 100

This file has been truncated. show original

aunt-lydia · February 22, 2024, 10:34pm

Hi there, I found this topic while searching for an option to increase the reporting rate of some Tuya illuminance sensors. One is a motion sensor with integrated illuminance, another is a door (hall) sensor with integrated illuminance sensor as well. I tried to use the service call as described above and found the corresponding values for my devices. Both seem to have the same cluster and attribute IDs for addressing the lux sensors. Both devices seem to behave in a similar way: When motion is detected or the door is opened, the illuminance value gets updated too. When there is no motion, the illuminance is updated every hour, and only if there is a change in brightness. This is great for battery saving, but not so practical for daily use of automations when brightness of the environment changes quickly. Hence my attempt to alter the duration to something up to max 15 min or so.

Whenever I call the service to change the report configuration, I get a false success. Am I doing it wrong, or is the device rejecting changes to it?

Here some info:

my service call:

service: zha_toolkit.conf_report
data:
  ieee: sensor.ml_z00_illuminance
  endpoint: 1
  cluster: 1024
  attribute: 0
  min_interval: 30
  max_interval: 900
  reportable_change: 25
  tries: 100
  event_done: zha_done

the event outcome:

event_type: zha_done
data:
  zha_toolkit_version: v1.1.8
  zigpy_version: 0.62.3
  zigpy_rf_version: 0.38.0
  ieee_org: sensor.ml_z00_illuminance
  ieee: a4:c1:38:63:83:24:7e:9e
  command: conf_report
  command_data: null
  start_time: "2024-02-22T21:52:52.414953+00:00"
  errors: []
  params:
    endpoint_id: 1
    cluster_id: 1024
    attr_id: 0
    min_interval: 30
    max_interval: 900
    reportable_change: 25
    dir: 0
    tries: 100
    expect_reply: true
    args: []
    event_done: zha_done
    read_before_write: true
    read_after_write: true
  success: false
  result_conf:
    - - status: 134
        direction: 0
        attrid: 0
origin: LOCAL
time_fired: "2024-02-22T21:53:06.458683+00:00"
context:
  id: 01HQ9CXMWTDCSYV7H16FX6NJFM
  parent_id: null
  user_id: null

and config report read outcome:

event_type: zha_done
data:
  zha_toolkit_version: v1.1.8
  zigpy_version: 0.62.3
  zigpy_rf_version: 0.38.0
  ieee_org: sensor.ml_z00_illuminance
  ieee: a4:c1:38:63:83:24:7e:9e
  command: conf_report_read
  command_data: null
  start_time: "2024-02-22T21:47:32.179813+00:00"
  errors: []
  params:
    endpoint_id: 1
    cluster_id: 1024
    attr_id: 0
    dir: 0
    tries: 10
    expect_reply: true
    args: []
    event_done: zha_done
    read_before_write: true
    read_after_write: true
  success: true
  result_conf:
    - cluster: Illuminance Measurement
      cluster_id: "0x0400"
      ep: 1
      attr_id: "0x0000"
      direction: 0
      status: 140
      attr: measured_value
origin: LOCAL
time_fired: "2024-02-22T21:47:39.825183+00:00"
context:
  id: 01HQ9CKNXHZ5XMK3GSE6K3S38S
  parent_id: null
  user_id: null

any idea how to change it, if possible?
Thanks!

le_top · February 23, 2024, 12:54pm

Error 134 means “unsupported attribute”.

“scan_device” on a sleepy device can take a while, but I suggest you try it to verify that your attribute is on endpoint 1 and is reportable, and verify it’s type;

It could be that the type is incorrect when seding the configuration (I believe this determines the size fo the reportable change) - possible that is incorrect in zigpy (zha-toolkit does not override it).

You can also use “conf_report_read” to verify the current configuration - I guess that it exists.

It could also be an aqara limitation: I have a temperature sensor and not all zigbee commands work as I expect.

aunt-lydia · February 26, 2024, 10:57pm

Hi, thanks for the reply!

Sorry, I should have made it more clear in my post: I already did the “conf_report_read” and had presented the result; here again:

event_type: zha_done
data:
  zha_toolkit_version: v1.1.8
  zigpy_version: 0.62.3
  zigpy_rf_version: 0.38.0
  ieee_org: sensor.ml_z00_illuminance
  ieee: a4:c1:38:63:83:24:7e:9e
  command: conf_report_read
  command_data: null
  start_time: "2024-02-22T21:47:32.179813+00:00"
  errors: []
  params:
    endpoint_id: 1
    cluster_id: 1024
    attr_id: 0
    dir: 0
    tries: 10
    expect_reply: true
    args: []
    event_done: zha_done
    read_before_write: true
    read_after_write: true
  success: true
  result_conf:
    - cluster: Illuminance Measurement
      cluster_id: "0x0400"
      ep: 1
      attr_id: "0x0000"
      direction: 0
      status: 140
      attr: measured_value
origin: LOCAL
time_fired: "2024-02-22T21:47:39.825183+00:00"
context:
  id: 01HQ9CKNXHZ5XMK3GSE6K3S38S
  parent_id: null
  user_id: null

As far as I understand it, the endpoint 1 and cluster 1024 (hex 0x0400) and attribute 0 is addressed correctly at the Illuminance Measurement cluster, and the conf_report_read succeeds, however the attempted change in report configuration (zha_toolkit.conf_report ) remains unsuccessful, regardless of the reportable change value (I tried different values between 0 and 100)… so I assume there is a fair chance that the change in report configuration is blocked by the manufacturers.

If anyone sees anything that I have missed or has an idea for a workaround, I’d be grateful! Thanks