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

Share your Projects!
113

Ok phew, everything updated. Actually made a number of changes besides just the bug fix, all the others are minor though. Locally I converted to using Threshold sensors instead of Template Binary Sensors when appropriate so now the package is updated for that. Also updated to leverage the new update_available field instead of comparing version identifiers as that seems preferrable.

@pergola.fabio pinging you since we were discussing on that other post. You should be able to pull the new package or just tweak the curl command in that one sensor and be all set.

Ah perfect, thanks! And I see there is an API for observer in there so added a sensor for that now as well @DavidFW1960

1 Like
114

Yeah I already had a sensor for that… found it earlier.

I changed to your code for the supervisor updates. Thanks.

115

Hi, I experience that only than “HACS” sensor provides me with an update. Since a while (don’t know when but longer time ago) I do not seem to get a notification for any of the other sensors…

Is this by design versus the recent update of home assistant? And others experiencing this?

116

Hello,

Could someone please help me out with this one?

I’m trying to get snapshots list from supervisor and would like to get latest slug so I could restore it automatically with an automation if necessary. I’m unable to even get the parsed listing in to HA.

This is my latest take on this:

  - platform: command_line
    name: Snapshots
    command: 'curl http://supervisor/snapshots -H "Authorization: Bearer $(printenv SUPERVISOR_TOKEN)" | jq --slurpfile slugs found_snapshots.txt ''{"snapshots":[.data.snapshots[] | select(.slug as $slug | $slugs | index($slug) | not)]}'''
    value_template: '{{ value_json.snapshots | length }}'
    json_attributes:
    - snapshots
    - date
    - name
    - slug

And this results to error:

Logger: homeassistant.components.command_line
Source: components/command_line/__init__.py:41
Integration: command_line (documentation, issues)
First occurred: 19.32.06 (1 occurrences)
Last logged: 19.32.06

Command failed: curl http://supervisor/snapshots -H "Authorization: Bearer $(printenv SUPERVISOR_TOKEN)" | jq --slurpfile slugs found_snapshots.txt '{"snapshots":[.data.snapshots[] | select(.slug as $slug | $slugs | index($slug) | not)]}'
117

I’m not really sure what to make of your “found_snapshots” file, not really understanding how that’s connected to your use case. It sounds like you want to find the latest snapshot and store its slug in a sensor. Based on that the command I would use is this:

curl http://supervisor/snapshots -H "Authorization: Bearer $(printenv SUPERVISOR_TOKEN)" | jq '[.data.snapshots[]] | sort_by(.date) | last'

This gets the list of snapshots, sorts the list by date ascending, then just keeps the last one (which is the newest by date). You can then leverage that in a sensor like this:

- platform: command_line
  name: Latest snapshot
  command: 'curl http://supervisor/snapshots -H "Authorization: Bearer $(printenv SUPERVISOR_TOKEN)" | jq ''[.data.snapshots[]] | sort_by(.date) | last'''
  value_template: '{{ value_json.slug }}'
  json_attributes:
  - name
  - date
  - type
  - protected

Seems like that gets you everything you need to do what I believe you’re trying to do.

Is there some reason your capturing a list of snapshot slugs in a text file and using it to filter the list? If so you’ll have to explain why so I can try and figure out what’s going wrong. Doesn’t seem necessary to get the slug of the latest snapshot though since the data of each snapshot includes a date.

1 Like
118

Thank you for your effort and this did indeed work.

Little bit more background for this: I’m trying to build redundant/highly available HA backup server which would launch automatically if the main server drops offline. Otherwise the backup servers overlapping automations and processes are turned off with automation. Updating configs to two server is quite hindrance so I was looking to this matter by trying to restore latest snapshot automatically in backup server.

I simplified the sensor even more for my purpose:

- platform: command_line
  name: Latest snapshot
  command: 'curl http://supervisor/snapshots -H "Authorization: Bearer $(printenv SUPERVISOR_TOKEN)" | jq ''[.data.snapshots[]] | sort_by(.date) | last | .slug'''

This could have been enough for me but then I ran to another problem with shell_command: I tried to launch the restore in several ways:

shell_command:
   restore: 'ha snapshots restore "{{latest_snapshot}}"'

This didn’t work as the shell commands are run in homeassistant docker, not hassio-cli

Then I tried to proceed with

shell_command:
  restore: 'curl -X POST http://supervisor/snapshots/restore "{{latest_snapshot}}" -H "Authorization: Bearer $(printenv SUPERVISOR_TOKEN)"'

But ran to 405 method not allowed error.

After total of 24 hours trying to solve this I’ve given up for now. Some sources indicate that calling ssh command could bypass limitations, but I see here so much breaking possibilites that I have decided for now to do the “cloning” of main server to backup server by hand.

My daily samba backup -goes straight to backup server so this is quite good emergency solution for now. Well maybe this way I have more control over the backup server and I can test&try with it and I don’t have to think about the automatic backup system running over my unfinished tinkering.

119

On my phone at the moment so I can’t test this myself but I notice the URL you are using to restore seems to be incorrect. Here is the API for interacting with snapshots via supervisor. There are two APIs you can use to restore a snapshot via the API -

  • /snapshots/<snapshot>/restore/full
  • /snapshots/<snapshot>/restore/partial

The slug goes in the URL as a resource path parameter, not the body. The body is just the password for a full restore or the details of what to restore for a partial restore (and the password).

If you’re trying to restore on another system you might have to use the upload snapshot API to get the snapshot into the correct place first unless the two share a folder for backups.

Also just an FYI, to get the value of the latest_snapshot sensor your template should be {{ states('sensor.latest_snapshot') }} not {{ latest_snapshot }}.

Cool idea though! If you get it all working you should make a thread or guide about your setup. Would be great to have things auto fail over to a backup replica.

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.