I really don’t know. The integration certainly does not include translations for the values of these state attributes, only for their names. The same is true for the next_change attribute, yet its value is getting translated properly. E.g., in English:
And in Dutch:
So, you can see that all the attribute names are translated, but only the next_change attribute’s values are translated. And that is NOT done by my integration. It is counting on translations defined elsewhere (e.g., in the sensor component-level code, frontend???) They seem to work for datetime’s, but not for bool’s. I don’t know why that is the case.
I am wondering if I have done something wrong. After installing Sun2, I no longer see sunrise or sunset times. I can use sensor.home_sun_rising or sensor.home_sun_setting. In the Sun2 device setting page, I have 7 enabled entries and 17 disabled, none of which are sunrise or sunset. Is this intended or am I missing something? Thank you…
sensor.home_sun_rising is indeed sunrise, and sensor.home_sun_setting is sunset, as explained in the README.md.
Maybe I’m misunderstanding you. What exactly do you mean by, “I no longer see sunrise or sunset times”?
FWIW, I chose to use “sun_rising” instead of “sunrise”, and “sun_setting” instead of “sunset”, to be more consistent with the way the built-in sun integration works.
I had a sensor named sensor.sunrise that I had to change to sensor.home_sun_rising. sensor.sunrise status is ‘unavailable’ now.
I must be missing something though because documentaion states “All “simple” sensor options (e.g., sunrise , sunset , etc.) will be created automatically.” however I cannot find sunrise or sunset sensors.
Ok, I can see the confusion. Yes, that paragraph is misleading. And I never explicitly state anywhere what used to be called sunrise is now rising and what used to be called sunset is now setting. I’ll try to make it clearer. Thanks for the feedback!
Thank you for the reply. It’s no big deal to me but is this a “breaking change” where we have to modify the names of the sensors in use (sunset and sunrise) before 3.1.1?
Well, it’s not technically a “breaking change”, because the older “platform” YAML config is still supported, although deprecated. So, nothing “breaks” just by upgrading.
That only happens when changing your YAML configuration to the new format, or using the new UI based config flow.
But, yes, changing from:
sensor:
- platform: sun2
to:
sun2:
- ...
or using the new UI config flow, is effectively a breaking change, at least concerning the naming of these two sensors. And, FWIW, that happened at release 3.0.0, which has been out for over two months now.
Having said that, the new names of these sensors is documented, and they are more consistent with the built-in sun sensor, so it shouldn’t be a complete surprise.
Still, I agree, the doc could use some improvement to make this all clearer, which I plan to do.
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.
Also, make documentation more explicit that the rising sensor indicates sunrise, and setting indicates sunset.
The idea is, you will have a choice to pick where you see the sun event: at the horizon, or at the top of an obstruction such as a mountain. And you can choose one for the sun rising in the east, and another for the sun setting in the west, since they may be different.
If you pick the horizon (which is the only option currently), then it will ask your elevation above ground level, which it will use to calculate how much further you can see around the curvature of the Earth.
If you pick an obstruction, then it will ask for the distance to that obstruction and how much higher it is than you, which can also be negative if you are actually higher than it.
I have an implementation working, although I haven’t pushed it to the repo yet. I hope to have a beta ready before long.
FWIW, I discovered this feature of the astral package (i.e., defining an obstruction that affects the sun events) doesn’t work correctly. Apparently, it isn’t used much, although I did find an issue against it that was raised late last year. Unfortunately, it looks like the package hasn’t been maintained lately. (Last commit was over a year ago.)
The new release will also have a few other nice new features:
Show current latitude/longitude/time-zone values in options flow with the ability to skip changing them.
Select whether to specify latitude & longitude via a map (like now) or manually. Entering manually makes copying latitude & longitude values from other places (e.g., Google Maps) much easier.
Allow specifying elevation (height above ground and/or obstruction) even when using HA’s Home location configuration (since the elevation entered there may still be above sea level instead of above ground level.)
I live on an east facing slope at 200m elevation: to the east the horizon is far away, to the west the horizon is blocked by a mountain. I will use this
I’ll try to get that beta out soon. I’ve been concentrating on adding tests to this integration, but I can put that aside for a bit and get back to it later.
Sorry, got sidetracked on an issue with my Google Maps integration.
Do you use YAML or UI configuration for the sun2 integration? I can probably get a beta out today, but it won’t have the docs updated yet. If you use UI based configuration, then it will walk you through it (either adding another integration entry, or re-configuring an existing one.)
The items in this next page depend on what is checked on the above page.
Yeah, the version of the integration that adds support for obstructions is pretty static. You define the values in YAML or via the UI, and you can change them afterwards, but that’s a pretty manual process.
I do have a request to add another feature that allows a service call to change the parameters (latitude, longitude, time zone & elevation.) The main intent was to be able to change the GPS & time zone values when, say, you go on vacation and want sun events for your vacation destination.
But that could be used to update the elevation/obstruction values, too. Maybe you could then add an automation that monitors azimuth or day of year or something like that and then updates the obstruction values as needed.
UPDATE: I have added working services. One to get the current parameters of any integration entry. The other to change the parameters of an integration entry. The latter only supports UI-based entries (because it can’t change the YAML config file, or at least, shouldn’t), and only one that does not use HA’s location configuration (since that entry already updates based on updates of that config.)
I’ll work on getting those out in another 3.3.0 beta release.
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 relative height of the obstruction from 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.)
This PR adds support for defining either type for easterly events (sunrise, dawn) and westerly events (sunset, dusk.)
NOTE: The documentation has not yet been updated to describe how to use this new feature from YAML configuration. Using it from UI configuration is obviously much easier. If you do want to try it from YAML, here is an example:
The old elevation config option has been deprecated by observer_elevation. It is still supported, however, in case you want to go back to a previous version of this integration. These options are no longer “coupled” with the location options (latitude, etc.)
new feature.
