Now that I'm becoming adept at writing rules, I am beginning to have devices 3-4 layers deep in rules which are becoming complex and typically triggered by button changes. The complexity results from the arrangement whereby Pico buttons set virtual switches, then state followers in RM4 watch for changes and make decisions based on various states which may be a function of other state follower rules. Since the implemented logic is reliable, I naturally kept pushing complexity until device action delays are becoming >1 second which starts to become a limit for how far the HE can be pushed.
Is there anything I can do to make the state follower arrangement faster? E.g. I am wondering if disabling all logging in RM4 would help. Or perhaps get a 2nd HE that just runs rules? Is a faster hardware platform in development? It is very convenient how high level the HE ruleset is, but I think I have hit the computational overhead ceiling for logic structure complexity.
Could you show an example of a "slow" rule? RM is a pretty big app, but the hub is usually pretty fast; still I try to avoid it for things I want to be as fast as possible like lighting automations, but it probably shouldn't be that slow. Maybe someone could spot an improvement or staff could identify an inefficiency if you don't mind sharing.
You may also wish to consider writing a custom app yourself in Groovy. You can make it as lean as you want, and you get all the power of Rule Machine plus more, albeit at the significant tradeoff of being more difficult.
Thanks for the reply. By 'slow' I'm talking about a ~1000ms delay between pushing a pico and a light comes on. Livable, but not instant. I'll copy some logs when I get a chance.
Pico, you say? I've noticed the first press of any Pico is slow for me after any hub reboot, then subsequent ones (on any Pico) respond as normal. That couldn't be the issue, could it? In my case, it takes a few seconds, or at least it feels like more than one...
There's also the "regular" vs. "fast" driver, but that again shouldn't be anywhere near a second, and you might already be aware of that.
I have multiple deep rules in RM also and reported delays in another thread. Some theories we around global variables and their usage adding time. So what id did was isolate the rules that need "instant" responses and kept the condition to one level deep and those that were not latency sensitive left as is.
Thanks. Picos are generally relatively instantaneous for me. They are probably my favorite device simply based on reliability and execution speed when accessed from HE. By traces I don't see the Pico being the issue-- I'll post some logs to elucidate. Generally every line of every rule has an execution time of a few ms and that adds up which is natural but at some point perceptible. Not a complaint, as it is doing exactly what I am asking it to
Below is a relatively simple rule train and since I'm bothering to post this I bothered to plot the delay sequence. I didn't cherry pick this event, it is the first thing I tried and recorded it. I didn't hit the physical Pico button, I hit the virtual pico button for the Pico in RM4. Perhaps something about the virtual Pico button is the first delay of ~750 ms. It seems the major delay in execution is the state follower rule that detects a change in the virtual switch which is set by the pico at another ~750 ms, then sets the light. So it seems one conclusion is the detection of a switch change for a rule to execute can be >500 ms. I wonder if this can be sped up?
It isn't critical, so I'm factoring out the information to here that I use a virtual switch to capture the intention of the users by following the pico button presses. A motion detector can also activate this light, then that rule resets the light back to 'how it should be' by setting it back to how the virtual switch has recorded the user preference by means of pico maipulation. That is, the effect is the users can control the light by pico, and the motion sensor has additional short-term activity that sits on top of the user preferences.
If it's just RM being slow due to lots of nesting, maybe a custom app would help. If it's a generalizable situation lots of people might want, perhaps an enterprising developer could come up with something. (That being said, I'm not sure RM should be that slow, but I don't know how many levels of nesting they suggest as a practical maximum or how many you've got going on.)
I'm thinking about efficiency as well. I have a rule that is nested 5 levels deep. However, I've noticed that it's rather slow at turning lights on/off/colors. I read elsewhere on this forum that it was better to use AND/OR/XOR and not nested statements. I have not tried that yet, because that will take some time to change a rule. But I wonder if it's better to have smaller rules but many of them.
I find smaller rules are better. i tried complex rules in various solutions over the last 20 years and always ran into issues, In WebCoRE I had a lot of small rules and now in Rule Machine I did the same. It's much easier to debug events also when you have smaller rules.
And the nice thing in Rule Machine you can also call the actions from rules and treat them as macros. For complex actions just chain the needed macros together. For example for my "sleep" mode change i chain together all the room's "scene" modes for sleep.
I agree. I have recently been combining some multiple old rules into a single RM4 in the interests of keeping everything in one place. I does tidy things up but in terms of functionality I now don't think this is the best way. Another benefit of smaller individual rules is that you can easily pause them if required which you can't do for parts of a single complex rule.
I know Bruce is an advocate of the KISS theory and I will be sticking to that going forward. Just because you can now have very complex rules in RM4 doesn't mean you should IMO.
Are you using a pico to turn on a Lutron switch or dimmer? We've had discussion previously on a 1 second or so delay for things that go Lutron Pico -> Hubitat -> Lutron Device. The same automation going Lutron Pico -> Hubitat -> Non-Lutron device is instant. If you are doing the first one I believe the issue lies somewhere besides with RM.
Thanks for he reply. RM4 takes ~0.5s to detect the virtual switch was flipped. I think this is what causes the perceptible delay. For the data shown I pushed the virtual pico button in HE- I think that is longer than when I push the real button which has an acceptable delay if the RM4 detection delay is eliminated. I collected these data while not at home so I couldn’t hit the actual button.
Per all above replies (thanks!) I am thinking to re-write as a single rule to eliminate the virtual follower switch.
After a couple months of HE migration, I just asked my primary boss how my WAF is doing. She currently has me >9 for the first time
With the latest firmware update, the delay I see with Picos is reduced by a factor of 2-3 vs. the plot I posted above. I am certain the improvement is not simply due to a reboot since I rebooted and tested before the update.
I am not sure if others are seeing such an improvement nor if the firmware intentionally targeted anything with respect to pico performance. At my house, the performance improvement is quite noticeable.
Good job Hubitat guys, I have had exactly 0 problems with my ~75 devices connected to my Hubitat since last posting several months ago. In my view your functionality is far past the beta stage and I think you guys have built a fantastic platform.
