Connected equipment
Pair a local bridge, map MQTT topics, add webhooks and rotate keys
Pair the bridge with a short-lived code, map each control to your own MQTT topics, optionally send signed outgoing webhooks and rotate keys without a gap.
How to use it
- Open Connected Services, then Bridge pairing. Create a pairing code and enter it into the bridge helper on the same network as your broker. A code works once and expires after ten minutes; create a new one if it fails.
- Open MQTT mapping. For each control, enter the command topic, payload, the state topic that proves the result and the allowed range. The bridge keeps its own copy of the mapping and treats it as authoritative.
- Commands are sent at QoS 1, never retained and never replayed after a reconnect. A broker acknowledgement is shown as Accepted only. Confirmed needs a non-retained state message that matches the request after delivery. The bridge worker is software you run beside your broker; there is no hosted broker or worker.
- Open Outgoing webhooks to add an HTTPS endpoint. Each request is signed; check the signature and timestamp on your receiver. Private network addresses are refused. Failed deliveries retry with growing delays and then stop as dead letters. Retries need the operator to run the webhook worker every minute.
- To rotate the bridge key, choose Rotate bridge key. The old key keeps working for 24 hours so the bridge can switch over. Bridge requests are signed with a separate signing secret.
- Bridge health appears in Connections when the worker has reported in. If it stops, commands are not sent.
Requires Ark+ and editing access. You run the bridge and, for self-hosted control, the broker. Outgoing webhooks have not been tested against a real receiver over TLS.