Can add-ons be started by an automation?

I see there is a service hassio.addon_start. (Available from the Services page of the Developr Tools).
I was wondering what goes in the service data? I assume it is also possible to start and stop add-ons in hassio dynamically with an automation? If so how does the yaml look?

My thinking is to have a maintenance input_boolean which would turn on e.g. the Samba add-on. It seems like a good idea to me to keep it turned off unless necessary.

I’d also use it to control when snapshots are taken rather as I do now every night at 3am.

1 Like

The one time you’ll really need it is when you can’t access the front end to turn it on :rofl:

Think you’re looking for answers to problems that don’t exist again.

1 Like

You can do it… I used to have one to start the LetsEncrypt addon at mignight to check the certificate and renew but don’t use that anymore as Caddy handles that.

I take your point, and it is a good one but

does rather go against one of the most consistent pieces of advice I’ve heard, i.e. ‘implement the security you feel comfortable with’ :stuck_out_tongue_winking_eye:

The addon name is the same as the last part of the url when looking at the details page for the addon. For example, the url for Let’s Encrypt addon is http://hassio.local:8123/hassio/addon/core_letsencrypt, so the service call would look like:

- service: hassio.addon_start
    addon: "core_letsencrypt"

Have a look at my example how to refer to the add on.

1 Like

Thanks. A perfect answer.

1 Like

Thank you, just use this info to re start an add one using automation (Watchdog)

Thanks for this! Just used it as well.

There was a comment earlier about never needing this unless you can’t use the front end. While that is fair, I think I found a pretty good use case for it. I created an automation that starts the “core_check_config” addon when a new version is available then sends me a notification with a link to that page after about 5 minutes. This way I can open up that add-on log and immediately see if updating presents any issues or not.

The alternative is press the button and wait 3-5 minutes for it to finish checking. The add-on says be patient but in my opinion patience is just code for “your automations have room for improvement” :slight_smile:


does this still works? when i go to my log after 30 min there is nothing

but when I do i manuel , the addon starts


Yea it definitely still works, I use it all the time.

The thing I noticed is that the OOTB sensor binary_sensor.updater is really slow to register that there is an update. So if you build an automation that starts the core_config_check addon when that says there’s an update available it will take a while to pick it up. Like I found it was often hours behind so if you’re someone like me that’s constantly on HA it’s going to seem like its not working.

This is why I actually made my own sensor to determine when updates are available to use instead of binary_sensor.updater. Here’s that sensor:

  # Alternate updater sensor for core since binary_sensor.updater is very slow to recognize updates
  - platform: command_line
    name: Updater Core
    command: 'curl http://supervisor/core/info -H "Authorization: Bearer $(printenv SUPERVISOR_TOKEN)" | jq ''{"newest_version","current_version"}'''
    value_template: "{% if value_json.newest_version != value_json.current_version %}on{% else %}off{% endif %}"
    - newest_version
    - current_version

This one will become true within a minute of an update being available.

FYI it’s actually copied and pasted from my post here which includes all my sensors/alerts around tracking updates as well as the automation logic for starting core_check_config on update. So if you want update notifications for other types of updates or want to know more about how it works, take a look.

thanks ! this seems to work, and is faster :slight_smile: