Phil, any chance you could do a custom component just to get those attributes in? (the missing ones)?
I’ll look into it. It wouldn’t be as fancy/flexible as what I did before. It would be basically starting over with the existing standard component. Exactly which attributes would you want added (besides sunrise & sunset)?
BTW, not sure how you figured it out, but Penny#7205 on discord does seem to be Swamp-Ig on github who has taken ownership of the sun component.
FWIW, I’ve used two home automation programs since 2006. First it was MisterHouse and then Premise (10+ years with Premise). In both programs, sunrise and sunset mean today’s sunrise and sunset. Thirteen years of garden-variety lighting automations based on today’s sunrise and sunset.
I was surprised to learn how Home Assistant handles this cornerstone of most lighting automations. Frankly, over the last 13 years, I never thought “What this automation needs is tomorrow’s sunrise/sunset.”
3 Likes
So I actually made a bash script that calls a python script (uses Astral) and gets the sunrise/sunset data yesterday/today/tomorrow. Problem is that astral (the python module) is not available in the HA container so it won’t work with hassOS but works on anything else.
I’m happy to share it if it’s of interest.
To be fair, sunrise & sunset, including offsets, are available in automation triggers and conditions (and really have nothing to do with the sun component, other than using common subroutines.) The problems start when one does something a bit more involved and needs to write template triggers or conditions. Then, all of a sudden, sunrise & sunset aren’t available anymore. 
I certainly understand why the current sun component has next_rising and next_setting attributes. They’re really strictly for the UI. But that doesn’t explain why it doesn’t have attributes for today’s sunrise and sunset, and I don’t understand why nobody on the core team seems willing to acknowledge that it should and will accept adding them in the current implementation, even if it isn’t what it ultimately should be.
That doesn’t make sense. It should definitely be there. Is there a venv for HA that maybe you need to activate first? Or why don’t you just install it, e.g., python3 -m pip install --user astral? I guess I don’t know the constraints of whatever type of install you’re using.
Anyway, what I’m thinking of doing, instead of making a custom version of the existing sun component, is to make a new integration (say, call it sun2) that uses a monitored_conditions config variable (like I did before), but instead of using that to selectively create attributes, use it to selectively create sensors, which is what I think balloob was wanting. E.g., let’s say you pick sunrise, it would create sensor.sunrise, whose state would be today’s sunrise (an aware datetime in the local timezone, converted to a string in ISO format.) Then it could also have attributes for yesterday’s and tomorrow’s sunrises.
What do you think?
1 Like
I remember balloob wanting it like monitored conditions. I.E. each monitored condition would create a new sensor, separate from sun.sun.
1 Like
@DavidFW1960 @finity @petro @123 @klogg, et al:
So this is what I came up with. Here is the config:
sensor:
- platform: sun2
monitored_conditions:
- dawn
- daylight
- dusk
- night
- solar_noon
- sunrise
- sunset
And here is what the entities look like:
and:
All the datetimes, including attributes, are in local time zone and expressed as a string in ISO format. These work with the as_timestamp template function.
Daylight and Night are in hours, where the state is, of course, a string (which can be changed with the |float filter), and the attributes are floats. I rounded to 2 decimal places.
Let me know what you think and if I should change anything. If this looks ok I’ll create a repo to put it in that’s compatible with HACS and share the link.
5 Likes
Wow, that was fast!
It looks great to me. I like that you can now have both of the components in your config so you get the benefits of both.
I still say if you could come up with an entirely new component in less than a day then it makes no sense for this stuff to not be included in the standard component.
thanks, again. You are a scholar and a gentleman. 
I suspect that something like this is what they’d like to scrap the current sun component for. All that’s left to do is to add some of the existing types, like azimuth/elevation, possibly even next_rising & next_setting, with their slightly more complicated update methods. I just implemented the “low hanging fruit”, especially since they aren’t part of the existing standard component.
Once I do a bit more testing, and after I publish it in a HACS-compliant repo, I might point balloob & Penny at it in case they’d like to plagiarize. 
That looks great. Add information about seasons and the moon and then you can call it the astro component (astronomical) like openHAB’s astro binding:
2 Likes
Ok, release 1.0.0 available here:
I may have to find a reason to use this. I’ve always wanted to have my instance know the time of day but I never bothered making it.
that’s a pretty good idea. It would then combine several different components into one.
1 Like
It’s one of the things I liked in openHAB. Its astro binding (a.k.a. component) is a one-stop shop for all things related to the sun and moon.
FWIW, it even reports solar eclipse data, solar radiation, lunar apogee/perigee, and even signs of the zodiac. I’m not sure how astrology fits into home automation but, yeah, even the zodiac. Honestly, I can’t think of many uses for those extras (maybe lunar apogee/perigee is used for tides).
If anyone gives the new sun2 integration a try, let me know how it works for you.
HACS won’t install it. Error is no suitable js files found
Did you set the type correctly?
Once again you save the day…and night : D
Just my 2c, maybe prefix the sensor name with sensor. solar_XYZ or sensor.astro_XYZ.
So much easier to see all the sensors in the browser at once.