If you are having problems with your blinds (and don't believe they are driver-related), 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.
v3 driver raw link (for import): https://raw.githubusercontent.com/RMoRobert/Hubitat/master/drivers/iBlinds-v3.groovy
v3 driver formatted link (if you want to see the code with syntax highlighting and whatnot): Hubitat/iBlinds-v3.groovy at master · RMoRobert/Hubitat · GitHub
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:
v2 driver raw link (for import): https://raw.githubusercontent.com/RMoRobert/Hubitat/master/drivers/iBlinds-v2.groovy
v2 driver formatted link (if you want to see the code with syntax highlighting and whatnot): Hubitat/iBlinds-v2.groovy at master · RMoRobert/Hubitat · GitHub
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" (
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!