Rule Machine control of Thermostat Scheduler

Rule Machine control of Thermostat Scheduler

Rule Machine has a new feature for actions that allows rules to change settings of Thermostat Scheduler. To use this feature Thermostat Scheduler must already be installed.

The actions available are the following:

  • Set EcoMode on or off.

  • Set EcoMode offset.

  • Set Hold on or off.

  • Set the heat and cool setpoints for mode based schedule for a specific mode.

  • Set the time, and heat and cool setpoints for a days/times based schedule period.

  • Set the heat and cool setpoints for Away mode for days/times based schedule.

  • Cause the current scheduled setpoints to be activated as if pushing Set Scheduled Setpoints in Thermostat Scheduler.

When using days/times based schedules in Thermostat Scheduler, it is possible to select different schedules based on days of the week. When setting these from Rule Machine the days selected in Rule Machine must exactly match the corresponding days selected for a schedule setting in Thermostat Scheduler. It is possible to change the time for any schedule period and/or the heat and cool setpoints.

Usage examples:

EcoMode is used to move the setpoints out when the system goes into Away mode. It may be desirable to do this in other modes or circumstances. Set EcoMode on/off allows this functionality.

The EcoMode offset can be changed. For instance, combined with setting EcoMode on as above, it may be desirable to have different EcoMode offsets for different modes or conditions.

It may be desirable to suspend Thermostat Scheduler by placing it into Hold. The heating and cooling setpoints of a thermostat are settable by other Rule Machine actions.

It may be desirable to vary the scheduled heat and cool setpoints or timing based on other factors besides daily or mode based schedule, for example based on outdoor temperature or season. Seasonal schedules can be established this way.

2 Likes

Excellent. Thanks Bruce.

Please don't hate me so soon after a new version release, but would it be possible to rename an instance of the app?

I think my best way of replacing what I currently do in RM might be to have an instance of Thermostat Scheduler set up for each of my current heating modes and then just choose which one is active by using RM to Hold/Schedule them appropriately.

I have just created another instance of the app but it is named the same as my original one, which obviously makes it difficult to identify which is which.

Can you see any other issues with running multiple instances of the app, providing only one is actually scheduled at a time?

I'm having trouble trying to figure out how to put 4 thermostats off/on hold without 4 rules. I don't use modes to control them I use time of day to set temp

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

  1. putting the thermostat in "mode=auto/fan=auto" first
    OR
  2. not sending any settings to TS or the thermostat -- the current schedule will take effect when hold is Off
    OR
  3. 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?