Enhanced Sun component

Share your Projects! Custom Integrations
649

Please try out the 3.3.0b1 release (described below.) It should have all the features you’re looking for.

It should be possible to create an automation that adjusts the distance & relative height of the mountains to the east (via the sun2.update_location service) as the year goes by (based on the state of the “Rising azimuth” entity.)

E.g., maybe something like:

automation:
  - id: sunrise_adjust
    alias: Sunrise adjustment
    trigger:
      - platform: numeric_state
        entity_id: sensor.home_sun_rising_azimuth
        below: 70
        variables:
          dist: 10000
          relh: 5000
      - platform: numeric_state
        entity_id: sensor.home_sun_rising_azimuth
        above: 70
        below: 105
        variables:
          dist: 9000
          relh: 7000
      - platform: numeric_state
        entity_id: sensor.home_sun_rising_azimuth
        above: 105
        variables:
          dist: 11000
          relh: 6000
    action:
      - service: sun2.update_location
        data:
          location: Home
          observer_elevation:
            above_ground: 0
            sunrise_obstruction:
              distance: "{{ dist }}"
              relative_height: "{{ relh }}"
3 Likes
650

Nice. I am very interested in photographing and have a card for showing me when golden and blue hours start and stop both in the morning and the evening.

image

This is now updated to use my phone location instead of being my home location. The sensors used for latitude, longitude and time_zone is from the companion app for Android.
I set a new sun2 location if my phone location has changed more than 50km.

alias: Ny posisjon til sun2
description: ""
trigger:
  - platform: state
    entity_id:
      - device_tracker.pixel_7
condition: []
action:
  - service: sun2.get_location
    data:
      location: phone
    response_variable: location
  - if:
      - condition: template
        value_template: >-
          {{ distance(location.latitude, location.longitude,
          'device_tracker.pixel_7') > 50 }}
    then:
      - service: sun2.update_location
        metadata: {}
        data:
          location: phone
          latitude: "{{ state_attr('device_tracker.pixel_7', 'latitude') }}"
          longitude: "{{ state_attr('device_tracker.pixel_7', 'longitude') }}"
          time_zone: "{{ state_attr('sensor.pixel_7_current_time_zone', 'time_zone_id') }}"
mode: single
2 Likes
651

Released 3.3.0b2

Updated documentation, services.yaml & en.json. Also, ru.json was added (but does not include all the new functionality in this beta.)

As far as I know, this is the final beta release for 3.3.0. Assuming I get no negative feedback, I’ll release 3.3.0 shortly.

1 Like
652

Thank you! I cover alot of area each summer on vacation, so this is great!

Any chance you can chare the card?

And a big thank you to you Phil!

**Edit:**deconz_daylight

How do i get the time of golden/blue hour? I’ve tried to research but my brain is getting error. I figured it might have something to do with azimuth time/angle and maybe a making a sensor?

Edit2: I see that the deCONZ daylight sensor have a golden hour 1 and 2, but how do i get that to display on a card?

653

I will, but you have to wait until later i May. I am not at home at the moment.

1 Like
654

Do you want to get a time? If so, which time? When they start? When they end? Each one, or both together?

Or do you just want a sensor that indicates when it is in the golden hour (or blue hour, or both)?

655

Released 3.3.0

1 Like
656

Hello Phil and thank you for the reply!

I was looking for start/end time for both golden and blue hours and replicate stigvis card.

I don’t need to know if i’m in the golden, just the time of when golden/blue hour starts and ends

/Keellan

657

Hello and sorry to bother you again Phil. I’ve been reading and reading but i can’t figure this out. I usually find an answer after alot of searching and trial and error, but this nut I can’t crack on my own and would really appriciate your help

658

Blue hour is between -6° and -4°, and golden hour is between -4° and 6°.

So, in the morning, blue hour starts at -6° and ends at -4°, and golden hour starts at -4° and ends at 6°.

In the evening, golden hour starts at 6° and ends at -4°, and blue hour starts at -4° and ends at -6°.

So, to do what you ask, you need eight time_at_elevation sensors, four with direction set to rising, and four more with direction set to setting.

