I have been using the Reliable Locks app for some time now - [Release] Reliable Locks. It creates a driver around the existing lock that performs checks on the lock when unlocking and locking to confirm that it has actually unlocked or locked.
I thought to do the same thing with my shades as I have a number of zigbee shades that don't always do what they are told. So I started to port the code over to create a similar approach. Only problem is that I am teaching myself groovy while I do this. I posted the code here GitHub - simondsmason/Hubitat-Reliable-Shades.
Currently the app is creating one virtual shade device that wraps the original shade but in the log I am seeing references to two virtual shade devices so things are going a bit awry. I was hoping that there may be someone who is interested in this functionality and could help fix the code? Thanks.
I've found it much better to handle this directly in the driver. See here for how I've done this with my ThirdReality shades.
Basically, whenever the shades are told to do something, I store a state variable for "desiredLevel" and come back 30 seconds later and check that the current level matches the desired level and if not I have the shades commanded again too move to that position. I'd say maybe 1 in 20 times it takes a second command before they "listen", and I don't think there's ever been a case where it took a 3rd try.
This has the advantage of not cluttering my Hubitat with yet another app, and two it doesn't also create wrapper devices for each 'real' device, which also adds to clutter. Instead I just have my window shades and handle the reliability code directly in their driver.
I know it's been a couple months, but if you haven't figured out a solution, maybe this will help.
I actually threw in the towel on the wrapper approach and did it with a rule. I refresh, send command, and then put it in a loop waiting for the desired state. Each loop I wait a few seconds, refresh, send the command, rinse, repeat. I also check for closing and opening as well as closed and open. That way if the command gets through, and it is closing or opening, I give up sending the command. This means the time between resends can be very quick but it doesn’t keep doing it until closed or open.
This works well because I put a cancel at the beginning if the rule gets called again, For example if someone sends an up and then a down.
But I am going to look at your driver and see if I could implement something similar there. More for the challenge of figuring out drivers.
but I can't say that it is working perfectly. Something is not going quite right. When the slide is open or closed the while loop is not exiting - which doesn't make any sense. I have a separate thread open on this but having gotten much joy so far:
What I am thinking of doing is moving away from a while loop and just hard coding repeating the commands 2-3 times which should be sufficient.
Doing it in the driver (as mentioned by or with the approach mentioned bu @daniel.winks) or through the wrapper is probably cleaner. But the rule works.
