Hello, here is what I want to do. I am working on a rule where I want to check the outdoor temperature, but I don't want the rule to make an instant decision. I want to have the rule either recheck (re-evaluate) the conditions, or to maybe see a trend somehow. In other words, I want to ignore momentary temp changes or a brief dip due to clouds/sun etc. Goal is to set a private boolean either true or false if temp is too high, or too low.
Here is what I started with, but maybe there is a better way? I am not sure if the double IF>THEN in each statement will do what I want (double-check the temp) or add a delay to prevent swings back and forth between true and false here. (I used underscore below to keep the indents formatted)
Trigger: Temp of [Weather] changed.
IF Temperature of [Weather} is < 60 THEN
Delay 5 minutes
____ IF Temperature of [Weather} is < 60 THEN
____Set Private Boolean True
End IF
IF Temperature of [Weather} is > 75 THEN
Delay 5 minutes
____ IF Temperature of [Weather} is >75 THEN
____Set Private Boolean False
End IF
This logic seems fine, but I'm still a little new to what is possible / best in HE. I personally would want to make sure I could define the IF/THEN type logic in one spot and piggy-back on this in as many rules as I wanted, which I'm guessing is what the boolean variable is about. A bit like defining a mode change that many rules could then use as a trigger, if that makes sense.
It also sounds similar to the post I made about determining when my washing machine had finished a cycle (I don't know how to include a link just yet...). If your inclined to write some code you could look at a new app along the same lines as the better laundry monitor. Perhaps flicking a "virtual button" when certain temp thresholds are met.
Actually looking at the logic again, you may want to work on when the boolean will transition from false back to true, e.g. you go above 75 into the "hot" zone, but then this will only drop back to true when you go below 60. If you ever wanted to look at the variable for some kind of status of too hot, too cold or just right, then you may want to use a different data type for the variable.
I really do want too hot VS too cold. I don't want anything to happen if "just right".
You are right that the private boolean will be the basis for other rules. This will be used to change the thermostat from heat to cooling mode automatically. I don't want to make the switch too often, or even more than 1-2 times a day.
What I hope happens is maybe it starts out cold in the AM, and as the day progresses it gets hot. The house indoor temp lags behind outdoor temp. So because of this, there needs to be that dead zone where the thermostat mode stays as-is until the temp rises or drops significantly. I am not sure of these heating and cooling points, but this is were I think I want to start.
The thermostat itself can do this, but it doesn't allow warmer heat than cool settings, or identical settings for both. This is how I plan to get around that limitation.
If I could code, I would write an app. App writing isn't my thing, so the RM will have to do for now.
That makes sense now that you mention about not wanting to switch too often, and if the variable is just a trigger, then keeping the value throughout the dead zone doesn't really matter, you have the temperature reading for that.
Why are you checking if the temperature is still less than 60? The rule is going to fire every time the temp value changes, so there is no need to check the value of the temperature again. The problem you are going to run into doing it this way is that the rule is going to fire every time the temp reading is received. So, you are going to set private boolean false over and over and over and over and over. That's not a very efficient use of the hub's resources. I'm not quite sure why you have the delay either if you have a "dead band". If you are turning off <60 and on greater than 75 you have 15 degrees where no change will be made. So, if the temp fluctuates around 75, nothing will change and if it fluctuates around 60 nothing will change. The first time it dips below 60 it will turn off and the first time it is above 75 it will turn on.
What I don't want to happen is that it goes from 60 to 63 to 59 and back to 65 within an hour or so and the furnace or A/C flip-flopping from heat to cool repeatedly.
That was the intent of the "double check" temp to be sure the outdoor conditions remained where they were (in this case, 5 minutes ago) previously. Maybe I don't need that? But the weather can change fairly rapidly at times. Last night a storm blew through, and it dropped like 20 degrees in a few minutes. After the storm was done, the temp and humidity came back up and I wouldn't have needed to switch from cool to heat in that case.
That is why I was trying to get some input to see if there was a better way to do this, or if I am overthinking things. Maybe just that deadband would be enough?
Ideally I would like to do a prediction, and only change from heat to cool if the trend (weather forecast maybe?) was to end up above or below a certain point.
If I were to use the logic in your first post, I would use a periodic trigger of X minutes and remove the delays in the actions, instead of using temp. changes. As @Ryan780 mentioned, temp. changes will be triggering the rule constantly.
I don't know how effective basing changeover on outdoor temp. would be in practice. Where I live, the temperature swings outdoors are anything but proportional to indoor ones.
Another example that may or may not give you an idea- My Centralite Pearl does not have auto changeover so I had to make a rule to do it. The wife and I came to an agreement on setpoints. Cooling is 72, Heating is 65. Then I chose a point in between for the changeover, making sure heating or cooling cycles weren't going to cause a changeover. Since last November, the most mode changes in a day has been three.
I had to sleep on this rule and give it some more thought. Still not sure what I am going to do, but here is my latest thoughts.
I do think time base rule might be a better choice than temp. It is pretty likely that polling every couple hours would solve the flip-flop problem.
You are right, that indoor and outdoor temps don't have to be related, and often aren't. That was the idea of "way too hot do X" and "way too cold do y". At some outdoor temp you will want heat or cool mode no matter what the indoor is doing.
My Honeywell t'stat already can do exactly like you are doing. It has outdoor sensors and everything. But it won't allow the close or overlapping heating and cooling setpoints like I want. I want a fairly constant 68-70 if we are home no matter if we are in heat or cool mode, and then do the setback (either warmer or cooler) for sleep, away, etc. So your rule won't work in this situation because of the lack of split between heat and cool modes.
Thanks for the help everyone. I would be happy to receive further input.
Just putting my thoughts out here. I decided to try a periodic check, 4 times a day. Basically morning, noon, night, midnight. Maybe I will have to move those around a bit or make the times more or less often, but it is a start.
I am going to log this rule and see what happens for a few days. I also narrowed the rule to certain months of the year, this is really only needed in Spring and Fall.
And yes, I added the ENDIF after I did a screen shot.
