You're right, because as it is now, RM will only zap one Thermostat Scheduler at a time. I will put doing multiples on the enhancement list, possibly for next release.
One other quick question. If I create a rule to set a different temp than in the scheduler and put the stat on hold when I take the stat off of hold it should revert to the temp setting in the scheduler right?
No, turning hold on or off does not affect the setpoint settings. It simply allows the schedule to operate or not.
Your asking about this allowed me to discover a bug with setting hold on or off from Rule Machine. Fix will be in next release. I don't think it works now, although it may look like it does superficially.
I wonder if this could be used to set my Ecobee thermostats as well as my virtual thermostats to heat or cool based on the hi temp outside which is available in the APIXU driver?
I'd like to hijack this a bit....
I've set a RM4 action to change my virtual thermostat (vTstat) when it's very humid (RH%) in the house (the coolingSetpoint (lowered), thermostatMode (cool), thermostatFanMode(on) while RH% is GTE 70%). This works just fine.
[The vTstat then calls KeenectZone which adjusts vents and talks to the real-world Tstat (ecobee3).]
When the RH% drops below my threshold of 70% I want RM4 to "release" its control. So, here's my Qs:
In the ELSE of the rule, will I need to reset all the params (that the RM4 changed (when the RH% increased), or is there a way to just set the TS back to its "default" settings (Mode or Time of Day)? This return to "default" I'm guessing is akin to what happens when you toggle HOLD.
Thanks
Can you provide any suggestions for the following use-case for RM controlling TS:
I'd like to set schedules for a thermostat using only TS, but use RM to control whether the schedule should be followed or ignored (ie., RM would turn the thermostat off or allow TS to set it to the schedule, RM would not "hold" at the current setpoint in TS) based on whether a motion sensor is active or not.
I'm not sure what action to have RM send to change the thermostat mode from "Off" to whatever mode TS would use at the moment, based on the setpoint & time (which could also be "Off").
I'd also create a virtual switch, visible on my 'Heating & Cooling' dashboard, to set a variable about whether to use the motion sensor or not.
Logically, the RM4 rule would be something like:
if MotionSensor(CHANGED) AND GlobalVarUseMotionSensor == TRUE then
if MotionSensor(ACTIVE)
if LocalVarThermoSchedulerAlreadyEnabled == FALSE
/* allow TS to take control, as per it's schedule & setpoints */
enable ThermostatScheduler
set LocalVarThermoSchedulerAlreadyEnabled = TRUE
cancel pending actions
endif
else /* motion sensor changed to inactive */
/* turn off the thermostat, then disable TS for that thermostat */
send ThermostatScheduler(off) delay 10:00 cancelable
disable ThermostatScheduler delay 10:05 cancelable
set LocalVarThermoSchedulerAlreadyEnabled = FALSE delay 10:05 cancelable
endif
endif@bravenel, is there a way for RM to enable/disable TS management of a thermostat, instead of having RM change a setpoint or schedule? (Original query)
I guess it depends on what you want to do. For example, assuming that something else other than TS will be in control, you could simply put TS into hold mode. That stops TS from doing anything based on its schedules. Then whatever else is going to control the thermostat could take over.
OK. So I'll turn the thermostat off, then put TS in hold mode.
When turning the hold Off, do you suggest
- putting the thermostat in "mode=auto/fan=auto" first
OR - not sending any settings to TS or the thermostat -- the current schedule will take effect when hold is Off
OR - change the thermostat (mode=auto/fan=auto) then turn hold Off in TS
The rules I've got now are:
Trigger Events: Den (Motion 4) *changed*
IF (Den HVAC Motion Control(off) is on(F) [FALSE]) THEN
/* "Den HVAC Motion Control" is a virtual switch, to enable/disable motion control of HVAC via a dashboard */
IF (Den (Motion 4) active(F) AND
Variable State(HEATING) = OFF(F) [FALSE]) THEN
Cancel Delayed Actions
Thermostats: Den HVAC:
--> Mode: auto
--> Fan: auto
Thermostat Scheduler for Den HVAC: Set Hold off
Set State to 'HVAC Active'
END-IF
IF (Den (Motion 4) inactive(T) AND
Variable State(HEATING) = HVAC Active(F) [FALSE]) THEN
Thermostat Scheduler for Den HVAC: Set Hold on --> delayed: 0:15:00 (cancelable)
Thermostats: Den HVAC: --> Mode: off
--> Fan: auto
--> delayed: 0:15:00 (cancelable)
Set State to 'OFF' --> delayed: 0:15:00 (cancelable)
END-IF
END-IF
Removing the hold won't do anything. TS would start scheduling again upon the next scheduled setting.
I don't understand how to parse these two statements:
That seems clear, and to me it implies that turning hold Off will allow TS to resume control of the thermostat via its schedules, but it doesn't seem consistent with your next statement:
Huh?
If "removing the hold" doesn't do anything, then what is the purpose of setting Hold=0n or Off?
Let's say the TS schedule looks like:
9AM Leave 62F
5PM Return 65F
and at 4PM my rules send "Off" to the thermostat and send "Hold = On" to TS. Does the statement
mean that at 5PM the heat would come up to 65F (that the previous hold "expires" upon the scheduled setpoint change)?
What I meant is that turning hold off does not cause anything to be sent to the thermostat at that instant. What it does do is allow TS to again control the thermostat per its schedule. Turning hold on stops the schedule from controlling the thermostat.
OK.
Is there any way to have RM turn a thermostat off when the room is idle and have it turn on, under control of TS, when the room is active?
Turning the thermostat off and putting TS on 'hold' is easy.
Turning the thermostat on with RM supplying the setpoint & mode is easy.
Having RM take TS out of 'hold' is easy...but that doesn't seem to immediately enable TS to resume control. I wonder if TS will only change the thermostat when there is a transition to a new time period, with a setpoint & mode that differ from the current state.
Is there a way for RM to query TS, asking based on the current time, what would the setpoint & mode & fan status be if you weren't on "Hold"? With that information, I could have RM duplicate those settings, then take TS out of Hold. Cumbersome, but possible, I guess...
2 Likes
TS simply sets the thermostat setpoints on a schedule. Putting it into hold stops it from doing that.
Perhaps what you want instead of Hold is EcoMode, with a wide spread value. Turning on EcoMode changes the setpoints away by x degrees (effectively turning off the thermostat), and turning off EcoMode puts them back to where they were before.
It looks like EcoMode might work, except I'd need more than a 5F temperature adjustment and I'm not using 'modes' -- your initial announcement of EcoMode seems to say that it's tied to Hubitat being in "Away" mode. Is that a requirement if EcoMode is initiated by RM?
Having Away set EcoMode to on is just an option. It can be turned on/off by RM.
Can we use multiple schedules for all the seasons?
Within Thermostat Scheduler itself, no, it has a single schedule. Using RM to change it, yes, you could change it per season.
I had some difficulty related to the topic of this thread, so I am posting my experience. I use dashboard tiles (via Rule Machine v5) to change any one of these seven settings on TS: wake/night times, night heat/cool temps, wake heat/cool temps, and TS Hold. I created seven hub variables (4 decimal types, 2 date/time types, and one boolean). I made a single rule in RM that is triggered by a change in any of the seven variables. The action of the rule is to set the appropriate settings in TS, using the seven hub variables.
I tried different approaches to implement the above, and ran into issues. What worked: I configured TS to read the hub variables directly; and then the sole action in my rule is the "Activate Scheduled Setpoints" in the TS.
Alternatively, what did not work, I tried to use the RM to set each setpoint in TS, using the hub variables. I configured TS with static values, with the intent that the rule action would replace those values. I got poor results:
-
I got errors (ArrayIndexOutOfBoundsException: 1 on line 1343) in my logs when the rule action used the date/time hub variables to set the wake and night times.
-
Even when using static time values, I did not see evidence that the TS was getting updated as I expected. This test was done during the Wake period: When I changed the Wake Time or Wake cool/heat temps, I did see that the Wake Time and the Wake Cool/Heat Temps were modified and shown changed in TS as expected. However, when I changed the Night Time or Night cool/heat temps, I did NOT see that the Night Time and the Night Cool/Heat Temps were shown changed in TS. But then, oddly, if I clicked into the TS edit area for changing the heating/cooling schedule, and then click Done w/o making edits, then the TS configuration displays the revised Night Time, but still not showing the revised Night Cool/Heat temps.
-
I tried putting a hold on the TS while the setpoints were changed, but that did not change my poor results.
My Dashboard
Hub variables:
Rule that worked:
TS Configuration that worked:
Rule that did not work:
TS Configuration that did not work:
Thanks for this post. Evidently the implementation of variable time in RM controlling Thermostat Scheduler is deficient. We will get this fixed for the next release.
2 Likes
