I have a greater project that I have in mind, but currently working on a proof of concept:
The general gist: When outside temp (aquired via a virtual device connected to OpenWeatherMap) is above a certain temp that the appropriate devices are triggered and will continue to be triggered every xx minutes (via a repeat) until the temp is no longer above the desired temp.
My challenge, is every time my OpenWeatherMap sees an increase in temp, the rule is triggered. So I end up getting a situation where the rule is running multiple times simulanously.
In my test code (attached below) I initally get one push notification every 10 minutes, but as the day progrewses, I end up a birage of push notifications....and I can look into the logs and can confirm the rule is running multiple iterations all with 10 min repeats at the same time.
I feel like there has to be a way to incoorporate a boolian logic variable where it goes "true" if the rule is currently running and as such, but just can't quite figure it out.....I feel like I'm really close on this one.
Edit -- my original post wasn't telling you anything you didn't already know, so...
What is the ultimate goal of this rule?
If you could please tell us more about what exactly you want to accomplish or get from this rule, then folks may be able to help offer other ways to approach it.
When below freezing outside, my hot water heater will circulate hot water through the pipes to avoid freezing (done via a smart relay). Additionaly, I want to have a push notification go to my phone that it is executing the "freeze protection" every time it turns on the hot water relay.
I want this to be done every hour as long as the temp outside is below freezing.
I had initially just thougt of creating a simpile rule that executes every hour on the house with an "if below freezing" then "hotwater heater on" command, but this would have the rule running 24/7.....seemingly a bad idea....or overkill.
Although maybe my attempt to do th repeat may overly complicate it and just best to stick with the simple rule and just know it will run 8,760 times a year.
My first inclination would be to use a Private Boolean (PB)...
Make PB=True the Reqd Expression for the rule (or one of the Reqd Expressions, if you have more).
The first action in the rule would then be settting PB=False -- this then will prevent concuurent triggers in the future.
I'd build a second (seperate) rule that then unwinds / turns all this off (instead of using a "Wait for temps > freezing" in this same rule)... I get skittish about waits/delays that I have no control over (like weather conditions that could stretch for days/weeks) -- when I have those, I always create distinct rules.
You could then leverage the first rule's PB status as a Reqd Expression in the second rule too, and use the final Action in the second rule to reset the first rule's PB back to True. That closes the loop on the entire process and resets it for next time temps drop.
But I am most def not a RM wizard -- I'm more of a gitterdun hack, so I'm guessing other smarter people can likely offer a more graceful solution.
I thought of this, but if step one of the rule is set PB to false.....after 1 hour when the rule repeats iself, woudn't it then see the boolian as false and NOT repeat the rule?
Ha! Me too. I had this running on ST.....the way I had to acomplish this with the limited ST rule ability was bonkers....a bunch of virtual devices to act like variables/boolian values, and a few rules that would then ping back and forth. It definatly worked, but was pretty clunky and anytime I needed to potentially debug/troublshoot....good luck.
In that suggestion, my assumption was that the repeats would be handled within the first rule.
Edit -- if I'm understanding correctly, the gist of all this is that you want a sequence of events to kick off when the temp drops, and then you want to unwind it all when the temp climbs back up.
That's where I'm thinking the first rule is primarily triggered by the temp drop. The second rule would be triggered by temp returning to whatever is deemed safe/comfortable enough to stop the first rule's actions.
You should look at Hub Variables for the weather temperature part. Basically, create a Boolean Hub Variable called "Weather Below Freezing" and set up Rule Machine to turn the Variable to true when the temperature reaches 32 or below.
Then you can create the simple rule from your other thread but have it based on the Hub Variable going true. This way, the constant weather reporting only goes towards the Hub Variable but does not affect the rule with the water circulation.
Ok, it doesn't appear that in my sitauion that I'm able to use a "connector" in my Boolian Hub Variable to toggle between true and false. I'm assuming I need to creat a simple rule that toggles that Hub Variable's value?
I didn't see anyone address this lower in the thread (apologies if I missed it).
This is incorrect. Once the rule is triggered, it is not being re-triggered every hour when the repeat happens. Preventing it from retriggering until your repeat is completed is exactly what you would want to do here.
So a generic rule to do this is:
Required condition is: PB is true
Trigger is; Something happens
Actions are:
1: Set PB false
2: While condition is true (for example, temp is below freezing) repeat actions
Final action: Set PB true (will happen after your condition is true, for example temp is no longer below freezing)
That way the whole time the rule is looping, it won't create a second instance of the loop if 'Something happens' again.
Two cautions with this approach are:
1: You can still get multiple instances running if the trigger event(s) happen multiple times within a few milliseconds. The second instance starts before the PB can be set to false.
2: The PB can get stuck in the false state if something causes the rule to exit abnormally without firing the last action to set the PB true again. Some users work around this by resetting all their PB's every night at midnight, or whatever interval is appropriate.
"Below 34deg" is the name of my Boolian Variable. I have one rule that will set it true/false depending on the temp. (In this test, I used 55degrees since it isn't that cold yet here in Dallas). Here is that rule:
Then, I have the loop rule. Right now my only action is just to send me a push notification to my phone. But this is just a proof of concept. I'll add my actual actions later:
I’ve not read this post thoroughly so if I’m way off please ignore. If you’re only wanting the rule to trigger when the temperature goes above/below a certain value and not trigger again until it goes back beyond the trigger temperature you can use a Boolean set by a separate rule and then reference that in your main rule. I do this for my lighting where I want it the lux level to trigger a rule as it passes a certain value then not trigger again. Here’s an example using lux:
It's fairly unusual to get down to freezing temps there right? Assuming yes, I'd try to restrict this rule more...
As is, this rule will trigger every time the temperature changes -- the vast majority of those changes will (rightfully) never invoke this rule.
Edit -- I get that setting/confirming the variable = false could be considered a nice (ongoing) result of this rule running all the time, but the main goal of this rule is really to set that variable = true when it's really gonna matter, and that shouldn't have to happen very often.
One of my goals when creating a rule is to limit as much as possible how often it gets called (triggered), and Reqd Expressions are great for that. When the Reqd Expression is false, then the rule is effectively paused. It's then one less thing my hub needs to manage -- sure, that doesn't make a huge difference in hub performance or anything like that, but it helps nonetheless.
In this case, I would make the Requred Expression something like "Temp reports < 38F" (or so) -- pad it a few degrees like that for wiggle room, but get it pretty close to the action temp (34?).
I'm not a big fan of using "changed" as a trigger**, but if you can box the rule in well with a good Reqd Expression and the rule's actions don't lollygag, then it should be fine.
** - depending on what's changing and how fast it can possibly change, "changed" as a trigger can induce race conditions. So that's why I avoid using it myself, but as long as it's carefully thought through and protected against, its use should be fine.
makes sence. And then make a 3rd rule for when it warms back up to put my variable back in to "false" mode? However....then wouldn't this run the rest of the year no different than I currently have?
And yes.....below freezing isn't too common in Dallas, but we will get it a couple dozen nights of the winter. And....well, because it dosn't happen often in texas, pipes aren't insulated well and given my old home....they freeze quickly. Ever since I implemented this concept....never a frozen pipe!!
I don't think an additional rule is necessary to ensure the variable gets reset to False.
Let's say we set Reqd Exp as <40F... At the end of an annual freezing "season", the rule will run a final time at some point -- for example, the nighttime temp will dip down to ~38/39 for the last time that year... The rule will trigger and set the variable = False. Then you're set until the next freezing season to start.
And when it does, the first "hit" (trigger) that next season will likely not be such a sudden/fast cold shot that the temp shoots straight past freezing, so same thing applies -- that first hit (let's say down to ~38/39) will ensure the variable = False.
