Update notifications! Core, HACS, Supervisor and Addons (now a blueprint!)

Share your Projects!
120

Just FYI, the following sensor:

- platform: command_line
  name: HassOS Installed Version
  command: 'curl http://supervisor/host/info -H "Authorization: Bearer $(printenv SUPERVISOR_TOKEN)"|jq ''{"hassos":.data.operating_system}'''
  value_template: "{{ value_json.hassos[7:] }}"

Needs to be updated to this in 2020.12:

- platform: command_line
  name: HassOS Installed Version
  command: 'curl http://supervisor/host/info -H "Authorization: Bearer $(printenv SUPERVISOR_TOKEN)"|jq ''{"hassos":.data.operating_system}'''
  value_template: "{{ value_json.hassos[18:] }}"
1 Like
121

I know … but would be possible to put all this in a blueprint?
Thanks

1 Like
122

No. It’s a sensor not an automation.

123

I was just thinking at the notification part (all the rest is more or less the same for everyone, so the code doesn’t change, the only thing that could be difference is how the notification is done …).
I am wrong?

124

Well not wrong, just incredibly vague. You replied to a post about a sensor and were talking about blueprints (which I couldn’t care less about, so you’re on your own there).

125

I’ll think about it. I would probably need to break this up into about 10 different blueprints and packages though. Each alert would become a blueprint and then I’d have to include a package you would need to install as well to have the sensors it depends on. Also the alert would probably not be repeatable like an alert is since to do that I would have to copy the logic this blueprint put together into each one.

I also am not sure how I feel about posting complex reusable assets like that which I am not using myself since then I’m essentially making other users my beta testers. Alerts are so much cleaner and simpler so there’s no way I would switch my system to use automations for notifications when alerts are available. Plus you can’t make a selector for a notification service or a device with a notification service currently, the best you can do is make a selector for devices of type mobile_app which is a lot more limiting. I don’t use the mobile app’s service for notifications myself so that would be another blocker for me to be able to adopt my own work.

I think I will wait for now to see what comes out next release before making any significant changes. Blueprints are clearly front and center on the HA team’s mind so I imagine they will be aggressively updated in the near future. I also notice there’s quite a lot of blueprints about notifications right now so I’m hoping there are some changes designed to make that easier. I think instead I may spend some of my time over break to take a look under the hood instead and see what it would take to add support for blueprints of type alert as then it would be easy to turn this into blueprints.

2 Likes
126

Many thanks … I got your point.

127

Great! I was looking for a central notification setup for all the important updates (not sure why it’s not part of the default setup yet):

  • HA Core
  • HA Supervisor
  • HASS OS
  • HACS
  • deCONZ Firmware

And this thread is like a jackpot. Even one of my first thoughts was „Well, a blueprint would be great, right?“ I‘m going to implement it as it is. Will also dig through all the posts to make sure not to miss important updates to the code in case the initial post has not been updated meanwhile.

Thanks again for sharing!

129

1st issue:
Using the device_class: problem does not work for me, therefore in lovelace UI the state_color: true does not work unfortunately.

I get errors in config check:

Invalid config for [sensor.template]: value is not allowed for dictionary value @ data['sensors']['updater_addons']['device_class']. Got 'problem'
value is not allowed for dictionary value @ data['sensors']['updater_hacs']['device_class']. Got 'problem'
value is not allowed for dictionary value @ data['sensors']['updater_supervisor']['device_class']. Got 'problem'. (See ?, line ?).

What I use instead: icon_template: 'mdi:update'
The config check errors still appear even if those icon_template lines are removed.

Probably a syntactical problem. Anyway, also automations are shown with state_color: true in lovelace UI. Tried to change the device class using the customize options, but that only gives me

grafik
grafik370×635 14.5 KB

So how to fix it in the .yaml, ideas?

2nd issue:

The 'entity_id' option is deprecated, please remove it from your configuration

How to fix that?

130

That device class is for a binary sensor, not a sensor.

Sensor device classes: https://www.home-assistant.io/integrations/sensor/#device-class

