US - NEW! iblinds Kit v3

[rlithgow1]

What driver are you using? I don't see a tightness in mine.

[wayne.pirtle]

Beaming capable devices are not essential, but they can help improve devices that are very sleepy. All battery powered devices are sleepy. They wake up periodically to see if there is a command waiting for them. Beaming devices cache commands for nearby sleepy devices and repeat the command when the sleepy device wakes up.

Don't be embarrassed. We are all learning, sometimes from others, sometimes from wailing and gnashing of teeth with the devices. Here is a picture of a portion of the bottom of the device page for one of my hardware version 3.0 iBlinds devices. I highlighted the firmware line. Ignore the hardware version line. It isn't accurate for iBlinds. The device has a tag on it that states the hardware model. The hardware model is EXTREMELY important to know when you consider upgrading firmware.

[wayne.pirtle]

I use the iBlinds provided driver (V3.10). Here is the iBlinds reference to it.

Hub Specific Device Drivers – Hubitat, SmartThings – iblinds Support (myiblinds.com)

[wayne.pirtle]

iBlinds are capable of S2 security. When connecting an S2 capable device to an S2 capable hub (C-7), a security choice window will popup during the join process. Here is a sample popup from HE's Z-wave documentation.

To join without security, choose the Cancel button.

C-5 hubs default to only joining locks and door openers securely.

[danabw]

@rlithgow1

On the C7 the security pop-up has changed and now looks like below...choose the "Skip" option to join w/out security.

[danabw]

I have found the most success w/iBlinds w/@bertabcd1234 's community iBlinds driver.

Found here:

[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 bu…

There are some differences between Robert's driver that are good things to have, IMHO.

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)

[danabw]

@Hal3

Multiple installs and uninstalls can leave "ghost devices" in the Z-Wave network so be sure to remove all "ghosts" - instructions are elsewhere in these threads.

This is important, @rlithgow1 - make sure you're Z-Wave Details Page doesn't have devices in it that are missing routing information in the last column...

[rlithgow1]

[rlithgow1]

Issue is when it does the calibration in ends up in the 70% open position instead of 50 and when you go to close it and it only moves a little bit like maybe closes to 30 %

[danabw]

Yeah, I saw that, and have never experienced anything like that. Tagging @Eric_iblinds to see if he has any input/suggestions.

First thing I would try if you're not using Robert's driver, is switch to it and hit Configure, and then set your Default On and Open position settings in Preferences. Then try using the driver buttons to open/close or turn on/off the blinds and see how they work.

If the blinds are binding that might affect how calibration works, so you could try doing a calibration while actually holding the blinds (I did this once) to ensure that there isn't something blocking them from moving freely. Probably not, but...

I have had my iBlinds act strangely a few times, and I usually ended up doing a factory reset on them to "start over." You could try that...unfortunately requires access to the motor.

You could try the "Reset and Clear Parameter Values" option first, and if that doesn't help, exclude the blinds, do the "Manual, Factory Reset" and then re-include them.

If you force manual calibration does it repeatedly stop at 70%/30%?

Parameter 1 determines close interval (and can be set in Robert's driver) and can also affect calibration. As @Hal3 noted above, I think, try changing that in Robert's driver to see if that has any effect.

[wayne.pirtle]

I have had that happen, primarily on very large blinds with v3.0 hardware. v3.1 hardware handled the larger blinds (6' x 6') with ease. This may have also been improved in the newer firmware for both hardware versions.

[danabw]

Interesting - I don't have really large blinds so never been an issue for me, good to know.

I think that changing the close tightness setting to a lower (tighter) number might help if that's the case. Tells the blinds to work harder to close the blinds tighter...whether the driver setting for how tight to close the blinds is "active" during calibration is something I don't know. @bertabcd1234 Robert might now...

[wayne.pirtle]

Nope. I tried that. As I understand the situation, it is an issue with how the firmware makes its decisions about what the end of travel looks like during calibration. I beta tested a 3.1 device for this situation. Worked like a dream, and it was a bit quieter too.

[danabw]

Thanks. I have a couple of the 3.1 devices I "beta'd" as well, and wasn't aware that was one of their improvements. I didn't want anyone to know, but now it's out there that I have small blinds. How embarrassing.

[rlithgow1]

No binding, Calibration goes from point to point no problem. But it doesn't respect it's own calibration. I'm going to try another unit to see if it does the same thing.

[danabw]

Bizarre...never seen anything like that. I assume you've tried factory reset?

[rlithgow1]

Yep

[wayne.pirtle]

@rlithgow1

Calibration goes from point to point no problem. But it doesn't respect it's own calibration.

What do you mean by that?

[rlithgow1]

It won't close to more than 30 percent and barely moves to 50.

[wayne.pirtle]

Did you find out what firmware version your iBlinds devices are on?