Skip to content

Releases: pnbruckner/ha-sun2

Major update & reorganization

29 Dec 15:22

Choose a tag to compare

Pre-release

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 the time_at_elevation astral 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. The yesterday, today & tomorrow attributes 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 use states(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_entity action
  • 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

04 Nov 14:15

Choose a tag to compare

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

30 Sep 18:22

Choose a tag to compare

What's Changed

New Contributors

Full Changelog: 3.4.0...3.4.1

Support Home Assistant 2024.8.3 or newer

30 Sep 18:00

Choose a tag to compare

What's Changed

Full Changelog: 3.3.5...3.4.0

Use UTC datetimes internally

20 Nov 15:31

Choose a tag to compare

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

30 Oct 20:29

Choose a tag to compare

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

13 Aug 15:27

Choose a tag to compare

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

31 May 16:46

Choose a tag to compare

What's Changed

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)

12 May 19:19
7bd584d

Choose a tag to compare

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

09 May 13:52
3b75033

Choose a tag to compare

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.