Thanks! I'll check and re-confirm. I meant to do that (check the actual values currently set in the driver before posting), but fankly just forgot.
It is working properly on one of my blinds which is interesting. I'll report back! 
And here we are. Parameter 2 is set to 1, which I believe is Reverse Close.
So this becomes a question to iBlinds support. I will try running another calibration first, to see if that resolves it. I did that yesterday but can't hurt to try it again.
Thanks for reminding me about checking the parameters.
Update on my post below:
Possibly this should start w/a DOH... 
The issue appears to be the orientation of the motor in the blinds. The close direction results depened on whether the motor is positioned in the blnds so that the IN/EX & CLBR buttons are near the back of the blinds, or near the front. In some of my blinds I have the buttons near the back, in others, near the front. For some reason my blinds were installed in two different orientations where the control rod was biased towards the back in some, and towards the front in others.
Buttons towards the back below. I believe this is the "expected" orientation where close up/down works as expected.
If the motor has to be rotated 180 degrees on blinds because the control rod is closer to the front of the blinds (like below), then close up/down get reversed.
iBlinds support is probably going to update the support docs to simplify the wording so that it's less confusing, since they can't always be sure of the orientation in which direction the motor has been installed. 
Regarding blinds close direction - I think the issue is that on the beta FW I've been testing they have reversed the parameters. My blinds (on FW 3.02) are closing up when I set it to down, and down when I set it to up. I've passed that info on to iBlinds...but I think that's the issue. Documentation and FW don't match.
I don't use open and close.
In SharpTools Rules I use SetLevel 1 or SetLevel 50 or SetLevel 99.
I use on and off in my automations (and rely on individual blind device settings for default open position). Since i've moved to scenes blinds open/close has been 100% perfect. That also coincided w/update to 3.03 w/stronger radio setting so that could be contributing.
@bertabcd1234...appreciate your insight on this...I have a severe WAF issue. 
Need to figure this out, as it will likely determine if I have any WAF on iBlinds installed in the office (that she initially loved), and future iBlinds planned for remodeled master bedroom.
Blinds had been running on an automation to open them in the AM and close around sunset. Wife now wants to be able to set the open/close level of the blinds via buttons. She will not use voice no matter what, just hates that for some reason.
I have a pico available to do the controlling of the blinds but need a way to allow her to dim them up and down w/it. Either continuously, or in some relatively low (5 to 10%) increment. I do something similar in Rule Machine for some celiing fan lights I have connected w/the Bond integration, which allows me to use startDimming and stopDimming custom commands to dim up/down to a desired level in a RM rule. Held on button 2 or 4 starts dimming and Released then stops dimming. Since the light dimming just goes around in a circle on the fan lights that works (dims down to lowest value and starts dimming back up - you can hold the button down until your desired light level is reached and then released. I don't think that would work w/the blinds...and they don't appear to have "startDimming" or "stopDimming" custom commands available.
Can you think of a way w/your driver as it is now that I can provide her a way to adjust the blinds to make them more opened or closed in a gradual way using a pico remote? Even steps of 5 or 10% could work. A Pico has five buttons w/both pushed and held options that I can apply to this (though it needs to be relatively simple for her to do, she won't spend much time on trying to remember how to do things...) [sigh]
Thanks for any suggestions.
As far as I know, iBlinds do not support the equivalent Z-Wave commands that Hubitat's startLevelChange() and stopLevelChange() commands (for dimmers/bulbs) usually map to, which is what you'd need for that "raise/lower while holding" thing it work. I know this was true for v2. I don't think I've ever actually tested v3. (In Hubitat's Z-Wave classes, this would be something like BasicWindowCoveringStartLevelChange or SwitchMutliLevelStartLevelChange). That would be neat if they do, though given the fact that they sometimes seem to have a bit of delay in responding, I'm not sure it would really be as cool as it sounds, regardless.
Something like "press a button to open/close by 10%" would be easy to do with a Rule or Button Controller. But the issue with most drivers (which in any other case I think is good--and it's why mine does this) is that they don't report new levels until the device responds back with the new level. And the app is likely to read the current state. So. on the first button press, your app or rule will do something like "OK, this button was pressed, and the current level is 50, so subtract 10 and set it to 40." If you want it to go down by 20 instead and press the button a second time without waiting for the new level, the second press will also read the current level as 50 and do the same thing, with no change in result. So, you'd need an app (or rule) written specifically with this type of device in mind that might temporarily "cache" the level while adjusting until the device (hopefully) responds back and they can verify in-sync-ness.
Otherwise, my Dimmer Button Controller app is pretty close to that aside from the caching thing. I had in mind to fork it into a "Blinds Button Controller" thing with a bit less things (like multi-presses that you probably don't need in this case) and with that caching thing (for devices that may take longer than you'd generally wait to report back). I haven't done that yet and don't know if/when I will. A rule could track with a global or local variable or something (maybe global so it can be "synced" when it does report back via another rule triggered on that?).
iBlinds' provided drivers would actually fare better here since they show the "new" level in Hubitat immediately, even if it never actually happens in real life, though that's not without other problems IMHO.
2 Likes
Thanks very much. I'll give your Dimmer Button Controller a whirl (already had it installed) and see how that goes. I'm almost at the point of just ripping them out and letting her deal w/them manually again. Must remain calm...
If your app doesn't seem to work then I'll start in on Rule Machine...not my favorite, and I'll likely have to post another "How do I do this?!?!" thread in the RM section and reaffirm my weak RM skills. 
Hi @danabw, I don't think a true 'dimmer' action will work with the blinds in this case just due to the response time. There's too much of a lag between blind movement and button control to do it 'real time'. Any possibility of using an actual dimmer with an LED bar to signify %? You can use the LED as a representative of the open % and use the dimmer level as the setPosition value.
Personally, I have a vertical slider on my dashboard to do what you're after so I've not attempted any of this code.
1 Like
Thanks for your suggestions...I've teed up Robert's app and will give it a quick look later today or tomorrow to see how it looks. She should only need/want to do this very occassionally, and a single press (change 15%) should get her where she wants so I'm hopefull that for those limited use-cases it will work.
By dimmer you mean a dimmer switch, correct? There are no dimmer switches that are easily reached in the office from where she usually sits, so not sure that would work for her. I hadn't thought about a slider on a dashboard...DOH! That could be an option. I have a tablet that I setup a dashboard on in the kitchen, gets little use. I can move that to the office and see if that works for her. There are three blinds, if groups are supported in a dashboard then I could have one slider to control all three...hmmm.
Yes, an actual dimmer, the HomeSeer I have has an LED bar to roughly indicate light level; but it sounds like that's not an option. A single press % is a good compromise, too.
Lemme know if you want the code for the vertical slider (it's pretty cool with the 'all touch' tile option from the company that can't be named ). I have 3 blinds setup with a single vertical slider now. Actually I have 4 sliders so I can do them individually or all at once, then I used a TileMaster for the actual blind conditions. The 3 on the left are the individuals and the far right slider is the override for all 3.
When they calibrated I had to determine what the lower, opened, and upper limits were that's what the numbers in () are. I have them close 'just tight' so the motor doesn't labor.
Thanks!
Just did some really quick testing - I tried two groups - one using Bryan's Groups app, and one w/the Groups and Scenes app. Then added the virtual group devices to my dashboard as Shade type, but moving the slider doesn't have any effect.
If the code is pretty easy to implement and configure for my purposes, I'd like to try it. I too use the dashboard option from the unamed.
I think this could be a solution that would give her exactly what she wants. (Aside from me and all my automations out of the house.)
Did some testing w/your Dimmer Button control app, and it does not work well w/your "smarter" community driver - the blinds stop responding to the button presses after one change, usually.
Switched to the "dumb" iBlinds driver, and your Dimmer Button controller app works great - tap, blind changes, tap again (not waiting), and blind changes again. Looks good, might make wife happy again.
Sure you can give this a try... I have 3 of these rules, one for each blind, the rules are identical just with different devices, this is the only rule that actually moves the blinds. The 'Blind_PoolPos' is a virtual shade (and used for the vertical slider), and the 'BlindPosReq' is simply a local variable.
It looks like a lot but it does a few simple things, it caps the lower and upper limit so the blind motor doesn't labor, checks to make sure that the requested position is worth-while to send (i.e. if the blind is at 40% and I request 42% then I don't even bother sending the command) and does a retry after 10s just in case it didn't make it.
Then I have this 1 rule for the blinds position override which simply sends that master position request to all three of the rules described above. 'Family Room Shades' (this is the one I use with Alexa and she sometimes confuses 'blinds' with 'lights' so I called it 'shades') is a virtual dimmer and used for the 4th vertical slider.
I have other rules that set the desired position based on time & weekday/weekend and they all look the same, just with different values. Then the master tile is a display only for the actual blind values and the battery level (this isn't displayed on a normal blind tile). I set it up this way because this gave me the most flexibility; between having to cap the min/max values, attempt retries, timed events, Alexa and Dashboard control this was the cleanest.
Hope this hepls,
1 Like
Thanks for sharing all of that! I will have some time to work on this starting in the week, diving into home automation on weekends is verboten (unless she's asleep).
After yesterday's "I NEED CONTROL" freak out, we had a calmer discussion today and I've set up some automated dimming of the blinds in the early evening to manage the amount of sun comming into the office for her. Explained (mansplained?! ) that the best automations are usually the ones you don't have to remember to do yourself.
Combined w/that I've set a button on her Pico that uses @bertabcd1234's button dimmer app to set the blinds progressively (35 to 30 to 25) using three scenes, which works very well.
All quiet on the western front...for now.
When I have time this week I'm going to look into your slider, as I'd like to have that for myself on my dashboard.
I have been following your discussion here the past couple weeks as I am trying to figure out a couple problems I have been with a few units. Using the community driver some of my blinds won't execute an automation, the button becomes unresponsive and a refresh is required to get the blind to respond. Ultimately I reached out to iBlinds and sent to update the firmware. I have tried 2 methods without any success. First I tried the built in Device Firmware Updater and get a raange of errors from not uploading the file to file doesn't match. Second I did the Secondary Controller Method with an Aeotec stick I have around. It looked good until I got a "Status: does not match the firmware target=0x04". I am using the US version of the firmware since I thought that might be the problem. Would anyone have any tips I might need? TIA
1 Like
I have found that the only FW update approach that is 100% successful is using PC Controller app and UZB stick as primary controller.
That means you have to exclude the blinds from your hub, include them to the UZB stick as the primary controller, do the update, exclude from UZB and then re-include to HE.
It's a PITA, but works for me. I have had inconsistent results w/HE FW updater, and using a UZB stick as a secondary controller for FW updates rarely worked.
If you have automations you don't want to break you can create a virtual switch and put it in the automation so you have a placeholder while you exclude, update, re-include.
That is the method I used earlier this afternoon and I just took another try at it and it worked! I don't know what I did differently but I am on my second unit now and it completed without a problem. I have about 8 that I need to get done first, which will be a little time consuming. Only a handful of the units worked today out of the 22. I feel like these are getting more buggy as time continues. Wonder how accurate the battery reporting is, they say 100 even on the ones that don't have the solar panels and they have been in use for a couple weeks now.
1 Like
22! OK...I think we have a new record holder.
Glad you FW updates are going well...any FW after 3.03 will have the more powerful radio settings so that definitely should help resolve issues w/responsiveness and consistency. W/3.03 and using scenes for setting the blinds they have been perfect.
1 Like
