Zigbee2MQTT

What is Zigbee2MQTT?

Zigbee2MQTT talks to a cheap USB Zigbee coordinator and publishes every paired device over MQTT, so lights, sensors and switches from many brands become plain messages your automation system can act on. No manufacturer hub, no account.

Best for

Getting Zigbee devices out of vendor clouds

Why choose Zigbee2MQTT

Zigbee2MQTT's central idea is that your smart devices should not belong to anyone. It talks to an inexpensive USB Zigbee coordinator and publishes every paired device over MQTT, which means a light, sensor or switch from any supported brand becomes a plain message your automation system can read and act on. The vendor hub, the manufacturer app and the cloud account all disappear from the picture, and devices from different brands interoperate because they are all just messages on a bus. Its device support is exceptionally broad because the community maintains the definitions, and the coordinator can be relocated for better radio coverage independently of the software. For anyone who wants local control as a principle rather than a feature, it is the standard answer.

Replaces

• Philips Hue Bridge
• Amazon Echo Hub
• SmartThings Hub

Key features

• Supports thousands of Zigbee devices across brands
• MQTT interface usable by any automation platform
• Web interface for pairing and configuration
• Network map and device health

What to watch out for

The radio is the weak point and no software can fix it. Coordinator placement, USB extension cables to avoid interference from the host, channel overlap with Wi-Fi and the number of devices a single network can carry are all real constraints that show up as intermittent unreliability. Some devices pair only partially: a manufacturer may implement a proprietary feature that Zigbee2MQTT exposes as a raw attribute or not at all, which is frustrating when it was the reason you bought the device. Upgrading the coordinator firmware can require re-pairing everything, so it is a maintenance event rather than a routine update. The MQTT dependency means a broker must be running and reliable, and losing it means losing control of every device at once.

How to deploy

• Docker with a USB coordinator passed through
• Set MQTT broker and network key
• Pair devices through the web UI

Getting started

Choose a coordinator that is on the recommended list rather than a cheap unknown, and put it on a USB extension cable away from the host and any USB 3 ports, because interference from those is a common cause of mysterious dropouts. Set the Zigbee channel deliberately after checking what your Wi-Fi uses, rather than accepting a default that overlaps. Pair one device and confirm it appears in the broker with sensible values before pairing a houseful. Name devices deliberately in the configuration, because renaming later means updating every automation that references them. Back up the configuration directory, since it holds the network keys and losing it means re-pairing every device.

Typical setup

It runs as a service beside an MQTT broker, with a USB Zigbee coordinator on an extension cable away from the host and any USB 3 ports, because interference from those is the most common cause of intermittent dropouts. The Zigbee channel is chosen deliberately after checking what the Wi-Fi uses. Devices are paired one at a time and named carefully in the configuration, since automations reference those names and renaming later means updating every rule. The configuration directory is backed up, because it holds the network keys and losing it means re-pairing every device from scratch.

Who should look elsewhere

Do not choose this if you are unwilling to think about radio placement and channel planning, because those constraints cause most of the frustration attributed to the software. Avoid it if the devices you own depend on proprietary vendor features — a cheaper path may just be the vendor hub. And if you already run a Zigbee implementation built directly into your automation platform, adding a broker and a second stack is complexity for likely no gain.

Project health

• GitHub stars: 15,684
• Last code push: 2026-10-01
• Open issues: 442
• Status: actively developed

Figures pulled from the GitHub API and refreshed periodically.