Curtain Rod Retrofit Options

Automation Central Automation Hardware
#1

So last year at Black Friday, I splurged a bit and finally pulled the trigger on some of the Switchbot curtain motors since they seemed to be the only ones on the market that allow for a retrofit of my existing curtain rods. Fast forward a couple of months and while they do work, they are a bit loud, their solar panels (mainly their mounting method) leave much to be desired, and as a result their battery life is not great. Mix that with one of them just not appearing in the app anymore for some reason even though I have a hub (yay Bluetooth) and I am looking for other options.

Looking at the usual places I ran across this which looks promising and I was wondering if anyone had any experiences with it or another product. I was also wondering if anyone has got it working inside HE or if it will be supported on CORE.

In case link is broken: Zemismart ZM85EL-2Z

1 Like
#2

It’s not yet supported on CORE, but it is probably a fairly simple one to add support for. With that said, since Tuya Zigbee devices have their own way of communicating it can sometimes be necessary to use a Tuya Zigbee gateway with a Zigbee traffic sniffer to get the right control commands if they are non-standard even for Tuya. There are other Zemismart curtain motors which are supported, so chances are the driver would only need minor modifications.

Zigbee2MQTT

EDIT: A quick check in the tickets show this from 6 days ago: [New device support]: Zemismart Curtain Robot motor ZM85EL-2Z · Issue #11251 · Koenkk/zigbee2mqtt (github.com)

2 Likes
#3

Finally got the curtain motor in and so far so good with this HE Driver:

There are some things to keep in mind though. You MUST have a solid run for your rods as, at least for my rods, the motor was not powerful enough to make the jump between the telescoping sections and if buying new rods try and get 1 inch rods. Also the driver has a few bugs in it that are not functionally relevant, but could be improved. Finally, AFAIK, you can only change the limits of open and close with the included remote, those settings do not seem to be exposed to ZigBee for some reason. Other than that it has been great, decently quiet, a bit slow but I rather have it quiet than fast.

Comparing it pound for pound to the Switchbot Curtain it replaced in no particular order:

  • No tug to open (I see this as a benefit as the tug to open is a gimmick IMO, since if you are getting up to tug you are going to be disappointed with how slow it is to open)
  • Harder and less reliable to install (could be improved later since the motor and the mount are modular)
  • Could use a better solar panel mount (currently just tape and no clear place on the motor to tape it to)
  • Much lengthier body so if your rail is mounted a bit higher like mine you can still hang the solar panel off of the motor and be useful (Switchbot solar panel was aiming straight at the wall)
  • Oh the ZigBee, and this is a big one, the BT and cloud setup of Switchbot I thought I could deal with, but I could not, it was so unreliable it is basically unusable. ZigBee paired within 30 seconds and has been extremely responsive through Alexa and the device page.
  • Cheaper than Switchbot by a significant margin (I paid $85 for 1 motor, 1 solar panel and 1 remote). Switchbot is $100 for the motor, $20 for the remote which is worse than Zemismart’s, $20 for the solar panel, and $40 for their hub mini. So for twice the cost you get half the product IMHO.
3 Likes
#4

BTW, if anyone is in the market for x3 Switchbot Curtain robots with 3 sets of grommet kits and 3 sets of solar panels just let me know. Probably not after reading my post above but I thought hey, no harm in asking.

#5

I’ve been thinking about getting one of these and I have almost bought them a few times now. One of my hesitations has been if they would work with HE. Thanks for confirming they do :+1: Something else was, will they work with my rod. I see you recommend the 1 inch rod (25mm). My current telescopic rod is 22mm and 19mm. Do you reckon I need to get a bigger rod to use this motor?

#6

They say it is compatible with 20mm-28mm, you might be able to get way with fudging the rollers with some electrical tape to make up the difference which is what I did before buying 1 inch curtain rods. It worked fine, but the issue of not being able to go between telescoping section was still there so I killed 2 birds with 1 stone by getting new rods.

1 Like
#7

I had already foreseen the transition between the two sections to be an issue, so I had already formed a plan to eliminate that. My blinds open from the centre to the sides, so I would just make sure to cut the big rod so that the transition occurs in the centre of the rod. I was already thinking about how to make the motor take a smaller rod (electrical tape etc), but it doesn’t sound right to me. Maybe I should just go for a bigger rod :wink:

#8

