[RELEASE] Unofficial iBlinds driver - v2 and v3

If you are having problems with your blinds (and don't believe they are driver-related) or general questions about them, please post about that in another thread.

I would like to keep this thread focused on discussion related to the driver.


Device/driver history note: This driver/post was originally written for v2 of the iBlinds unit. This driver still appears below. I have also written a new driver for v3, also below. Check your model (v3 was released in fall 2020). Hubitat now also has a built-in driver for v3 only that may meet your needs, but I wrote my own v3 driver because I offer additional options and capabilities that I needed for my use.

UPDATE for version 3:

Hubitat, as of platform version 2.2.4, now has a built-in driver for the iBlinds v3 units. However, I also overhauled my v2 driver to work for the v3 units. Links for both appear below, and my commentary on differences between both my driver and iBlinds' and my driver and Hubitat's appear at the end of this post.


ORIGINAL POST for version 2:

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


Differences from my driver compared to the one from iBlinds include (updated for both v2 and v3):

  • Events not generated unless new state received from blinds (iBlinds' provided driver updates when user sends command, regardless of what device actually does).
    • Note: the v2 blinds do not automatically send state on their own, so it is requested some time after sending (this is what the "travel time allowance" setting in the driver does; set it high if calibrating and feel free to keep it higher that needed since requesting the level while still in motion can be problematic on the v2 units).
    • The v3 driver configures the v3 units to report state back to the hub (which they can do on their own) and simply waits for a report; this is one reason why I recommend my v3 driver over the v2 driver for the v3 units
    • This change makes the devices behave better with "Device Watchdog"- or "Device Activity Check"-type apps, plus it provides a more reliable indication of the device's actual state
  • More in line with Hubitat conventions: debug and info/description logging separated and each optional
  • v2 only (v3 sends reports on its own so this isn't needed): added configurable daily battery poll time option, which should request battery state from v2 unit daily, with some likely improvements over the way iBlinds implemented this in their driver (more randomized time, attempted recovery if schedule lost, etc.)

Differences from my driver compared to Hubitat's include:

  • v2: Hubitat doesn't have a v2 driver, though it's possible the generic or v3 drivers may work to some extent (but probably not for automatically fetching device state after change)
  • v3: Hubitat's driver is a pure "WindowShade" device (setPosition() command only), whereas mine adds "Switch" and "SwitchLevel" (on()/off() and setLevel() commands), opening wider compatibility with more apps--but you can comment this out if needed; mine also exposes most Z-Wave parameters for the device (all except the automatic Z-Wave reporting parameter, which the driver specifically sets to a value that makes the driver work well with Hubitat)

Let me know if you notice any problems!

6 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 v2 and v2.1 modules (I think these are the exact same aside from a translucent case on the v2.1 and possibly other hardware changes that don't affect functionality; software-wise, they seem identical, and both are 500-series Z-Wave, and I'm not sure what "v1" was if it ever existed publicly). 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...

2 Likes

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

See this thread for info on the new features in the V3 iBlinds shipping in November 2020.

Orders up to 10/23/2020 are discounted from $149 to $119 on the iBlinds site.

For anyone with the new v3 units, I've updated my original post in this thread. Hubitat now has a built in driver for the v3 units, so if that works for you, there's no reason to use anything else. iBlinds is also providing a driver for v3 from themselves, but I'm still not a fan of it for reasons similar to their v2 driver (notably, it reports state changes as soon as you send a command, so Hubitat may not accurately reflect the real device state; this is less excusable on v3 than it was on v2 since the v3 units actually report state back on their own--and it also means that if you're using my v2 driver that tried to work around this, I would use either my v3 driver or Hubitat's driver instead on those rather than the v2 driver, as it does not need to work around the oddities that v2 has).

So, I threw together a v3 driver and updated the original post with that, too. :slight_smile: I haven't used Hubitat's driver much to see how it compares, but off the top of my head it looks like Hubitat went with pure "Window Shade" capability on theirs rather than "Switch" (on/off commands) and "Switch Level" (setLevel command, like a dimmer), which is totally fine and probably ideal except that some apps and voice assistants don't like those as much, so you may find increased compatibility here (and they can still be commented out in my driver if you want to be that pure). I also didn't make use of the "opening" and "closing" states while the device is in transition, as I really only want events to be generated when the device actually reports something (and it doesn't report this, just when it's done).

I haven't tested all of the parameters, but I added them to my driver according to what the manual says. If anyone tries it out, let me know! :smiley: I've been testing it on the one I have and it seems to be working fine for me so far.

1 Like

Just started using your v3 driver (thank you!) and so far zero issues. Even little micro-adjustments (e.g., change level from level 49 to 55) are handled smoothly, the iBlinds 3.1 driver from iBlinds didn't handle those types of changes very well.

Looks like excellent work so far, and greatly appreciated.

Any plans to put into HPM for easier install for some, and for broader exposure to HE users?

1 Like

Tempting, but I'm guessing Hubitat's build-in drivers would work well for most new users at this point given that they'd probably have a v3, but I certainly could if there is
interest!

I'm not sure why, but it looks like theirs uses 0 for the rate/duration of the "Set Level" if you don't provide one, which is probably just as fast as the blinds can move. Mine just doesn't pass a specified duration on to the command to the device at all in this case, which I will assume use whatever the rate is set to via the Z-Wave parameter (new in v3) for this. Or you can provide your own for "Set Level" (but not "Set Position," per the Hubitat capability definitions; these are otherwise equivalent in my driver and all blinds/shades drivers I know of).

1 Like

I certainly have interest in that, particularly when it's so easy when referring folks to it, for them to install it and keep it updated. (And I like the auto-update that HPM enables as well. :slight_smile: )

Woot - Update!