My iblinds sometimes fail to run the close at sunset rule I have setup. Looking at the logs, the hub sends the commands to close at sunset and the iblinds must report back that they are closed because the device shows closed in the hub device section, but the blinds are actually open.
Sometimes when it runs I can just manually command them to close. Today, I had to actually command them to open to match their reported state (even though they were already open) to then close them.
I am using the default HE driver. What would cause the device to report the wrong position?
What generations of iBlinds are you using (v2 or v3; see here if you're not sure: https://support.myiblinds.com/knowledge-base/version-identification/), and by "default HE driver," do you mean the built-in driver (guessing so but just checking), one the vendor supplied, or something else?
Also, if you enable debug logging and then run some command on the blind that doesn't actually work but the device updates anyway, what do you see for the device in Logs? This may be difficult to capture if the devices work as you expect at the moment you perform the test, and keep in mind that debug logs automatically disable themselves after 30 minutes, but it would be great information to have if you can get it since this is unusual behavior for a Hubitat driver (not for this vendor's custom driver, though, which is why I asked the above to be sure).
FWIW, I'm not a fan of iBlinds' custom driver. It doesn't wait to hear back from the devcies and just updates the status on Hubitat as soon as the command is sent. This means it will look like it works from the hub side of things even if the device is dead. Sort of the a similar problem, but the built-in driver should only update if the device is heard back from (which I personally prefer since it makes troubleshooting a dead device easier). Updating the firmware can't hurt, but I'm also curious if there wasn't just a hardware issue with the device if you had to move it and then set it back to get it where you want it--especially if the device reported back that it truly (thinks it) moved, which the Z-Wave info from debug logs will say for sure.
that is some long rtt on those blinds. I'd consider putting a repeater nearby. That said, I use the driver from their website and it's been solid for me. (Also more easily allows calibration)
Good point on the RTT. The repeater is fairly close but I will move today and see if I can bring that RTT down.
I have a couple of more blinds on the way this week and a Zwave Chime coming also, so hopefully I can get everything positioned for the lowest latency.
Ill check out the custom driver and see what happens after I get the RTT down.
Ok thanks. I did run a repair this morning on the whole zwave network because I did move the repeater after I initially paired it but I didn't see any difference.
Those RSSI are pretty bad. Silabs suggests that 17dB RSSI is the lower limit of reliability. (see below) You have:
0x0B at 13dB (Weak)
0x0C at -3dB (WAY below where it probably should work at all)
0x0D at -8dB (WAY below where it probably should work at all)
0x0E at -9dB (WAY below where it probably should work at all)
0x0F at 4dB (Extremely weak)
Your mesh as a whole is not good. Those minus dB signals are below a whisper to the hub, so it isn't shocking that things don't work well. I would suggest moving the hub to a different location or experiment with turning the hub up on one edge and/or rotate it to aim the antenna better.
You definitely need more repeaters or line-powered devices to strengthen the mesh. The unofficial number that I use where many people see a good mesh is about a dozen repeating devices (line powered or dedicated repeaters).
Thanks for the info neonturbo. After I re-ran zwave repair this morning my values increased slightly to
0x0B at 13dB (no change)
0x0C at -0db
0x0D at -5dB
0x0E at -1dB
0x0F at 2dB
The OxOC device is actually within 10 feet of the hub so its weird that its RSSI is so low.
Anyway, I had debug enabled and the rule ran at sunset, with the same result. The blinds think they are closed but they are not closed. The debug log for the event shows:
I had to command them to open first and then I could get them to close manually.
I'll look at adding more repeaters, but I dont understand why I can manually command them open or close whenever I want, they properly run the sunrise rule to open, but the sunset rule to close throws this weird logic issue.
That Z-Wave log shows a SwitchMultilevelReport from the device (hopefully the driver also said that; most will show what that got parsed into before it becomes a Hubitat event in the driver, though it doesn't really matter since you know what's coming in). That payload the device thinks it is at level 0, or closed.
Have you calibrated the blinds recently? It might not hurt to do so. The fact that you're commanding them to 0% and they're reporting back 0% strongly suggests that this is what the blinds think they're doing, so maybe there is some physical/mechanical issue that calibration might help with (though checking for proper installation wouldn't hurt; being a retrofit product, sometimes the strings or other things in the headrails get caught and affect performance). It's definitely not the driver just saying "welp, let's just say it's 0% because that's the command you sent" before it actually hears back--it's hearing back and that's what the blinds think. Hopefully that sheds some light on the issue, even if the possible fix isn't obvious.
Have you calibrated the blinds recently? It might not hurt to do so.
I just ran calibration this morning.
I just added another 2 iBlinds (got 3 more going up this weekend) and the 2 I just put up closed without an issue last night, but the bathroom blinds (original) did not. I had to manually close them. Commanding them to close when they are in this state doesn't work because I have to first command them to open (even though they are already open) and then command to close.
This morning all three blinds opened as they should. We'll see what happens tonight after the re-calibration.
I have the Aeotec doorbell/chime 6 on its way, which I hope will help solve the weak zwave network in addition to the repeater I already have. I also have two GE/Jasco fan and lights switches (right next to each other) that are powered off the mains that repeat but I don't know that they are doing a good job at that.
You can just go to the rule and click "Run Actions" to test. Also enable debug logging to check what's going on. That way for at least functioning you can see what's up. (Obviously that won't help with scheduling issues)
Looks like all is fixed after the re-calibration. They successfully closed the last two days, but I will keep monitoring it.
I also have the blinds exposed to Google Home through the Google Home Community app, and I found that some of my query values weren't correct resulting in the Google Home app not properly displaying the blinds status. I don't know if that had any impact, but putting it here in case anyone has a similar issue.
