Consider it done.
Ok, 1.2.0 released.
seems to give a config error:
Log Details (ERROR)
Fri Jun 21 2019 23:36:54 GMT+0200 (CEST)
Invalid config for [sensor.sun2]: value is not allowed @ data['monitored_conditions'][0]. Got 'solar_midnight'
value is not allowed @ data['monitored_conditions'][11]. Got 'civil_daylight'
value is not allowed @ data['monitored_conditions'][12]. Got 'nautical_daylight'
value is not allowed @ data['monitored_conditions'][13]. Got 'astronomical_daylight'
value is not allowed @ data['monitored_conditions'][15]. Got 'civil_night'
value is not allowed @ data['monitored_conditions'][16]. Got 'nautical_night'
value is not allowed @ data['monitored_conditions'][17]. Got 'astronomical_night'
value is not allowed @ data['monitored_conditions'][1]. Got 'astronomical_dawn'
value is not allowed @ data['monitored_conditions'][2]. Got 'nautical_dawn'
value is not allowed @ data['monitored_conditions'][8]. Got 'nautical_dusk'
value is not allowed @ data['monitored_conditions'][9]. Got 'astronomical_dusk'. (See ?, line ?). Please check the docs at https://home-assistant.io/components/sensor.sun2/
using:
sensor:
# https://github.com/pnbruckner/ha-sun2
- platform: sun2
entity_namespace: astro
monitored_conditions:
- solar_midnight
- astronomical_dawn
- nautical_dawn
- dawn
- sunrise
- solar_noon
- sunset
- dusk
- nautical_dusk
- astronomical_dusk
- daylight
- civil_daylight
- nautical_daylight
- astronomical_daylight
- night
- civil_night
- nautical_night
- astronomical_night
You have to upgrade and restart for those errors to go away.
sure, Ive loaded the new component, changed the sensor settings, and hit check config. above errors presented. Hit restart: won’t restart because of given errors.
Commented out the offending conditions: config checks alright and restart is happening…
Proof of the new integration being loaded correctly: we’ve got Night!
uncommenting now gives a valid config…
update
that took unusually long, but finally the sensors are there. all except the astronomical ones, that either show ‘Invalid date’ (Atronomical Dusk, Astronomical Dawn), which as I have learned recently means ‘unknown’ using the device_class: timezone, but is an ugly way of telling so. Or they show Unknown (Astronomical Night, Astronomical Daylight)
will hunt for errors in the logs
Updated to the most recent version and everything seems to be working as expected for me. 
1 Like
Just an FYI, that’s to be expected. While HA is still running, even if you load a new version, the old version is still being used (via the __pycache__ folder.) You have to restart (or stop & start) to get the new version to take effect. Of course, while the old version is still running, you have to have a valid config defined by it to pass the config check. So if you change the config for the new version, you’ll fail the config check. And also you can’t restart from the UI, because that won’t restart if the config check fails. But if you leave the config as is so you can restart, as soon as you do you’ll get config errors when the new version takes effect. Kind of a “Catch 22.” In this scenario, where there is a “breaking change” between the versions, you have to stop, change the config, then start.
No need to hunt for errors. Everything seems to be working from what you describe.
Thanks Phil for this new component… I just switched to using it from my learning experience with Python. Works well and thanks for helping us all understand the intricacies of day/night length…
1 Like
This looks good and I finally got round to putting it in my config.
Is there any chance of max_elevation finding it’s way back in?
No big deal if not, I just wondered.
Right now it is just meant to compliment the existing standard sun component. Although I have written it in such a way as to be a basis for which to replace the standard component. So maybe someday…
1 Like
Oh, wait. I was thinking elevation. Yes, I think I can add max_elevation.
1 Like
well except for the astronomical sensors not working… Ive given it a few hours, and a few restarts after that, but give the fact the other sensors load immediately, I would think something is amiss…
We discussed this before. Astronomical sensors are for when the sun is 18° below the horizon, which does not happen at your location at this time of the year (at least.) That’s why you’re seeing none.
O I’ve completely misunderstood that. My pardon.
Wouldn’t it be possible though to have it display another state in that case? This seems very much like a config error. Ill adjust my issue in the GitHub…
Display what?
For the point in time sensors I’m using 'none', which makes sense to me. I can’t help what the frontend does with that.
For period of time sensors, for now I’m using None, which probably displays as 'unknown' as the state, and null as the attributes. I’m thinking about how to scan backwards and forwards (days) for the start and end, if they do exist, but haven’t worked that out yet. In that case I may actually be able to display a time (which would be more than 1 day.) But don’t hold your breath! 
hmm I see, this is the 3d time this week Ive run into a device_class: timestamp sensor showing ‘Invalid date’ because of the state being ‘unknown’.
This could be seen as a bug in the device_class , rather than in the integration of course. I’d rather have it show ‘not available’ (which in this case would probably be the most accurate, or ‘not set’ or something like that, because ‘unknown’ is generally associated with a config error…
Hey Phil, not a biggie, but sensors reporting in hours (decimal hours) isn’t particularly useful (for me anyway). Could you add an attribute showing the same info but with hh:mm:ss as well as h.hhhhhh?
In keeping with the desire to make attributes be as “raw” as possible, that would mean they should actually be Python timedelta’s. Unfortunately, that won’t work because, by default, timedelta’s are not JSON serialize-able, which causes problems with the database. (I ran into this before.) The only way it could work is to convert the timedelta’s to strings, but then they’re not “raw” anymore.
So although I could, I’d rather not, because of the above, and also because then there would be two versions of the same data (and actually three for today, since the state is yet another version.)
Of course you can always modify the code yourself. It is custom after all.
Yeah that’s why I suggested an additional sensor. In the script I was running it just popped out h:mm:ss automatically when I subtracted the 2 dates so not sure why a conversion is necessary? I thought you had to do a conversion to get decimal hours. I am using a template sensor to put it in my desired format anyway so like I said, no biggie.