It looks like you may have manually triggered your true/false timer twice. It appears to be running in duplicate.
1 Like
Is there a way to prevent more than one instance of a rule running?
I’ll preface this with a reminder that looping like this isn’t something we officially support, but there are some best-practices you can use to help with this sort of thing:
Unofficial Variable Loop Rule Best PracticesThat being said, we are considering introducing a first class loop feature and are looking for feedback from the community on what use-cases they are using loops for (in general, event driven rules are preferred, but there are some use-cases where a loop makes sense)
Thanks @josh. I think I have it to only a single instance now with the Stays for xxx clause. This was a big deal because I was getting multiple thousand hits on OpenWeather API and it was starting to cost real money. This should take me from 2000+ pings daily to 72.
Hey Ken,
The multiple running is most likely caused by manually flipping your true/false AFTER it has already been started once. The second time triggers your rule while the first is still running. That will add another instance every time the variable is flipped.
1 Like
With the updates trigger, that’s absolutely right. The state stays trigger helps deduplicate the events which is why it’s the first thing listed in the unofficial recommendations linked above. 
Here’s my response from Ken’s other thread:
Yup…it looked like Ken was using DELAY, not STAYS. I’ve had relatively few issues since changing mine to STAYS, but… it’s not perfect. About 4 or 5 times a week I’ll have to restart my 10 minute weather timer. No errors or clues as to why it stops. No real complaints, just waiting for the “First Class” timer!!! LOL
Is there a way to tell it has stopped? This is one of the reasons I had parallel rules running. I have a once a day rule that resets my variables. If it hasn’t failed, I will now have two running.
I use another rule to alert me if the loop timer stops. Don’t know if right or wrong, but it does the job for me.
You might notice this is based off of a virtual switch being OFF or ON. I changed this timer to use a virtual switch instead of a variable. This one has not stopped since I created it as opposed to my variable based one that stops often. I don’t know what the difference would be… but…
2 Likes
I am trying to run some automations based on tonight’s forecasted low temperature. I am using the following openwether command:
condition = $context.response.data.daily.1.temp.min
This seems to return the low temperature for a 24 hr period based on the time the system is checked.
What is the proper command to use?
Are you using their OneCall 3.0 API or something else? It might help to show the actual URL / API call you are making - with your API key redacted of course.
I would also strongly recommend reading through their documentation - since it’s someone else’s product, referring to their documentation is going to be the best source of truth.
Also keep in mind that arrays / lists of data use zero-based indexes, so data.daily[1].temp.min would be the low temperature for tomorrow based on when the request is made. And data.daily[0] would be today.
I suppose the min or max for ‘today’ could have already occurred in the past… and similarly I suppose your concern is the ‘min’ for the day might not be overnight if the temperatures are trending downward later in the day from something like a cold front?
If you had a particular time range you are interested in, could you filter the hourly response to that range and then find your minimum value from that with an expression?
Thanks Josh. Here’s the actual call. I did review OWPs documentation, but I’m not a programmer and most of it was greek to me. Since I got the ret of the calls from posts on here, I figured those geniuses might have an idea for me. I have also asked the question at Open Weather.
Can you clarify what the issue is though? Is the issue what I described above and are you always looking for the minimum during a certain ‘night’ time range? Otherwise it seems like the daily[1].temp.min would give you tomorrows low temperature which is likely over night but could be during the day if a warm front was coming in late in the day or something I suppose.
OpenWeatherMap also seems to have eve and night values and it seems like those are supposed to map to 18:00 and 00:00 respectively if one of those fixed times might work for your needs (as it would be a much simpler way to directly access that temperature).
Source: OWM OneCall 3.0 documentation
daily.tempUnits – default: kelvin, metric: Celsius, imperial: Fahrenheit. How to change units used
daily.temp.mornMorning temperature.
daily.temp.dayDay temperature.
daily.temp.eveEvening temperature.
daily.temp.nightNight temperature.
daily.temp.minMin daily temperature.
daily.temp.maxMax daily temperature.Source: OWM Weather Date Response Parameters
temp.eveTemperature at 18:00 local timetemp.nightTemperature at 00:00 local time
Otherwise if you really need the minimum temperature during a specific time range, I would think the ‘hourly’ values from OpenWeatherMap might cover what you’re looking for but it would require building up an appropriate expression, so it would be helpful to better understand your constraints.
For example, are you only interested in the minimum temperature between a particular ‘night’ time range like 10pm and 6am? If the request is made in the middle of that range, for example at 1am, are you interested in the minimum from ‘now’ (1am) to 6am – or you always want the next interval which starts at 10pm? If there’s other constraints or sensitivities, it would be helpful to better understand what you’re looking for.
The automation that I want to run is the setback temperature for our furnace. For the first time in 10 years of smart home ownership, my wife asked me for an automation that sets a setback temperature based on the nights low temperature. Example:
Daytime Temp: 70F
Nighttime Temp if Forecast Low is >=40F: 62F
Nighttime Temp if Forecast low is <40F: 65F
With the current call, the system finds the 24hr low around the time the call is made. That may have happened 12 hrs ago and the temps may be rising through the night, so it doesn’t work very well. OWM help says they can’t do it directly.
The period to be considered is the upcoming nighttime between 10pm and 4am. What I am now thinking is to run an OWM request at 10pm for the upcoming daily.temp.night and call it good enough. If I am calling it at 10pm is it:
condition = $context.response.data.daily.1.temp.night
Since it is the upcoming night is it a 0 or 1?
I tried this out last night and it seems to work. Using “1” gets the temperature at midnight tonight. For my purposes, that’s good enough. Here’s the whole rule. In a nutshell, at 10pm, it checks that my thermostat is set to heat, that I’m not on vacation, does a forced refresh of the thermostat, calls open weather, parses the low temp and writes it to a variable, does some logic on the low temp and then assigns it as the thermostat setback temp. At the end, it checks if the thermostat is online, and if not, sends me a text.
