Enhanced Sun component

Share your Projects! Custom Integrations
148

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
149

I remember balloob wanting it like monitored conditions. I.E. each monitored condition would create a new sensor, separate from sun.sun.

1 Like
150

@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:

image
image627×811 67.2 KB

and:

image

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
151

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. :slightly_smiling_face:

152

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. :slight_smile:

153

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
154

Ok, release 1.0.0 available here:

155

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.

156

that’s a pretty good idea. It would then combine several different components into one.

1 Like
157

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).

158

If anyone gives the new sun2 integration a try, let me know how it works for you.

159

HACS won’t install it. Error is no suitable js files found

160

Did you set the type correctly?

161

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.

162

Yes, but it is an integration and I tried plugin. Now it installed

1 Like
163

I suppose I could add an optional prefix config variable, which defaults to none. Personally I like sensor.sunrise, sensor.sunset, etc. But I see your point.

EDIT: https://github.com/pnbruckner/ha-sun2/issues/1

EDIT 2: Turns out, there’s already a standard way to do this via the entity_namespace configuration variable.

1 Like
164

Something is off in the time conversions. I have dusk at 19:20 and sunset at 21:11, which is correct, but the converted times say dusk in 10 hours and sunset in 7 hours. All times PDT (-7)

165

Dusk, I would think, should come after sunset. So the relative times for sunset and dusk seem about right. Also the sunset time looks about right. But the dusk time definitely does not look right. Are you sure you read it correctly?

EDIT: FWIW, this is what I’m seeing:

dawn    2019-06-19T03:05:47-05:00 12 hours ago
sunrise 2019-06-19T05:17:02-05:00 10 hours ago
sunset  2019-06-19T20:30:59-05:00 In 4 hours
dusk    2019-06-19T22:42:14-05:00 In 6 hours

All times CDT (-5)

166

Hi please don’t delete the existing repo.

I don’t care that it is effectively unsupported, I understand that this is ‘use at my own risk and it may not work in future HA versions’. It is working great for me and I use to perform an automation that e-mails me solar stats on sunset every day.

Also FWIW, I think having sun2 may be cause confusion, as our solar system only has a single sun :smiley:

The astro: name makes more sense to me.

167

lol!

No plans to do that.