Well, I'm in a pickle of a mess. I have had these Zemismart roller shade motors operating on Hubitat for about a year now. Over the past 2 months one of them mysteriously just decides to open all on its own. I've removed it and rejoined it to the hub (zigbee) about 10 times. Still the problem persists. I have finally captured in the logs what I believe is the culprit.
Can anyone help me understand what the log entry for "Remote Opening" or "DP=1031" means, outside of the obvious. If remote opening is because the "BT remote" opened it, I assure you, that is not the case. Also, this particular shade is installed in a double window case with another one just next to it and that motor never has any problems. In fact, all 9 others I have installed, never fail, just this one.
Please if anyone has deep understanding of the Tuya commands used in the driver and how to prevent this from occurring it would be a tremendous relief.
It appears as though "remote opening" is triggered by the BT remote. I even took the batteries out of the remote some time ago, aside from the test above, so I can't figure how it would receive a BT remote command.
@s1godfrey can you please obtain and post your device fingerprint? ( temporary switch to HE inbuilt 'Device' driver and hit 'Get Info' button.
So far I have identified 20 (twenty!) different variations Zemismart blinds/shades/motors and most of them have slightly different behaviors. Some models have reverse position reporting, others have reversed Open/Close/Stop commands, others report the final and the current positions using one and the same Tiya command (dp), etc, etc..
Compare the problematic device 'Manufacturer' value to the other blinds that work OK. Is it the same? It is not unusual for Tuya products sellers to ship different models (or different firmware versions) even when in one and the same purchase order.
Yes, this is the 21st different model/manufacturer of Zemismart motors...
Are all of your motors the same 'Manufacturer' ? Or the Manufacturer ID of the one that behaves erratically differs from the rest that work OK?
They all report the same data. And were bought at different times, some several months apart from each other. The one that is acting up was the first one purchased.
This is the one from Zemismart site order history. Purchased Dec 7th 2020. I bought both the 'bad' one and the 'good' one for a double window as a set.
Zemismart Tuya Zigbee Roller Shade Motor For 38mm tube SmarThings Alexa Echo Google Home Control Electric Engine Shutter Rod
Providing the Manufacturer ID is the same and the firmware version ( shown as 'Application' - in your case 52) are the same for all your motors, then it looks like a hardware problem ... The first thing to check is usually the power supply/battery. But your model seems to have the AC power supply built-in, so it will be not very easy to check whether the power supply is acting up.
Aside from the actual cause, could you suggest a workaround to post adjust the motor position when compared to its right side motor? These are controlled as a pair using a 'shade control' app created to make groups for shades like these:
/* Shade Controls
*
Copyright 2021 Hubitat Inc. All Rights Reserved
*/
definition(
name: "Shade Controls",
singleInstance: true,
namespace: "hubitat",
author: "Bruce Ravenel",
description: "Create shade automations",
category: "Convenience",
I've tried with Webcore to create a piston that triggers when 'shade1' position or even windowShade attribute becomes different than 'shade2'. But it works sometimes, not all.
@s1godfrey , this one seems to be the same motor I use. I´ll post its fingerprint and if it is really the same you may try the driver I posted. Mine uses battery, and its only problem is the battery not being reported, differently of yours that uses AC.
The fingerprint:
endpointId: 01
application: 44
softwareBuild:
inClusters: 0000,0004,0005,EF00
outClusters: 0019,000A
model: TS0601
manufacturer: _TZE200_5sbebbzs
If it don´t work, you will know its a hardware problem...
So this is the weirdest occurrence. I have an automation to open all of the 6 roller blind motor driven shades in the house each morning and to close them all at night. As the previous post show, one of these has been problematic and strays away from the pack, so to speak.
But this morning, all of my shades, except the problem one decided to not work. And the logs show that they all reported as open (100%) and executed the TUYA command. Yet, physical all, except for the supposedly 'bad' one failed to physically respond.
I'm in the same boat, but not as bad.
I have 5 motors all the same model, from the same supplier. Some report their position correctly. Others work properly but only ever report a state of opening or closing.
It is not uncommon for Tuya products suppliers to ship different models/modifications, even in one and the same purchase order. So for me it is possible that this may be yours and (less likely) @s1godfrey cases.
Can you double-check again if there are any differences in the 'Manufacturer' and 'Application' values between your blinds/motors?
The 'Manufacturer' is what explicitly identifies a Tuya product. The 'application' is the firmware version.
As an example, saying 'my Zemismart blinds model is AM43' doesn't uniquely identify the device. There are at least 3 different AM43 models with different Tuya commands implementation.
The identified different models (manufacturers) of Zemismart Rollers/Blinds/Shade Motors is now increased from 20 to 24, each of these may have potentially slightly different commands set and respectively slightly different behavior. There are also about a dozen modifications of the "ZemiSmart Zigbee Blind" driver for HE, every mod patched to work fine for just one of the models, but not properly working for the other models.
I've been working recently on an attempt to improve this driver to support all of the different types of Tuya/Zemismart blinds. If this activity is successful, the final goal is to merge these changes into Amos Yuen's driver, which seems to be the most popular and available in HPM.
The temporary link to the work-in-progress driver mod is here. If you have time, you can test it and please let me know if it works for your model(s) ( 'Manufacturer' )
Not so much here. I changed to the new driver and then trouble started. Now it only moves up 2 or 3 steps or down 2 or 3 steps. I switched back to old driver, no change. I did wipe device using cleaner, nothing. I unpaired the device and repaired, same results.
Can anyone please tell me how to completely wipe the zemismart zigbee tubular motor model: ZM25TQ back to factory defaults.
I tried press 5x quickly, still paired. I tried hold for several seconds, still paired. I tried unplug AC, hold on plug-in, still paired. By still paired, I mean that it will move motor upon command, not correctly, but it still responds from hubitat. So, its definitely not reset to factory defaults.
