[RELEASE] Unofficial iBlinds driver

I wasn't quite happy with the Hubitat driver that iBlinds provided, so I modified it and wrote my own. Here it is:

(Raw link: https://raw.githubusercontent.com/RMoRobert/Hubitat/master/drivers/iBlinds.groovy)

Changes include:

  • More in line with Hubitat conventions: debug and info/description logging separated and each optional
  • Events created when reports received from device, not when sent to device (ensures the device is actually responding and updates "Last Updated" in driver so the devices are actually useful with apps like Device Watchdog now). The "Travel time" option basically sets the delay before the level/position report is requested from the device (which it appears to not send on its own after level/switch commands are issued).
  • Fixed their daily battery poll option (apparently it also does not send these reports on its own? their default driver makes you pick a time per day; mine defaults to a random early-morning time but can be changed or disabled, or you could do a refresh() whenever you want this--plus position information--too.)

This has been working well for me so I thought I'd share. Let me know if you notice any problems!

PS - I'm not very well versed on Z-Wave (neither are they, apparently) and kept some methods from their driver that I'm not sure are really needed, but anything I've been able to get to run does run as expected for me. Other eyes are certainly welcome!

4 Likes

"Reverse", Thank you, so much! :partying_face:

@bertabcd1234

A couple things I noticed after adding the iBlinds driver to my iBlinds device. After clicking "Configure" in the Logs I see an Error occurred.

Also noticed at "4 a.m." there was no listing in the Logs about "battery level refresh". Would that show when it takes place?

Thanks for any you can help me with.

There really isn't any configuration to do on these, so I didn't implement configure() but forgot that I left the capability declared (both things iBlinds also did). I've made configure() call initialize() now, which is probably better because otherwise there are some things (like the battery schedule) that would only happen if you clicked "Save Preferences," so I'd say this should work as expected now.

I also fixed a couple bugs regarding default preferences that would happen if you didn't click "Save Preferences," as I found with a couple blinds that didn't open this morning when I just changed the driver but never did anything else on those devices. :slight_smile:

First, it isn't really at 4 AM, just a random minute and second during the 4 AM hour (or whatever hour you've selected). I did this to avoid overwhelming the hub or at least the Z-Wave network at any one exact time for people with lots of blinds. If you know how to read cron expressions, you should see this under "Scheduled Jobs," but at the very least you should see something there and this is the only thing my driver would have put there.

Second, if you still have debug logging enabled (unlikely since I have it automatically disable after 30 minutes per Hubitat custom), you'd see a debug entry in your logs that says "getBattery()" any time the battery level is requested. If you have descriptionText logging enabled (as it should remain unless you manually disable it), you'll see an info entry in the logs that says "(Device display name) battery level is (battery level)%" if the new level is different from the old level when the hub hears back from the device (which should just be a couple seconds later). The "Last Activity" field should, I think, get updated if it hears back regardless of level.

That being said, I discovered a problem that prevented the battery attribute from actually getting updated (again an oddity I accidentally carried over from their driver), so that should work now, too.

Thanks for pointing these out!

2 Likes

Great driver.. picked up an iblind to see if it would work and this driver is perfect... Thanks!

Is it possible to add "start level change - up,down" and "stop level change" to a shade/blind driver? I haven't seen one that supports this yet.

It would depend on the device, but if you're not sure what it supports, you could try something like a zwave.switchMultilevelV1.switchMultilevelStartLevelChange or a zwave.commands.basicwindowcoveringv1.BasicWindowCoveringStartLevelChange in the driver (see here for some docs), which would be a promising guess if it supports either of those command classes.

However, as-is, I can tell you such a feature would pretty much be useless on iBlinds. They don't respond fast enough to commands, so by the time you tell it to stop, it would undoubtedly be way past where you want it to go (and it wouldn't start exactly when you begin pressing or holding the button, either). I could see this being desirable for roller shades or other devices with longer distance or times between their "minimum" and "maximum" levels/positions.

1 Like

I agree with this, However I do like the iblinds overall.

I have some Zemismart Zwave curtains that do respond very fast that I would like to try this on. I didn't realize it was device dependant. I was thinking the driver made it work lol.

Thanks for the info!!

Would love to hear about the general overall happiness w/iBlinds. I'm close to ordering the iBlinds kit v3, and frankly wanted a little reassurance that I won't regret it. :slight_smile:

And a couple of questions...I've never used smart blinds so forgive my ignorance, the things I'm asking about below seem like they should be obvious but I'm not sure exactly what they refer to:

What do these driver settings mean:

  • Set level (and why a Duration option?) Is this for raising/lowering the blinds?
  • Set Position - is this to set the angle of the slats?

