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