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:
))