Binary sensor device classes: https://www.home-assistant.io/integrations/binary_sensor/#device-class

Likewise, state colour only works for devices with binary states. e.g. switches, input booleans, binary sensors. Not the sensor domain.

For your 2nd issue remove the key entity_id: form all your template sensors. Just like it says in the warning.

131

Thank you, that makes sense.

For #2:

So what will stay in that part?


- platform: template
  sensors:
    # True if there's an update available for supervisor
    updater_supervisor:
      friendly_name: 'Updater - Supervisor'
      device_class: problem
      entity_id:
      - sensor.supervisor_updates
      value_template: "{{ state_attr('sensor.supervisor_updates', 'update_available') }}"
      availability_template: "{{ (states('sensor.supervisor_updates') | int(-1)) > -1 }}"

    # True if there's updates available for any HACS components
    updater_hacs:
      friendly_name: 'Updater - HACS'
      device_class: problem
      entity_id:
      - sensor.hacs
      value_template: "{{ states('sensor.hacs') | int > 0 }}"

    # True if there's updates available for any addons
    updater_addons:
      friendly_name: 'Updater - Addons'
      device_class: problem
      entity_id:
      - sensor.supervisor_updates
      value_template: "{{ states('sensor.supervisor_updates') | int > 0 }}"
132

Bad indentation lines 26 and 29!

133

@CentralCommand can you please update your yaml config in the OP to fix the

The 'entity_id' option is deprecated, please remove it from your configuration

warnings? I´m not familiar enough with YAML yet. Just remove the entitiy_id lines as suggested by @tom_l won’t work, keeping the lines below (e. g. sensor.*updates) as is or with name: sensor.*updates) also doesn’t.

134

It’s not rocket science, e.g. this:

- platform: template
  sensors:
    updater_supervisor:
      friendly_name: 'Updater - Supervisor'
      device_class: problem
      entity_id: ### <--------------- Remove this ###
      - sensor.supervisor_updates ### and this ###
      value_template: "{{ state_attr('sensor.supervisor_updates', 'update_available') }}"
      availability_template: "{{ (states('sensor.supervisor_updates') | int(-1)) > -1 }}"

Becomes this:


- platform: template
  sensors:
    updater_supervisor:
      friendly_name: 'Updater - Supervisor'
      device_class: problem
      value_template: "{{ state_attr('sensor.supervisor_updates', 'update_available') }}"
      availability_template: "{{ (states('sensor.supervisor_updates') | int(-1)) > -1 }}"

Do the same for every template sensor.

1 Like
135

Why aren’t you just using the package file, that is noted in the first post? It is up to date and runs just fine (removing the two indentation errors). The only thing you may need to change is the notifier.

136

Did not see it until now. But even that code still contains deprecated entity_id options.

That worked. Thought the entitiy_id is a reference for further attributes - but it´s just unnecessary part of yaml code. My deprecated warnings are gone now, thanks folks.

137

Huh, when did that slip in, I’m sorry about that, both indentation errors are fixed now. Thanks for pointing that out.

1 Like
138

I updated the package to fix the indentation errors pointed out but there were no template sensors in the package which had entity_id, that had been fixed already. The package is mostly using threshold sensors now since I realized that was an easier way to get a binary sensor which is true when a number is greater then 0 (and those require the entity_id field). I updated the details post to do the same thing as the package for sensor.updater_hacs and sensor.updator_addons and fixed sensor.updater_supervisor to no longer have entity_id

1 Like
139

It does? :slight_smile: I can’t see any. :smiley: You do realise, entity_id is only deprecated for a template sensor, not for all occurrences… :wink:

I’d start “fresh” in your case. Remove your entries and copy the “new” package/version from the first post. Change the notofier, if necessary, and you are good to go. :slight_smile: Another advantage is, whenever there is an update, you just need to copy it from here and are good to go. :slight_smile:

140

Everything is fine and working for me even with the “old” template sensor based approach I will keep now, thanks. As you can see

CentralCommand even updated the OP meanwhile.