[RELEASE] Zemismart Zigbee Blind Driver

Hello @kkossev

This driver has been working great so far with my Hiladuo blind. Thanks ! However, I'd say once out of every 25-30 commands the blind will fail to move. Might be something wrong with the device itself, but I thought I would check with you if there is anything usable in the logs. I have a rule that partially opens the blind at 7:00 am and then fully opens it an hour later. This past Sunday, the partial open (to position 40) failed :

Device details:
image

Limits are set (including a stop near position 40 so that the blind will stop there when using the remote - wonder if it has anything to do with my issue?). Preferences:

Once in a while, I do get these warnings (just in case it provides any clues):

Cheers,

pj

EDIT : this is what logs look like when the command is successful (yes, we get up earlier on weekdays :wink: )

1 Like

Hi @hubitrep ,

The warning messages are harmless (these are Tuya periodic check-in messages), I will downgrade such warning to debug messages in the next update.

Can you try increasing the 'Position report timeout' value from 2500 to 3500 milliseconds ?
image

1 Like

UK here too. I've recently purchased 2 from AE (different models) - both 100%.

@menz

  1. https://www.aliexpress.com/item/1005003375223114.html?spm=a2g0o.order_list.order_list_main.5.cd191802PhNg2w

  2. https://www.aliexpress.com/item/1005002927293175.html?spm=a2g0o.order_list.order_list_main.11.cd191802PhNg2w

2 Likes

Done. Will report back in a few weeks. Thanks !

1 Like

thanks
thinking of getting one
what are there main differences between the two please??

Nothing as far as I can see, other than model number.

@kkossev Started noticing this on my AM43 the last couple of days

1 Like

Is it the same message you’re getting @rlithgow1

No very different than the one you posted

Hi @kkossev, reporting back as promised. In the past three weeks I think the blind failed to move only two or three times (I have RL rules that changes its position 4 times a day).

Looking at the logs, the main difference I see when the blind doesn't move is that the sendTuyaCommand() is not acknowledged by a parse (02): received target message (which usually comes less than a second following sending the command).

Could it be the battery-powered blind is sleeping or missing the command somehow? I wonder if it would it be possible to add some kind of retry logic in that case.

1 Like

How in the world did you get this connected to the Tuya Smart app so you could set the upper and lower limits? Maybe my instructions are messed up, or i am just doing something wrong, but it says to add the "Magpie app" and use that as a gateway in the tuya smart app, in order to add these blinds so i can set the upper and lower limit?

  1. That magpie app does not exist as far as i can tell
  2. There isn't even an option for zigbee blind motor in the tuya app, the closest thing is 'Curtain Motor Ball Chain BLE', or 'Curtain Motor Zigbee'. Neither of these sound right for blinds, but maybe its just poor translation.

I'd appreciate any help!

It could be possible (I have done something similar in Tuya wal thermostat driver), but it will be a rather complex implementation, because of the different behaviour of the different 'Zemismart' labeled devices. Some of them report the current position during the movement, and some do not...

In the logs sample above the device has confirmed the reception of the Close command . However, the timer expires 2500 milliseconds later. There is an additional delay of 800 milliseconds between sending the Close command and the confirmation received from the device.

So probably the 'Position report timeout' value is still low. The timings depend on the momentary status of the Zigbee network, so you can try increasing again the timeout value to 5000 or even 10000 milliseconds. Maybe the default timeout value is set too low, it works for me but I have a very stable Zigbee network and this problem doesn't show up with my blinds.

1 Like

image

This is a Zigbee connectivity system response message related to the routing tables, something that should be handled on HE system level.

I have added in the TODO list to downgrade the log message from warning to debug level.

1 Like

Never mind then, in my case at least it’s fairly straightforward to add redundancy in my RL setup.

I seem to have a very stable mesh as well but in any case it won’t hurt to try a longer timeout and see. Thanks!

I can't get the speed setting to work. 1-100 all give me the same speed but i dont see the current speed listed anywhere either

I'm hoping someone can explain this behavior on a recently installed TS0601/TZE200_r0jdjrvi Tuya curtain motor on the most recent driver. I am able to pair it with my C8 hub and it allows me to open and close the curtains once. It then becomes unresponsive. Any tips on how I can troubleshoot this?

Change the driver to the inbuilt one named ‘Device’.’ Click on the ‘Get Info’ button. If the device is connected to your C-8 , you will see the fingerprint in the live logs.

If nothing in the logs, pair the device again to the hub, keeping the Device driver. Click on the Get Info button several times again.

If the fingerprint logs stop to appear after some time, this is the Hubitat platform Zigbee connectivity problem, that is reported by different users for other devices as well.

Do you keep your old HE hub operational? Is the problem with the C-8 hub only?

I went back to my C5 hub. When I pair and switch the driver to 'Device' the logs show this entry every 3 minutes:

"Zigbee parsed:[raw:AAC40100001801002046E2FF2036E4FF2000, dni:AAC4, endpoint:01, cluster:0000, size:18, attrId:0001, encoding:20, command:0A, value:46, clusterInt:0, attrInt:1, additionalAttrs:[[value:36, encoding:20, attrId:FFE2, consumedBytes:4, attrInt:65506], [value:00, encoding:20, attrId:FFE4, consumedBytes:4, attrInt:65508]]]"

When I switch over to the zemismart driver there's no check ins.

Interestingly, it reports position in the logs when I manually move the curtain. Although it reports 'open' when the curtains are closed and 'closed' when they are open.

I would change this part of OP as it threw me for a loop. Setting the open/close limits can be done in hubitat now. I spent hours trying to figure out how to do it through the app and it just doesn't work there.

1 Like