Enhanced Sun component

pnbruckner · March 30, 2022, 9:16pm

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.

pnbruckner · March 30, 2022, 9:42pm

pnbruckner:

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

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.

pnbruckner · April 1, 2022, 8:35pm

For the new phase sensors, see:

Add phase sensors by pnbruckner · Pull Request #60 · pnbruckner/ha-sun2 (github.com)

Mariusthvdb · April 1, 2022, 9:23pm

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

pnbruckner · April 1, 2022, 10:02pm

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.

Micha-Btz · April 3, 2022, 12:51pm

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

pnbruckner · April 4, 2022, 6:27pm

I suggested a solution in your original topic which does not require the use of my custom sun2 integration.

But to answer your specific question, the binary elevation sensor does not have an option for below; it only accepts above, with the default value being -0.833. So, if you configure:

binary_sensor:
  - platform: sun2
    monitored_conditions:
      - elevation

You’ll get a sensor named binary_sensor.above_horizon that will be on between sunrise and sunset, and off otherwise.

pnbruckner · May 3, 2022, 10:38pm

Released 2.1.0

Add phase sensors

Add new sun phase sensors. One emulates the behavior of the deCONZ Daylight Sensor. The other has more common states and other useful attributes.

pnbruckner · June 13, 2022, 3:13pm

Released 2.1.1

Fixed a typo that caused blue hour attribute to be wrong and rising attribute to be missing for the new sun_phase sensor.

Mariusthvdb · June 17, 2022, 5:35pm

Hi Phil,

maybe I just didnt see it because of the time of year, but currently, the warning for Sun elevation in binary_sensor Astronomical Dawn shows 3 times during a regular startup sequence:

once at the very beginning, and twice at the very end:

<snip>
2022-06-17 17:40:37 WARNING (SyncWorker_5) [homeassistant.loader] We found a custom integration sun2 which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant

<snip>


2022-06-17 17:40:41 WARNING (MainThread) [custom_components.sun2.binary_sensor] Astral Above Astronomical Dawn: Sun elevation will not reach -18.000000 again until 2022-07-22


<snip>


2022-06-17 17:43:00 WARNING (MainThread) [custom_components.sun2.binary_sensor] Astral Above Astronomical Dawn: Sun elevation will not reach -18.000000 again until 2022-07-22
2022-06-17 17:43:03 WARNING (MainThread) [custom_components.sun2.binary_sensor] Astral Above Astronomical Dawn: Sun elevation will not reach -18.000000 again until 2022-07-22
2022-06-17 17:43:10 INFO (MainThread) [homeassistant.setup] Setting up ffmpeg
2022-06-17 17:43:10 INFO (MainThread) [homeassistant.setup] Setup of domain ffmpeg took 0.2 seconds

<ready>

is this to be expected?

yaml:

binary_sensor:

  - platform: sun2
    entity_namespace: astral
    monitored_conditions:
      - elevation:
          above: -18
          name: Above Astronomical Dawn

pnbruckner · June 17, 2022, 6:29pm

The reason there are three warning messages is because the entity is being updated three times. The first one is when the entity initializes itself. The other two are due to the HA core firing the core_config_updated event twice during system startup:

2022-06-17 13:16:05 INFO (MainThread) [homeassistant.core] Starting Home Assistant
2022-06-17 13:16:05 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event core_config_updated[L]>
2022-06-17 13:16:05 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event homeassistant_start[L]>
2022-06-17 13:16:05 DEBUG (MainThread) [custom_components.sun2.binary_sensor] Astral Above 71.86: above = 71.860000, elevation = 71.252818
2022-06-17 13:16:05 WARNING (MainThread) [custom_components.sun2.binary_sensor] Astral Above 71.86: Sun elevation will not reach 71.860000 again until 2022-06-19
2022-06-17 13:16:05 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event core_config_updated[L]>
2022-06-17 13:16:05 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event homeassistant_started[L]>
2022-06-17 13:16:05 DEBUG (MainThread) [custom_components.sun2.binary_sensor] Astral Above 71.86: above = 71.860000, elevation = 71.252818
2022-06-17 13:16:05 WARNING (MainThread) [custom_components.sun2.binary_sensor] Astral Above 71.86: Sun elevation will not reach 71.860000 again until 2022-06-19

