architecture
architecture copied to clipboard
home-assistant
Climate scheduler
Triggered from: home-assistant/home-assistant/pull/21017
It would be useful to add a scheduler to the climate component, specially for the generic_thermostat platform. You can actually do this by using automations in HA, but this way the ui would be more user-friendly.
It should enable the user to set rules triggering temperature changes at certain hours and days of the week. It could also be useful to add a sort of timer to manual temperature changes (making them last 1h for example), but that should be optional and enabled in the component configuration.
This could be done as a standalone componenent (see PR at the beggining) or integrate the functionality into the climate component. The standalone component approach would make sharing a single schedule between different climate entities easier.
I would like to see a "smart" scheduler be implemented in future, something can compete with Nest's "learning thermostat". That scheduler should consider the weather forecast, the current temperature, and user usage pattern, etc.
If you want to implement a "time" scheduler component with a user friendly UI, I would suggest we implement a generalized scheduler component, not only for climate, but can call any service at a given time.
The generalized scheduler component sounds good. However, how can we make it work with the different components? Multiple platforms for a schedule component? It is way different to call 'switch.turn_on' than 'climate.set_temperature'. The differences would also affect the UI.
If you think this is the way to go, I can try to refactor the existing code and turn it to a generic platform (and I think a new PR would be needed, am I correct?).
I also like the idea of the 'smart' scheduler, but It may be something more for the long term, and maybe it could be extended to other components as well. Fore the climate component, I have been thinking of applying some machine learning to the turn-on times of the 'generic_thermostat', as it overshoots the set temperature (When it turns off, the radiators are still hot, warming the house a little bit more). However, I don't have enough data collected yet to try anything.
I've been thinking of another approach:
Instead of showing a component with a card, a new panel could be added, which would allow to have a single 'schedule' component with more complex UI options that unifies events for multiple platforms.
For example, you should be able to select a time and day/days/workday/holiday and then a event to fire. Simple events like turning on/off a light or changing a climate's temperature should have a predefined UI, and perhaps an editor for custom events.
The problem with this approach is that it would be like reinventing automations...
Hi,
As the author of Schedy, I just want to add my two cents here.
While it's certainly easy to design an UI for a simple scheduler with time slots for different workdays, maybe even weeks, months etc. I can't imagine a way to account for external conditions such as weather sensors, presence and that sort of things without creating if ... then... rules, which we already have with automations, although they become very complicated to maintain when used for scheduling.
What has to be considered as well is what happens when HA wasn't running at the time the scheduled value switched, there has then to be a mechanism to find out what to set at startup, so whatever the scheduling algorithm looks like, it has to be able to find a suitable value at every time.
I once also thought about integrating Schedy as a component into HA directly, but had no time to dive into it, hence it still requires AppDaemon. Since the rules concept is quite powerful, maybe that would also be an option?
Best regards Robert
Thanks Robert!
I think that the easiest thing to do would be to integrate into HA just the time-based rule functionality of Schedy. If someone wants to write more complex rules, Schedy or automations can be used.
Yeah, at least that's the part which it should be relatively straightforward to create an UI for.
However, automations aren't suited well for scheduling IMHO. When you just want to execute service X at time Y, that's straightforward. But I think it'd be more appropriate to have a mapping between - let's say - a time slot and the state of an arbitrary entity to be maintained during that time slot. How to bring the entity to that state then differs from entity type to type.
At least that's the concept used in Schedy. You have actors (entities) of a specific type (thermostat, switch, fan or any other customizable type) and a schedule that maps time slots (and, if you go the advanced route via expressions, also arbitrary state conditions) to states of the specific actor type. It can then easily ensure all actors are in the state dictated by the schedule while still allowing for manual adjustments and, if desired, revert these adjustments after a given time.
All in all, the code isn't that small (~4000 lines) and, at the moment, tightly coupled with the AppDaemon API. I also wished to move away from using AppDaemon for it, but simply don't have the time to work on it.
Just an idea for the simple time-based scheduling... Can't this be acomplished with a calendar + an automation that triggers when an event in the calendar starts? Maybe even the temperature/value/whatever could be supplied with the event.
That way no new interface for creating the schedules has to be written, since there are plenty of good UIs for managing calendars out there.
EDIT: Even restoring state at startup would be possible with an additional automation trigger.
Hi, I have implemented heating timers using an automation and some input selects and scripts to set the profile. Have been using them for 18 months now and they are very stable. I am also pretty happy with how it looks in the UI too.... I can share the code if you are interested.
I have pasted the automations, input selects and input booleans below. You will just need to create a clock.yaml file which is a list of available times (i have every 15 mins from 05:00 - 22:00) and a profiles.yaml which is a list of available profiles. You then need to create a script with a name that matches each profile. For example, script.heating_off that turns off the heating. script.heating_medium which sets the heating to a medium setting etc. I have per room control on my set up so have about 6 profiles for heating different parts of the house.
You can then copy and paste these automations, increasing the number by 1, and create any number of timers, I have 9 currently.
########## Heating rules ##########
automation:
- alias: Heat Profile 1
initial_state: 'on'
trigger:
- platform: template
value_template: '{%if states.input_select.heating_timer_1_time.state == states.sensor.time.state %} true {% endif %}'
condition:
- condition: state
entity_id: input_boolean.heating_timer_1_switch
state: 'on'
- condition: state
entity_id: input_boolean.summer_mode
state: 'off'
- condition: or
conditions:
- condition: state
entity_id: input_boolean.heating_holiday_mode
state: 'off'
- condition: state
entity_id: input_select.heating_timer_1_profile
state: 'Off'
- condition: or
conditions:
- condition: template
value_template: '{{ is_state("input_boolean.heating_timer_1_weekday", "on") and is_state("binary_sensor.workday_sensor", "on") }}'
- condition: template
value_template: '{{ is_state("input_boolean.heating_timer_1_weekend", "on") and is_state("binary_sensor.workday_sensor", "off") }}'
action:
- service: script.turn_on
data_template:
entity_id: script.heating_{{ states.input_select.heating_timer_1_profile.state }}
input_boolean:
heating_timer_1_switch:
name: Active
icon: mdi:gesture-double-tap
heating_timer_1_weekday:
name: Weekdays
icon: mdi:calendar-check
heating_timer_1_weekday:
name: Weekdays
icon: mdi:calendar-check
########## Overrides ########
summer_mode:
name: "Summer Mode"
icon: mdi:weather-sunny
heating_holiday_mode:
name: "Heating Holiday Mode"
icon: mdi:beach
input_select:
heating_timer_1_time:
name: Time
icon: mdi:clock
options: !include clock.yaml
heating_timer_1_profile:
name: Heat Profile
icon: mdi:thermometer-lines
options: !include profiles.yaml
heating_timer_1_profile:
name: Heat Profile
icon: mdi:thermometer-lines
options: !include profiles.yaml
sensor:
- platform: time_date
display_options:
- 'time'
- 'date'
I'd like to see this as a scheduler, instead of using automations. Please can it also consider #20154 though. With the current setup, using automations overrides any temperature set by enabling away_mode.
A real scheduler would be the right way of solving those sorts of tasks. But again, it shouldn't be specific to the climate component IMHO.
What about the idea of using a calendar and just fetch the temperature to set from it? Reacting to away mode etc. would then be not difficult with just a few plain automations.
Automations shouldn't have to know about away_mode, etc, for setting temperatures. The end climate component should be able to handle that.
I'm currently working on a generic schedule component, I'll try to make a pull request next week.
It's questionable whether away mode should be implemented in the climate component directly at all, since whether I'm away is something that could affect other domains as well, such as lights etc.
@alex-torregrosa I'm very interested in what you're developing. Maybe you could link the PR to this issue to have us notified?
I think there should be scheduler class and it should be base class for other schedulers.
Then we should create generic_climate_scheduler which is managed by HA schedule and then we will be able to implement scheduler for different platform.
Right now I'm writing bosch thermostat component and those devices has "built-in" week calendar with schedule to turn on comfort/eco program (for both climate and water_heater) I think it would be better if in such situation HA would be only kind of frontend for "calendar" and for climate components without such function we can use generic_scheduler.
A thermostat should have it's own scheduler, sure you can use automations to connect the scheduler to the thermostat, but that is just an extra burden for the end user.
isn't gonna be worse if user create some schedule in thermostat mobile app and then try to schedule something different in HA scheduler and be surprised that it's going crazy?
Syncing schedules between platforms sounds like a huge effort to implement properly with not much benefit. Each manufacturer allows a different number of setpoints per day, different time resolution, single/multi-week schedules, to name just three of the problems this will cause.
Why not just have a central schedule to maintain in HA (or a calendar, for instance)?
Another problem is how to deal with manual overrides, e.g. when a window is opened or if I want to overwrite the scheduled value for an hour or two.
@efficiosoft I think that depends on the platform. But I see various smart thermostats exposing their schedule and HA platforms being able to incorporate that.
Some others might just dumb down their thermostats due to lack of support.
@efficiosoft I can see benefits for both approaches, but some thermostats has to have schedule set up if using auto mode. So in case we don't sync scheduler from manufacter we can't really control it (we have to ask user to use manual mode)
@pszafer That has only usability impacts, right? So the user won't see whether schedule is active or not on the thermostat display?
Personally, I'd prefer to have HA control the thermostats, because it can make more sophisticated decisions than a thermostat can (time of day/day of week).
A thermostat should have it's own scheduler, sure you can use automations to connect the scheduler to the thermostat, but that is just an extra burden for the end user.
It's worth remembering that this issue was raised "specially for the generic_thermostat platform". Whatever is designed needs to support that, which has no scheduling or other capabilities beyond determining temperature and state.
If a thermostat has its scheduler, it makes sense to me to use that instead, although I can see the benefit of being able to view/edit it from within HA. But a generic scheduler in HA could be tied into a thermostat and be used instead, assuming the thermostat's scheduler (if it exists) can be disabled.
@efficiosoft Buderus setup is quite complex (I know 2 houses with similar setup). I'm not an expert but as far as I understand buderus (IP gateway is manufactured by bosch) thermostat schedule has to be configured. In set up where there is heat pump which is used for heating (climate device) and for water (water_heater). This thermostat can have solar panel as another heating device as well. I think it is easier to create frontend and backend of manufacturer scheduler which is send to thermostat than try to implement such inteligence which knows that it controls heating device which sends water to climate and water heater.
@b4dpxl I think this is best aproach, if device has scheduler capability implement it to HA, if not use generic scheduler.
I think you all may be over thinking this. The scheduler should be platform agnostic. All it needs to do is set thermostat parameters at a predetermined point in time. This should be independent of any platform (nest etc.) configured schedule. The user can then choose wether to use the platform and/or home assistant for scheduling
Interesting how this issue pops up every time again. You want something with less options than full fledged automation, but dynamic enough so you can change the timing easily and manually.
Definitely think this should be platform agnostic.
I imagined it as something with the following UI: a table of entries with a + sign to add more entries. Each entry has a start time, end time (optional), service call, boolean whether it's on, input select for recurring and - sign for deletion.
@tsvi +1 for the table approach.
However, entering a service call in every table row would add quite some overhead I think. Maybe it should be a two-step process.
- Create some named service call templates with
serviceanddata, maybe evendata_templateto dynamically insert the entity id - Select one of these templates in each of the table rows.
I think that a generic scheduler should work with scenes. Users can configure a scene for "active" and for "not active", or any other state that a scheduler would support.
It would be a bit more helpful if we extend our scene support to allow users to create them on the fly, including better restore support. But that's getting off topic.
