Enhanced Sun component

[parautenbach (Pieter Rautenbach)]

I’ve upgraded my HA to 2024.1.3 today, including the sun2 integration to 3.1.0.

This is my exsting config:

sensor:
  - platform: sun2
    monitored_conditions:
      - daylight

I use this daylight value in a number of places. I’ve looked through the docs and how sensors like sunrise and sunset must be converted, but they’re all point in time changes. This one is a duration and it doesn’t seem like it’s supported anymore. Should I make my own template sensor now?

EDIT: Or will it be a default sensor by simply using sun2: in my config (with no or other options)?

[mobile.andrew.jones (Andrew Jones)]

I don’t have sun2 anywhere in my configuration.yaml.
It’s added in the GUI devices and services.
All the sensors are enabled or disabled in the GUI.

And I definitely have the daylight length sensor.

[parautenbach (Pieter Rautenbach)]

Thanks, Andrew.

Yeah, I was wondering whether I should just completely remove (not migrate) my YAML config in favour of the UI, or not. I decided to stick with the YAML.

I then saw that sun2: by itself does nothing, so I changed it to:

sun2:
  - unique_id: "some_id"

It created the default sensors for my home location, plus it then started to show up on the integrations page, where I was able to enable the daylight sensor. Now that I see I have to do this via the UI anyway, I’m thinking of removing the YAML config.

I read this part of the docs to mean that it’s only done this way if the integration is set up via the UI (config flow), so I somehow thought it would be different for YAML config, since the example above this sentence uses YAML.

Simply go to the Settings → Devices & services page, click on Sun2, then entities, and enable/disable the entities as desired.

[pnbruckner (Phil)]

I don’t know if this has been discussed before relative to this custom integration, but it would appear HA has been misleading us (probably for years) as to what it’s elevation config option is. It says, “Altitude above sea level in meters. Impacts sunrise data.”

Well, turns out, that is wrong! It should be “observer’s elevation above ground level” (at location specified.)

I’ve noticed for a long time that the sunrise, dusk, etc. values provided by both this custom Sun2 integration, and the built-in sun integration, (which both use the same astral package) have been off for my HA configured location. I just wrote that off to them being close, but not identical because other places I’ve looked for this info (weather apps, etc.) probably provide data for a nearby, big city instead of my exact location.

Well, turns out, that is wrong, too. I had configured HA’s elevation setting to my location’s altitude above sea level, as HA’s docs say to do. I happen to live in a very flat area, so my “observer’s elevation” is actually zero. I changed HA’s elevation config accordingly, and presto magico!, all the sun data matched other sources of the same data exactly!

Now, having said that, there are five built-in integrations that also use this config option, and I have no idea how they interpret this value, but I don’t care, because I don’t use any of them.

AMAZING!!!

[finity]

So how do you know what the elevation above ground level will be?

Is “ground level” the average level above sea level for your area?

Does your location (lat & lon) you enter into HA already take into account your elevation above sea level?

From your explanation it seems that your elevation above sea level means nothing (as it’s already factored in…) and it should be if you live on the ground floor or on the top of a 10 story building (0 feet for the former and ~100 feet for the latter).

how does a non-flat area (hills/mountains) figure into all of this?

[pnbruckner (Phil)]

It really isn’t that complicated. Look down. How far are you above the ground?

By “your elevation above ground level”, I mean simply that. If your house is on the ground, then your elevation is zero. If it’s on 20 meter stilts, then it’s elevation is 20.

Ok, so the average person is maybe 1 - 2 meters tall, so maybe you could enter 1 or 2.

There’s a whole discussion here:

Why are the sunrise and sunset times wrong?

Home Assistant uses the Astral package (currently v2.2) to calculate sun-related data & events. Some of the data it requests from the package require an “observer elevation.” In these cases, HA provides its elevation config value. As mentioned previously, the value provided to the package should be the observer’s “elevation above ground level.” See Effect of Elevation from Astral’s documentation for more detail. However, the HA documentation says the elevation configuration parameter is “Alti…