And:

  • Can you tell iBlinds to set the blinds to a certain angle via Google Home voice commands?
  • Do you know if they support any "dimming" commands via Lutron Picos, to set the blind angle?
  • iBlinds appears as a switch in the ABC app...do "On" and "Off" correspond to Open and Closed, or ?

I rarely raise or lower my blinds, I just adjust the angle of the slats depending on the sun's position. Looking forward to automating that when we get up, as the sun changes, and when it starts to get dark outside.

I have a few v1 and v2 modules (I think these are the exact same aside from a translucent case on the v2 and possibly other hardware changes that don't affect functionality; software-wise, they seem identical, and both are 500-series Z-Wave. I just pre-ordered a v3 because I can't help myself (and I'm curious what's different; 700-series Z-Wave sounds promising, as do some of the touted features, though most seem like ones already doable on the driver side if you use Hubitat). Don't tell my SO. (Yes, I have a couple v2 modules I haven't even installed yet... :grimacing:)

As for your questions:

  • Hubitat's "Set Level" comand specification requires an optional duration (meaning the command must accept one if provided, but you do not have to provide one; notice the lack of asterisk on the device page for this parameter). I'm just following the standard command requirements here, but I have yet to see the duration actually matter, so you might as well leave it off. I pass it along in what should be the standard Z-Wave fashion (Z-Wave, I think, also requires this for the command class I'm using), but the devices just move at whatever speed they want and apparently the only speed at which they can move.
  • "Set Level" and "Set Position" are identical and used to set the slat position, open or closed (or some percentage in between, with 0 being closed down, 50 being flat open, and 99-100 being closed up). The "Set Position" command is the "real" Hubitat command for this (coming from the standard "Window Shade" capability designed for this purpose), but "Set Level" is there (coming from the "Switch Level" capability most often seen on dimmers and bulbs) because it makes the device much more widely compatible with apps that expect dimmer-type devices. It also helps with some voice assistants (or did; Alexa can probably handle real Window Shade devices now, but I'm not sure about Google).

and:

  • You can tell Alexa to set a specific level (because mine is a dimmer, something I can probably adjust now but left this way, I say "dim the living room BLLLIIIIIIIIIIIINNNNDDDZZZZZ to 99%" to close them; I assume Google could do the same). Yes, I have to say "blinds" like that or it insists on hearing "lights" instead. :slight_smile:
  • Picos don't support "dimming" commands per se, but any app that can use a Pico may be able to send them. Button Controller or Rule Machine would work well here--that's what I'm using for many of mine. I'm also using my custom Dimmer Button Controller app on some but want to re-work that into a "Blinds Button Controller" app to accommodate some things that might help it work better (like the fact that these devices don't report their status back and this driver just requests it after it's likely to be done moving...kinda curious if v3 are different here, and I hope they are).
  • Yes, my driver also implements the "Switch" capability ("On" and "Off" commands plus the "switch" attribute/state). "On" is configurable but by default opens to 50%. "Off" will close them to level 0.

I'm mostly happy with mine, except one or two I seem to need to "reboot" on occasion to get responding again (turning the battery off for a few seconds and back on). I've also had to un-join and re-join one to my network once when it stopped responding and this didn't help. I hope this is just bad luck on my side and not a common occurrence...

1 Like

Thanks for all the excellent info. Your secrets about dozens of unused iBlinds are safe with me, as long as you send me one. :wink:

You've sold me, I'm going to order one of the v3 and see if it works well enough to be our main blind control for some new windows were adding to the house.

Hopefully this works out, if not, as usual I'll blame the internet. :sunglasses:

One thing I forgot...can I connect a wall charger to the charging port 24\7, rather than having to charge it up every few months?

They don't say you can, but I don't see why not--physically you definitely can, though it might be a bit ugly and hard to hide the cord (but to mitigate that, you could keep the "external" button and USB port inside the headrail; I pretty much ended up doing this on a couple blinds where it didn't really fit in the old tilt string cutout anyway). You may have seen that they sell a solar panel for more or less this same purpose, keeping it charged, and I have a couple of those too that seem to work well so far.

1 Like

Just ordered one of the v3 for initial testing. Happy to do any testing for any updates you may make to your driver when they arrive. :slight_smile: Assuming it works out and has reasonable WAF, we'll get these for all the blinds when we do our remodel (start is still 2-3 months out).

Forgot to mention, they do list some new features w/the v3 blinds. Maybe opening/closing speed really will be configurable (like setting dimming speed). I assume "Direction" means they will support what you already have, making the blinds close upwards.

Configurable:

  • Direction
  • Speed
  • Calibration
  • Preset Open