Feature Request | Thermostat Controller + Scheduler

@bravenel thanks for taking time to develop this cool app combo for us.
Recently I ditched my two Ecobee's tstat, I decided that I would like to go less cloud dependant as it makes me uncomfortable the huge amount of telemetry being gathered on my behalf, also the polling of the apps would peg my usage stats on the particular apps.

Now I bought two HoneyWell T6 Pro and using the outstanding drivers by @bcopeland, thanks Bryan.

After giving a spin to your apps, found myself contrived in my decision as I was hoping to be able to perform similar automations as my former tstat.
Feel that Thermostat Controller and Scheduler are getting there were it needs to be, but is missing some basic automation available on almost any "smart" thermostat on the market.

I was hoping to give my humble opinion and maybe give some ideas.

-My number one omission to the current apps is regarding the the remote temperature and humidity sensors. Because I knew I was going to migrate from Ecobee, I went to lengths to make sure I would place temp/humid sensors on the same spots as I had with Ecobee.
The way the remote sensors were used is by modes (I know there is modes option on Controller, bear with me) , much like hubitat does location modes. But not only modes is necessary, but partitioning of the remote temp/humid sensors by mode. In other words, each mode will have a specific set of temp/humid sensors assigned to that particular mode. For example, during night I would like to average only my master bedroom and omit the rest, but then during the morning, another thermostat mode kicks in and a different set of remote temp/humid sensor will be used for averaging.

-This second point is easily doable by other means like RM, but regardless it would be nice.
One of the signature features of "smart" tstat is the ability to automatically go into ecomode or away mode whenever a threshold of time had gone by without tripping a PIR motion sensor or any other presence sensors like a door contact. This feature would mimic a very similar behavior from current WIFI enabled tstat and would turn the "dumb" tstat on a real "smart" tstat.

My two cents.

You can have multiple schedulers. You should be able to force Eco Mode anytime you want by activating Away mode to put Thermostat scheduler into Eco Mode. Time restrictions can be used to limit other schedulers too.

You can use restrictions for thermostat controller. Setup one with the sensors you want to use during a specific time period and then set the restrictions so it's only active during the desired period. Create another thermostat controller child instance for the time period you want the other sensors to also be used for averaging, and set its restrictions to not include the period of the other controller child instance.

Thanks @SmartHomePrimer, that is a great workaround. But think about it. You would then have multiple controllers floating around, at that point which controller I should share/present in my dashboard, homebridge or alexa. Then I would have to deal with the wife and kids :wink: . It would definitely work, but defeats the purpose of what Thermostat Controller should be by nature or what it should be, that is a virtualization abstraction of the real thermostat.

That sparks another idea, the inclusion of a new RM ability to allow add/remove remote temperature sensors and reconfigure the Thermostat Controller on the fly.

Why would you put an automated controller in Dashboard? You share only what’s needed for manual override. Or better yet, set the thermostat to function in the range that your wife likes and accept that unless you are a bachelor, you have no actual power over the thermostat setting! :stuck_out_tongue_winking_eye:

This is why I still use an Ecobee and don’t try to fight it or integrate it with my hub at all. Even a manual override can go longer than you want. No system in the world is able to keep up with our ever changing moods. :wink:

Thank you for sharing your insight.

Automated controller or not, its impossible to foresee every iteration in the future. Is my personal preference that for every automation there must be a physical or alternative override, that is true throughout all my implementations. For example, I don't want my alarm panel to be controlled by just an automation, I want to be able to go to the alarm keypad and enter my code and that will in turn disable HSM and vice versa, if not would be a mediocre half baked integration that only us nerds would be able to figure out. I don't live alone, I have 2 kids and 2 adults living with me and none of them are technology literate. In other words, if a 5 year old can't figure it out by himself then is not a human friendly solution. Automations are made to simplify everyday nuances and facilitate the environment we live in, not the other way around. If its too complex for a normal person (not a nerd) to be able to manage it, we might as well be better without it.

But this is besides the point that I am trying to drive with this post.
My feature request is a "request", it is because a simple solution does not exist.
I am perfectly aware and capable of coming up with a convoluted and overly complex solution, but that is not my intention with the post, my north is more to contribute ideas for the betterment of Hubitat. Ponder this, Hubitat is it is today is the most consumer friendly local automation HUB in the planet right now (for normal non geek persons). And we have been the early adopters, as such is in my interest as a customer to keep the platform relevant. A vast majority of consumer that goes into automation, probably one of the very first items that will be acquired is a thermostat. Then it would be in best interest of Hubitat to cement themselves in that automation part of the market and be the differentiator.

And there you go, an elegant, yet stupidly and unnecessarily complicated setup that doesn't use a thousand Thermostat Controllers to accomplish what a "smart" thermostat should be.

Created a placeholder virtual temperature sensor:
image

Then used the outstanding AveragingPlus by our one and only @bptworld in conjuction with his flawless driver implementation for the t6 Pro:
image

Created a child averaging automation with my required remote temperature sensors per mode:

Used RM to dynamically adjust the targeted averages profiles and pass on the value to the sensor place holder while selecting correct averaging profile depending on the mode:

Set up the vThermostat controller with the virtual temperature placeholder:

Then setup the Scheduler to manually control my tstat by modes:

And to scale out with other profiles, rinse and repeat.

See @SmartHomePrimer, that wasn't that bad.
Now I can tamper down my tantrums and ever changing mood swings :wink:
This system in my world is able to cope with all the manual changes I want and works as a truly smart tstat. I didn't even had the need for a janky, convoluted setup as you suggested.

BTW @bptworld beer is on me this weekend:
image

2 Likes

Glad you found a solution that works for you

Thank you, always appreciated!