My biggest issue with controlling thermostats in Hubitat is how painfully hard it is. I have 11 thermostats in the house, which I set to different temperature in another platform (Hilo) based on scenes. For example:
My work scene => My office thermostat to 22, basement thermostat to 21, main floor thermostats to 18 (office is in the basement)
Partner's work scene => Partner's office thermostat to 23, room below it to 20
Meals scene => kitchen and living room thermostat to 23, etc
Night scene => all thermostats to 17
Away scene => all thermostats to 12
Peak hours scene => all thermostats to 17 (when the utility company asks us to reduce our usage during peaks)
Pre-heating scene (before peak hour) => all thermostats to 23
And then I can just schedule or activate scenes based on different criteria.
In order to do that with the thermostat scheduler, I have to create multiple schedules for each thermostat, with different temperatures for various schedules, and then if there's a "peak hour scene", I have to go and change that in the schedule. What a hassle!
Modes don't fix that, because it would need multiple modes to be active at the same time (i.e. Meals + My work, or My work + Partner's work)
Scenes could fix that, but they only control switches, no thermostats.
Why can't scenes control thermostats (or any device really) ? That would make controlling thermostats so much easier than the thermostat scheduler (which I'm not planning to use at all because of that). Unless thermostats and variables (I use a variable to control the set point of a thermostat) are added to scenes, I will need to write my own rules to do that based on virtual switches (that then act as what scenes should be)
Not sure what you mean by "scene", but you could certainly create a rule per scene that sets the thermostats when the scene is activated, or just add setting the thermostat to the same scheduling/activating methods that set the "scene".
Again, depending on what you mean by a "scene", this is readily doable, but there does have to be an action done in some app. It doesn't make sense to put thermostats (and any device really) into a lighting app, as that approach leads to all apps just turning into Rule Machine -- do anything to any device for any reason.
Thermostat Scheduler is only intended to provide the same basic scheduling of a thermostat that older programmable thermostats have, but many "smart" (i.e, Zigbee, Z=Wave) thermostats lack.
Here's one way to do it. You'd have a virtual dimmer device, which in my example is called Alpha. Alpha gets set in some scenes to the desired heating temperature.
Then there is a single rule that sets the heat for some of the scenes:
Notes: first thing is to take the level of dimmer Alpha and put it in a local variable (called Heat Level), second is to set the thermostat(s) setpoint using that Heat Level variable.
You'd have a similar rule of each collection of thermostats that are set, with two more such virtual dimmers for the case where there are three different levels being set.
That's nice that some other system does this in a way that you prefer. Hubitat can do it this way, using adjunct rules and means to pass values around. We are not planning to add features to Groups and Scenes nor to Room Lighting to do this. Based on your writeup above, you'd have 4 of these rules and three virtual devices. That's 10 minutes time investment to setup.
My write up above is only a portion of what I do with scenes that can include other devices.
Yes, I know there are many complicated ways to do it. I think Hubitat would benefit from being more user-friendly and make things like this simple to do without a bunch of convolution with virtual devices and variables, but I see we disagree.
The price of doing this in adding more complexity to the lighting apps, and that in turn results in a less user-friendly system for many users (speaking from experience). So there's a tradeoff, and not a single right answer. There's a long time saying about this: "your use case is not my use case", and it's just very difficult to cover every use case in just the way that is optimal for that particular user. You have a singular perspective, and that is certainly valid. Our approach is to offer a large variety of apps and to be responsive to the things users tell us as best we can. Features get added to apps all of the time. This request just doesn't get over the hurdle I'm afraid.
To do what I do with Hilo in 6 scenes (with 11 thermostats) in the way you suggest, I would need 11 virtual dimmers, 11 variables, 11 rules that link those, and then 6 switches or buttons to toggle the scenes, with 6 rules to describe how the scenes change the dimmers, and finally some scheduling that would press the 6 switches based on hours and days
(that being said, I'm not sure why I would involve virtual dimmers and variables rather than just hardcode the thermostat set points in the 6 rules)
I understand it does not fit in "Room lightings", but I don't understand how it doesn't fit in "Groups and scenes" (why is that considered a lighting app exclusively ?)... or just a copy of "Groups and scenes" that does thermostats instead of switches.
Ironically, I have one switch which acts as a thermostat (just without set point) that I can put in a scene.
@mboisson give the guys at hubitat a break. Appreciate we all have individual needs but sometimes we need to bend with the wind and be realistic. This is a £100 hub which doesn't have space x funding.
Each scene has its own activator virtual device, created by the Scene app. That device being turned on activates the scene. All you need is a Basic Rule triggered by the activator turning on, which then sets your thermostats for that scene.
Net outcome: no additional virtual devices, no additional events, just the additional actions that you seek. The only argument left is that you don't want an extra Basic Rule for each scene, while the argument against your suggested approach is extra app complexity for an edge case (most lighting scenes do not entail setting thermostats).
This is the intended and designed approach to dealing with these sort of automations.
I just spent 2-3 hours trying to set up these "scenes" with a bunch of rules and virtual switches, and I am only halfway done. Most of the time is spent designing rules for how to set thermostats and rules for when to activate a scene.
The approach I took is to:
create a virtual switch for each scene
for each scene, create a rule to say what happens when that switch is turned on
Regarding the suggestion to use scenes and their activator, how is creating a scene just to put all the rules outside of the scene accomplish better than creating a virtual switch to put all the rules in the rule engine ? That's just using an empty scene used as a virtual switch, isn't it ? Are scenes easier to schedule based on events than writing rules manually based on virtual switches ?
I would agree that most lightning scenes do not involve thermostats, but at least in my case no scene involve lighting. I have very little use for lightning scenes (and the little need I have is handled great with Room lightings, rather than groups and scenes).
Lighting is simple: on or of based on presence, it's instantaneous. Heating is complex: pre-heat, heat adjacent rooms, heat the whole floor in multiple rooms, and it is not instantaneous, you don't start heating when you get in the room, you do it before you get in the room, before you get up in the morning, etc. For that reason, my need for scenes is purely for thermostats, not for lighting.
But I guess I'm in the minority and home automation is about lighting rather than high energy utilities (heating/cooling)
Yeah, I don't know, writing a custom driver just to force thermostats to behave like dimmers and be accepted by Groups and scenes looks like even more of a chore than setting up 10-20 rules
There are always multiple ways to accomplish anything you want to do. I'm not advocating a particular approach, as I really don't have a complete picture of what you're doing with Scenes, or why.
Home Automation is not always simple, so solutions to solve particular automation cases may not be simple either. You just have to find what works for you. I offered the suggestion of using the scene activator as a trigger because you said you were using scenes, so I took that as a starting point. Scenes themselves came into existence to met a need to set multiple lights to different levels from a single activating event. Maybe that fits your case, or maybe it doesn't.
In general, automations start with some triggering event, be it pushing a button, tripping a motion sensor or contact sensor, or some time of day. From that, often some qualifying logic has to be considered. The built-in apps are building blocks that fit portions of an automation need, or perhaps an entire automation situation.
Yeah, it does exactly, if you replace "lights" with "thermostats" and "levels" with "set point". My need is to set multiple thermostats to different set points from a single activating event. That's precisely why I went to scenes to fit that need, except they don't.
I guess @ymerj's idea of making thermostats behave like dimmers (that's essentially what they are) would work too.
Now that I think of it, displaying thermostats as dimmers in dashboards is also something I would like (the slider is far more intuitive to me than the two arrows that disappear when it's not heating, I'm not even sure how to adjust the set point when the thermostat is off, since the arrows disappear). It just feels backward to undo a core device to replace it with a custom one, I don't like reinventing stuff. @ymerj, do you have a pointer to your solution ?
What's wrong with a straight forward rule? Whatever your activating event is just fires a rule that sets the thermostats. One rule for each unique combination/setting. What am I missing?
All a Scene is is a special subset of that approach, but for dimmers or bulbs. There's no magic here, they all do pretty much the same thing -- variations of the same thing.
I think I managed to do it with virtual switches and rules that sets thermostats when switches are turned on or off. I then automate switches with Room Lighting (which is a lot more convenient than writing complicated if/else rules myself). Not ideal, but it can work.
Heating in Québec (a cold climate) is generally achieve with electric baseboard and for most, thermostats here only offer a range of heat (there is not even an off setting). Hubitat thermostat driver (and dashboard tile) are design for far more complex system. From our point of view, Thermostat are in fact only dimmer but in other region it has to control more options. They maybe overkill in this particular situation and cause a bit of frustration.