1 Like
659

Hi

Here are the sensors I have created. The code below is from the storage to HA, but you have to use the sun2 configuration to create them

{
“entry_id”: “be87d11dcd1a9aa7d4de8fd1b2e7d4eb”,
“version”: 1,
“minor_version”: 1,
“domain”: “sun2”,
“title”: “phone”,
“data”: {},
“options”: {
“elevation”: 0.0,
“time_zone”: “Europe/Oslo”,
“latitude”: 58.737857,
“longitude”: 5.6400118,
“sensors”: [
{
“time_at_elevation”: -6.0,
“direction”: “rising”,
“icon”: “mdi:weather-sunset-down”,
“name”: “blue hour starts in the morning”,
“unique_id”: “dcf3e30175de6772cf298682ec037045”
},
{
“time_at_elevation”: -4.0,
“direction”: “rising”,
“icon”: “mdi:weather-sunset-down”,
“name”: “golden hour starts in the morning”,
“unique_id”: “1b08550a104a4140818439ee6f8500c6”
},
{
“time_at_elevation”: 6.0,
“direction”: “rising”,
“icon”: “mdi:weather-sunset-down”,
“name”: “golden hour ends in the morning”,
“unique_id”: “3e888eb383f9ae6ec949aa3a7d365616”
},
{
“time_at_elevation”: 6.0,
“direction”: “setting”,
“icon”: “mdi:weather-sunset-down”,
“name”: “golden hour starts in the evening”,
“unique_id”: “a2e734f5e58222825d46dde64ee6c9f7”
},
{
“time_at_elevation”: -4.0,
“direction”: “setting”,
“icon”: “mdi:weather-sunset-down”,
“name”: “golden hour ends in the evening”,
“unique_id”: “48b4b258edfbacaa41cbf2e470341a9f”
},
{
“time_at_elevation”: -6.0,
“direction”: “setting”,
“icon”: “mdi:weather-sunset-down”,
“name”: “blue hour ends in the evening”,
“unique_id”: “d6db91cbedab062536d361294e7694f6”
}
],
“observer_elevation”: [
0.0,
0.0
]
},

Here is the card (in norwegian)

type: entities
entities:
  - entity: sensor.phone_sun_bla_time_slutter_kveld
    icon: mdi:weather-sunset-down
    type: custom:multiple-entity-row
    state_header: Blå
    name: Gylden time kveld
    format: time
    entities:
      - entity: sensor.phone_sun_gylden_time_starter_kveld
        name: Start
        format: time
      - entity: sensor.phone_sun_gylden_time_slutter_kveld
        name: Stopp
        format: time
  - type: divider
  - entity: sensor.phone_sun_gylden_time_slutter_morgen
    attribute: tomorrow
    icon: mdi:weather-sunset-up
    type: custom:multiple-entity-row
    state_header: Stopp
    name: Gylden time morgen
    format: time
    entities:
      - entity: sensor.phone_sun_bla_time_starter_morgen
        name: Blå
        format: time
        attribute: tomorrow
      - entity: sensor.phone_sun_gylden_time_starter_morgen
        name: Start
        format: time
        attribute: tomorrow
  - type: divider
  - entity: sensor.phone_sun_setting_azimuth
    format: precision0
    state_header: Ned
    name: Sol, retning
    icon: mdi:sun-compass
    type: custom:multiple-entity-row
    entities:
      - entity: sensor.phone_sun_rising_azimuth
        format: precision0
        name: Opp
  - entity: sensor.phone_sun_daylight
    attribute: tomorrow_hms
    state_header: I morgen
    icon: mdi:sun-clock
    name: Daglengde
    type: custom:multiple-entity-row
    entities:
      - entity: sensor.phone_sun_daylight
        name: I dag
        attribute: today_hms
  - entity: sensor.pixel_7_geocoded_location
    name: ' '
title: Fototid

image

And here is the automation for setting a new location when on travel

alias: Ny posisjon til sun2
description: ""
trigger:
  - platform: state
    entity_id:
      - device_tracker.pixel_7
    attribute: latitude
condition: []
action:
  - service: sun2.get_location
    data:
      location: phone
    response_variable: location
  - if:
      - condition: template
        value_template: >-
          {{ distance(location.latitude, location.longitude,
          'device_tracker.pixel_7') > 10 }}
    then:
      - service: sun2.update_location
        metadata: {}
        data:
          location: phone
          latitude: "{{ state_attr('device_tracker.pixel_7', 'latitude') }}"
          longitude: "{{ state_attr('device_tracker.pixel_7', 'longitude') }}"
          time_zone: "{{ state_attr('sensor.pixel_7_current_time_zone', 'time_zone_id') }}"
mode: single
1 Like
660

I’m currently burnt out and generally need more direct instructions as my brain doesn’t quite keep up, so this helps alot! Appreciate your answer!

Going to sit down and try this!

Tusen takk!

661

Do you have any idea why the sensors created with negative elevation shows up as “unknown”?

The two sensors that works is the golden hour start in the morgon and ending in the evening, when the elevation is above horizon

Read through the readme but i couldn’t find an answer

Edit. Nothing was wrong, I just remembered where i live and the sun almost doesn’t set atm… :person_facepalming:

2 Likes
662

Hello again!

I was wondering if there’s a way to get a sensor like ‘time at elevation’, but instead of elevation i would like ‘time at azimuth’. I want the times when the sun is shining on my balcony, so I can open the windows and lower the temperature so my flowers don’t die

663

How should this work? Azimuth is an angle (if I’m not mistaken), how should this go together with a time? In my understanding at least one of each would need to be provided, as in “at what time is the azimuth 300°” or “what is the azimuth at 08:00am”.

EDIT: I forgot to add a link to the “adaptive cover” integration, that could help you here. Take a look at it, it could give you some ideas how to modify to your needs:

664

I have no plans to add such a sensor. Although the astral package has a “time at elevation” method, it does not have the same for azimuth.

If your plan would be to use the sensor to trigger an automation, then you can just trigger on the azimuth value directly instead I would think.

665

Azimuth can also be made with a template sensor. Anyway, it is strongly connected to time of day and does not change much through a year. So if accuracy of around 20 minutes is ok, one could also use GMT time.

1 Like
666

Apparently, I’ve been remiss in announcing a few bug fix releases:

20240512 Released 3.3.1

Fix processing time_at_elevation config when value is zero

20240531 Released 3.3.2

Move zoneinfo & pytz file I/O to executor

20240813 Released 3.3.3

Fix en translations for nautical_dawn & nautical_dusk

20241030 Released 3.3.4

Fix for breaking change in HA 2024.11

1 Like
667

Not sure if anyone caught it, but this integration has a bug that manifests during Daylight Saving Time to Standard Time transitions. E.g., here’s what the elevation sensor looked like during this period:

image

Notice the hour where it didn’t update correctly. That was during the overlap period after leaving DST.

The root cause is that Python datetime comparisons & math don’t work correctly (or, at least, as expected) for times just before and after this DST → ST transition if the two datetime objects are “aware” and have the same tzinfo object.

E.g., for this comparision:

2024-11-03T01:45:00-05:00 < 2024-11-03T01:15:00-06:00

One would expect the result should be True, since the first time is just before the transition, and the second time is just after. Unfortunately, Python returns False, because it ignores the fold attribute and simply compares the “naive” part of the datetime objects.

Anyway, I’m working on a fix that uses UTC times internally. UTC comparisons & math are not vulnerable to this issue because there are no DST transitions (i.e., fold is never 1.)

P.S. I actually didn’t notice this first. I noticed a related issue with my composite integration, and realized all my integrations that do time comparisons or math are affected. I’m in the process of fixing them all.

3 Likes
668

Released 3.3.5b0

Python datetime object comparisons and math don’t work as expected when the objects are aware and have the same tzinfo attribute. Basically, the fold attribute is ignored in this case, which can lead to wrong results.

Avoid this problem by using aware times in UTC internally. Only use local time zone for user visible attributes.

1 Like