Daily Thermostat Schedule

while scanning a simple key in “”, line 127, column 1: ^ could not find expected ‘:’ in “”, line 128, column 1:

To configure actions manually … ^

1 Like

Not sure I follow the comment here… Is something broken when using this blueprint?

Would it be difficult to add support for multiples times of day? Say different temp ranges for morning vs evening?

1 Like

I currently do this with another automation using the same blueprint… e.g. “Weekday - Morning” runs at 6:00a to set the daytime temperature and “Weekday - Evening” runs at 6:00p to set the nighttime temperature.

Would this accomplish what you are looking for?

If not, let me know your use case and I’d be glad to see if I can adjust this easily.

I guess that would do it, yes. I see that’s already implied in your automation example with the " - Evening" part of the automation name

Becomes a question of number of automations vs a more complicated single automation. Hard to decide where the line is sometimes.

I was just playing with a similar automation today and used trigger ids which successfully accomplishes this in a single automation, but I don’t have the day of week feature incorporated (I WFH and our HVAC schedule is the same 7 days a week) not sure if that would complicate the condition logic. Too tired to think through the flow in my head :confused:

I’m also only setting the low end temp right now and I use input helpers so I can present adjustment options in the front end for my wife as she’s only a standard user and can’t edit Automations directly, not that I’d want here too anyway… too confusing for an end user :smiley:

alias: 'Climate: Thermostat Schedule'
description: ''
trigger:
  - platform: time
    at: input_datetime.hvac_schedule_morning_time
    id: morning
  - platform: time
    at: input_datetime.hvac_schedule_evening_time
    id: evening
condition: []
action:
  - choose:
      - conditions:
          - condition: trigger
            id: morning
        sequence:
          - service: climate.set_temperature
            target:
              entity_id: climate.sensi_thermostat_homekit
            data:
              target_temp_high: 22
              hvac_mode: heat_cool
              target_temp_low: '{{ states(''input_number.hvac_schedule_morning_low'') | int }}'
      - conditions:
          - condition: trigger
            id: evening
        sequence:
          - service: climate.set_temperature
            target:
              entity_id: climate.sensi_thermostat_homekit
            data:
              target_temp_high: 22
              hvac_mode: heat_cool
              target_temp_low: '{{ states(''input_number.hvac_schedule_evening_low'') | int }}'
    default: []
mode: single

I see what you are getting at… Adding multiple trigger times to the blueprint would be pretty straightforward. It would simply require adding the desired number of triggers as time elements.

e.g.

trigger:
  - platform: time
    at: !input 'at_time_am'

  - platform: time
    at: !input 'at_time_pm'

(of course you would need to add these as inputs to the blueprint).

Alternatively, you could use a Date / Time helper as the trigger input rather than blueprint variables:

  - trigger:
      - platform: time
        at: input_datetime.hvac_morning
      - platform: time
        at: input_datetime.hvac_evening

This appears to work well for my needs however I am hitting an issue where when I try to disable any day of the week one of two issues occur.

1.) The save button doesn’t always pop up
2.) When I am able to save it doesn’t seem to keep the day disabled when going back in to the automation. This may be why 1 occurs.

Any ideas on this? I’m not seeing anything inherently wrong but I’m not very familiar with Home Assistant scripting.

Thanks!

Edit: After some further testing I found that toggling off a day in the UI causes the value to be set to ‘true’ in the YAML itself. Modifying the YAML to set it to ‘false’ keeps it that way. So perhaps an issue with the toggle logic?

I have not run into that behavior… I’m using a pretty basic implementation of the !input. Which version of Home Assistant are you using?

Also, I have a simplified version of the day-check logic in the latest updated on the blueprint. (Thanks to @123 and @AntonH for the pointers!) Are you using that version?

Sorry you are having trouble! Hopefully we can sort out what’s going on…

EDIT I think I see what you are experiencing now… There is a bug around saving blueprints using the UI that may be related. As a workaround, does the YAML editor work for your needs?

What is the gist url for this automation. I can’t get it to import.

