Short Answer: Add MQTT Only When a Specific Thing Needs It

For a normal Home Assistant setup, MQTT is optional. If you use ZHA for Zigbee, Z-Wave JS for Z-Wave, the Shelly integration for Shelly devices, Matter for Matter devices, HomeKit Device for HomeKit accessories, or a vendor's official local integration, you usually do not need MQTT at all. Those integrations already give Home Assistant entities, which are the lights, sensors, switches, locks, and cameras you automate in the UI.

Use MQTT when a product or bridge is designed around it. Zigbee2MQTT needs a broker, which is the local relay service that accepts messages and passes them to Home Assistant. Tasmota talks to Home Assistant over MQTT. Frigate can run without MQTT by itself, but its Home Assistant integration requires MQTT to be configured. Some DIY sensors, energy monitors, alarm panels, and local bridge projects also publish MQTT messages because it is a simple way for devices to announce state.

The plain-English rule is this: MQTT is a tool, not a requirement. It is excellent when you need a local message bus. It is unnecessary complexity when a direct Home Assistant integration already handles the device well.

Why This Question Keeps Coming Up

The demand is real because MQTT appears in a lot of Home Assistant tutorials before anyone explains the parts. Reddit r/homeassistant has long beginner threads asking whether MQTT replaces Zigbee or Z-Wave, whether new users need it, and what username should be used for the broker. Home Assistant Community threads show the practical failure mode: Zigbee2MQTT does not add devices, Frigate asks for MQTT, or the MQTT integration asks for broker credentials and the homeowner is not sure which component is which.

The timing matters too. Home Assistant keeps improving native integrations and protocol screens. The Home Assistant 2026.7 release notes, published July 1, 2026, highlight new device-management and protocol work such as the ZHA Zigbee overhaul and dedicated infrared/radio-frequency panels. That does not make MQTT obsolete. It does mean old advice that treated MQTT as the default answer for everything is not the right homeowner default in 2026.

A useful MQTT setup starts with vocabulary, not YAML.

MQTT, Mosquitto, and the Home Assistant Integration Are Different Things

MQTT is a lightweight message protocol. A device publishes a message to a topic, such as a temperature value, and another system subscribes to that topic. Think of it as a local message board for devices, not as a radio like Zigbee or Z-Wave.

Mosquitto is a broker. The broker is the service that receives MQTT messages and distributes them to subscribed clients. On Home Assistant OS, the official Mosquitto broker app is the common broker. Home Assistant's Mosquitto app docs say to install the app, start it, create a new Home Assistant user for MQTT, then add the discovered MQTT integration.

The Home Assistant MQTT integration is not the broker. It is Home Assistant connecting to a broker. The official MQTT docs say Home Assistant requires a broker that supports MQTT protocol version 5, and the integration can be configured with the broker host, port, username, and password. Once connected, Home Assistant can create entities from MQTT discovery messages or manually configured MQTT platforms.

Simple translation: MQTT is the language, Mosquitto is the local post office, and the Home Assistant MQTT integration is Home Assistant's mailbox at that post office.

When You Usually Do Not Need MQTT

Skip MQTT when the official integration already gives local entities and your setup is straightforward. That reduces the number of services that can fail, the number of passwords to track, and the number of places a device can be misconfigured.

  • Zigbee with ZHA: ZHA is Home Assistant's built-in Zigbee integration. It does not require MQTT.
  • Z-Wave with Z-Wave JS: the official Z-Wave JS path exposes devices through Home Assistant's Z-Wave integration, not MQTT.
  • Shelly stock devices: Home Assistant's Shelly integration can auto-discover Shelly devices and is listed as Local Push. MQTT can be useful for some advanced Shelly designs, but it is not required just to control Shelly locally.
  • ESPHome devices made for Home Assistant: ESPHome's MQTT docs say you may prefer the native API when connecting to Home Assistant, and that MQTT is not needed in that case.
  • Matter, HomeKit, Lutron, Hue, and many Wi-Fi integrations: use their native Home Assistant integration first unless the device documentation specifically says MQTT is the supported path.

Native does not always mean better for every advanced build. It does mean easier to hand off to a homeowner when the native integration is mature and local.

When MQTT Is the Right Tool

Use case Why MQTT appears Homeowner caveat
Zigbee2MQTT Zigbee2MQTT's getting-started docs say the host should have an MQTT broker installed, with Mosquitto recommended. Great device support, but Zigbee enters Home Assistant through MQTT rather than the built-in ZHA path.
Tasmota devices Tasmota's docs say it communicates with Home Assistant using MQTT, and Home Assistant's Tasmota integration docs say each device must be configured with MQTT broker settings. Useful for flashed or DIY Wi-Fi devices, but it adds broker credentials and topic troubleshooting.
Frigate camera integration Frigate's installation docs say an MQTT broker is optional for Frigate itself but required for the Home Assistant integration. Cameras and Home Assistant must point at the same broker. Container installs often fail when people use localhost incorrectly.
Custom sensors and bridges MQTT is a simple way for a small device, script, or bridge to publish state without writing a full Home Assistant integration. Give each device a stable topic plan and unique IDs, or discovery can create duplicate or confusing entities.
Multi-system homes MQTT can let Home Assistant, Node-RED, dashboards, and other local services share events. Good for advanced installs, but it should be documented because the broker becomes shared infrastructure.

The Home Assistant OS Setup Path

If you run Home Assistant OS or a supervised install and you need MQTT, the simplest path is the official Mosquitto broker app plus the MQTT integration.

  1. Install the Mosquitto broker app. In Home Assistant, go to Settings > Apps > Install app, install Mosquitto broker, then start it.
  2. Create a dedicated MQTT user. The Mosquitto docs say to create a user from Settings > People > Users, not by reusing reserved usernames such as homeassistant or addons.
  3. Add the MQTT integration. Home Assistant should discover MQTT. Add it from Settings > Devices & services, and enable discovery if your devices or bridges use it.
  4. Point the device or bridge at the broker. Use the broker host, port 1883 for unencrypted LAN MQTT, and the username/password you created. For an add-on running inside Home Assistant's add-on network, docs and community examples often use core-mosquitto as the broker host.
  5. Confirm entities appear. If using discovery, the bridge or device must publish discovery payloads under the expected prefix, commonly homeassistant.

Do not turn MQTT into a public internet service. The broker belongs on your LAN unless you have a real reason, certificate plan, and access-control plan.

The Container or Separate-Server Path

Home Assistant Container users do not get the Home Assistant app store. That means Mosquitto is a separate container, VM, package, or network service that you operate yourself. Home Assistant then connects to it through the MQTT integration.

The most common confusion is localhost. If Frigate, Zigbee2MQTT, Mosquitto, and Home Assistant are in different containers or VMs, localhost usually means "this container," not "the other service." Use a Docker network name when the containers share a network, or use the broker's LAN IP address when services are separated.

This is where a small diagram in your house notes pays for itself. Record:

  • where the broker runs
  • which clients connect to it
  • which username each client uses
  • where the broker configuration and persistence live
  • how to restart it without guessing

MQTT is reliable when the operational notes are boring. It is frustrating when the broker is treated as invisible glue nobody wrote down.

Local Control and Security Boundaries

MQTT can be fully local, but it is not automatically private in every configuration. It is local when the broker runs inside your home network and all clients connect to that local broker. It becomes cloud-dependent when devices publish to an external broker or when you bridge your local broker to a cloud service.

The Mosquitto app docs note that all connections must use a username and password, and that unencrypted connections are possible on default ports such as 1883 unless certificate files are configured for encrypted ports. For a normal home, the practical rule is simple: keep port 1883 inside the LAN, use strong per-purpose credentials, and do not port-forward MQTT from the router.

For locks, alarms, garage doors, and safety devices, avoid raw topic shortcuts as the only control path. Prefer Home Assistant entities created by the integration, add sanity checks, and keep a manual fallback. MQTT is a transport; it does not decide whether an action is safe.

Why MQTT Devices Sometimes Do Not Show Up

When MQTT devices fail to appear, check the layers in order instead of deleting integrations at random.

  1. Broker: is Mosquitto or your chosen broker running?
  2. Home Assistant integration: is the MQTT integration connected to the right host and port?
  3. Client credentials: is Zigbee2MQTT, Tasmota, Frigate, or the device using the same username and password that the broker accepts?
  4. Discovery: is MQTT discovery enabled in Home Assistant, and is the device using the expected discovery prefix?
  5. Topics: can you see the device publish messages with the Home Assistant MQTT listen tool or an MQTT client?
  6. Retained discovery: Home Assistant's MQTT docs explain that retained discovery payloads can make entities available after restarts; missing or stale retained messages can make recovery confusing.

The Home Assistant MQTT docs also show that deleting a discovered MQTT entity can be done by sending an empty message to the discovery config topic. That is powerful and dangerous. Do not purge retained topics until you know which device published them and what will recreate them.

What Happens When Home Assistant or MQTT Restarts?

MQTT can make some systems more resilient during a Home Assistant restart because the broker can keep running while Home Assistant reloads. Devices can continue publishing messages to the broker, and Home Assistant can read current retained discovery or state when it reconnects.

But the broker is now its own dependency. If Mosquitto is down, misconfigured, out of storage, or restored without its data, MQTT-based devices can become unavailable even while Home Assistant itself is healthy. If your Zigbee2MQTT network, Tasmota devices, or Frigate entities matter to daily life, include the broker in backups and update plans.

Power matters too. If Home Assistant and the broker are on one small hub, a short outage can take them both down. If the broker runs on a separate server, it needs the same UPS, restart, and backup thinking as Home Assistant. Do not let "it is just MQTT" become "nobody knows why half the house disappeared."

The Zigbee2MQTT Caveat

Zigbee2MQTT is one of the strongest reasons to use MQTT in Home Assistant. It has broad device support and deep device-level control. It is also a different operating model from ZHA.

Home Assistant sees Zigbee2MQTT devices through MQTT, not through the built-in ZHA integration. That can affect where devices appear in new Home Assistant protocol screens. A Home Assistant frontend GitHub issue opened on January 8, 2026, documented that the new protocol dashboard did not include Zigbee when Zigbee2MQTT was used, because the user expected the Zigbee protocol to show even though ZHA was not the integration path.

That is not a reason to avoid Zigbee2MQTT. It is a reason to choose it intentionally. If you want the built-in Home Assistant Zigbee path, use ZHA. If you want Zigbee2MQTT's device catalog, converter ecosystem, and MQTT architecture, accept the extra broker and document it.

Tara's Take

For a homeowner, the best default is native first, MQTT second. Use MQTT when it solves a real integration problem: Zigbee2MQTT, Tasmota, Frigate, custom hardware, or a bridge that is designed for MQTT. Do not add it just because a forum answer from five years ago said every serious Home Assistant setup needs Mosquitto.

When Tara packages a Home Assistant system with MQTT, we treat the broker as installed infrastructure. It gets a documented host, dedicated credentials, backups, and a clear restart path. We also avoid putting sensitive lock codes, alarm state shortcuts, or camera privacy details into cloud-routed message paths.

The goal is a smart home that a family can live with. MQTT can be part of that, but only when it earns its place.

MQTT decisions usually sit next to Zigbee stack choice, Home Assistant hosting, backups, network layout, and no-cloud planning.

FAQ

Do I need MQTT for Home Assistant?

No, not by default. Install MQTT only when a device, bridge, or application specifically needs it. A native integration is usually simpler when it already gives Home Assistant reliable local entities.

Is Mosquitto the same thing as the MQTT integration?

No. Mosquitto is the broker that receives and distributes MQTT messages. The MQTT integration is Home Assistant connecting to that broker. On Home Assistant OS, many people use both: Mosquitto as the broker and the MQTT integration as Home Assistant's connection to it.

Is MQTT local or cloud?

It depends where the broker lives. A broker on your LAN is local. A hosted broker or vendor broker is cloud. For a Home Assistant home, keep MQTT local unless you have a specific secure design for doing otherwise.

Does Zigbee2MQTT require MQTT?

Yes. Zigbee2MQTT is designed around MQTT. Its docs say the host should have an MQTT broker installed, and Home Assistant receives Zigbee2MQTT devices through MQTT discovery and MQTT topics.

Why are my MQTT devices not showing in Home Assistant?

Check the broker first, then the MQTT integration, then device credentials, then discovery settings and topics. In container setups, make sure the device or app is pointing at the broker's reachable network address, not localhost in the wrong container.