Trigger update from home assistant

[ElVit]

Hi, thanks for this awsome application :)
I found the way to display the docker updates in home assistant as update entities and its working great 😃.
Now the update entities give the possibilty to also trigger an update.
According to AI this is possible with the follwoing home assistant automation:

automation:
  - alias: "MQTT Update Entity mit drydock im Friendly Name"
    trigger:
      - platform: event
        event_type: call_service
        event_data:
          domain: update
          service: update_entity
    condition:
      - condition: or
        conditions:
          # entity_id shall start with 'update.dd_'
          - condition: template
            value_template: >
              {{ trigger.event.data.service_data.entity_id.startswith('update.dd_') }}
    action:
      - service: mqtt.publish
        data:
          topic: "my_device/update/trigger"
          payload: "start"

The question is now, is it possible to trigger an update in drydock via mqtt?
My docker containers are setup with docker compose so therefore I have added the docker compose trigger in drydock.
What shall the mqtt publish topic look like to trigger an update?
Or is there maybe a better way? Via REST API?

[s-b-e-n-s-o-n]

Hey @ElVit, glad you're enjoying drydock with Home Assistant! Great question.

Short answer

The MQTT trigger is outbound only — it publishes container state to your broker but doesn't subscribe to any command topics. So you can't trigger an update via MQTT directly.

The correct approach is the Webhook API, which was designed exactly for this use case.

How to trigger updates via the REST API

drydock has a webhook endpoint that triggers container updates:

POST /api/webhook/update/:containerName
Authorization: Bearer <your-token>

Heads up: In the upcoming v1.5 release, the canonical API path moves to /api/v1/webhook/update/:containerName. The old /api/webhook/... path will be deprecated. If you're setting this up now, you may want to plan for that change.

Since you already have the docker-compose trigger configured, calling this endpoint will use that trigger to pull the new image and recreate the container — exactly what you want.

1. Enable webhooks in drydock

Add these environment variables to your drydock container:

services:
  drydock:
    image: codeswhat/drydock
    environment:
      - DD_SERVER_WEBHOOK_ENABLED=true
      - DD_SERVER_WEBHOOK_TOKEN=your-secret-token-here
      # ... your existing config

2. Create a Home Assistant REST command

Instead of going through MQTT, use Home Assistant's rest_command integration to call the drydock API directly:

rest_command:
  drydock_update_container:
    url: "http://drydock:3000/api/webhook/update/{{ container_name }}"
    method: POST
    headers:
      Authorization: "Bearer your-secret-token-here"

3. Create the automation

automation:
  - alias: "Trigger drydock update from HA update entity"
    trigger:
      - platform: event
        event_type: call_service
        event_data:
          domain: update
          service: install
    condition:
      - condition: template
        value_template: >
          {{ trigger.event.data.service_data.entity_id
             | select('match', 'update.dd_')
             | list | count > 0 }}
    action:
      - service: rest_command.drydock_update_container
        data:
          container_name: >-
            {{ trigger.event.data.service_data.entity_id
               | replace('update.dd_', '')
            }}

Note: The container_name in the webhook URL must match the Docker container name as drydock knows it (e.g. myapp). You may need to adjust the Jinja template above depending on how your MQTT entity IDs map back to container names — check the entity attributes in Home Assistant to see the exact mapping.

Webhook rate limits

Webhook endpoints are rate-limited to 30 requests per 15-minute window, which should be plenty for manual update triggers.

Full docs

See the Webhook documentation for all configuration options, including per-endpoint tokens and per-container opt-out via the dd.webhook.enabled label.

[ElVit]

Thank you for the detailed answer.
I tried the rest_command and it worked 😃.
But unfortunately I can't test the automation because the update entities from drydock have no button "Update".

I think it's because the command_topic is missing in the mqtt message.
Is it possible to add it?

This is how an update entity with an "Update" button (from zigbee2mqtt) look like:

• mqtt topic:
  homeassistant/update/0x847127fffe44b65a/update/config
• mqtt message:

