[BUG] Aqara relay. Only one channel works

Question

[BUG] Aqara relay. Only one channel works

3AXAPOB opened this issue 4 years ago · comments

Hi. I am using cc2531 and have some problems with two channel aqara relay (LUMI lumi.relay.c2acn01). I can switch from frontend only first relay. If I press second channel switch there is no result and got this at log:

2020-06-23 22:26:25 DEBUG (MainThread) [homeassistant.components.zha.entity] light.lumi_lumi_relay_c2acn01_5bd84b04_on_off_2: turned off:
2020-06-23 22:26:25 WARNING (MainThread) [zigpy_cc.api] Waiter timeout: <Waiter matcher=<Matcher type=CommandType.AREQ subsystem=Subsystem.AF command=dataConfirm payload={'endpoint': 2, 'transid': 102}> future= timeout=10000 sequence=None>
2020-06-23 22:26:27 DEBUG (MainThread) [homeassistant.components.zha.core.channels.base] [0xfaa2:2:0x0006]: command failed: on exception:
2020-06-23 22:26:27 DEBUG (MainThread) [homeassistant.components.zha.entity] light.lumi_lumi_relay_c2acn01_5bd84b04_on_off_2: turned on: {'on_off': TimeoutError()}

3AXAPOB commented 4 years ago

0x2b7c

Alexei Chetroi · Answer 1 · Sun Jun 28 2020 00:33:57 GMT+0800 (China Standard Time)

This seems to be cc2531 related, moving this to zigpy-cc

Alexei Chetroi · Answer 2 · Sun Jun 28 2020 00:50:53 GMT+0800 (China Standard Time)

can you enable debug for:

