Ikea Zigbee repeaters are the best bang for buck IMHO.
They don't seem to cause issues with other brand devices as some Tuya repeaters appear to do.
2 Likes
Unfortunately they aren't available in North America.
Sengled outlets (the oval ones not the square ones)
1 Like
The new models added in the last month were pushed for an update in version 3.2.4 via HPM.
Hi everyone,
Just letting you know I've successfully used this driver with a Blindsmart Tuya Zigbee Motorized Window Opener: https://www.aliexpress.com/item/1005004251482469.html
- endpointId: 01
- application: 53
- inClusters: 0000,0004,0005,EF00
- manufacturer: _TZE200_fzo2pocs
- model: TS0601
- outClusters: 0019,000A
- softwareBuild:
Substitute Open/Close commands with SetPosition was automatically set after Configure was run, however I had to set Mode to tilt manually. Everything worked great after that. Thanks to the creator(s). Fantastic work.
I see a couple of log entries that may be of interest:
dev:5722022-12-10 16:16:30.327 warn parse: Not a Tuya Message descMap=[raw:F63B0100001801002053E2FF201FE4FF2000, dni:F63B, endpoint:01, cluster:0000, size:18, attrId:0001, encoding:20, command:0A, value:53, clusterInt:0, attrInt:1, additionalAttrs:[[value:1F, encoding:20, attrId:FFE2, consumedBytes:4, attrInt:65506], [value:00, encoding:20, attrId:FFE4, consumedBytes:4, attrInt:65508]]]
dev:5722022-12-10 16:16:00.046 error org.codehaus.groovy.runtime.metaclass.MissingMethodExceptionNoStack: No signature of method: user_driver_amosyuen_ZemiSmart_Zigbee_Blind_694.autoPoll() is applicable for argument types: () values: [] (method autoPoll)
The warning only appeared after I enabled Log unexpected messages, so may not be that important. I'd be interested in getting to the bottom of the error message though.
1 Like
Thank you for the report, @Gradenko !
That's another Tuya platform oddity - your device has a newer firmware (application) version 53, and the manufacturer has changed the inClusters list compared to the previous version 52 ! : (
As there was no need to track the app. version of one and the same model and manufacture until now, there is no code to set the Mode parameter to tilt automatically for this device, it should be done manually for now.
The unexpected message is informative only, every device has some specific (and generally unknown) messages that probably only the manufacturer uses for specific needs.
The error log message is due to the fact that this device fingerprint was missing and most probably it was assigned another driver when first paired to HE (the Tuya Metering Plug maybe)?
I have added unscheduling of all periodic tasks that may have left potentially from other drivers, when you click on Save Preferences button again the error should not pop up anymore.
You can update the driver manually to the new dev, branch version 3.2.5
Yep, that's correct. HE initially assigned the Tuya Zigbee Metering Plug as the driver.
Thanks for the updated driver. I'm trying it out now.
1 Like
The development branch was updated to version 3.3.0 (2022-12-30) :
- adds support for TS0601 and TS130F models of Tuya/Moes Curtain switches: _TZ3000_zirycpws, _TZ3000_1dd0d5yi, _TZ3000_4uuaja4a, _TZ3000_fccpjz5z, _TZ3000_vd43bbfq, _TZ3000_ke7pzj5d
- new advanced option "forcedTS130F" - use only for these TS130F curtain switches, that are not automatically recognized by HE hub.
- new Calibrate command - works for some models only (ZM85, TS130F and Moes TS0601 curtain switches)
- improvements for ZM85EL-2x "SUPER CURTAIN ROBOT MOTOR" - some more details here.
The driver can be updated to the latest version by clicking on Import button within Drivers Code when editing "ZemiSmart Zigbee Blind" driver. If no issues are reported, the main version will be updated and pushed via HPM in the next week.
Happy New Year 2023!
1 Like
@kkossev (or anyone who knows for sure) - a query regarding the preference panel and 'Min Open Position'.
My blind was calibrated correctly with the buttons before it was added to HE. Every now and then when the blind opens on a morning, the value for level is at 98 (rather than 99/100) when it reaches it's fully open position. That results in the state showing 'opening' rather than 'open'. This screws up some of my lighting rules which are set to turn off when that blind reports open. If I lowered that 'Min Open Value' to 98 would that solve my problem or is that setting for something different? Thanks.
Hi @johnwill1 ,
Happy New Year!
I think that this use case has been exactly the aim when the "Min Open Position" was added in the driver - when for any reason the blind can't reach the 100% open position, the blind to be considered open when it reaches 85 or 85 or ... percent.
This is not OK.... The windowShade state should become 'Partially open' when the blind does not reach the fully open position after a timeout. What is the value of the Advanced option "Position report timeout, ms *" ?
Hi @kkossev - Happy New Year to you too.
Thanks for confirming that function. I should be able to drop the value from 99 to 98 to resolve that occasional issue.
Apologies please disregard that comment about the state remaining as ‘opening’ when the blind stops at level 98 as I didn’t confirm that in the device page at the time. I’m sure it will be ‘partially open’, as I recall we tested this to death some time ago when you added my model to the driver code.
I’d have to see it fail again in order to be sure the what the state is. I could send it to position 98 to test but perhaps that’s not quite the same as when a command sends it to position 100 and the blinds limit stops it early at 98 - position reached vs failed to reach position
Hi,
I got another two of these window openers:
Noticed some oddities while setting them up. Both of them refused to do anything except jiggle a little when "Configure" is hit. Changing the driver to "Tuya Zigbee Metering Plug", hitting "Off" and then changing the drive back to "ZeniSmart Zigbee Blind" seemed to have fixed both. I have no idea why that works, but I was able to issue Set Level after that.
Another oddity I found is that while "Substitue Open/Close" is automatically set, it isn't applied until "Show Advanced options" is enabled.
1 Like
"BlindSmart" seems to be a new manufacturer... Please post the model, manufcturer, application, etc... from the device web page in HE 'Data' section.
I previously reported on an example of this motor on Dec 10th. These 2 new motors have the following details:
- endpointId: 01
- application: 53
- manufacturer: _TZE200_fzo2pocs
- model: TS0601
What do you think about this unit now that you have used it for a few months?
The extremely cheap price tag on it causes worry and relief if I wanted to do the whole home with them.
What's your take? Is the remote control still needed?
It's most probably the TuyaMagic() code used in the metering plug driver that made it work .. : )
This spell wasn't needed for the older Zemismart devices, but it is obviously required for your device.
I will add it in the next driver version, so there should be no need to flip between different drivers.
I had a fair bit of difficulty initially as I had a wooden rod - there is a fair amount of friction between the rod and the curtain rings, it needs a lot of lubricant spray (eg teflon) . If you have metal on metal I think it should be fine. Also note that you may have problems if there is a joint/bump in the rod as it does not handle these that well. That said it does the job but not without quite a bit of 'tuning'. Because of this I am no where close to getting 6 months battery life probably 2 at most between charges.
Remote is a must have as this is the only way to set the travel end points.
How did you deal with the bump?
I don't have that problem as my rods are a single length. You basically need to smooth out any transitions as best you can.
Hello my friends
There is any way to remove the battery status from the driver? My motor is connected to power. Thanks and appreciate this amazing community
