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