Template to script or automation help/ heating schedule

Configuration
7

Yes i understand what you mean regarding the calender events although i could not get any documentation on the calender trigger, would the times be changeable on the fly i.e from lovelace.

The reason the automation is ran every 1 minute is to allow for a scenraio were the automation could not run at the start time or at the off time or if home assistant was not running or i have been making changes at the time. It also gives us the ability to stop it easily by switching a toggle or changing the times so it has immediate effect.

8

There are better ways to do that than with a Time Pattern Trigger. All of my scheduled automations are designed to survive restarts and outages without using a Time Pattern Trigger.

Not a direct benefit of a Time Pattern Trigger.

As mentioned, a Time Pattern Trigger is often misused; the vast majority of examples employing it are often inappropriate. It has a very limited range of justifiable applications.

If you are interested, here’s a brief tutorial on the subject of composing a “resilient” automation:

9

Not sure when you checked but 2022.5 literally just came out and so now the doc for it is visible. The doc on the calendar trigger can now be found here

Yes. I mean not necessarily from lovelace but no restart required. Like what I would do here is this:

  1. Make a calendar in google called hvac schedule
  2. Set up google calendar if you haven’t already
  3. Tell HA to track “hvac schedule”
  4. Use the new calendar trigger in your automation to turn the hvac on when any event starts on the hvac calendar and turn the hvac off when any event ends on the hvac calendar
  5. Make events in that calendar according to your hvac schedule. Like “HVAC on” with start time set to day and time it should turn on and end set to when hvac should turn off. Make the event repeat indefinitely. Keep adding events this way until your entire weekly schedule is in this calendar.

You can modify this calendar at any time in google this way. You can also add new events to it from HA if you want by using google.add_event service although you can only modify or delete existing events from the google calendar UI.

You can also do this with any other calendar HA integrates with, google is just the only one OOTB. But if you use HACS there are other options, like this one for Office 365.

10

FWIW, the one philosophical problem I have with using Google Calendar (or any cloud-based calendar) is that it makes something as fundamental as scheduling dependent on the cloud. Effectively, it makes a cornerstone of “local control” Home Assistant into “cloud-dependent” SmartThings.

I recognize its value but for basic scheduled tasks, my preference is to keep it local; to each their own.

2 Likes
11

I appreciate the advise, i agree and have thought about running them on start up as i do this for quite alot of other things.
The benefits i see with time pattern is it can read updated input timedate data should anyone in the house want to switch that rooms heating off or modify how long it will be on for.

In my example how could i incorporate the template into the script where it loops through the 10 input times.

12

Yea I know, its not ideal. There was discussion about a local calendar at one point. Like an option to simply make and manage calendars that are stored only in HA. I think this new trigger might bring that discussion back to prominence. I’m going to go see if there’s a feature request for it.

EDIT: Couldn’t find one so I made one

1 Like
13

I could spend time re-engineering your automation but the disincentive is that, despite everyone’s advice, you still believe the Time Pattern Trigger has benefits for this application.

14

Thank you, again it probably comes down to personal preference the calender schedule does look though.

This was one my first goes at creating automations for our heating schedule although far from perfect it nearly is for us as the rest of the family understand it and a big part to that is the layout we have on lovelace its very easy to make adjustments and see when the schedule is active.

I understand it uses alot of helpers/variables but for me that was really easy to add hundreds in notepad.

15

I recall experimenting with the Caldav integration and a local instance of Radicale but the clumsy part was adding calendar events. It worked but I lost interest in it.

Upvoted your FR.

16

I would not expect that at all, i appreciate all the help you have given but i do not expect you to re-engineer it for me.
I do not see a big problem with it, it works as intended and yes it runs 1440 times a day but it does not affect the system and i could easily change that to run every 5 or 10 minutes.

If this solution you added above allowed for modifications in between the times i would totally agree with you it would be the way to go along with runs the automation on startup.

trigger:
  - platform: time
    at:
    - input_datetime.onwkday1
    - input_datetime.onwkday2
    - input_datetime.onwkday3
    - input_datetime.offwkday1
    - input_datetime.offwkday2
    - input_datetime.offwkday3
    - input_datetime.onwkend1
    - input_datetime.onwkend2
    - input_datetime.onwkend3
    - input_datetime.offwkend1
    - input_datetime.offwkend2
    - input_datetime.offwkend3
  - platform: state
    entity_id: input_boolean.en_trv_masterbedroom

Another way i could have asked this question was adding a for loop into an automation/script template and using the result as a condition.

17

Can you elaborate on what you mean by “modifications in between the times”? What is being modified in between the scheduled times?

18

If anyone changes an input_datetime variable it will currently take effect within 1 minute or whatever we set the time pattern at.

I have maybe over assumed here, but the solution were only triggering the automattion at the input_datetime values would not allow for this.

19

Add a state change trigger then

