Closed eriknn closed 1 year ago
You did not fill out the issue template.
Please provide the device signature and diagnostic information for the affected device.
Is your feature request related to a problem? Please describe. Yes, seems to be a bug in the device
Describe the solution you'd like Use divisor = 1 instead of divisor = 100 which I believe is default
I thought I would try to make the quirk myself. The standard class for this attribute is here: https://github.com/zigpy/zigpy/blob/dev/zigpy/zcl/clusters/general.py#L389
If I understand quirks correctly, this is the class that would typically be modified with the quirk. However, the divisor is not here, it is here: https://github.com/home-assistant/core/blob/c3e27f68123511fe28a6898ef49b1a60aeabe64c/homeassistant/components/zha/sensor.py#L624
I'm asking on the wrong github channel? Or could it still be fixed with a quirk?
You're totally right. I thought there was a divisor attribute available on that cluster, but that's not the case.
This could probably still be fixed with a quirk by modifying the sent messages (modifying when saving the attribute -- perhaps overriding _update_attribute
for that cluster), but it's more complicated than just changing a constant divisor.
Yeah, I’ll try to figure it out. Might as well understand how this works and maybe I can be a resource for you guys later as well!
Okay, I got this working now!
One question though: Endpoint 1 contains a switch that does nothing, and a scenes cluster that I don’t see as necessary either. Is it considered okay to just remove this endpoint in the replacement signature?
A different problem, a bit more unrelated: One of the attributes has reporting set to 5/900/1 according to the reconfigure-log, yet it still updates every second. Zha Toolkit reveals that the actual config is 1/900/1. Configuring manually with Zha Toolkit fixes the issue. Any idea why this is happening? It was the case w/o quirk as well!
Is it considered okay to just remove this endpoint in the replacement signature?
If they really don't do anything and create and unnecessary entity in HA, it should be fine to remove them, yes. Also, can you post the device signature (and your current quirk)? (or feel free to already create a PR with your current quirk)
One of the attributes has reporting set to 5/900/1 according to the reconfigure-log. Zha Toolkit reveals that the actual config is 1/900/1. Configuring manually with Zha Toolkit fixes the issue.
Hmm, after you've configured it with ZHA Toolkit, does starting a normal "reconfigure" through the UI set it to 1/900/1 again? Can you maybe also post the debug logs from the reconfigure (and the ones from when you set it with ZHA Toolkit)?
Will test this later tonight. I noticed that this device reports these values in HA: (Cluster - Attribute) ElectricalMeasurement - Active Power Metering - Instantanious Demand
These two give the same value. Using the signature we can disable/remove an entire cluster. But can I remove a single attribute somehow?
Did a test now. A reconfigure does indeed set the value back to 1/900/1.
My debug log is very large, but I tried to extract the part when reconfiguring through UI. Seems like it should be okay....
2023-01-24 22:21:40.812 DEBUG (MainThread) [zigpy.zcl] [0x8B93:2:0x0702] Received ZCL frame: b'\x18\x85\x07\x00'
2023-01-24 22:21:40.812 DEBUG (MainThread) [zigpy.zcl] [0x8B93:2:0x0702] Decoded ZCL frame header: ZCLHeader(frame_control=FrameControl(frame_type=<FrameType.GLOBAL_COMMAND: 0>, is_manufacturer_specific=0, direction=<Direction.Client_to_Server: 1>, disable_default_response=1, reserved=0, *is_cluster=False, *is_general=True, *is_reply=True), tsn=133, command_id=7, *direction=<Direction.Client_to_Server: 1>, *is_reply=True)
2023-01-24 22:21:40.813 DEBUG (MainThread) [zigpy.zcl] [0x8B93:2:0x0702] Decoded ZCL frame: Metering:Configure_Reporting_rsp(status_records=[ConfigureReportingResponseRecord(status=<Status.SUCCESS: 0>)])
2023-01-24 22:21:40.813 DEBUG (MainThread) [zigpy_deconz.api] 'aps_data_indication' response from <DeconzAddress address_mode=AddressMode.NWK address=0x8b93>, ep: 2, profile: 0x0104, cluster_id: 0x0702, data: b'18850700'
2023-01-24 22:21:40.813 DEBUG (MainThread) [homeassistant.components.zha.core.channels.base] [0x8B93:2:0x0702]: Successfully configured reporting for '{'instantaneous_demand': (5, 900, 1), 'current_summ_delivered': (30, 900, 1), 'status': (1, 900, 1)}' on 'smartenergy_metering' cluster: [ConfigureReportingResponseRecord(status=<Status.SUCCESS: 0>)]
2023-01-24 22:21:40.814 DEBUG (MainThread) [homeassistant.components.zha.core.channels.base] [0x8B93:2:0x0702]: finished channel configuration
These two give the same value. Using the signature we can disable/remove an entire cluster. But can I remove a single attribute somehow?
Not easily and you normally shouldn't really or does HA creates two sensor entities?
HA creates two sensor identities with the same value, which seems a bit redundant. I can't find any good docs on how HA decides which entites to create - looks a bit like magic for me at the moment. Is there any developer docs on this, or do I have to browse code?
Ah, that's annoying then.
Check https://github.com/home-assistant/core/blob/dev/homeassistant/components/zha/sensor.py for which attributes are used to create sensors. There aren't any docs really :/
I wonder if we can just use CONSTANT_ATTRIBUTES to override the attribute from the Metering cluster then..
I think the debug log above was from the manual successful entry. Here's the log from reconfigure. Looks correct to me.
2023-01-28 00:19:54.903 DEBUG (MainThread) [homeassistant.components.zha.core.channels.base] [0x8B93:2:0x0702]: bound 'smartenergy_metering' cluster: Status.SUCCESS
2023-01-28 00:19:54.904 DEBUG (MainThread) [homeassistant.components.zha.core.channels.base] [0x8B93:2:0x0702]: Configuring cluster attribute reporting
2023-01-28 00:19:54.904 DEBUG (MainThread) [zigpy.zcl] [0x8B93:2:0x0702] Sending request header: ZCLHeader(frame_control=FrameControl(frame_type=<FrameType.GLOBAL_COMMAND: 0>, is_manufacturer_specific=False, direction=<Direction.Server_to_Client: 0>, disable_default_response=0, reserved=0, *is_cluster=False, *is_general=True, *is_reply=False), tsn=115, command_id=<GeneralCommand.Configure_Reporting: 6>, *direction=<Direction.Server_to_Client: 0>, *is_reply=False)
2023-01-28 00:19:54.904 DEBUG (MainThread) [zigpy.zcl] [0x8B93:2:0x0702] Sending request: Configure_Reporting(config_records=[AttributeReportingConfig(direction=0, attrid=0x0400, datatype=42, min_interval=5, max_interval=900, reportable_change=1), AttributeReportingConfig(direction=0, attrid=0x0000, datatype=37, min_interval=30, max_interval=900, reportable_change=1), AttributeReportingConfig(direction=0, attrid=0x0200, datatype=24, min_interval=1, max_interval=900, reportable_change=1)])
2023-01-28 00:19:54.905 DEBUG (MainThread) [zigpy_deconz.zigbee.application] Sending packet: ZigbeePacket(src=AddrModeAddress(addr_mode=<AddrMode.NWK: 2>, address=0x0000), src_ep=2, dst=AddrModeAddress(addr_mode=<AddrMode.NWK: 2>, address=0x8B93), dst_ep=2, source_route=None, extended_timeout=False, tsn=115, profile_id=260, cluster_id=1794, data=Serialized[b'\x00s\x06\x00\x00\x04*\x05\x00\x84\x03\x01\x00\x00\x00\x00\x00%\x1e\x00\x84\x03\x01\x00\x00\x00\x00\x00\x00\x00\x02\x18\x01\x00\x84\x03'], tx_options=<TransmitOptions.NONE: 0>, radius=0, non_member_radius=0, lqi=None, rssi=None)
2023-01-28 00:19:54.905 DEBUG (MainThread) [zigpy_deconz.api] Command Command.aps_data_request (51, 116, <DeconzSendDataFlags.NONE: 0>, <DeconzAddressEndpoint address_mode=AddressMode.NWK address=0x8b93 endpoint=2>, 260, 1794, 1, b'\x00s\x06\x00\x00\x04*\x05\x00\x84\x03\x01\x00\x00\x00\x00\x00%\x1e\x00\x84\x03\x01\x00\x00\x00\x00\x00\x00\x00\x02\x18\x01\x00\x84\x03', <DeconzTransmitOptions.USE_NWK_KEY_SECURITY: 2>, 0)
2023-01-28 00:19:54.919 DEBUG (MainThread) [zigpy_deconz.api] Received command aps_data_request[2, <DeviceState.APSDE_DATA_REQUEST_SLOTS_AVAILABLE|2: 34>, 116]
2023-01-28 00:19:54.920 DEBUG (MainThread) [zigpy_deconz.api] APS data request response: [2, <DeviceState.APSDE_DATA_REQUEST_SLOTS_AVAILABLE|2: 34>, 116]
2023-01-28 00:19:54.920 DEBUG (MainThread) [zigpy_deconz.api] Received command device_state_changed[<DeviceState.128|APSDE_DATA_REQUEST_SLOTS_AVAILABLE|APSDE_DATA_INDICATION|2: 170>, 0]
2023-01-28 00:19:54.920 DEBUG (MainThread) [zigpy_deconz.api] Device state changed response: [<DeviceState.128|APSDE_DATA_REQUEST_SLOTS_AVAILABLE|APSDE_DATA_INDICATION|2: 170>, 0]
2023-01-28 00:19:54.920 DEBUG (MainThread) [zigpy_deconz.api] Command Command.aps_data_indication (1, <DataIndicationFlags.Always_Use_NWK_Source_Addr: 1>)
2023-01-28 00:19:54.922 DEBUG (MainThread) [zigpy_deconz.api] Received command aps_data_indication[25, <DeviceState.APSDE_DATA_REQUEST_SLOTS_AVAILABLE|2: 34>, <DeconzAddress address_mode=AddressMode.NWK address=0x0000>, 0, <DeconzAddress address_mode=AddressMode.NWK address=0x8b93>, 0, 0, 32801, b'm\x00', 0, 175, 232, 36, 62, 85, 0, -78]
2023-01-28 00:19:54.922 DEBUG (MainThread) [zigpy_deconz.api] APS data indication response: [25, <DeviceState.APSDE_DATA_REQUEST_SLOTS_AVAILABLE|2: 34>, <DeconzAddress address_mode=AddressMode.NWK address=0x0000>, 0, <DeconzAddress address_mode=AddressMode.NWK address=0x8b93>, 0, 0, 32801, b'm\x00', 0, 175, 232, 36, 62, 85, 0, -78]
2023-01-28 00:19:54.922 DEBUG (MainThread) [zigpy.application] Received a packet: ZigbeePacket(src=AddrModeAddress(addr_mode=<AddrMode.NWK: 2>, address=0x8B93), src_ep=0, dst=AddrModeAddress(addr_mode=<AddrMode.NWK: 2>, address=0x0000), dst_ep=0, source_route=None, extended_timeout=False, tsn=None, profile_id=0, cluster_id=32801, data=Serialized[b'm\x00'], tx_options=<TransmitOptions.NONE: 0>, radius=0, non_member_radius=0, lqi=232, rssi=-78)
2023-01-28 00:19:54.923 DEBUG (MainThread) [zigpy_deconz.api] 'aps_data_indication' response from <DeconzAddress address_mode=AddressMode.NWK address=0x8b93>, ep: 0, profile: 0x0000, cluster_id: 0x8021, data: b'6d00'
2023-01-28 00:19:54.923 DEBUG (MainThread) [homeassistant.components.zha.core.channels.base] [0x8B93:2:0x0b04]: bound 'electrical_measurement' cluster: Status.SUCCESS
This is the same reconfiguration, but the device temperature cluster:
2023-01-28 00:19:55.012 DEBUG (MainThread) [homeassistant.components.zha.core.channels.base] [0x8B93:2:0x0002]: bound 'device_temperature' cluster: Status.SUCCESS
2023-01-28 00:19:55.013 DEBUG (MainThread) [homeassistant.components.zha.core.channels.base] [0x8B93:2:0x0002]: Configuring cluster attribute reporting
2023-01-28 00:19:55.013 DEBUG (MainThread) [zigpy.zcl] [0x8B93:2:0x0002] Sending request header: ZCLHeader(frame_control=FrameControl(frame_type=<FrameType.GLOBAL_COMMAND: 0>, is_manufacturer_specific=False, direction=<Direction.Server_to_Client: 0>, disable_default_response=0, reserved=0, *is_cluster=False, *is_general=True, *is_reply=False), tsn=125, command_id=<GeneralCommand.Configure_Reporting: 6>, *direction=<Direction.Server_to_Client: 0>, *is_reply=False)
2023-01-28 00:19:55.014 DEBUG (MainThread) [zigpy.zcl] [0x8B93:2:0x0002] Sending request: Configure_Reporting(config_records=[AttributeReportingConfig(direction=0, attrid=0x0000, datatype=41, min_interval=30, max_interval=900, reportable_change=50)])
2023-01-28 00:19:55.015 DEBUG (MainThread) [zigpy_deconz.zigbee.application] Sending packet: ZigbeePacket(src=AddrModeAddress(addr_mode=<AddrMode.NWK: 2>, address=0x0000), src_ep=2, dst=AddrModeAddress(addr_mode=<AddrMode.NWK: 2>, address=0x8B93), dst_ep=2, source_route=None, extended_timeout=False, tsn=125, profile_id=260, cluster_id=2, data=Serialized[b'\x00}\x06\x00\x00\x00)\x1e\x00\x84\x032\x00'], tx_options=<TransmitOptions.NONE: 0>, radius=0, non_member_radius=0, lqi=None, rssi=None)
2023-01-28 00:19:55.015 DEBUG (MainThread) [zigpy_deconz.api] Command Command.aps_data_confirm (0,)
It seems that this gets a "Command Command.aps_data_confirm (0,)" reply. Note that this only has one attribute. The "electrical_measurement" cluster also contains several attributes, and does not get an ack.
So could it be that configuration fails when trying to configure several attributes in one packet?
HA creates two sensor identities with the same value, which seems a bit redundant. I can't find any good docs on how HA decides which entites to create - looks a bit like magic for me at the moment. Is there any developer docs on this, or do I have to browse code?
Thank you for the temperature quirk!
For the power sensors it does seem to report differently:
The instantaneous sensor seems te be reporting much more often? I don't know if that makes sense, I'm pretty new to this Zigbee stuff.
Yeah, read my posts above. This seems to be due to an issue when the entity is configured. HA attempts to configure update frequency on all sensors belonging to the same cluster with one config-telegram. The device doesn’t handle this well, and ends up with minimum 1 sec interval (should be 5). I had to fix this manually by setting each individually.
Ah yes I see. I guess I'll be installing ZHA Toolkit then 😅 I can probably figure it out. Thanks!
Haha guess not 😅 I have ZHA Toolkit running and I think I need to call service ZHA Toolkit: conf_report, select ieee Entity "mydevice Instantaneous demand". Then fill min/max/reportable with 5/900/1. But it seems like I need to fill in more stuff before it will let me call the service. That's where I'm lost.
Could you please fill me in on this? There is a lot to read about all this but it is a bit overwhelming.
So this is where I'm at now:
service: zha_toolkit.conf_report
data:
ieee: sensor.frient_a_s_splzb_131_instantaneous_demand
min_interval: 5
max_interval: 900
reportable_change: 1
Try these:
service: zha_toolkit.conf_report
data:
ieee: sensor.device_ac_frequency
cluster: 0xb04
attribute: 0x300
min_interval: 5
reportable_change: 50
max_interval: 900
service: zha_toolkit.conf_report
data:
ieee: sensor.device_rms_voltage
cluster: 0xb04
attribute: 0x505
min_interval: 5
reportable_change: 50
max_interval: 900
service: zha_toolkit.conf_report
data:
ieee: sensor.device_rms_current
cluster: 0xb04
attribute: 0x508
min_interval: 5
reportable_change: 50
max_interval: 900
service: zha_toolkit.conf_report
data:
ieee: sensor.device_active_power
cluster: 0xb04
attribute: 0x50b
min_interval: 5
reportable_change: 5
max_interval: 900
service: zha_toolkit.conf_report
data:
ieee: sensor.device_instantaneous_demand
cluster: 0x702
attribute: 0x400
min_interval: 5
reportable_change: 5
max_interval: 900
service: zha_toolkit.conf_report
data:
ieee: sensor.device_summation_delivered
cluster: 0x0702
attribute: 0x0000
min_interval: 5
reportable_change: 10
max_interval: 900
Ah yes I was looking for the cluster/attribute in the "Manage Zigbee Device" option of the device. I found the 0x702 and 0x400 and put it in the conf_report_read service. Found the output in the HA log and it was 1/900/1 as expected.
I did the conf_report service call for the instantaneous_demand and another read and the log now shows:
Last logged: 19:21:20
Read reporting with [ReadReportingConfigRecord(direction=0, attrid=1024)] {'manufacturer': None}
Read reporting with [ReadReportingConfigRecord(direction=0, attrid=1024)] result Read_Reporting_Configuration_rsp(attribute_configs=[AttributeReportingConfigWithStatus(status=<Status.SUCCESS: 0>, config=AttributeReportingConfig(direction=<ReportingDirection.SendReports: 0>, attrid=0x0400, datatype=42, min_interval=1, max_interval=900, reportable_change=1))])
Read reporting with [ReadReportingConfigRecord(direction=0, attrid=1024)] result Read_Reporting_Configuration_rsp(attribute_configs=[AttributeReportingConfigWithStatus(status=<Status.SUCCESS: 0>, config=AttributeReportingConfig(direction=<ReportingDirection.SendReports: 0>, attrid=0x0400, datatype=42, min_interval=5, max_interval=900, reportable_change=1))])
Not sure why at the second bullets it shows 1/900/1 and at the third bullet it shows 5/900/1. I'm still pretty new at this Zigbee stuff 😅
Alright, looks like you’ve got it under control then! Sure these aren’t read before and after you configured it correctly? I think multiple reads will cluster up like that…
i debugged the zigbee betwork to really clean this up, so take note of my values. Some are multiplied etc, that’s why I have some high reportable change-thresholds!
It could be clustered. I'll keep an eye on it. Thank you for your help and for the other values. Really appreciated!
Hi, it seems that device temperature is reported "as is" from the device, but then a divisor of 100 is applied, giving a wrong result. If I'm not mistaken the 100 divisor is default for device temperature, so this is probably a bug in the device. Is this something that could be solved with a quirk?