{
  "availability": [
    {
      "topic": "zigbee2mqtt/bridge/state",
      "value_template": "{{ value_json.state }}"
    }
  ],
  "command_topic": "zigbee2mqtt/bridge/request/device/ota_update/update",
  "default_entity_id": "update.fernbedienung_wohnzimmer",
  "device": {
    "hw_version": 1,
    "identifiers": [
      "zigbee2mqtt_0x847127fffe44b65a"
    ],
    "manufacturer": "IKEA",
    "model": "TRADFRI on/off switch",
    "model_id": "E1743",
    "name": "Fernbedienung Wohnzimmer",
    "sw_version": "2.3.079",
    "via_device": "zigbee2mqtt_bridge_0x04cd15fffec072e4"
  },
  "device_class": "firmware",
  "entity_category": "config",
  "entity_picture": "https://github.com/Koenkk/zigbee2mqtt/raw/master/images/logo.png",
  "name": null,
  "object_id": "fernbedienung_wohnzimmer",
  "origin": {
    "name": "Zigbee2MQTT",
    "sw": "2.9.1",
    "url": "https://www.zigbee2mqtt.io"
  },
  "payload_install": "{\"id\": \"0x847127fffe44b65a\"}",
  "state_topic": "zigbee2mqtt/Fernbedienung Wohnzimmer",
  "unique_id": "0x847127fffe44b65a_update_zigbee2mqtt",
  "value_template": "{\"latest_version\":\"{{ value_json['update']['latest_version'] }}\",\"installed_version\":\"{{ value_json['update']['installed_version'] }}\",\"update_percentage\":{{ value_json['update'].get('progress', 'null') }},\"in_progress\":{{ (value_json['update']['state'] == 'updating')|lower }}}"
}

[ElVit]

This should be the documentation for the Home Assistant update entities created over MQTT:

https://www.home-assistant.io/integrations/update.mqtt/

[s-b-e-n-s-o-n]

Great find on the command_topic spec, @ElVit! You're exactly right — the missing command_topic in the discovery config is why HA doesn't show the Install button.

I've read through the HA MQTT update entity docs and the zigbee2mqtt pattern you referenced. Native command_topic support is now on the roadmap for v1.6.0 (Phase 5.8). The implementation will:

• Add command_topic + payload_install to discovery messages (opt-in via config flag)
• Subscribe to a wildcard command topic and trigger the container update
• Follow the same zigbee2mqtt pattern HA users expect

It's behind an opt-in flag because adding command_topic silently turns read-only update entities into actionable ones for everyone on upgrade — we want users to enable it deliberately.

Workaround for now

Until v1.6, the webhook API works well with HA's rest_command. Since you already confirmed the REST call works, here's a complete setup:

1. Enable webhooks in drydock

services:
  drydock:
    environment:
      - DD_SERVER_WEBHOOK_ENABLED=true
      - DD_SERVER_WEBHOOK_TOKEN=your-secret-token-here

2. Add a REST command in HA

rest_command:
  drydock_update:
    url: "http://drydock:3000/api/webhook/update/{{ container }}"
    method: POST
    headers:
      Authorization: "Bearer your-secret-token-here"

3. Create a script per container (for manual buttons)

If you want a manual "Update" button in HA for specific containers:

script:
  update_adminer:
    alias: "Update Adminer via Drydock"
    sequence:
      - service: rest_command.drydock_update
        data:
          container: adminer

4. Automation for update entities (if you want to trigger from entity state)

automation:
  - alias: "Drydock update via webhook"
    trigger:
      - platform: state
        entity_id:
          - update.dd_adminer
        to: "on"
    action:
      - service: rest_command.drydock_update
        data:
          container: adminer

Note: The container value must match the Docker container name as drydock knows it. Check the container list in the drydock UI to confirm the exact names.

This gives you a working trigger path today. Once v1.6 ships with native command_topic support, the Install button will appear natively in your update entities and you can remove the REST workaround.

[s-b-e-n-s-o-n]

Quick follow-up to the earlier reply — native command_topic support for the HA MQTT discovery sensor is now scheduled for v1.6.0 (Phase 5.8). That's the zigbee2mqtt-style pattern: discovery payload ships with command_topic + payload_install, drydock subscribes to {baseTopic}/+/+/cmd, and clicking the HA native Install button publishes to the command topic and drydock executes the update — no REST shim in HA needed.

Design notes that are already locked in:

• Opt-in flag: DD_NOTIFICATION_MQTT_{name}_HASS_COMMANDS=true (default false) so existing setups don't silently change behavior.
• Single wildcard subscription (O(1) vs per-container), with per-container in-handler rate limiting so a flooded broker can't turn into an unintended DoS.
• Full webhook-equivalent guards on the message handler (container existence, rollback protection, audit events).

The REST-command/webhook workaround in my earlier reply will keep working even after v1.6 ships — the native path is purely additive.

Leaving this open as the tracking discussion until the v1.6 work lands.

[s-b-e-n-s-o-n]

Just a status note: the REST webhook workaround from my March reply is stable and works on all released RCs including v1.5.0-rc.19.

The native bidirectional MQTT path (command_topic + DD_NOTIFICATION_MQTT_{name}_HASS_COMMANDS=true) is still scheduled for v1.6.0 — no timeline yet, but it's locked into the design. I'll update this thread when it ships.

If the rest_command approach is working for you, feel free to close this — or leave it open as a tracking point for the v1.6 MQTT feature, whichever you prefer.