Thermostat Away change temp


#1

I’m trying to get a Piston to automatically recognize when we’re away and change the setpoint for a Honeywell Total Connect Comfort Thermostat

Recognize if we’re not home
If the thermostat mode is heat

  • then change the heat set point to 60’F

If the thermostat mode is set to cool

  • then change the set cool point to 80’F

The problem I’m having is when I try to create logic to recognize that the away mode has already been set, and then not send a request to the thermostat. In the image I’ve attached, it can get the thermostat to recognize that we’re away and change the mode when the pointed to lines are not in the Piston. When the lines are in the Piston, the change does not happen.


#2

I’ll import your piston and post something up in a few minutes.

Maybe this time you’ll mark my post as the solution instead of your own, lmao! :joy:


#3

Give this one a shot? If it doesn’t work, I have a theory on the DO action that we can look into. I don’t have a thermostat to verify it with.

if this doesn’t work the way you want it to, can you post up log files for me to look at?

Thanks!


#4

I have a Honeywell Thermostat that I set back as well. My code is similar to what @michicago posted without the nested IFs, so that ought to work.

Going back to your original question, I’m not sure why you need the third lines you pointed to. You are changing the setpoint to that value anyway, so I would not bother testing to see if it’s already there. But, if you want them to remain, try using “Equal to”, “is greater than or equal to” or “outside range” instead of “is different than”. These are decimal value comparisons and I’m not sure “is different than” is appropriate.


#5

@Bry Thanks for your review and input. Overall my program was working, but when we were away, the command to reduce the heat setpoint was triggering to the thermostat every time it ran; every 15 minutes. I’d like to have a cleaner Piston that only sends a command to the thermostat when a change is needed.


#6

@Bry, Even after trying other options for the comparison temp, I’m experiencing the same issue; the Piston does not send a command to the Thermostat.

I can get the Piston to work without the highlighted temp comparison line, but it sends a command to the thermostat each time the Piston runs; every 15 minutes. Is there any harm in that?

@michicago,
I tried your suggestion, but it didn’t seem to kickoff, or at least it didn’t register in the Device Event List. Here’s a copy of the logs.

Thanks for your help.

image


#7

Hi Tim. The version I provided won’t do anything if the test button is pushed because the condition for all presence devices not to be present will be false. If that’s false, none of the piston runs.

Try letting it run when your presence sensors are actively changing and, at least once, nobody is home, then see how it’s working. If something isn’t right, we’ll get it fixed.


#8

I’ve never contemplated if there are issues with something running that frequently and I write my code differently. In your case, the piston runs based upon a set conditions and not upon a trigger. While that will work if written correctly as webCore evaluates the conditions if it can’t find a trigger, that may not be the cleanest way to write the code.

In my case, my SHM mode changes when no one is present, and I use the mode change event to trigger the piston. Here is a simplified version. You can differentiate a trigger from a condition by noting the lightning bolt in the left margin for the trigger. You can only have one trigger per statement.


#9

@michicago,
I just got around to setting up a new Piston, as you suggested, it did appear to trigger when we left, but the temp change to the thermostat did not happen.

Here’s the Piston, with logs below. Thanks for your help.

image

Thanks for your help.


#10

I think it’s not running because it evaluates presence sensor 1, which changed to not present, so true, and then presence sensor 2, which did not change at exactly the same time, so evaluates as false and exits the piston. You would basically have to do if any of presence1 or presence 2 changes AND presence 1 is not present AND presence 2 is not present.

I take a different approach for presence.

Here’s what I do for my ecobee (and other stuff)

  1. I have a background piston that runs every time a presence sensor changes, and sets a global variable of @HouseOccupied (true or false). I can use this variable in any piston where I need to know whether anyone is present.

  2. I have a piston that triggers when @HouseOccupied changes to False. No one is home. This lets my centralize everything that should happen when no one is home - shutting off lights, changing thermostat, etc. Note that I set both the heating and cool points. Doesn’t really matter if I change the heating set point when the air conditioner is running, and it simplifies the piston.

  3. I have another that triggers when @HouseOccupied changes to True. Someone is now home. I just resume the regularly scheduled programming on the thermostats instead of setting a temperature.
    image


#11

Thanks. I’ll give it a try.
For the @HouseOccupied global variable, is there anything else to setup in addition to the Piston (example you provided). Once I get the global variable setup, is there a way I can query or have it report it’s current state? thx!


#12

I do something similar to @milhouse but I use numbers of occupants instead of true/false. That way if someone comes home but the house is already occupied, I can run a different lighting scenario than if one or more people come home to an empty house.

He was also right that your piston wouldn’t ever return true because you had “presence 1 and 2 changes to not present”. Just change it to “are not present” and you’ll get the effect you’re after.


#13

@michicago “Just change it to “are not present””

That fixed it. Thanks!


#14

@michicago,
I’ve continued to refine my Thermostat Geo-Fence driven piston, and have decided on a final usecase. However, I’m not able to get it to work as I’d like. This is what I’d like it to do:

When any of our presence changes:
–If All of us are not home
----When the Thermostat is set to Heat
------Set the temperature to 60’
------Send a text message
----When the Thermostat is set to Cool
------Set the temperature to 82’
------Send a text message
----When Any of us arrive home
------Resume the program

I’d appreciate any help you can offer to edit the piston.

Thanks for your help!


#15

This should do what you want it to - hopefully this is cleaned up a bit and easier to follow. Any questions on how it works, just let me know!


Thermostat Setup
#16

Thanks. It’s running now. I’ll report back in a day or so. Really appreciate your help!


#17

@michicago
Really appreciate your help! The piston has been functioning as I hoped.

Regarding the logic, if I add another presence sensor to my house, would I modify the piston as follows:

if
–Presence Sensor 3’s presence is present
then
–Set variable {Occupancy} = {Occupancy+1}

Also, if I would like to use this logic to control other ST devices, should I create the same logic in another Piston [Piston-x], or should I create a Piston [Home_Presence_Piston] with this logic, and have the Piston-x call Home_Presence_Piston?


#18

Glad to help!

You got it!

I would leave the logic in this piston (or you could create a standalone “presence” one like you mentioned. Then just change the variable name to @Occupancy and your other pistons will have access to it. In addition, they can trigger off changes to it… so your other pistons can simple say “IF @Occupancy changes, then…”.

I have a standalone presence piston that also creates tiles on my webCoRE Dashboard. You can look here for reference. If you have any questions, let me know and I’ll try to help!


#19

Ah, forgot those examples don’t have the global variable. This is what my piston looks like now - simpler to add devices to it the way you mentioned above… or you could get fancy and do a “FOR EACH” loop, but it didn’t make sense for just 2 presence sensors.

Ignore the variable in this sample too - was going to try a different method but scrapped it.