FYI, 0.111 added a core_config_updated event at startup, which all the sensors listen for and update when it occurs (since the latitude, longitude, etc. may have changed.) Unfortunately this event was not handled properly in the elevation and binary sensors. I’m working on a fix which hopefully I’ll release tomorrow.
1 Like
Released 1.8.1
This release fixes the bug that caused the elevation sensor & binary sensor to malfunction after a core_config_updated event. The bug manifested more readily starting with HA 0.111 because it now fires that event at startup (which it did not use to do.)
Is there some advanced shadow calculator ?
Like this cool website where you can draw a simple object and have some shadow projection : http://shadowcalculator.eu/
I draw a simple part of my house.
That would be a great tool !
1 Like
So I can’t install your addon in general while homeassistant is running?
I need it running to use the file editor and paste your code into it though.
How would I do it otherwise?
Install the component, restart HA, edit the config. This is standard for any custom component.
1 Like
Hi Phil,
today in the WTH thread ‘golden hour’ was mentioned. No core support for that (yet), while it would be a valuable state for the automations concerning light (and motion for that matter).
Though it can be quite easily made into a binary sensor template as I’ve posted there, would this be something you might be willing to consider adding to your enhanced sun integration?
If so, it would be even fancier, if that sensor had an additional attribute for the fixed golden-hour time (eg like 17:00 pm to 20:30 pm) , and a next golden_hour attribute (next golden hour: in 3 hours (or a plain timestamp).
Golden hour would be a great moment to soften the tones in a theme automatically, and for the photographers amongst us, the ‘next’ would be a nice tool to gear up and go for a walk…
Guess a ‘past’ wouldn’t be that useful
Well, you probably understand what I mean.
There’s already a request for something to do with golden hour, although I could never exactly understand what was being asked for:
sorry. missed that. did my request bring some extra info on what is asked for? I gladly repost the above in the issue on your GitHub if you prefer that.
Hi Phil,
The moment finally seems to have arrived the older sun enhancement integration starts getting/causing issues with HA. As of this update 115.x I see an error in the log, which seems to have been caused by my automation (that has never errored before) using platform state on the sun.sun integration…
I’ve posted it as an issue on the GitHub, (fully respecting you don’t maintain/support that any longer)
seems we would only miss out on attributes next_daylight and prev_daylight, when using the core sun integration and you sun2 integration?
But, these could be templated (…) from the daylight attributes in your sun2 integration.
Main issue would be here to note the sun enhancement integration now causes trouble… or is it something else completely and am I searching in the wrong direction?
thanks for having a look if you would.
I’m not seeing any issues here with sun2
No, it was the older Enhanced Sun integration, not Sun2.
I tried making a template for when the sun is at 2/3 of its max elevation but I don’t know how to enter it error free into my config.yaml
- platform: template
sensors:
two_thirds_of_max_elevation:
value_template: '{{ states('sensor.max_elevation') / 100 * 66 }}'
Also, how would I have to enter it as a condition in an automation?
Will it pop up in the list of entities once it’s configured correctly in the config.yaml file?
I mean I can’t set the following into the “below” field of a “numeric state”-trigger
{{ states('sensor.max_elevation') / 100 * 66 }}
so I suppose it works the former way
edit: by the way, I just realized I don’t even know how to do a trigger “if the sun is at max elevation, today, then do x”
Just setting the max_elevation sensor as the trigger doesn’t work. It triggers the automation at 0:00 AM.
I’ll try setting max_elevation to “on” as the trigger and see if that works
Tried adding a binary sensor
- platform: sun2
monitored_conditions:
- max_elevation
;I tried it like this
- elevation:
above: max_elevation
name: Above Max Elevation
;and then like this
Both gave me an error
Hey Phil…
Any reason the sun2 elevation
[sensor.solar_elevation]
Is showing only nearest degree? The sun.sun elevation attribute for example shows 52.42 and sun2 says 42.5 (so maybe now 0.5 degree)?
Yep, not supporting that older custom integration any more, and yep, enough reorganization within HA’s core was done that the old custom integration no longer works. RIP!
Hey Phil,
would there be a way to calculate the max_elevation and min_elevation during the year on a certain location (default Instance location)? We can have the min_ and max_ for the 3 days with the current sensors, but this doesn’t give us the locations overall min_ and max_ elevation.
Given the current attributes and states, I didnt quite see a quick solution for this challenge…
nor did the https://www.timeanddate.com/sun/netherlands/amsterdam and https://www.suncalc.org/ websites, without having to fiddle with the clock.
thanks if you could have a look
@pnbruckner
It works today even after the “security earthquake” 
: HassOS 5.10, supervisor-2021.01.7, core-2021.1.5
Hi David!
Sorry, I’ve been “away” from HA for a while.
I took a different tack with this integration. Instead of updating periodically (where the period changes throughout the day per a “step function”), this sensor was designed to only update whenever the value changed by 0.5 degrees. So it “automatically” updates more often where the slope is higher and less often where the slope is lower.
1 Like
While you’re here Phil
* No 'version' key in the manifest file for custom integration 'sun2'. This will not be allowed in a future version of Home Assistant. Please report this to the maintainer of 'sun2'
in 2021.3.0b0. I suspect it’s an easy fix…
Same for your illuminance integration as well
Yep, already saw that and working on it…
BTW, I should mention, the values are not really being “rounded.” I.e., it’s not grabbing the elevation at some “random” time and rounding to the nearest 0.5 degrees. Rather, it’s waiting until the elevation gets to the next 0.5 degree increment and then it updates the sensor at that time. E.g., if you enable debug for the integration you’ll see lines like these in the log:
2021-02-25 08:10:23 DEBUG (MainThread) [custom_components.sun2.sensor] Raw elevation = 16.499365 -> 16.5
2021-02-25 08:13:25 DEBUG (MainThread) [custom_components.sun2.sensor] Raw elevation = 16.998134 -> 17.0
2021-02-25 08:16:28 DEBUG (MainThread) [custom_components.sun2.sensor] Raw elevation = 17.496940 -> 17.5
2021-02-25 08:19:33 DEBUG (MainThread) [custom_components.sun2.sensor] Raw elevation = 17.998357 -> 18.0
2021-02-25 08:22:38 DEBUG (MainThread) [custom_components.sun2.sensor] Raw elevation = 18.496835 -> 18.5
It strives to determine the next update time so that the difference between the actual and reported values is no more than 0.02 degrees.
1 Like