Understanding MQTT: the invisible language of the connected home

MQTT. Four letters that appear very quickly once you get seriously interested in home automation: in Zigbee2MQTT, in the settings of a home controller, in the datasheet of a battery or an inverter…
Yet its workings aren't obvious when you first encounter it. Rather than a lengthy technical explanation, let's look together at what MQTT is, what it's concretely used for in a connected home, and why it has become indispensable. You'll see: the principle is, at heart, quite simple.
What is MQTT?
MQTT (historically Message Queuing Telemetry Transport) is a very lightweight communication protocol, originally designed to allow machines and sensors to exchange small amounts of information.
Its key feature: devices don't communicate directly with each other. They do so through an intermediary: the broker.
Think of it like a postal sorting centre. A device sends a message indicating an address. The broker forwards that message to everyone who has requested to receive mail arriving at that address.
That address has a name: the topic.
With these three concepts, we've already grasped the essentials:
Publisher → MQTT Broker → Subscriber
- the publisher publishes information;
- the broker receives and distributes it;
- the subscriber subscribes to the information it's interested in.
The most widely used broker is called Mosquitto. Free and open-source, it runs on a Raspberry Pi, a home automation server or a NAS. Some gateways even integrate their own broker directly.
A very simple example
Take a meter that measures the home's electricity consumption. It periodically publishes the measured power on a topic:
home/energy/power → 742
The home automation controller is subscribed to that topic. As soon as a new value arrives, it receives it almost instantly and can display it, store it or use it in an automation.
And it also works the other way: the controller can publish a command on a topic to which a device is subscribed.
MQTT is used both to send information and to transmit commands.
A language understood by most connected products
MQTT doesn't belong to any brand or platform. It is an open standard, and that is what makes it powerful.
Most home automation controllers can connect to it: Home Assistant, Jeedom, openHAB, Domoticz, ioBroker, Homey, or tools like Node-RED. Each has its own interface and its own automation logic, but all of them can read and publish MQTT messages.
A device that publishes its data in MQTT is not tied to any particular software. You can switch controllers, or run several at once, without touching the devices.
Zigbee2MQTT: the best example
The best-known use of MQTT in home automation is undoubtedly Zigbee2MQTT (often abbreviated Z2M). And its name perfectly summarises its function.
A Zigbee device doesn't speak MQTT. It speaks Zigbee with the network coordinator. Zigbee2MQTT acts as a bridge between these two worlds:
Zigbee Device → Zigbee Coordinator → Zigbee2MQTT → MQTT Broker → Home Controller
Take an energy meter SEM-4-1-00. It sends its readings to the Zigbee network. Zigbee2MQTT picks them up and publishes them on a topic like zigbee2mqtt/home_meter, as a small message grouping power, voltage, current or cumulated energy. The home controller receives them and can use them immediately.
In the other direction, to switch on the relay of a SIN-4-1-21 module, the controller publishes a command on zigbee2mqtt/water_heater/set. MQTT carries it, and Zigbee2MQTT translates and sends it to the corresponding module.
Zigbee2MQTT can run on a home automation server, with a Zigbee USB key. But there are also gateways that bundle everything in a single box, such as the NodOn Zigbee MQTT Bridge (B2M-4-1-00).
Connected to the local network via Ethernet and powered by USB-C or PoE, it integrates the Zigbee coordinator, the Zigbee–MQTT gateway and its own secure MQTT broker, all configurable from a web interface. Zigbee devices are then accessible via MQTT to any compatible controller, with no additional server.
The broker is the postman, not the brain
The broker plays a central role. But it should not be confused with the home automation controller.
The broker decides nothing. It doesn't know whether a battery should be charged, a water heater started or a lamp switched on. Its job is to receive and distribute messages.
It is the home automation controller, with its automations and scenarios, that makes use of that information to make decisions.
It is precisely this separation of roles that makes MQTT interesting.
MQTT isn't limited to Zigbee
This is probably the point that causes the most confusion: MQTT is not a Zigbee protocol. Zigbee2MQTT is only one of its applications.
Many Wi-Fi or Ethernet devices can publish directly to MQTT: ESP32-based modules (Tasmota, ESPHome), micro-inverters via gateways like OpenDTU, certain home batteries such as Zendure, EV chargers, weather stations…
In my setup, for example, part of the information from my Zendure battery and my micro-inverters arrives via MQTT, alongside Zigbee data.
These devices come from different manufacturers, use different technologies, and sometimes have nothing in common. Yet their information flows through the same environment.
A real data bus
In a home equipped with photovoltaic panels, the home automation controller needs to know at all times:
- photovoltaic production;
- actual home consumption;
- grid import;
- surplus injection;
- battery charge or discharge power;
- water heater consumption.
Some data comes from Zigbee via Zigbee2MQTT, others directly from MQTT, others from the controller's own integrations. And yet the controller brings them together to obtain a coherent view of the home.
An important point to remember: not everything needs to go through MQTT for MQTT to be useful. It is simply one of the means of circulating information between the various components of the system.
A concrete example: the solar water heater
When the panels produce more than the home consumes, the surplus goes to the grid. The home automation controller knows this thanks to the readings from the SEM-4-1-00 meters. It can then decide to divert that surplus to the water heater, controlled by a SIN-4-1-21.
Photovoltaic production → Flow measurement → MQTT → Home controller → Automation → Water heater / batteries / other uses
This is exactly what works in my installation every day, with Home Assistant as the controller. But the same principle works with any MQTT-compatible controller.
MQTT doesn't decide to heat the water. It carries part of the information needed for that decision. The controller remains the conductor.
To go further: Controlling a water heater with the SIN-4-1-21: turning solar surplus into hot water
Information published once, used everywhere
This is one of MQTT's great advantages: a device publishes information once, and several systems can subscribe to it.
Take instantaneous photovoltaic power:
- the home controller displays it on its dashboard;
- a display can show it on an LED matrix;
- an EMS uses it to decide to charge a battery;
- another programme logs it in a database.
The producer of the information doesn't need to know all those systems. It publishes its data, and those who need it subscribe.
This is what is called a Publish / Subscribe architecture. And it is undoubtedly the most important concept for understanding MQTT.
From home to building
The principle of MQTT doesn't change with the size of the installation. What works in a home also works in an office building, a school or a hotel.
In the building sector, the home automation controller is called a BMS (Building Management System), and it too can communicate in MQTT.
It is for this type of project that the NodOn Zigbee MQTT Bridge (B2M-4-1-00) was designed. Each bridge manages up to around sixty Zigbee devices, and as many bridges as needed can be installed to cover one or several buildings.
Three modes allow adaptation to the existing architecture:
- Standalone: each bridge carries its own broker, and the BMS connects to it;
- Multi-bridge: a central bridge acts as broker and aggregates data from “satellite” bridges;
- External broker: all bridges connect to the broker already present on the BMS side.
In all cases, we find the same three notions: publishers, broker and subscribers.
Why MQTT is so popular in home automation
MQTT brings together four qualities especially suited to the connected home:
- Lightweight: the exchanged messages are very small.
- Fast: information is transmitted almost instantly.
- Universal: home controllers, BMS, ESP32, Raspberry Pi, gateways, software… many systems speak MQTT.
- Local: when a device offers local MQTT communication, its data can circulate without systematically going through the manufacturer's cloud.
This last point is essential: an installation that works locally remains operational even when the internet connection or a manufacturer's service fails.
From Smart Home to Smart Resilience
A truly smart home shouldn't be a mere accumulation of connected objects and mobile apps. It should make its devices talk to each other, leverage its own data and ensure the maximum number of essential functions locally.
In this approach, each component has its role:
- the home controller is the brain;
- Zigbee, Wi-Fi and other protocols connect the devices;
- MQTT allows these components to exchange information simply;
- automations leverage that data to optimise the home, especially its energy consumption.
This is what I like to encompass under a broader notion: Smart Resilience. A connected home, yes, but above all a coherent, interoperable home that is as local as possible.
In the end, MQTT isn't that complicated
If you're discovering MQTT, you don't need to start with its technical subtleties. Simply remember this picture: a device publishes information on a topic, the broker distributes it, and the interested devices subscribe.
The notions of QoS, retained messages, discovery or security will come later. They aren't essential to understanding the principle.
Once this mechanism is understood, many things become clearer when you observe what's happening behind Home Assistant, Zigbee2MQTT or any MQTT-compatible controller.
MQTT is neither the brain, nor the eyes, nor the arms of my home. It is its messaging system. And without making any noise, it allows this whole little world to communicate.
Key takeaways
✔ MQTT is based on three concepts: publisher, broker and topic
✔ The broker distributes messages; the home controller makes decisions
✔ Zigbee2MQTT bridges the Zigbee network and MQTT
✔ Information published once can be used by several systems simultaneously
✔ The NodOn B2M-4-1-00 Bridge combines Zigbee coordinator, gateway and broker in one box
✔ MQTT favours a local, open and interoperable installation
Products used
- SEM-4-1-00 – Zigbee Smart Energy Monitor
- SIN-4-1-21 – Zigbee Multifunction Relay Switch with Metering
- B2M-4-1-00 – NodOn Zigbee MQTT Bridge
In the same series
- Building a Residential EMS with Home Assistant and NodOn Zigbee Products
- Measuring energy flows with the SEM-4-1-00: the first step towards a more energy-efficient home
- Optimizing photovoltaic self-consumption with Home Assistant and NodOn Zigbee solutions
- Controlling a water heater with the SIN-4-1-21: turning solar surplus into hot water
eHome Labs
Passionate about home automation for over 20 years, Pascal Stephany continuously evolves his installation at the pace of his experiments. Every automation is tested in real conditions before being adopted in daily life, making his home a genuine full-scale laboratory.
This approach allows him to constantly refine his home's energy strategy and get the most out of what Home Assistant and NodOn Zigbee solutions have to offer.





Leave a comment
This site is protected by hCaptcha and the hCaptcha Privacy Policy and Terms of Service apply.