Use UTC datetimes internally

What's Changed

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

Full Changelog: 3.3.4...3.3.5

Fix for breaking change in HA 2024.11

What's Changed

• Class Config was moved from homeassistant.core to homeassistant.core_config.

Full Changelog: 3.3.3...3.3.4

Fix en translations for nautical_dawn & nautical_dusk

What's Changed

• Fix English translation of deconz_daylight sensor's states of nautical_dawn & nautical_dusk.

Full Changelog: 3.3.2...3.3.3

Move zoneinfo & pytz file I/O to executor

What's Changed

• Move zoneinfo & pytz file I/O to executor by @pnbruckner in #126

HA 2024.6 adds a check for this type of file I/O happening in the event loop. This release fixes the problem and avoids the WARNING in 2024.6.

Full Changelog: 3.3.1...3.3.2

Fix processing time_at_elevation config when value is zero (#124)

If time_at_elevation was zero, it would cause the following error:

Logger: homeassistant.components.sensor
Source: helpers/entity_platform.py:356
integration: Sensor (documentation, issues)
First occurred: 2:06:28 PM (1 occurrences)
Last logged: 2:06:28 PM

Error while setting up sun2 platform for sensor
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 356, in _async_setup_platform
    await asyncio.shield(awaitable)
  File "/config/custom_components/sun2/helpers.py", line 513, in async_setup_entry
    cls(hass, entry, async_add_entities)
  File "/config/custom_components/sun2/helpers.py", line 417, in __init__
    self._entities = list(self._get_entities())
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/sun2/sensor.py", line 1217, in _config_sensors
    raise ValueError(f"Unexpected sensor config: {config}")
ValueError: Unexpected sensor config: {'unique_id': 'sa3', 'time_at_elevation': 0.0, 'direction': 'rising', 'name': 'sa3', 'icon': 'mdi:weather-sunset-up'}

This release fixes that problem

Allow more flexible configuration of what affects sunrise & sunset events

Add elevation option for observer obstruction vs horizon

The astral package this integration uses can accept two different types of data for certain events like sunrise & sunset to describe where these events are seen relative to the observer.

The first, which has been the only supported option so far, is the horizon. In this case, the elevation of the observer relative to ground level defines how much to adjust the event by due to the curvature of the Earth.

The second is an obstruction, such as the top of a mountain. This is defined by the horizontal distance to the obstruction, and the height of the obstruction relative to the observer (both expressed in meters), which can be negative if the obstruction is lower than the observer (e.g., the observer is on an even higher mountain.)

It is now possible to define either type for easterly events (sunrise, dawn) and westerly events (sunset, dusk.) Note also that the old elevation config option has been deprecated by the new observer_elevation option, and both are no longer associated with the location options (latitude, etc.), and hence, can be specified independently.

Add services & sensors

Add sun2.get_location & sun2.update_location services. Also add sunrise_azimuth & sunset_azimuth sensor options.

Together these allow dynamically updating location parameters, such as latitude, longitude and time zone, and/or parameters that define what affects sunrise & sunset events.

One use case might be for vacation. Let's say you add a config entry to get sun related info for a vacation location. You can use the services to update its location maybe once a day, or when you push a button in the UI, based on the current location indicated by a device tracker entity.

Another use case might be when, e.g., sunrise is based on a mountain, but the distance to, and the relative height of, the top of that mountain changes throughout the year as the sunrise azimuth changes.

Only reload config entry if it's in a state where it can be reloaded

Depending on startup timing, it's possible for an attempt to be made to reload a configuration entry when it's still in the process of being initially setup (i.e., loaded.) This change avoids reloading a configuration entry when it is not in a state where it can be reloaded.

Remove support for configuring under binary_sensor & sensor

Since 3.0.0, configuring sun2 under binary_sensor & sensor has been deprecated. YAML configuration should be moved to sun2. This release removes that deprecated support. You can find more information about this here:

https://github.com/pnbruckner/ha-sun2/tree/3.0.0#converting-from-platform-configuration

IMPORTANT: If you still have sun2 configured under sensor or binary_sensor in your YAML configuration, you should change it to the new sun2 format BEFORE upgrading this custom component.

Also note that the sensor that used to be called sunrise is now rising, and sunset is now setting.

Also, make documentation more explicit that the rising sensor indicates sunrise, and setting indicates sunset.

Fix display of period-of-time sensors w/ HA 2024.2

Starting in HA 2024.2, the frontend no longer displays sensors with a duration device_class as HH:MM:SS if the entity has a suggested_display_precision set, or the user has manually set a display_precision for the entity.

Previously, the period-of-time sensors (daylight/night) had a suggested_display_precision of 3. This change removes that setting.

Unfortunately, there's a bug in the sensor component that doesn't properly remove suggested_display_precision from the entity registry. Therefore, this change also forcibly removes it from the registry if necessary.

Also, add a state_class of measurment to period-of-time sensors (which was not possible for duration sensors in much older HA versions.)

Lastly, change the description of the elevation configuration option to "observer's elevation above ground level at specified location" instead of "location's elevation above sea level." Unfortunately, Home Assistant incorrectly describes the elevation option (in the general system configuration section) as elevation above sea level. This is not correct for the purpose of determining sun related events. If you've experienced the values returned by this integration were a bit different from other sources (such as weather websites, etc.), this is probably the reason why.

Therefore, the following are suggested:

• If you've set a display precision for any of the daylight or night sensors, remove that setting (i.e., return it to default.)
• Change the elevation option for all your Sun2 configurations per the discussion above. In most cases that probably means changing it to zero (or maybe 1 or 2 meters.)

Updated Dutch translations

3.1.0

Bump version to 3.1.0