That is exactly what I did with my new rods, previously I had a 3 section rod which had the problem, but I just found one that had 2 sections and spanned the gap.

Regarding smaller rods, you also could 3d print a larger roller to accommodate the smaller size. You would not be adjusting the motor side of the roller just the other passive roller.

These are the rods I got and they seem pretty rock solid and then I just reused the old finials.

1 Like
#9

For anyone that has automated curtains, what are you using to automate them? I found this set of nodes that seems super powerful and I have it working, but I only now just realized that it is meant for vertical blinds not horizontal curtains. Anyone know of nodes that takes the latitude, longitude, and the orientation of the window to open and close the curtain based on the sun position?

#10

@markus If you want another project with some teeth to it, this would be a great candidate. Kind of like the node I mentioned above, but instead for horizontal curtains.

My initial thoughts building on what this node already does.
Given conditions:

  • Lat,Long
  • Orientation of the window
  • Distance to the bottom of the window
  • Distance to the top of the window
  • Width of the window
  • Direction that the curtains close
  • Minimum distance the curtain motor can travel (might have issues translating between true distance (needed for calculation) and percentage (needed for adjusting the motor))
  • How much the sun can encroach into the room (length on the floor, probably measured perpendicularly)

What to do:

  • Calculate the azimuth of the sun for the given lat,long
  • Split the width of the window into minimum movements of the motor and calculate how far the sun is coming into that room for that smaller width
  • If any of those segments’ projections are longer (probably measured perpendicular to the window not true length) then adjust the curtain to block just that segment
  • Repeat on some sort of interval (either timer based or significant change based)

A lot of this I imagine is already calculated by the nodes I referenced above. I havent dug into their github yet, but I wonder if it could be adapted easily.

Aside: In writing this I thought of another interesting application. A lot of curtain motors have a solar panel attached. I wonder how complicated it would be to input the distance from the window and the distance from either the bottom or top of the window and then be able to make it so that the solar panel always tries to follow where the sun is coming through. It would likely be a range, and it would be fighting with the programming above. But even if the “collisions” were not handled. Turning the “solar mode” on when away and the “comfort mode” when present would be interesting.

Upon further thought, this could actually be the exact same as the first program, except the height of the “window” is the height of the intersection between the window and the solar panel, the width should stay the same, and the distance into the room is just the distance from the window to the solar panel.

#11

While I do need things to keep myself occupied with which are not “just” developing more for CORE, I don’t have a clear picture on how to implement this properly. Maybe some inspiration will strike, but no promises :stuck_out_tongue: If you have some initial flows doing, parts of, this maybe that would help to understand the problem better? Or find something written in some other languages for some other platform? I happily read most any programming language describing a problem than parsing non-computer languages…
My own motorized curtains are opening/closing from both sides at once without ability to only choose to open/close one side. Apart from time-based they are currently manually controlled or linked to lights being on/off, with some control based on lux in one location.

#12

Yeah the closest I have found was those blind control nodes. But I will take a look at their repo and see if I can glean the important functions.

This is the closest file to the action I am proposing:

And here is the documentation for using it. It includes some useful figures for the sun calculations.

1 Like
#13

image
Basically, and this is ripped from their documentation, instead of a side view, a top down view (technically it has to be a 3d view but for sake of argument and clarity of how the curtains move a top down view is better) and then adjust the curtains to the path that the sun takes throughout the day and projects into the room.

These nodes being used for blinds simplifies it incredibly since all it cares about is if the current azimuth of the sun is between the start and end of the window (90 degrees each side of the orientation for simplicity sake). Versus what I am describing which in effect is breaking the window into smaller (by width only) windows and checking those smaller segments (I assume with the same math) and then adjusting accordingly. Thinking of it in terms of smaller windows that make up a big window actually should make the calculation far easier.

Actually, upon further thought, I am not convinced if as written is “simplified”, it might just be different. It might be calculating smaller “windows” as well, but with a constant width, variable height segments, versus my idea which needs variable width, constant height segments.

Actually on further thought again, you combine those two and you basically have a targeting algorithm with a definable grid size, but back to the problem.

Maybe instead of checking for if it is within the width and then getting the depth into the room, we can check if it is within the height (backtrack from depth into the room and lower and upper heights to get the angle range and compare to current angle (anything shallower I am thinking would extend into the room further)) and then from there check what segment(s) of the width it is entering through:

Instead of

blindHeight = (tan(altitude)*lengthOnFloor) - bottom