trigger:
  - platform: time
    at:
    - input_datetime.onwkday1
    - input_datetime.onwkday2
    - input_datetime.onwkday3
    - input_datetime.offwkday1
    - input_datetime.offwkday2
    - input_datetime.offwkday3
    - input_datetime.onwkend1
    - input_datetime.onwkend2
    - input_datetime.onwkend3
    - input_datetime.offwkend1
    - input_datetime.offwkend2
    - input_datetime.offwkend3
  - platform: state
    entity_id:
    - input_datetime.onwkday1
    - input_datetime.onwkday2
    - input_datetime.onwkday3
    - input_datetime.offwkday1
    - input_datetime.offwkday2
    - input_datetime.offwkday3
    - input_datetime.onwkend1
    - input_datetime.onwkend2
    - input_datetime.onwkend3
    - input_datetime.offwkend1
    - input_datetime.offwkend2
    - input_datetime.offwkend3
    to:

Now when any of the helpers change it immediately reruns the automation and sets it according to the new schedule. Instant response for updates, don’t even have to wait for the minute to be up.

20

Yea thats a very simple solution to the time pattern i never thought of… Thank you.

1 Like
21

The Time Trigger will trigger at whatever time specified by the Input Datetime even if you change its value (EDIT: However, a State Trigger is also needed to detect backdated times.) There’s simply no justification for employing a Time Pattern Trigger for your intended application.

Unnecessary; the Time Trigger takes into consideration any changes made to the Input Datetime’s value. EDIT Yes, it is needed to detect backdated times.

22

Well it matters if the time is in the past.

Like let’s say input_datetime.onwkday1 was set to 11:00:00 and the time is currently 10:30:00. And you realized you’re cold because its winter now and mornings are colder so you want to move the time up to 10:00:00. Well now you have an issue because that time is in the past. You missed that time trigger and now it won’t trigger at 11:00:00 anymore. Everything will be fine tomorrow but what about today?

That’s where the state trigger comes in. It fires because you changed one of the helpers and re-evaluates the schedule. This causes it to recognize that the hvac should be on right now and self-correct.

1 Like
23

You’re absolutely correct; I had overlooked to consider the need to backdate the scheduled time; a Time Trigger certainly won’t trigger if its time is set to the past. Your suggestion to employ a State Trigger is definitely needed to detect the change in the input_datetime’s value. Then the Time Conditions in the choose come into play to determine which action to perform (if any).

I’ll amend my previous post.

24

So I have changed the triggers to time at and state changes of the input times and is all working as expected without the time pattern… so thanks for this improvement.

I will now work on for loop logic to reduce the code size I will post when I get something up and running.

25

Two things that might be helpful:

  1. Splitting the time triggers into ‘on’ and ‘off’ groupings so you can leverage the trigger id in your Choose action
  2. Declaring trigger-based variables to derive the necessary time and weekday/weekend conditions.

The following only addresses actions based on the time triggers…

trigger:
  - platform: time
    id: on
    at:
    - input_datetime.onwkday1
    - input_datetime.onwkday2
    - input_datetime.onwkday3
    - input_datetime.onwkend1
    - input_datetime.onwkend2
    - input_datetime.onwkend3
  - platform: time
    id: off
    at:
    - input_datetime.offwkday1
    - input_datetime.offwkday2
    - input_datetime.offwkday3
    - input_datetime.offwkend1
    - input_datetime.offwkend2
    - input_datetime.offwkend3
  - platform: state
    entity_id:
    - input_datetime.onwkday1
    - input_datetime.onwkday2
    - input_datetime.onwkday3
    - input_datetime.offwkday1
    - input_datetime.offwkday2
    - input_datetime.offwkday3
    - input_datetime.onwkend1
    - input_datetime.onwkend2
    - input_datetime.onwkend3
    - input_datetime.offwkend1
    - input_datetime.offwkend2
    - input_datetime.offwkend3
    to:
  - platform: state
    entity_id: input_boolean.en_trv_masterbedroom
condition:
  - condition: state
    entity_id: input_boolean.boost_masterbedroom
    state: 'off'
    for:
      hours: 0
      minutes: 0
      seconds: 10
  - condition: state
    entity_id: input_boolean.en_trv_masterbedroom
    state: 'on'
action:
  - variables:
      dow_type: "{{ trigger.entity_id[-6:-1] }}"
      dow_match: "{{ (dow_type == 'wkend' and now().isoweekday() >= 6) or (dow_type == 'wkday' and now().isoweekday() <= 5 ) }}"
      time_index:  "{{ trigger.entity_id[-1:] }}"
  - choose:
    - conditions:
        - condition: trigger
          id: on
        - '{{ dow_match }}'
        - condition: time
          before: input_datetime.off{{dow_type}}{{time_index}}
      sequence:
        - service: climate.set_temperature
          data:
            hvac_mode: auto
            temperature: '{{ states(''input_number.ontemp''~time_index) }}'
          target:
            entity_id: climate.trv_masterbedroom
    - conditions:
        - condition: trigger
          id: off
        - '{{ dow_match }}'
      sequence:
        - service: climate.set_temperature
          data:
            hvac_mode: off
          target:
            entity_id: climate.trv_masterbedroom
26

Hey that’s nice solution, short and easy to understand.

The only issue when compiling is the time variable

- condition: time
            before: input_datetime.off{{dow_type}}{{time_index}}