Thermostat Programming

I am hoping someone more “logic” savvy than me can help. I have a thermostat I would like to program to change between heat and cool depending on the temperature, then to set the heating temperature or cooling temperature based on time of day and day of week.

I am struggling to tie it all together. I can figure out how to do it for heat or for cool…but true/false causes the two separate conditions to overlap. Ideally I want the cooling to kick on at or above 77F and the heating to kick on at or below 67F. From there I would like to drive different heating and cooling temperatures for times when I should be home versus when I should be gone. For example, heat at 69F during a given day/time combination or 65F outside of that time frame; cool at 72F and 77F for the same respective time frames. I am sure it’s simple, I just need a nudge in the right direction please!

Not sure if this helps but I would break down into 3 Reactors, 1 for Heating, 1 for Cooling and the other to control which condition you need ie Heating or Cooling.
I’m sure there will be a plethora of other suggestions coming soon, so I’m looking to read how others would do it with reactor.

Let’s approach this incrementally. Don’t try to do everything at once. Learn it step by step.

Let me get my caffeine system going (there’s too much blood in it this morning), and I’ll edit this post with more detail…

1 Like

Thanks, that is exactly what I managed to kludge last night. I have the “control” Reactor setting the mode as well as toggling the other two reactors on and off. My concern now is actually not so much with the logic (since I am optimistic about how I pieced it together) and with whether or not the thermostat is actually taking the command. :grimacing:

Thanks! That is how I tackled it, I just feel that there must be a much more elegant approach that doesn’t involve so many separator Reactors. Part of my failure is that I have not yet figured out how to make a true/false of a sub-category conditional upon it’s parent also being true.

OK. First step… let’s set up the emergency heating (<=67) and emergency cooling (>=77) temperatures. Here are the conditions, grouped:

The “Emergency Cooling” group looks to see if the thermostat is not in cooling mode and the temperature is >= 77. If that is true, we need emergency cooling on (we’ll get to that in a moment).

The “Emergency Heating” group checks to see if the thermostat is not is heating mode and the temperature is <= 67. If that is true, we need heating on.

Now… action…

The “Emergency Cooling is TRUE” activity will fire when the Emergency Cooling group goes true. The actions here force the thermostat to cooling mode and set the setpoint to 67. That’s it. The “Emergency Heating is TRUE” activity does the same for heat.

Now, on to simple home/away temperature control… (coming soon)

Edit: just noticed an error in the heating activity–it should set the heating setpoint, not the cooling setpoint. I’m not going to redo the screen shot for that. Just know you need to set the correct setpoint for the mode you want.

Question for you, @JoshMcMadMac … does your thermostat do auto-changover between heating and cooling? Big difference in approach to the rest if it does or does not.

Good stuff! I only have “SetCurrentSetpoint” on my thermostat, which may make things easier or harder depending on the conditions, I think :sweat_smile:

Yes…but I really do not like it. I have tried the controls through Reactor as well as the Auto Thermostat App, but for how I use the thermostat I would much rather suffer through programming it to switch between heating and cooling.

OK. So let’s rewind a bit here, then. Since we’re going to do part of the job of the thermostat, let’s make our own setpoints for the thermostat to obey. We’ll do that by creating four “Expression/Variables” (on the same-named tab in your ReactorSensor):

We’re going to use heatsp and coolsp to store our current heating and cooling setpoint, when we get around to that. So these variables have been created by name, but they have no expression–this lets us set them externally. We’ll get back to that.

In order to keep sanity in the thermostat and safety of the house, we put our setpoint variables through min/max functions to bound them to our desired limits. So climit is bounded cooling setpoint and will never go above 77, while hlimit is bounded so it can never go below 67. You may want these ranges further out, but let’s stick with them for now.

Now that we have our variables, we can modify our “Emergency” groups that we created previously by doing two simple things:

  1. We will change their names from “Emergency Cooling” to “Call Cooling” and from “Emergency Heating” to “Call Heating”.
  2. In the “Device State” expressions in each group, where we previous had values 77 and 67 “hard-coded”, we’re going to use variable references. So where we had 77 we will put {climit}, and where we had 67 we will put {hlimit).

Finally, go in and change the actions just as you did the conditions: where we previously had coded “77” to set the cooling setpoint, put in {climit}, and where we previously had “67” put in {hlimit}. This will make those actions use the values of those variables to set the setpoint. And it’s OK if your thermostat has a single “Set Setpoint” action rather than separate setpoints for heating and cooling–that’s not uncommon–just use what’s available to you.

At this point, you have a ReactorSensor that functions as a virtual thermostat to keep the temperature within the range of hlimit to climit, simulating auto-changeover by the actions setting explicitly the desired operating mode and setpoint as needed.

Next step… getting your different setpoints in for home/away/time of day…

1 Like

IMO
Rigpapa if it were not for your Reactor app and Richards Pleg app I am not sure how worthwhile my vera would be. Thank You for your fantastic work.

3 Likes

Better still, we’ve set the bar really high for the engineering team to write their own rules engine! I’ve said before, it will be a good day when they make Reactor obsolete. Yes, I am throwing down the gauntlet. :smiley:

