Releases: pnbruckner/ha-sun2
Major update & reorganization
Beta testers needed
Since it is very difficult to test all locations & times of year, both of which affect the operation of these sensors, I would really appreciate it if people could give this beta release a try AND provide your feedback, good or bad. THANKS!!
What's Changed
4.0.0b0 (2025-12-08):
- Make sensors use observer elevation that should but haven't
This feature (or really, a bug fix, since these sensors should have always used observer elevation as an input) was first introduced in release 3.4.2, but the implementation was seriously flawed, so that release was retracted. This is a second attempt to implement the same improvement, but in a different way. Also, more manual testing was done than before.
Sensors affected: Phase, deCONZ Daylight & Elevation binary sensor. - Simplify some sensor implementations
Some of the sensors used an "elevation curve" search mechanism to determine their state. This is overly complex and leads to some sensors disagreeing with each other. Simplify the sensors that used this mechanism to use thetime_at_elevationastral method instead.
Sensors affected: Phase, deCONZ Daylight, Elevation & Elevation binary sensor. - Change sunrise & sunset elevation from -0.833 to -0.267
The astral package made this change in its 2.0 release and was first used in Home Assistant with its 2021.5.0b0 release. This is because the astral package now accounts for refraction
4.0.0b1 (2025-12-08):
- Remove outdated manual entity name translations
Support for placeholders for entity name translations was added to Home Assistant in the 2024.2.0b0 release.
4.0.0b2 (2025-12-09):
- Fix first update of elevation binary sensor
If HA starts when the sun is setting (i.e., it is after solar noon), but it does not set today (e.g., it stays above or below the horizon for the whole day), this sensor's initial state was set incorrectly. This change fixes that bug.
4.0.0b3 (2025-12-18):
- Make point in time sensors show next time event occurs
If event does not occur in the current day, have the state show the next time the event does occur, as long as it occurs sometime within the next year. Theyesterday,today&tomorrowattributes are not affected by this change. - Make updates atomic
This was supposed to be the case initially, but due to a bug, atomic updates were not guaranteed. - Elevation sensor updates now use raw, unrounded values
This could potentially be a breaking change. If multiples of 0.5 are still needed, this can be accomplished by leaving the display precision set to one decimal place, and usestates(ENTITY_ID, rounding=True). - Limit some potentially long updates to 50 msec at a time
- Round timestamp type states to nearest second
- Change azimuth sensor update rates
Take observer elevation into account. Make rate every 2 minutes when within 6 degrees of sunrise/sunset, and every 10 minutes otherwise. - Provide list of available time zones in config flow
- Fix bug related to disabled entities when configuration is updated
4.0.0b4 (2025-12-26):
- Properly handle
homeassistant.update_entityaction - Use HA's zoneinfo time zone implementation instead of astral's pytz-based implementation
4.0.0b5 (2025-12-29):
- Drop support for HA versions before 2024.12.0
Full Changelog: 3.4.3...4.0.0b5
Revert code changes in 3.4.2
Release 3.4.2 is broken
The code changes in the 3.4.2 release seriously broke the phase & deCONZ daylight sensors. Depending on the configured location and time of year, they could cause bursts of state changes, resulting in a seriously negative impact on system performance. Unfortunately, I didn't take all the boundary conditions properly into consideration, my own testing was minimal, and I did not receive any beta testing feedback.
This release reverts the code changes from the 3.4.2 release. I apologize for any inconvenience.
Add swedish translation
Support Home Assistant 2024.8.3 or newer
What's Changed
- Support Home Assistant 2024.8.3 or newer by @pnbruckner in #142
Full Changelog: 3.3.5...3.4.0
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_daylightsensor's states ofnautical_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.