Keeping the system up to date

Configuration
1

We are using HassOS on Raspberry Pi 4, so there are 3 layer to keep updated:

  1. HassOS
  2. Supervisor
  3. Core

The goal is to have a zero touch system with the latest and greatest. To keep updating it is quite tedious.
The first 2 components are more stable, so auto-update approach for them seems appropriate. The core is trickier as major versions contain many breaking changes, so they require more attention. Minor versions for core seem also quite safe for auto-update mechanism.
We also have a daily backup (by the “Google Drive Backup” add-on), which is a safety-net in case something goes wrong with the auto-update (which never happened for us).

Here is how we implemented the above:

automations.yaml

- id: ha_new_version
  alias: ha_new_version
  trigger:
    - platform: state
      entity_id: binary_sensor.home_assistant_versions_update_available
  condition: "{{ int(states('sensor.home_assistant_versions').split('.')[-1]) == 0 }}"
  action:
    - variables:
        message: >
          Version {{ states('sensor.home_assistant_versions') }} is available.
          The installed one is {{ states('sensor.current_version') }}.
    - service: notify.mobile_app_amits_phone
      data:
        message: "{{ message }}"
    - service: notify.gmail
      data:
        title: "Home Assistant New Version"
        message: "{{ message }}"
- id: ha_new_minor_version
  alias: ha_new_minor_version
  trigger:
    - platform: state
      entity_id: binary_sensor.home_assistant_versions_update_available
  condition: "{{ int(states('sensor.home_assistant_versions').split('.')[-1]) > 0 }}"
  action:
    - service: shell_command.update_core
    - service: notify.gmail
      data:
        title: "Home Assistant New Minor Version"
        message: >
          Version {{ states('sensor.home_assistant_versions') }} was installed.
- id: update_ha
  alias: update_ha
  trigger:
    - platform: time
      at: "03:32:00"
  action:
    - service: shell_command.update_supervisor
    - service: shell_command.update_os

configuration.yaml

shell_command:
  update_core: 'curl -X POST http://supervisor/core/update -H "Authorization: Bearer $(printenv SUPERVISOR_TOKEN)"'
  update_supervisor: 'curl -X POST http://supervisor/supervisor/update -H "Authorization: Bearer $(printenv SUPERVISOR_TOKEN)"'
  update_os: 'curl -X POST http://supervisor/os/update -H "Authorization: Bearer $(printenv SUPERVISOR_TOKEN)"'
1 Like
2

Supervisor updates itself anyway

1 Like
3

Then you should choose something other than home assistant.

4 Likes
4

I find HA to be reasonably mature and its upgrades are relatively stable and backward compatible (with the exception of major core upgrades).
Therefore, it seems reasonable to automate the maintenance of the home automation system itself :slight_smile:

BTW,

  1. Our Ubiquiti network, with its 22 devices, is also in an auto-update mode.
  2. I believe that CI/CD mindset is the future (borrowing a term from the cloud world). We should try and make any type of upgrades a non-event. This is even more important with IoT systems, where you can have dozens of different devices (e.g. we have 80 devices in our house).
1 Like
5

You probably don’t want to do that, if you’re on vacation. It can fail, it will fail. :innocent:

6

While we are discussing an auto-updated system, here is another rule for keeping the Shelly devices (there are more than 50) updated:

- id: shelly_update
  alias: shelly_update
  trigger:
    - platform: time
      at: "02:32:00"
  action:
    - service: button.press
      data:
        entity_id: >-
          {{  
              states.button | 
              selectattr('entity_id', 'in', integration_entities('shelly')) |
              selectattr('attributes.device_class', 'eq', 'update') |
              map(attribute='entity_id') |
              reject('match', '.*beta.*') |
              join(',') 
          }}
7

Again. Not a good idea. Shelly often release bad firmware.

8

Is a manual approach better? It’s a heavy maintenance burden and ends up with less frequent updates, which means bigger windows for the security vulnerabilities (like Log4Shell).
Our phones update the (dozens of) mobile apps automatically. Why do we trust the mobile app developer to create a stable update, but not Shelly or HA? In many cases we have a bigger dependency on those mobile apps for our day-to-day activities.
BTW, we do trust HA to release a stable mobile app update (as they get updated automatically) :slight_smile:

Anyway, this is a wider discussion about the general approach to updates. Different people can have different taste and approaches.

9

With a robust backup system, I think this approach is good. You just have to have access to your system in case something breaks.

10

This thread should be tagged as ‘Share your projects’ since you aren’t actually asking for help, simply showing what you have done.