If you have self-hosted home setup with some docker containers that don’t run under HAOS, you can get the same experience as with Add-Ins, by being notified of new image updates via Home Assistant, and if you want triggering an automatic pull and restart.
There’s zero config needed on Home Assistant side, presuming that MQTT is setup and the automatic component discovery hasn’t been turned off. Can also use it with other tools and scripts, since everything happens over regular MQTT topics.
As well as regular image registry pulls, if you have containers that build locally from a cloned git repo, it can check for remote repo changes and trigger a build. And for things that change very frequently, it can do the pull and restart without asking if you want.
updates2mqtt is updated now to be easier getting started with the auto-generated config file.
Also now available as a plain python package with “pip install updates2mqtt”
can’t understant why my ha is not seeing anything. MQTT is working, updates2mqtt posts under the same discovery topic, discovery is enabled and… nothing.
config:
ode:
name: docker-hack # Unique name for this instance, used to name MQTT entities. Defaults to O/S hostname
healthcheck:
enabled: true
interval: 300 # publish a heartbeat every 5 minutes
topic_template: healthcheck/{node_name}/updates2mqtt
mqtt:
host: rutto.lan
user: user
password: pass
port: 1883
topic_root: updates2mqtt
homeassistant:
discovery:
prefix: homeassistant # Matches the default MQTT discovery prefix in Home Assistant
enabled: true
state_topic_suffix: state
docker:
enabled: true
allow_pull: false # if true, will do a `docker pull` if an update is available
allow_restart: false # if true, will do a `docker-compose up` if an update is installed
allow_build: false # if true, will do a `docker-compose build` if a git repo is configured
compose_version: v2 # Controls whether to use `docker-compose` (v1) or `docker compose` (v2) command
default_entity_picture_url: https://www.docker.com/wp-content/uploads/2022/03/Moby-logo.png # Picture for update dialog
device_icon: mdi:docker # Material Design Icon to use when browsing entities in Home Assistant
# device_icon: mdi:train-car-container # Alternative icon if you don't like Docker branding
discover_metadata:
linuxserver.io:
enabled: true
cache_ttl: 604800 # cache metadata for 1 week
scan_interval: 10800 # sleep interval between scan runs, in seconds
log:
level: INFO
i manage my 5docker installation through a central portainer instance so i know i’m not going to be able to update images from ha, but at least see updates…
Does it discover any of the docker containers? That should show up on the logs if it does, just set the log level in config.yaml to DEBUG and it will show each container.
It might be that the dockerpy API can’t access the local docker daemon. Double checked my own docker-daemon.json and don’t have any customisations for that - only ever had to do that for remote access, for vscode environments. Is you container running under a different UID, and is that UID a member of the docker group?
Ok this is my fault
I see single entities created in mqtt, but i expected to find the “hosts” themselves, that is not the case
So now my issue is understanding why this
was not shown to me anywhere if not going to take it specifically:)
Also, is there a way to group updates under “general” entities describing the hosts? I’m not sure what class they could have, but it would be a lot clearer!
Lastly do you think it is feasible to let updates2mqtt to work also when docker instances are managed through portainer agents?
I would like to have entries for the hosts, so things like critical apt,rpm etc updates show up, plan was that docker would be just one of the update sources. For the future.
Seems that you’d like one button to update all of the containers on a single host - I hadn’t thought of that, but seems a reasonable option to have, if you have lots of containers, though I guess most folk would want to have control of which ones to accept.
I think that would be a better change to have in Home Assistant itself, so you could have all the Zigbee firmware updates in their own group, or grouped by zone, and similar for docker updates. If I had good enough TypeScript, I’d give a PR for that a try!
I have Portainer, and Podman, on the list for future improvements. I’ve always had Portainer running myself, though for the last couple of years running what became updates2mqtt I’ve rarely ending up using the UI.
Thanks for the questions and feedback, hopefully the troubleshooting guide is more useful now
well this is not my case my case is more "you have a lot of HOSTS, every one with some containers, i’d like to be able to evaluate, host by host, the update status. Atm, if i install updates2mqtt on every docker host, i’ll end up having a lot of specific entities (one for container), hard to manage.
It’s not about updating since i’m with portainer so i can’t use that function
Have you any idea on why the update notice is not coming up to my HA? is it because i only have “skip” and not “update”?
Thanks a lot!
(i’m not managing a server farm, but in my lan - proxmox based - i have docker LXC in different vlans doing different things, that’s why i need a central management tool - portainer - and also some way to monitor containers update…)
I have just two hosts! Can see your point. will have a look at how that can be done.
allow_restart defaults to True, however you won’t see the update button if it can’t find a compose path, which comes from the docker com.docker.compose.project.working_dir label
There’s some more logging in v1.4.1 that will diagnose this
i see for example WUD creates a whole device (the host) that contains boolean sensors for the containers update. Seems reasonable, isn’t it? even if wud does not manage multiple hosts
i’ll give a try to 1.4.1, but honestly i think the reason i don’t see any update popup is inside HA, not your code…
I’m also evaluating if to automate the update (in a portainer environment) it should be better to just use portainer API: updates2mqtt detects the new version, mqtt to HA, update popup, and the update command triggers the re-deploy of the stack in portainer. I’m not sure i have all the information needed, but could be feasible…
Thanks again!
Hello,
this seems to be far easier than expected. If in the discovery of entities you add a device block in the json, HA joins all entities under the device. In our case, the device could be the server, listing the update entities for all containers. Makes a lot of sense. It should be enough something as easy as
However, i’m seeing a strange behavior (not blocking the tool to work) on healthcheck: the container starts, but it stays in “starting state” since it seems it tries to connect to a mqttbroker not existant (on localhost). So i found out the healthcheck.sh uses different mqtt configuration
sorry to tag @jey how can i setup mqtt variables for healthcheck? env vars in healthckeck block?
thanks
Now in v1.4.2, along with ability to set suggested area ( if Hom Assistant does anything with that yet, maybe only first time for devices) and a few more icons. Can switch off the device creation in config, on by default since its nice
for healthcheck to work you need to set up env vars for mqtt connection (it was written in the docs ahahaha sorry)
and yes, the HA popup is not showing up if the update can’t be executed so you need at least an “allow_pull” enabled. I assume this is HA behaviour and nothing related to U2M. That’s a pity since with portainer this is not going to work, but at least the information shows up…
However, as always… i have a stupid question this is a piece of my “stack” (or compose)
healthcheck:
test: ["CMD", "/app/healthcheck.sh","healthcheck/docker-hack/updates2mqtt"] # Change for your node name
interval: 5m
timeout: 30s
retries: 3
start_period: 60s
environment:
- MQTT_HOST=
- MQTT_PORT=
- MQTT_USER=
- MQTT_PASS=
why do i need to specify those information that are already in the config.yaml file? i mean, the healthcheck topid is in the config. So it is the heartbeat. And for sure mqtt settings are well included in the config file… am i missing something?
Healthcheck is simple bash script, that doesn’t do any yaml loading and parsing, so needs env vars. Plus it’s better to have these values in env vars rather than config so can be protected better, e.g. have the .env in .gitignore if you commit the config, and it could be sourced from a vault
You don’t need to repeat the values, in the main config do like this:
thanks, this makes sense.
and also i have to say i admire you for the precision of your git repo and of the help page, it’s clear you know what you are doing and you are also doing it with passion
tomorrow i’m going to install U2M on all my docker servers, let’s see what happens
i’m only sad there’s no way to use proper images for containers in place of common docker… why can’t we take images from public repositories? i mean, not setting manually the image for every container…
thanks again and kudos for the tool!
let me know if i can help anyhow
There’s no limit in U2M on where images come from - I have docker,gchr plus containers that are built locally from a forked repo because I have to fix them ( why the git pull support is in u2m too )
i was talking about images in the meaning of “graphical images”, the icons i hate that “common” docker icon, and i was wondering why can’t we use the same icon containers show on repositories (avoiding to set them up manually for each container)
For example, portainer agent: portainer/agent - Docker Image
But i checked that a docker inspect doesn’t show any url if not the hash of the image, so probably this is not something standard… i’ll try to give a look if we can deduct some sort of url starting from the inspect values…
Best I have so far for icons is fetching the linuxserver ones, which is almost 200 now. You can set your own with an environment variable in the compose file or .env
Its possible that the ghcr might be predictable enough to get the repo icon, though in the case of rtl_433 that means a photo of the developer’s face
