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

[e-raser]

Thanks for explanation. I already changed it for my HA instance, getting slowly used to that YAML stuff.

Not quite long on board so good point if there are cases like forced rollbacks (where an update actually is a downgrade) it´s probably even better to not use the greater than operator instead use your setting or rely on the update_available information. Would depend on what those states are in a “forced rollback/downgrade” scenario, for the moment I´m fine.

And once again: many many MANY thanks for this topic, this was exactly what I was missing out of the home assistant box and you served it, just perfect.

[duncan86 (Duncan Bloom)]

Hi Guys, I hope someone here can help me.
I’m trying to set up a sensor to show the current and latest version of an addon with the steps provided in this thread.

  - platform: rest
    resource: https://192.168.2.202:8123/api/hassio/addons/core_check_config/info
    name: Check Home Assistant configuration
    value_template: '{{ value_json.data.state }}'
    scan_interval: 60
    headers:
      Authorization: !secret llt_addons
      Content-Type: application/json
    json_attributes_path: "$.data"      
    json_attributes:
      - version
      - version_latest  

I’ve been trying to get this sensor to work for a few days now. But for some reason it just doesn’t create the sensor. Whenever I try to find it, it just doesnt show up.

I really hope someone can explain it to me.

[CentralCommand (Mike)]

Well to start you probably have to add verify_ssl: false to your sensor. Since that’s a local IP address whatever SSL certificate you are presenting is either self-signed or for a different domain entirely since CAs won’t issue SSL certificates for private IP addresses.

Also it looks like you’re providing Content-Type: application/json as a header which is weird since its a GET call and has no request body. Did you mean to put Accept: application/json to specify that you want JSON back? Not sure if that’s necessary or not but it makes more sense then providing Content-Type without a postbody.

Also only you can verify this but make sure your llt_addons secret is of the format Bearer <a valid token>.

I’m guessing it was blowing up on the SSL certificate since it looks correct other then that. Maybe the extraneous Content-Type header but most APIs just ignore that on a GET call.

[duncan86 (Duncan Bloom)]

Why didnt that occur to me before…
The verify_ssl did the trick. Big thanks!

[e-raser]

Update notifications don´t work sometimes, sometimes they do. E. g. update to HA Core 2021.1.4 is shown in the UI, but did not fire my automation.

Any idea what to check?

Clearly available:

Automation with notification:
Last time fired: two days ago (for HA Core 2021.1.3)

alias: Notify_System_Update HA Core verfügbar
description: ''
trigger:
  - platform: state
    entity_id: binary_sensor.updater
    to: 'on'
condition: []
action:
  - service: notify.all_devices
    data:
      title: "Update available \U0001F7E2"
      message: >-
        HA Core {{ state_attr('binary_sensor.updater', 'newest_version') }} is
        available.
      data:
        subtitle: ''
        push:
          thread-id: updates-notification-group
mode: single

[CentralCommand (Mike)]

Huh, that is really confusing. I’ve had issues with not receiving notifications before due to end device state but never with ha not firing an automation when it obviously should. If you go to developer tools you can manually set binary_sensor.updater to on and off to test it. Does it work when you do that at least?

[e-raser]

Yes, this time it worked.

Really strange. Even HA reboots should not affect the automation trigger detection I guess. I have absolutely no idea… logs empty of course.

Will continue monitoring this a few more days/weeks.

[e-raser]

Next occurence:

Supervisor shows HA Core update:

HA Core Updater (“binary_sensor.updater”) states:

This seems to not be related to the additional update sensors at all, but it´s very strange… did someone else discover this behaviour too?

[DavidFW1960 (David)]

That binary sensor only updates once a day so you cannot rely on it.

[e-raser]

Well… that´s okay if it´s not a security update. Higher update intervals would be a possible solution.

[DavidFW1960 (David)]

it’s hard coded for that binary_sensor. This thread gives you other ways to be notified almost immediately so if that is a concern for you, use that rather than the binary sensor.

[e-raser]

@DavidFW1960

This thread gives you other ways to be notified almost immediately so if that is a concern for you, use that rather than the binary sensor.

