I'm a developer myself and it didn't think it would add any more complexity as it was to add the "Off" mode. IMOHO the controller should expand on the underlying device - not curtail it.
I do think I found another 2 bugs though:
I have 2 controllers that control a single thermostat. One controller is active when the mode is "Home" and the other one when "Night". Changing the mode doesn't seem to trigger the sync from the now active thermostat.
I gave those 2 controllers 2 different names, but in the "Apps" list those names aren't reflected.
One more reason to have heat/cool: When setting the temperature through the Google Assistant (e.g. "Set thermostat to x degrees", Google sets heating and cooling setpoints for thermostats in "auto" mode based on the current spread and the temperature asked for. So the "high setpoint" for cooling could change resulting in unexpected results (e.g. the aircon cooling your house in the winter).
Are you talking about a Restriction? So removing a Restriction doesn't do anything? That wasn't really their intent, as they are intrinsically passive. I'll have to think about this one. I understand that you want a particular controller thermostat to "kick in". Right?
This is a bug. Will get it fixed.
I'll look at the heat/cool mode stuff. I hate it when Google calls the shots!!
Yes, each controller has a restriction to only control the thermostat when a specific "mode" is active. Just curious: What would happen if you have 2 controllers (linked to 2 different temperature sensors) control the same thermostat (neither one having any restrictions).
That is correct. As in my use case, at night, the temperature sensor in the bedroom "controls" the thermostat. During the day, the temperature sensor in the office does. I would have thought that the change in one of the restrictions would "refresh" the controlled thermostat.
I was thinking I could just change the "Free/Controlled" switch in my own rules to facilitate which controller is active, but I wasn't able to find any way to do this in the rules. Am I missing something or is this just not possible?
Nothing to support that has been implemented, yet. I'm going to look into all of this for the next release. One possibility I will look at is making the restrictions more than passive, that is subscribing to the events that cause their state to change. Controlling the app externally is another possibility. Perhaps the app could create a virtual switch child device that mirrors Free/Control. Another possibility is to allow the logic to be forced to look at sensors, most likely with a refresh command on the controller thermostat.
I found another bug in the Thermostat Controller:
Changing ThermostatMode to off while the therrmostatOperatingState is in heating (or cooling) doesn't set the therrmostatOperatingState to idle.
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.
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. ??
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.
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..
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.
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?
