I implemented this. I think it's good, because you get a direct visual situation awareness thing for conditional actions, in addition to the indentation. I mostly use desktop access to the webui, but this works on mobile without cluttering. Saves steps when building conditional actions.
Those buttons are entirely context sensitive, and only show up as appropriate to the specific context within conditional actions.
I agree from what you have shown. It also doesn't stop people doing it the old way, it just leads you down the correct way of what your likely going to need next. For a none programmer or someone not used to the logic statements by doing this it's almost training them. Whilst also making it quicker as a whole.
I'm assuming not from Bruce's screen shot. But why wouldn't you use them when they would reduce you having to click though to find them.
Both IF-THEN and Repeat do this. Repeat is going to need END-REP. So once you start one, an END-REP button appears. You can't do ELSE-IF with a button because it needs a full condition, just like IF-THEN needs one. ELSE, END-IF, and END-REP are the only cases (but one) in actions where there is just a stand-alone word for an action. The other is Exit Rule, but that doesn't warrant its own button, as it is not used very often. Both IF-THEN and Repeat have to have a closing word, END-IF and END-REP, to allow for proper 'syntax' of a rule's actions, and in the case of IF-THEN, to allow for proper nesting of conditional actions.
I was just thinking I could remove the old way of doing these three, END-IF, ELSE, and END-REP. If you pay attention, those actions do not appear in the drop down list until either IF-THEN or Repeat has been done -- those drop down menus are context sensitive also. So, there is code associated with manipulating those menus to do that context sensitivity. It would be nice to get rid of that extra code. Having put these buttons in I can't see why anyone would want to use the old method to add ELSE, END-IF or END-REP. Even @furom won't once he tries this.
Maybe give me the benefit of the doubt on this one? It's going to save you lots of clicking around -- if you use conditional actions. If you don't use them, you'll never see it.
I like this, thanks, Bruce
Will this appear any time soon as an HE update? Or do we have to update our RM app some other way to get this?
It will be in the next release, 2.2.6.
@bravenel Any chance of there ever being a ladder logic style tool? I know there are IEEE standards out there and free programming tools. As an industrial controls engineer I struggle to adapt concepts from ladder logic to rule machine. For example is a trigger latched? Once a trigger comes true does the rule continue to execute till it concludes an action? If the rule Re triggers in the middle of execution, say a delay timer is running, what happens? Does the rule Re-execute and my delay timer resets or does it continue to count down? Any way to see if a timer is counting and where itās at? Might be the wrong thread for these questions.
Can't give an informed answer about ladder logic tool.
With respect to your other questions:
Triggers are not latched, although most devices are in effect latched (e.g. a motion sensor will only report motion active once, until motion becomes inactive). Once triggered, a rule executes to completion. If the rule re-triggers in the middle of execution, another instance of the rule is instantiated and runs to completion also. Depending on the rule, this can be a bad thing, and should be carefully thought through. It is possible to enforce single execution by using a variable or Private Boolean to record that an instance is already running. If a delay is running, it will continue to run. This is actually a scheduled event, and it will cause the rule execution to start again where it should, just after the delay. Multiple instances can have multiple simultaneous delays. Where things get into trouble with multiple instances are delays embedded in conditional actions (IF-THEN ... ). A rule only has a single state store, so multiple instances will step on each other with respect to state. State is used to manage nesting of conditional actions, hence a problem with multiple instances. Bear in mind that with no delays, rule execution happens within a few hundred milliseconds.
But doesnāt Stop Repeating Actions , Cancel Rule Timers , and Cancel Delayed Actions cancel the scheduled event, thereby causing that thread to cease execution without running to completion?
Well, yeah. But otherwise you can have multiple simultaneous delays...
Thanks so much for that explanation above. It should be pasted verbatim into the documentation for Rule Machine. I have never before seen such a clear and concise explanation. Thanks.
Hi @Pooch, being controls engineer also with more years than I care to admit 
doing PLC logic. I've had a brief high level conversation with Bruce about this before. It boils down to Ladder logic and RM being fundamentally different. Ladder logic is always scanning and evaluating logic whereby RM is 100% event driven, no logic is even looked at until something happens. Some things can be translated between the 2 methods but they're just too different to have any hope of being implemented in HE. Because of all the other features in this platform event driven logic IMO is the better choice to minimize CPU usage.
What helps me is that I write my logic down in ladder/ST and see how I can break it up/rebuild it with RM.
This was very timely information to read. I was just looking at a scenario that occurred today where my hub was very sluggish and was alerting on CPU usage. Automations were running, but slowly - e,g,, light comes on 45 seconds after motion detected.
I have a rule that runs once each minute. It does read power values from three devices, but other than that just does simple variable math. No other device actions. In the logs I observed that the actions in this rule were occurring several times a minute, not just the one as expected. I was initially under the impression these multiple instances were the problem. However, after reading this explanation, I conclude it was probably collateral damage of something else that was causing high CPU.
Should this be one rule to start and stop the dehumidifiers like i have it or two rules, one to start using a trigger for humidity greater than or equal to 50 or over and a second rule to stop the dehumidifiers less than or equal to 47?
Can someone explain where the private Boolean would go to stop a second instance of this rule from executing?
My sense is that it should stop the action from triggering but when I selected a private Boolean in the trigger it showed up as an OR, can I make it an AND? As in humidity changed and private Boolean is false?
Does it make sense how i am setting the private Boolean to true in the first action and setting it to false after the delay timer and false again after the dehumidifiers turn off?
Thanks
So the rule is going to trigger, no way to use the private Boolean to stop that. First conditional action is to test if the private Boolean is true, if it is then I want to stop this second instance of the rule from executing, but how, whatās the action? There is no option to ācancel this ruleā.
Thanks, didnāt see that little gem.
Download the Hubitat app
