I have two simple (local, no cloud) rules on a C4 running 2.3.1.134 filtering out occasional, anomalous, very high, 531F device temperature reports. The rules work as expected, but according to the app log reports they run for what I feel is a long time, 415ms average for one of the rules.
It was originally one rule using "Changed" with an IF filtering the temperature, but that took ~350ms per execution. I felt that was excessive, so I decided to try splitting it into two rules, but now it looks like it's using more time.
If there is a better way to handle this please let me know. Otherwise, @bravenel is this the expected run time for this 100% local RM?
Turn on all of the logging for these rules, and look at those times, e.g., time from the actual device event to the rule being triggered, and time from being triggered to the action running. I don't pay any attention to rule running times, as I have yet to see any reason to do so. Bear in mind that you now have two rules responding to every change in temperature of the sensor, as doing a comparison like that will trigger on every event. Those two rules are effectively competing for the same computing resource at the same time, and that may be why you see higher times. They run simultaneously, which you can probably see in their respective logs.
Traced one RM there were perhaps 6 real temperature reports from my initial report, but the app log spiked from 11 to 37 while avg ms dropped to 326. The traced RM ranged from 142 to 204ms in the log. The RM logging remains active.
@bravenel
The rule was being traced when the hub rebooted today as it set to do, weekly on Wednesday at 1PM. There were 4 recorded events prior to me stopping the trace, but app stats show 32. Not sure what is going on but it sure makes the statistics feel unreliable. Kindly submit this for research and correction.
Thank You
Running 2.3.1.135
