[RELEASE] Springs Window Fashions Sheer Shade Driver

I recently migrated from ST to HE and so far haven't looked back. :wink:

In working through the differences between the platforms I found the stock Generic Z-Wave Shade driver wasn't working for my needs, particularly the battery level reports. I also miss the Preset button.

I decided to address these and tackle one of my pet peeves with every shade driver I've come across on both platforms, namely, how they handle Bali Sheer Shades.

These are manufactured by Springs Windows Fashions under the Graber and Bali brand names. They are not like regular roller or double-roller shades in that when fully extended, they appear sheer (aka partially open) and are opaque (aka closed) when the motors are between 3 and 6 (depending on the length of the window). Trust me, if you have these, you know what I'm talking about.

It always bothered me that the platforms reported my shades ( windowShade attribute) as being partially opened when they were closed (opaque) and closed when they were in the sheer position, which is where we keep them during the day. :crazy_face: Also, we had to press the closed button to make them sheer and remember which level set them to closed since they are different lengths. This wasn't an issue for my webCoRE pistons, but even they looked strange too with a lot of comments that "position 4 is really closed."

This device handler addresses all of those shortcomings and adds a preset button and position in webCoRE. AAMOF, with this driver, I was able to tell She-Who-Shall-Not-Be-Named to close the kitchen shade, and it actually closed instead of opening to sheer! :grin:

There are three additional settings for this driver that aren't in the generic driver (or others for that matter):

The Closed Position needs to be set to the specific level/position that make the shades fully opaque. That number will be different for each shade, based on length. For example, here is what I have for my windows:

Shade Type Sheer Closed Open
Office Double Roller
Office Double Roller
Kitchen Sheer <4 4-6 >6
Dining Room 1 Sheer <3 3-4 >4
Dining Room 2 Sheer <3 3-4 >4
Living Room 1 Sheer <3 3-4 >4
Living Room 2 Sheer <3 3-4 >4
Bedroom 1 Sheer <5 5 >5
Bedroom 2 Sheer <5 5 >5
Bedroom 3 Sheer <5 5 >5
Bedroom 4 Sheer <5 5 >5

Based on this, I set the Closed Position for my kitchen shade to 5. YYMV, be sure to set it to whatever works best for each window covering. The Preset Level can be set to whatever you'd like. It just makes it easier to go to a specific position.

The Relative Level setting is where this either gets confusing or really fun (depending on your view).

When set FALSE there is no difference between the Position and Level settings/reporting. If you set it to TRUE the position will still be the absolute motor position (0 to 99) but the level is calculated relative to the amount the shade can actually be open or raised (i.e, substract the motor positions that are part of the sheer positions). IMHO, this give you the best of both worlds, you can set an absolute position and still tell She-Who-Shall-Not-Be-Named to set the shade to 50% and it will go half-way up.

For example, if 5 represents closed, and you want the shade rolled up to 10%, it actually moves the motor to 14. A level of 50% will open the shade halfway up the wall allowing for the positions that are closed/sheer. When sheer, it reports how sheer the shade is.

