New Device: Roller Shade Motor from Zemismart (first draft working accessory code attached)

[samsawyer]

Device Description
Zemismart Roller Shade Motor (one of these things), but possibly generalizable to a lot more Tuya curtain-type devices. They show up in iot.tuya.com as "Curtains" under product id q5ymhtoa6sdjymwx. As far as HomeKit is concerned, it's a window covering.

Current support
You'd hope that this would work transparently with SimpleBlinds or SimpleBlinds2, but it doesn't. Those accessories use dp 1 for control, and these devices use dp 1 for a control channel and dp 2 for position.
If you override cmdOpen to open, cmdClose to close and cmdStop to stop in config for SimpleBlinds, you can get them to mostly open/close, but they don't report position state properly at all under this work around, and you can't set or read positions other than open/close.

Device Schema
Example signature reported by the device is here (is something else needed here? not sure where to get a "schema"):
{"1":"open","2":0,"5":true,"7":"opening","10":0}
1 is control; 2 is position; 5 is control_back (whether or not the motor direction is flipped, I think; doesn't affect the logic described below). 7 looks like it should be position state, but seems largely useless (see below). Not sure what 10 is supposed to do.

Additional context
I worked up a plugin that deals properly with these devices; the file is attached here: ShadeAccessory.js.zip. (Is there a better way to stick a code file in than zipping it?) I've been using it successfully for a couple of days in my own Homebridge setup.

I used SimpleBlinds.js as a jumping-off point to figure out how to talk to HomeKit about a window covering, but these devices have a significantly different set of dps, states and behaviors than SimpleBlinds dealt with.

This is my first foray into HomeKit/homebridge or really Node.js programming, so there's possibly a lot of stuff that's been handled inelegantly in my code. Happy for any suggestions. If you'd like me to figure out how to turn this into a formal pull request let me know; you're also more than welcome to take this code and do whatever you'd like with it yourself.

The main wrinkles I had to figure out how to solve relative to the SimpleBlinds starting point are:

• Separate control and position channels (control uses the strings open, close, stop); position is 0 to 100 (but percent closed as opposed to HomeKit's percent open)
• You can command open or close by setting the control with no position, or you can command a specific position with stop but there seem to be some circumstances where commanding open or close plus a specific position doesn't work. So, if you want a full open (HomeKit sets target position to 100), you want to command open with no position specified; but if you want a partial open (say HomeKit sets target position to 35), you want to command stop plus position 65.
• The dp 2 position channel is used both to send a command and to read status — which leads to the problem that right after you command a position, the plugin then sees a change to that position, followed by another set of updates from the original position as it moves. That leads to flapping of the position state characteristic reported to HomeKit, etc. I sorted this out with a flag that ignores position messages for 2 seconds after commanding a change to avoid the flapping.
• Position is (usually) reported continuously, so you don't need to keep track of it with a time-to-open model the way SimpleBlinds does, so I took that code out.
• At least one of my devices occasionally stops reporting position during a move, which makes it hard to figure out when the move completed to update the position state characteristic to stopped. (dp 7 from the signature looks like it should be position state, opening or closing or whatever — but with my devices, it always says "opening," and is never updated as a changed value. So I'm not sure it's useful for anything.) I ended up keeping track of position state by building logic into the accessory object for the plugin, and set a configurable timeout to assume completion and report position state as stopped to HomeKit even if the device lost contact.

[samsawyer]

@iRayanKhan — just tagging in case you hadn't seen this.

[eecue]

Can confirm this works flawlessly with these other Tuya blind motors: https://www.aliexpress.com/item/4001045079168.html Great work @samsawyer!

[samsawyer]

@eecue Really glad to hear it's working for someone else. Thanks for taking the time to comment.

[iRayanKhan]

Would you like to make a PR? I'll merge it in :)

Edit: If so, make the accessory a new simpleblinds. I think we're in V3, but not sure.

[javimoralez]

Hi there, I'm barely new to the home bridge environment, I would love to make my motor to work, I have installed the pluggin but does not work with my motor, it is very similar to the one you have. Would you be so kind to explain me how can I get it to work with what you've done? @samsawyer thanks!

[samsawyer]

@iRayanKhan — sorry I lost track of the notifications on this issue. I just created a PR relative to the current 2.0.1 release. If you'd like it named something else other than SimpleBlinds3, I'm happy to change the name to whatever you want or to for you to adjust the naming as you prefer.

[samsawyer]

@javimoralez To use the file I included above, you would have also had to make simple edits to the index.js and config.schema.json files from the original along with copying in my original ShadeAccessory.js. But an easier way to do this would be to wait for the PR I just made to get merged into a new release, or if you want to be on the bleeding edge, grab the #282 PR right now for yourself.

[bubez81]

Hello sorry can't understand very well, how can I test this Simpleblinds3?

[bubez81]

Nevermind! Done...seems to work perfectly with position state too! Thank you

[bubez81]

except for this in the logs:
[6/5/2021, 8:40:45 AM] [homebridge-tuya] This plugin generated a warning from the characteristic 'Current Position': characteristic value expected valid finite number and received "NaN" (number). See https://git.io/JtMGR for more info.
[6/5/2021, 8:40:45 AM] [homebridge-tuya] This plugin generated a warning from the characteristic 'Current Position': characteristic value expected valid finite number and received "NaN" (number). See https://git.io/JtMGR for more info.
[6/5/2021, 8:40:45 AM] [homebridge-tuya] This plugin generated a warning from the characteristic 'Current Position': characteristic value expected valid finite number and received "NaN" (number). See https://git.io/JtMGR for more info.
[6/5/2021, 8:40:45 AM] [homebridge-tuya] This plugin generated a warning from the characteristic 'Current Position': characteristic value expected valid finite number and received "NaN" (number). See https://git.io/JtMGR for more info.

[blastoma]

Hi, @bubez81 !
Did you fix this?

[bubez81]

Nope, but I think it's not a real problem...only a warning that I can't understand

[blastoma]

@bubez81 you can fix this error like this:
getCurrentPosition(callback) {
this.getState(this.dpPosition, (err, dp) => {

You need to change dpAction to dpPosition

[bubez81]

Ah ok thank you!!