Device classes have been around for a long time, and new choices are implemented from time to time. I believe they have more to do with internal implementation (backend and frontend), i.e., “behind the scene” details, than something a user should be too concerned about.
It means the entity’s state is one of a known set of values, which are listed (aka, enumerated) in the options attribute.
Released 2.2.0b2 (on 2023-01-05)
Release 2.2.0b3
Normally the elevation sensor updates every 0.5 degrees. Code was added in 2.2.0b0 to add an update when the sun’s elevation crossed -0.833, which is the sunset/sunrise point. However, it was initially done improperly, resulting in multiple updates around that point. This release fixes that issue.
Released 2.2.0
NOTE
FYI, I’ve discovered a race condition in the code. It’s possible at startup for at least the elevation sensor to update initially, and then not update until the next restart. This will only happen if the entity uses the local location configuration (i.e., if latitude, etc. are not specified.) It happens because HA sends a config update signal a few times at startup and the sun2 integration is not handling this completely correctly. I think this bug will manifest rarely, but I’ve experienced it, so it is possible. If you experience this problem, I’d like to hear which type of sensor it happened to. In any case, a HA restart will probably make it work again normally.
I’m working on a fix…
Released 2.2.1
Fixes race condition described above. Also removes state_class from duration (aka “length of time”) sensors in preparation for an upcoming HA release.
Released 2.3.0b1
Added a time_at_elevation sensor. Looks like this:
sensor:
- platform: sun2
monitored_conditions:
- time_at_elevation: -10 # Rising at minus 10 °
- time_at_elevation: 10
direction: setting
icon: mdi:weather-sunset-down
name: Setting past 10 deg above horizon
just to be sure, Phil please let me ask whether I understand this correctly:
-4 is used in my setup for being dark outside, so Id like to test the new functionality on that elevation.
- platform: sun2
monitored_conditions:
- time_at_elevation: -4 # Rising at minus 4 °
name: 'Time at Dark outside off'
- time_at_elevation: -4
direction: setting
icon: mdi:weather-sunset-down
name: 'Time at Dark outside on' #Setting past -4 deg below horizon
would that give me 2 sensors for crossing the -4 threshold in either direction correctly? No need to use a nvm the last, I just saw Add time_at_elevation point-in-time sensor by pnbruckner · Pull Request #76 · pnbruckner/ha-sun2 · GitHub which states as muchdirection: rising option on the top sensor (is default?),
edit
yes it is 
beautiful!
I think I’ll change the default icon to mdi:weather-sunset-up if direction is rising, and mdi:weather-sunset-down if direction is setting.
Released 2.3.0b2
Base default icon on direction setting.
hey Phil,
Nice touch
speaking about eye candy, why not add an icon for the integration too?
I’ve been thinking of doing that. I did recently for my composite integration. Just need to find a reasonable image.
hehe, yes, I guess it boils down how adventurous you want it to be, a quick google search on astral sun image icon - Google Search doesn’t really narrow down your options…
Oh, I don’t know. I think I found a good one via that search. Thanks!
UPDATE:
yep. looking sunny and happy. thanks Phil, always a pleasure
Has anyone seen errors related to some of the “point in time” sensors, such as astronomical_dawn, especially during the winter or summer? It seems some changes to the core software, possibly as far back as 2021.12, can cause exceptions with these sun2 sensors, but I only recently had the issue reported.
Released 2.2.2 & 2.3.0b3
These releases address the issue mentioned above.
Specifically, if the event for a “point in time” sensor (such as astronomical_dusk) does not occur during the current day, the sensor used to attempt to set its state to “none”. Prior to HA 2021.12 this used to work. But starting with that release, since the sensor has a device class of timestamp, that value is not allowed, which can cause an exception. Further, if that exception happens during startup (i.e., the event does not occur on the day HA is (re)started), the sensor will not get created normally, and instead will have the value “unavailable”.
Now, for days on which the event does not occur, the sensor’s state will be “unknown” (which, internally, is represented with the Python value None.)
Dear Phil,
thanks for keeping this up to date! Ive just noticed that my config (using time_at_elevation) is no longer documented
- platform: sun2
entity_namespace: Astral
monitored_conditions:
- time_at_elevation: -4 # Rising at minus 4 °
name: 'Time at Dark outside off'
- time_at_elevation: -4
direction: setting
icon: mdi:weather-sunset-down
name: 'Time at Dark outside on' #Setting past -4 deg below horizon
is that piece of documentation moved, or was it never there…
the entities are created alright, so I was a bit puzzled…
btw, have no unknown/unavailables yet so maybe didnt watch closely enough, and will keep an eye out for that now.
That feature is, as of yet, still considered beta. It is available if you use 2.3.0b3. (If you note above, the fix for the point-in-time sensors was released in both 2.2.2 and 2.3.0b3.) I probably need to go ahead and release that feature fully, but just haven’t spent the time to do so.
UPDATE: The manifest.json file for the beta release points to the corresponding documentation, which is:
ha-sun2/README.md at time_at_elevation · pnbruckner/ha-sun2 · GitHub
Released 2.3.0
Sorry it’s taken so long, but I finally fully released the new time_at_elevation sensor.
Just for clarification, as it didn’t come up in the last 50 posts or so:
Thank you for that component, it’s so much better than the original! 
