[RELEASE] Turn Thermosat Up/Down When Away (based on motion or presence)

⚙️ Custom Apps and Drivers
1

On ST and Hubitat, I used a webCoRE piston that monitored select motion sensors around my house and turned my thermostat down (usually a few degrees) to an "away" setpoint when I wasn't at home. I know a lot of people probably use either "smart" thermostats that have this functionality built in to the manufacturer's own app, while others probably use Life360, ST, webCoRE, or another app to detect their own presence. However, I don't use presence on my phone, and my thermostat is intentionally a "dumb" smart model that only integrates with my HA system, where I can perform all the logic (that's why i got it, right?). [EDIT: I've changed my mind and integrated optional presence sensors into this app too. Now, if you set both presence and motion sensors, it will wait until both conditions are met. If only one or the other is set, it will, of course, only wait for whichever is set--so if you only set motion, it still works exactly as the previous version without presence.)

Anyway, in trying to move away from webCoRE, I thought I'd share the custom app I wrote to replace this piston. It allows you to choose any number of motion sensors to monitor. When all remain inactive for the specified amount of time, the app will change your thermostat's heating or cooling setpoints to the values specified in the app. It can also be restricted to only change the setpoint during certain modes or times of day.

Here's the GitHub repo for this app, creatively named "Thermostat Up/Down When Away":

https://github.com/RMoRobert/Hubitat/tree/master/apps/Thermostat%20Up-Down%20When%20Away

Last modified: 2018-11-08 (bug fixes)

Or, if you prefer, you can copy and paste the raw code or its URL here: https://raw.githubusercontent.com/RMoRobert/Hubitat/master/apps/Thermostat%20Up-Down%20When%20Away/Thermostat%20Up-Down%20When%20Away.groovy

(NOTE: I have a Zen Thermostat and have only tested it with this device, which provides a readable "thermostatSetpoint" attribute but requires setting either "heatingSetpoint" or "coolingSetpoint." You may need to modify the code if your thermostat acts differently, as I know at least on ST there was some variation here. This seems like it should work for most, though. I also have it hardcoded to not change the setpoint if the existing setpoint is within 0.9 degrees of the target setpoint due to the fact that the Zen tends to change to something like 54.9 instead of 55 °F, and I didn't want to bog it down with requests to change the setpoint when that's as close as it will go.)

Feel free to let me know of bugs and/or horrible coding. Just wrote it this morning and it seemed to work OK for me today, but your mileage may vary. :slight_smile: (Also no idea if anyone actually wants this, but for me, motion sensors are the best indicator I have of if I'm home. I also thought about adding door sensors but it's bit harder to code "time since last opened or closed event" and my piston didn't do it, so I didn't bother.)

2 Likes
2

Oh man! Here I thought I was the only one experiencing this. Thanks.

I’ll give your app a whirl when I get home in about a week and a half.

3

Yeah, mine did that on both ST and Hubitat, so while it could be something with the DTH/driver, I suspect there's likely something about the device itself (maybe it uses Celsius internally and converts to Fahrenheit if you have that selected? but that still seems unlikely since these don't match up with integer Celsius values either). In any case, I figured giving slightly less than one degree (0.9 degrees) of leeway on either side should prevent unnecessary commands from being sent to the device (important to me because I also have virtual dimmers synced to the thermostat setpoint and temperature levels to faciliate Alexa access via a simulated thermostat on ST until Hubitat gets native support :slight_smile: ).

4

In the event anyone is using this, I updated the app today. The app did not work if you disabled debug logging since the motion-handling event was accidentally entirely nested within an if which checked that and whose contents therefore never executed. :slight_smile: (Oops.)

1 Like
5

Update released! (Version 2019-02-27.)

This adds presence sensors as an option you can choose to turn the thermostat up/down when away. If you don't use this option, it behaves exactly as before. (Yes, I've given in and am finally toying with a presence sensor.) So, the possibilities are now:

  • Set motion sensors only: thermostat will turn up/down after your specified delay after all become "inactive"
  • Set presence sensors only: thermostat will turn up/down when all specified sensors become "not present"
  • Set both motion and presence sensors: thermostat will turn up/down when all motion sensors are inactive for specified delay and when all selected presence sensors are away

I may rethink that third combination, since many current options for presence are notoriously unreliable, and if you get stuck "present" or "not present" when you aren't, it may be nice to have the motion-sensor outcome still happen as a "backup." I'm going to try this out myself for a while and see how it feels, but I also welcome others' ideas in case anyone besides me uses this. :slight_smile:

6

New update! (2019-03-13)

Added the ability to use "or" instead of "and" for motion and presence conditions if both are set. (I did, in fact, change my mind after my HomeKit-based presence sensor decided to stop working reliably until I logged out of and back into iCloud, something I'd prefer to not have to do on a regular basis.)

Link to code in original post.

7

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.