It is noteworthy to watchers of this thread that zha_toolkit/ota_notify now includes an option to request downloading the firmware listed in koenkk/zigbee-OTA used in Z2M. this extends beyond the FW currently downloaded by zha (when configured to do so).
2 Likes
Thank you for UI mode, but I miss here choice to input or see data in hex format.
In HA Manage Zigbee Device all data is in hex format.
It’s soo annoying to convert cluster/attribute numbers from hex to number.
I agree, but for defining the UI of the service call, I am bound to Selectors - Home Assistant .
This could have been a nice entry for the WTH month - maybe it is still open .
How do you remove this, i moved to Zigbee2mqtt and removed this integration, now i cant restart… I reinstalled the HACS integration but still nothing
The system cannot restart because the configuration is not valid: Integration error: zha_toolkit - Integration 'zha_toolkit' not found.
``You probably have zha_toolkit: in configuration.yaml which tries to load the component.
Remove/comment that.
I needed to set the time and timezone data (dststart, dstend, dstshift) for several of my objects.
Getting the DST data using templates is at least complex so I implemented ‘misc_settime’ to do that with just one service.
You may also be interested in an “off topic” service: ha_set_state which allows you to change any state in ha. I use it to detect same value attribute updates of temperatures.
1 Like
I need to add reporting on a manufacturer cluster attribute on a ZHA device. I’ve already configured the reporting on the attribute but I can’t find the way to activate reporting. Can anybody point me to where I should go to do that activation.
Documentation:
Example where one is written, without the manufacturer id. You just need to add the manufacturer id and change the other values to what you need:
Example where a manufacturer attribute’s reporting configuration is read back:
I’ve done this:
service: zha_toolkit.conf_report
data:
ieee: 50:0b:91:40:00:01:f1:e7
cluster: 65281
attribute: 84
min_interval: 1
max_interval: 300
reportable_change: 1
event_success: my_read_success_trigger_event
event_fail: my_read_fail_trigger_event
event_done: my_read_done_trigger_event
results:
[custom_components.zha_toolkit] Fire my_read_done_trigger_event → {‘zha_toolkit_version’: ‘v0.8.29’, ‘zigpy_version’: ‘0.53.0’, ‘zigpy_rf_version’: ‘0.19.2’, ‘ieee_org’: 50:0b:91:40:00:01:f1:e7, ‘ieee’: ‘50:0b:91:40:00:01:f1:e7’, ‘command’: ‘conf_report’, ‘command_data’: None, ‘start_time’: ‘2023-01-31T01:45:43.213733+00:00’, ‘errors’: [], ‘params’: {‘cluster_id’: 65281, ‘attr_id’: 84, ‘min_interval’: 1, ‘max_interval’: 300, ‘reportable_change’: 1, ‘dir’: 0, ‘tries’: 1, ‘expect_reply’: True, ‘args’: [], ‘event_success’: ‘my_read_success_trigger_event’, ‘event_fail’: ‘my_read_fail_trigger_event’, ‘event_done’: ‘my_read_done_trigger_event’, ‘read_before_write’: True, ‘read_after_write’: True}, ‘success’: True,
‘result_conf’: Configure_Reporting_rsp(status_records=[ConfigureReportingResponseRecord(status=<Status.SUCCESS: 0>)])}
Then I’ve done this:
service: zha_toolkit.conf_report_read
data:
ieee: 50:0b:91:40:00:01:f1:e7
cluster: 65281
attribute: 84
event_success: my_read_success_trigger_event
event_fail: my_read_fail_trigger_event
event_done: my_read_done_trigger_event
results:
2023-01-30 20:51:14.808 DEBUG (MainThread) [custom_components.zha_toolkit] Fire my_read_done_trigger_event → {‘zha_toolkit_version’: ‘v0.8.29’, ‘zigpy_version’: ‘0.53.0’, ‘zigpy_rf_version’: ‘0.19.2’, ‘ieee_org’: 50:0b:91:40:00:01:f1:e7, ‘ieee’: ‘50:0b:91:40:00:01:f1:e7’, ‘command’: ‘conf_report_read’, ‘command_data’: None, ‘start_time’: ‘2023-01-31T01:51:14.727627+00:00’, ‘errors’: [], ‘params’: {‘cluster_id’: 65281, ‘attr_id’: 84, ‘dir’: 0, ‘tries’: 1, ‘expect_reply’: True, ‘args’: [], ‘event_success’: ‘my_read_success_trigger_event’, ‘event_fail’: ‘my_read_fail_trigger_event’, ‘event_done’: ‘my_read_done_trigger_event’, ‘read_before_write’: True, ‘read_after_write’: True}, ‘success’: True,
‘result_conf’: [{‘cluster’: ‘Sinopé Technologies Manufacturer specific’, ‘cluster_id’: ‘0xFF01’, ‘ep’: 1, ‘attr_id’: ‘0x0054’, ‘direction’: <ReportingDirection.SendReports: 0>, ‘status’: <Status.SUCCESS: 0>, ‘type’: ‘0x30’, ‘min_interval’: (1,), ‘max_interval’: (300,), ‘attr’: ‘actionReport’}]}
Still no reporting. Do I need to bind the cluster 0xff01 (65281) to the gateway?
Also what is ‘direction’: <ReportingDirection.SendReports: 0>
Yes, I forgot about the binding - you need to bind the devices to the coordinator.
Also use zha-toolkit for that because the UI will not allow you to do it.
II did
service: zha_toolkit.bind_ieee
data:
ieee: 50:0b:91:40:00:01:f1:e7
command_data: 00:21:2e:ff:ff:05:cc:60
cluster: 65281
attribute: 84
event_done: zha_done
but the cluster 0xff01, attribute 0x0054 does not appear in ```
zha_toolkit.conf_report_read
would it be better to unlink the device from ZHA and add it again?If you want o check the configured bindings, you need to use zha_toolkit.binds_get .
Regarding the binding itself, only clusters are bound, not individjjual attributes.
zha_toolkit.bind_ieee does not use the “attribute” parameter. It does use the undocumented “cluster_id” parameter (not “cluster”) and when it is not find it only checks a list of internally “default” clusters.
So you need to write “cluster_id” not “cluster”. Sorry “cluster” is the correct parameter, “cluster_id” is used internally.
EDIT: You should also see the result of the binding by observing the event (‘zha_done’)
Here is the result for:
service: zha_toolkit.bind_ieee
data:
ieee: 50:0b:91:40:00:01:f1:e7
command_data: 00:21:2e:ff:ff:05:cc:60
cluster: 65281
event_done: zha_done
But with service: zha_toolkit.binds.get the cluster 65281 is not bound to the coordinator.
could it be because 65281 is a manufacturer cluster ?
The Bind_req command does not have a manufacturer parameter: zigpy/types.py at 297a2b0f364fe7a31de3b4966d70d1a67d432358 · zigpy/zigpy · GitHub .
That also matches the Zigbee specification.
The ‘result’ field is empty which suggests that no binding request was sent.
This seems to call for debugging. Hopefully the debug output provides enough information.
You can enable the debug level by calling this service:
service: logger.set_level
data:
custom_components.zha_toolkit: debug
zha_toolkit.scan_device can also help understand better what the structure is.
The question is why the code does not find the cluster in one of the ‘ep.out_clusters’ or ‘ep.in_clusters’. Their contents is not logged in bind_ieee, but scan_device loops over all thos values and reports "Scanning input cluster … " and “Scanning output cluster …” in the log when debugging enable which allows to verify it’s prensense there, and normally also in the JSON output ( /config/scans ).
config/scans for my switch give this information
"0xff01": {
"cluster_id": "0xff01",
"title": "Sinopé Technologies Manufacturer specific",
"name": "sinope_manufacturer_specific",
"attributes": {},
"commands_received": {
"0x01": {
"command_id": "0x01",
"command_name": "1",
"command_arguments": "not_in_zcl"
},
"0x0f": {
"command_id": "0x0f",
"command_name": "15",
"command_arguments": "not_in_zcl"
}
},
"commands_generated": {
"0x00": {
"command_id": "0x00",
"command_name": "0",
"command_args": "not_in_zcl"
},
"0x01": {
"command_id": "0x01",
"command_name": "1",
"command_args": "not_in_zcl"
}
}
}
},
in the log I have this for zha_toolkit.bind_ieee
[custom_components.zha_toolkit.binds] 0xe9e7: got the [] endpoints for 65281 cluster [custom_components.zha_toolkit.binds] 0xe9e7: skipping ff0104X cluster as non present
[custom_components.zha_toolkit.binds] 0xe9e7: got the [1] endpoints for 65281 cluster
I pre-release v0.8.31 - it should fix this (but I did not test).
The cluster was not bound because the coordinator does not have a matching cluster - something that we can expect on device-to-device bindings but is not needed on the coordinator.
I also updated the messages to indicate in/out cluster, and success is now set to false if nothing was bound.
Thank you @le_top I’ve tested and it work perfectly for single_click_on, single_click_off, double _click_on, double _click_off, long_press_on and long_press_off. I’ll be able to find out all manufacturer cluster attribute that have reporting to improve my quirck for sinopé device.
1 Like
Just updated to HA 2023.2.0 and zha_toolkit is no longer recognized as a valid service.
I just updated a system to 2023.2.1 to check this - I do not have an issue.
Check your logs to see if there is any message regarding zha_toolkit indicating some issue.
There can be several causes. For example: a user had two integrations managing the USB stick or once a zigpy/zha itself did not start (the user did a reboot and the system worked).