Zigbee binding
Zigbee binding links two devices directly — a remote to a bulb, a switch to a plug — so commands flow device-to-device without passing through the coordinator. Bound devices keep working even if the hub is down, with none of the latency of a hub round-trip.
A binding is an entry in a device’s binding table telling it where to send its commands: the remote’s on/off cluster is pointed at the bulb (or at a group address covering several bulbs) instead of at the coordinator. The result is instant, hub-independent control — the closest thing in the smart home to the reliability of a dumb wall switch.
The trade-off is that the hub may not learn about bound-command state changes unless devices also report state, and setting bindings up requires a platform that exposes them — Zigbee2MQTT and ZHA both do, with per-cluster control; consumer hubs mostly hide the feature or use it silently (Hue dimmer kits and IKEA remote-plus-bulb pairs are factory-configured bindings).
| What a binding stores | Source endpoint, cluster ID, and a destination — either a device endpoint or a 16-bit group address |
|---|---|
| How it is created | A ZDO Bind_req (0x0021) written into the source device’s binding table; Unbind_req removes it |
| Clusters usually bound | On/Off (0x0006), Level Control (0x0008), Color Control (0x0300), Window Covering (0x0102) |
| Latency | One radio hop — typically well under 100 ms, versus a hub round trip |
| Works with the hub offline | Yes; the coordinator is not in the path once the binding exists |
| Platforms that expose it | Zigbee2MQTT and ZHA directly; Hubitat partially; most consumer hubs not at all |
What a binding is at the packet level
A binding table is a small list stored on the sending device. Each row says: for this endpoint and this cluster, send commands here. The coordinator writes those rows during setup using a ZDO Bind_req and then steps out of the way. From that point the remote’s button press produces an On/Off command addressed straight at the bulb, routed through the mesh like any other frame.
The destination can be a single device endpoint or a group address. Group binding is the better option whenever more than one target is involved: a single groupcast reaches six bulbs at once and they respond together, where six unicast bindings produce the visible popcorn effect of bulbs turning on in sequence. Group binding requires the targets to have been added to that group first.
Bindings are per-cluster, which is what makes them precise. You can bind On/Off and Level Control from a dimmer to a lamp while leaving Color Control unbound so that colour still goes through your hub’s automations. Nothing about this is all-or-nothing.
Why it is the closest thing to a dumb wall switch
The appeal is not really speed, though a bound press is noticeably snappier than a hub round trip. The appeal is that the path has one dependency instead of four. A hub-routed press depends on the remote, the mesh, the coordinator, the automation engine, and — on cloud platforms — the internet. A bound press depends on the remote and the mesh.
That matters most for the lights people use every day. If your partner cannot turn on the kitchen light while Home Assistant is restarting, the smart home has made the house worse. Binding the wall remote directly to the kitchen bulbs and letting the hub handle only the clever automations is the design that survives contact with a household.
Be honest about what binding does not buy you. It does not save battery in any general sense — the remote transmits either way, and unicast bindings to several targets mean several transmissions where a group binding or a hub would send one. And it adds no logic: a bound button toggles, it cannot check whether it is after sunset.
Setting bindings up, and the state problem
Zigbee2MQTT exposes a Bind tab on each device with per-cluster checkboxes and a target selector, and ZHA offers the same through its device page and services. On Hubitat, some drivers create bindings for you and others do not. On Hue, Aqara, IKEA, and the other closed hubs, the feature is either invisible or applied automatically in the factory pairing kits — an IKEA remote paired directly to a bulb without a gateway is a binding, whether or not the box says so.
The recurring gotcha is state. A bound command travels device to device, so your hub never sees it and its idea of the bulb goes stale — the dashboard says off while the light is plainly on. The fix is attribute reporting: leave the bulb reporting its On/Off and Level attributes to the coordinator, so the hub is told about the change after the fact. Zigbee2MQTT configures this for most devices automatically; when it does not, an occasional poll is the fallback.
Two other limits. Both devices must actually support binding — plenty of cheap Tuya remotes only ever address the coordinator, and no amount of configuration changes that. And a binding survives in the source device’s table until it is explicitly removed, so re-pairing a bulb to a different network can leave a stale row on the remote that quietly does nothing.
Frequently asked questions
What is the difference between a Zigbee binding and a Zigbee group?
A group is a list of devices sharing a 16-bit address so one command can reach them all. A binding is an instruction stored on a sending device about where to send its commands — which can be a single device or a group. They are usually used together: create a group of bulbs, then bind the remote to that group so all of them respond in the same instant.
Does Zigbee binding work when the hub is off?
Yes. Once the binding exists it lives in the remote’s own table and the command goes device to device through the mesh. The catch is that the mesh still needs its routers powered, and your hub will not know the state changed until the target device reports it. Bindings are the reason a well-built Zigbee light setup keeps working during a hub reboot.
Which hubs let me create Zigbee bindings?
Zigbee2MQTT and Home Assistant’s ZHA integration both expose per-cluster binding directly, which is the main practical reason to run either. Hubitat supports it for some device drivers. Philips Hue, IKEA DIRIGERA, Aqara, SmartThings, and Alexa hubs do not expose it, although several of them create bindings internally when you pair a remote to a light.
Why does my hub show the wrong state after I use a bound remote?
Because the command never passed through the hub. Bound traffic goes straight from remote to bulb, so unless the bulb is separately configured to report its attributes back to the coordinator, your dashboard keeps the last state it knew. Enabling attribute reporting on the target device — or, failing that, periodic polling — brings the two back in sync.
Does binding improve battery life on the remote?
Not inherently. The remote transmits once per press either way. Where binding can help is by removing retries in a marginal link to a distant coordinator; where it can hurt is unicast binding to several targets, which makes the remote send one frame per target. Group binding is the version that sends the fewest packets.