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 %}
Note the “whatnightused to be” part. In the current implementation night is between Astronomical dusk/dawn. But it will be:
BTW, for types like daylight & night, which are numbers of hours, I should probably make them 0.0 in this case, rather than 'none'. That probably makes more sense.
I’m working on a new version (to implement the sensor types in the post you referenced), but it will take a while.
I overlooked to mention that I agree with your proposed definitions. Even though your version of night doesn’t jibe with Astral’s version (astronomical night), it’s probably a better fit with what many people consider to be ‘night’ (that period between sunset and sunrise).
Yes, I’ve read that, but please let me ask to be certain of what you’ve written: you will also support:
`nautical_night` = between Nautical dusk/dawn, -12°
`civil_night` = between Civil dusk/dawn, -6
Which I would template out for sure then in my config.
Personally I find the new definition of Night way too wide, being the period between Sunset and Sunrise. I am a nature kinda guy, and feel that there is a great distinction between evening, dusk, night, and dawn … which in the new setting all would be Night? Not even Evening and Morning
Follow the song of the birds and you know what I mean…
This is what I’m currently attempting to implement:
There will be two types of sensors: ones that provide points in time, and ones that will provide lengths of time. All sensors with have yesterday, today and tomorrow attributes, which will be as “raw” as possible (either a Python aware datetime in the local time zone, or a non-rounded float in hours), and the state will be a “prettier” version of the today attribute (for point in time types the datetime will be converted to a string in ISO format, and the others will be rounded to 3 decimal places and, of course, also converted to a string.)
The list of options for the “point in time” type will be:
solar_midnight
dawn
sunrise
solar_noon
sunset
dusk
The dawn and dusk sensors will be “civil”. I could be talked into providing astronomical & nautical versions of dawn & dusk as well.
The list of options for the “length of time” type will be:
daylight - from sunrise to sunset (-0.833°)
civil_daylight - from civil dawn to civil dusk (-6°)
nautical_daylight - from nautical dawn to nautical dusk (-12°)
astronomical_daylight - from astronomical dawn to astronomical dusk (-18°)
night - from sunset to tomorrow’s sunrise (-0.833°)
civil_night - from civil dusk to tomorrow’s civil dawn (-6°)
nautical_night - from nautical dusk to tomorrow’s nautical dawn (-12°)
astronomical_night - from astronomical dusk to tomorrow’s astronomical dawn (-18°)
To be clear, these don’t indicate when the time is in these periods, they are simply the length of these periods.
Also, right now the plan is to have these all update 1) when HA starts, 2) if HA’s location configuration changes, and 3) at local midnight.
So, not really worried about how the current version works. I’m more concerned with making something reasonable, even if it means the next release will be a “breaking change.”
great, if I misunderstood that before, this is way precise, and what I would have hoped for.
well, I hope you don’t get me wrong, and having read my earlier request, please let me talk you into it, not pushing in any way, and only if you see it fit because of added value. I would certainly appreciate it
Agree all of what you stated after that, provided I fully grasp what it means here and there, have to read up on some specifics…
and
its not as much a time period, more of a behavior or consideration to paraphrase your words. I would consider Evening the end of the day, lets say beginning with sunset, and including dusk. Most importantly the song of the blackbird…or nightingale for that matter.
All silent makes it a night (that is, I don’t live in a rainforest, so please forgive me its not a universal definition), and the hedgehogs walk.
Same would go for morning, starting from dawn, until Noon. Of course, get up at 5 and hear the same songs echoing and you get the feeling. Replace Nightingale for a whole army of morning whistlers.
The only thing in my proposed definitions that seems to go against established norms, and that picture, is the definition of night. As I stated above, I’ll use the sensor type of astronomical_night to correspond to what is usually meant by night, and I’ll use night to mean 24 hr - daylight. It’s a trade-off to make things more symmetrical.
You have my vote. Using the astronomical definition of night would be technically correct but your repo willl be buried in Issues complaining about “How can night possibly be only 3 hours long??”
EDIT
I’m still of the opinion that you should expose Astral’s moon phases and then call the whole shebang the astro component. That way there’s no way to confuse it with the stock sun component nor with your customized sun component. So rather than rolling it out as a ‘breaking change’ version of your custom sun component, you can say it is now deprecated and superseded by the new astro component.
and hedgehogs roam. 
