Sunrise / sunset display one time, automations start at another

Configuration
1

Hi everybody,

I have created sensors for sunrise and sunset:

sensor:
  - platform: template
    sensors:
      sonnenaufgang:
        friendly_name: "Sonnenaufgang"
        unit_of_measurement: "Uhr"
        value_template: '{{ state_attr("sun.sun", "next_rising").split("T")[1].split("+")[0]}}'
      sonnenuntergang:
        friendly_name: "Sonnenuntergang"
        unit_of_measurement: "Uhr"
        value_template: '{{ state_attr("sun.sun", "next_setting").split("T")[1].split("+")[0]}}'

They work, as in they do display some time:
image

I also have a script.debug, which will just send a notification via telegram when it is triggered. When I create an automation to run at the time value sensor.sonnenuntergang returns, it will be sent at a different time. Sunset today should be at 18:22:58, which sounds about right. But when I use platform: sun, event: sunset, and also run script.debug, it will be triggered at a different time.

What am I doing wrong? I don’t know exactly how much the offset is for sunset. But I can tell you for sunrise. Today, the sensor states that sunrise should be at 04:18:03. However, irrigation has been triggered at around 06:21 (seconds not shown, and I don’t know the exact time as I only received the irrigation notification after irrigation had finished, so it started ca. 5 minutes prior to this).

What do I need to do in order to display the actual time that Home Assistant uses for event: sunset?

Thank you for your help :slight_smile:

2

Where is the automation that started the irrigation?
Is it perhaps set up to UTC timezone?

3

This is it. I don’t know what time zone it uses. How can I determine this?

automation:
  - alias: "[Timer] Bewässerung Morgens"
    trigger:
      platform: sun
      event: sunrise
    condition:
      - condition: state
        entity_id: binary_sensor.bewaesserung_condition
        state: "on"
    action:
      - service: input_number.set_value
        data_template:
          entity_id: input_number.wasserstand_links_alt
          value: "{{ states('sensor.tonne_links') }}"
      - service: input_number.set_value
        data_template:
          entity_id: input_number.wasserstand_rechts_alt
          value: "{{ states('sensor.tonne_rechts') }}"
      - service: switch.turn_off
        entity_id: switch.valve_01, switch.valve_02, switch.valve_03
      - service: switch.turn_on
        entity_id: switch.dr_wasser
      - delay: "00:00:02"
      - service: switch.turn_on
        entity_id: switch.valve_01
      - delay: "{{ states('input_datetime.dauer_bewaesserung_morgens') }}"
      - service: switch.turn_off
        entity_id: switch.valve_01
      - service: switch.turn_on
        entity_id: switch.valve_02
      - delay: "00:01:00"
      - service: switch.turn_off
        entity_id: switch.valve_02
      - service: switch.turn_on
        entity_id: switch.valve_03
      - delay: "00:02:30"
      - service: switch.turn_off
        entity_id: switch.dr_wasser
      - service: switch.turn_off
        entity_id: switch.valve_03
      - service: homeassistant.update_entity
        entity_id: sensor.verbrauch_tonne_links
      - service: homeassistant.update_entity
        entity_id: sensor.verbrauch_tonne_rechts
      - delay: "00:00:05"
      - service: notify.me
        data_template:
          message: "Gießen fertig. Verbrauch (Links {{ states('sensor.verbrauch_tonne_links') }} Liter) (Rechts {{ states('sensor.verbrauch_tonne_rechts') }} Liter)"
4

I thought you used the template sensors you created in the automation.

5

No. I only created those sensors so that I’d know what time sunset actually is.

6

Usually when you want to debug something you make sure you use the same thing everywhere.

Also I noticed you split a lot in the template, I notice for instance the T part.
So what is the string before all the splits.

7

Two things:

First, the next_rising and next_setting attributes of sun.sun are expressed in UTC, not your local time zone. So when your template sensors remove the time zone offset, they can be wrong if interpreted as times in your local time zone.

Second, next_rising is today’s sunrise when the current time is before sunrise, but is tomorrow’s sunrise when the current time is after sunrise. The same thing happens with next_setting. Depending on where you live and the time of the year, the error can be significant.

The sunrise & sunset sun triggers are based on your local time zone.

Given what you’ve said it sounds like maybe the time zone settings on your system (OS & HA), and possibly the clock, may be set incorrectly. Here’s a simple test. Enter the following in the Template Editor. What do you get? Do the times and time zone settings seem correct?

{{ utcnow() }} {{ utcnow().tzinfo }}
{{ now() }} {{ now().tzinfo }}
{{ now().astimezone() }} {{ now().astimezone().tzinfo }}
8

Thank you @pnbruckner. This is the output I get

2020-08-27 06:25:12.174220+00:00 UTC
2020-08-27 08:25:12.174365+02:00 Europe/Berlin
2020-08-27 08:25:12.174469+02:00 CEST

