Have two rules, one of the two executes it's mission about a second later than I'd expect, which is critically slow. No Delays or Waits are in the rules.
One rule sends a GET to an external device, the other rule has the simple job of turning on an MHCOZY relay. I can turn the relay on via the Device Driver and I don't see/perceive that 1 second lag, but when the rules run I have time stamps that show at least 1 second delay before that MHCOZY relay is on.
So my question is more conceptual here, I'm not looking for a solution per se because I know there are a couple things I could try first (like combining the rules and there may be multiple things at play here); I'm just wondering how things work under the HE hood when it comes to the "who gets served and is likely drinking first" question.
Or perhaps what operations take longer..... I presume both rules are getting notice of the trigger in pretty much the same microseconds of time, but is it the case that shipping off a GET to another LAN device would really be accomplished and have that device acting on that command a good 1-1.5 seconds before the HE gets a radio command out across a repeater device to turn on that MHCOZY relay?
Where is the operational/processing order, or traffic overhead difference if any?
I can't answer the platform questions, but I do know there were one or two folks seeing something similar (lag between trigger and actions) that was fixed in .140.
I avoid this situation. If timing is critical to you, then don’t leave it to chance.
In this case I would l have one rule triggered and the it can RUN the other two rules in sequence or use variables or virtual switches to trigger the other two rules. Often I will have a wait between as well (like wait until the first rule turns the variable back off) to avoid radio congestion.
How are you determining that one is later? It's possible that both rules start running around the same time (they should happen in an non-guaranteed order with likely only milliseconds in between), but something else might be taking longer. You'll need logging enabled (and to check the output of Logs for the rule apps in question) to get an idea for that. The "something else" could be your Z-Wave network, to name one possibility. However, without these clues, it's impossible to know where to start looking.
But as mentioned above, I'd also update to the latest platform version if you haven't already. There were some fixes for slowdowns over time, particularly with RM, in the latest release.
It's like having multiple science, engineering, and logic professors that give you some things to think about but tell you to go back and look at the data.
Going back into the logs I see that the trigger does indeed cause that relay to be turned on ~1.3 seconds after being triggered. Not as quick as I would like but not as long delayed as I first thought from the time stamps on camera images captured post triggering.
So from this I am concluding that there might be another second +/- of night time image gain & compression compensation going on whereby I don't see the results of that relay being turned on immediately.
The point about putting these actions all into the same rule is taken and I will now that I'm done testing. The point about .140 having a fix for a possible trigger to action delay is taken. And lastly, this is an "all Zigbee" C5 environment (still) so no Zwave in this bar
Two hubs, one I keep on the bleeding edge of your releases. The other, more critical to a number of field operations, I lag behind....like .117 behind. If you can guarantee I won't be spending the next three days under the hood figuring out why multiple irrigation valve rules broke I'll do it.
Just coming back to report I upgraded to .140 without catastrophe, and as it turns out the delay I was seeing was less about the inherent RM delay problem (fixed in .140) and more about mindful design which doesn't
So thank you, and @bertabcd1234, for the thoughtful responses that had me "lifting the hood" to look closer at the process & order of operations.
