Curious about the "looping"
I have 2 sets of 3 blinds in 2 global device vars in WebCore.
I just loop through each device var with a 2 sec delay between commands and they work fine.
Sounds like you're doing the old school delay technique of NOP iterations to burn CPU cycles.
I'm doing a repeat while loop, essentially looking at the status of the blinds and if anyone of them is open/closed then it will pass through the actions again. Here's a snip, I have a global variable setup determining how many times I want it to repeat itself.
So the first step is to send the command, then delay, then refresh, then loop. This is all in an attempt to wake them up.
Not to familiar with what you were describing though.
Are they failing when closing only? Do they report closed but are still open?
Today they all closed properly except one. Looking at that one, it currently thinks it is closed but it is in fact open.
Here are the logs for today:
That would be why the loop isn't running. But again, I don't think refresh does anything for this. For some reason the blind reports or believes it is closed when it is not. The only way I have found to fix this is to manually send open command and then close. I have one that I stopped fighting and now set the position to 1 before send close command to the rest of the group. I guess I should contact them about it and see what they say but really haven't had the time or want to do massive troubleshooting. Position 1 is so close to closed that it is good enough for that blind. But if you have more than 1 doing this than it would probably be a bit more annoying 
Now you have me wanting to figure it out. I just ran a rule that made it close properly by itself. Going to try it again later, 1 minute before the others close after sunset to see what happens.
I was pondering a similar idea myself.
What if I send it a command to open before sending it one to close so that any blind that thinks it is closed would refresh to open? The reason why is because of what you stated, refresh does nothing to fix it because the blind for some reason or another does not recognize it is open based on its tilt level.
But that would then cause a bigger issue, what if it stays Open because of Network congestion? I think your idea of setting it to 1 before setting it to 0 is probably a good one but holy crap why do we have to go through this to get expected behaviors from very basic and standard features?
It seems to me like the root cause of this isn't the hardware but the software. Other than refresh, is there any other command to get it to wake up and realize it is in the wrong status?
The features open and close are very basic, but the motor sitting inside a metal cage (assuming your blinds' housings are metal) does complicate things by adding "Faraday-cage" issues. 
Even on the C8\C8 pro with the external antenna, I've never gotten better than a 40kbps connection to my five blinds.
I only get 40k on mine as well.
I just "assumed" that's all they were capable of.
C8 as well with a non-stock ZB antenna.
I assumed the same, 40kbps looks to be the maximum they get. But without being an expert in Z-Wave technology I would assume that all that means is that the connection is not as fast as other devices like switches, bulbs, thermostats or sensors.
It shouldn't mean that the device is returning a wrong status. Right?
Now that you mention it, I think I may remember something along those lines., but been a while.
I would expect it means that the device status never got properly updated from the device to the hub, not that the device doesn't know its own state. But @bertabcd1234 Is the guru on this stuff.
I'm not exactly sure what the question is, but if it's that 40 Kpbs indicates a "wrong status," no, that is simply something Z-Wave devices can choose to do. Higher speeds generally indicate a better connection (if the device is capable of that, and I'm pretty sure at least the 700-series variants of these should be capable of 100 Kpbs), but one reason it may choose a lower speed is to prioritize range. And with these often being installed in unfortunate locations like inside metal headrails, that is quite likely to be a priority for the device.
I also think the differing behavior above backs up my suspicion about luck, not the driver, but that's another story. 
2 Likes
If it is the same blind that doesn't close, this would probably work. As long as it never closes, otherwise if it closes sometimes you may end up reopening it and closing it again or maybe not closing the second time.
My one blind actually closed correctly when the new rule ran to close it, I created a separate rule to close it 1 minute before the old rule to close the group ran. So I updated the old rule to close the blind 30 seconds before it closes the group. I will see if it works tonight.
I'm not too concerned about the speed, the speed to me indicates that 40kbps is just a slower connection but the device itself should still function.
The problem is when the device reports a status of close, hubitat refreshes and it still says closed but it is actually open.
@CaptWoody do you have yours setup in groups or individual blinds? I'm thinking about using your idea as a fail-safe in case I see a more consistent pattern of blinds missing their automation. Set the rule to position them to 1 and then to close or maybe just set their position to 0 instead of setting them to close. The position itself is independent from the status of open/close.
Hope this makes sense.
On a brighter side, iBlinds sent me the two replacement batteries so I should be getting those two motors sorted out this weekend.
Has anyone ever attempted to add aftermarket antennas to these motors?
I use Room Lighting to group them. I have few different groups like front, back and all as well as few others that control other combinations. This works really well, other than the one blind that just doesn't seem to want to close properly.
I think using the position like you stated is probably the easiest way to resolve it, as it has worked for me for over a year. But now I'm a dog with a bone and have to try to figure out how to make it work correctly 
If I get time this week and bored enough, I may do what I have been putting off for over a year and swap motors with another blind closer to the hub to see if it makes a difference. Not sure it will as it is next to another blind that works perfectly but have seen stranger things.
I think the faulty batteries may have caused part of the problem. iBlinds sent me replacement batteries and they are working well now.
Of course this is only a day or two worth of testing so let's see how long they're consistent.
1 Like
2 Likes
Hopefully no news is good news for you.
So after some trouble shooting it turns out that the one blind was having issues with closing only and mostly when the command was coming from Room Lighting. So I swapped it with one of the motors that is in the same room as the hub. This seems to have fixed the issue. Guess I will chalk it up to weak radio in the motor or just another thing that test my patience 
1 Like
I have over 100 z-wave devices spread over 5 hubs. I have two c-7s, two c-8s, and a c-8pro. Over the years I have worked with all my wireless devices to try to get them to behave in the most reliable way possible. And for the most part, all is going well. I have 17 iBlinds v3.1 on 3.12 firmware. They are the bane of my smarthome.
I have spent more time on these devices than anything else in my home. For much of the time, they were all on c-7s. 14 of them now run on the c-8pro and this does help greatly. But the hub sits in a room where 4 of the blinds are and two work flawlessly while there have been issues with the other two. They are all connected directly. They have been connected with and without s2. I prefer s2, seems to do better. My rules always have catches for when these buggers don't want to behave. Usually with a command to do what it should do, a refresh, checks for each blind afterwards with followup commands to retry, refresh, repeat as needed. Makes them more reliable. But still, there will be issues every now and then. And using a remote to control them is embarrassing as people often wonder when they will actually open/close after pressing the button. I just tell them to be patient.
But for the most part, I do not think the problems these run into have anything to do with the mesh. Or the hub, in general. The newer radio seems to help, but I think that has to do with the radio in the iblind devices. All of them connect at 40kbs.
Anyway, one thing I would like to point out after reading the above posts. Occasionally, a blind would make this horrible squeeling noise as it would not stop trying to close the blinds. This would require opening up the blind and turning off the battery and turning it back on. If this was not done, then the thing would die and sometimes leave the blind in a state where it would not work again. This has happened maybe 8-10 times over the last 4 years but mostly over the last year as the devices have aged. I figured it was a battery issue. I have replaced batteries before and had them work again, sometimes not. Sometimes they would work but the battery would only report 1% afterwards (as I have noticed above in some of your posts). Recently I had three blinds not working as I was on vacation and not at home to take care of them. Once home, I set up a replacement motor and battery before putting them into the blinds. I had it connected to the hub and checked that it was functioning as expected. I wanted to be sure the battery and motor worked together prior to installing as it is not fun to replace these things. After replacing, I found that I still had the same problem. So, something else was the problem. The solar panel seemed like the only thing that could be affecting it as it was adding a power source to the system. After disconnecting the solar panel and restarting, everything worked again. I disconnected the solar panel from the other two blinds that were not working and viola! Everything worked!
I still have 14 of these that are working with the solar panel although some do not stay at 100% and need a manual charge from time to time. But the three that no longer have a solar panel attached have been working much better now.
Not saying that this is the reason for all their issues, (I have only been operating these three without solar for about a week now) but you may want to consider it when debugging these things.
1 Like
