Dusk appears to be correct now, but night is only 1.711 hrs. That could be true for astronomical dusk and dawn, but I would expect it to be civil dusk and dawn which are a little over 6 hrs apart this time of year.
Glad to hear it’s working for you. Regarding night, I just used the default, which is defined as “The amount of time between astronomical dusk and astronomical dawn of the next day.” Honestly, I’m not fully versed on all the details. Just trying to provide a reasonable interface to the astral functions. If you and others feel strongly that I should change night, by all means, let me know.
I don’t really care how long night is, but I’m much more interested in how long day is and “daylight” does seem to be the period between civil dawn and civil dusk, which for consistency’s sake, I guess night should be the period between civil dusk and civil dawn.
Before HA arrived I used astral to calculate nautical dusk and dawn, which seemed to be closer to when I actually would want lights on and off. I currently use a value for solar elevation for dusk and dawn, which is closer to nautical dusk and dawn, than civil dusk and dawn, so I guess offsets and/or elevation would be a nice feature to add at some point. Thanks for your hard work on this.
I get just over 3 hours report by sensor.night. Technically speaking, that’s correct given that I’m in the northern hemisphere, today is June 20th, and ‘night’ is defined as the period between astronomical dusk and astronomical dawn.
For the purposes of home automation, the astronomical definition of ‘night’ is of limited use (unless you want to know when it’s best to go star-gazing). Yes, it means it is dark outside, as dark as it’s ever going to get. However, the twilight periods flanking astronomical night, namely civil and nautical dusk and dawn, are dim (nautical more so than civil). The problem is that it’s hard to pin down one definition of ‘night’ suitable for home automation use.
My own preference for ‘night’ would span from nautical dusk to nautical dawn. For others it might be only loosely related to the sun and more about lifestyle where ‘night’ is anything later than 21:00 and before 06:00.
FWIW, I’d leave it the way it is. At least it adheres to a generally accepted definition of ‘night’, even though it may not be very useful for home automation purposes.
(But I wouldn’t complain if you changed it to represent the period between nautical dusk and dawn)
BTW, installing a custom-component by copying files into a new folder is not hard but I just used HACS and it made me think “It should’ve always been this easy!”
1 Like
To me, it sounds like these are all potential monitored conditions. Keep em all!
1 Like
Since which sensors are created is configurable anyway (where people would only use the ones they cared about), would it make sense to have something like the following options?
daylight = between Sunrise/Sunset, -0.833°, same as before
civil_daylight = between Civil dawn/dusk, -6°
nautical_daylight = between Nautical dawn/dusk, -12°
astronomical_daylight = between Astronomical dawn/dusk, -18°
astronomical_night = between Astronomical dusk/dawn, -18°, what night used to be
nautical_night = between Nautical dusk/dawn, -12°
civil_night = between Civil dusk/dawn, -6°
night = between Sunset/Sunrise, -0.833°
Would that make sense to people? (Of course I’d add definitions on the doc page.)
On the plus side:
daylight + night = 24 hrs
civil_daylight + civil_night = 24 hrs
nautical_daylight + nautical_night = 24 hrs
astronomical_daylight + astronomical_night = 24 hrs
I like that it’s symmetrical and the names seem to correspond (mostly) to dawn/dusk terms. (I.e., civil_daylight and civil_night are between Civil dawn & dusk.)
The only downside I can see is night is not how “Night” is apparently normally defined.
1 Like
Seems reasonable.
1 Like
thanks Phil,
sorry to report though the Night sensor still shows Unknown…
dawn and noon still few seconds off I am afraid
no errors in the log this time yet.
Are you using 1.1.1? And restarted?
I wasn’t sure it would address the issue of night being all None’s (aka null/unknown. I figured it fix the exceptions, though.) I was hoping solar_depression not being set would have been the root cause for this, too.
Hmm, not sure what to do. I’m getting exactly the same results as the standard sun now.
Wait, exactly what are you using in that second box? Is that my original custom sun? If so, maybe that’s the problem. (Maybe it has a bug that has since been fixed in the standard component.) Any chance you could (at least temporarily) go back to use the standard sun component and see if my sun2 results agree with it (at least for the matching types/days)?
The only thing I can think of doing at this point would be for me to test with your HA config, specifically latitude, longitude, elevation & time zone. If you’re willing you could send them to me via a PM, or e-mail or something. Totally up to you. I certainly understand if you’d rather not.
yes, downloaded a fresh and restarted.
yes indeed, never use the native sun.sun 
sure, will do.
np, Pm in your mailbox
update
still off with native sun.sun for dawn, dusk is fine, noon is off
Passes on my end.
| * | sun2 (tomorrow) | sun (next_*) |
|---|---|---|
| dawn | 1561107184.0 | 1561107184.0 |
| dusk | 1561166995.0 | 1561166995.0 |
| sunrise | 1561109324.0 | 1561109324.0 |
| sunset | 1561164855.0 | 1561164855.0 |
Everything also has a value
sensor.dawn
yesterday = 2019-06-19 04:52:46-04:00
today = 2019-06-20 04:52:54-04:00
tomorrow = 2019-06-21 04:53:04-04:00
sensor.daylight
yesterday = 15.421388888888888
today = 15.424166666666666
tomorrow = 15.425277777777778
sensor.dusk
yesterday = 2019-06-19 21:29:21-04:00
today = 2019-06-20 21:29:39-04:00
tomorrow = 2019-06-21 21:29:55-04:00
sensor.night
yesterday = 3.898888888888889
today = 3.894722222222222
tomorrow = 3.8930555555555557
sensor.solar_noon
yesterday = 2019-06-19 13:11:03-04:00
today = 2019-06-20 13:11:16-04:00
tomorrow = 2019-06-21 13:11:30-04:00
sensor.sunrise
yesterday = 2019-06-19 05:28:25-04:00
today = 2019-06-20 05:28:33-04:00
tomorrow = 2019-06-21 05:28:44-04:00
sensor.sunset
yesterday = 2019-06-19 20:53:42-04:00
today = 2019-06-20 20:54:00-04:00
tomorrow = 2019-06-21 20:54:15-04:00
1 Like
Thanks! I’ll let you know what I find.
No, not really. They all agree.
is the same as
And
is the same as
I am really sorry…causing all this confusion.
I checked sun2. sensors state and not attribute against sun.sun attributes, hence the few seconds Off… as it was supposed to be.
Sorry again.
Hope you can find the midnight issue though, because that is still here, even after reinstalling sun2 and several restarts/clean cache.
btw does this interfere in any way: Reset location elevation back to civil after updating sun by Swamp-Ig · Pull Request #24612 · home-assistant/core · GitHub
do have another question though…:
trying your daylight template few posts above works fine:
daylight_delta_yesterday:
friendly_name: Daylight delta yesterday
value_template: >
{{((state_attr('sensor.sun2_daylight','today') -
state_attr('sensor.sun2_daylight','yesterday'))*3600)|round(1)}}
daylight_delta_tomorrow:
friendly_name: Daylight delta tomorrow
value_template: >
{{((state_attr('sensor.sun2_daylight','tomorrow') -
state_attr('sensor.sun2_daylight','today'))*3600)|round(1)}}
but trying to do that for tomorrow yields ‘0’.
Now I know I am experimenting on the first day of Summer, being the longest day, but I thought id better ask whether this is correct?
I’m seeing zero difference in day length for tomorrow. Today is 4 seconds.
That’s because the value is the same… June 21st is the longest day of the year from what I remember. This is expected 
Yeah that’s what I was alluding to.
1 Like
right, I expected as much, but never really realized it was precise up to the second …
proves the integration’s calculation is pitch perfect ;-
Only thing left is my missing Night. Hope HA isn’t as intelligent to spot that’s the time my HA tinkering is most frequent…
lol! No, I don’t think it’s that. Here is the issue:
astral.AstralError: Sun never reaches 18 degrees below the horizon, at this location.
FWIW, I think I’m going to change the state (& attributes) back specifically to 'none' in this case. Leaving them as None gets displayed misleadingly – 'unknown' for state, and null for attributes.
but would that give me a Night? It s not so much that I didn’t like the display of the state, but more the fact it wasn’t calculated at all?? as you wrote here: Enhanced Sun component it should be Night between sunset/sunrise, or maybe even better between Dusk/Dawn
period_of_day:
friendly_name: 'Period of the day'
value_template: >
{% if (as_timestamp(state_attr('sun.sun','next_dusk'))) -
(as_timestamp(state_attr('sun.sun','next_setting'))) < 0 %} Dusk
{% elif (as_timestamp(state_attr('sun.sun','next_rising'))) -
(as_timestamp(state_attr('sun.sun','next_dawn'))) < 0 %} Dawn
{% elif (state_attr('sun.sun', 'elevation')) < 0 %} Night
{% else %} Day
{% endif %}
icon_template: >
{% if is_state('sensor.period_of_day','Dusk') %} mdi:weather-sunset-down
{% elif is_state('sensor.period_of_day','Dawn') %} mdi:weather-sunset-up
{% elif is_state('sensor.period_of_day','Night') %} mdi:weather-night
{% else %} mdi:weather-sunny
{% endif %}