Enhanced Sun component

Mariusthvdb · March 30, 2021, 2:12pm

yes, you’re right, the availability sensor on my binary_sensor vijverpompen doesnt help.
And yes, they are being recreated (show yellow in the frontend and state entity is unavailable)

The set of conditions doesnt help either. I’ve only been able to prevent this automation from triggering by adding the additional condition in the action block:

  - alias: Vijverpompen aan
    id: Vijverpompen aan
    trigger:
      platform: state
      entity_id: binary_sensor.vijverpompen
      from: 'off'
      to: 'on'
    condition:
      - >
          {{trigger.to_state.state != 'None'}}
      - >
          {{trigger.from_state is not none and
            trigger.to_state is not none and
            trigger.to_state.state != trigger.from_state.state}}
    action:
      - condition: state
        entity_id: input_boolean.vijverpompen_alterneren
        state: 'on'
      - service: input_boolean.turn_off
        entity_id: input_boolean.vijverpompen_alterneren

this being the binary:

    vijverpompen:
      friendly_name: Vijverpompen
      value_template: >
        {{states('sensor.pond_tools_buiten_sensor_calibrated_temperature')|float > 6 and
          is_state('binary_sensor.outside_daylight_sensor','on')}}
      delay_off:
        minutes: 60

this is straying form the threads topic though, sorry.

pnbruckner · March 30, 2021, 3:40pm

Mariusthvdb:

    trigger:
      platform: state
      entity_id: binary_sensor.vijverpompen
      from: 'off'
      to: 'on'
    condition:
      - >
          {{trigger.to_state.state != 'None'}}
      - >
          {{trigger.from_state is not none and
            trigger.to_state is not none and
            trigger.to_state.state != trigger.from_state.state}}

There’s a few things about this that don’t make sense.

First, you’re specifying both from: & to: in the trigger, so this should not trigger when the sensor gets deleted or added (i.e., at startup, at shutdown, or when the template sensor is reloaded.)

Second, because of the trigger, it will only fire when trigger.from_state.state is 'off' and trigger.to_state.state is 'on', so none of the conditions are needed.

Lastly, this certainly doesn’t help (and probably hurts):

      - >
          {{trigger.to_state.state != 'None'}}

If trigger.to_state is none (which, of course, can’t happen per the above, but in general, if it could be), then trigger.to_state.state doesn’t make sense and probably causes an error.

But, yes, I think we’ve strayed off topic a bit.

pnbruckner · April 2, 2021, 6:38pm

Looks like HA will be updating the astral package from 1.10.1 to 2.2 in an upcoming release (presumably 2021.4.) See PR #48573. That change breaks this custom integration. (E.g., it broke using a HA dev checkout.) See Issue #32.

I think I’ve fixed it so that it will continue to work ok with current and previous HA releases (that use astral 1.10.1), as well as newer releases (that use 2.2.) See PR #33. I’ve tested it with a HA dev checkout, as well as with 2021.3.4. If anyone else could give it a try, either with a current HA release, and/or with a dev checkout, it would be greatly appreciated!

paddy0174 · April 2, 2021, 8:15pm

What should one do?

pnbruckner · April 2, 2021, 8:23pm

If you know how to use the code from github, then by all means, give it a try. If not, then I plan to release a new version before the next HA release, and then you can just update the custom integration at that time. If all goes well you shouldn’t run into any problems (as long as you update the custom integration before updating HA to the new version that uses the new version of the astral package.)

Mariusthvdb · April 2, 2021, 9:11pm

can confirm the updated version is working perfectly under 2021.4.0b2.
Thanks for updating!

As a matter of fact, it doesnt even trigger:

WARNING (MainThread) [homeassistant.loader] You are using a custom integration

etc etc

pnbruckner · April 2, 2021, 9:20pm

Released version 1.8.3

Handles upcoming change to HA (related to the astral package, and also provides backwards compatibility to existing HA version.)

paddy0174 · April 2, 2021, 10:35pm

OK, that was too fast for me… Just wanted to try, and there it is, the new version.

Updated to 1.8.3, can’t report any errors so far. I didn’t check the exact times, but I guess that should work. I still have the warning about a custom_component, but that is expected as well. On my installation everything works fine, thanks for the update!

pnbruckner · May 5, 2021, 9:00pm

Released 2.0.0

A request was made to support creating entities that show sun data for alternate locations. It wasn’t too hard, so I did it!

The default is still to use Home Assistant’s location configuration. But it’s now possible to use that location, another location, both, or multiple locations. Each “- platform: sun2” entry will accept new optional location parameters. See doc for more details.

EDIT:

Oh, I wanted to also make note of a slight change of behavior regarding the friendly_name attribute when using the optional entity_namespace configuration parameter. entity_namespace did not use to affect the friendly_name, but now it does.

I decided to do this to help differentiate multiple entities of the same type, but at different locations. E.g., let’s say you want sunrise entities for HA’s location config, as well as another location. So:

sensor:
  - platform: sun2
    monitored_conditions: sunrise
  - platform: sun2
    monitored_conditions: sunrise
    latitude: ...

Without using entity_namespace this would create two sensors with ID’s sensor.sunrise and sensor.sunrise_2, both with a friendly_name of “Sunrise”. Not very helpful.

Using entity_namespace (even without the change I’m talking about) would be slightly helpful. E.g.,

sensor:
  - platform: sun2
    entity_namespace: Home
    monitored_conditions: sunrise
  - platform: sun2
    entity_namespace: Beach
    monitored_conditions: sunrise
    latitude: ...

This would create entities with IDs sensor.home_sunset and sensor.beach_sunset, but still, they’d both have the same friendly_name of just “Sunrise”. So better, but still not great.

Now (i.e., in 2.0.0), the entity IDs would be as just stated, but their friendly_name attributes would be “Home Sunset” and “Beach Sunset”, respectively. Much better!

BUT, this means if you were using entity_namespace before, the friendly names of your entities will change. If you don’t want that (i.e., you want to change them back to what they were), just use the standard customization capabilities. Or you can even rename them in your Lovelace configuration I suppose.

DavidFW1960 · May 5, 2021, 9:24pm

Nice update!

Mariusthvdb · May 6, 2021, 8:06am

yes, +1 to that, beautiful and elegant, while great in new functionality. Thanks Phil!

dang12 · May 6, 2021, 9:58pm

I know this is a total noob question, but I have an older version installed, how do I manually update since the newest Core update broke the configuration? Thanks.

pnbruckner · May 6, 2021, 10:00pm

Just follow the installation instructions (like you did originally), overwriting the existing files in your install. Then restart HA.

paddy0174 · May 6, 2021, 10:31pm

Or use HACS. Makes it easier, and if you’re already around doing updates…

dang12 · May 6, 2021, 11:18pm

Thanks! I did a copy paste job and must have missed something

dang12 · May 6, 2021, 11:18pm

This is a manual install unless I’m missing something??

DavidFW1960 · May 6, 2021, 11:25pm

you can add the repo as a custom repo in HACS. It is compliant.

dang12 · May 6, 2021, 11:50pm

Thanks! I was able to add and working now. I appreciate the help!

paddy0174 · May 7, 2021, 12:34am

Sorry, should have been more explicit. Thanks @DavidFW1960 for pointing it out.

pnbruckner · May 20, 2021, 1:38pm

Released 2.0.1

Old version of astral package used to throw its own AstralError. Now it can throw TypeError or ValueError. Was only handling TypeError in 2.0.0. Now catch ValueError, too.