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
Please forgive my absolute newbness, but is there a reason the handler doesn't show these as windowshades in Hubitat, and consequently Google Home or such? If I use the native HAB handler built in to HE, they don't show up in the app, and can't be shared with Google, and with this handler they show up as lights and frustrate my wife. I have zero understanding of Groovy to experiment myself, and don't want to sound ungrateful.
I don't use the stock Google Home integration, so not currently familiar w/that. I use the Community GH integration and while that offers an option to add them my iBlinds as blinds, at least as far as I was able to figure it out, I only had options to open/close the blinds using that approach, I could not set them to a specific "dim" level (e.g., Hey Google, set the family room blinds to 25%).
So I currently have them integrated as Dimmers, and can say:
- Hey Google, open the Family Room Blinds (opens to default open setting in driver)
- Hey Google, close the Family Room Blinds
- Hey Google, set the Family Room Blinds to 45% or whatever % desired
I would think that should work for your wife.
You can also replace "Open" and "Close" with "Turn on" and "Turn off" if you wish, but obviously "Open" and "Close" make more sense for blinds.
FYI, the Community Google Home thread is below...it says "Alpha" but it is very robutst:
I'm also not familiar with Google Home, but if you want to make this a "pure" window shade device on Hubitat with no dimmer-type capabilities, you can comment out this line in the driver:
capability "SwitchLevel"
that is, change it to this:
// capability "SwitchLevel"
I left this in since a lot of early blinds/shades drivers did it, and it opens up compatibility with a wider variety of apps (lots work with dimmers, not as many with shades). I'm not sure if it will solve your problem, and it may require a "rediscovery" (removal and re-add?) in GH, but it's worth a try if you wanted to see if it helps--if the above doesn't. But I'm not familiar with either.
1 Like
@bertabcd1234/Robert & @Eric_iblinds / Eric:
I just updated three of my blinds to Beta FW 3.07 and they have stopped reporting status in the driver page. If I open/close the status stays the same. I can update status by hitting Refresh.
Not sure if there is something new in the Beta 3.07 FW that the driver needs to know about, or if it's just an issue w/the beta FW that it isn't reporting status properly.
They do seem to work normally, opening and closing using buttons on driver page even if the reported open/close status doesn't update.
Logs from one of the blinds w/a close and open command.
Hmm. Can you use the Basic Z-Wave Tool to check the value of parameter 3, or uncomment the line in this driver where it lets you set it (toward the top)? The default is 0, but for Hubitat it must be set to 1. The driver does this on its own with a "Configure," so that's something you can try without doing any of this if you want to as well.
If the firmware update changed how this parameter works, that would also be worth knowing. Nothing in your logs shows a report coming in with the new level, so it's at least not just the driver ignoring it. (Also, I don't think I have updated any of my units to this firmware yet but can try if it's available.)
Thanks very much, Robert.
Just saw this, and I'll have to try in the AM, have an early meeting w/wife and contractor and have to hit the hay.
The 3.07 version is available on the iBlinds site if you want to try it:
https://support.myiblinds.com/knowledge-base/iblinds-v3-firmware/
A few minutes to get things done in bed ... Parameter 3 looks good.
28522021-09-18 11:17:03.960 pm infoConfigurationReport- parameterNumber:3, size:1, value:1
I down-graded one of my blinds to 3.06 and it still isn't reporting status unless I hit Refresh. So unclear if the problem w/reporting is about FW version, or some other issue related to doing a FW upgrade. Let me know if you want any additional information.
Have you tried turning it off and back on again? 
(Seriously, reboot the blinds, though a firmware update might also effectively do the same...)
Otherwise, maybe try changing parameter 3 to 0 and then back to 1. I've seen things like that be necessary with other devices in the past, though generally only if that parameter was newly added. Not so sure about this, but I'm not sure what else you could try to make the device send status back to the hub (or really why there is a parameter to sisane this in the first place).
1 Like
Rebooting didn't help, so no luck on the simple resolution. 
Also changed Parameter 3 to zero and back to one, and no joy. Totally bizarre...
What did we decide about updating what is not broken??!!
I was waiting for you... 
In a moment of unbridled optimism and generosity I decided I would help test the beta FW. I know...I need to start going back to meetings. 
I'm in the Hubitat beta program as well so clearly a glutton for punishment.
Did we decide to pair the blinds with S2 enabled or not? I'm about to pair a blind that got scrambled in the last Hubslide.
All of mine are paired w/out S2. Prefer less complication, and should generate less hub traffic. But that's just me...and we know how I turned out.
Where are we with the iBlinds accurately reporting their current status back to the Hubitat? Is that what is called "supervision? Is that a firmware issue or a driver issue?
My shade dashboard never seems to know where the shades really are set currently.
All shades are open now.
iBlinds v2 never report status to the hub. It must be retrieved with a "refresh," or my driver requests one a certain amount of time after an open/close/set position command is sent (and they have a further oddity in that they don't like it if a request is sent while they are still moving). iBlinds has (or at least had?) a driver on their site that just "optimistically" set the level based on what you last sent, regardless of whether it actually happened. These are really the only options with this hardware/firmware.
iBlinds v3 (at least with original firmware; I don't know if this changed) do not report back by default. However, parameter 3 can be set to 1 , which my driver does by default. I'd guess Hubitat's built-in driver does the same. If that didn't get set or got un-set for some reason, a "Configure" (with my driver, at least) will set it again, or you could use the Basic Z-Wave Tool to check/set for sure.
That being said, @danabw is saying above that this doesn't work for him. I can check later when I'm home but don't think I've noticed any issues recently...
Also, Z-Wave Supervision is a different issue--it's one way of trying to ensure a command was actually sent. This only works with S2 (at least with this hardware--I'm not sure if that's necessarily universally true), so I'd actually consider that an advantage theoretically...except that if you have a v3 unit that doesn't respond, which Supervision might help with (it will try to re-send in a few seconds), my experience suggests that it won't respond a few seconds later, either. Might take a minute or two or a reboot...
1 Like
