RM 4.0 Rule Questions and Optimizations

You have to insert a END-IF right after Exit Rule or it won't work, the rule would always stop

1 Like

I just realized that triggers with "becomes >" or "becomes <" logic don't work the way I thought.

Example Trigger: "LUX becomes > 5000" (i.e., it's getting really bright out)

I assumed this would trigger when the LUX reading crossed above 5000 from below 5000--i.e. it becomes more than 5,000 when it wasn't immediately prior. But I now believe this is wrong. The trigger appears to fire whenever the threshold is satisfied (LUX>5000), whether the threshold was crossed or not. So on a bright day, it'll keep firing once it gets bright out, unless it's not.

Which brings me to the question: I have a few use-cases where I only want the rule to fire when the threshold is crossed, not when it stays above the threshold. Is this possible? How would I design such a trigger?

Add a < (say 5500) to the rule

When Lux is >5000 AND Lux is <5500. You would need to find a sweet spot value for the less than.

Not sure if this will help but this is what I use and have for well over a year, works flawlessly

Rick

1 Like

The easiest is to use the Private Boolean here with a rule like this:

IF ( lux > 5000 and Private Boolean is True) Then
  DO actions
  Set Private Boolean False
Else-if (lux < 5000)
  Set Private Boolean True
End-If
3 Likes

Toy, doesn't this rule fire whenever Illuminance isn't between 12 and 26, which kind of defeats the purpose of my question? IOW, if your LR motion is at 30 and it changes to 32, it fires. If it's 32 and it changes to 34, it fires. It keeps firing, which I assume is inefficient for the hub (?). I want my rule to only fire when, using your example, it passes above 26 or below 12.

I wonder if what I'm trying to do is even helpful -- do "noisy" rules effect the hub's efficiency anyway?

Ah, this. I think this is the solution I was looking for. Mega props.

Just one follow-up question if I might. My original goal was to prevent the rule from firing (i.e., prevent it from being triggered) because I assumed that's what consumes hub resources. While I love your solution, I don't believe it prevents the rule from firing. In terms of hub efficiency, to what extent should I care about rule-triggering versus rule-conditions-taking-action?

I wouldnā€™t worry too much about the resources used for firing a rule. It is really negligent.

1 Like

That all depends on the frequencies of the rule firing. For the 4th of July I have to put my outside lights on their own dedicated hub because having the rule changing from Red/White/Blue every 5 seconds between each, will lock up my normal use hub within a couple hours everytime.

Even with them being on a dedicated hub, even it locks up before sunrise about every other morning.

Are you saying, having lights changing every 5 seconds will lock up a dedicated HE Hub within 48 hrs ?
Wow, that sounds like a classic Memory Leak, there and thatā€™s not good !

Surely thatā€™s something @mike.maxwell and the gang could simply test out.

Of course the questions then come; what Devices, what Apps and what Drivers ?

I have a test app i run that turns a virtual switch on and every 100ms, it doesn't lock up anything...

exactly...

1 Like

This last 4th of July I had just a single Hank RGBW bulb for a porch light that had a simple rule to come on at sunset and off at sunrise and during that time to change from red > 5 seconds > White > 5 seconds > Blue > 5seconds Repeat.

My home hub locked up within 2 hours, I removed the bulb and put it on my empty backup hub ran the same rule it worked fine for a few hours would begin slowing down missing transitions and by morning would also hub would have to be rebooted.

Mike, I'm trying to understand the relative hub resource "use" between just triggering an app (that then takes no action because the conditions are false) versus the same rule triggers and taking the action (all else equal)? Not sure that the question can be asked at this level of abstraction but wth I'll try.

It worked fine for a bit, but over an extended time period (sunset to sunrise) yes almost everyday the hub required rebooting because the hub UI wasn't functional by morning.

Not that I have ever seen. when it gets dark due to clouds, lights come on, as the sun come out the lights go off. I have never seen any issues.... so I ain't messin with it... LOL

Rick

If you're turning a switch on that's already on, then the driver loads sends the command to the switch, the switch responds that it's on with an event that is generated but ignored by the event system since it's a duplicate...
If the app checks the state of the switch before hand, it never sends the command to the device in the first place.

It's usually not a big deal until you get hundreds of devices.

I could be wrong (insert newbie caveat here), but I think that's a different issue. That's the overhead associated with an event. I'm trying to understand the overhead of a trigger firing.

Here's perhaps a better way to ask: if I have a rule that triggers every 10 minutes all day long but, because of its conditions, rarely takes action, how hard should I work to reduce the incidence of action-less triggers? Does the act of triggering a rule that does nothing most of the time consume precious hub resources?

Every trigger that fires loads the app, that's maybe 20 to 30ms of execution time.
It's not really anything to worry about unless you have some spastic device generating hundreds of events per second, or at least trying to...

1 Like

I created a rule that does just what you are describing. First, I ran it on a bare new hub. After a day or so, nothing untoward had happened, so I moved it to my main production hub. This hub runs my house, and I do development work on it several hours a day. Nothing untoward has happened to my hub, everything is running smoothly, with normal fast response times. I even put the light on a Dashboard that I leave open, so that's updating every 5 seconds also.

So I'm curious what is different about your setup that caused your hub to "slow down".

Here is the rule:

That looks similar to mine, mine has been deleted as it was the only rule on that hub and the holiday is over but it was a 3.0 "rule" similar to this if I remember correctly.

There is a chance (in my opinion) this could have been a device related issue here as I've mentioned to @mike.maxwell about issues I noticed with the device here HankRGBW Driver Bug

Currently that is the only "color" bulb I own so I have no way to test the rule with a different device on the hub to see if the issue goes away.