Welcome back.
1 Like
Released 2.0.3
Handle Entity property name change
Starting with HA 2021.4 the Entity property device_state_attributes has been renamed to extra_state_attributes. This change supports the new name, as well as continues to support the old name for backwards compatibility.
2021.12.7
but still no warnings.
not a big deal at all. Just strange that I don’t get the warnings when I have gotten them before with other integrations (including mine). Just another HA mystery.
I’ll update to the latest anyway.
Did you search home-assistant.log? Depending on timing of how your system comes up, it’s possible the warning happens before the UI logging infrastructure is completely set up. I’ve definitely seen that some warnings in home-assistant.log, that happen very early after startup, don’t show up on the Logs UI page.
I never use the UI unless I have to. You should know that… 
and I checked the real log right after start up was complete (~ 5 minutes) and it never showed up.
1 Like
I’ve had a request to create a sensor that emulates the behavior of the deCONZ Daylight Sensor. See Request/Enhancement Sensor Daylight “actual_state” · Issue #58 · pnbruckner/ha-sun2 (github.com). I have an initial implementation. If anyone would like to give it a try, let me know. Also, if anyone has a functioning deCONZ Daylight Sensor, I’d be very interested to know how well my sensor emulates it. I could only find partial information about the details of it works.
I also plan to create another sensor that does basically the same thing, but which has states that I believe are more appropriate/useful. I’ll post back here when I start on it and have a better idea what the states will be. In the meantime, if anyone thinks they could use such a sensor, and has an opinion of what the states should be, by all means, let me know. I’m thinking something along the lines of:
night
morning_astronomical_twilight
morning_nautical_twilight
morning_civil_twilight
day
evening_civil_twilight
evening_nautical_twilight
evening_astronomical_twilight
night
I can also see a case for including the morning & evening blue & golden “hours” (which I understand overlap civil twilight and part of the day, where blue hour is between -6 & -4 degrees, and golden hour is either between -4 & 6 degrees, or -6 & 6 degrees, depending on where you read about them.)
2 Likes
Here’s what the initial implementation of the deCONZ Daylight Sensor emulator looks like (with five different instantiations, all with the same longitude, but with different latitudes: 80, 40, 0, -40 & -80):
1 Like
If anyone would like to try it you can get a copy from here:
Hi Phil!
that is a nice development. Ive tried the ‘real’ Deconz daylight sensor, but it never worked. I was interested in the SunCalc states of it, so glad you made a direct translation of it.
It was so promising, to have all of these states in 1 sensor. I was especially mesmerized by the Nadir which was what made me look into it, as I had never heard of it. As are the golden our states, which I actually use in hand made versions…
Id have a few cosmetic suggestions/requests:
use golden_hour_morning/evening instead of 1/2
would it be possible to ‘unslugify’ the states (lower case and underscores are not too nice to look at, and stand outa bit right now)
maybe even give it another name, why not Suncalc instead of deconz. Makes it a bit more generic and meaningful
lastly, some better fitting icons per state, or group of states, would make it even better in the frontend:
Anyways, thanks again for your efforts, Ill be happy to watch it happen and check if things are ok.
as for the second sensor you are considering: what would be the main difference with the current monitored conditions. I mean when would we use the one or the other… or would that simply be personal preference for a certain state one would be interested in?
btw I take it you are aware of GitHub - AitorDB/home-assistant-sun-card: Home assistant sun card based on Google weather design which has this nice graph card of the suns movement:
though the legend is a bit large, its a nice graphic. I wonder if something like that could be made out of the SunCal or Sun2 state for that matter.
As I understand it, it’s simply exactly 1/2 day away from solar noon, whereas solar midnight is actually the lowest point. But, I don’t know that the deCONZ sensor actually implements it that way. That’s part of the problem here … I’m working from vague descriptions and not the actual deCONZ code. I’ve seen the library it uses, and the HA integration code, but not how it uses the results from the library to come up with state values.
Which leads to an answer for some of your other questions. That is, I’m trying to faithfully emulate the deCONZ Daylight Sensor, not implement what makes sense to me. Hence, I’m using the same state values it uses, etc.
Regarding the icon, yep, I’ve thought it might make sense to have it change as the states change. That’s kind of on the to-do list. What I have so far is just an initial implementation to see if I’m anywhere close to what the deCONZ Daylight Sensor did.
Mainly states that make more sense to me. And, sure, I could use nicer (unslugified) state values.
Isn’t deCONZ a hardware device? Am I missing something here? is this an emulator for that? How does it work?
I’d wondered the same thing…
Looks like it’s a non-hardware sensor that’s built into the deCONZ integration that tells you whether it’s light/dark where you are (along with other attributes as noted above)
There’s a note about it here…
As I said above:
I’ve had a request to create a sensor that emulates the behavior of the deCONZ Daylight Sensor . See Request/Enhancement Sensor Daylight “actual_state” · Issue #58 · pnbruckner/ha-sun2 (github.com)
My understanding is there’s some deCONZ hardware/software system that integrates with HA. That can create a sensor in HA whose state somehow reflects the current “phase” of the sun. (According to the descriptions on the HA integration page, this is a “special” software-only based sensor in the deCONZ software package, that itself uses the “suncalc” package, as opposed to my custom integration, and HA itself, that use the astral package.)
UPDATE: I was just pointed at the deCONZ implementation of this, and it appears it doesn’t use suncalc, but rather based its own implementation on the suncalc package. I.e., it ported it. So now I can hopefully get a more concrete idea of how this sensor.daylight actually works rather than trying to guess based on clues. 
So, yes, this is strictly meant to be an emulation of that HA / deCONZ sensor. Although I do plan to create a variant that has states that make more sense to me (along the lines of what I suggested above.
1 Like
so we won’t need to use the deCONZ integration it will just have an emulator in sun2 for that sensor?
Well, of course deCONZ does a lot more than this one software-only sensor, but yes, my sun2 custom integration will have a new sensor option to emulate the deCONZ Daylight Sensor, but it does so without any interaction with the deCONZ-related integration or a deCONZ system.
2 Likes
I think what I’ll do for this variant of the sun phase sensor is to have states similar to those described above, and for blue hour & golden hour I’ll have attributes for them (again, since they overlap with the civil twilight periods and partially with day.) And since it’s easy, I’ll probably have another attribute for rising. These will be Boolean attributes so it would be easy, e.g., to do something like:
{{ state_attr('sensor.sun_phase', 'golden_hour') and
state_attr('sensor.sun_phase', 'rising') }}
With that in mind, would it be better to remove the morning/evening prefixes from the twilight states? If someone wanted to differentiate, then simply use the rising attribute.
Oh, and “de-slugifying” the states, we’d then have:
Night
Astronomical Twilight
Nautical Twilight
Civil Twilight
Day
with three Boolean attributes:
rising
blue_hour
golden_hour
That’s what I’ll do unless someone thinks strongly otherwise.
For the new phase sensors, see:
Add phase sensors by pnbruckner · Pull Request #60 · pnbruckner/ha-sun2 (github.com)
Since you ask… imho, I like the sensor names to be descriptive on their own, and adding morning and evening adds to that. Like with the golden hour sensors. not _1/_2 but _morning/_evening.
I feel that would be more concise than needing to add/check the rising attribute (which in itself is very nice indeed)
hope this makes sense…
thx!
btw, anything will be better than the ‘real’ Deconz sensor, it never worked at all I my setup
I guess it depends on how one intends to use the sensor. If they just care whether or not it is, say, golden hour, and they don’t care whether it’s in the morning or evening, then not having the morning/evening prefix or suffix would be better. Again, they can still use the rising attribute to differentiate if they want.
But if it was more likely that the use cases do need to differentiate, then yes, I could see using the prefixes would be helpful. But on the downside, it does make long state names even longer.
For now, I’m going to go without the prefixes. If anyone really, really, really wants them, I could always add it as an option.
Regarding the states of the deCONZ emulated sensor, I’m trying to make it as close as possible to the way that works (or is supposed to work.) This all stated with someone who had been using it and really missed it. This way any existing automations, etc., should still basically work as-is. Also, I don’t personally really care about it. I much prefer the other phase sensor option.
Hi there,
I was pointing to this thread, because I search for a possibility to create a value to below_horizon -30min. Sometimes it is really dark minimal before the sunset. And it seems to be a time difference between sunset and the value below horizon works.
Releated to Alternatives to below horizon
If I understand it right, I can use the elevation, but should my value above or under the default -0.833?
elevation:
above: -0.833 #( more or less)
name: before_sundown
Thanks Micha