Smartwings Zigbee shade position reversed

Is there a way of editing the driver file to fix this? I’m using the maker api and home assistant as my main hub, along with HA Alexa integration. The shade opens when I tell Alexa to close it and vice versa. I assume the SmartWings driver can be edited, but I don’t know enough about driver code to do it

Built-in driver code comes with hub platform updates and is not user-editable, nor are most of them open source. As your options, this would then leave ones like:

  • Verify that the device is installed and configured correctly and that any apps using it are as well
  • Use or write a custom driver
  • Provide data (such as debug logging and an explanation of what is really happening with each entry) to support a claim that something is wrong with the built-in driver

The built-in SmartWings Z-Wave shade driver uses 0 for closed and 99 for open, as is standard. If this isn't what's happening for you, I'd assume there is either something odd with the device/firmware, or is it possible for it to have been installed upside down or backwards?

I am quite certain the shades are installed correctly. The RF remote raises the shades using the “up” button and vice versa so they appear to be functioning properly.

I contacted SmartWings support to see if there is a newer firmware version and if so, how to install it. I have yet to hear back but I’ll follow up via a phone call tomorrow.

I changed the driver on one of the shades to “Generic Zigbee Shade” and selected the “Reversed” option under “Travel direction.”

If I specify a position, for example “20,” the Generic driver shade opens so that 80% of the window area shows. The SmartWings driver shade closes more such that only 20% of the window area shows. To me, the former makes more sense - in other words, a totally closed position would be 100%. That said, I don’t care which way that works, I can get used to it.

In this context, the Reversed option for the generic driver works as I would have expected.

What makes no sense is that for both drivers, an “open” command closes the shade (ie the window is totally covered) and “close” opens the shade all the way. It doesn’t matter whether the “Reversed” option is selected or not for the generic driver. While that may be intentional, I think for the vast majority of people “open” means you can look out the window and “close” means you cannot.

On my hub, the SmartWings driver shows up and looks editable. I might try to fiddle with it, but I’m not a coder and I’ll probably break the driver, if not the shade. I definitely do not have the experience to write a custom driver.

I’m hopeful that this information is helpful in figuring out why open and closed are reversed.

I’ll also post some logs for each shade soon.

One other data point - I installed and configured the Adaptive Cover integration, and it works correctly if I configure it with the reverse shade direction option selected.

For better or worse, the reasoning for the "closed = 0 / open = 100" standard comes from categorizing blinds/shades as a lighting device -- closed is dark (mimicing a light being off), whereas open is bright (mimicing a light being on).

2 Likes

This is the expected behavior, 0% = closed and 100% = open, so then 20% would be open 20% (or shade is closed 80% of the way).

This is how z-wave devices typically report their state as well, when it is open they report a shade level of 100.

If that is how your is already working with the proper driver, then try the open / close commands directly on the device page. Do they work as expected? Alexa should be calling those commands directly. You can check the event log to see what commands Alexa is sending to the hub to confirm.

You can also try my ZEN53 driver, either the normal version or the reversed version:

OK, well, my assumption was Z-Wave because that is the topic of the thread you posted in. If you have an unrelated problem, it is generally less confusing to start a new one.

That being said, I don't know as much about the Zigbee window covering command class to tell you what is "normal," but if the open and close commands (and maybe reported position?) seem backwards in the driver, it may be possible to add a similar option. But the percent reported is normally the percent open, where 0 is closed and 100 is open (or sometimes 99, or with blinds 50).

Thanks for that bit of insight. Now what seemed to me to be the opposite of logical now makes sense. Took a while but I got over 0 being closed and just adapted my thinking to the reality of "that's just how it is."

1 Like

As I mentioned , I don’t care if a set position is 20% open or 20% closed. It is annoying to say the least that “open” and “closed” are reversed. That’s like saying yes means no and no means yes.

To command the shade to open via Alexa integration, I have to say “Alexa, close shade xxx,” which I assume makes sense to no one.

Using the logic of a light switch, if I say “Alexa, turn shade xxx off,” it raises the shade all the way up. If turning off a light bulb makes it dark, then turning off the shade should close it (ie cover the window), not open it.

My bad about posting this issue in a z-wave thread but from what I can tell the protocol doesn’t matter since the behavior is backwards for open and close commands based on other posts, unless I’m missing something. Perhaps someone can enlighten me as to whether those commands via the Hubitat Alexa integration using z-wave shades works correctly.

Another mea culpa - I neglected to mention that I’m using Home Assistant as my primary automation platform and that Alexa integration as well. The C8 is there to support zigbee and a-wave devices. Adaptive Cover is a HA integration that adjusts the shades based on the azimuth and elevation of the sun based on which way your windows face.

Provide a link to the custom driver you are using.

It does, different hardware, different driver.

Please check this and answer my question, and post a screenshot of the event log showing the alexa (or home assistant) commands (also mention what you told alexa to do).

OK, the SmartWings folks solved the problem. The solution is as follows:

You need to do this for each shade. I am using the SmartWings zigbee driver. I assume this ought to work with z-wave as well.

Apparently, this does something to reverse whatever command is sent to "open" or "close." When telling Alexa to "open" the shade, the shade retracts so you can see out the window, and vice versa.

The set position command, for example, will leave 20% of the shade open if you say "set position of shade xxx to 20." At this juncture, I don't remember how it worked prior to updated my shades, but I can live with 20% meaning 20% open, 60% being 60% open, etc.

Since my Alexa integration is via the Home Assistant hub, I think in my setup it's all working correclty now. I can easily reverse the direction in the Adaptive Cover integration I described in an earlier post.

Thanks one and all for your advice and help!

That's great, thanks for sharing! Worked like a charm on my new Zigbee smartwings.

I spoke a little too soon as they were still wonky, but figured it out. In order to get the smartwings Zigbee blinds to operate properly you have to do all of (as I believe you did):

1- Switch from the smartwings zigbee shade driver to the generic zigbee shade driver.
2- Set the travel motion as reversed.
3- Then do the button push program change that smartwings shared with you.
Without all 3 changes there's going to be something (either state or movement direction) that displays or fires wrong.

I actually have a bunch of their Z-wave blinds too, which work normally and as expected on the smartwings driver without any of that being necessary. Something wrong with the zigbee driver code I suspect and/or the way they install it on their blinds.

Interesting…. I’m still using the SmartWings driver and the shades seem to be working properly. I had to add another zigbee device between the Hubitat hub and the bedroom where the shades are installed.

My shades were also wonky, and I suspected it was a radio range issue. I moved the hub to the bedroom and the shades worked perfectly. Coincidentally, I noticed that a zigbee motion sensor at the other end of the house no longer functioned.

I purchased a ThirdReality night light that has motion and illumination sensors. I plugged it into an outlet about half way between the original location of the Hubitat hub and the bedroom. Problem solved! No more wonky behavior.

I’m adding more zigbee devices to my network in general because they are relatively inexpensive compared with z-wave and really fast (for example, door or motion sensing). While Matter/Thread is available, it still seems immature and there aren’t a ton of devices out there yet. I have yet to try mqqt.

I’ll keep an eye on things and update the post if I find the SmartWings driver problematic

I don't think mine should have any mesh related issues. All my light switches are Zigbee, so it should be a pretty robust network. Strange that the driver works differently.

When I added the blinds (using the smart wings driver) the open/closed commands worked opposite, and the open/closed position was displayed as opposite. After applying the smartwings fix the open/close command worked correctly, but the position still displayed incorrectly. It wasn't until changing the driver and selecting reverse direction that everything reports and operates correctly (both via Hubitat and Home Assistant- linked via maker API). And this was for 4 different blinds, all acting the same way.

I suppose it depends on what one considers “reversed” in the context of position. I set up a dashboard card with a slider control. 100% is the fully open position. At 85% the shades are 85% open. This makes sense to me. I suppose if you want 0% for closed / 15% partially open in this scenario then you’d have to use the generic driver and reverse everything.

In MHO, as long as the numbers make sense WRT position and Alexa functions correctly, you’re good to go….

TLDR; why do the Alexa and rule machine open and close commands work oppositely with the same driver?

I've been using the Smartwings ZigBee shades with the built-in Hubitat Smartwings ZigBee driver for over a year. Once I adjusted to 100 open and 0 closed it's all good. I just added a large shade over a sliding door and wanted to control that with rule machine and Alexa. I say "Alexa open shade" and it opens to 100%, "Alexa close shade" closes it to 0%. Nice surprise. I added the shade to a rule that "open"s the shades at sunset. They were already open, at sunset the shade closed ??
For some reason Alexa commanded by voice opens and closes the shade as you might expect. The "open" and "close" commands from rule machine act in the opposite. An easy work around for rule machine is set level. But, why do the Alexa and rule machine open and close commands work oppositely with the same driver?

Answered my own question. The shade event logs for Alexa open and close show "command set position", not open and close.

1 Like

Open/Close were not always reversed. I have 6 Smartwings ZigBee roller shades that were purchased in September '23. I added a 7th shade on the same remote in Nov '24. All are using the built-in "Smartthings ZigBee Shade" driver. The '23 shades respond to Open/Close from the device page as you would expect. The Nov '24 shade is reversed. Same driver, the device pages says same firmware and software.
I didn't realize the Nov '24 shade was reversed because all of my rules use set position which works normally.

The tip off was the five Roman shades I purchased in late November that were "Reversed," I assumed it was the Roman shade software. I just installed 5 new roller shades and they are Reversed as well. I'm hoping @bravenel can add a Open/Close reverse option to the built-in driver. Smartwings has made a change to their ZigBee firmware between my first purchase and subsequent ones.

I noticed this as well after purchasing new ZigBee shades recently. However, just need to follow this from the docs to fix it. Fixes open/close and everything else continues to function as normal.