This is a perfect case for the State Machine automation design approach. You will need multiple rules (unfortunately) for handling all conditions (basically one rule to handle each State). But after all you will have very robust atomation. Single rule may do the job but frankly I finally gave up creating complex single rules (which actually worked but was not enough stable) and rewriting all of them as a State Machines. The only downside is significantly entreated number of rules. But HUGE advantage is rules stability wich is highest priority.
Here is how to convert you example in a State Machine with two States (two very simple rules will be needed).
Rule-1 (State-1)
TRIGGER : Switch is ON
Actions:
First while loop;
IF Switch is ON
Run Rule-2 (Switch to State-2)
End If
Rule-2 (State-2)
No Trigger needed
Actions:
Second while loop;
IF Switch is ON
Run Rule-1 (Switch to State-1)
End If
This two rules will cycle until Switch turns Off
This example shows how to create a simple two states SM with very simple rules (KISS).
And the SM could be easily expanded.
This.. - Doing this is in a single rule with loops and repeats feels complex... - as @vitaliy_kh noted, seems like two rules, and either a hub variable (Boolean, number?) or Virtual Switch to track state across the multiple rules, feels alot more "natural" with less "waits" in rules (which always can be problematic)
I prefer to be have already exited any rule, while "waiting idle" for the next state change..
And yes, you do get more small/short rules with this approach (Naming conventions are your friend) - but they are generally just "doing something, set some state" and exit - Short and sweet.
The State machine isn't a bad idea, if you want to make sure you have EVERY possible event flow covered, which some states can usually be ignored based on the physics of a situation, but the state machine drawing will at least force you to figure that out on paper, versus just hacking at rules, and discovering other conditions based on edge cases of event changes (things may not behave the way you expect them to).
I am very experienced EE and cannot even imagine how to design nice and clean hardware logic without using SMs. RM (which is very nice and powerful automation tool) designing SMs requires multiple rules. At the beginning (since 2019) I did not like to create multiple rules for handling single automation. But now my thinking is very different because practically complex single rule works but very unreliable (it looks like related to the internal race conditions).
Taking my EE experience in account SMs is the way to go.
I've got an advanced degree in CS, and about 40 years in industrial automation and communications - so yeah, I'm a fan of SMs (I'm not a huge HW type). That all said, not everyone on this forum is going to be familiar or comfortable mapping out state tables, and the associated state transitions.
So while I'm right there with you as an SM advocate (pun intended) - just trying to make things a bit less formal for everyone, and not mandate anything - Perhaps even more important than a finalized SM's - is at least having a plan on paper with your inputs/triggers and desired outputs mapped out (which is the 1st step to creating an SM diagram) - Just not everyone approaches logic problems the same way.
As noted above, I'm a strong advocate of multiple small/short rules - Whenever I want add a wait or delay in RM, I step back and re-consider the overall design. So I do have overall hundreds of rule snippets (I have around 15 rules, just for a single set of 3 independent under-counter LED's).
I DO wish there was a folder structure native to RM, just to make logical grouping/hiding things a bit easier, as even with a naming convention, I have lots of rules to scroll thru - And slogging thru screens to remember what I named something is the downside of this approach. There is a 3rd party plugin that helps in this regard, but some native RM organization mechanism would be nice, IMHO.
This was my a primary reason why I did not use SMs when I started with HE/RM.
I agree 100%+. It will be nice to have native SM-based RM. I am not sure how GUI should look like but I am positive something very intuitive for everyone could be created.
Perhaps, for everyone who grasps the concept of a state machine as it relates to home automation. I think that's a small subset of our users, actually.
For everyone who is familiar with State Machines everything what is needed - is subfolders for organizing rules. The rest is aready there.
Some sort of intuitive GUI should be designed to help non technical home automation enthusiasts to create SM-based automation. The RM "as is" also requires a lot of knowledge how to deal with all that logic. Is not it? SM is just one extra layer above all logical equations. And SM actually makes underlying logic much simpler (please check my exaple above).
How may users are using RM?
My good guess the same RM users will be using SMs once they realize the beauty of SMs for automations which is:
easy rule expandability;
KISS aproach for logic within States;
much better stability (potentially can mitigate all that race conditions);
etc.
As I already mentioned, at the beginning I was enough stupid not to use SMs and instead attempting to create a complex single rule. They worked but because of internal timing issues these complex rules were not stable. And the reason for these complex rules was inability to organize rules in subfolders.
Anyway, I am not pushing for creating new SM-based RM but I'm sure it will be a very welcome addition to the HE aps.
PS.
For myself I am somewhat allset. As of now I am using only SMs for all new automations and converting the existing complex rules into SMs. For the rules organizing I am using prefixing and suffixing. This make rules/devices names too long but well organized.
It is what it is.
If you are taking about the one which created Virtual Switch for each State then yes. That implementation was not intuitive enough even though I new very well what SMs are.
Agree 100%.
But my point is/was to show how easy and simple @danabw example could be implemented with SM vs suggested single complex rule.
Actually current RM already has near 100% of all requred functions. I am not sw developer and could be wrong but the new RM could be just a modified GUI. Another words, it is not something which needs to be started from scratch.
But again, I could be wrong.
For those who are fans of State Machines, have you checked this out? I use RM for 90% of my automations, but for a handful of things, state machines are justtt right and my brain is jussstttt abstract enough, that itās a beautiful solutionāin the right places.
OK...had some time to play w/this today and have the two state rules created and running. So far just the first rule has executed and it seems to be doing its stuff.
EDIT: Oops, had posted the wrong screen shots, updated w/the correct screen shots.
State 1 Rule - First rule loops through one set of lighting effects
State 2 Rule: - Second rule loops through another set of lighting effects that require a different command to start. If the master switch is still on at the end of its loop the State 2 rule calls back to the State 1 rule and things start over again.
I created the first state rule and then cloned it to use it to create the second since the basic structure is the same. I changed all the variables in the second rule (adding "DIY" ending) just for my own self-protection - adding the "DIY" makes it less likely I'll confuse the two rules and accidentally make an edit in one rule that intended for the other.
Thanks for the suggestion, fun process to see how this works.
