I believe I know the answer here, but I'm asking anyway.
Can I control the order of execution for actions in a single rule.
For example execute a mode change before a button push? 
Well, no, but there is an order of execution. Do you need some particular relative order? Just made one tweak to that this morning already. Speak up, could be in next release.
More of an explicit order, I think. Not so much every button is after every mode change, for example. I could see needing to flip that in some circumstances. Just a general way to organize the execution order of all the actions to be performed.
1 Like
This is not really in the cards right now, as it would entail major rework of the app. If there is some specific order of execution that you need, that makes sense from a general point of view, it could be accommodated. For example, if you need mode changes to happen prior to other actions, that is a doable change (mode changes are relatively late in the current order). These needs for specific order are pretty obscure, generally speaking, since most rules only do one or two things.
The example from earlier today was a need for another rule to be resumed prior to the execution of evaluate another rule. That one makes very obvious sense, and that change was made.
Understood. I won't ask for any change at this time, I'll continue to investigate how I might accomplish what I need as it is.
Thanks
You can always force the order of execution by using a separate Action, run from the rule. These will be run in the order displayed in the app (probably alphabetic). But one Action can in turn run another Action, so you ultimately can completely control the order of things happening.
2 Likes
I ran into an order of execution issues a while ago.
Case: Push a button, flash a light to acknowledge the button push, run another rule (action). The problem was that it moved onto the action which was to turn off about 35 devices and slowed down the hub resulting in the 1 sec light flash being about 10 seconds long. Adding a 3 second delay in the action fixed the problem.
Would it be possible to have a second set of actions controlled by a delay within the same rule or a priority flag on an action that gets executed first?
This is possible now. Use Evaluate Rule, it offers a delay option. This works to run an Action or the actions of a Trigger.
Didn't see the option until I selected a rule... It's true you learn something new every day!
Thanks Bruce!
Is there a general scheme to the order of execusion at a high level? I would assume, just from anecdotal observation:
Notification Events
Switches/Dimmers
Scenes
Doors/Locks
HSM
Mode
Custom Commands/Other rules
But that is just a wild guess from my observations. Also, I'm not looking for super-granular detail. Just a 30,000 foot/Reader's Digest version. Trying to figure out if something will cause a conflict. Thanks!
Here you go:
capture devices
switch on
refresh device
poll device
z-wave poller dimmer
z-wave poller switch
stop z-wave poller dimmer
stop z-wave poller switch
toggle
flash
delay off
delay off cancel
switch per mode
delay per mode
push button
button per mode
track dimmer
set dimmer
set other dimmer
toggle dimmer
adjust dimmer
dimmer per mode
fade dimmer over time
activate scene
scene per mode
set color temp
color temp per mode
set color
garage open
garage close
lock
unlock
adjust fan
raise shade
lower shade
stop shade
adjust shade
open valve
close valve
thermostat
hsm setArm
set mode
player
toner
http get
resume rule
private Boolean true
private Boolean false
evaluate rule
rule actions
stop rule actions
pause rule
camera
notify
send sms
speak
media
switch off
restore devices
repeat seconds
repeat minutes
repeat hours
execute custom commands
1 Like
Wow....thanks!! It's interesting to see some of the noticeable differences with ST. Nothing bad, just different that's all. However, since I'm so used to the old way every time I THINK there's something wrong until I remember. It's that two seconds of "oh craa...nevermind" that happens every time. Thanks for the detail though.
Like what? Switch off moved, lots of additions.
In routines on ST my garage door always opened first in my goodbye routine...now it's much further down (almost last). SHM would be first or second and HSM is further down the list. Like I said, just little things you notice when you're watching it like a hawk (since i'm still debugging). In the grand scheme it makes no big difference.
Thank you for this list.
My issue, Vertual Switch "ODLLAuto" (Out Door Lighting Levels Automated) needs to evaluate prior to setting an unknown number of OutDoorLights to a level, often relating to the level of outdoor light.
I live rural, if it is dark, I need almost no light outside. When the day/night is transitioning, areas of my yard are darker than others, and it is helpfull to allow my eyes to adapt to the increasing/decreasing light levels. The same applies to the inside lights. Often coming from the wife's desire to just light up the night, with no requard to my eyes ability and need to adapt to the areas that are not lit. Minor issue, there are work arounds, and this is just presented as an example, not so much a request...
(this is the longest thing that I have typed since I switched to tablest. OTG for USB dongles and wireless mouse/keyboard combos!)
That order was for actions. Any conditions or trigger events by definition happen before actions. So if you had a rule with something about the level of ODLLAuto as a condition, that is going to be evaluated before any actions happen.
That explained why it works! Sweet.
1 Like
Can I extrapolate that Restrictions come before conditions and triggers? Private boolean being false, for example, means conditions or triggers are "ignored" (not evaluated) ?
Correct, Restrictions are the very first thing looked at, and if they are in effect, nothing else happens. Minor exceptions for resuming a pause, or changing Private Boolean, when those are in effect.
I have a GE zigbee dimmer switch (model ZB3001), in rule machine it does the following:
from off, if I dim to 100% it turns the light on.
from off, if I dim to any other % it pre-stages the light, but does not turn it on. if I then turn it on it will turn on to the correct %.
If I use rule machine to both turn the light on and set the dimmer (to a level lower than previous) in a single rule, the lights will briefly go full brightness and then dim back down.
It may be that this is best addressed in the generic zigbee switch driver, but would it be better if rule machine adjusted dimmers before turning on switches?
thanks
