Sun State change 3 minutes after sunrise event [Solved]

Hi there!

I have a question about sunrise event.
What I try to do is:

  • Create automation that launch my action at sunrise but not before 8 am

For that, I wrote that:

- id: volets_ouverture_default
  alias: Volets Ouverture 8H/Sunrise
  trigger:
  - at: '08:00:00'
    platform: time
  - event: sunrise
    platform: sun
  action:
  - condition: and
    conditions:
    - condition: time
      after: '08:00:00'
    - condition: state
      entity_id: sun.sun
      state: above_horizon
  - entity_id: cover.my_shutter
    service: cover.close_cover

But it doesn’t work.
I did some investigations and I found that sun state changes 3 minutes after the sunrise event.
Is it a normal behavior?

If necessary my automations.yaml tests that show this fact:

- id: test759
  alias: Test 759
  trigger:
  - at: '07:59:00'
    platform: time
  action:
  - service: system_log.write
    data_template:
      message: |
        759
        date_time => {{ states("sensor.date_time") }}
        state => {{ states('sun.sun') }}
        next_rising => {{ state_attr('sun.sun', 'next_rising')}}
		
- id: testsunrise
  alias: Test sunrise
  trigger:
  - event: sunrise
    platform: sun
  action:
  - service: system_log.write
    data_template:
      message: |
        sunrise
        date_time => {{ states("sensor.date_time") }}
        state => {{ states('sun.sun') }}
        next_rising => {{ state_attr('sun.sun', 'next_rising')}}
        
- id: testsunriseplus1
  alias: Test sunrise plus 1
  trigger:
  - event: sunrise
    platform: sun
    offset: '+00:01:00'
  action:
  - service: system_log.write
    data_template:
      message: |
        sunrise +1
        date_time => {{ states("sensor.date_time") }}
        state => {{ states('sun.sun') }}
        next_rising => {{ state_attr('sun.sun', 'next_rising')}}
		
- id: test802
  alias: Test 802
  trigger:
  - at: '08:02:00'
    platform: time
  action:
  - service: system_log.write
    data_template:
      message: |
        802
        date_time => {{ states("sensor.date_time") }}
        state => {{ states('sun.sun') }}
        next_rising => {{ state_attr('sun.sun', 'next_rising')}}

- id: test803
  alias: Test 803
  trigger:
  - at: '08:03:00'
    platform: time
  action:
  - service: system_log.write
    data_template:
      message: |
        803
        date_time => {{ states("sensor.date_time") }}
        state => {{ states('sun.sun') }}
        next_rising => {{ state_attr('sun.sun', 'next_rising')}}
		

An the logs relative to automation tests:

2019-11-28 07:59:00 ERROR (MainThread) [homeassistant.components.system_log.external] 759
date_time => 2019-11-28, 07:58
state => below_horizon
next_rising => 2019-11-28T07:00:07+00:00

2019-11-28 08:00:07 ERROR (MainThread) [homeassistant.components.system_log.external] sunrise
date_time => 2019-11-28, 08:00
state => below_horizon
next_rising => 2019-11-29T07:01:27+00:00

2019-11-28 08:01:07 ERROR (MainThread) [homeassistant.components.system_log.external] sunrise +1
date_time => 2019-11-28, 08:01
state => below_horizon
next_rising => 2019-11-29T07:01:27+00:00

2019-11-28 08:02:00 ERROR (MainThread) [homeassistant.components.system_log.external] 802
date_time => 2019-11-28, 08:01
state => below_horizon
next_rising => 2019-11-29T07:01:27+00:00

2019-11-28 08:03:00 ERROR (MainThread) [homeassistant.components.system_log.external] 803
date_time => 2019-11-28, 08:02
state => above_horizon
next_rising => 2019-11-29T07:01:27+00:00

Thanks!

What is the altitude you entered in the HA config? Perhaps that is taken into account?

2 Likes

@Skye is on the money with the altitude thing, except it is called ‘elevation’. Set that properly in your onboarding or configuration.yaml for accurate sunrise and sunset times.

