It would be great if Suncalc information (by lack of a better description ) would be added to the Sun integration. The example below is a JavaScript based library:
This would bring fourteen states of the sun’s position on which people can apply automations based on a descriptive solar position, rather than Asimuth or only ‘above horizon’ or ‘below horizon’, etc. Ideally an entity would be added which has one of the following values:
Value
Description
sunrise
sunrise (top edge of the sun appears on the horizon)
sunriseEnd
sunrise ends (bottom edge of the sun touches the horizon)
goldenHourEnd
morning golden hour (soft light, best time for photography) ends
solarNoon
solar noon (sun is in the highest position)
goldenHour
evening golden hour starts
sunsetStart
sunset starts (bottom edge of the sun touches the horizon)
sunset
sunset (sun disappears below the horizon, evening civil twilight starts)
Edit2: It appears I wasn’t very clear what I have in mind exactly, as per the discussion below. I currently have a pseudo device from my Conbee II, which has one of fourteen states mentioned above. I would like to see this functionality in the Sun integration. Through this, we could either trigger on a solar state change or, query the current solar state. (to be used for initial colour temperature and/or brightness of lights as an example - So when turning on the light, based on the position of the sun (or at least one of the fourteen states), you could decide you want to have light turned on less bright and warmer by your motion sensor (so that you’re not blinded in the middle of the night and you need to go ))
@Emphyrio
Hi,
Yes, I saw that one, but that one is insufficient. From what I can tell, all of the functionality is in the current Sun integration. (It also shows ‘next rising’ and ‘next setting’, etc).
There is a big differrence between “beginning of sunset” and “start of night” and “darkest moment”. (can be hours apart) depending on where you live and which season you are in)
For example:
Today in Paris the sun sets at 21:49, but night (no sunlight at all anymore) is at 01:21 tomorrow. (well more than two hours difference)
On december 1st in Paris, the sun sets at 16:54 and night sets in at 18:51 (less than two hours) @myle
Hi,
Yes I saw that one too. But that one too hardcoded. It only changes the colour temperature of ‘lights’ (no dimming/etc). By being able to use the fourteen solar stages, I could (for example) disable the my doorbell after night sets in. (so not sunset, which is still quite light where I live).
sunrise - sunrise (top edge of the sun appears on the horizon)
sunriseEnd - sunrise ends (bottom edge of the sun touches the horizon)
goldenHourEnd - morning golden hour (soft light, best time for photography) ends
solarNoon - solar noon (sun is in the highest position)
goldenHour - evening golden hour starts
sunsetStart - sunset starts (bottom edge of the sun touches the horizon)
sunset - sunset (sun disappears below the horizon, evening civil twilight starts)
dusk - dusk (evening nautical twilight starts)
nauticalDusk - nautical dusk (evening astronomical twilight starts)
night - night starts (dark enough for astronomical observations)
nadir - nadir (darkest moment of the night, sun is in the lowest position)
nightEnd - night ends (morning astronomical twilight starts)
nauticalDawn - nautical dawn (morning nautical twilight starts)
dawn - dawn (morning nautical twilight ends, morning civil twilight starts)
You can do ALL of these with the standard component (except for the dubious ones, I’ll note)
Sunrise - Well that’s ‘sunrise’ in the standard component
SunriseEnd - This is just made up, why would you want that ? Anyway this is virtually impossible to calculate, see : - Sunrise - Wikipedia
The atmosheric lens effect will mean that you can define a position of the sun above the horizon (which would be 16’ (16 minutes or 0.266666 degrees) above the horizon but due to the lens it will appear much higher)
goldenhourEnd - This is a ridiculous statement as it depends on lattitude, the golden hour is a nominal name for a light effect that occurs with the sun very low in the sky. An hour after sunrise in Florida is FAR differentt to an hour after sunrise in Alaska - you are better to use an elevation and work on that.
SolarNoon - This is ‘noon’ in the standard component
goldenHour - see goldenhourEnd
sunsetStart - see sunriseEnd
sunset - This is ‘sunset’ in the standard component
dusk - The definition of dusk is when the sun is 6° below the horizon, need I say more ?
nauticalDusk - The definition of nauticaldusk is when the sun is 12° below the horizon, need I say more ?
night - well your description is astronomical dusk which is defined as when the sun is 18° below the horizon, need I say more ?
nadir - This is ‘midnight’ in the standard component
nightEnd - see night
nauticalDawn - see nauticalDusk
dawn - see dusk
Quite frankly these are all easy to derive and no developer would spend time doing this as pnbruckner has already done most of the work (that’s if you aren’t comfortable using the standard component as described above) in his enhanced sun component.
The ‘golden hour’ is just subjective and varies between individuals and latitudes.
The sun kissing the horizon ‘could’ be worked out and defined but it’s usage is beyond me, if ‘you’ feel the need, work out the elevation and apply it.
Well, what’s called the “Golden Hour” and the “Blue Hour” are in reality almost never “an hour” (see my screenshot above), and of course calculated based on sun elevation. They are also quite important to photographers, for instance.
Having the wished-for extra data in sun’s attributes is more a nicety than a requirement – just making things easier to read and program. Of course we can set up lots of triggers based on elevation (I actually do), but I watch myself looking in the StudioDisplay code each and every time …
The descriptions which they are given can be quite misleading I admit, but at the end of the day it’s just a name. ‘Sun is in the highest position’ would of course suggest, a specific moment. In the suncalc algoritms, it is considered a period which takes about some over seven hours today where I live. (I admit the naming could be better )
For example: Yesterday it started at 13:44 and ended at 21:08. The Sun integration stated ‘noon’ as one point 13:43 today, which is considered of course a moment in time. (.)
The same differences are there for ‘midnight’ and ‘nadir’.
N.B. The suncalc calculations do take latitude, longitude and elevation in account.
Also as @Moonbase59 also mentions. It’s a ‘nice to have’.
Your distinction is lost on me unless you are talking about periods between any two of the given ‘instants’ as in yournoon lasts until the sun kisses horizon, which is then setting until it’s set, then it’s set until dusk etc. ???
This again makes no sense as the period bears no relationship to the name given it other than “it’s what triggered it”
Triggering periods is alway difficult and ambiguous as what happens at a restart ?
As most of these instant’s are difficult to calculate in advance/retrospec (this requires a definition of the instant and binary division offset to asymptotically approach the correct ‘time instant’ ) Note: this would only be applicable at your home location and elevation anyway so a photo shoot 10km from home would be a ‘best guess’ and would become ‘wild’ with further distance
If you keep these items/status’s in (say) an inpur text or the series in an input select then they assume last status (whatever it was when HA went down) you would need to run through all the calcs, establish the current time in relation and select the slot. This is doable, but I fail to see an application.
Ah. Now I see where the confusion lies I wasn’t completely clear in my opening post.
At this moment I have a pseudo-device which is brought by my Zigbee stick (a Conbee II)
That device provides (next to the entities of several bulbs, switches and motion sensors) an entity (named “Daylight”) which always has one of the fourteen states mentioned above. Through the pseudo device I can perform checks based on the ‘current’ state of that pseudo device for several purposes. I would like to see that functionality built in the Sun component (or if the HA people decide they won’t do so, I’ll check with the Sun2 developer, which I just discovered through the remarks made above. The one linked to (Sun Enhanced) is superseded by the creator into Sun2 as you probably already knew)
For me personally I can work with what I have and that works fine, but not everybody has a Conbee II, or wants to/can create complicated triggers based on a load of sensors, whereas it can also be done via one. Also it feels like a proper addition to the Sun integration. A real nice ‘nice to have’.
(So I don’t want to fetch the times, I want to fetch the ‘current state’)
You have to follow a couple of links to get to the current implementation. Just so you are aware, the current implementation of my “sun2” integration (including documentation), can be found here.
It has 10 “point in time” sensors (sunrise, dawn, etc.), 8 “length of time” sensors (daylight, civil_daylight, etc.), elevation, max_elevation, and you can configure as many binary sensors as you like (that are 'on' when the sun is above the elevation(s) you specify.)
It was also designed to fairly easily extended.
I don’t know if it’s exactly what you were looking for, but I wanted to make sure you weren’t just seeing the older, original implementation.
Thank you for your reply.
You are right. At first I was only aware of the ‘old’ version (which is practically functionally integrated in the base integration I believe?) I did look at the new one. (sun2)
What I’m basically looking for is an Entity that has the ‘current value’ as in the screenshot I put the edited opening. (each colour is a different state (solar_noon, nadir, etc. etc.)), so rather then having a list of times/durations I would like to be able to use the ‘current’ state.
At the moment I use it to make decisions in my automations based on the current state. (e.g. if it’s ‘solar_noon’ use brightness 123, if it’s nadir, use brightness 321, etc)
Well that would be an instant in time, so that would effectively always be false. If you mean is it after solar noon (and before midnight), then that can be determined with a template binary sensor using either the current sun integration or my sun2.
If you’re looking for a sensor that indicates whether it is, say, during the civil daylight hours, then you can configure a binary sensor that indicates when the sun’s elevation is above -6 degrees. And if you want something more complex, say during civil twilight, then you could configure two binary sensors – above -6 and sunrise – and then create a template binary sensor that combines those.
But it seems like what you really want is a sensor whose state is the name of the “period” the sun is currently in. I suppose you could do that by defining enough elevation-based binary sensors in sun2, and then create a template sensor that determines which period it’s in based on those.
Having said that, although I haven’t throught it completely through yet, I suspect it wouldn’t be too hard to enhance my sun2 integration to create a sensor that does this. If there’s a really good definition of what the periods are – i.e., what elevations deliniate them – then I suppose it could be “hard coded.” Or, maybe, it could be configurable so that the user could specify the parameters of the periods and give them whatever names they want.
Yes, that’s what I’m looking for. If you look at what the Conbee II (or DeConz, depending on which actually generates it) in the OP. Each colour is a different ‘period’. The naming is actually quite misleading as obviously some of the names are always ‘one exact moment’ and others can be concidered a longer period of time, but let’s not get into language and word-choice here
Yes, I know this topic is quite old, but I’m cleaning up bookmarks and ran across it again. @lennardw, not sure if you already know this, but the sun2 integration now has two sun “phase” sensors, one of which, the “deCONZ Daylight” sensor, I think provides exactly what you were looking for.
) would be added to the Sun integration. The example below is a JavaScript based library:
))
