zha-device-handlers
zha-device-handlers copied to clipboard
[Device Support Request] TS130F - _TZ3000_1dd0d5yi - Moes curtain switch
Is your feature request related to a problem? Please describe. Currently there is already an implementation for this device, however, it seems it might be outdated? https://github.com/zigpy/zha-device-handlers/blob/dev/zhaquirks/tuya/ts130f.py#L161-L203
Describe the solution you'd like
Currently my device is seen as a general Tuya curtain roller (TuyaTS130FTI2). This isn't the case, it's a Moes curtain switch module.
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.
{
"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=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=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": "0x0203",
"in_clusters": [
"0x0000",
"0x0004",
"0x0005",
"0x0006",
"0x0102"
],
"out_clusters": [
"0x000a",
"0x0019"
]
}
},
"manufacturer": "_TZ3000_1dd0d5yi",
"model": "TS130F",
"class": "zhaquirks.tuya.ts130f.TuyaTS130FTI2"
}
Additional context
https://zigbee.blakadder.com/Moes_MS-108ZR.html
In addition to this issue. I can run various tasks for this device, like setting the calibration_time value. So basic functionality seems to work ok. It just thinks it's a different device.. hence the situation below:
It looks like it’s not 100% closing each time. So opening works fine but closing the cover doesn't close it fully. Even after I manually force-close the cover to try and "reset" the 0 location for the cover switch it still isn't fully closing after I use it again.
In my case it’s a patio cover in my garden which is slightly tilted down, I’m guessing this might be the reason it’s not fully closing? Not sure here… I guess it would be solved if the motor was run just a second longer when closing but I have no idea how to fix this with the ZHA clusters.
Any suggestions or tutorial/documentation pointers are very welcome!
Did some more testing and can definitely confirm that the opening and closing speed of my patio cover is not the same. This is the reason the calibration is off. Each time I open the cover and close it again it stops further away from actually closed.
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.
While this issue indeed has become stale it is definitely not fixed.
I have the same device and the same issue : it open nicely, but won't close completely. Please let me know if I can help debugging this :)
@JoryHogeveen I think this have been fixed : i found this issue where there is a lot of details, and it explains how you can check if the correct quirck is loaded. You need to use the Calibration time attribute. Make sure you read through everything : https://github.com/home-assistant/core/issues/46146
Hi @jbtrystram I've quickly read through the topic but unfortunately this won't fix this issue.
They point that there are to calibration types:
- Time: The time it takes for a motor to open and close. This doesn't work in this case since the open and close time is different.
- Rotations: This wil require a motor that provides feedback to the switch. I doubt any external motors can do this. Usually such switches are embedded in a curtain switch, example: https://nl.aliexpress.com/item/1005003796343800.html
So nope, this issue is still very much active :(
My current solution is to not calibrate the switch at all. I've disabled it on the moes switch and have finetuned it manually through a HA automation.
calibration_time
How do you add calibration time with zha? (no zigbee2mqtt).
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.
(Comment for GH Actions and future ref)
Issue is still very much active though people seem to find ways around the issue. For what I can tell now the issue is that ZHA doesn't provide simple ways to modify the modes and settings in which the curtain switch can operate. I'm not sure this is an actual issue of this switch or a more general ZHA issue for device settings. The Tuya app (and Z2MQTT) provide a clear interface to change such settings and ZHA only has the more technical clusters interface which requires the end user to do a lot of research and digging into the Tuya documentation to get/set cluster values.
Any new with this issue? I have the same problem, the up and down time are different, so if you sset it to 50% and then to 100% It will not close the blind completly. Mi first blind was waorking with 2 switches and I used Time based cover custom component with up and down time. But now I'm using the zigbee Moes MS-108ZR and I have the same issue. @JoryHogeveen Can you share the script you used to patch this?
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.