For a better explanation than mine, see Effect of Elevation from the astral package’s documentation. (As mentioned above, HA, including my custom integration, uses the astral package to make these sun related calculations.)

@finity

how does a non-flat area (hills/mountains) figure into all of this?

If you’re on a hill, then yes, you’d want to include that, assuming that hill is above the average ground level in your area. It all has to do with the curvature of the Earth and how you see the horizon from where you are. Interestingly, the astral package also apparently has a way to tell it there is a mountain between you and the horizon (how far it is from you and how high it is), because that can delay sunrise, but HA doesn’t support that. Although, I might with my custom integration. Hmm…

[parautenbach (Pieter Rautenbach)]

This relates to prominence.

You could be in a valley and be surrounded by mountains too.

[finity]

@pnbruckner

If your house is on the ground, then your elevation is zero. If it’s on 20 meter stilts, then it’s elevation is 20.

Then yeah, I agree with your assessment…amazing!

I guess I need to go and change my elevation setting in HA now.

@pnbruckner

It all has to do with the curvature of the Earth

wait, I thought I heard somewhere that the earth was flat?

I’m so confused…

I definitely think they made it way more confusing than it needed to be.

[pnbruckner (Phil)]

Released 3.1.1

Fix display of period-of-time sensors w/ HA 2024.2

Starting in HA 2024.2, the frontend no longer displays sensors with a duration device_class as HH:MM:SS if the entity has a suggested_display_precision set, or the user has manually set a display_precision for the entity.

Previously, the period-of-time sensors (daylight/night) had a suggested_display_precision of 3. This change removes that setting.

Unfortunately, there’s a bug in the sensor component that doesn’t properly remove suggested_display_precision from the entity registry. Therefore, this change also forcibly removes it from the registry if necessary.

Also, add a state_class of measurment to period-of-time sensors (which was not possible for duration sensors in much older HA versions.)

Lastly, change the description of the elevation configuration option to “observer’s elevation above ground level at specified location” instead of “location’s elevation above sea level.” Unfortunately, Home Assistant incorrectly describes the elevation option (in the general system configuration section) as elevation above sea level. This is not correct for the purpose of determining sun related events. If you’ve experienced the values returned by this integration were a bit different from other sources (such as weather websites, etc.), this is probably the reason why.

Therefore, the following are suggested:

• If you’ve set a display precision for any of the daylight or night sensors, remove that setting (i.e., return it to default.)
• Change the elevation option for all your Sun2 configurations per the discussion above. In most cases that probably means changing it to zero (or maybe 1 or 2 meters.)

[Mariusthvdb (Marius)]

Hi Phil,

thanks for your continued development of this fine component.
Please let me ask if it is to be expected that this config in a core entities card:

      - type: attribute
        entity: sensor.thuis_zon_fase
        attribute: golden_hour
        name: Golden hour
      - type: attribute
        entity: sensor.thuis_zon_fase
        attribute: blue_hour
        name: Blue hour

is supposed to Not be translated, as it shows:

with lower text, and not in Dutch with capitalized Uit, as I had hoped for, see another card:

the latter is a template entity row card of

    entities:
      - type: custom:template-entity-row
        entity: binary_sensor.donker_buiten
        state: >
          {{state_translated(config.entity)}}
        name: >
          Donker buiten (< -4°)
        secondary: >
          {% if has_value(config.entity) %}
            {{relative_time(states[config.entity].last_changed)}} ago, Elevation:
            {{state_attr('sun.sun','elevation')}}
          {% else %} Not yet set, Elevation: {{state_attr('sun.sun','elevation')}}
          {% endif %}
      - entity: binary_sensor.golden_hour
        secondary_info: last-changed

so you see the top of that has the new state_translated() template functionality, while the second is a regular binary sensor entity.

could it be the Sun2 entities (or their attributes) are somehow not correctly translated?

in dev tools states:

options:
  - night
  - astronomical_twilight
  - nautical_twilight
  - civil_twilight
  - day
blue_hour: false
golden_hour: false
rising: true
next_change: "2024-02-20T12:55:53+01:00"
device_class: enum
icon: mdi:weather-sunny
friendly_name: Fase

note that even though the attributes names themselves are translated alright, that does not happen when we use the attribute option in the entities card, which then uses the main entity name. We need to set a name: option for those.

Guess that would be a Frontend issue (bug even maybe), but my ask here is about the value of the attribute…

[pnbruckner (Phil)]

I really don’t know. The integration certainly does not include translations for the values of these state attributes, only for their names. The same is true for the next_change attribute, yet its value is getting translated properly. E.g., in English:

And in Dutch:

So, you can see that all the attribute names are translated, but only the next_change attribute’s values are translated. And that is NOT done by my integration. It is counting on translations defined elsewhere (e.g., in the sensor component-level code, frontend???) They seem to work for datetime’s, but not for bool’s. I don’t know why that is the case.

[Mariusthvdb (Marius)]

yes, its all a bit inconsistent yet (HA dashboard I mean).

Ive openend this using attribute option in entities card does not show the attribute name (but defaults to the main entity) · Issue #19840 · home-assistant/frontend · GitHub to see the response on that first.

I would hope that basic values like true/false on attributes would be automatically translated by the HA frontend also.

Will open another quest on that after some initial response to the above

[merlebeckman (Jim)]

I am wondering if I have done something wrong. After installing Sun2, I no longer see sunrise or sunset times. I can use sensor.home_sun_rising or sensor.home_sun_setting. In the Sun2 device setting page, I have 7 enabled entries and 17 disabled, none of which are sunrise or sunset. Is this intended or am I missing something? Thank you…

[pnbruckner (Phil)]

sensor.home_sun_rising is indeed sunrise, and sensor.home_sun_setting is sunset, as explained in the README.md.

Maybe I’m misunderstanding you. What exactly do you mean by, “I no longer see sunrise or sunset times”?

FWIW, I chose to use “sun_rising” instead of “sunrise”, and “sun_setting” instead of “sunset”, to be more consistent with the way the built-in sun integration works.

[merlebeckman (Jim)]

I had a sensor named sensor.sunrise that I had to change to sensor.home_sun_rising. sensor.sunrise status is ‘unavailable’ now.

I must be missing something though because documentaion states “All “simple” sensor options (e.g., sunrise , sunset , etc.) will be created automatically.” however I cannot find sunrise or sunset sensors.

[parautenbach (Pieter Rautenbach)]

You can enable or disable specific sensors under the integration’s config.

Or look for it under your settings > entities view (check the disabled ones) and enable it.

[pnbruckner (Phil)]

Ok, I can see the confusion. Yes, that paragraph is misleading. And I never explicitly state anywhere what used to be called sunrise is now rising and what used to be called sunset is now setting. I’ll try to make it clearer. Thanks for the feedback!

[merlebeckman (Jim)]

Thank you for the reply. It’s no big deal to me but is this a “breaking change” where we have to modify the names of the sensors in use (sunset and sunrise) before 3.1.1?

[pnbruckner (Phil)]

Well, it’s not technically a “breaking change”, because the older “platform” YAML config is still supported, although deprecated. So, nothing “breaks” just by upgrading.

That only happens when changing your YAML configuration to the new format, or using the new UI based config flow.

But, yes, changing from:

sensor:
  - platform: sun2

to:

sun2:
  - ...

or using the new UI config flow, is effectively a breaking change, at least concerning the naming of these two sensors. And, FWIW, that happened at release 3.0.0, which has been out for over two months now.

Having said that, the new names of these sensors is documented, and they are more consistent with the built-in sun sensor, so it shouldn’t be a complete surprise.

Still, I agree, the doc could use some improvement to make this all clearer, which I plan to do.

[merlebeckman (Jim)]

Thank you for this detailed thorough explanation! And for this app!