Hi @chewie41983 - there is no gist for this blueprint… If the import button is not working, you can copy the YAML block from blueprint: down to mode: single and paste that into a local blueprint file.

Hope it works for you!

Thanks! I got it working. It is a cool/hot automation!

1 Like

Do I create a file .yaml here for it to work since import does not work

If the import link is not working for you, then you will need to create a local blueprint using the instructions found in the Blueprint tutorial - Home Assistant.

Also, I’ve removed the extra YAML configuration code from the overview. This should help the “Import” button work properly, so give that a try again.

Hey @jheddings, thanks for this blueprint! I just set a few schedules for my ecobee thermostat last night.
I did also add another condition to the blueprint, since I like to use a heat/cool range instead of just heat and cool separately.

Not sure if you want to add this to the blueprint or not. If not, I figure it would be helpful for me to leave a comment in the thread in case anyone else also wanted to make the change locally.

This is going in the action > choose section

      - conditions:
          - condition: state
            entity_id: !input climate_id
            state: heat_cool
        sequence:
          - service: climate.set_temperature
            entity_id: !input climate_id
            data:
              target_temp_high: !input cooling_temp
              target_temp_low: !input heating_temp
1 Like

Hi @jheddings!
Would it be possible to add a retry loop as discussed here: Retry an action in an automation when entity is not available

With the option in the configuration for how long ( while, condition, time, before) so if e.g. the chosen trigger time is 11 and the retry time-out is 2 hours, then the before condition is set to 11+2 = 13.

It would be immensely useful as my HVAC (innova) loses connection sporadically throughout the day (resulting in an “unavailable” status instead of cooling or heating) for up to 2 hours at a time and will then potentially miss the temperature change. and remain on the previous.

Thanks in advance!

I like this idea… I need to think about how that would work when there are multiple schedule triggers throughout the day. e.g. if you have a “Early Morning” and “Mid Morning” schedule, the retry would have to stop when the new schedule kicks in.

Let me give it some thought and try a few things. Thanks for the tip!

Thanks for the reply, I’d really appreciate it!
In the meantime (after posting the question) I tried to make some changes myself, but seeing as i know literally nothing about YAML and it is (in my opinion) extremely fuzzy about whitespaces etc. I failed miserably.

I had a more manual approach to that problem; I added a selector:

    retry_timeout:
      name: Retry timeout
      description: The time the automation should stop trying to resolve the automation.
      selector:
        time: {}

and tried using repeat until and time before as condition, as well as state detection.

I dont know if its helpful at all, just wanted to at least say I tried. =)

@Looxoor - Okay… I think I have something that works here. It’s a slightly different approach using a “timeout” slider rather than a fixed time value. That will make it easier if you adjust the trigger time. I’ve updated the blueprint, so give it a shot and let me know if it works for you!

@is343 - Thanks for the update! I’ve added it to the latest version of the blueprint. My thermostat does not support a temperature range, so I’m unable to verify completely with the new retry logic. If you give it a spin, let me know how it works out for you.

FWIW - you can “force” the retry logic by triggering the automation and manually changing the temperature to something other than the target (within 1 minute). The blueprint should try to change it every minute until the desired target temperature is reached.

Nice!

Thank you very much for the quick turnaround and that you found my suggestion worthwhile!

In the meantime, I (possibly) got my more rudimentary version working with much help from the forum.
I don’t really know yet how good any of them work (as I can’t trigger the unavailable status by myself), but as an experiment, I’ve set up my two different units with each version.

I’ll include my version as well if anyone wants to see it.
I changed the time and temperature inputs to use dashboard helpers instead to ensure everything is synced and convenient.

(Edit: This is confirmed to work, I added a one minute delay to avoid spamming with requests)

