Home Assistant reached mosquitto and the three Servarr apps at 127.0.0.1 and a port typed into its
own storage. It now requires mqtt-topic (asking for every topic: discovery and the devices' topics
are its job), sonarr-api, radarr-api and lidarr-api, and a run-once `provisions` step — declared
last, restarted when a binding or pair credential changes — makes Home Assistant's config entries
say what the mesh bound, through Home Assistant's own config flows and never its .storage:
- MQTT: the broker is asked first whether it takes the delivered login; then the integration's
reconfigure flow sets broker, port, username and password, every other setting sent back as Home
Assistant pre-filled it, and Home Assistant's own connection test must pass. A digest of what was
written makes a rerun "already as the mesh says". Refused anywhere, nothing is written and Home
Assistant keeps the login it has.
- Sonarr/Radarr/Lidarr: the bound key is tried against the app (a minted key is never written; the
failure names the `secret accept`); no entry is made through the user flow; a reauth Home
Assistant started is finished with the bound key (and URL where the integration asks); an entry
already at the bound URL, or at another URL reaching the same running app, is left as it is.
These integrations have no reconfigure flow, so a working entry elsewhere is refused loudly —
the step never removes an entry.
The sidecar's URL now uses the port it was given.
home-assistant: states/call-service/config tools, emits state.changed bounded
to actuator/contact domains (not attribute ticks), overridable via a watch
allowlist. influxdb: health/buckets/flux-query tools — tools-only, since a
time-series DB has no lifecycle event to emit here. Typecheck; manifests parse.
jschoubben