I tried two more configurations.
The first was with logger removed from my config. I still saw the warning in the LOGS tab and in home-assistant.log.
The second was with:
logger:
default: error
Although, as before (i.e., with “custom_components.sun2: error”), the warning did not appear in home-assistant.log, it still showed in the LOGS tab:
I have no idea what might be different about your system where you don’t see it. Oh well!
For minimum elevation, give this a try.
could it be returning this…:
I’ve re-downloaded twice, both sensor.py and binary_sensor.py, (the other files were older)
Are you sure you downloaded from the branch? The only files that changed were sensor.py & README.md.
yes?
https://github.com/pnbruckner/ha-sun2/tree/min_elevation/custom_components/sun2
_SENSOR_TYPES = {
# Points in time
'solar_midnight': (Sun2PointInTimeSensor, 'mdi:weather-night'),
'astronomical_dawn': (Sun2PointInTimeSensor, 'mdi:weather-sunset-up'),
'nautical_dawn': (Sun2PointInTimeSensor, 'mdi:weather-sunset-up'),
'dawn': (Sun2PointInTimeSensor, 'mdi:weather-sunset-up'),
'sunrise': (Sun2PointInTimeSensor, 'mdi:weather-sunset-up'),
'solar_noon': (Sun2PointInTimeSensor, 'mdi:weather-sunny'),
'sunset': (Sun2PointInTimeSensor, 'mdi:weather-sunset-down'),
'dusk': (Sun2PointInTimeSensor, 'mdi:weather-sunset-down'),
'nautical_dusk': (Sun2PointInTimeSensor, 'mdi:weather-sunset-down'),
'astronomical_dusk': (Sun2PointInTimeSensor, 'mdi:weather-sunset-down'),
# Time periods
'daylight': (Sun2PeriodOfTimeSensor, 'mdi:weather-sunny'),
'civil_daylight': (Sun2PeriodOfTimeSensor, 'mdi:weather-sunny'),
'nautical_daylight': (Sun2PeriodOfTimeSensor, 'mdi:weather-sunny'),
'astronomical_daylight': (Sun2PeriodOfTimeSensor, 'mdi:weather-sunny'),
'night': (Sun2PeriodOfTimeSensor, 'mdi:weather-night'),
'civil_night': (Sun2PeriodOfTimeSensor, 'mdi:weather-night'),
'nautical_night': (Sun2PeriodOfTimeSensor, 'mdi:weather-night'),
'astronomical_night': (Sun2PeriodOfTimeSensor, 'mdi:weather-night'),
# Min/Max elevation
'min_elevation': (Sun2MinElevationSensor, 'mdi:weather-night'),
'max_elevation': (Sun2MaxElevationSensor, 'mdi:weather-sunny'),
# Elevation
'elevation': (Sun2ElevationSensor, 'mdi:weather-sunny'),
}
from the new sensor.py…
The config will not be valid until you restart HA.
a, ok, and it wont restart with the config… ok let me take it out and restart… sorry.
btw, thanks for adding it!
Yeah, that’s a Catch 22 in the design of HA. You need to stop HA, change the config (at which point you can test the config via the command line), and then start HA. Or, I suppose, as you said, not change the config to use the new feature until you restart HA. Then you can change the config to use the new feature and restart HA again so it takes affect.
Just a question, without having thought too deeply: If we have the condition that some astronomical day phases don’t happen (like the night, or astronomical twilight), shouldn’t their length result be 0 hours instead of unknown?
Reasoning: “If it doesn’t happen, it’s zero hours in length.”
Yes, that makes sense, too. And I suppose it might help when graphing…
If nobody objects, I suppose I could change it to result in zero in this case.
EDIT: On the other hand, couldn’t 24 be the right value sometimes, too? Or actually 937 (or whatever) hours???
When the period gets smaller and smaller, and then “doesn’t happen”, zero would make sense.
But when the period gets bigger and bigger, until it no longer “ends” during the current day, then really the length is until it ends again, which could be many days later. I suppose in this scenario it could calculate how long it will be until it ends (the “logic” is already in the binary sensor implementation.) But that might be less trivial than it sounds; not sure.
The current implementation is “easy” – it just results in ‘unknown’ when the period does not both start and end in the current day.
Released 1.8.0
Added min_elevation option.
having grown accustomed to ‘unknown’ makes me feel hesitant about a fixed ‘0’, or any of its equivalents. I’d rather see ‘unavailable’, simply because we know it isn’t there (when the period does not both start and end in the current day). It’s not ‘0’, and it’s not ‘unknown’.
It’s non-existent, null… closest to the would be ‘unavailable’ , which is not the same as ‘None’ as that would indicate the sensor isn’t initialized…
'unavailable' is generally meant to indicate the sensor can’t be accessed, such as due to communication errors. It means there is a value, it’s just that HA can’t currently “get” to it or retrieve it. So I don’t think that would jive very well with the usage of that term.
The Python value None is internally converted to the string 'unknown' when setting an entity’s state. So basically an entity’s state could never be None.
Of course it could be 'None' (i.e., a string), or more likely 'none' (i.e., all lower case.) In fact, the “point in time” sensors return 'none' when the event does not happen in the current day – when does blah happen? Well, there is none! 
For the “period of time” sensors, I use 'unknown' (which is internally represented as the Python None object) when the period does not start, or does not end, or both, in the current day, because it doesn’t currently try to determine what the period really is, and so, to the sensor, it’s “unknown.”
If it did calculate it, then it would be either zero (if it didn’t happen during this time of year), or the total length of time it was present, since the last time it started (possibly today or on some day previously) and the next time it ends (either today or some day in the future.)
But, like I said, it was easier not to do this and just return 'unknown', because, again, it is unknown to the current implementation of the sensor.
this must be one of the best posts on the community. I’ll bookmark this, just for having a smile each day needed.
Thank you sir!
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.
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 !
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.
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.