it could be

curtainWidth = windowWidth - (lengthOnFloor / tan(unsure how to express this angle in terms of its relation between window orientation and sun position (maybe their difference? not sure)))
(I think I am missing something to account for the opening from the left or right as well, but I cannot figure out what exactly right now)
EDIT:

  • NVM, I do not think this actually works, the triangle used does not have a reference point on the window so it can float anywhere in there, so calculating the base is not very helpful.

  • This works with the blind because it intercepts with the floor by definition, hence it has the reference of the bottom height of the window to calculate the blind position. I cannot find any point of reference in this curtain example however.

  • Also, I apologize for the arctan/tan mixup, it was like 3am in bed with my phone when I got this inspiration and when I took a second look and actually drew it out, I found the error, though my logic was still correct, I just called the wrong function.

but it must already be calculated since “in the window” is determined currently, though as I understand it that is just a comparison between sun azimuth and window azimuth range.

Yeah that actually seems like it might be doable, it might even be the exact same math used in the nodes I listed above, but just used in a different way. No clue how it would be done in a NR environment though (outside of functions, context variables, and tons of headaches), it seems like something that would have to be done in a traditional programming environment due to the math involved and the complex set of checks.

Also this is turning out to be a very interesting problem, you could reframe it as a grid and the coordinate you are trying to block (or hit) (grid steps defined by the accuracy of the motors) as (x,y), (curtainWidth, blindHeight) and then theoretically block out only certain parts if you had like a x,y motor array that could stretch and contract a cloth across your window. Hell, this sort of algorithm is probably used in stuff from weapon systems to 3d printing…what have I stumbled upon…

2 Likes
#14

So I did a bit more thinking on this and a bit more observation of the way the sun falls into the room, and I do not think it is as easy as I make it out to be. The sun cast into the room is always parallel to the window at its furthest point, therefore I cannot selectively block the curtain for the offending regions simply based on distance into the room because the entire region is that far into the room. You could however protect parts of the room, say the bed, but let it cast as far as it likes beyond the bed or to the side (depending on layout), however I have not figured out a way to do that mathematically.

I did however get something working well with the existing nodes using the blind control node, and the restrict sunlight setting. Every setting is setup just like you would a blind however I set the min delta to be the full range, in my case 100, so that it can either be open or closed, the kicker here is that it ONLY closes if the sun is being cast into the room past my length. This is something that the minimize and maximize sunlight setting does not do, which as far as I can tell only detect and change based on azimuth, not azimuth AND altitude.

1 Like
#15

Out of curiosity, has anyone else gone down this road and purchased some ZM85EL-2Z’s and connected to Z2M? I have mine connected but boy are they weirdly unreliable. I installed it using this the external converter defined by this post:

And it seems to work for a bit, then you give it some time and they stop responding to commands. After I tried “waking” them up by reading something simple like time from the dev console, they start responding again, but again after some time they stop again. I am wondering if it is something as simple as I need to setup a reporting method to keep it alive, but as I have never messed with external converters I do not know.

Any ideas that people can provide would be appreciated.

P.S. Their LQI’s hover around 100 according to their exposed variable so not great but also not terrible, and 255 according to the map, but weirdly it seems that every battery device that I have seems to have a 255 connection (they are all connected to various Iris 3210-L/L2’s so it might just be a bug with those devices?)

#16

The people that quoted my blinds were talking about zemismart. I haven’t been able to to check them out yet. Or consider them. Will have to check out the code, maybe we can make heads or tails of it. So they just keep falling off?

#17

According to the map they are still connected and appear to be reporting (18 minutes ago for one), but they just do not respond reliably to commands.

#18

Do you have anything that can snif the traffic?

#19

unfortunately no, do you have any recommendations?

#20

I’ve never liked sniffing zigbee traffic. You need wireshark and a cc2531 dongle flashed with the correct firmware. Here is the link to the project.

andrebdo/wireshark-cc2531: Wireshark extcap interface for the TI CC2531 USB dongle (github.com)

I do know that @LosinIt created one not so long ago when he was sniffing out the issues with the iris sensors. I’m not sure which project he used for it, but the concept is pretty much the same. Maybe he’ll offer you some input. If you can also offer up some data, maybe I can get @markus to have a look at it to see if it can be improved. Possibly some logs can go a long way in this case. It’ll be beneficial to work that out as others are likely to have the same issues.