Greetings, everyone! I just updated my v2 and v3 drivers:
v2 with some minor fixes (mostly regarding the battery reports--you have to make the v2 units do this because they apparently don't send anything back on their own, ever)
v3 with some minor fixes and enhancements (all Z-Wave parameters exposed except the Z-Wave reporting one that must be set to a specific value for the driver to work well with Hubitat; ability to set default "open" level).
Both have also been updated to update the "position" attribute, which I appear to have been neglecting before in favor of just "level." (They are synonymous in my driver; using both makes them more widely compatible with apps. You can comment out the Switch and SwitchLevel things if this is problematic, or you could consider Hubitat's built-in driver that is a "pure" WindowShade.)
This updated version of the driver is working great for me. Both of my blinds installed so far are showing accurate anc consistent status, and respond to commands as expected. Excellent work, @bertabcd1234, thanks very much for sharing this w/us.
@bertabcd1234...is it possible to add an additional preference, similar to the existing "Open Command opens to" setting.
What I'd like is the opposite "Close Command closes to" setting, so that my wife can use simple "open/close" voice commands via GH, and the blind will close to a specific close position w/out her having to tell GH the setting as a dimmer level.
Does the V3 FW support that, and possible to add at some point?
If that parameter isn't available, is there another way to achieve this?
I didn't add that because I figured most people would either want to close all the way up or down, and the firmware already provides a way to set it so that it closes up ("reverse"), and if you aren't really closing them, a "Set Level," as you note, can already do whatever you want. If what you (or she) wants isn't really either of those, it wouldn't be a big deal to add something.
Since my driver also exposes them as dimmer-esque devices, you could also include the blinds in a Hubitat scene with a specific level and then just use whatever device/voice command you'd use to activate that scene. Just another idea.
Thanks for the suggestions. I will look at those options.
BTW - I noticed something that seems like a parameter isn't getting set. It's occuring on both blinds, and not sure if it's just a reporting/display issue, or ?
On both blinds Parameter1 (the gap tightness), the State Variable value isn't matching what I set the blinds to. Just a reporting thing, or ?
And, is this another way to get to my goal? If I set a "looser" value here will that result in the blinds stopping before they are tightly closed? That is why I was asking about the close setting, my wife is worried that the blinds will be affected by how tightly iBlinds is closing them. Can't talk her out of her worry, so ...
I don't modify any state variables in my driver, so those must be left over from a previous driver. I'd suggest using the plain "Device" driver to clear these to avoid confusion, but they're otherwise also harmless to keep. You can check the actual value with the Basic Z-Wave Tool if you're not sure if it got set--it could still indeed be an issue if I messed something up (or their manual is wrong).
Thank you so much for all of your effort on this. At this moment all three of my iBlinds seem to be working as expected and I credit your driver as much as anything.
Just fixed a mistake/omission that would have prevented most parameters from being set if the device was joined securely. Should be fixed now. Thanks for the report!
I appreciate the thanks, but I think it's more to do with the devices. Mine, with any driver, are extremely picky--and every once in a while, they just don't do what I say. My v3 unit has been pretty well behaved, but my v2 units do this on occasion. Rebooting them (normal people have to reboot their blinds, right?) seems to help, but other times I wonder if it's just the fact that I waited more time. But I'm suspicious that this might be why they added the "feature" where you can press the calibration button (CLBR) on the motor 5 times to reboot without needing to pull power now...
Aaaaand now mine isn't sending reports back to the hub when the position is changed, even though I have parameter 3 (size 1) set to 1, as verified with the Basic Z-Wave Tool. (I have no idea why anyone wouldn't want this, but I think it's a result of them misunderrstanding the fact that their v2 units misbehaved if they received a BasicGet while the blinds were in motion, per many users' complaints. If the unit decides to send something on its own, it should both know when to do so and be fine--or they could just have fixed that problem in the first place.)
I even tried changing it to 0 and back to 1 and waiting for reports when it was 0 in case the manual has it backwards, but that didn't help either. I also tried rebooting my blinds, both via cutting power and the 5-CLBR-button tap. So, they are working fine for me, but "Current States" isn't not updating. If anyone else notices anything in this regard and has any ideas, let me know! I know this did work in the past, so the units are certainly capable of doing so (v3 only).
EDIT: Ignore all below...my problems were caused by the 2nd blinds unit falling off the mesh and taking my mesh down with it.
Just did a close and open. I reported close status fine.
Open command took longer to process (5-7s?) and has not registered open states yet (been a minute or more?)
Not related to your updated driver (which I had just installed before trying this)?
Hitting configure and refresh a few times updated state info. Should have been more patient, no idea if it just caught up coincidentally, or my button mashing did it.
Tried the second blind:
It responded to both close and open somewhat languidly, open being the slower response. State still shows closed, a minute or more later.
It is set to close normally (downwards) but it is closing upwards instead. Was not doing that on the previous release driver, IRRC. I ran a manual configure on the blinds to see if that helps.
State reporting has generally been pretty good/consistent for me.
Both blinds really don't seem to change their close tightness regardless of that setting - mine is at 26 (set it manually this AM) and they still close very tight.
A refresh() still worked for me--that sends a "get" to the device, which responds with a "report," and the driver (sees and) parses the report fine; it's just that v3 should send a report on its own whenever the state changes (either after a command from the hub or the pushbutton on the charging unit), but that was temporarily broken for me. But mysteriously, it's working again for me. With debug logging enabled, you'll see everything the driver gets from the blinds, even if it doesn't get parsed (though I'm pretty sure I have every possible report handled...but just in case).
The only thing I can find in their manual is that parameter 3 should be set to 1 for automatic reporting (and that it's disabled by default). Mine is/was, except for during my testing with the opposite setting, so I'm not sure what's going on. I didn't make any changes to the driver that should affect this, and I actually noticed it before I made my latest change right before I did the fix. And again, it's working now. iBlinds...
After rebooting the second blind unit showed up failed in Z-Wave Details list... This one has been a problem child...finally got it to work for a day or so but it's fallen off the mesh again. That's what caused all my issues.
Back to the drawing board trying to get this one solidly connected. Probably going to remove it from the blinds and bring the antenna outside the unit.
Did another report on the blind that is solid - info below. Looks like parameter 3 got the "1" value desired, and my tightness setting (Parameter 1) is correct at 26, and open to (Parameter 4) at 45. Default speed (parameter 6) is set to 3 as desired.
Parameter 2 is the "reverse direction of blinds" parameter (0 = normal/close down, 1 = reverse/close up). Parameter 5 is "reserved for manufacturer," so no idea other than that I wouldn't change it.
This is from their user guide, assuming that is accurate.
@bertabcd1234 - I have a couple blinds now where I've set the option to close upwards, but they close down regardless. Any thoughts on how to get them to close upwards per the setting. I've tried hitting Save Preferences again, and using the Configure button, but they still close down.
Hmm. Have you verified with the Basic Z-Wave Tool that this parameter is actually getting set to the correct value? (This is parameter 2, with value 0 = normal and value 1 = reversed. The manual doesn't specify size, but I'd assume 1 byte. A "Get" of this parameter should show you to be sure.)
If that's correct but doesn't work, I'd suggest reaching out to your best friend, their support team, to ask if anything else is necessary (I assume we don't need to re-calibrate or anything?) or if this might be a problem (or is the manual wrong?). If the value isn't getting set correctly by the driver, that's definitely my problem and almost seems more likely, but I don't see any problems with that off hand.
I should note that beyond setting the parameter value, my driver doesn't do anything different when the blinds are reversed--it still sets them to 0 to close, and my understanding of the manual is that the device should then flip these positions around internally (so that 0 would close up in this case). In my v2 driver, this is all faked by calculating the "inverted" level since the device doesn't support this natively, but v3 should (and it matters outside the driver too, since I assume the manual open/close with the charge button would also obey this direction).
Mine, with any driver, are extremely picky--and every once in a while, they just don't do what I say. My v3 unit has been pretty well behaved, but my v2 units do this on occasion. Rebooting them (normal people have to reboot their blinds, right?) seems to help, but other times I wonder if it's just the fact that I waited more time. But I'm suspicious that this might be why they added the "feature" where you can press the calibration button (CLBR) on the motor 5 times to reboot without needing to pull power now...
This one has been a problem child...finally got it to work for a day or so but it's fallen off the mesh again. That's what caused all my issues.