I don’t know why HA fires this event twice, but there’s not much I can do about it, since the entity needs to update if the core config (i.e., location) is updated. Now, of course, the config isn’t being updated, but for some reason the core fires this event two times anyway.

I suppose I might be able to filter out any messages that happen before the homeassistant_started event, but I’m not sure that wouldn’t hide potential other issues.

EDIT: I added code to filter out any errors or warnings until after the core is fully running. That filters out the first two occurrences of that message, and now it will only show up once (unless, of course, you do update the core config. )

I also found a bug which I’ll fix, too, and release a new version soon.

pnbruckner · June 17, 2022, 6:53pm

Released 2.1.2

Filters out binary sensor warning or error messages before HA core is fully running. Before this, as discussed above, these messages showed up three times in the log. Now they should only show up once.

Also fix bug in elevation binary sensor if threshold is never reached.

Mariusthvdb · June 17, 2022, 7:06pm

Let’s ask @bdraco . Nick pardon the tag, but since we/you’re in the process of optimizing the startup, it seemed quickest to copy you in this .
If nothing please ignore

bdraco · June 17, 2022, 7:24pm

Its been a while, but I think when we added it in Make the frontend available sooner (Part 1 of 2) by bdraco · Pull Request #36263 · home-assistant/core · GitHub, its for:

github.com

home-assistant/home-assistant-js-websocket/blob/2aaaf3c3a80090e3a00a0e7de5119c793cd251d5/lib/config.ts#L33


      
          
          const fetchConfig = (conn: Connection) => getConfig(conn);
          const subscribeUpdates = (conn: Connection, store: Store<HassConfig>) =>
            Promise.all([
              conn.subscribeEvents(
                store.action(processComponentLoaded),
                "component_loaded"
              ),
              conn.subscribeEvents(
                () => fetchConfig(conn).then((config) => store.setState(config, true)),
                "core_config_updated"
              ),
            ]).then((unsubs) => () => unsubs.forEach((unsub) => unsub()));
          
          export const configColl = (conn: Connection) =>
            getCollection(conn, "_cnf", fetchConfig, subscribeUpdates);
          
          export const subscribeConfig = (
            conn: Connection,
            onChange: (state: HassConfig) => void
          ): UnsubscribeFunc => configColl(conn).subscribe(onChange);

pnbruckner · June 17, 2022, 7:53pm

So, it seems it was something to get the frontend to respond to core state changes (even if the actual “config” hasn’t changed.) Hmm, seems like there should be two different events then: one just for actual config changes (that would most likely be used just in the backend), and a state changed event (that maybe??? includes config changes as well as actual state changes.) Hmm. Seems kind of disruptive to fire an event multiple times for “config” changes when the config isn’t actually changing, causing possibly many entities to update for no reason. But, I suspect it might be more complicated than that.

bdraco · June 17, 2022, 8:04pm

It could definitely be made more efficient. Since there is long list of things that are far less efficient ahead of it, I expect it may be a while before we get there. The good news is that we have been making great progess in this area recently so the list is shrinking instead of growing which is a nice change.

Mariusthvdb · June 17, 2022, 10:26pm

hehe, we all know you’re on top of it.

so should we make an issue of sorts: or is it on your list now
no hurry, just dont forget…
please.

bdraco · June 17, 2022, 10:28pm

Probably something to remind me about in 3-4 months once we are through this cycle of optimizations

Mariusthvdb · June 17, 2022, 10:30pm

sure!
note to self (“dont forget”) I am terrible at that.
especially now Phil filters the messages…
great

cowboysdude · June 19, 2022, 3:40pm

Trying to get this as a sensor… since i have my sensors in my config like this…

sensor: !include_dir_merge_list includes/sensors/

I can’t just put the straight config in my config file so I have to actually create a sensor in the sensors dir…
Keep getting errors…

- platform: sun2
  sensors:
    sun2:
      monitored_conditions:
        - solar_midnight

Invalid config for [sensor.sun2]: [sensor] is an invalid option for [sensor.sun2]. Check: sensor.sun2->sensor. (See ?, line ?).

It’s setup correctly but where’s the error I’m not seeing it…