So I think I have it working reasonably well. The goal is to update the sensor when the elevation changes to the next whole integer degree, although the state is the “raw” elevation rounded to one decimal point, mainly because there are some boundary conditions that have to be handled specially. I wrote a program to test the algorithm and ran it through a simulated cycle of three days for my location and the numbers look good. I converted that into the actual custom integration code and now I’m testing it “live.” Tomorrow I’ll probably try to run the test program for various interesting days throughout the year for my location, and then maybe try a few other interesting locations. If all goes well I’ll check the change in and release it.
2 Likes
@maurizio53 I’m still working on it. I’ve found a better way to implement it, and I think I can still improve it a bit more. And once I like it I’ll probably add azimuth, too.
I have a question, though. Do you think one degree resolution is good enough, or should I make it 1/2 degree? I’ve actually implemented both. Making the resolution smaller just means it will update more often. For my location with 1/2 degree resolution for the most part it updates every 3 or 4 minutes, whereas with 1 degree resolution it obviously updates about half as often. I guess it depends on the use case, but I’m thinking, will anyone really need 0.5 degree resolution?
Hmm, it just hit me. If the use case is determining when the elevation goes above/below a certain threshold, then that can be done much more easily and accurately by implementing a binary_sensor with a configurable threshold. Then it just has to update twice a day – once when the sun goes above that elevation and then again when it goes below. And a sensor like this would use way less CPU resource. Hmm… 
Oh, i think it’s up to you and I will use it following your docs, but using less CPU resources for who uses raspberry is a very important thing… Actually I use also 1/2 degree in my automations but I can quietly change them accordingly to the component.
Ok, I think I’m pretty happy with the current implementation. It updates at each 1/2 degree change (and tries to be as close to x.0 & x.5 as possible.) So this differs from the current sun component’s implementation in that it updates as necessary, not just on a fixed schedule (where the schedule changes during the day/night.) Here is what my integration does:
And here is what the standard sun component does:
And the difference between them looks like this:
You’ll see that the amount of difference varies throughout the day. This is due to the way the standard sun component works – i.e., it changes how often it updates throughout the day, updating very infrequently during the night. Also note that the differences are not due to errors. It’s strictly a function of when these two update – mine updates as close to 0.5 multiples as possible, whereas the standard component updates on a fix schedule and will hence update at fairly random points relative to elevation.
I think I’ll check in what I have and release it, probably later today.
I’ve also tested the concept of creating a binary_sensor that will update whenever elevation crosses a configurable threshold. I.e., when HA first starts it will update immediately and be 'on' or 'off' based on whether the sun is above or below the specified elevation, respectively. It will then not update until the sun crosses the threshold again. So normally it will update twice a day - when the sun goes above the threshold (and change to 'on') and when the sun goes below the threshold (and change to 'off'.) It even works in the case where the threshold is not reached during parts of the year. In this case it may not update for days, weeks or months (and will output a warning stating so.) And if the threshold is never crossed, it will just update once at startup and then output an error stating it won’t update again. Now I just need to actually write the binary_sensor.py file (based on my test code.)
1 Like
Released sun2 1.4.0
Adds option for elevation.
The latest version is failing to install via HACS. It seems to be re-installing 1.3
it installed 1.4.0 for me and it’s working correctly with new sensors
Not me. I had to install 1.4.0 manually to get the elevation sensor and HACS still indicates I have 1.3.0 installed with an available update to 1.4.0 and if I update it does indeed reinstall 1.3.0 again.
Updated: I fixed it by hand-editing the hacs.* files in .storage. Must be some HACS weirdness after the big update.
Too late now but maybe using the reload
might have fixed it…
I did all that first
HACS 
For anyone that might be interested, I think I have the binary_sensor for elevation working. You configure it like this:
binary_sensor:
- platform: sun2
monitored_conditions:
- type: elevation
name: <name> # optional
above: <threshold> # optional
You can create as many as you like. If you don’t specify a threshold it defaults to -0.833, the same as sunrise/sunset. Also the default name is “Above Horizon” if above is -0.833, or “Above N” (where the N part will be “minus N” if it’s negative), resulting in an entity_id like binary_sensor.above_horizon, or binary_sensor.above_3 or binary_sensor.above_minus_5_125.
The idea is it will change to 'on' whenever the sun’s elevation becomes a value above the threshold, and change to 'off' whenever the sun’s elevation becomes the threshold (or lower.)
When HA starts the state is set accordingly. Now here’s where the main reason for doing this comes in. It will then calculate when it should change next, and not update until then. I.e., it figures out exactly when it should change, rather than constantly comparing a value against a periodically updating sensor. The result is it’s much more efficient, and it changes right when it needs to, not on some sample point that might be minutes from when the threshold was actually reached.
Now, in the grand scheme of things, maybe these advantages aren’t all that important or significant. However, one big advantage might be that you don’t need to create any other sun related entities (whether that be sun.sun or any of my sun2 entities) for this to work. It’s completely stand-alone. So, if all you care about is knowing when the sun is above a certain elevation, possibly for use in an automation trigger and/or condition, then this can be much less of a burden on the system (and database) because you don’t need any of the sun entities that change a lot during the day. (Now, of course, if you do want to display elevation, etc., that’s another story. 
)
Thoughts?
4 Likes
HI Phil,
Thanks for this! please let me ask if I understand correctly and could use:
binary_sensor:
- platform: sun2
monitored_conditions:
- type: elevation
name: Sun is up # optional
# above: <threshold> # optional
using the default elevation threshold and still feel all the relieve for the system? Or would I need to specify the threshold to benefit from your new binary_sensor.
btw, this is already working with version 1.4? Because I see:
Hi Marius,
Yes, that configuration would be perfectly acceptable and would create binary_sensor.sun_is_up that changes around -0.833 degrees.
This entity does not depend on sun.sun, nor any of the other sun2 sensors. So, to “feel all the relieve” you’d need to remove those (or at least any you don’t otherwise need or want) from your configuration.
I’ll also state, automation sun triggers and conditions are completely independent as well, meaning they don’t depend on sun.sun either.
Does that answer your questions?
Thanks!
glad I got it right 
Understand about taking out the other stuff.
only issue left is the error message…
Oh, sorry, meant to answer that, too. No, it’s not in the release yet.
Before releasing I’m trying to decide whether or not to include a next_change attribute, for this binary sensor as well as the elevation regular sensor, since both are implemented by figuring out when they should update next. It looks like this:
You can see that the -60 binary sensor will update next later today, the -70 won’t until Nov. 29 (when the sun finally dips below -70), and the -80 won’t at all (since the sun’s elevation never gets to -80 here.)
Do you think this attribute would be useful? Or would it just take up more space in the database for no good reason?
I think it would be useful and I would configure logger not to add to db as well.
1 Like
Nice going with this!
As a side note, would it be a good idea to also track the moon, and its phases ?
This way, the custom card, Lovelace: Sun Card could display the moon.
Basically making this a sun and moon integration.
Just my 2 cents.
Cheers.
If you (or anyone) would like to give the new stuff a try (before I release it), you can find it on this github branch. I’ve simplified the config for the elevation binary sensor a bit. See the doc for details.
FWIW, the config you posted above would now look like this:
binary_sensor:
- platform: sun2
monitored_conditions:
- elevation:
name: Sun is up
Thanks! 
Yes, that has been asked for before. I just haven’t spent any time looking at it yet, other than to check that the astral package does indeed have a moon_phase() method. But that seems to be the extent of moon related functionality.
I wasn’t aware of that custom card.