It appears that this grouping and metering does not solve the issue. I mean, it may, as it has done to a couple of people that posted here, but it is not guaranteed that it will continue to work or that it will work for others.
As @JasonJoel said, the way to go is really to have the rule engine take care of this. From my very naive perspective, it doesn't seem that hard to implement: store state of devices before rule runs, compare state of devices after rules runs with desired state and redo commands that didn't go trough until desired state equals final state or until some retry threshold is reached.
While I certainly follow your logic (on wanting a "Verify" feature in RM, or at least for Scenes, to know they are "Set", which is already testable), I'd hasten to point out that such a feedback mechanism may face too many roadblocks to be workable in practice.
For example:
A poorly implemented device may not issue a status response sufficiently quickly;
An older non-Plus device me require Z-Wave polling that isn't set up yet;
I've seen a dimmer whose connected light is ON but it reports OFF;
"Verify" would need to know "when to stop asking", which in turn might keep the Rule "active" longer than intended, with downstream ramifications;
Grouping (of devices) and Metering (of commands) both exist and address the underlying problem, so hypothetically should permit a manageable resolution;
I'm not here to warn "Careful what you wish for" since we've all had similar thoughts, but I am suggesting "It may not work the way you think" just so expectations are set accordingly.
You can always have the rule run a second time after a few seconds (or more) of delay. As long as you are using a “group device “ with on/off optimization enabled, it will check the state of each device and only send commands to the devices that require it. That way the mesh isn’t burdened by needless commands being sent. This should get you the reliability you seek since you said your devices did report their states correctly.
Just make sure the delay is longer than the time it takes for the last device to report its status to the hub.
The concerns you listed are very real and they all can be addressed by simply setting a toggle for the rule in question and a retry limit. You would only toggle the "verify status and fix" setting if your devices behave properly and the retry limit would take care of the time to stop trying.
This seem a really good suggestion to add to the rule. So, the question is, how to I make the "simple rule" run again after a few seconds? whould't that cause a loop? I the last action of "rule 1" is to run "rule 1" again. it would loop forever.
In programmer parlance, what you seek is the analog of a DO-UNTIL loop which has been mentioned elsewhere on the Forum (sorry, no link jumps to mind). I believe there is a WAIT UNTIL function in RM, so explore that, too.
I'll keep this idea rolling around in the back of my head for now and get back to you if a lightbulb comes (verifiably) ON, lol.
EDIT: This post may be illustrative of the direction you want to take this.
You would have to use Rule Machine, and a second action with a delay when the button is pushed. You are correct that this could cause problems, especially if you tried to turn back on or off before the rule completed, but there are ways to cancel the actions. Perhaps @bravenel would be able to post an example since he is the master, and will likely do it more elegantly.
I just want to press a button and turn on some devices and long press it and turn them off. I've told this many times before, I'm a simple man with simple needs.
The do-until parlance should be directed to the hubitat dev's I guess as this may help them fix what they sell as " reliable". And I'm ranting again. just can't help myself. sorry.
Imagine going to a hardware store and buying a switch that should turn on/off when pressed but only turns on/off when it feels like it and then you have to concoct a very twisted dance of steps to maybe do what you want. come on.
In my opinion, they should have addressed this long before improving on other things like allowing for more complex rules. If the most basic of the basic doesn't work why put effort on more complex stuff?
The good part is that, thanks to the many helpful people that came to this thread to help me ( you included ), I mean, everyone, I may have a solution that works. I will have to test it, but the goal right now is to try to group them as first suggested by @stephen_nutt and maybe try to implement some kind of re-run of the rule as suggested by @Ken_Fraleigh . Just waiting for him to tell me how to go about that.
By way of anecdote, allow me to illustrate that I'm thinking very much along the same "It should just work" line of reasoning as you...
When I wired in my very first X-10 switch, back in the mid 1980s, its job was to simply turn a spotlight on and off. Push once for ON, push again for OFF. Simple!
Many nights, however, after my X-10 timer sent that switch its OFF command, the light would indeed go OFF for a moment, and then turn ON again. More times than not, in fact!
This drove me bonkers. No matter what I did, troubleshooting the problem led me nowhere. So I brought the switch and its controller back to Radio Shack, demanding a refund. They insisted it worked fine (which was true) and that I should give it another go, looking for problems down the line — such as line interference, noisy appliances, transformer signal bleed, etc.
Turns out the kid across the street had bought his own X-10 kit and, like me, left his first module (a receptacle, into which his television was plugged) set to the default setting, Channel A, Device 1.
Every time I was turning off my spotlight, his TV went off. So he clicked his TV back on. Turning my light back on!!
Moral: We will find you a workable (and satisfyingly basic) solution. It just might take winding down a few dead ends before the answer becomes obvious. Welcome to the world of home automation!
that one story made my day. really. thanks for sharing it!
And for everyone else that came here to my rescue, many many thanks. I really appreciate it.
I had one similar with two wireless mouses set on the same channel on the same office. Sometimes I would be called by one of them telling me that his mouse was possessed. oh well. At least we can have a laugh.
I don't think I have a weak mesh as I can toggle them individually with no issue at all and the devices that don't follow the rule are not always the same devices. it's very random.
Having said that, and even having most of the devices directly connected or only one device away ( just tree or four on this state ), the thing is that the rule should try as much as possible to do what it was told to do without any gimmicks as the ones suggested here and that I am going to try.
I agree that it would be nice if rules were "smarter" and retry failed action attempts.
I think you were clear in your desire/request in this thread too.
So in summary - it is what it is today. One needs to live with it as-is, or implement workarounds (of which there were a number of good suggestions for above). Maybe Hubitat will change this in the future based on the feedback - only time will tell.
They almost never commit/comment on new features until they are actively working on it (especially something like this which would be quite a lot of engineering effort), so I wouldn't expect official feedback 'soon'.
I suffer from lost zwave commands on a daily basis!!!
Here is a belt and braces method using webCoRE... loops until all lights are turned off, with the ability to set a limit on the number of loops (to prevent an endless cycle should a device be faulty or something).
You will need to play about with the command execution delay, the wait between loops and max number of loops... but I can usually find a happy balance with a bit of trial and error.
Isn't this similar to the approach of using groups with on/off optimization and running the rule a couple of times? @RobinWinbourne
also, the developer tag that you have means you are an hubitat developer? If so, can you tell me why my feature request haven't been implemented yet in the code before, it it because it is complex to do or simply because it's not a priority?
