My blinds are working fine.
I'm not even going to look!
Smartest man in the room... 
My bigger issue is aside from the battery some days they open some days they don't some days they say they're open but they're really closed I'll tell you what it's really hit or miss on these things
Are you using my driver? Mine shouldn't report the wrong open/close state; they rely on reports from the device (so should Hubitat's built-in driver). iBlinds' driver from their site just sets the state after you send the command, regardless of what happens (or doesn't; mine have been well behaved lately but have indeed been hit or miss at various times).
yes sir.. my guess it is the units are finnicky..
Mine haven't mis-reported status for ages (also using this excellent driver from Robert).
They have on a few cases failed to open (but very rarely). Recently I switched back to using Scenes activated by SAR, and all five have been perfect, opening/closing morning and evening as designed.
Thanks! Never though of making it a scene might try that.. but what's SAR?
Simple Automation Rules... 
I have two scenes, one for "on" (open) and one for "off" (closed). Then call each scene w/ a separate Simple Automation Rule. Using scenes has been most reliable for me overall.
2 Likes
I've just updated this driver with a couple changes:
- added optional battery refresh schedule (like I had for v2, where this was necessary because they never sent on their own; my v3 unit isn't for me, either, but I see some people's are, so I've left it disabled by default--but now an option)
- improved Z-Wave Supervision handling for incoming and outgoing commands; this may increase reliability of commands like
on()orsetLevel(), as per Hubitat staff recommendation I have now added Supervision (outgoing) to thesetLevel()command (which ones likeon()andoff()also call internally) and will check and re-send a few seconds later if the device did not send a Supervision report back for the initial attempt; this is capped at one re-try and is only available if the device is paired with security
1 Like
Excellent - thanks very much for the update. I'll apply and let you know if I see any differences.
Thanks for the tip.. set it up tonight after sunset.. let's see how tomorrow goes..
1 Like
Remember:
- Good results: Me
- Bad results: Someone else
1 Like
Welp, my blinds stopped working fine. 
One of my blinds stopped working at all yesterday.
I tried to do an exclude/include. Nothing.
The red light would blink but no response in Hubitat.
I moved Hubitat to the blind with a long ethernet cable.
I tried to factory reset the blind.
I recharged the blind.
I reset and reset with power down on the hub.
I excluded.
I included.
Nothing appears in the Hubitat add device screen.
I tired every combination and permutation of the above.
My other two blinds on either side are fine.
I had not tried to update the driver.
- protocolVersion: 7.12
- hardwareVersion: 1
- firmwareVersion: 3.01
- deviceId: 113
- S2: 131
- manufacturer: 647
I am using this driver:
- Version History
- 2020-11-22: Initial release for iBlinds v3 (portions based on v2 driver)
- 2020-11-24: Added missing "position" events, Z-Wave parameter 1 option and paramter 3 auto-setting (for reporting to hub);
-
Added option for default digital "on"/"open" position; battery reports now always generate event (state change) - 2020-11-25: Minor fixes (parameter 3 au
Help!
Does the blind still show on your Z-Wave Details screen?
If it does, does it show Clusters and Route info?
I assume you've tried to control it from the blind's device page, and that doesn't work.
1 Like
OK. Fixed it.
If anyone else has a similar problem I took the blind down and did a CLBR Reboot and CLBR reset to default settings and IN/EX include.
1 Like
Glad that worked for you! In the past, a "simple" reboot has worked for me to solve unresponsive iBlinds v2 units, though I always did it manually (by unplugging power from the motor), which 5 taps of CLBR is supposed to do on v3 (not sure anything like this was on v2, probably why they added it...), though all of mine have, luckily, been behaving lately.
In any case, the driver would not be related to any inclusion/exclusion problems (and probably not any device responsiveness issues, either, though with S2 and Supervision there are things you can do to help, which my latest update does--but I'm not sure this would have helped me at any point in the past, where they just seemed to be hosed and not just missed a single command or gotten part of the security exchange out of sync).
2 Likes
To be clear, the problem arose before updating to the new version of the driver!
Thanks!
1 Like
OK, figured this one out. I'm using the original shipping firmware 3.01 . In 3.03, they added:
send an unsolicited battery report every 12 hours if the battery level changes more than 10% since the last check. Low-level battery reports are sent every 12 hours even if the battery level is not changed.
Not sure why that wasn't done originally, but that would explain it. I'll probably rework the driver to add a scheduled check by default if on earlier firmware, or not if not, but the preference will still be there and can be changed by anyone if needed (but I wouldn't do it if you don't need to). Meanwhile, I'm finally going to upgrade mine to the next version, 3.06, and see if I can add the parameter 7 thing (immediate calibration; why this is a parameter and not a command, I don't know, aside from the fact that I'm not sure there's a good command class to shove this into).
1 Like
I just tried upgrading to 3.06 and it failed. I skipped 3.03. Do you think that might be the problem?
I did mine in sequence (was on 3.03 before 3.06) but I see nothing in their docs recommending sequential, and I'd be surprised if that was required. More likely some flakeyness w/the HE FW update. IRRC I had the most success w/FW udpates if I did the following before starting the update:
- Reboot hub
- Open and close blinds (to "wake them up")
1 Like