I also created a version for standard roller and double-roller shades that uses the same base code (minus the sheer settings that has the battery reporting and preset option.

Now, this single webCoRE command works no matter the shade type or length of each.

As Springs uses the exact same Somfy motors in all their roller shades, there's no way to pull an electronic signature to know if the shade is a roller, double-roller, or sheer shade. You have to chose which driver to use yourself.

Both are available in GitHub and can be installed via the Hubitat Package Manager.

P.S. Thank to DevTodd for having a clean base for me to start with.

5 Likes

Mind if I link the drivers in the post I maintain for the Graber shades?

Please and thank you! :ok_hand:

thankyou for the driver , i was able to get the battery status on my dashboard finally .... :+1:

1 Like

:ok_hand:

Any chance that this could also include support for their layered shades?

What I'm missing is the ability to send the "Home" button press on the remote which splits the layered shades. I can't seem to set any level or position that can split the shades the same way the "Home" button on the remote can. Setting Level 1 doesnt open the shade enough, setting level 2 opens the shade too much.

If I set the shades up as dimmers and then set the dimmer switch "on", as long as the shades were fully closed to start, the shades will split the proper way. Whatever command is sent by dimmer on seems to mimic the home button on the physical remote

I have two of their layered shades myself. I agree, setting a level 1 or 2 is not the same as the HOME button but it's as close as I can get it.

There is no function that I've found in the library to programmatically call that position. I would love to be able to add that to the driver.

I did try sending the open command (0xFF) but that didn't send the shades to home, it fully opened them, just as the 100% (0x64) command does.

I'll keep doing some research in to the available commands. If anyone here knows what command to call to have the Somfy motors move to home I'd love to hear it.

Just wanted to say thanks for the driver. The standard Z Wave one would not stop the shades unless I used Set Position -1. Which was good until I realized that the Advanced Button Controller would not support negative numbers. So anyway ended up adding the stop command for shades on the Advanced Button controller (Child) for the Somfy held event on the remote. So full parity (and more) with what came out of the box with the ZebraBlind shades.

Great to hear, thanks! Glad I could put something together that helps.

So chatting with the dev of ABC and he has suggested that it would be good to implement the stopPositionChange() method as indicated in this thread. Advanced Button Controller (ABC) - #340 by stephack

If you are open to doing that and posting it I am happy to test both ABC and the updated driver.

Essentially would need this in your driver, so not to break any other uses of stop();

def stopPositionChange() {
logDebug "StopO=PositionCHnage command issued."
stop()
}

I added the stopPositionChange() per your request.

Thanks for that, loaded that up and on its own no issues. I also dont expect any issues from ABC as well. Thanks for supporting this change request

I have a total of 6 blinds using the roller shade driver now. On my dash board 3 of the shade tiles stay lit yellow when the shade reports closed, and 3 go back to being gray when the shade reports closed. All shades are reporting level 0 and position 0 in their individual device page. Any idea what would cause this behavior? Thanks!

Can you send a copy of the logs for one that stays yellow and one that goes back to gray as well as a screenshot of the settings for each?

Hi. Hope I'm providing the correct log:
Shade that stays yellow no matter the position:


Shade setting screen shot

I just realized that with the Springs Window Driver that all the icons stay the color they are regardless of the shade position. The ones that are gray stay gray if they are closed, open, partially open and the ones that are yellow, stay yellow if they are closed, open, partially open. I think it depends on their state when I switched from Generic Driver to Spring Window driver, if they were yellow when switched they stay yellow etc...

Log from a shade I reverted to Generic Driver where the icon color behaves correctly:
MB 1 Log
Settings from shade:

Thanks. Which template are you using for the tile in the dashboard?

I don't use the dashboards as much as I use WebCoRE. The tiles I see in my dashboard do show the proper state name (as it changes) and the sliders work fine. Mine don't change color though.

It's all grey all the time.

I'll try and duplicate what you're seeing.

Im using the shade template.
The state changes fine, the icon changes fine, however the tile color is always stuck, unlike the generic driver which is dynamic. Thank you for looking into this.

Fixed! :wink:

Well, not really a fix so much as a change to accommodate how the dashboards work. It took a little reverse engineering to figure out what triggered the background color change.

I still don't quite understand why the two drivers behaved differently in the dashboard, considering they both use the same "shade" tile template. The sheer tiles stayed gray all the time and the roller shade tiles remained yellow all the time. :man_shrugging:

In any case, both drivers have been updated along with the HPM manifest, so you can just pull the update via HPM at it will update both drivers.

The tiles will be gray when closed and yellow for the other states (open, sheer, partial open). Now that the tiles will change color based on state, you can change the colors to whatever you'd like.

I had partial success. I updated the driver and installed it.
LR1 was partially open and it was still gray. I closed the shade and reopened to partial open and it was yellow. Success!

LR2 was partially open and it was still gray. I closed the shade and reopened to partial open and it stayed gray. Fail

Here are the logs showing both a close and partial open for LR1 and LR2 along with the settings of each device.



I also rebooted the hub to see if that had any effect and it didnt.

Thanks

Adding on to my previous post...
I watched 3 of my shades (not the ones mentioned above) go to full close, report close, then I opened them completely, and all 3 reported open and turned yellow. I exited the dashboard and came back and only two were still yellow even though all 3 were reporting open. Strange