"Hello everyone, I have written a simple template to compare two times, the sunset time and the alarm time, so that it can be integrated into an automation. I would expect the template to return a value of TRUE or FALSE. I had to convert the text strings of sensor.sun_next_rising (which leaves a value in UTC) into datetime because I need the time zone to be taken into account.
My problem is that the template works in the ‘Developer tool - Template editor’. The same template, tested on a condition applied to an automation, does not work.
{# set sun rising time as datetime, not as string #}
{% set next_rising = states('sensor.sun_next_rising') %}
{% set next_rising_dt = as_local(as_datetime(next_rising)) %}
{# set wake up time as datetime, not as string #}
{% set wake_up_string = "06:30:00" %}
{% set wake_up_dt = as_local(strptime(wake_up_string, "%H:%M:%S")) %}
{# compare #}
{{ next_rising_dt.time() < wake_up_dt.time()}}
Do you have any suggestions?"
This is the whole automation:
alias: Apri tapperelle al mattino 2
description: ""
trigger:
- platform: sun
event: sunrise
offset: 0
- platform: time
at: "06:29:50"
condition: []
action:
- choose:
- conditions:
- condition: time
weekday:
- mon
- tue
- wed
- thu
- fri
enabled: true
- condition: template
value_template: >
{# set sun rising time as datetime, not as string #}
{% set next_rising = states('sensor.sun_next_rising') %}
{% set next_rising_dt = as_local(as_datetime(next_rising)) %}
{# set wake up time as datetime, not as string #}
{% set wake_up_string = "06:30:00" %}
{% set wake_up_dt = as_local(strptime(wake_up_string, "%H:%M:%S"))
%}
{# compare #}
{{ next_rising_dt.time() < wake_up_dt.time()}}
sequence:
- wait_for_trigger:
- platform: time
at: "06:30:00"
- action: notify.persistent_notification
metadata: {}
data:
message: "TRUE"
- conditions:
- condition: time
weekday:
- sat
- sun
sequence:
- wait_for_trigger:
- platform: time
at: "08:00:00"
default: []
- action: light.turn_on
metadata: {}
data: {}
target:
device_id: 28a1c43dd62242ca9efd27383082d708
mode: single
can you grab the last trace where it failed and you think it shouldn’t have?
and btw, the conditions on your choose are “anded” together, so it only triggers if it’s a weekday and your template is true. so if you were working on this yesterday, it shouldn’t have passed your first choose.
It’s a workday, maybe is summer and sun rises too early: please wait do not switch on the light (or open cover, or what else). Let me sleep till 06:30, then you can open the cover.
It’s a workday, it’s autumn or wintertime, and sun rises after 06:30. Don’t mind. Let’s wait sunrise time to open the cover.
It’s saturday/sunday, I want to sleep till 08:00. Wait that time to open cover.
– I’m going crazy with the simplest way to write this automation without redundant instructions
I just added your template code to the Template editor and added output to each of the variables you set, the results are interesting. I think you may be mixing formats incorrectly as I’m getting 2 different offsets, one is not accounting for daylight savings time. But it’s the wake_up_dt that’s really interesting. Because your not feeding it a date it defaults and January 1, 1900 will always be before any time in 2024 .
Since you’ve already set wake_up_dt as a string there’s no need to convert it. Try using {% as_timestamp(states('sensor.sun_next_rising'))|timestamp_custom('%H:%M:%S') %} to get a comparable string to use.
Your observation is not exactly correct. When I request just the value of states('sensor.sun_next_rising'), the system responds that sunrise is at 05 AM because it does not take into account the time zone, which is UTC +2, so I have to convert it in datetime, that contains extra info like timezone
The fact that the date refers to the year 1900 does not matter, because then I only ask to compare the time parts using the .time() option.
Not directly, but you can set up the overall structure in the UI then switch to YAML using the “Edit in YAML” option in the 3-dot expansion menu to add the variables…
.
