Fair enough. I guessed it was something like that.
So are you calculating those things or just pulling them out of Astral? I am calculating the day lengths in my python script as the ‘standard’ query doesn’t include it and it seemed more trouble than it was worth pulling out the data directly but I guess you are doing that so it’s puzzling theres a discrepancy…
Just using the astral functions. Actually, for daylight and night the astral functions return start & end datetimes, so I am subtracting them and converting to hours, but that’s the extent of my “calculations.” 
Also, FWIW, I’m only using astral’s Location class (directly. It’s creating an Astral class “behind the scenes.”) This is the same as what the standard sun component and its helper do. And although we are using it slightly differently, I thought they should end up with the same results. But obviously that’s not happening, so I have some head scratching to do…
Odd… I’m only using the location class as well. I can’t check now but I didn’t see start/end in that class… I’ll have a look tomorrow.
@froz @DavidFW1960 @Mariusthvdb
I think I may have figured it out and fixed it. I’ll do some more testing today, and if it seems to check out ok I’ll release a new version. Thanks again for testing and providing feekback!!
this might be it:
Log Details (ERROR)
Thu Jun 20 2019 14:01:26 GMT+0200 (CEST)
Update for sensor.sun2_night fails
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 220, in async_update_ha_state
await self.async_device_update()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 375, in async_device_update
await self.async_update()
File "/config/custom_components/sun2/sensor.py", line 137, in async_update
self._state = round(self._today, 3)
TypeError: type str doesn't define __round__ method
Dusk seems alright, dawn and noon are few seconds off:
I’ll implement it tonight to test for ya. I’ll even make a template sensor or 2 using the dates.
self._today is somehow getting populated with a string.
@Mariusthvdb @petro @DavidFW1960
The exception is due to a bug which I’ve since fixed.
In general, the data was wrong because I was taking a shortcut that I shouldn’t have. The astral Location class automatically creates an astral Astral object, which as a solar_depression property. Apparently after I create the Location object I’m supposed to set the solar_depression to ‘civil’ before calling the other functions. But in the bit of testing I did I discovered (at least under some circumstances) the solar_depression property seemed to be defaulting to the equivalent of ‘civil’, so I didn’t bother setting it. Well, apparently this doesn’t always work that way. I added a line to set solar_depression explicitly, and now I’m getting the exact same results as the standard sun component (well, at least for the one day the standard component calculates the values for.)
I want to spend a little more time with it and should release a fixed version later today.
@DavidFW1960 @finity @petro @123 @klogg @Mariusthvdb @froz, et al:
Released 1.1.1 which should hopefully fix the observed problems. 
Let me know!
1 Like
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
