I have no plans to add such a sensor. Although the astral package has a “time at elevation” method, it does not have the same for azimuth.
If your plan would be to use the sensor to trigger an automation, then you can just trigger on the azimuth value directly instead I would think.
Azimuth can also be made with a template sensor. Anyway, it is strongly connected to time of day and does not change much through a year. So if accuracy of around 20 minutes is ok, one could also use GMT time.
Apparently, I’ve been remiss in announcing a few bug fix releases:
20240512 Released 3.3.1
Fix processing time_at_elevation config when value is zero
20240531 Released 3.3.2
Move zoneinfo & pytz file I/O to executor
20240813 Released 3.3.3
Fix en translations for nautical_dawn & nautical_dusk
20241030 Released 3.3.4
Fix for breaking change in HA 2024.11
Not sure if anyone caught it, but this integration has a bug that manifests during Daylight Saving Time to Standard Time transitions. E.g., here’s what the elevation sensor looked like during this period:
Notice the hour where it didn’t update correctly. That was during the overlap period after leaving DST.
The root cause is that Python datetime comparisons & math don’t work correctly (or, at least, as expected) for times just before and after this DST → ST transition if the two datetime objects are “aware” and have the same tzinfo object.
E.g., for this comparision:
2024-11-03T01:45:00-05:00 < 2024-11-03T01:15:00-06:00
One would expect the result should be True, since the first time is just before the transition, and the second time is just after. Unfortunately, Python returns False, because it ignores the fold attribute and simply compares the “naive” part of the datetime objects.
Anyway, I’m working on a fix that uses UTC times internally. UTC comparisons & math are not vulnerable to this issue because there are no DST transitions (i.e., fold is never 1.)
P.S. I actually didn’t notice this first. I noticed a related issue with my composite integration, and realized all my integrations that do time comparisons or math are affected. I’m in the process of fixing them all.
Released 3.3.5b0
20241120 3.3.5
Python datetime object comparisons and math don’t work as expected when the objects are aware and have the same tzinfo attribute. Basically, the fold attribute is ignored in this case, which can lead to wrong results.
Avoid this problem by using aware times in UTC internally. Only use local time zone for user visible attributes.
Released 3.4.0b0
Sorry, this was released back in May, but I forgot to announce it here.
Released 3.4.0
Released 3.4.1
Released 3.4.2b0
Phase sensor did not take into account observer elevation settings. This change uses that input to adjust phase changes accordingly. Fixes #137. Also simplifies the implementation of the phase sensor in the process.
Released 3.4.2b1
Same for deCONZ daylight (phase) sensor.
I’ve deleted this release and will hopefully replace it with a fixed release soon.
UPDATE:
Released 3.4.3
Reverts code changes in the 3.4.2 release.
A new release (with a lot more testing!) will hopefully be available soon.
Released 3.4.4b2
Hopefully a properly functioning release that causes the phase & deCONZ daylight sensors to take observer elevation or obstruction into account.
I’ve done a lot more testing this time, but still, it’s very difficult to test every combination of location, time of year, etc. IT WOULD BE GREATLY APPRECIATED to get more feedback from beta testers.
in the HA 2025.12 beta cycle currently, so this is as good a time as ever 
could you indicate what specifically you want to check, (I didnt experience any trouble using the previous beta…)
phase and deconz, fear I wont be much help, having but a simple config for elevation or obstruction.
will check anyways
The beta (3.4.4b2) really only changes the Phase & deCONZ Daylight sensors.
Starting with the 3.4.2 release, I tried to make them take observer elevation into account but ended up breaking them. That change was backed out in the 3.4.3 release. Now I have a different implementation, which hopefully works correctly. I’m hoping to get some people to test them, since last time I got no feedback and ended up creating a bit of a mess. 
I’m considering making a fairly significant change to this integration, and releasing it as 4.0.0 (which would include what I was doing with the 3.4.4 beta.)
When you boil it done, the astral package really has two (effectively inverse) functions: time_at_elevation & solar_elevation (which could also be called elevation_at_time.) The problem, as I’ve noted before, is that these two functions don’t agree very well, probably due to lack of precision or simplifications. E.g.,
solar_elevation(time_at_elevation(X)) != X
Or, to put that another way, the difference between X and solar_elevation(time_at_elevation(X)) is often noticeable.
So, for various sensors, I chose not to use time_at_elevation (for the most part), but rather implemented a (rather crude) method of “searching” the curve resulting from the solar_elevation method for the time that would result in a particular elevation value. The idea was to make sensors that report a time at a given elevation agree with the solar elevation curve.
However, this implementation has two significant problems.
First, many of the astral package’s “built in” methods (such as sunrise, sunset, dawn, dusk, etc.) that are used for many of sun2’s sensors effectively use time_at_elevation (really its underlying method, time_of_transit, that does the grunt work.) So, they generally don’t agree with the solar elevation “curve” (and, hence, the elevation sensor.)
Second, the implementation that “searches” the “elevation curve” is overly complex. Since it’s been around for quite a while, and used by many people, I feel it generally “works”, but still, it probably uses too much CPU time, etc.
So, bottom line, I’m thinking about getting rid of the whole “search the elevation curve” implementation and replacing it with a simple call to time_at_elevation instead.
On the plus side, that would make sensors generally agree, as well as reduce code complexity and CPU usage.
On the negative side, the time_at_elevation method can sometimes return no result (i.e., indicating the sun never reaches that elevation on the given day), when the solar_elevation method for that day would return that elevation value (at some point during that day.)
Anyway, I haven’t completely decided yet, and if I do this, it will take some time, so don’t expect a 4.0.0 beta any time soon.
Mostly, I’m curious what people think about this. Should I do it or not?
I’m using your integration to get the time at elevation as start and stop time for excess charging of my ev. For elevation above 30° rising i start charging and for elevation below 30° setting i stop charging. Outside this window the excess power is insufficient for charging. So i’m o.k. with my use case. Currently i’m getting “unavailable” but that is o.k. I could lower elevation if needed.
Yep, that should work the same way, although you might get unavailable slightly more, although probably not noticeably more. Even with the current implementation, you may be at a location and time of year where the sun just doesn’t rise that high.
BTW, I’m assuming you’re using two “time at elevation” sensors, one for rising and one for setting. Instead, you could use just one binary elevation sensor. It will be “on” when above the elevation threshold (30° in your case), and “off” when below the elevation threshold.
I should also mention, many (if not most) of the sensors use observer elevation already, and I’m adding that to the two different types of phase sensors as well. But, e.g., the binary elevation sensor does NOT use observer elevation. I’m considering also adding that but making it configurable. I.e., you could just care about the absolute elevation of the son, or you may care for it to be relative to your observer elevation (like sunrise, sunset, etc.)
Released 4.0.0b0
Released 4.0.0b1
4.0.0b0:
time_at_elevation astral method instead.4.0.0b1:
Since it is very difficult to test all locations & times of year, both of which affect the operation of these sensors, and since not enough testing was done after the first, failed implementation, I would really appreciate it if people could give this beta release a try AND provide your feedback, good or bad. THANKS!!
Looking for some feedback…
This issue was raised concerning the value of the “point in time” sensors when the corresponding event does not occur during the current day. The current behavior is for the state of the sensor to be unknown.
The request was made to either make it some other value, such as “Not Applicable”, or the next time the event occurs (even if it is days, weeks or months in the future, assuming it does occur at the given location.)
The first option is not possible because these sensors have a “device class” of timestamp, and random string values are not allowed (and would cause an exception.)
The latter option, however, would be possible. However, would that break assumptions such as the value is either sometime today or unknown?
An alternative could be to leave the value as unknown, but to add an attribute that indicates the next time it occurs (assuming, again, that it does.)
Thoughts???
Not one that’d impact me (@ 53N) but I’d prob go for the “next time event occurs” option as think it’d make more sense to me…
I just did a quick implementation that will search ahead up to one year to look for the next “event” (dawn, dusk, etc.), and this is what it looks like for one of the test locations I made:
Note that the yesterday, today & tomorrow attributes show the “raw” values (i.e., not affected by this change.)