zigpy
zigpy_cc
components (see https://www.home-assistant.io/integrations/zha/#debug-logging) reproduce the issue and post the logs?

3AXAPOB · Answer 3 · Sun Jun 28 2020 01:34:25 GMT+0800 (China Standard Time)

Full log here: https://pastebin.com/Ecw6Qi4j

Alexei Chetroi · Answer 4 · Sun Jun 28 2020 01:42:31 GMT+0800 (China Standard Time)

what's the NWK address of the relay? I don't see requests to 0xfaa2 device in the new log

Alexei Chetroi · Answer 5 · Sun Jun 28 2020 01:44:16 GMT+0800 (China Standard Time)

did you rejoin it? shouldn't have changed the NWK unless it was reset and rejoined

3AXAPOB · Answer 6 · Sun Jun 28 2020 01:48:51 GMT+0800 (China Standard Time)

Yes i rejoin it.

Alexei Chetroi · Answer 7 · Sun Jun 28 2020 01:51:19 GMT+0800 (China Standard Time)

2020-06-27 19:59:06 DEBUG (MainThread) [zigpy.zcl] [0x2b7c:1:0x000c] Attribute report received: present_value=24.31667709350586
2020-06-27 19:59:07 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event call_service[L]: domain=light, service=turn_on, service_data=entity_id=light.lumi_lumi_relay_c2acn01_5bd84b04_on_off_2>
2020-06-27 19:59:07 DEBUG (MainThread) [zigpy_cc.zigbee.application] request (0x2b7c, 260, 6, 2, 2, 110, b'\x01n\x01', True, False)
2020-06-27 19:59:07 DEBUG (MainThread) [zigpy_cc.api] --> SREQ AF dataRequest tsn: 110 {'dstaddr': 11132, 'destendpoint': 2, 'srcendpoint': 2, 'clusterid': 6, 'transid': 111, 'options': 0, 'radius': 30, 'len': 3, 'data': b'\x01n\x01'}
2020-06-27 19:59:07 DEBUG (MainThread) [zigpy_cc.uart] Send: b'\xfe\r$\x01|+\x02\x02\x06\x00o\x00\x1e\x03\x01n\x01e'
2020-06-27 19:59:07 DEBUG (MainThread) [zigpy_cc.uart] Frame received: <UnpiFrame type=CommandType.SRSP subsystem=Subsystem.AF command_id=1 data=b'\x00' length=1 fcs=100>
2020-06-27 19:59:07 DEBUG (MainThread) [zigpy_cc.api] <-- SRSP AF dataRequest tsn: None {'status': 0}
2020-06-27 19:59:07 DEBUG (MainThread) [zigpy_cc.uart] Frame received: <UnpiFrame type=CommandType.AREQ subsystem=Subsystem.AF command_id=128 data=b'\x00\x02o' length=3 fcs=170>
2020-06-27 19:59:07 DEBUG (MainThread) [zigpy_cc.api] <-- AREQ AF dataConfirm tsn: None {'status': 0, 'endpoint': 2, 'transid': 111}
2020-06-27 19:59:07 DEBUG (MainThread) [zigpy_cc.zigbee.application] message ignored: dataConfirm
2020-06-27 19:59:08 DEBUG (MainThread) [zigpy_cc.uart] Frame received: <UnpiFrame type=CommandType.AREQ subsystem=Subsystem.AF command_id=129 data=b'\x00\x00\x0c\x00|+\x01\x01\x001\x00]V\xa8\x00\x00\n\x18\xcc\nU\x009\x9a3\x0eB\x14\xa0\x1c' length=30 fcs=231>
2020-06-27 19:59:08 DEBUG (MainThread) [zigpy_cc.api] <-- AREQ AF incomingMsg tsn: None {'groupid': 0, 'clusterid': 12, 'srcaddr': 0x2b7c, 'srcendpoint': 1, 'dstendpoint': 1, 'wasbroadcast': 0, 'linkquality': 49, 'securityuse': 0, 'timestamp': 11032157, 'transseqnumber': 0, 'len': 10, 'data': b'\x18\xcc\nU\x009\x9a3\x0eB'}
2020-06-27 19:59:08 INFO (MainThread) [zigpy_cc.zigbee.application] handle_message incomingMsg
2020-06-27 19:59:08 DEBUG (MainThread) [zigpy.zcl] [0x2b7c:1:0x000c] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=False disable_default_response=True> manufacturer=None tsn=204 command_id=Command.Report_Attributes>
2020-06-27 19:59:08 DEBUG (MainThread) [zigpy.zcl] [0x2b7c:1:0x000c] ZCL request 0x000a: [[<Attribute attrid=85 value=<TypeValue type=float, value=35.550392150878906>>]]
2020-06-27 19:59:08 DEBUG (MainThread) [zigpy.zcl] [0x2b7c:1:0x000c] Attribute report received: present_value=35.550392150878906
2020-06-27 19:59:08 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=sensor.lumi_lumi_relay_c2acn01_5bd84b04_analog_input, old_state=<state sensor.lumi_lumi_relay_c2acn01_5bd84b04_analog_input=24.3; friendly_name=LUMI lumi.relay.c2acn01 5bd84b04 analog_input @ 2020-06-27T19:59:06.447776+03:00>, new_state=<state sensor.lumi_lumi_relay_c2acn01_5bd84b04_analog_input=35.6; friendly_name=LUMI lumi.relay.c2acn01 5bd84b04 analog_input @ 2020-06-27T19:59:08.462474+03:00>>
2020-06-27 19:59:08 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=sensor.lumi_lumi_relay_c2acn01_5bd84b04_electrical_measurement, old_state=<state sensor.lumi_lumi_relay_c2acn01_5bd84b04_electrical_measurement=24; unit_of_measurement=W, friendly_name=LUMI lumi.relay.c2acn01 5bd84b04 electrical_measurement, device_class=power @ 2020-06-27T19:59:06.452295+03:00>, new_state=<state sensor.lumi_lumi_relay_c2acn01_5bd84b04_electrical_measurement=36; unit_of_measurement=W, friendly_name=LUMI lumi.relay.c2acn01 5bd84b04 electrical_measurement, device_class=power @ 2020-06-27T19:59:08.466777+03:00>>
2020-06-27 19:59:13 DEBUG (MainThread) [homeassistant.components.zha.core.channels.base] [0x2b7c:1:0x0b04]: async_update
2020-06-27 19:59:13 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=sensor.lumi_lumi_relay_c2acn01_5bd84b04_electrical_measurement, old_state=<state sensor.lumi_lumi_relay_c2acn01_5bd84b04_electrical_measurement=36; unit_of_measurement=W, friendly_name=LUMI lumi.relay.c2acn01 5bd84b04 electrical_measurement, device_class=power @ 2020-06-27T19:59:08.466777+03:00>, new_state=<state sensor.lumi_lumi_relay_c2acn01_5bd84b04_electrical_measurement=35; unit_of_measurement=W, friendly_name=LUMI lumi.relay.c2acn01 5bd84b04 electrical_measurement, device_class=power @ 2020-06-27T19:59:13.053321+03:00>>
2020-06-27 19:59:17 DEBUG (MainThread) [homeassistant.core] Service did not complete before timeout: <ServiceCall light.turn_on (c:233c581bafe74f57b00b481c23d215e9): entity_id=['light.lumi_lumi_relay_c2acn01_5bd84b04_on_off_2'], params=>
2020-06-27 19:59:17 DEBUG (MainThread) [homeassistant.components.zha.core.channels.base] [0x2b7c:2:0x0006]: command failed: on exception:
2020-06-27 19:59:17 DEBUG (MainThread) [homeassistant.components.zha.entity] light.lumi_lumi_relay_c2acn01_5bd84b04_on_off_2: turned on: {'on_off': TimeoutError()}

@sanyatuning mind taking a look?
IIRC these relays were picky about source endpoints. And in this case it is coming from SrcEndpoint=2.

I'm also noticing

2020-06-27 19:59:07 DEBUG (MainThread) [zigpy_cc.zigbee.application] message ignored: dataConfirm
2020-06-27 19:59:08 DEBUG (MainThread) [zigpy_cc.uart] Frame received: <UnpiFrame type=CommandType.AREQ subsystem=Subsystem.AF command_id=129 data=b'\x00\x00\x0c\x00|+\x01\x01\x001\x00]V\xa8\x00\x00\n\x18\xcc\nU\x009\x9a3\x0eB\x14\xa0\x1c' length=30 fcs=231>

Are we really ignoring data confirm and don't notify that message was sent successfuly? But I guess in case of successful transmission and if we're expecting a reply, then we could ignore it.

puddly · Answer 8 · Mon Jul 13 2020 02:33:02 GMT+0800 (China Standard Time)

This problem might also be related to #57 (comment), since it only fails on endpoint 2.

Alexei Chetroi · Answer 9 · Mon Jul 13 2020 02:45:59 GMT+0800 (China Standard Time)

I have that feeling too. Not quite sure why we need so many endpoints with the same profile-id. Think those could be coalesced into fewer and zigpy-cc should pick a specific src endpoint id when communicating with devices based on profile id and cluster id

puddly · Answer 10 · Mon Jul 13 2020 02:48:51 GMT+0800 (China Standard Time)

How does zigpy choose which endpoint is the source (https://github.com/zigpy/zigpy/blob/29e362563f31bc8e77462ac5b2fbd78c40aa926f/zigpy/application.py#L233-L260)? You could ignore the src_ep parameter in Application.request but that seems to me like the wrong place to do it.

Balazs Sandor · Answer 11 · Sat Jul 25 2020 03:48:10 GMT+0800 (China Standard Time)

Maybe this is the root cause (same ep_id used for src_ep and dst_ep)
https://github.com/zigpy/zigpy/blob/29e362563f31bc8e77462ac5b2fbd78c40aa926f/zigpy/endpoint.py#L220-L221

puddly · Answer 12 · Sat Jul 25 2020 23:17:38 GMT+0800 (China Standard Time)

I consolidated all of the endpoints into one in zigpy-znp and just override the source endpoint for every request. I unfortunately don't have any of these affected devices but it seems to work with my Bosch motion sensor that only has endpoint 5.