I have noticed that my Rule Machine child app has become increasingly slow during code entry, I have something like 50 lines. Is it better to keep the code smaller by creating sub rules and what are the implications when running?
Without seeing your rule, it is impossible to gauge how it should be structured. In general, rules are free; multiple smaller rules are often more efficient than one large rule with multiple nested conditionals.
If you care to share a screen shot of your rule, there are many RM experts here who can advise on how it can be optimized.
6 Likes
Smaller is easier to troubleshoot when things go sideways. I've found that it is sometimes easier to turn things on and off in two separate rules when there are lots of conditions.
6 Likes
YES!
If you know what is State Machne is - create you rule as a State Machne. You will have set of small rules (basically one rule which handles a State). The only downside is - harder to organise the related rules (unfortunately no such thing as a FOLDER). But very good naming convention (i.e. smart use of Prfixes and Suffixes) will take care about this issue.
2 Likes
I have added some screen shots of the rule I am currently working on. I am attempting to write a number of rules to replace my Room Lighting setup as I have found that it doesn't work unless a refresh is done on the lights immediately prior.
Thanks I do use a quite tight naming convention, as it is the only thing that allows me to manage.
Hello! Might want to give my Rule Machine Manager a try. It will allow you to create multiple sections where you can organize your rules. You can then drag/drop rules into whatever sections you desire.
4 Likes
I was JUST thinking about this. Naming is the only way to go right now.
It would be neat to have some way to bind (poor choice of words probably) multiple rules in a way that if you pulled one up the other one(s) was loosely tethered/linked/presented in a way that you were encouraged (or forced) to consider that the changes in one may be consequential to the other (which you may have forgotten about two years later).
Thinking out loud here without a lot of early morning clarity.
1 Like
Just saw your post.
What you have created is a perfect example of a broadly impactful idea that should be adopted as a proof-of-concept prototype into the core system.
As much as I am always impressed with the Creativity of the Community there's this root fear that "adopting something like this comes with dependencies that the company won't guarantee to keep the integrity of with time". With ALL DUE respect to your work..,and i mean that.
Maybe I shouldn't worry, I guess nobody in the HA space worries about this cause there's 1000s of things in that environment that are sole-creator features right?
3 Likes
I mean.... yeah, you're not wrong. There is always a risk with using a community driven "plugin" environment:
- Will the code be sustainable?
- Will the developer drop off the face of the earth?
- How does it integrate with other community plugins?
- How is the plugin supported (questions, updates, improvements, bug fixes).
- Will there be changes to core code over time that "break" the plugin?
These are all valid questions; and usually at the top of any community driven platform (WordPress, Drupal, Joomla, HA, Hubitat). Here is what I can say about my plugin here:
- It only uses a single core webpage to "scrape" all of the rules and their associated parameters.
- From that point on; it is only "visual" changes being made. Nothing is being interacted with on the core Hubitat system (other than that single web page).
- Any changes are saved in custom variables; and re-applied from those custom variables.
Not trying to "sell" you.. lol. I actually agree with your statement. Honestly, it is my background in these community driven platforms that helped shape the direction of the Rule Machine Manager.
1 Like
You've set my brain into a tail spin thinking about this...
I have a few questions:
- Can you give me a quick example of two rules that could be "binded"? I'm not sure I understand what you mean here.
- Are you saying that when you are creating a rule... you are able to use another, previously created, rule in there somehow? How is this previously created rule used? Is it a conditional?
I am thinking I might be able to, using my plugin, notate that a rule is "binded" to other rules. There would not be an interface to actually change anything for the rules.. but it would at least visually cue the user that other rules are attached.
Of course... I may also just be chasing a squirrel. Look!! Squirrel...
Thanks for the replies!
I'm sure others will chime in but I'm coming at this from a "converted" mindset. I use to cram stuff under one rule and rely on WAIT and DELAY and CONDITIONS to manage subsequent actions. Now I'm "gettin-it" with respect to the above mentioned STATE MACHINE approach to programming.
So despite trying to simplify the possibilities as I did in the other post let me jump way ahead into an idealistic design view. So in the old days I would have made a honking big program with a lot of subroutine calls to bust down reusable components. Now we're not talking subroutines to be reused in this case....as I see it we're talking independent actionable pieces of code operating in response to state changes.
Yet when I go about a building out a task (use case) it really is all one bundle in my mind. I have a device or two or three that I want controlled or monitored and certain actions to take place depending on a variety of conditions of the state either influenced by my code or independently.
Sometimes these are not related in any way....they truly stand alone. But so often the devices and variables are the same, it's just that the instructions and logic are perhaps inverse (an undoing of what was done in the other rule).
So putting on the dream hat, I'm sitting there with two windows....the doing rule window, and the un-doing rule window. Maybe one builds the other as I work (to some degree). When I'm done I have two Rules very much intertwined with the stuff that's being used in them, I can't make mistakes on what I'm calling things or using because they are two tethered / bound rules. Whoooa that's dreaming.
So coming back to reality...today I name rules with emoji icons and use verbiage that is exactly the same except for one word that relates to the "doing" and the other the "un-doing". That way when I look in the Rules they are right there together and I'm reminded that they really are, in my functional mindset, a bundle. Your App helps this...but whooowa if we could take this to another level at the build stage wouldn't that be cool.
Maybe a compromise step is that these rules are simply organizationally tethered (bound is a scary word in this case)...just that you can't view one without a link to the other being present. I donno. Others chime in here.
1 Like
Okay... so what is an example of something I could "check" from the code to determine if a rule is "intertwined" with another rule?
For example; I can't just say if "x" variable changes... then it must have been another custom rule causing the change. I would need to know how Rule 1 is "used" in Rule 2.
Yes, I see the irony in the fact that I wrote a Rule Machine Manager plugin... and that I have almost zero experience with actually building real, actual rules.. lmao.
I guess I'm asking.. is there something in rule manager where you have to manually select another rule? Or are they only tied together using custom variables or attributes?
Somebody else is going to have to pipe up here because there are features in RM that do allow some calling or inter-use of rules but I have not delved into that. The only thing I've done is use the same variables between two "allied purpose" rules.
EDIT ADD:
To be fair, some of the simplified built-in applications like Simple Automation etc do address some of this, "you want it on, then you want it off at some point/condition" bundling.
I am using number of triggerless rules as a subroutines. Gladly RM allows to run a rule from a rule. The called rule better to be as a last line in parent rule or parent rule must not rely on the results from called rule because the parent rule will continue to execute immediately whatever is after a called rule.
1 Like
I am thinking of using a combination of state and flow mechanisms. A state function probably works very well for everyday tasks (eg room now becomes occupied) but when it comes to an exception condition (eg system recovery, not all lights turned on) then there is a need to follow a flow. To keep things maintainable to call other rules to process the actions that the flow requires.
My original enquiry was more around how slow I was finding it during rule entry, and were my rules therefore getting too large,, but I have now found another issue on HE that I am trying to resolve which may be that cause.
1 Like