5 Likes

Build or buy…

Just a thought like :wink:

C

1 Like

No need to reinvent the wheel. Just buy it!

2 Likes

Warning: Thread hijack
PLEG was the only thing that kept me with Vera, all was good until UI5 became obsolete ( I still have have the house running UI5 and it has never missed a beat), anything after drove many away. Reactor is a valuable addition and easier for new comers to understand rather than the Boolean of PLEG. Both have their uses and without either Vera would be nothing.
Patrick, you’re money is safe, unfortunately any royalties that you should receive in making Vera a marketable & commercial product will go into the Atom.
By the way that’s a very elegant solution for Environmental Control, if I every merge my GEN3 and GEN 5 systems I’ll use this solution for HVAC Control. :slight_smile:

1 Like

OK… back on track here (and thank you all for the compliments–appreciated!)…

Now, to get temperatures to what you want, you just make groups with the rules. Here’s a rule that will set temperatures to 69/72 when house mode is home and it’s between 6am and 10pm. First, the conditions:

This is an AND group, so both conditions have to be true for the group to be true and run its activity.

Activities:

The “is TRUE” activity for our new group sets the heating and cooling setpoints to the “home daytime” temperatures (69/72).

The “is FALSE” activity supplies “night or away” temperatures–it restores the default temperatures when we’re not home and daytime. Because there’s only one temperature control group, we can get away with using “is FALSE” on that group. But, if we were to add additional temperature groups (e.g. “home night”, “horribly cold outdoors”, “horribly hot outdoors”), we would not use “is FALSE” anywhere; we’d want to set up a separate group to be the default when none of the other temperature groups is TRUE. Here’s a group that does that (not showing the details of the three additional control groups):

Notice that this is a “NOT OR” group… it uses “Group State” conditions to look at all the other temperature control groups we’ve created. If any of them is true (i.e. in control of setpoints), then this group will be false. If and only if none of those groups is true, however, then this group will be true, and its “is TRUE” activity would then be where we restore the default system temperatures (67/77).

Making sense?

3 Likes

It sounds like a suitable path is being reached so I offer this as additional information that may or may not be helpful. I am not a Reactor user but here is what I have done in PLEG.

For mode, I check the outdoor temperature (you can use the VTOS plug-in or something else. I use the Darksky plug-in). If >65, I set the thermostat to cooling. If <60, I set it to heating. This really works well in the spring and fall when you may be heating in the morning and cooling in the afternoon.

Then I set my thermostat depending on the house mode. For Home, I set heating/cooling setpoints at 68/75. Away 65/78, Night 65/72, and Vacation 60/80.

Night mode is set at particular times during the week and weekend end. I have a Holiday virtual switch (VS) which extends the weekend schedule to a holiday. Night mode is not enabled if both iPhones are away.

Away mode is set when both iPhones are away. I have a Guest virtual switch which acts like a 3rd iPhone to not freeze/roast my guest(s) and not be bothered by a bunch of motion alerts and recordings of people moving about my house.

Vacation mode is set when both iPhones are more than 100 miles from home. Again, Guest VS overrides this.

I rarely touch the thermostat.

1 Like

Awesome stuff @rigpapa, thanks so much! With your guidance I think I have it functional. A hiccup I think I figured out is that I do have separate heat and cool setpoints, but they are labeled identical so I could not tell I was setting them incorrectly unless I went into each menu, scrolled down, and insured I had the proper one selected.

1 Like

HI @rigpapa

Many thanks for the Reactor plugin. I have been following this thread with great interest. I am trying to setup the aircon which does heating and cooling in our office. I am just trying to work out how to do two parts. When to turn on the heating/cooling and when we leave the office, but might put the alarm on during the day. also if we go into the office outside of the hours do nothing might be getting a tool, but i might go in for a day over the weekend and manually turn on the aircon via remote (vera would not know about this) but the office temp would rise.

What i am trying to achieve is:

Winter
In the morning workday, if its cold outside turn on the heating.
when the alarm is armed and it will be cold tomorrow keep the heating on set to 19oc (which is programed to heat 10oc)

Spring
In the morning workday, if its cold outside turn on the heating. unless the office is already=>17
in the afternoon turn on cooling if needed
when the alarm is armed and tomorrow the morning weather will be =>14 turn off the aircon

Summer
In the morning workday, dont turn on the aircon
when the office starts to get warm turn on the aircon
when the alarm is armed turn off the aircon

Or am I over thinking this?

Final part is currently i have a vera scene called “Aircon heat” that allows alexa to turn on the heating. but would not be needed if they was some logic. :slight_smile:

Tried to create a logic summary and i got “Handler failed” (using the beta version 3.5)

It’s up to you. If that’s what you want to do, have at it. Similar things have been discussed in other threads in this category. A few people have done things like this. My only caution is, if you are manipulating the mode and setpoint of your thermostat, be very sure your logic is set up so that only one active group (i.e. a group that has activity actions to control the thermostat) can be true/active at a time. If it’s at all possible for more than one group to be true, it will happen and they will both compete for control, with unpredictable/unexpected results.