Not sure if you´re familiar with this thread… I spent many hours here, so… look :

@CentralCommand

For Core and HACS we’re good to go since those come standard with binary_sensor.updater for Core and sensor.hacs for HACS. However there is no sensor for Supervisor and its addons so we need to make one.

[DavidFW1960 (David)]

@e-raser

Not sure if you´re familiar with this thread

Well I have posted to it a bunch of times so I guess I’m familiar.
I don’t use his sensor as I already had my own…

[CentralCommand (Mike)]

Yea that’s my bad, I need to update that. Early on after I posted it and started using this package one of the first things I noticed was that binary_sensor.updater was wayyyy too slow for me. When I started digging into making update sensors for the other components of supervisor (after @DavidFW1960 pointed it out actually) I realized I should just make my own for core. I mentioned it here:

@CentralCommand

And I personally was finding the binary_sensor.updater far too slow to react to updates to core being available so I replaced it with my own command_line sensor for that purpose.

There’s two packages on the initial post. One is the base package that I posted initially, the second one includes a lot more update sensors for the various supervisor components and includes a much faster sensor for core. Here it is if you want to add it. With this one you can set the scan_interval to whatever you want:

sensor:
  - platform: command_line
    name: Updater Core
    command: 'curl http://supervisor/core/info -H "Authorization: Bearer $(printenv SUPERVISOR_TOKEN)" | jq ''{"newest_version":.data.version_latest,"current_version":.data.version, "update_available":.data.update_available}'''
    value_template: "{% if value_json.update_available %}on{% else %}off{% endif %}"
    json_attributes:
    - update_available
    - newest_version
    - current_version

[e-raser]

Other automations (e. g. for Supervisor Addons) don´t trigger too from time to time.

What do your automations look like @CentralCommand?

Until now I checked if the updater sensor switched to “True” to fire my notification.
That obviously didn´t work reliably, maybe (wild guess) because that switch to “True” sometimes happens during HA restarting and the automation doesn´t get triggered (due to maybe HA not being fully started yet?).

Now I´m thinking of setting a time pattern as trigger (e. g. “every 3 hours”) and setting the check if sensor state is “True” as a condition.

Problems with this strategy:

• Obviously:
  notifications/actions will be fired every time according to time pattern. Receiving a notification ONCE is enough… don´t know how to work around that from the automation perspective
• Possibly:
  ending up in the same situation (automation not getting triggered).

I was wondering how you guys set up your notification automations.

[tom_l]

Just triggering on the sensor changing to the true state, I’ve never missed one.

[e-raser]

So like I do. No idea why notification automations don´t trigger sometimes.

When I manually set the sensor in the developer settings, automation triggers instantly:

So still a complete miracle to me why it´s not reliably working…
(one indication: there is a correlation between automations not being triggered when sensor state changes and at the same time or only few minutes before HA is being restarted)

1. HA restarted @ 19:00:33
   

2. Updater sensor changed state to true @ 19:02:22
   

   

3. Automation history: it did NOT fire…
   

   
   
   History should contain an entry like
   Has been triggered by state of sensor.updater_addons @ roughly 19:02:XX - but it doesn´t
   Let´s see what others use or if someone has an idea.

[CentralCommand (Mike)]

I have had issues with triggers not firing when the state changed during a restart. I can’t think of any specific examples off the top of my head but it is something I’ve struggled with before.

But I actually don’t use automations at all with update notifications. In the package at the top you can see there’s a whole bunch of alerts, that’s what I use. They’re basically automations specifically for the use case of notifying you of a situation.

I have noticed with alerts that occasionally I’ll miss the first one for a similar reason (state changed during a restart). But that’s not a big deal with alerts since they have a built-in reminder feature so I’ll get the second one even if I somehow miss the first.

[alessiocamaioni (LxS)]

Hi, I have problems with alerts the reference sensors are ON but the alerts remain on idle.

Only the HACS alert works for me

[CentralCommand (Mike)]

I’ve never seen that. Really don’t know what to make of that. Might have to report a bug I guess but its not something I’ve ever seen and I use tons of alerts in my system for all sorts of things.