But it does set the controlled thermostat mode to off. Doesn't that stop the real thermostat?
BTW, I came up with something that works pretty well for controlling the app when its used with multiple instances:
The controlled thermostat will have a virtual switch as part of it, and an attribute "control", that can be set to 'free' or 'controlled' (commands of those names). The switch and that attribute are tied together, and both do the same thing. Turning the switch off puts the app into Free, while turning it on puts it into Controlled. Going from Free to Controlled, as now happens in the UI, will kick start the app to evaluate all of the sensors and setpoints as expected. The switch, the attribute, and the UI element are all tied together.
Also, all real thermostat modes will be supported.
I had the controlled thermostat already in "Free" mode as currently this isn't working for me with the multiple instances I need.
If I understand the current implementation correctly, the underlying restrictions are only evaluated when the thermostat switches between free and controlled. Allowing to programmatically to change that state will help, but shouldn't a change of an underlying restriction trigger an update of the thermostat controller regardless?
That's great! I am looking forward to that version.
OK, if it's in Free, then it won't touch the controlled thermostat with anything that happens. But, I will fix it so that changing mode to off puts it into idle. In fact, changing the mode will go to idle and then except for off, check temps and setpoints and go from there as appropriate to the mode, which logic includes starting heating or cooling if demanded.
No, restrictions are evaluated on every event driving the app, which are the temperature events. If it's restricted at that moment, it doesn't process the event, so nothing can happen as a result. This is true if the app is in Controlled mode. If it's in Free mode, it won't process those events whether restricted or not and won't bother checking the restriction.
You raised this question before about changes to restrictions causing something to happen. I haven't gotten around yet to looking at that, and it's quite a departure from the way restrictions work.
The controller thermostat also will support Refresh, which will cause it to look at temps/setpoints.
I've been musing about the idea that multiple instances is not really the best way to do what you'd use them for -- viz, changing what sensors are used for different periods of the day, or different modes, etc. While, with restrictions, it can be made to work, it falls into what I would consider a kludge.
That got me thinking about Thermostat Scheduler, and thinking that really what is needed is not multiple instances of the controller, but a way to tell one controller how to adjust for different parts of a day or modes. Thermostat Scheduler does that now, for ordinary setpoint control. Thermostat Controller raises the stakes by having the extra temperature sensors, with their weights, offsets, etc.
So, what if there were something like Thermostat Scheduler meets Thermostat Controller to allow defining these changes for day parts. ??
Any thoughts?
I agree, that this would be more inline with an advanced version of the Thermostat Scheduler rather than a controller.
For my use case having remote sensors that control a thermostat is essential. Being able to switch between them in a very flexible way is also important. Creating virtual thermostats (like the thermostat controller) is also important so they can easily be integrated into any UI (e.g. Google Home). From the front-end there shouldn't be any need to know what goes on behind the scene.
Ideally, changing the setpoint on one of the virtual thermostats should make it the "controller" of the physical thermostat - in addition to set that through some rules.
What are the parameters that drive the switching? Time of day, modes, ... ??
Currently I am using modes and a virtual switch. I have a virtual switch called "Working" that turns on/off when I enter/exit my office. Depending on the state of that switch the "Office Thermostat" or "Bedroom Thermostat" (Thermostat Controllers) is in control of the physical thermostat that's located in a hallway. When I am in "Night" mode the Bedroom Thermostat is always in control.
Hi @bravenel i've been playing with the thermostat controller.
can you add an option make the controlled thermostat go into "off" mode when the free/controlled switch is turned to "off"? i tested this a while ago and it didn't..it simply left everything running if it was running.
my use case is that i have a virtual switch called "wholeHouseACcontrolled", which is configured as the 'Restriction' switch on the Thermostat Controllers such that when on lets the virtual thermostats do their thing as necessary. then i can press a button on the dashboard when i'm out of the house to put all the A/C units back into 'manual' mode, with the actual A/C units off and ready for manual operation if required.
without this i have to have another RM4 app to first switch the thermostats to free, and then set the mode to off for each A/C unit. one of the benefits of this app is avoiding extra apps for controlling A/C units.
another feature to help with consolidating and simplifying A/C control would be a separate Door/Window switch for each thermostat controller, which in effect would work in tandem with the Free/Controlled switch to allow the A/C unit to be automatically controlled:
i.e.
IF ( Door_Window(closed) AND Free_Controlled (on) )
{ doYourThermostatThing }
ELSE IF ( Door_Window(open) AND Free_Controlled (on) )
{ switchOffControlledUnitsButStayControlled }
ELSE { switchOffControlledUnitsandStayinFreeModeUntilToldOtherwise }
or something along those lines anyway 
thanks for the good work..
As an option you would have to select, yes.
It's interesting the wide variety of uses for this app, and the subtle nuances of control needed.
Is this right: If this switch is turned off, turn off the controlled thermostat(s) (remain Controlled)?? What should happen if it's turned back on? If the answer is turn the controlled unit back on, how is that any different than just doing that outside of Thermostat Controller, simply a virtual switch or even RM variable that simply turns the units on or off? I realize that by adding it to TC that it would save having a rule to do it, but that is a weak reason to add such a feature.
Great, thanks for the prompt response, Bruce.
regarding your last point, a lot of thermostats have door/window contacts/relays/inputs, so virtual ones should too.
yes of course I could (and currently do) do it with RM.
to answer your question, if the door/window contact is "turned back on", the controlled devices simply resumes doing what its' told by Thermostat controller (i.e. if Thermostat Controller at that time would be setting the controlled device to cooling, then the A/C unit is switched back on).
In effect both inputs have the same effect on the control algorithm, but are used for different reasons (one is 'temporary' if a door is opened, the other is more of an on/off switch for automatic control). The way i normally configure the door/window switch in my RM controller is to provide a configurable wait/delay function on the door/window switch, to ensure it is on/open for a minimum period (i usually use 3 minutes) before turning off the AC. we don't want the AC cycling off/on just because someone walked through a door. but if they forget to close it, then we want the A/C off... and to release the hounds.
before thermostat controller, i had about 4 or 5 rule machine instances controlling various elements for each A/C unit. PITA to make changes, config & CPU intensive, but it worked.
one of the key value points of thermostat controller from my perspective is that it replaces the lot of them...almost. so my suggestions were about adding the missing pieces so that all I needed for control was the last one, and then i can remove all my other RM pieces and then Thermostat Controller is the one App to Rule Them All 
hi @bravenel, i just installed 2.2.6, i was hoping the features we discussed would make it in there. did you decide not to do them, are they pending development, or do i need to remove and re-add the thermostat controller instance to enable new app features?
No, these points were not implemented. Still completely unsure what do about them.
why is that? particularly the first feature which you didn't flag any issues with:
As an option you would have to select, yes.
Sorry, I didn't get to looking at this yet. And,I'm not sure these should be options in the app. I just haven't had time to focus on this recently.
fair enough, with 2.2.6 release today it must have been all hands on deck.
my perspective is that with the current 'restrictions' section available, its nearly there and i'm just requesting those restriction modifiers to be added to to enhance the existing options.
e.g. adding the option to revert the controlled thermostat to OperatingMode=off when restrictions are enabled makes a significant difference, as my use case is to stop the A/C unit operating during restricted periods, either due to door/windows left open or because i need to have the whole house hvac automation disabled for other reasons.
multiple RM workarounds to achieve this is config & CPU intensive, nowhere as elegant or easy to configure compared to having it integrated into existing restriction parameters.
OK. This did get done for Thermostat Scheduler, and that feature can be lifted into Thermostat Controller. I'll get to that this week so that it gets into a hot fix release.
1 Like
champion!!!! 
I would like that alot!
The option to select which temp sensors are used during each period would be fantastic also!
My use case is that during the night, I use only 2 sensors (averaged), then during the morning I use 3 other sensors, then during the day I use all 4 sensors.
Sort of a poor man's zoning......
I am trying to figure out the different controls with thermostat controller and scheduler, and what they do since there is no documentation about these apps, at least I couldn't find any...
I am using a T6 as my stat. Got away from ecobee because of the lousy cloud connectivity issues.
I am using your (Bravenel) sensor averaging app for the temps, but controller has that built in also. Only advantage to using the sensor averaging app is that I can add weight to each sensor and calibrate each one.
Just trying to make sense of the apps...
