Have been beating on the Hubitat for a month now and am totally happy with the solution however am starting to look at optimization and have found that the longer and logic bound rules take a fairly big hit from a performance perspective....
I’m seeing an addition of about 2 to 5 seconds on my more complex rules ( and they are not that complex ) ... to be sure I threw in a light on instruction at the start of the rule before all other code to see if the light would turn in quickly and bang ... which resulted in the light turning on fast thereafter the logic took hold and did its job .....
My rule is not complex probably made up of about 15 to 20 lines 2 or three conditions leveraging global variables and two writhe to log commands .... Not much at all however the latency added is really noticeable as a user ... walk into a room and the lifts go on vs walk into a room tans there a few seconds and then the lights go on....
Thoughts? Does this sound about right? Is RM code interpreter performance restrained ?
All devices are Zigbee, the network is fairly robust ( repeaters galore) , no errors in the log ( app and system), using native drivers for these devices , hub in all other regards seems fine but to be sure I did a soft reset last night which had no effect + or minus .... latest patches are on the hub and restarted it a few times 2
Depends on what you use it for.. Remember that RM is high level.. Not knocking it, it is a very valuable and useful tool..
If you want real performance write in groovy... I still use RM for my simple rules.. But have moved all my complex actions to groovy code.. All my complex automations that I moved to groovy native code run crazy fast...
Perhaps my rules are dramatically simpler. I have never seen any delay close to as long as what you are describing. If I had two to five second latency I would be one of those folks talking about going back to SmartThings! Are the rest of your hub operations running quickly? Access to the console relatively quick?
Yes everything is fast .... UI is snappy, device list is snappy , basically everything is fine , or at least it feels fine .... Zigbee devices ( when controlled from the device listing are basically instantaneous and rules are firing off very reliably , status of devices is also reporting back quickly and accurately)
a simple rule , motion causes light to switch on its zippy not instant but Close.... on my semi complex rule, my conditions are not terrible .... eg event of motion or contact ( which I have watched and the trigger instantly ) ,actions are basically mode checking setting a few variables based on conditions ( local and global ) logging a few comments and the turning on the light with variables for level and fade rate etc ... that’s it ..... on another semi complex rule I also use private Boolean to block unnecessary misfires as the result of multiple trigger events ( to minimize zigbee transmissions ) and that suffers almost identical lag ....
Was thinking of putting a pre logic On command in rules to just get lights on quickly and then let the logic do its thing and tidy up , however I’m thinking groovy may be the way to go ..... which is really why I asked the question to figure out if I have a problem or “it is what it is” ... not an issue really either way just want to understand
It depends on what you want your lights to do but you may find someone has already written an app that does what you want.
Or maybe there is one close enough so that the author may add your special requirements.
Most of my apps started out really simple but got bigger as people asked for more and more features.
Yea that tracks with my thoughts however don’t really want to be adding virtual devices left right and center unless totally required .... hmm going to have to play with this some to see what works best ... code, reuse, live with ..... or a combo
The use of apps is an option however these tend to be standalone and sharing or reusing settings is not always an available option ... that said it’s easily corrected with rules that fire off when the device/s are turned on .... an option with play with
Using virtual devices makes sense , instead of having a global variable for light temp and another for color I would have a virtual bulb that does the same ... actually I think it’s a neater approach... “ one bulb rules all” type of thing .... and maybe it’s faster ... not hard to test will do tonight ....
I use local variables a lot. That doesn't seem to kill performance as much (but that is anecdotal - i didn't time local vs global variable impact - but will when I have time). Global variables are the ones that seem to really kill performance for me,
My understanding from what I've read on here is that global variables have to refer back to the parent RM app, while local variables are only used within the rule they are part of. That's why there's a performance hit with global variables. I changed all of my global variables to virtual devices and saw better performance. Some people are having good luck with global variables, but I personally would not use them unless I had to.
Very interesting guys.
Glad I followed this thread as I’m only using Local Variables and that could explain why I have NO issue with slow down/ latency.
BENCHMARK/ SANITY CHECK
The what: did nothing just triggered the slow rule a few times to confirm
The result: slow response every time , some variances in response but averaging about 2 to 4 seconds to get the light on post motion trigger ..... enough to be annoying... also confirmed in each that the motion sensor was reporting quickly ( it was basically reporting instantly )
NO GLOBAL VARIABLES
The What: Copied the offending rule and stripped out the global variables ... paused the original and activated the new .....
The Result: fairly big improvement in performance ... not instant on but satisfactory .... hard to stopwatch but about a second maybe and the lights come on, great looks good
NO LOGIC / ONE LINER / LITE
The what : stripped all logic and variable out of the rule and left the dim command ONLY ... in short one trigger one line of code, about 10 lines of code removed most of which is conditional and all using local variables
The Result: fairly much instant on when the motion triggered ........ interesting ... vs test 2 there was a palpable improvement in performance and compared to test one its night and day ....
STAGED
The what : Reusing the lite rule from test 3, I created a new rule which had much of the same type of logic that was causing me heartache) and added a delay of 2 seconds at the start ( the 2 seconds just allows me to keep up with what’s going on , ) ...
The result: test 3’s lite rule performs instantly as it did in test 3 and the new rule roles in behind ( with a 2 second lag + its own built in latency ) and sets everything up I want .... and from a user perspective everything is responsive and it lands where I want it to ....
So after all of that... I’m going to say that it’s likely that global variables have a big cost to performance.. that as per test 3 there is something going on with logic and or local variables as well however I really didn’t try to disassemble that to much. And a super lite rule flys.
Thinking about test 3 and test 4 ; did not expect much of a variance there but it was as stark as the timing difference between test 1 and test 2 .... and would not have anticipated that a small number of lines of code have such an impact .... could be the local variables , could be the logic , could be that there is a high intrinsic cost to every line of code ... IDK
Ps this is not to say global variables are bad .... but that their use in automations which have time sensitive user interactions ( like a lights on or off ) should be carefully considered ... I have another rule that turns on a plug / fan combo and the lag is irrelevant as long as the fan turnS on or of quick enough that I don’t think the button event did not happen ( resulting in another button push and frustration ) , which it does
This is some good information to know. Thank you for sharing your test results. I built almost all of my automations/rules prior to RM 4 and global/local variables even existing on the Hubitat platform. Thus, I have never even tried them. Good to know that they can cause a performance impact. Seems to me if one needs to use local/global variables extensively in an automation, perhaps that particular automation would be best written as a simple custom groovy app...
Possibly , however the skill level jump from point and click to real coding is material, daunting and from what I can see platform specific documentation is lite for the Hubitat ( have not researched 2 much yet but have not found a great deal of documentation beyond the generic groovy stuff ) ....
Coding is probably beyond many users .....
that said that’s where I’m heading next ..... lol
Understood... However, if one is able to grasp all of the complexities of using Rule Machine with variables, you've basically already learned a programming language. Groovy is pretty simple for anyone who already has a little bit of programming experience. While the Hubitat developer documentation is a little lite, the example apps that are available via the community make getting started much simpler. Also, the Classic SmartThings Developer documentation can be very useful as well.
