Nothing major here but as my list of rules grows, it occurred to me that it might be nice to have a second level of organization beyond text-based rule name prefixes.
If there is a suggestion box then please add this one to it.
Thanks!
1 Like
Yes. I've done the same but looking for a solution
I use icons....(example section of rules list shown below)...
The only issue with this is it means your rules are not sorted alphabetically so it can still be a pain to find a rule in a long list like mine. But it sure is pretty 
1 Like
Dusting this suggestion off.
It has come up before in other threads.... but as I have recently had yet another suggestion that I "think more event driven" and split rules up into two or more rules to simplify the waits and conditions. I am reminded that one of the reasons people gristle at that suggestion is the "coming back later and trying to make sense of everything".
One visual aid in this would be the ability to group rules, not just by rooms/functions/device associations but in this case...RELIANCE. In other words, I'd like to see the grouping or tagged association of three rules constructed to manage the on X, the running X, and the off X of device X or set of devices serving a combined function X.
Sure, I guess that could be addressed by labeling them "Function X - ON, Function X - RUN, Function X - OFF". And now that I just said that, I'm pondering why I didn't start out with all my rules with that naming convention instead of the action being first, i.e. ON - Function X.
As he presses pause 
and leaves the room mumbling to himself instead of deleting his post. 
=======================================================
EDIT: But wait, there's more....just let me leave this search result here showing the long history of this request.
And say.... that this would be helpful especially the more "I GET" the benefits of separate rules to address Part A , Part B, and Part C of a particular "use case" (i.e. event driven programming is different than what some of us learned early on, so is the use of the word "application" ) 
I am slowly learning that many of the trip-ups encountered in longer rules with the use of Wait For, complicated IF Then, Private Boolean, AND "what happens if there is a power outage, reboot, etc" can be alleviated by simpler rules that work together but stand resiliently on their own listening for a trigger vs "WAITING" for it.
Simple example: it would not initially occur to me to write two rules for turning something on by a certain trigger, waiting for X amount of time, or otherwise waiting to proceed after some secondary event/trigger to turn it off. It just makes sense to bundle that in one process flow in my old vernacular.
But I am getting why it is no skin-off-my-nose to bust that up into two rules if I can and thus stop worrying about ALL the things that could potentially leave that rule stranded and uncompleted as expected/intended. As I keep hearing...THAT IS EVENT DRIVEN PROGRAMMING which every HE Newbie needs to embrace vs the "half-way adoption" many of us go with.
So yeah, any rule grouping / organizational aids to encourage this kind of approach would encourage the Best Practice suggetion we hear from HE Gurus & Principles all the time.
1 Like
