Released 3.0.0
4 Likes
I need help to convert this to the new version
1 Like
sun2:
- unique_id: some_place
location: Some Place
latitude: XYZ
longitude: XYZ
time_zone: Europe/Rome
elevation: 194.26
Give the location name whatever you like. Then, after reloading, go to the Integrations page, click on Sun2, then click on the entities. Enable the sensors you want, and disable the sensors you don’t want.
The entity names & IDs will be different from what you had before. You can either change them (via the settings dialog for the entities), or you can adjust your system (frontent, automations, etc.) to use the new IDs.
1 Like
I can’t seem to find a solid answer for this: I see this integration defines daylight as when the solar angle (elevation) is greater than or equal to (>=) -0.833 degrees.
Why that particular choice, or what is the source of that definition?
Here’s why it matters in my case: I have a fair weather sensor and I calculate a percentage of day that it was fair weather. It would never reach 100%, so tonight I started investigating: The daylight sensor for today for my location is given as 14h25 (14.431) for today, yet my fair weather sensor says 14h18. I then calculated the daylight duration by hand looking at the solar angle, and I got 14h18 too – which would’ve given me 100% of fair weather. As a hunch, I did the same calculation at -1 degrees – and got 14h25. That was when I then checked the code and noticed the setting of -0.833. Civil twilight is, for example, -6 degrees, but I can’t find where the other value would come from.
Is - 0.8333 not the angle when sunrise/sunset is determined (see Measurement section)
1 Like
Oh right, so it’s actual vs apparent position of the sun above the horizon. I knew about this difference, but didn’t connect the dots. I checked some other sources which said daylight was when the angle is above 0, but didn’t think to check Wikipedia. Thanks!
1 Like
Apologies in advance if this has been asked before, I’ve briefly gone through the topic and don’t think I’ve seen it come up before: I installed the sun2 integration today, while my HA already had the ‘original’ sun integration.
Now, both coexist, and I only have one sun.xxx entity. If I disable the original sun integration, I have none.
Is there a proper way to ensure I use the sun2 iso sun?
Thanks in advance and best wishes for 2024!
Happy New Year!
The sun2 integration does not create entities in the sun domain (i.e., they are not sun.xxx.) It creates sensor and binary_sensor entities. There are quite a few it creates, and most of them are disabled by default. After you add a sun2 integration entry, click on it, then click on the link to its entities. Enable the ones you want to use and disable the others.
Also, the sun2 integration is in no way dependent on the sun integration. If/when you use the sun2 integration, you can disable or delete the sun integration if you have no use for it. Completely up to you.
1 Like
Thank you very much Phil!
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)?
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.
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.
1 Like
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!!!
4 Likes
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?
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:
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.)
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…
Then yeah, I agree with your assessment…amazing!
I guess I need to go and change my elevation setting in HA now.
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.
2 Likes
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.)
1 Like
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…