Why are your conditions in the action block?

Also conditions are AND by default so you only need:

- id: volets_ouverture_default
  alias: Volets Ouverture 8H/Sunrise
  trigger:
  - platform: time
    at: '08:00:00'
  - platform: sun
    event: sunrise
  condition: 
  - condition: time
    after: '08:00:00'
  - condition: state
    entity_id: sun.sun
    state: above_horizon
  action:
  - service: cover.close_cover
    entity_id: cover.my_shutter
1 Like

The sun.sun attribute you are looking at is sun next rising, once it has happened that would now be ‘last’ rising, so to be honest, I’m surprised it take 3 minutes to update.
You can ‘cope’ with this in three ways (half the year it will go earlier, though not contiguously) : -

  1. If used in a binary_sensor then you could introduce a delay off of say 2 mins
  2. You could enter today’s values into input_datetime at say 01:30 (or whatever) and use those values that will be valid all day
  3. Use pnbruckner 's enhanced sun component or sun2 component that gives you values for ‘today’ as opposed to ‘tommorow’

starting to slowly turn red here, :blush:

this is something Ive never understood correctly apparently. I’ve always taken elevation for the height above sea level, as that is such a dominant mindset in our country which is almost 50% below… (AHN Viewer | AHN)

because of this: Setup basic information - Home Assistant

so if this is sun setting, wat should I enter there to have a valid config…

this: ?

18

these values are changing so how can I enter that in the config…


sorry for this, feel truly stupid…

seems I was right after all… pfff. relieved is the word, please ignore my temporary mind lapse :wink:

For your case I would set the elevation to 0. Reason being that even if you are below sea level there must be a dam or dyke between you and the horizon that is at least at sea level or you would be adversely affected by dihydrogen monoxide overdose.

1 Like

It’s dangerous stuff that but you can buy packets of it in dehydrated form.

Marius, I look at Google earth and that gives you an elevation. It IS height above sea level. But there are lots of places on the Earth’s surface that are lower than you eg the dead Sea.

Edit: the point is also kinda moot if you have a 20’ wall round your property or are surrounded by skyscrapers. It’s just a general rule of thumb for light levels (well my use is) I don’t use it for astral navigation or anything. :man_shrugging:

no, no worries, I am at 5.39443 above sea level :wink:

yes, Ive edited my post above, feel a bit less shaken now :wink:
I’ve added a link to the AHN viewer…

Meters or parsecs?

Never understood parsecs. Who would base a distance on an arbitrary angle of measurement?

haha:
52

like to be precise do you;-)

Always specify a unit and label your graph axes. Words to live by.

Also, get some global change insurance!

Are you implying a global conspiracy by the US and the International Air Travel industry to sink Holland ? :rofl:

1 Like

:rofl::rofl::rofl: I think we can rule out the US, the acting President Liar in Chief doesn’t even know, that the Netherlands are a country. He still thinks, it’s a suburb of Belgium (the city :crazy_face: :joy:)… :open_mouth:

But, if something happens to the Netherlands, you can always come here to Bavaria. We don’t have a lot of space, but everyone is sliding a bit together, than this will work! :slight_smile: As long as we can find an understanding about soccer, everything will be fine! :rofl::rofl::rofl::rofl:

1 Like

He isn’t acting when he lies and he only lies when his lips are moving !

2 Likes

Ha! This is hilarious!

Who would base a distance on an arbitrary angle of measurement?

Astronomers with a very self centred POV.

1 Like

It was very helpful when astronomers had to measure things by hand. If you measure the movement of a star that is close by relative to the starts in the background, you are effectively measuring in degrees. By measuring a stars’ position half a year apart, its apparent location will change depending on the distance. A parsec makes it very easy to directly translate this difference in angle directly to a distance from earth.

see: https://en.wikipedia.org/wiki/Parsec
:nerd_face:

Even ‘light year’ assumes that an earth orbit is a universal constant. So I agree again. :+1:

Off topic alert :rotating_light: