What is the correct way to use the "set level" and "set position" variables?
Black Friday is Black Friday. 
If it's anything like the Xiaomi Aqara curtain driver I'm using, it doesn't seem to make any difference. They both seem to mean the same thing.
Yes, when I used them they had the same effect. I think the "Set Level" option is there to allow you to control the blinds position as if they are a Dimmer switch.
The v3 units are so much nicer than the v2 units: they report state back when changed (in Z-Wave terms, do a "set" and it sends a "report" back when it's done, say, if you changed the level/position). The v2 units don't, so my v2 driver basically polled them (or did a "get," in Z-Wave terms) a specified interval ("travel time" in the driver) afterwards. The v2 units were further problematic in that if you did a "get" (or at least this specific type of "get") while they were moving, they did something odd like went all the way open/close instead of stopping at the desired level, so you had to be careful not to issue one too soon. If you don't care for near-instant reporting--or are calibrating the v2s--the longest possible setting should be the least problematic, FYI.
The v3 driver is much leaner because it doesn't have to worry about this or force the device to talk to the hub (the v2 also didn't report battery unless asked, so I scheduled a daily refresh of that so you had some idea and recently added in a few checks to re-schedule that if it somehow got missed and never rescheduled, which seemed to happen on a couple of my devices). The v3 units also support S2, so I updated my v3 driver to accommodate this, while I left it entirely out of the v2 driver since it doesn't. (The v2 driver file has also been renamed, in case anyone is using the importURL; see my iBlinds driver thread for the links.)
That being said, Hubitat's driver will probably work fine for most v3 users--I just like writing my own so I know exactly what's going on. 
(And I had some apps that would better with the dimmer-esque setLevel() commands and whatnot that Hubitat's "pure" window shade driver doesn't have.)
2 Likes
Thanks for the great summary. Sounds like iBlinds did some good things, glad to hear it.
Can we assume the 3.1 iBlinds driver takes advantage of the FW\communication improvements? NVM...I saw your comments in your driver thread...man, pretty disappointing that the iBlinds 3.1 driver doesn't take advantage of the status communication improvements in the FW. "Two Different Teams" syndrome... We had that sometimes at my old workplace...FW team develops cool innovation. SW team not informed, or mis-informed/partially informed, or just too buysy doing other stuff and SW isn't updated to take advantage of new FW. 
I'm off to look say your driver, thanks for sharing it! Update: LOVE your driver and the updates you've put into it. Will be using it going forward. Thanks again for your contribution(s) to the community. Five stars.
I tried your driver and this came up in the log...
2020-11-22 01:24:30.897 pm [error]java.lang.IllegalArgumentException: null on line 225 (open)
Thanks for the report! I put in a quick fix (making "open" go to 50%) but will think of a better way to do this in the long run, either adding back the v2 preference for "open" level or seeing if the device's Z-Wave parameter for the pushbutton also works for basic "on" commands to the device (it's only documented for the former).
1 Like
Fixed thanks!
I finally got mine installed, minor issues only. The opening for the charging adapter was a little too narrow, had to dremel the corners a little bit.
After a little dremel work...
My battery did not fit on the left hand side, by 1/8th of an inch so I had to go across on the right hand side of the motor.
2 Likes
That was about my experience, too. I had a v2 unit in the headrail of the same blinds I put the v3 in, yet the v3 charge adapter had a much harder time fitting (even though they looked nearly identical aside from opaque vs. translucent plastic--though the manual does specifically warn against interchanging the v2 and v3 pieces here). We eventually got it without the use of power tools, but I almost settled for just letting it rest in the headrail without easy access...
I also found the v3 charge adapter cable (the pre-attached micro USB cable) to be about an inch shorter than the one on the v2 unit, which made it harder to reach the motor unit. This had to be repositioned after installation, was not fun, and seems like something they could have easily avoided by keeping the cable the same length, but it is what it is. On the Z-Wave side of things, I'm much happier with how the v3 units operate (aside from some difficulty I had pairing them with S2, which I eventually got to work), so that almost makes up for it.
1 Like
I'm glad I got in at the v3 version, the improvements over v2 and your new driver made it worth the wait.
@eibyer - nice install. I had the opposite problem, my opening for the charging adapter was way to big, but the double sided tape saved me by holding the adapter in place. I also had issues (almost) placing the battery pack, but I found room for it.
I received this cable today and hope to use it to connect both a USB charger cable directly from the wall plug and the adapter charger cable at the same time. I have the included charger cable connected to the the adapter port 24.7, but don't like that it partially blocks access to the manual open/close button. So I want to connect this y cable to the motor USB port, and then connect both the wall charger USB cable and adapter port USB cable to it. That way I can charge continuously w/out having a cable blocking the manual operation button. Hopefully it will work.
https://www.amazon.com/gp/product/B089PYGB6D/ref=ppx_yo_dt_b_asin_title_o03_s00?ie=UTF8&psc=1
I'm supposed to receive my replacement unit for the one I got that would not update its FW today or tomorrow, and then the other two I ordered on the BF sale should arrive this week. It's going to be a blinds-filled holiday week.
1 Like
This device was a hit. She event took a video on her phone while the blinds were closing/opening hands-free
1 Like
OMG...you hit the jackpot! 
Quick, purchase any home automation device(s) you ever wanted before the mood wears off...
1 Like
Ok, something strange happened. We were watching tv and we hear this whirring sound. I thought it was coming from the outside then we realized it was the motor making the sound with the blinds closed. The last event in the device properties was at 5:20PM when I had it set to auto-close, nothing after that. The whirring sound happened at around 8:50PM.
The only way I could get it to stop was to click "Off" in the Device page.
Odd.
Sounds like the blinds weren't moving, so it was trying to close them when they were already closed?
Did you update the FW on it yet? Mine is on 3.02 after the update, what FW is yours on?
Just thought of something - maybe it was trying to do a calibration - if that is initiated by the blind that might be why no events would showed up?
The blinds were already closed when it happened. Mine is still on the original firmware 3.1.
I tried to open/close the blinds and it still worked but it did start making the sound again after a few seconds of closing. I hit "Off" again and then the sound stopped.
Odd...PM me if you want the FW file to see if updating the FW helps.
NVM...easier just to post it.
FYI - just found out this is a Beta FW release. Do not install this and then expect iBlinds to help you out if you have problems. It has been running fine on one of my blinds since last week, but YMMV and you have been warned.
[iBlinds v3.02 Beta FW]
Thanks, do I need a secondary controller to update fw?
I added an "off" command after 5 seconds to my webcore piston's open/close command just to be safe.
You should be able to use the new FW update app in the 2.2.4 release...it's a built in app, so you can access it from the Add Built In App button.
