Request/Enhancement Sensor Daylight "actual_state"
n0nk opened this issue · 16 comments
In the past i used Deconz addon, which provided Daylight sensor (as you know i guess...)
I searched for a replacement and found this. But i am missing a beloved feature :)
I don't want to work with several different sensors therefore it would be nice to have a actual_state sensor (i dont care for the naming)
which just shows the string of the actual Sun state depending on the calculations.
E.g.
sensor.sun2_actual_state = "solar_noon"
switch to
sensor.sun2_actual_state = "sunset"
switch to
sensor.sun2_actual_state = "dusk"
switch to ... etc.
Anyone else thinks that this may be useful?
Thanks in advance
Actually it should behave like the existing sun.sun sensor but more detailled
Something like this should be possible. However, the states you give in your example are moments in time, not periods of time. I.e., solar noon, sunset & dusk are instants in time and hence could really not be states for a sensor that would last for some period.
Given the basic structure of the existing integration, it would make sense to have states like:
night
morning_astronomical_twilight
morning_nautical_twilight
morning_civil_twilight
day
evening_civil_twilight
evening_nautical_twilight
evening_astronomical_twilight
night
But I'm not so sure that's what you, or anyone else for that matter, would want.
Maybe you could describe the states of the Deconz Dalylight sensor. (I'm actually not familiar with Deconz at all.)
This is a screenshot of the Sensor history:
And it showed changes the states and just keeps the last state it switched to. This was easy to use in automations while doing something like "Do something if daylight.state switched to Dusk" like using a motion sensor.
(Screenshots "stolen" from this thread because i am not running deconz anylonger --> https://community.home-assistant.io/t/sensor-daylight-in-automations/267560)
The Sensor got the following states:
| sunrise_start | sunrise (top edge of the sun appears on the horizon) |
|---|---|
| sunrise_end | sunrise ends (bottom edge of the sun touches the horizon) |
| golden_hour_1 | morning golden hour (soft light, the best time for photography) |
| solar_noon | solar noon (sun is in the highest position) |
| golden_hour_2 | evening golden hour |
| sunset_start | sunset starts (bottom edge of the sun touches the horizon) |
| sunset_end | sunset (sun disappears below the horizon, evening civil twilight starts) |
| dusk | dusk (evening nautical twilight starts) |
| nautical_dusk | nautical dusk (evening astronomical twilight starts) |
| night_start | night starts (dark enough for astronomical observations) |
| nadir | nadir (darkest moment of the night, the sun is in the lowest position) |
| night_end | night ends (morning astronomical twilight starts) |
| nautical_dawn | nautical dawn (morning nautical twilight starts) |
| dawn | dawn (morning nautical twilight ends, morning civil twilight starts) |
This sensor was the most useful sensor for my time/light-based automations :) Would be nice to get it back without deconz installation.
Does this answer your questions?
Yes, it does, thanks! Those states seem kind of weird to me, and not very symmetric. But I suppose I could try to implement a "deCONZ Daylight Sensor" emulation sensor. No promises. I'll try to remember to comment here if/when I get working on it.
Nice to read this. Thanks for trying :)
After doing a bit of digging, I'm not 100% sure, because I don't know how to see the code of the actual deconz stuff, but based on what you've provided, and the code I could see, it appears the states of the sensor are effectively the name of the previous event. E.g., nadir starts at the lowest elevation (i.e., nadir) and continues until the sun reaches -18 degrees, which is the start of morning astronomical twilight. At that point the state changes to night_end and continues until the sun reaches -12 degrees, which is the start of morning nautical twilight.
Here are what I believe the states would be:
| Sun Angle | Event | Period Begins | State Begins ??? |
|---|---|---|---|
| lowest | nadir | (night continues) | nadir |
| -18 | astronomical dawn | morning astronomical twilight | night_end |
| -12 | nautical dawn | morning nautical twilight | nautical_dawn |
| -6 | civil dawn | morning civil twilight & golden hour 1 | dawn |
| -0.833 | sunrise | day (morning golden hour continues) | sunrise_start |
| -0.3 | - | (day & morning golden hour continue) | sunrise_end |
| 6 | - | (day continues) | golden_hour_1 |
| highest | solar noon | (day continues) | solar_noon |
| 6 | - | night golden hour (day continues) | golden_hour_2 |
| -0.3 | - | (day & night golden hour continue) | sunset_start |
| -0.833 | sunset | evening civil twilight | sunset_end |
| -6 | civil dusk | evening nautical twilight | dusk |
| -12 | nautical dusk | evening astronomical twilight | nautical_dusk |
| -18 | astronomical dusk | night | night_start |
I'm not sure that makes perfect sense, but that's the best I can tell.
Let me know what you think.
@n0nk I have an initial implementation that I'm testing out.
@pnbruckner,
Sorry for the delayed answer, i was on vacation. initial implementation good. If you want me to test or something else please let me know.
I don't know how to see the code of the actual deconz stuff
I dont know if you noticed, but the deconz sensor is based on this github project --> https://github.com/mourner/suncalc
Some states --> https://github.com/mourner/suncalc/blob/6bc2757074c1e5eaa2389aa2ab36806f04c6d2a0/suncalc.js#L102
So it seems to me that you picked the right states by sun angle :)
... it appears the states of the sensor are effectively the name of the previous event ...
that's also my understanding and how i used it. In automations i just checked the actual_state change event or checkd by time.
Let me know what you think.
I am happy that you develop this! 👍
I'm getting ready to check in the initial changes on a branch. I think it pretty much works, but I want to create a second option with states that I think make more sense, too. I need to massage the code a bit so both sensors can use the same code but with different data tables.
In any case, here's what the sensor looks like:
There are five instantiations, with locations that have the same longitude, but different latitudes: 80, 40, 0, -40 & -80. The top binary sensors are template sensors that show the value of the daylight attribute of the five phase sensors.
I dont know if you noticed, but the deconz sensor is based on this github project --> https://github.com/mourner/suncalc
Some states --> https://github.com/mourner/suncalc/blob/6bc2757074c1e5eaa2389aa2ab36806f04c6d2a0/suncalc.js#L102
Yes, I've seen that, and I've seen HA's deCONZ integration code, but not the code in the middle -- i.e., not the actual deCONZ code itself, so I don't know how it takes the results from the suncalc library and translates that into states.
In any case, here's what the sensor looks like:
Actually that looks great for me 🥇
... but not the code in the middle ...
Maybe this is the missing part? --> https://github.com/dresden-elektronik/deconz-rest-plugin/blob/ffda04e41a56947cf1aa0db53f98111bfdc4438c/daylight.cpp#L70
For me it does not look like suncalc is used as a library. It was more used for the calculation and gets ported
--> https://github.com/dresden-elektronik/deconz-rest-plugin/blob/78939ac4ee4b0646fbf542a0f6e83ee995f1a875/daylight.cpp#L15
Ah, thanks. I didn't try to find the deCONZ software, but that looks like it. And, yes, it does look like it's a port of the suncalc package. It did say "based on", which I took to mean "uses", but I guess it really meant "ported." 😄
Ok, I looked at pydeconz & deconz-rest-plugin, and everything I've done so far seems right, except for the daylight attribute. Despite the description on the HA deCONZ Daylight Sensor doc page, the daylight attribute is true between sunrise and sunset, which of course, makes more sense. I'll update accordingly.
At first i also assumed they used it as a lib. I am happy to "help" you.
Maybe you could tag the actual branch version as 2.x.x-b1 and prerelease it so i maybe would be able to add it direcly using hacs. ... At least i guess this should also work with branches but didn't find in die docs.