Closed localocavn closed 12 months ago
The same with the "_TZE200_r0jdjrvi"
Hello,
A few of us are having this issue and I've gathered some information. As I went to enter an issue, this one appears to be related so I am placing my additional info here:
Here’s a brief summary:
I have 4 Zemismart Zigbee curtain rails model TS0601. 3 of them work fine in HA. The 4th pairs without entities. Verified the device runs on Hubitat hub. All devices are branded zemismart but the manufacturer id for the device in question is different than the others. I believe this is related to the device not being read correctly in the library. The manufacturer ID of the rails that work is: TZE200_xaabybja The manufacturer ID of the rail that doesn't install the entities is: TZE200_rmymn92d
I have 2 Zemismart Zigbee curtain shades (brand new) that pair to HA without entities. The device model on these is also TS0601. The manufacturer ID of these shades is: TZE200_68nvbio9
There's a thread with screenshots and troubleshooting steps taken at: https://community.home-assistant.io/t/switch-zigbee-tze200-ts0601-paired-but-without-entities/262762/28?u=sergeantpup but what I've found out since is that it's definitely the same problem other people are having.
Another user has a device model TS0601 Radiator valve that has manufacturer ID: TZE200_zion52ef User is experiencing the same behavior. Device will pair without entities. Here is a link to their thread: https://community.home-assistant.io/t/adding-moes-rad-valve-tso601/364401?u=sergeantpup
Lastly, another user is having the same issue with device model TS0601 manufacturer ID: TZE200_rmymn92d (this is the same manufacturer ID of the first issue above). This user has done the digging and from what I can tell has determined the change that needs to be made: https://community.home-assistant.io/t/switch-zigbee-tze200-ts0601-paired-but-without-entities/262762/30?u=sergeantpup https://github.com/zigpy/zha-device-handlers/blob/9a1401337a25a4adc33e0b37ace62d808b7b3098/zhaquirks/tuya/ts0601_cover.py#L184
Signal strength has been ruled out by pairing it within the same room. All users have zigbee networks that are running fine with no other pairing issues besides these specific devices not installing entities
Hi @SergeantPup, I have the same problem with another motor _TZE200_nogaemzt. I've tried to add same line into the "right place" as this last user described, and I've tried to made custom zha quirk. After these actions, you will see entities but none of the commands would work. Problem is not in just one code line. I think there's something with the 242 GreenPowerProxy cluster, all of our devices have it and can't work properly. Another devices without it work normally.
Unfortunately, I've reached the extent of my knowledge/ability at this time. I'm new to HA but not new to smart homes and this is the deepest I've ever had to dive into any zigbee issue. I can point to the problem and that's about it; I don't possess enough knowledge to confirm/provide complete solutions. What you said certainly makes sense but I don't have the skillset to take this any further without somebody who understands better than I do :)
https://github.com/zigpy/zha-device-handlers/issues/1294 This is definitely related.
Having the same issue with TZE200_68nvbio9.
Having the same issue with TZE200_68nvbio9.
This is the same manufacturer id as my zemismart zigbee shades that I'm having the issue with. Thanks for your additional comments!
Today I added two more Zemismart Tuya Zigbee Curtain Motors with Track and both of them show up as TS0601 by _TZE200_rmymn92d.
The same with the "_TZE200_r0jdjrvi"
I confirm this one "_TZE200_r0jdjrvi" - device is added with no entities. Is there a way for a common user to add these IDs to quirks? I've tried configuration.yaml + .py file method with no luck. (my setup: HA OS on RPi 4)
@drusha for a common user - no. I think I did more, but nothing works
Any update on support _TZE200_rmymn92d ?
Hello,
A few of us are having this issue and I've gathered some information. As I went to enter an issue, this one appears to be related so I am placing my additional info here:
Here’s a brief summary:
I have 4 Zemismart Zigbee curtain rails model TS0601. 3 of them work fine in HA. The 4th pairs without entities. Verified the device runs on Hubitat hub. All devices are branded zemismart but the manufacturer id for the device in question is different than the others. I believe this is related to the device not being read correctly in the library. The manufacturer ID of the rails that work is: TZE200_xaabybja The manufacturer ID of the rail that doesn't install the entities is: TZE200_rmymn92d
Another user is having the same issue with device model TS0601 manufacturer ID: TZE200_rmymn92d (this is the same manufacturer ID of the first issue above). This user has done the digging and from what I can tell has determined the change that needs to be made: https://community.home-assistant.io/t/switch-zigbee-tze200-ts0601-paired-but-without-entities/262762/30?u=sergeantpup
Hello, I have a small update on manufacturer _TZE200_rmymn92d
Thanks to the undying effort and support of TheJulianJES, we loaded a custom local quirk that is partially working. The device is recognized, is being used as a router and offers curtain controls/position monitoring. All of this works except the curtain controls lol (they just don't respond). We spent several hours going down the rabbit hole and this is what we learned: When manufacturer _TZE200_rmymn92d buttons are pressed (and don't respond) you get what looks like attempts to send information out:
2022-02-27 11:59:18 DEBU2022-02-27 11:59:18 DEBUG (MainThread) [bellows.ezsp.protocol] Send command sendUnicast: (<EmberOutgoingMessageType.OUTGOING_DIRECT: 0>, 0xC7AC, EmberApsFrame(profileId=260, clusterId=61184, sourceEndpoint=1, destinationEndpoint=1, options=<EmberApsOption.APS_OPTION_ENABLE_ROUTE_DISCOVERY|APS_OPTION_RETRY: 320>, groupId=0, sequence=186), 187, b'\x05A\x11\xba\x00\x00\x00\x01\x04\x00\x01\x01')
2022-02-27 11:59:18 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame 52 (sendUnicast) received: b'00a5'
2022-02-27 11:59:18 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame 63 (messageSentHandler) received: b'00acc7040100ef010140010000a5bb0000'
2022-02-27 11:59:18 DEBUG (MainThread) [bellows.zigbee.application] Received messageSentHandler frame with [<EmberOutgoingMessageType.OUTGOING_DIRECT: 0>, 51116, EmberApsFrame(profileId=260, clusterId=61184, sourceEndpoint=1, destinationEndpoint=1, options=<EmberApsOption.APS_OPTION_ENABLE_ROUTE_DISCOVERY|APS_OPTION_RETRY: 320>, groupId=0, sequence=165), 187, <EmberStatus.SUCCESS: 0>, b'']
2022-02-27 11:59:18 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame 69 (incomingMessageHandler) received: b'00040100ef0101000100004bffbfacc7ffff0518ba0b008302'
2022-02-27 11:59:18 DEBUG (MainThread) [bellows.zigbee.application] Received incomingMessageHandler frame with [<EmberIncomingMessageType.INCOMING_UNICAST: 0>, EmberApsFrame(profileId=260, clusterId=61184, sourceEndpoint=1, destinationEndpoint=1, options=<EmberApsOption.APS_OPTION_ENABLE_ROUTE_DISCOVERY: 256>, groupId=0, sequence=75), 255, -65, 0xc7ac, 255, 255, b'\x18\xba\x0b\x00\x83']
2022-02-27 11:59:18 DEBUG (MainThread) [zigpy.zcl] [0xc7ac:1:0xef00] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=True disable_default_response=True> manufacturer=None tsn=186 command_id=Command.Default_Response>
2022-02-27 11:59:18 DEBUG (MainThread) [homeassistant.components.zha.core.channels.base] [0xC7AC:1:0x0102]: executed 'stop' command with args: '()' kwargs: '{}' result: [0, <Status.UNSUP_MANUF_CLUSTER_COMMAND: 131>]G (MainThread) [bellows.ezsp.protocol] Send command sendUnicast: (<EmberOutgoingMessageType.OUTGOING_DIRECT: 0>, 0xC7AC, EmberApsFrame(profileId=260, clusterId=61184, sourceEndpoint=1, destinationEndpoint=1, options=<EmberApsOption.APS_OPTION_ENABLE_ROUTE_DISCOVERY|APS_OPTION_RETRY: 320>, groupId=0, sequence=186), 187, b'\x05A\x11\xba\x00\x00\x00\x01\x04\x00\x01\x01')
2022-02-27 11:59:18 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame 52 (sendUnicast) received: b'00a5'
2022-02-27 11:59:18 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame 63 (messageSentHandler) received: b'00acc7040100ef010140010000a5bb0000'
2022-02-27 11:59:18 DEBUG (MainThread) [bellows.zigbee.application] Received messageSentHandler frame with [<EmberOutgoingMessageType.OUTGOING_DIRECT: 0>, 51116, EmberApsFrame(profileId=260, clusterId=61184, sourceEndpoint=1, destinationEndpoint=1, options=<EmberApsOption.APS_OPTION_ENABLE_ROUTE_DISCOVERY|APS_OPTION_RETRY: 320>, groupId=0, sequence=165), 187, <EmberStatus.SUCCESS: 0>, b'']
2022-02-27 11:59:18 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame 69 (incomingMessageHandler) received: b'00040100ef0101000100004bffbfacc7ffff0518ba0b008302'
2022-02-27 11:59:18 DEBUG (MainThread) [bellows.zigbee.application] Received incomingMessageHandler frame with [<EmberIncomingMessageType.INCOMING_UNICAST: 0>, EmberApsFrame(profileId=260, clusterId=61184, sourceEndpoint=1, destinationEndpoint=1, options=<EmberApsOption.APS_OPTION_ENABLE_ROUTE_DISCOVERY: 256>, groupId=0, sequence=75), 255, -65, 0xc7ac, 255, 255, b'\x18\xba\x0b\x00\x83']
2022-02-27 11:59:18 DEBUG (MainThread) [zigpy.zcl] [0xc7ac:1:0xef00] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=True disable_default_response=True> manufacturer=None tsn=186 command_id=Command.Default_Response>
2022-02-27 11:59:18 DEBUG (MainThread) [homeassistant.components.zha.core.channels.base] [0xC7AC:1:0x0102]: executed 'stop' command with args: '()' kwargs: '{}' result: [0, <Status.UNSUP_MANUF_CLUSTER_COMMAND: 131>]
But manufacturer _TZE200_xaabybja doesn't do anything like that:
2022-02-27 12:03:16 DEBUG (MainThread) [bellows.zigbee.application] Received incomingMessageHandler frame with [<EmberIncomingMessageType.INCOMING_UNICAST: 0>, EmberApsFrame(profileId=260, clusterId=61184, sourceEndpoint=1, destinationEndpoint=1, options=<EmberApsOption.APS_OPTION_ENABLE_ROUTE_DISCOVERY: 256>, groupId=0, sequence=58), 254, -79, 0x85f8, 255, 255, b'\t-\x01\x00w\x01\x04\x00\x01\x02']
2022-02-27 12:03:16 DEBUG (MainThread) [zigpy.zcl] [0x85f8:1:0xef00] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=45 command_id=1>
2022-02-27 12:03:16 DEBUG (MainThread) [zigpy.zcl] [0x85f8:1:0xef00] ZCL request 0x0001: [Command(status=0, tsn=119, command_id=1025, function=0, data=[1, 2])]
2022-02-27 12:03:16 DEBUG (MainThread) [tuya] 8c:f6:81:ff:fe:d1:b7:ab Received Attribute Report. Command is 0x0001, Tuya Paylod values[Status : 0, TSN: 119, Command: 0x0401, Function: 0x00, Data: [1, 2]]
2022-02-27 12:03:16 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=sensor.washer_energy_monitor_electric_consumption_a, old_state=<state sensor.washer_energy_monitor_electric_consumption_a=0.0; state_class=measurement, meter_type=1, meter_type_name=ELECTRIC, unit_of_measurement=A, device_class=current, friendly_name=Washer Energy Monitor: Electric Consumption [A] @ 2022-02-27T12:03:01.329390-05:00>, new_state=<state sensor.washer_energy_monitor_electric_consumption_a=0.0; state_class=measurement, meter_type=1, meter_type_name=ELECTRIC, unit_of_measurement=A, device_class=current, friendly_name=Washer Energy Monitor: Electric Consumption [A] @ 2022-02-27T12:03:16.306796-05:00>>
2022-02-27 12:03:16 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame 69 (incomingMessageHandler) received: b'0004010204010140010000befeb6f5ccffff0808120a000029d307'
2022-02-27 12:03:16 DEBUG (MainThread) [bellows.zigbee.application] Received incomingMessageHandler frame with [<EmberIncomingMessageType.INCOMING_UNICAST: 0>, EmberApsFrame(profileId=260, clusterId=1026, sourceEndpoint=1, destinationEndpoint=1, options=<EmberApsOption.APS_OPTION_ENABLE_ROUTE_DISCOVERY|APS_OPTION_RETRY: 320>, groupId=0, sequence=190), 254, -74, 0xccf5, 255, 255, b'\x08\x12\n\x00\x00)\xd3\x07']
2022-02-27 12:03:16 DEBUG (MainThread) [zigpy.zcl] [0xccf5:1:0x0402] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=18 command_id=Command.Report_Attributes>
2022-02-27 12:03:16 DEBUG (MainThread) [zigpy.zcl] [0xccf5:1:0x0402] ZCL request 0x000a: [[Attribute(attrid=0, value=<TypeValue type=int16s, value=2003>)]]
2022-02-27 12:03:16 DEBUG (MainThread) [zigpy.zcl] [0xccf5:1:0x0402] Attribute report received: measured_value=2003
2022-02-27 12:03:16 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=sensor.front_entryway_motion_sensor_upper_temperature, old_state=<state sensor.front_entryway_motion_sensor_upper_temperature=68.5; state_class=measurement, unit_of_measurement=°F, device_class=temperature, friendly_name=Front Entryway Motion Sensor (upper) temperature @ 2022-02-27T11:48:07.548408-05:00>, new_state=<state sensor.front_entryway_motion_sensor_upper_temperature=68.0; state_class=measurement, unit_of_measurement=°F, device_class=temperature, friendly_name=Front Entryway Motion Sensor (upper) temperature @ 2022-02-27T12:03:16.313976-05:00>>
2022-02-27 12:03:16 DEBUG (MainThread) [bellows.ezsp.protocol] Send command sendUnicast: (<EmberOutgoingMessageType.OUTGOING_DIRECT: 0>, 0xCCF5, EmberApsFrame(profileId=260, clusterId=1026, sourceEndpoint=1, destinationEndpoint=1, options=<EmberApsOption.APS_OPTION_ENABLE_ROUTE_DISCOVERY|APS_OPTION_RETRY: 320>, groupId=0, sequence=18), 244, b'\x18\x12\x0b\n\x00')
2022-02-27 12:03:16 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame 52 (sendUnicast) received: b'00d5'
2022-02-27 12:03:16 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame 89 (incomingRouteRecordHandler) received: b'f885abb7d1feff81f68cfdb3011cb4'
2022-02-27 12:03:16 DEBUG (MainThread) [bellows.zigbee.application] Received incomingRouteRecordHandler frame with [0x85f8, 8c:f6:81:ff:fe:d1:b7:ab, 253, -77, [0xb41c]]
2022-02-27 12:03:16 DEBUG (MainThread) [bellows.zigbee.application] Processing route record request: (0x85f8, 8c:f6:81:ff:fe:d1:b7:ab, 253, -77, [0xb41c])
2022-02-27 12:03:16 DEBUG (MainThread) [bellows.ezsp.protocol] Send command nop: ()
2022-02-27 12:03:16 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame 5 (nop) received: b''
2022-02-27 12:03:16 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=sensor.washer_energy_monitor_electric_consumption_kwh, old_state=<state sensor.washer_energy_monitor_electric_consumption_kwh=57.19; state_class=total_increasing, meter_type=1, meter_type_name=ELECTRIC, unit_of_measurement=kWh, device_class=energy, friendly_name=Washer Energy Monitor: Electric Consumption [kWh] @ 2022-02-27T12:03:01.419613-05:00>, new_state=<state sensor.washer_energy_monitor_electric_consumption_kwh=57.19; state_class=total_increasing, meter_type=1, meter_type_name=ELECTRIC, unit_of_measurement=kWh, device_class=energy, friendly_name=Washer Energy Monitor: Electric Consumption [kWh] @ 2022-02-27T12:03:16.408221-05:00>>
2022-02-27 12:03:16 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame 89 (incomingRouteRecordHandler) received: b'f885abb7d1feff81f68cd5b5011cb4'
2022-02-27 12:03:16 DEBUG (MainThread) [bellows.zigbee.application] Received incomingRouteRecordHandler frame with [0x85f8, 8c:f6:81:ff:fe:d1:b7:ab, 213, -75, [0xb41c]]
2022-02-27 12:03:16 DEBUG (MainThread) [bellows.zigbee.application] Processing route record request: (0x85f8, 8c:f6:81:ff:fe:d1:b7:ab, 213, -75, [0xb41c])
2022-02-27 12:03:16 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame 69 (incomingMessageHandler) received: b'00040100ef0101000100003bc9b2f885ffff0a092d010077010400010204'
2022-02-27 12:03:16 DEBUG (MainThread) [bellows.zigbee.application] Received incomingMessageHandler frame with [<EmberIncomingMessageType.INCOMING_UNICAST: 0>, EmberApsFrame(profileId=260, clusterId=61184, sourceEndpoint=1, destinationEndpoint=1, options=<EmberApsOption.APS_OPTION_ENABLE_ROUTE_DISCOVERY: 256>, groupId=0, sequence=59), 201, -78, 0x85f8, 255, 255, b'\t-\x01\x00w\x01\x04\x00\x01\x02']
2022-02-27 12:03:16 DEBUG (MainThread) [zigpy.zcl] [0x85f8:1:0xef00] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=45 command_id=1>
2022-02-27 12:03:16 DEBUG (MainThread) [zigpy.zcl] [0x85f8:1:0xef00] ZCL request 0x0001: [Command(status=0, tsn=119, command_id=1025, function=0, data=[1, 2])]
2022-02-27 12:03:16 DEBUG (MainThread) [tuya] 8c:f6:81:ff:fe:d1:b7:ab Received Attribute Report. Command is 0x0001, Tuya Paylod values[Status : 0, TSN: 119, Command: 0x0401, Function: 0x00, Data: [1, 2]]
2022-02-27 12:03:16 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=sensor.washer_energy_monitor_electric_consumption_w, old_state=<state sensor.washer_energy_monitor_electric_consumption_w=0.0; state_class=measurement, meter_type=1, meter_type_name=ELECTRIC, unit_of_measurement=W, device_class=power, friendly_name=Washer Energy Monitor: Electric Consumption [W] @ 2022-02-27T12:03:01.506706-05:00>, new_state=<state sensor.washer_energy_monitor_electric_consumption_w=0.0; state_class=measurement, meter_type=1, meter_type_name=ELECTRIC, unit_of_measurement=W, device_class=power, friendly_name=Washer Energy Monitor: Electric Consumption [W] @ 2022-02-27T12:03:16.507407-05:00>>
2022-02-27 12:03:16 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame 63 (messageSentHandler) received: b'00f5cc04010204010140010000d5f40000'
2022-02-27 12:03:16 DEBUG (MainThread) [bellows.zigbee.application] Received messageSentHandler frame with [<EmberOutgoingMessageType.OUTGOING_DIRECT: 0>, 52469, EmberApsFrame(profileId=260, clusterId=1026, sourceEndpoint=1, destinationEndpoint=1, options=<EmberApsOption.APS_OPTION_ENABLE_ROUTE_DISCOVERY|APS_OPTION_RETRY: 320>, groupId=0, sequence=213), 244, <EmberStatus.SUCCESS: 0>, b'']
2022-02-27 12:03:16 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame 89 (incomingRouteRecordHandler) received: b'f885abb7d1feff81f68cffb1011cb4'
2022-02-27 12:03:16 DEBUG (MainThread) [bellows.zigbee.application] Received incomingRouteRecordHandler frame with [0x85f8, 8c:f6:81:ff:fe:d1:b7:ab, 255, -79, [0xb41c]]
2022-02-27 12:03:16 DEBUG (MainThread) [bellows.zigbee.application] Processing route record request: (0x85f8, 8c:f6:81:ff:fe:d1:b7:ab, 255, -79, [0xb41c])
2022-02-27 12:03:16 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame 69 (incomingMessageHandler) received: b'00040100ef0101000100003cffb2f885ffff0a092d010077010400010204'
2022-02-27 12:03:16 DEBUG (MainThread) [bellows.zigbee.application] Received incomingMessageHandler frame with [<EmberIncomingMessageType.INCOMING_UNICAST: 0>, EmberApsFrame(profileId=260, clusterId=61184, sourceEndpoint=1, destinationEndpoint=1, options=<EmberApsOption.APS_OPTION_ENABLE_ROUTE_DISCOVERY: 256>, groupId=0, sequence=60), 255, -78, 0x85f8, 255, 255, b'\t-\x01\x00w\x01\x04\x00\x01\x02']
2022-02-27 12:03:16 DEBUG (MainThread) [zigpy.zcl] [0x85f8:1:0xef00] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=45 command_id=1>
2022-02-27 12:03:16 DEBUG (MainThread) [zigpy.zcl] [0x85f8:1:0xef00] ZCL request 0x0001: [Command(status=0, tsn=119, command_id=1025, function=0, data=[1, 2])]
2022-02-27 12:03:16 DEBUG (MainThread) [tuya] 8c:f6:81:ff:fe:d1:b7:ab Received Attribute Report. Command is 0x0001, Tuya Paylod values[Status : 0, TSN: 119, Command: 0x0401, Function: 0x00, Data: [1, 2]]
Here is the original and working _TZE200_xaabybja
Here is the last and non-button responsive _TZE200_rmymn92d
Here it is displaying as an actual router like the _TZE200_xaabybja which is an improvement from previous functionality:
As you can see, we're significantly further along than the last time I checked in and I believe this will help me on my endeavor to resolve _TZE200_68nvbio9. We just can't figure out why the physical buttons in HA aren't working and why is this device trying to make calls when none of the others do that.
Here is the file structure we used to get it local:
Here is the actual files with the quirk: tuya.zip
We added a line to reverse _TZE200_rmymn92d by default like _TZE200_xaabybja and this is helping the device recognize the correct open/closed state accurately:
I'm hoping some of the more savvy people on this thread might be able to take a look and bring us home! I will continue to put forth effort on this device until we can get it running. We're so close.
I may not have formatted everything here correctly but I have scads of documentation from our steps/logs, I fully understand where we're currently at in the situation and I'll happily provide it in whatever form makes it easier to use.
Normal covers is needing button maps added in INIT or the keys is not working: https://github.com/zigpy/zha-device-handlers/blob/e4e62504738ced0c54c983ee5094a3a6af0a741d/zhaquirks/tuya/__init__.py#L93-L111
And normally for testing your need doing the changes in the HA container if not doing extra patching or its not working with custom quirks.
but we have that and it DOES match the button configurations of the other working device manufacturer:
Never trust tuya devices then they is doing all possible and impossible things in them !! Try all combinations if its getting the keys working OK al look in the log what the system is doing then pressing the keys.
We tried a dozen combos last night with the same results on each. I can run through and try all the combinations.
The last screenshot is the up out grayed = its 100% up = OK or its between and its stop or its 100% down = down.
Can also trying inverted function if the device is inverted: https://github.com/zigpy/zha-device-handlers/blob/e4e62504738ced0c54c983ee5094a3a6af0a741d/zhaquirks/tuya/__init__.py#L112-L124
Yes that's correct. Up is grayed out because the curtain is currently in open position and this matches the other devices/states.
If I were to close the curtains with the remote, the up would appear and the down will continue to appear until they are closed, then the down will gray out. It's absolutely tracking accurately; I have other animations that respond when the curtain is moved via remote. I'm playing with button combos right now if we really think that's all this is.
Now that I went through the exercise of swapping out all the button settings, it has become obvious that I just did what TheJulianJES, had me do but I didn't realize there were only a few combinations till just now. I just tried all of them again with restarts in between with no new results. I DID see this:
2022-02-27 13:28:55 DEBUG (MainThread) [homeassistant.components.zha.core.channels.base] [0xC7AC:1:0x0102]: executed 'stop' command with args: '()' kwargs: '{}' result: [0, <Status.UNSUP_MANUF_CLUSTER_COMMAND: 131>]
2022-02-27 13:28:53 DEBUG (MainThread) [homeassistant.components.zha.core.channels.base] [0xC7AC:1:0x0102]: executed 'down_close' command with args: '()' kwargs: '{}' result: [0, <Status.UNSUP_MANUF_CLUSTER_COMMAND: 131>]
Isn't it telling me I have a problem, here?
Not sure if this matters but these zigbee signatures don't match:
I tried swapping it for "0x0202" like what's in the Zigbee signature and the other devices but then all the buttons turned gray
The device is definitely being read/recognized like the other ones as 0x0051 and it's keeping position/state accurately:
Zigbee profile 0x0202
is what the quirk is giving the device in the replacement and its:
https://github.com/zigpy/zigpy/blob/ba9abc75d9575da3f23d5f681d5ad131980af8d7/zigpy/profiles/zha.py#L46.
0x0051
is what tuya is saying it is and must match in the signature for getting it matched and loaded.
https://github.com/zigpy/zigpy/blob/ba9abc75d9575da3f23d5f681d5ad131980af8d7/zigpy/profiles/zha.py#L23
Changing it in the signature is making the system is not loading the quirk if you is looking on the device signature.
@SergeantPup keep digging pls. I stopped on "UNSUP_MANUF_CLUSTER_COMMAND" too with _TZE200_r0jdjrvi
@Kiread-work, I have reached out to Blakladder and asked for a double validation of the code. Something is definitely not right and the fact that it's acting so differently than the others when trying to control it leads me to believe there's a silly problem somewhere upstream. It definitely stands to reason with the unsup manuf cluster command if something's not set just right and the commands aren't being recognized/executed.
I know their site says both models were validated with ZHA and Zigbee2MQTT https://zigbee.blakadder.com/Zemismart_BCM500DS-TYZ.html but I've not been able to find a single user or issue open/closed regarding rmymn92d so my suspicion grows further. The fact that the device state is being read accurately increases my suspicions even further.
@SergeantPup I see some projects where our devices work fine, for example, https://github.com/Koenkk/zigbee-herdsman-converters/blob/master/devices/tuya.js https://community.homey.app/t/app-pro-tuya-zigbee-app/26439 https://github.com/Koenkk/zigbee2mqtt/issues/11016
So it might work right, but how :(
The zigbee2MQTT resources were not available last night (I kept getting page errors last night). They appear to be working this morning and I can continue my digging. I want to validate some things in zigbee2mqtt to see if our problem is starting there.
I DO see where rmymn92d is referenced in one of the links you provided. I know it works on other platforms (I had this working on Hubitat fine). In 3 months time, I've already forgotten how Hubitat works but I thought when I looked at this before, their architecture is so different, there wasn't anything I could use from it to help us here. I'm desperate enough to fire it back up just to get this device figured out.
I'll spend more time on this today.
For the record, my rmymn92d is working perfectly with Z2M currently.
device:
applicationVersion: 68
dateCode: ''
friendlyName: Bedroom Curtains
hardwareVersion: 1
ieeeAddr: '0xa4c138df4bca9cbd'
manufacturerID: 4417
manufacturerName: _TZE200_rmymn92d
model: TS0601_cover
networkAddress: 64732
powerSource: Mains (single phase)
stackVersion: 0
type: Router
zclVersion: 3
well that just saved me a TON of digging! Thank you, I'll play with this some more today
For the record, my rmymn92d is working perfectly with Z2M currently.
device: applicationVersion: 68 dateCode: '' friendlyName: Bedroom Curtains hardwareVersion: 1 ieeeAddr: '0xa4c138df4bca9cbd' manufacturerID: 4417 manufacturerName: _TZE200_rmymn92d model: TS0601_cover networkAddress: 64732 powerSource: Mains (single phase) stackVersion: 0 type: Router zclVersion: 3
Since approximately when? I'm wondering if we all have an outdated copy of the Zigbee2MQTT code for this device? It was copied about a month ago.
Humm, let's see.. When I first got it, I tried to get it to work with ZHA, but ended up switching to z2m after testing that it "just works" there. It was delivered on 17th of January, 2022, installation took me about a week. Then a day or two of fighting with ZHA and failing, would put me going for z2m at around early February.
I'm on bleeding edge though (1.22.2-dev commit: f0f7662 currently), if that matters. Absolutely no idea what the commit ID would've been for the version I initially found it working.
Have exactly the same problem with _TZE200_nogaemzt, #1240. Got it at the end of December 2021, had no luck to make it work in ZHA since then.
There's one little detail that I've noticed. Another curtain motors that look identically but work normally not only missing GreenPowerProxy cluster, but their manufacturer_code is 4098 while our devices manufacturer_code is 4417. Maybe this is related to the UNSUP_MANUF_CLUSTER_COMMAND
problem.
Humm, let's see.. When I first got it, I tried to get it to work with ZHA, but ended up switching to z2m after testing that it "just works" there. It was delivered on 17th of January, 2022, installation took me about a week. Then a day or two of fighting with ZHA and failing, would put me going for z2m at around early February.
@operinko, I am trying to triangulate the problem/difference between the drivers. I have both versions of this device for ZHA and the rmymn92D is definitely showing different logs when pressing buttons(that don't work). But the sister device xaabybja works fine but doesn't show anything conclusive in the logs.
I was wondering if you'd be willing to run logging on your machine and press the curtain close button and capture the successful logs for us?
I was provided this logger that I'm hoping will work with zigbee2mqtt based on what it's searching for:
logger:
default: info
logs:
homeassistant.core: debug
homeassistant.components.zha: debug
bellows.zigbee.application: debug
bellows.ezsp: debug
zigpy: debug
zigpy_deconz.zigbee.application: debug
zigpy_deconz.api: debug
zigpy_xbee.zigbee.application: debug
zigpy_xbee.api: debug
zigpy_zigate: debug
zigpy_znp: debug
zhaquirks: debug
tuya: debug
You can easily find your device in the logs by searching the the device network id that's found in the device page. Mine looks like this: 0xc7ac
I'd like to take THOSE logs, cross reference it with the logs from my two devices and try to figure out what we're missing (or at least point to something conclusively wrong like where it appears to be making a call out in my logs).
Then based on THOSE findings, work with Julien in the code and try to figure out what's preventing control but allowing state tracking on the ZHA version.
I'm in the middle of a home network renovation, but I'll try to find some time to do that in the next few days. I'd have time now, but opening and closing the bedroom curtains while the pregnant wife is asleep is a death sentence :D
absolutely no hurry at all. This is the only device out of 300 that doesn't work and its in a non-critical area. Thank you
Same issue with curtain rod motor TZE200_cf1sl3tj. I will try Z2M since I'm not very comfortable with custom quirks.
@operinko @makeitworktech @drusha @matt-from-uk @localocavn Hey guys, try a solution from https://github.com/zigpy/zha-device-handlers/issues/1294. I've managed to control the covering percentage via sliders with it, but buttons still don't work. Guys from this issue can control buttons, but they have another model. Signature is same, it should work for your devices.
i am having the same behaviour with my zemismart 6 gang switch 4x4, TS0601 by _TZE200_9mahtqtg must be related.
same, pairing with no entitites:
{ "node_descriptor": "NodeDescriptor(logical_type=<LogicalType.Router: 1>, complex_descriptor_available=0, user_descriptor_available=0, reserved=0, aps_flags=0, frequency_band=<FrequencyBand.Freq2400MHz: 8>, mac_capability_flags=<MACCapabilityFlags.AllocateAddress|RxOnWhenIdle|MainsPowered|FullFunctionDevice: 142>, manufacturer_code=4417, maximum_buffer_size=66, maximum_incoming_transfer_size=66, server_mask=10752, maximum_outgoing_transfer_size=66, descriptor_capability_field=<DescriptorCapability.NONE: 0>, allocate_address=True, is_alternate_pan_coordinator=False, is_coordinator=False, is_end_device=False, is_full_function_device=True, is_mains_powered=True, is_receiver_on_when_idle=True, is_router=True, *is_security_capable=False)", "endpoints": { "1": { "profile_id": 260, "device_type": "0x0051", "in_clusters": [ "0x0000", "0x0004", "0x0005", "0xef00" ], "out_clusters": [ "0x000a", "0x0019" ] }, "242": { "profile_id": 41440, "device_type": "0x0061", "in_clusters": [], "out_clusters": [ "0x0021" ] } }, "manufacturer": "_TZE200_9mahtqtg", "model": "TS0601", "class": "zigpy.device.Device" }
Any progress here?
Data point: I have a "ZemiSmart Curtain motor" (the one that crawls along the rail) with id _TZE200_nw1r9hp6
. ZHA detects it without entities. It works with Zigbee2MQTT using this converter code (with modified manufacturerName
).
{
"node_descriptor": "NodeDescriptor(logical_type=<LogicalType.EndDevice: 2>, complex_descriptor_available=0, user_descriptor_available=0, reserved=0, aps_flags=0, frequency_band=<FrequencyBand.Freq2400MHz: 8>, mac_capability_flags=<MACCapabilityFlags.AllocateAddress: 128>, manufacturer_code=4098, maximum_buffer_size=82, maximum_incoming_transfer_size=82, server_mask=11264, maximum_outgoing_transfer_size=82, descriptor_capability_field=<DescriptorCapability.NONE: 0>, *allocate_address=True, *is_alternate_pan_coordinator=False, *is_coordinator=False, *is_end_device=True, *is_full_function_device=False, *is_mains_powered=False, *is_receiver_on_when_idle=False, *is_router=False, *is_security_capable=False)",
"endpoints": {
"1": {
"profile_id": 260,
"device_type": "0x0051",
"in_clusters": [
"0x0000",
"0x0004",
"0x0005",
"0xef00"
],
"out_clusters": [
"0x000a",
"0x0019"
]
}
},
"manufacturer": "_TZE200_nw1r9hp6",
"model": "TS0601",
"class": "zigpy.device.Device"
}
Is there a solution to this problem?
Currently, working solution can be found here in the latest comments https://github.com/zigpy/zha-device-handlers/issues/1953. My similar motor works with it.
Is there a solution to this problem?
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.
Is your feature request related to a problem? Please describe. At the moment it just adds it as a "router" device, doesn't detect as a curtain
Describe the solution you'd like Use it to open/close curtains
Device signature - this can be acquired by removing the device from ZHA and pairing it again from the add devices screen. Be sure to add the entire content of the log panel after pairing the device to a code block below this line.
Additional context My device looks like Tuya_DS82
I tried the guideline from https://github.com/zigpy/zha-device-handlers/issues/744#issuecomment-973143832 but it looks the issue the same as https://github.com/zigpy/zha-device-handlers/issues/1240