Released 2.5.0
1 Like
I’ve had a request for adding internationalization support (i.e., translations) to the sun2 custom integration. I’ve made the changes I thought were necessary, but it doesn’t seem to work for me. If anyone would be willing to give it a try (so far only English) and let me know how it works for you, I’d appreciate it. Or, if anyone knows what I’m doing wrong, that would be helpful, too.
The changes are currently on a branch (GitHub - pnbruckner/ha-sun2 at internationalization), but I suppose I could create a beta release if necessary.
When I say it doesn’t work, I’m seeing “day” instead of “Day” or “astro_twi” instead of “Astronomical Twilight”. And Ctrl-F5 doesn’t seem to help.
1 Like
Is there any way to get sun angels (elevation, azimut) for the recent location, but for any given (future) time stamp?
Background: would like to precalculate the PV irradiation from sun positions (and size, and bearing, and shadows, and cloud coverage) for next 3 days in a 15 minutes interval… for better energy usage planning.
Don’t hesitate to throw me into some Python pool. I am C++ dev, could learn to swim there …
THX
Try Forecast.solar or Solcast instead. You’ll need to create some REST sensors to get the data, since these will give you next day data only. No need to reinvent the wheel.
Will try it!
Thank you 
[Edit]
Already used “Forecast.Solar” since days, didn’t remember the exact name last time.
- Good: I can use up to 4 panels in one call - exactly what i have @ Hoymiles 4 channel inverter.
- Bad: This program is far away from real values for my installation. At least it seems needing some 1-hour shift and some damping calibrations, right?
- Bad, but not blaming them: I have a large shadowing object walking through my panels (neighbor house) from mid of September and there is no 360-degree-horizon model or the like to reflect this obstacle.
Had a look at Solcast then:
- Bad: 10 calls per day make it nearly useless for 3-sides-roof or similar multichannel setups.
- Bad, but not blaming them: also not using the 360 degree horizon of the EU PVGIS or similar obstacle definition.
Self cooking:
- Good: some recorded sol.angle and sol.azimuth from august/early September, mangled with panels’ angle and bearing, combined with some recorded OpenWeatherMap cloud coverage percentage are fitting quite well with my PV power.
- Good: a hour-wise calculation of neighbors house (estimated as a rectangular wall) shadowing half-cell banks of each single panel are also not too bad, compared to real power yield.
- Worse: I found a geometric and mathematical formula paper for calculation of solar position, but this is much too complex to get written down as source code, et least for an old man with finite spare time. I wonder if such basic formula azimuth = f(latitude, longitude, date) does already exist in C, C++ or Python open source libraries?
Still thinking about self cooking.
With the new elevation_at_time sensor, it’s possible to do this for at least elevation. E.g., configure it to use an input_datetime with both date & time. Then you could have an automation that sets that input_datetime and then reads the value of the corresponding elevation sensor.
But that seems a bit involved. Might be better to write your own custom integration, or even a Python Script. Or do what @parautenbach suggested.
Throwing in the towel!
Have you tried the Discord dev channel?
Yes, I did.
Hi! Thanks for a nice integration. Maybe I’m doing something wrong but this seems off. My sensor.sunrise has value 2023-11-10T06:29:57+00:00 and my sensor.sunset has value 2023-11-10T15:11:09+00:00.
With these two values I would expect sensor.daylight_2 to have value 8.687 (I did calculation on https://www.calculator.net … but my sensor.daylight_2 has value 8.78270324916667. Hours minutes difference is 8 hours, 41 minutes, and 12 seconds vs 8:46:57 - so more than 5 minutes difference!
Am I doing something wrong or why could there be such a difference? Also, why would my sensor be called sensor.daylight_2 and not without (_2)? I have no other sensor with the same name …
thanks!
1 Like
To answer the first question, because the sun2 integration has a bug, and you’re the first one to notice! I used the wrong value for solar depression for the calculation for daylight. I’ll fix it.
To answer the second question, I couldn’t say for sure. However, you should be able to fix it via the Settings → Devices & Services → Entities page. Make sure all entities are shown, then search for daylight. You might see another entity with an ID of sensor.daylight that is disabled or something. If so, try to delete it. Then you should be able to change sensor.daylight_2 to sensor.daylight.
Update: See daylight calculates wrong value · Issue #94 · pnbruckner/ha-sun2 (github.com)
Released 2.5.1
Fixes daylight calculation per above comments.
Released 3.0.0b0
This release adds import config flow, so integration now shows up on Integrations page. Also, this was necessary to support translations, which have also been added (only en & nl so far.) If anyone creates translations for any other language(s), I’d appreciate those files as well (either via a PR, or just send them to me.) Service type device info has also been added to entities, so each configured location will also show up as a service.
Previous configuration format (i.e., as a platform under binary_sensor & sensor) is now deprecated. A new sun2 configuration format has been added. All “simple” sensor types (i.e., those with a single word, such as dawn & sun_phase) are no longer added via config, but are always added, most of which are disabled by default (much like what is done with the standard sun integration.) Simply enable the sensor types you want, and disable the rest. So, a configuration that looked like this:
sensor:
- platform: sun2
entity_namespace: London
...
monitored_conditions:
- sunrise
- sunset
- time_at_elevation: 3
Now looks like this:
sun2:
- unique_id: london
location: London
...
sensors:
- time_at_elevation: 3
1 Like
FYI, I’ve already found one bug that I’ve fixed in 3.0.0b1, but I just found another. I’ll let everyone know when it should be ready (i.e., hopefully when I release 3.0.0b2 
)
1 Like
Nice Phil, thanks and congrats for keeping this integration up to speed !
Since you show the entity_namespace, ( and I have set that to astral to clearly indicate the origin): can we still use that using the config_flow? Or maybe only set that in yaml?
or
ofc we can set in in the ui… nevemind. me…
working beautifully, magic. really appreciated
So, that is in the older style configuration (i.e., platform: sun2), which is now deprecated. That does not carry over to the newer style configuration (i.e., sun2:). In the newer style, there is a new option called location. Entity IDs and friendly names are a bit different now. E.g., instead of “London Sunrise” and sensor.london_surise, it would now be “London Sun Rising” and sensor.london_sun_rising. There are reasons for this which I won’t go into. Suffice it to say I would have been swimming against the current to do it any other way. But, having said that, the integration entries, service entries and entity entries can all be edited via the UI. So, if you want different names or entity IDs, just change them.
As far as the config flow goes, so far, I’m only supporting import from YAML. But I’m doing it with possibly being able to add entries via the UI. No promises.
Glad it’s basically working for you. I do have a couple bugs I still need to fix. Hopefully you won’t be affected by them in the meantime.
Released 3.0.0b2
Fixed a bug in core config update handling.
Have you seen/tried the translations yet? Is your language setting nl? If so, everything should be translated already (when you change your config to the new “sun2:” style.)
yes it is in nl, and I must confess that always strikes me as odd, these translations often feel a bit unnatural. But maybe these are the official meteorological terms, not sure .
entity_ids like thuis_zon_nacht …
maybe its because the ‘sun’ or ‘zon’ part now seem unnecessary. Before, I just had ‘astral’ and astral_midnight, or astral_solar_noon were beter imho.
not sure if you need to add the ‘sun’ part to each entity_id.
btw my config is:
sun2:
- unique_id: home
sensors:
- time_at_elevation: -4
- time_at_elevation: -4
direction: setting
and those are the only ones not translated as you can see
maybe Ill just replace the ‘thuis_zon’ bit with ‘astral’ again…
btw, if Iwouldnt need these 2 time_at_elevation entities, could I leave out the full yaml, or still require the
sun2:
- unique_id: home
entry?
asking because in the docs there’s the above entry https://github.com/pnbruckner/ha-sun2/blob/643bf3e1cf7903dc13c51ccee33306f203cfc8ea/README.md, but leaving that out completely now still provides all of the entities in my screenshot above
on those translations, not happening on all of the attributes and their states:
