MQTT

The broker, the integration and the clients

My Home Assistant MQTT integration connects to a broker on my local network. The broker accepts messages from clients and passes them to subscribers. Home Assistant, camera services and device bridges each have their own role in that exchange.

The broker routes messages. Home Assistant turns the relevant information into entities or evaluates it in automations. Each device bridge remains responsible for communicating with the equipment or service behind it.

Device or service → MQTT broker → Home Assistant entity or automation → configured action

Commands can travel in the other direction: Home Assistant publishes a request, and a subscribing bridge or device handles it. An automation can also respond through another integration, such as Hue or Frigate, without publishing an MQTT command at all.

MQTT therefore connects selected parts of my build. Z-Wave JS, ZHA and the Hue bridge still have their own connections to Home Assistant.

What I connect through MQTT

These are the roles represented in my configured entities, dashboards and automations. Each connection has a different dependency behind the messages it publishes.

Scroll the table horizontally to compare all four columns.

Camera services and Bark Alerts

Frigate has a substantial role in my MQTT automations. Some use its event messages directly, while others use entities exposed in Home Assistant. Ring MQTT also supplies camera-related entities and accepts commands from my automations.

My Bark Alerts integration uses the Home Assistant sensor state exposed by the Frigate integration. MQTT is part of that upstream detection path; Bark Alerts itself watches entity state changes. Camera video and optional bark-history downloads use separate streaming or HTTP connections.

The Frigate setup article explains those connections and the collar beep workflow in detail.

Shark and Roomba vacuum bridges

My Shark vacuum connection uses the Shark2MQTT Home Assistant add-on. The add-on packages the Shark2MQTT bridge and uses MQTT discovery to expose supported vacuum controls and status in Home Assistant.

My Roomba connection uses a local custom MQTT bridge built on dorita980, the unofficial Roomba library. The bridge uses the library's local connection to communicate with the vacuum and connects that information and its supported commands to my MQTT broker. The linked repository is the underlying library, not a published repository for my custom bridge.

These connections bring vacuum entities into my dashboards. My configuration also includes an automation that publishes vacuum-related MQTT messages. The bridges handle the device-specific communication, while Home Assistant provides the dashboard controls and automation logic.

Lighting and monitoring

My dashboards include Govee lighting through Govee2MQTT. MQTT also carries custom sensor and monitoring information used by notification automations.

Govee2MQTT supports LAN control for compatible devices and cloud-based paths for other functions. An MQTT entity alone does not establish that a particular device or feature works without the internet. The same distinction matters for Ring: the broker connection is local, but the Ring service remains a cloud dependency.

How messages become actions in my setup

Frigate events into helpers and camera controls

I have automations that inspect Frigate message payloads and update helper values and timers. This gives Home Assistant a useful state to work with beyond the original event message.

Other MQTT-triggered automations call Frigate pan/tilt actions for supported cameras. MQTT supplies the trigger; the action uses the Frigate integration. That is a different path from publishing a camera command back through the broker.

Frigate messages into Ring commands

Some of my configured automations listen for Frigate messages, evaluate conditions involving Ring motion entities, and publish on/off command payloads to Ring MQTT. Home Assistant connects the two services and decides when to send the request.

The broker does not interpret that automation logic. It delivers the resulting message to the client subscribed to the command topic. The bridge and the underlying service still determine whether the requested action succeeds.

Lighting and media across integrations

An incoming MQTT message is also used to toggle Hue lighting. Elsewhere, MQTT switch states participate in routines that control lights, switches and media players through other integrations.

This lets an MQTT input participate in a wider routine without requiring every target device to speak MQTT. Home Assistant handles the connection between the input and the action.

Problem reports into notifications

My configuration includes notification automations driven by MQTT problem and status entities, along with direct message triggers. Those reports put service and device information alongside the rest of my monitoring.

A problem sensor describes what its publisher reports. It does not, by itself, establish that the broker, the publisher and every service behind it are all healthy.

Messages, discovery and Home Assistant entities

A topic identifies a message channel; the payload carries its content. A direct MQTT trigger can inspect that content in an automation. An MQTT entity instead gives Home Assistant a sensor, light, switch or other supported control with a defined interpretation of the messages.

My configuration also explicitly defines MQTT sensors and buttons. These sit alongside the bridge-provided entities in the build. A compatible publisher can use MQTT discovery to announce the information Home Assistant needs to create its entities.

Discovery information and current device state serve different purposes. An entity can exist even when its publisher has stopped updating it. Conversely, a message can arrive at the broker without producing an entity unless Home Assistant has a matching entity definition or discovery configuration.

The Home Assistant MQTT documentation covers discovery, explicit configuration and message handling.

State, availability and the limits of delivery

A last reported value is not a freshness check

Availability reporting and sensor state are separate. Depending on its configuration, an entity may become unavailable when its publisher disconnects, or it may continue to display its last value. A displayed value alone does not prove that the device is currently reachable.

That distinction matters for the problem reports and camera states used in my automations. If updates stop, the last recorded state should not be treated as fresh evidence that a service is healthy or a detection is still active.

Retained messages and commands

A retained MQTT message can be delivered again when a client subscribes. That can help restore state, but an old value is still an old value. Retention also needs care on command topics because a newly connected subscriber may receive the stored command.

MQTT delivery guarantees concern messages between clients and brokers. They do not confirm that a light changed, a camera moved or a collar beeped. Where a device reports its resulting state, that report provides a separate check on the requested action.

Broker failure and upstream failure

If the broker or the Home Assistant MQTT connection is unavailable, the affected message-driven paths stop updating. Other Home Assistant integrations may continue to work, but routines depending on those MQTT inputs cannot receive fresh information through that connection.

A healthy broker also cannot repair a failed bridge or a cloud-service outage. Frigate, Ring MQTT, Govee2MQTT and custom publishers each have dependencies outside the broker.

Checking the connection from source to action

For a missing update or an action that did not happen, the useful checks follow the same path as the automation:

1. Check the publisher. Confirm that the bridge or service is running and can reach its device or upstream service.
2. Check broker delivery. Use the MQTT integration to listen to the relevant topic and look for a fresh message. A saved or retained value is not proof of a new event.
3. Check the interpretation. Confirm that the entity definition or trigger matches the topic and payload actually received.
4. Check the automation trace. A received message can still be filtered out by conditions or routed to a different action.
5. Check the result. If a command was requested, verify the target response separately. Successful publication alone does not establish the physical outcome.

This is why MQTT fits my build: it gives services a shared way to exchange information, while Home Assistant combines their inputs into useful behavior. Keeping the publisher, broker, entity and action distinct also makes it easier to locate a failure without treating the entire home as one connection.