My rule has taken 169,258 seconds ~ almost 2 days out of my 8 day uptime! 
The rule seems rather simple and I can't figure out why this rule is taking so much time to process. Anyone who has similar experiences? I have ~6-7 rules like this and hubitat keeps telling me that load is severe. Sometimes things gets delayed a few seconds because of this.
Do you have any other conditions defined in the rule?
Open the Actions page and see if there are any others defined in the Manage Conditions section
Hmm... strange. If my maths is right, it's taking about 14 seconds each time to run... which does seem excessive for the rule definition.
Yeah, that's absolutely right. It's taking about 24% of the total time reported from " Time hub spent processing each app's code (Total, ms column)." This means it's around 14 seconds per minute.
One thing you could try with the current copy of the rule would be to turn on logging and see if you can tell where the delay may be occurring.
Aside from that, you could try pausing this copy of the rule and work through setting it up again, either in full, or slowly adding each of the actions to see if you can work out which one may be causing the log running time. Again logging would likely help with this effort as well.
Thanks for the suggestion they all makes sense. My suspicion is that there's some hidden bug that is under the hood in rule machines that took away a lot of processing time.
Find a better way to do this than running it once a minute. The hub is an event driven system, and you are essentially polling every minute to do what you could do much less frequently with the same outcome. For example, use a trigger of Variable Clear Weather changes, and the same actions. That's the only change of state that affects the setting of Den Direct Sunlight.
2 Likes
That makes sense let me try that. Isn't the cpu time still a bit higher than what one'd expect?
Actually I realized your suggestion won't work. Only the triggering of Variable Clear Weather is not sufficient. If you don't include a time-based triggering, then my variable "Den Direct Sunlight" will not be changed at 14:30 (line 2).
Try adding the three specific times in your IF Statement (930, 1030, & 1430) along with the Variable Clear Weather as triggers if you want to ensure the rule runs at those three times.
Change the trigger to when variable clear weather changes. Leave everything else the same. Your if statements are fine with the time validation and such. That alone will help this run considerably less frequent.
Do your other rules also run every minute? Are they then triggering simultaneously? You say you have 6~7 similar rules. Try offsetting the times they run as well.
I have multiple rules to make sure my thermostat has the correct setpoints and mode, but I have them set for periodic using cron string to have them run at specific times, none of them at the same time. The trigger event shows this.
1 Like
I honestly think the option to run a rule every min shouldn't even be a option. This is like the 4th or 5th time in so many weeks that I have seen users now create self inflicted issues with that function. Instead of running this every so many minutes you should try to identify what should trigger that action and only run on those events.
Set up your triggers like this and leave the rest of the rull the same. Your actions section will then trigger correctly based on the the hub state.
If you have other rules running ever min that will cause all kind of havoc on performance.
It should also be noted that though the CPU MS time is a good metric to try to point to a issue, it isn't always 100% accurate depending on how a app is written. I was working with a developer that showed that it isn't a clear value for actual usage by a program. If the app is written in a way that it is getting allot of time in a certain method that is embedded in another method in groovy it can cause the CPU MS number to be elevated even though the program is running well.
2 Likes
Thanks for all the help! It makes a lot more sense to hear that CPU ms isn't accurate. Normally if everything is in memory and the logic shouldn't take more than a few ms. Seeing it taking 25% of time was definitely surprising so knowing it's not a true metric makes me worry a lot less.
I made changes according to all the suggestions here and now the hub is a lot more responsive! Thanks again!
2 Likes
I have a rule running every minute that just generates a heartbeat between hubs. It was showing very high numbers too. A manual trigger somehow did not "consume" as much for the same actions.
Perhaps this trigger is not as optimized as the rest and this is part of the cpu consumption? That or constantly rescheduling the next event?
Or you the "very high numbers" don't really indicate what you might think they do.
Running anything once a minute like that is not a good design for an event driven hub.