The now().tzinfo value is correct. It is currently 08:25 and I am located in GMT+02:00 (= Europe/Berlin).

Second, next_rising is today’s sunrise

Thanks for letting me know. I guess this is okay, because I mainly rely on the next_setting value, anyway. Let’s say it is currently 16:30 and I want to know when event x is going to happen (which will happen when Home Assistent detects event: sunset, for example 18:34), then it will be before this time. Once the event has happened, Home Assistant will show me the value for tomorrow - but I will also already have received the notification, so I’ll know that the sun has already set. I guess I could even modify my button-card so that it will display one icon next to the time if it is still about to happen (value is still for today) or has already happened (value is for tomorrow).

Perhaps I described the issue incorrectly @Hellis81: the sensor I created is only to show me the equivalent of event: sunrise/sunset. If there is a way to directly display the exact time Home Assistant uses for these events, I would not need my sensor.

The value for {{ state_attr("sun.sun", "next_setting")}} (so before splitting it) is 2020-08-27T18:20:39+00:00.

9

I understood what you meant but I don’t think you understand me.
If you take a time value and expect this to be the time an automation triggers then trigger on that time value.
Don’t use the entity you got the time value from.
Use a template {{ sensor.time == sensor.your_value}} or something like it.
With the setup it’s much easier to debug it, if the trigger does not happen at the said time it has to be a problem with the template or the actions.

When you set an automation that is based on a state of an entity and that state is set by the time you add another layer which depends on an understanding of how that state changes.
And in this case that was not sure since you expected one time and got another.

This is just a tip when you want to debug something, go back to as basic as possible where as little as possible relies on something else and work your way from there to the more complex.

1 Like
10

Ok, good, looks like the clock and time zone settings are correct.

So that is UTC, not you local time. If you want it to be expressed in the local time zone, then try this:

sensor:
  - platform: template
    sensors:
      sonnenaufgang:
        friendly_name: "Sonnenaufgang"
        unit_of_measurement: "Uhr"
        value_template: >
          {{ as_timestamp(state_attr("sun.sun", "next_rising"))
             |timestamp_custom("%H:%M:%S") }}
      sonnenuntergang:
        friendly_name: "Sonnenuntergang"
        unit_of_measurement: "Uhr"
        value_template: >
          {{ as_timestamp(state_attr("sun.sun", "next_setting"))
             |timestamp_custom("%H:%M:%S") }}
2 Likes
11

Another road to the same destination:

{{(as_timestamp(state_attr("sun.sun","next_rising"))|timestamp_local)[-8:]}}
1 Like
12

Thanks everybody. I went with @pnbruckner s solution, but @123 s works equally fine.

13

Is there a way to subtract 12 hours fom %H value? The above code is working like a charm for me but would prefer to read 12 hr values (with AM/PM) than 24 hr notations.
Thanks!

14

Change %H to %I, you can also add %p for am/pm

strftime.org

1 Like
15

Thanks @petro :smile:

Awesome!!!

sun

16

Hello, I’m a beginner and I’m still struggling with a lot of “little things”…
I found these older posts here and would like to calculate the duration between sunrise and sunset in XXH XXM.
As template:

{{ as_timestamp(state_attr("sun.sun", "next_rising")) |timestamp_custom("%H:%M:%S") }} -
  {{ as_timestamp(state_attr("sun.sun", "next_setting")) |timestamp_custom("%H:%M:%S") }}

unfortunately this doesn’t work.

Did I just spell that wrong or are there other reasons?
I would be very happy about tips.

17

It’s not quite as simple as subtracting the values of sensor.sun_next_rising from sensor.sun_next_setting.

Why not? Because the calculation would only be valid prior to today’s sunrise. After sunrise, the value of sensor.sun_next_rising automatically becomes tomorrow’s sunrise. So, immediately after sunrise, the calculation would be subtracting tomorrow’s sunrise from today’s sunset (which would be invalid).

You would need to create a Trigger-based Template Sensor, triggered at midnight, so that it performs the subtraction prior to sunrise thereby ensuring it uses the current day’s values for sunrise and sunset.

template:
  - trigger:
      - platform: time
        at: '00:00:00'
    sensor:
       - name: 'Day Length'
         state: >
           {% set sunset = states('sensor.sun_next_setting') | as_timestamp %}
           {% set sunrise = states('sensor.sun_next_rising') | as_timestamp %}
           {{ (sunset - sunrise) | timestamp_custom('%H:%M', false) }}
18

Hello,
wonderful, thank you.
It works just like I wanted it to.
I wonder where I can find more information on these subjects. I would like to delve deeper into the matter.

But thank you for the great support

19

References:
Trigger-based Template Sensor
Templating

20

Thank you for the hints and links.
Unfortunately, my problem starts earlier, I’m already missing the basics.
But I enjoy the topic a lot and I will keep at it