Yes, I think so. At least you said that when I linked to the product earlier. 
@ktd Sections 5 and 6
Thank you but it doesnât look lite the one I got.
I have this motor ZM85EL-1Z.pdf - Google Drive
Unfortunately it seems like there is no factory reset. Deleting all limits and reset them doesnât work.
I get the beeps indicating limits been set but the blind passes by the limits like they donât exist. 
I would suspect you could still use the same instructions (leave the remote out of it)
The instructions say that this model requires the remote to set limits.
I will try without thoughâŚ
UPDATE those instructions unfortunately doesnât work at all.
Have you tried fresh batteries in the remote ?
After having the device powered off for almost a week I tried resetting the limits again yesterday and it worked.
Iâm keeping my fingers crossed it was a pane time issue.
Thank you all for trying to help. 
2 Likes
Hi @kkossev and co.
Been playing around with a _TZ3000_yruungrl, another flavour of TS130F, and couldn't get the setPosition to work (no calibration), so after fiddling around with the driver and the tuya docs, I stumbled upon this solution:
In the void setPosition(final BigDecimal positionParam) { method, last call, replace
sendTuyaCommand(DP_ID_TARGET_POSITION, DP_TYPE_VALUE, position.intValue(), 8)
with
if (isTS130F()) {
sendZigbeeCommands(zigbee.command(0x0102, DP_COMMAND_LIFTPERCENT as int, zigbee.convertToHexString(position.intValue(),1)))
}else{
sendTuyaCommand(DP_ID_TARGET_POSITION, DP_TYPE_VALUE, position.intValue(), 8)
}
aaand setPosition miraculously works.
Might work on other models as well, I have none to test.
Best part, seems to not need limits calibration 
The relay: Nous B4Z ZigBee Smart Curtain module - Nous technology
Made by Sheee.... :cough: Nous
Have a bonus fingerprint for the driver:
fingerprint profileId:'0104', endpointId:'01', inClusters:'0004,0005,0006,0102,E001,0000', outClusters:'0019,000A', model:'TS130F', manufacturer:'_TZ3000_yruungrl' ,deviceJoinName: 'Zigbee Curtain Module'
1 Like
Hello guys,
I have Abalon curtain motor which works fine with this driver.
- endpointId: 01
- application: 46
- manufacturer: _TZE200_rmymn92d
- model: TS0601
Driver is set to "lift" and "reverse".
The only issue is setting position to less than 37. TargetPosition shows correct, but the possition starts to change to final positions 63-100...
TargetPosition 0 = final Position 63
TargetPosition 37 = final Position 100
Setting position to 37-100 leads to correct final position.
The strangest thing is that I have one more motor which works absolutely perfect. The driver is only set to "forward" because of different way of closing the curtain.
Hello everyone, I have tried several versions of this driver with my tuya based plantation shutters motors (Search blindsmart plantation shutter motor on amazon to see which ones I am talking about. I cannot yet post links to the forum.)
The blinds work but are unreliable and there are many errors in the logs. I am very new to the Hubitat ecosystem and I really appreciate any assistance the community could provide. My device data is:
Device Data
| Application | 4D |
|---|---|
| In Clusters | 0004,0005,EF00,0000,ED00 |
| Manufacturer | _TZE284_myikb7qz |
| Model | TS0601 |
| Out Clusters | 0019,000A |
| Software Build | null |
Some of the log errors are:
abnormal case : 1127
dp = 1127
catchall: 0104 EF00 01 01 0040 00 E174 01 00 0000 02 01 00356704000100
dp = 1127
catchall: 0104 EF00 01 01 0040 00 E174 01 00 0000 02 01 00346704000100
read attr - raw: E17401000012DFFF4205C3575C2F11, dni: E174, endpoint: 01, cluster: 0000, size: 12, attrId: FFDF, encoding: 42, command: 0A, value: 05C3575C2F11
read attr - raw: E174010000180100204DE2FF2038E4FF2000, dni: E174, endpoint: 01, cluster: 0000, size: 18, attrId: 0001, encoding: 20, command: 0A, value: 4DE2FF2038E4FF2000
catchall: 0000 0013 00 00 0040 00 E174 00 00 0000 00 00 0374E1316822197738C1A480
abnormal case : 1127
dp = 1127
catchall: 0104 EF00 01 01 0040 00 E174 01 00 0000 02 01 00296704000100
read attr - raw: E17401000012DFFF4205B8505C2F11, dni: E174, endpoint: 01, cluster: 0000, size: 12, attrId: FFDF, encoding: 42, command: 0A, value: 05B8505C2F11
1 Like
Hi Dan,
Thank you for reporting the issue!
I've also observed another problem that appears with the latest HE platform versions when using this driver... 
When I have an update I will notify you.
1 Like
'ZemiSmart Zigbee Blind' community driver version 3.5.0 - 2025-03-08 8:57 PM is now available for manual update from GitHub :
- secured settings.mode and settings.direction for null values;
- added checkDriverVersion();
- added TS0601 _TZE284_myikb7qz; _TZE200_9p5xmj5r Hiladuo Motorized roller shade; Lidl _TZB000_42ha4rsc
- added _TZE204_57hjqelq _TZE200_axgvo9jh _TZE200_zxxfv8wi _TZE204_lh3arisb _TZE200_eegnwoyw _TZE600_ogyg1y6b _TZE200_cpbo62rn _TZE200_libht6ua _TZE200_zvo63cmo _TZE200_g5xqosu7 _TZE204_g5xqosu7 _TZE204_r0jdjrvi _TZE200_p2qzzazi _TZE200_clm4gdw4 _TZE200_2vfxweng _TZE204_2rvvqjoa _TZE200_zyrdrmno _TZE200_p6vz3wzt _TZE200_jhkttplm _TZE200_5nldle7w _TZE200_eevqq1uv _TZE200_icka1clh AM43; (not tested!)
- hopefully fixed _TZE200_pw7mji0l setlevel position;
- added TS011F manufacturers _TZ3000_8h7wgocw _TZ3000_e3vhyirx _TZ3000_yruungrl _TZ3000_jwv3cwak _TZ3000_74hsp7qy _TZ3210_dwytrmda
@dan18 please try this version and let me know what works and what not... The Blindsmart plantation shutter motor TS0601 _TZE284_myikb7qz is a new device and I didn't find any information for it.
Thanks a lot for working on this! I have four of these devices and they all were able to work with the dev version for a few minutes. However, after several minutes of idle they became unresponsive and no longer move until I reset the devices and re-add to HE.
When they did work, I had to send commands several times before each device would respond. Once the device responded, however, it would reliably open/close within a second of the command being sent. In the time it took me to program a Zen37 remote's button to open the shutters, they all became unresponsive again.
I am not sure if this helps, but when they do work they will make a clicking sound in response to the command. After they make that sound, I know that the next command that is sent will be responded to correctly.
I had enabled debugging logs on a few of the devices and this is a snippet from one of the devices that stopped responding. If I can do any test routines or provide more specific logs to help please let me know.
dev:1212025-03-08 03:42:22.723 PM
debug
MBR Left Window Left Plantation Shutter parse (103): ZM25TQ/AM43 Up limit was reset (direction:1) (raw:0)
dev:1212025-03-08 03:42:22.721 PM
debug
MBR Left Window Left Plantation Shutter parse: descMap=[raw:catchall: 0104 EF00 01 01 0040 00 E1A1 01 00 0000 02 01 004E6704000100, profileId:0104, clusterId:EF00, clusterInt:61184, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:E1A1, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:02, direction:01, data:[00, 4E, 67, 04, 00, 01, 00]]
dev:1212025-03-08 03:40:49.375 PM
debug
MBR Left Window Left Plantation Shutter parse: Not a Tuya Message descMap=[raw:E1A1010000180100204DE2FF2038E4FF2000, dni:E1A1, endpoint:01, cluster:0000, size:18, attrId:0001, encoding:20, command:0A, value:4D, clusterInt:0, attrInt:1, additionalAttrs:[[value:38, encoding:20, attrId:FFE2, consumedBytes:4, attrInt:65506], [value:00, encoding:20, attrId:FFE4, consumedBytes:4, attrInt:65508]]]
dev:1212025-03-08 03:40:49.240 PM
debug
MBR Left Window Left Plantation Shutter Tuya MCU Version Respinse : [00, 35, 40]
dev:1212025-03-08 03:40:44.148 PM
debug
MBR Left Window Left Plantation Shutter ZDO cluster 0013 device announcement Device network ID: E1A1, Capability Information: 80
dev:1212025-03-08 03:40:29.993 PM
debug
MBR Left Window Left Plantation Shutter updateWindowShadeArrived: position=1
dev:1212025-03-08 03:40:29.992 PM
warn
MBR Left Window Left Plantation Shutter endOfMovement() timeout!
dev:1212025-03-08 03:40:15.029 PM
debug
MBR Left Window Left Plantation Shutter sendZigbeeCommands (cmd=[he cmd 0xE1A1 0x01 0xEF00 0x00 {6EBE0104000100}, delay 2000])
dev:1212025-03-08 03:40:15.028 PM
debug
MBR Left Window Left Plantation Shutter sendTuyaCommand: dp=0x01, dpType=0x04, fnCmd=0x00, fnCmdLength=2
dev:1212025-03-08 03:40:15.006 PM
debug
MBR Left Window Left Plantation Shutter sending command open (0), direction = reverse (1)
dev:1212025-03-08 03:40:00.329 PM
debug
MBR Left Window Left Plantation Shutter sendZigbeeCommands (cmd=[he cmd 0xE1A1 0x01 0xEF00 0x00 {F5280104000100}, delay 2000])
dev:1212025-03-08 03:40:00.327 PM
debug
MBR Left Window Left Plantation Shutter sendTuyaCommand: dp=0x01, dpType=0x04, fnCmd=0x00, fnCmdLength=2
dev:1212025-03-08 03:40:00.312 PM
debug
MBR Left Window Left Plantation Shutter sending command open (0), direction = reverse (1)
dev:1212025-03-08 03:39:54.446 PM
debug
MBR Left Window Left Plantation Shutter sendZigbeeCommands (cmd=[he cmd 0xE1A1 0x01 0xEF00 0x00 {4A420104000100}, delay 2000])
dev:1212025-03-08 03:39:54.444 PM
debug
MBR Left Window Left Plantation Shutter sendTuyaCommand: dp=0x01, dpType=0x04, fnCmd=0x00, fnCmdLength=2
dev:1212025-03-08 03:39:54.428 PM
debug
MBR Left Window Left Plantation Shutter sending command open (0), direction = reverse (1)
dev:1212025-03-08 03:39:49.162 PM
debug
MBR Left Window Left Plantation Shutter sendZigbeeCommands (cmd=[he cmd 0xE1A1 0x01 0xEF00 0x00 {BF4A0104000100}, delay 2000])
dev:1212025-03-08 03:39:49.161 PM
debug
MBR Left Window Left Plantation Shutter sendTuyaCommand: dp=0x01, dpType=0x04, fnCmd=0x00, fnCmdLength=2
dev:1212025-03-08 03:39:49.148 PM
debug
MBR Left Window Left Plantation Shutter sending command open (0), direction = reverse (1)
dev:1212025-03-08 03:35:29.919 PM
debug
MBR Left Window Left Plantation Shutter updateWindowShadeArrived: position=1
dev:1212025-03-08 03:35:29.918 PM
warn
MBR Left Window Left Plantation Shutter endOfMovement() timeout!
dev:1212025-03-08 03:35:14.922 PM
debug
MBR Left Window Left Plantation Shutter parse (01): stopping (DP=1, data=1)
dev:1212025-03-08 03:35:14.905 PM
debug
MBR Left Window Left Plantation Shutter parse: descMap=[raw:catchall: 0104 EF00 01 01 0040 00 E1A1 01 00 0000 02 01 004C0104000101, profileId:0104, clusterId:EF00, clusterInt:61184, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:E1A1, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:02, direction:01, data:[00, 4C, 01, 04, 00, 01, 01]]
dev:1212025-03-08 03:35:14.401 PM
debug
MBR Left Window Left Plantation Shutter parse (01): stopping (DP=1, data=1)
dev:1212025-03-08 03:35:14.384 PM
debug
MBR Left Window Left Plantation Shutter parse: descMap=[raw:catchall: 0104 EF00 01 01 0040 00 E1A1 01 00 0000 02 01 004C0104000101, profileId:0104, clusterId:EF00, clusterInt:61184, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:E1A1, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:02, direction:01, data:[00, 4C, 01, 04, 00, 01, 01]]
dev:1212025-03-08 03:35:14.238 PM
debug
MBR Left Window Left Plantation Shutter parse (01): stopping (DP=1, data=1)
dev:1212025-03-08 03:35:14.218 PM
debug
MBR Left Window Left Plantation Shutter parse: descMap=[raw:catchall: 0104 EF00 01 01 0040 00 E1A1 01 00 0000 02 01 004B0104000101, profileId:0104, clusterId:EF00, clusterInt:61184, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:E1A1, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:02, direction:01, data:[00, 4B, 01, 04, 00, 01, 01]]
dev:1212025-03-08 03:35:14.114 PM
debug
MBR Left Window Left Plantation Shutter stopPositionReportTimeout(): unscheduling endOfMovement timer
dev:1212025-03-08 03:35:14.114 PM
debug
MBR Left Window Left Plantation Shutter updateWindowShadeArrived: position=1
dev:1212025-03-08 03:35:14.113 PM
debug
MBR Left Window Left Plantation Shutter updatePosition(1): arrived!
dev:1212025-03-08 03:35:14.112 PM
debug
MBR Left Window Left Plantation Shutter isWithinOne:true (position=1, lastPosition=0)
dev:1212025-03-08 03:35:14.110 PM
debug
MBR Left Window Left Plantation Shutter updatePosition(): position=1
dev:1212025-03-08 03:35:14.109 PM
debug
MBR Left Window Left Plantation Shutter updateWindowShadeArrived: position=1
dev:1212025-03-08 03:35:14.095 PM
debug
MBR Left Window Left Plantation Shutter parse (03): arrived at position 1
dev:1212025-03-08 03:35:14.093 PM
debug
MBR Left Window Left Plantation Shutter parse: descMap=[raw:catchall: 0104 EF00 01 01 0040 00 E1A1 01 00 0000 02 01 004A0302000400000001, profileId:0104, clusterId:EF00, clusterInt:61184, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:E1A1, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:02, direction:01, data:[00, 4A, 03, 02, 00, 04, 00, 00, 00, 01]]
dev:1212025-03-08 03:35:09.675 PM
debug
MBR Left Window Left Plantation Shutter stopPositionReportTimeout(): unscheduling endOfMovement timer
dev:1212025-03-08 03:35:09.664 PM
debug
MBR Left Window Left Plantation Shutter stopPositionReportTimeout(): unscheduling endOfMovement timer
dev:1212025-03-08 03:35:09.663 PM
info
MBR Left Window Left Plantation Shutter is closed
dev:1212025-03-08 03:35:09.661 PM
debug
MBR Left Window Left Plantation Shutter updateWindowShadeArrived: position=0
At 3:40:44.148 PM the device has rejoined the Zigbee network.... The last Zigbee message received before this event was at 03:35:14.922 PM.
It seems that a previous command might be causing the device to reset itself, or perhaps the device expects a specific command that wasnât sent. The fact that the log shows âZM25TQ/AM43 Up limit was resetââlikely using the same Tuya Data Point for a different functionâindicates that this device behaves differently from other known motor devices.
As a test, try refraining from sending any commands through the deviceâs web page. Instead, operate the shutter motor from its remote and check whether the device remains connected and continues to log Zigbee messages in real time. This will help determine whether certain driver commands are causing the device to freeze or reset, though it wonât necessarily reveal the correct commands.
To find out the correct commands, youâll need a Tuya Zigbee hub and a Tuya Cloud developer account to look up the specific âTuya Data Pointsâ for this device. Or, we should wait for the ZHA/Z2M community to investigate and publish a solution for Home Assistant, but that may take months.
Another option is to contact the Amazon seller to ask if this device can be used with a Tuya Matter Gateway and exposed to other home automation systems. However, sellers often lack the technical expertise to provide answers to such questions...
I just purchased a Tuya hub and I have a developer account for Tuya but I am not sure how to get the Tuya data points for the devices. Do you know how?
I unfortunately do not have a remote for the devices⌠the boxes just had the motors and the solar panels.
One interesting thing is that even when paired with the Tuya hub the device will sometimes only respond on the second command. This is with the Tuya hub only a few feet from the device, so I donât think it is a reception issue.
Thanks again for your help!
I use the manual method (at the bottom of the linked article) :
Here are the data points I was able to retrieve from your instructions:
"1":"Control"
"2":"Curtain position setting"
"3":"Current curtain position"
"5":"Motor Direction"
"10":"Total Time"
"11":"Situation_set"
"12":"Fault"
"13":"Battery Percentage"
"16":"Border"
"19":"Best Position"
"101":"Child Lock"
"102":"set mode"
"103":"Motor operating mode"
I was also able to locate the instruction sets and status sets in the device debugging menu on the Tuya developer platform:
Stantard Status Set:
control Enum
{
"range": [
"open",
"stop",
"close",
"continue"
]
}
percent_control Integer
{
"unit": "%",
"min": 0,
"max": 100,
"scale": 0,
"step": 1
}
percent_state Integer
{
"unit": "%",
"min": 0,
"max": 100,
"scale": 0,
"step": 1
}
control_back_mode Enum
{
"range": [
"forward",
"back"
]
}
time_total Integer
{
"unit": "ms",
"min": 0,
"max": 120000,
"scale": 0,
"step": 1
}
situation_set Enum
{
"range": [
"fully_open",
"fully_close"
]
}
fault Bitmap
{
"label": [
"motor_fault"
]
}
battery_percentage Integer
{
"unit": "%",
"min": 0,
"max": 100,
"scale": 0,
"step": 1
}
border Enum
{
"range": [
"up",
"down",
"up_delete",
"down_delete",
"remove_top_bottom"
]
}
position_best Integer
{
"unit": "%",
"min": 0,
"max": 100,
"scale": 0,
"step": 1
}
Standard Instruction Set:
Code Type Values
control Enum
{
"range": [
"open",
"stop",
"close",
"continue"
]
}
percent_control Integer
{
"unit": "%",
"min": 0,
"max": 100,
"scale": 0,
"step": 1
}
control_back_mode Enum
{
"range": [
"forward",
"back"
]
}
border Enum
{
"range": [
"up",
"down",
"up_delete",
"down_delete",
"remove_top_bottom"
]
}
position_best Integer
{
"unit": "%",
"min": 0,
"max": 100,
"scale": 0,
"step": 1
}
If I can do anything else to help please let me know!
1 Like
Hi Dan,
This is exactly the information that I needed, thank you! 
In the dev. branch update 3.5.1 - 2025-03-10 11:50 PM I have replaced the open and close commands with the TS0601 _TZE284_myikb7qz commands that I suppose are used instead. I can't be 100% sure about this, so let me know if open/close works.
In this version I have also implemented some changes planned quite long time ago :
- added Ping() command;
- added Refresh() command;
- finally replaced the misused Presence capability w/ healthCheck !
Use the Ping() command to check whether the Zigbee communication to your device is stable :
The healthStatus by default is passive - the driver expects to receive at least one Zigbee message from the device in a 3 x 4 = 12 hours period.
For a test, you can enable the 'Advanced Options' and change the healthCheck method to be active polling, every 10 minutes for example :
You can leave this frequent polling for a day and then observe the logsâis the Zigbee communication stable all the time, or are there timeouts?
(frequent polling will deplete the battery much faster, of course, but it will be beneficial to have the 24 hours picture).
Increase (also temporarily) the events history size :
Thanks for another update! I was able to successfully test the open/close functionality and it worked exactly as desired. There is an error in the logs for each device that is repeated a few times, but I am not sure what the cause is... especially given that the blinds function as expected with the development driver. The error seems to repeat twice each time it is posted.
Here is the error:
dev:1312025-03-11 01:29:59.881 PM
error
groovy.lang.MissingMethodException: No signature of method: user_driver_amosyuen_ZemiSmart_Zigbee_Blind___Dev_718.logTrace() is applicable for argument types: (org.codehaus.groovy.runtime.GStringImpl) values: [Tuya check-in message (attribute 0001 reported: 4D)] on line 549 (method parse)
Thank you for the feedback and for the cooperation, @dan18 ! I have fixed this exception in the last update of driver version 3.5.1 - 2025-03-11 8:00 PM
I will not be pushing this for automatic updates through HPM for now.
The latest version can still be updated from HPM manually - use the 'Repair' function.