blueprint:
  name: HVAC Daily Schedule, local version
  description: Set the target HVAC temperature based on its mode.
  domain: automation
  input:
    climate_id:
      name: Thermostat
      description: The thermostat to control.
      selector:
        entity:
          domain: climate
          multiple: false
    cooling_temp:
      name: Cool Set Point
      description: The target temperature when cooling.
      selector:
        entity:
          domain: input_number
          multiple: false
      #selector:
        #number:
          #min: 0.0
          #max: 100.0
          #step: 1.0
          #mode: slider
          #unit_of_measurement: "°C"
    heating_temp:
      name: Heat Set Point
      description: The target temperature when heating.
      selector:
        entity:
          domain: input_number
          multiple: false
      #selector:
        #number:
          #min: 0.0
          #max: 100.0
          #step: 1.0
          #mode: slider
          #unit_of_measurement: "°C"
    at_time:
      name: Time
      description: The time to update this device.
      selector:
        entity:
          domain: input_datetime
     # selector:
     #  time: {}
    retry_timeout:
      name: Retry timeout
      description: The time the automation should stop trying to resolve the automation.
      selector:
        time: {}
    on_monday:
      name: Monday
      default: true
      selector:
        boolean: {}
    on_tuesday:
      name: Tuesday
      default: true
      selector:
        boolean: {}
    on_wednesday:
      name: Wednesday
      default: true
      selector:
        boolean: {}
    on_thursday:
      name: Thursday
      default: true
      selector:
        boolean: {}
    on_friday:
      name: Friday
      default: true
      selector:
        boolean: {}
    on_saturday:
      name: Saturday
      default: true
      selector:
        boolean: {}
    on_sunday:
      name: Sunday
      default: true
      selector:
        boolean: {}
  source_url: http://localhost
variables:
  weekly_schedule:
  - !input on_monday
  - !input on_tuesday
  - !input on_wednesday
  - !input on_thursday
  - !input on_friday
  - !input on_saturday
  - !input on_sunday
  heating_t: !input heating_temp
  cooling_t: !input cooling_temp
trigger:
- platform: time
  at: !input at_time
condition:
- condition: template
  value_template: '{{ weekly_schedule[now().weekday()] }}'
action:
  - if:
      - condition: and
        conditions:
          - condition: time
            before: !input "retry_timeout"
          - condition: state
            entity_id: !input "climate_id"
            state: unavailable
    then:
      - repeat:
          until:
            condition: and
            conditions:
              - condition: time
                before: !input "retry_timeout"
          sequence:
            - if:
                - condition: and
                  conditions:
                    - condition: time
                      before: !input "retry_timeout"
                    - condition: state
                      entity_id: !input "climate_id"
                      state: unavailable
              then:
                - delay: 00:01:00
              else:
                - choose:
                    - conditions:
                      - condition: state
                        entity_id: !input "climate_id"
                        state: heat
                      sequence:
                        - service: climate.set_temperature
                          entity_id: !input "climate_id"
                          data: 
                            temperature: '{{ states(heating_t) | float }}'
                    - conditions:
                      - condition: state
                        entity_id: !input "climate_id"
                        state: cool
                      sequence:
                        - service: climate.set_temperature
                          entity_id: !input "climate_id"
                          data:
                            temperature: '{{ states(cooling_t) | float }}'
    else:
      if:
        - condition: and
          conditions:
            - condition: time
              before: !input "retry_timeout"
            - not:
              - condition: state
                entity_id: !input "climate_id"
                state: unavailable
      then:
        - choose:
            - conditions:
              - condition: state
                entity_id: !input "climate_id"
                state: heat
              sequence:
                - service: climate.set_temperature
                  entity_id: !input "climate_id"
                  data:
                    temperature: '{{ states(heating_t) | float }}'
            - conditions:
              - condition: state
                entity_id: !input "climate_id"
                state: cool
              sequence:
                - service: climate.set_temperature
                  entity_id: !input "climate_id"
                  data:
                    temperature: '{{ states(cooling_t) | float }}'
      else:
        - stop: Still unavailable
mode: single
1 Like

@jheddings Hi! After one day of testing (and realizing that using states under Developer tools, I indeed can change states to test the automations) I’ve realized that this version doesn’t work under my special conditions. When the reported state is “unavailable” the automation simply skips all other steps, as the state is neither “heat”, “cool” nor “heat_cool”.
I suppose the easiest solution is to wrap everything in the action with an outer repeat until with condition not unavailable.