ProcirelHome Assistant + MQTT: A Local Smart Home That Lasts
Home Assistant plus an MQTT broker is the closest thing to a permanent smart home. Devices integrate themselves, automations run locally, and no vendor shutdown can take your lights hostage. The key is MQTT discovery devices announce themselves.
> At a glance: 8 minute guide · part 9 of 10 in the complete IoT and ESP32 guide track · includes a worked example and a quick-reference table.
## Connecting the broker
Here is the working theory in one pass. Install the Mosquitto broker add-on, then configure Home Assistant’s MQTT integration with the same credentials. The “Listen to a topic” debug panel becomes your oscilloscope for the whole home.
| C | o | m | p | o | n | e | n | t | | | | | | | | | | | |
| — | — | — | — | — | — | — | — | — | — | — | — | — | — | — | — | — | — | — | — |
| D | i | s | c | o | v | e | r | y | | t | o | p | i | c | | r | o | o | t |
| P | u | r | p | o | s | e | | | | | | | | | | | | | |
| sensor | …/sensor/… | Measurements | | | | | | | | | | | | | | | | | |
| switch | …/switch/… | Relay-controlled loads | | | | | | | | | | | | | | | | | |
| button | …/button/… | Momentary triggers | | | | | | | | | | | | | | | | | |
| binary_sensor | …/binary_sensor/… | Open/closed, motion | | | | | | | | | | | | | | | | | |
| light | …/light/… | Brightness control | | | | | | | | | | | | | | | | | |
## Discovery messages
Publish a retained JSON config to homeassistant/
## Designing device topics
Structure topics by room and device: home/livingroom/sensor1/state. Publish state on change plus retained, subscribe to set topics. With this discipline, replacing a device is editing one config message, not re-teaching the home.
## How to apply this in your build
Work through the sequence below each step assumes the previous one passed. For numbers that need calculating, the linked tools at the end of this guide do the arithmetic instantly.
1. Run Mosquitto and connect Home Assistant with credentials
2. Write discovery configs with unique object IDs
3. Publish retained state and command topics from the device
4. Test each entity from the UI before automating anything
### Worked example
An ESP32 relay publishes a switch discovery message once (retained). It survives broker restarts, reappears after Home Assistant updates. Answers commands in under 100 ms on the LAN. Run the numbers yourself with the related calculator and the result should agree to within rounding.
> Practical note from the bench. Our reference smart-home build wires every DIY device through discovery topics adding the tenth sensor takes minutes because the first nine enforced the pattern.
## Pitfalls that cost real hardware
– Non-retained discovery devices vanish on broker restart
– Colliding object IDs silently merging entities
– Automating before validating raw topics in the debug panel
## Key takeaways
– Connecting the broker the foundation of this guide; revisit it if any measurement here surprises you.
– Discovery messages the foundation of this guide; revisit it if any measurement here surprises you.
– Designing device topics the foundation of this guide; revisit it if any measurement here surprises you.
## Who this guide is for
Beginners get a single focused topic instead of a whole textbook chapter. It assumes the track’s earlier pages in the complete IoT and ESP32 guide path. Intermediate readers use it as a reference the table, the worked example and the mistake list answer the questions that come up mid-build. If you teach, the structure (theory, application, example, failure modes) maps cleanly onto a lab session.
## What you need before starting
Nothing exotic: the parts or tools named in the guide, a multimeter. A notebook for the numbers. Run Mosquitto and connect Home Assistant with credentials before you begin the guide assumes it and keep the quick-reference table above within sight while you work through the steps.
### Quick reference card
| Aspect | Where to find it in this guide |
| — | — |
| Core theory | Connecting the broker |
| Application steps | How to apply this in your build |
| Worked numbers | Worked example |
| Failure modes | Pitfalls that cost real hardware |
## How this fits the complete IoT and ESP32 guide track
This guide is one stop in the structured learning path. Start from the [complete IoT and ESP32 guide](/tutorial/iot-esp32-complete-guide) pillar page for the full map, or continue with [MQTT protocol basics](/tutorial/mqtt-protocol-explained) and [Mosquitto setup](/tutorial/mosquitto-mqtt-broker-setup).
## Frequently asked questions
Does this work when the internet is down?
Completely broker, Assistant and devices all run on your LAN.
Can I mix bought Zigbee devices with MQTT?
Yes; bridges exist for Zigbee too, and both live side by side inside Home Assistant.
Where do I go next?
Back to the [complete IoT and ESP32 guide](/tutorial/iot-esp32-complete-guide) pillar page it indexes every guide in this track and updates as new ones are published.
## Continue this track
– Building a foundation? The [iot, sensors & esp32 complete guide](/tutorial/iot-esp32-complete-guide) maps every step in order.
– Next: [LoRaWAN for Beginners: Long-Range IoT Without WiFi](/tutorial/lorawan-tutorial-beginners)
– Next: [Setting Up a Mosquitto MQTT Broker on Raspberry Pi](/tutorial/mosquitto-mqtt-broker-setup)
– Next: [MQTT Explained: The Protocol Behind Practical IoT](/tutorial/mqtt-protocol-explained)
– Work the numbers: [battery life estimator](/tools/battery-life) · [LM317 designer](/tools/lm317-regulator) · [wire gauge checker](/tools/wire-gauge-awg)
## Bench verification habits
Keep a lab notebook entry for every build in this track. The measured values, the deviations from the guide and the reason for each. Six months from now, those notes are worth more than any tutorial. They describe your bench and your components rather than a general case.
When a result here disagrees with your expectation, write down both numbers before changing anything. The gap between predicted and measured is where the real engineering lives. It is usually a tolerance, a parasitic or an assumption that was never checked.
## Formulas and checks from this guide
Verification checklist for this track: watch RSSI before blaming code, measure supply current during radio bursts. Confirm MQTT topics against the broker log. Wireless bugs are usually power or signal problems wearing a software disguise.
Bookmark this page against your next build in the track. The checklist above is the same one used across 23 guides in this series.
## From our lab notebook
Measure current during transmit bursts. Sags under load are power problems, no firmware fixes those.
Location, then device, then measurement. Document the tree before flashing the first device.
## Final note from the author
A note on radio current, which defines this track: transmit bursts draw in spikes, not averages. Scope the supply or log RSSI before concluding the protocol is at fault.
Working through Connecting the brokerand Discovery messages with that habit in mind takes minutes, and it is the difference between reading about this topic and owning it.