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 
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 
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.