Newbee here, I have a simple rule that turns on two outdoor light switches 20 minutes after sunset and then turns them off at 11:15PM.
I noticed the other night only one of the two devices turned off at 11:15PM.
I have also noticed on my all on and all offf rules sometimes the execution fished before all the actions are completed. Mind you this is rare, but it does happen. Wondering if there is ened to end confirmation of every action or simply an attempt to execute the action? Not sure the handshaking protocol underneath this.
Lastly I noticed the enable on/off optimization switch in the body of the simple rule. Is it recommended to turn this on or off and will it address my inconsistency issue?
Thanks for any light on this.....
Logs would help reveal the clues here.
My initial suspicion is a weak/compromised mesh, but logs would help get to the root issue.
4 Likes
Here are the two devices in my simple rule. They seem to have very good no hop, comms with Hubitat.
I did turn on the "enable on/off optimization" switch in the rule and it ran properly last night. Not sure if this is cause and effect or just randomness. So will monitor a few days to see what happens. What exactly does on/off optimization do?
On the same system I have a rule machine rule call "kitchen task" which is triggered by various button presses (and a virtual switch) in the home but only causes two dimmer switches to dim to 100%. That's all. I noticed a few mornings when I trigger the rule with a button press (Zooz ZEN32 scene button) the rule runs but only turns on the second light (kitchen island) in the rule, the first light is skipped (Kitchen Ceiling). If I press the switch again the first light in the action sequence then turns on.
I don't seem to see the enable on/off optimization in the rule machine pages. Is this not an option for these types of rules?
Here are stats for those two devices:
the is the kitchen task rule:
Just wondering why actions are not completed reliably and there isn't more handshaking in the system to confirm all the actions were executed and if not some sort of error code returned. This is why I left a different hub platform recently due to unreliable execution of scenes. Hubitat is much better but there are still holes it seems. Just wondering if I am missing something obvious here....
I still see intermittent execution of this rule. This morning I pressed the wall button (button 2 on a ZEN32 wall scene controller) and the Kitchen task ran but only the Kitchen ceiling lights went on. I waited a couple minutes just to be sure there wasn't an abnormal delay but the kitchen island lights did not come on. So I pressed the 2 button again and then the kitchen island lights came on. Below are the logs for the various devices and the rule. As shown it is very simple. The pressing of button 2 turns on a virtual switch, that virtual switch triggers the rule "kitchen task" which only has two actions to turn on each of the two light fixtures. (I stagger the actions in time one second thinking maybe flooding a action queue might have been the problem.)
The fact the logs show the button was pressed and the button press did, in turn, trigger turning on the virtual switch which,in turn, triggered the rule to run seems to show the logic is sound. The logs also show both lights had been turned off since 11:30 the prior evening, they they both started in the off state.
Why then doesn't the rule Kitchen task faithfully turn on the kitchen island light? I deduce that a rule only changes state of a device if it thinks the device needs to change state (ie it doesn;t turn on an already on device). I see my second running of the task doesn't attempt to turn on the already on kitchen ceiling lights.
I am wondering if Hubitat has a state wrong for the kitchen island and thinks it is one when I first run the scene thus doesn't issue the on command. This wouldn't explain then why it worked on the second press (unless somehow the state got corrected).
So I am puzzled here, this seems very basic functionality and that the protocol and logic would have enough handshaking to confirm end to end the actions completed. One last thing both these switches are beside each other in a four gang box. Each of there are 3 ZEN77 dimmers and one ZEN32 scene controller in the various bays. The ZEN32 used to run this is one of the switches and the two dimmers are all colocated. Wondering of this has an RF proximity issue?? One radio interfering with another?
Any ideas welcome, I am running out of ideas on this one. Would prefer rock solid execution instead of "sometimes" it works execution....
To confirm, you have a rule called "Kitchen Task" and a virtual switch called "Kitchen Task" - is that correct?
I'm no rules guru, but if this was me, I think I'd try to get the virtual device out of the picture, at least to begin with...
For the Kitchen Task rule, I'd remove the triggers and save it. Then I'd instead set up the (physical) button devices in Button Controller (BC), and just call the Kitchen Task rule from those BC setups with a "Run rule actions" command.
That just saves you from having to recreate the Kitchen Task rule actions in each Button Controller.
If you want to keep the virtual switch for more flexibility, you could just make that the sole trigger for the rule -- that won't affect the ability to use "Run rule actions" in BC with physical devices. But for sanity's sake, I'd rename the virtual switch to something like "Kitchen Task - VS".
@CuriousB can you post your z-wave details page in its entirety? Please use windows snip to post it.
Here is the ZWave details output
to hydro311... yes a rule called kitchen task and a virtual switch called kitchen task, Yes would have been clearer if I notated the VS and rule differently but that shouldn't contribute to the erratic execution.
The fact that the rule launches each time used seems to validate the triggering scheme albeit perhaps a bit over complex with the VS but it was simple way for me to trigger the rule from the dashboard and a few ZEN32 locations.
It seems the actions are not faithfully executed as the root of it. Why wold part of the actions run one time and not another? Also I think that certain actions are skipped if the device is already in the intended state seems to be a big clue. I think the rules engine is seeing the wrong starting state and intentionally skipping that action line.
Sorry, I have no idea. If me, I'd next try some other ways of accomplishing the task to see if that shakes something loose... You could try setting this up in Room Lighting - that has a "Force" option, and builds in the Room Lights Activator as its own virtual switch.
In Button Controller or Rule Machine, you can still use the "Run rule actions" option to call the Room Lights rule too as necessary.
You seem to have some high route changes for such a large mesh...
What model hub do you have?
Is it located centrally?
If you're having consistent issues with the switch try throwing a repeater near by and/or try re pairing with s2 and see if that helps. (note may or may not be slower but command should register better)
Newest C8 pro
Located approx 8’ from the switches in question. Hub is located centrally and approx 7’ high on top of kitchen cabinet. Ethernet back to router. These switches are in fact the closest devices to Hubitat.
I thought most of links were single hop @ 100k back to hub hence repeats not needed.
I am just surprised Hubitat doesn’t have some sort of action confirmation/ retry handshake so that device actions are assured instead of attempted. That is the reason I left a different controller brand behind, it only attempted a state change and didn’t flag failure of same.
S2 will do that. As I mentioned, try excluding and then re-pairing the switches in question with s2
2 Likes
OK, I will try S2 mode. Kind of bummed because during inclusion Hubitat recommends skipping S2. I had S2 mode used on my other controller but considered it overkill per Hubitat's recommendation...
So 30 plus devices to redo....
I would only do it for now with the problematic ones.
Another thing I would try even before this is to swap antennas and see if those route changes come down. If they do it's indicative of a bad antenna.
