Folks, I'd like to get some opinions on how others would handle this.
I have a rule that triggers when a value drops below a certain threshold. The problem is sometimes the value can drop below that threshold quite often, sometimes several times a second which is constantly triggering the rule. It only needs to run every few hours so this is way too many triggers.
The way I am handling it is when it triggers the first time, a part of the rule will turn off a virtual switch, wait 2hrs and then turn it back on. The rule has a Required Expression that states this virtual switch needs to be on(true) for the rule to trigger in the first place. With it off the rule won't be constantly triggering. This seems to be working out fairly well.
I'm just wondering, is there a better/different way to handle this?
I would have used a private Boolean but that's just semantics. The actual code would be the same instead of a variable you just be referencing the private Boolean. The private Boolean is just a true/false variable that is baked in.
You might to take into account though that if the hub looses power and your in the middle of the "wait". You might want to reset the variable when the hub reboots?
I have a few rules that have time outs that I reset when the hub reboots
You could use Webcore and use the "is less and stays less than" condition, which lets you set a time period for how long it must stay below the value. But you have a solution, so no need for that, just an FYI I guess.
I wrote a simple rule to test this theory and what I'm seeing is that any delayed actions that are scheduled before the reboot do get executed after the reboot. @bravenel is that true in general of scheduled jobs?
Of course. Reboots don't affect app state, other than (a) the hub is gone for a couple of minutes, and (b) there's a systemStart event after reboot. Otherwise, rebooting is a non-event for apps, and whatever they have going on...
Ok, I implemented the Private Boolean and created a conditional trigger. In doing so I was able to recreate the rule without the expression and the virtual switch so the rule now seems more efficient and seems to work the same. I'm going to apply this to some of my other rules I use virtual switches for.
BTW, to be honest, I had to learn what a private boolean was in the first place. This is why I put the post out there asking for comments. I'm not a programmer nor do I think like one so I ended up learning something new.
'Thinking like a programmer' simply means applying basic logic to a problem. We all do that every day in many ways. Don't limit yourself with words like "nor do I think like one", because you actually do think like one (gasp!). That's how you ended up with a solution.
While I agree in concept, my logic on what I want to achieve and what actually happens sometimes can end up as two wildly different things. I've read posts in this forum from people that should be working for NASA. There is just a different mindset when it comes to certain things and I like that I can tap into it via this forum.
On a lighter note, having raised 3 daughters, applying basic logic to a problem usually returns an error. Nor does it apply if the wife asks if the dress makes her look fat, lol.
I think there is logic to be applied there. Given that you want to keep your wife happy, because that keeps you happy, the only logical response is "no" given the outcome you want to achieve.
Basically, if you create a function which maintains a "mynow" variable and updates mynow every minute, you can use that variable in conditions.
When you go into your rule, you update a local variable to currenttimedate+offset.
Then in your prerequisite conditional, you just compare the local variable to mynow and if mynow is greater, your condition is met and its time to allow it to fire again.
