I’m using a piston to return a thermostat to it’s normal schedule from a permanent hold, conditioned upon motion sensor activation. That is working fine.
In the interest of not firing each time there is motion, I’m trying to add a condition to fire only when the thermostat is on a permanent hold. However, I can’t find that condition to evaluate it. I see a number of thermostat conditions, but none that evaluate whether or not the thermostat is in a permanent hold.
Am I missing that? Or workaround suggestions?
I’m using WebCore and have CT101s, so not sure if this would work for you. But what I did in my thermostat schedules is have it check a virtual switch’s state and if the “Thermostat Hold” switch is on then the schedules don’t run. I use this in conjunction with two other Momentary Tile virtual buttons – one triggers “Home Hold” and the other “Vacation Hold”. Basically, push the momentary button and it sends temp commands to the thermostats and then turns on the Hold button.
Hope that makes sense.
That does make sense, and I thought about doing that. The problem is that the thermostat is set from either the Honeywell app or manually at the thermostat. So I’m not sure how to throw the switch.
Which thermostat are you trying to use?
Also, why are you checking that it’s on perm hold? If there is motion and you’re already running on schedule it doesn’t hurt anything to send resume program again. As long as your motion sensor has a timeout period, say 10 minutes, and you only send the resume program from Core when it changes to active, you shouldn’t have a lot of resume program commands from the piston… unless this is an area you go in frequently but don’t stay in long. For example, a bathroom in a busy house. The only issue i would see is if you are setting a temporary hold in either the app or on the thermo (can’t set temporary hold from ST) and you don’t want to lose that temporary hold when motion is detected.
You should be able to find a list of the parameters stored in ST under the ide. I recently upgraded from Honeywell to Ecobee because of other issues with Honeywell (remaining idle forever when recovering) which prevented me from automating my ceiling fans with my A/C so i don’t have a device to pull up the list of parameters that honeywell populates for ST.
I have a Honeywell Total Connect. When I’m away from the house, I set the thermostat back to a permanent hold either at the thermostat, in the thermostat app or via IFTTT. So I want to check the hold status so that the piston only fires when needed. It’s just cleaner that way.
When I come back to the house, I want to release the permanent hold using the motion sensors. I’ve tried using IFTTT for this (connecting/disconnecting from a router) but it is not that reliable.
I can get the permanent hold to release with a CORE piston, but I don’t want it to keep firing. One of the motions has a longer timeout, but that’s only minutes. I want to have the rule run only when it has to.
I may be at the vacation home days at a time, during which the piston does not have to fire at all, because I may not put the thermostat into a permanent hold.
Do you know how to access the ST ide? If you look at the device there it will list all the available parameters. I don’t have that device anymore so i can’t look it up myself.
I took a look in the IDE and can see that there is no state that defines if the thermostat is in a permanent hold.
So I guess that answers my question. I may need to presume the permanent hold state by looking at the programmed temperature, as I typically set it to the same temperature when invoking the permanent hold. I guess I’ll just have to account for both heat and air with some sort of OR.
It might not be a separate parameter. If you don’t want to copy/paste them here, that’s fine but that means I can’t help you.
Look at the params with perm hold on and then with it running based on schedule. I’m willing to be something within the list will change, if you’re looking at the right list.
Thanks. It’s in permanent hold now, but nothing changed from when it wasn’t:
Type Honeywell TCC 8000/9000 Thermostat
Device Network Id 924721.00D02D5AE0D4.972922
Last Activity At 2018-02-17 10:07 AM EST
Date Created 2018-02-17 10:07 AM EST
Last Updated 2018-02-17 10:07 AM EST
Data No data found for device
temperature: 70 F
humidity: 40 %
heatingSetpoint: 70 F
coolingSetpoint: 75 F
thermostatSetpoint: 70 F
[auto, on, circulate]
[cool, heat, off, auto, emergency heat]
maxHeatingSetpoint: 90 F
minHeatingSetpoint: 40 F
maxCoolingSetpoint: 99 F
minCoolingSetpoint: 50 F
And do you really have an 8000/9000 thermostat? when i had my honeywell 6000 series it was always getting updated to a different DTH than what i was using.
I really think that you will be fine with the piston without checking to see if it’s on perm hold. It shouldn’t cause it to be fired that often.
Also, have you given any thought to a different trigger than a motion sensor? What about a good morning or I’m back routine? That’s what i use. Just a thought. Good luck
So here is what I finally settled on. After giving the circumstances some consideration, I realized that querying for a permanent hold status wasn’t the best approach.
To recap the issue, I have thermostats that get set back to a permanent hold through either manual entry at the thermostat, through the thermostat’s app or through an IFTTT routine. My goal was to release that permanent hold from the thermostat through some presence routine.
As additional requirements, I didn’t want sloppy code that fired when not needed. I also wanted performance for others that do not use the Smartthings app.
I decided to release the holds based upon motion from select motion sensors so that any occupant of the house would trip the routine upon occupancy.
Using webCore, I defined an Or-If statement that resets the thermostat based on two conditions, a motion sensor changing to Active and a temperature reading from the thermostat set below or above a certain temperature. For the temperature trigger points, I picked values two degrees below the typical setpoint (for the winter) and two degrees above the typical setpoint for the summer.
Using temperature readings from the thermostat as trigger requirements allows for a delay or sorts. When the thermostat is set low in the winter, for example, it will be a while before the temperature drifts down 2 degrees. So if the permanent hold is set a the thermostat for example, You can still walk around the house for a while and not inadvertently release the hold on the thermostat right after you set it. It also keeps the code clean by limiting firing when the thermostat is in the permanent hold mode (assumed by temperature above or below normal setpoints).
So basically the rule i.e. piston goes something like this.
IF x motion sensor changes to Active AND temperature is at or below 67 degrees, OR
IF x motion sensor changes to Active AND temperature is at or above 77 degrees, THEN
Run the routine to release the permanent hold from the thermostat.
Hope this helps someone!
So, this wouldn’t return to schedule if you had a perm hold at 69 degrees for example?
One thermostat is typically set to 70, so 69 would not cause the rule to fire, nor would I want it to. That thermostat is set back to a permanent hold of 62 in the winter, so it’s set to trigger at 68. If the thermostat is usually set to 70 and then set back to 62, the temperature in the house could possibly drop back to 69 while you are still there, causing the rule to inadvertently fire. Hence the 68 degree setting for that 'stat.
This will also release a temporary hold, so if you do one of those and then leave for a bit, it will release that hold as well upon your return.