You have an established Zigbee2MQTT network. Existing devices report normally and automations fire. Then a new device refuses to join: no interview, no device announce, nothing in the logs, even with permit_join on and the device sitting next to the coordinator. If you dig further, the same log may show a Zigbee2MQTT TABLE_FULL error against a bind request.
It is tempting to read those as one problem: the coordinator’s binding table filled up, so it stopped taking devices. The reports behind this article don’t support that reading, and the Zigbee spec points the other way. A TABLE_FULL in a bind response comes from the device that stores the binding, which is usually not the coordinator, and a binding table can’t stop a join by itself. This article separates the tables involved, says what each status can and can’t tell you, and covers what you can actually check. All of it happens on your own coordinator and Zigbee2MQTT install. No cloud service is in the path.
This is a synthesis of three GitHub reports, the Zigbee2MQTT EmberZNet adapter page and Zigbee stack documentation for the bind response, checked between late September and early October 2026. I have not filled a coordinator’s tables on a test bench. Where the sources leave a gap, I say so instead of filling it.
The symptom: Zigbee2MQTT stops accepting new devices
The clearest report is a 2026 issue on a Home Assistant Connect ZBT-2 (EFR32MG24 chip, EmberZNet 7.5.1, EZSP 13, Zigbee2MQTT 2.13.0-1). The reporter’s network stopped accepting joins at roughly 39 devices. Even after a full power cycle there was no join, interview or announce activity in the logs. Existing devices carried on as normal. The issue title also reports TABLE_FULL on bindings for existing devices.
The chip’s spec sheet supports several hundred devices. Thirty-nine is nowhere near it, so raw device count isn’t the explanation.
The issue is closed, and in the content our research could see there is no maintainer root-cause comment. A closed issue with no stated cause can mean a later firmware or release fixed it, or simply that it went stale. Read the last comments on the thread before acting on it. What the report does give us is the failing request: a bind between two device IEEE addresses on the genOnOff cluster that came back with status TABLE_FULL. The issue has the exact wording if you want to compare it with your own log.
What TABLE_FULL means in a bind response
In Zigbee, a binding is a record that tells a source device where to send something. The record is stored on the source device. A bind request goes to the device that will hold the entry, and that device answers with success, TABLE_FULL or not-supported. In that answer, TABLE_FULL means the storing device has no room left in its own binding table. So:
- In the ZBT-2 report’s failing request, which binds one device to another on genOnOff, the table reported full belongs to the source device, not the coordinator.
- Zigbee2MQTT’s configure step binds a new device’s clusters to the coordinator so that reports flow back. Those entries are written on the new device. The coordinator is the destination of those bindings; it doesn’t hold them.
Our binding troubleshooting guide makes the same point about direction.
Coordinator stacks also use TABLE_FULL-style statuses for their own internal tables. Z-Stack, for example, has a separate NWK_TABLE_FULL status for routing tables. A TABLE_FULL line tells you a table somewhere ran out. Check which request it is attached to before deciding which device owns it.
Binding table full vs coordinator device capacity
The official EmberZNet adapter page lists device-count ratings for the SMLIGHT SLZB-MR adapters, roughly 500 to 800 depending on model. As of the brief’s check on 2026-09-29, it says nothing about binding-table size. Given where bindings live, that’s not a gap in the page. A coordinator’s rating describes how many devices it can carry; a bind TABLE_FULL usually describes a different device’s storage.
I think this is the mix-up that costs people the most time. The marketed number is real, but a bigger coordinator does nothing for a source device whose own table is full.
What the configure step binds
A 2024 report on an SMSZB-120 failing to configure with TABLE_FULL lists the clusters the configure attempt touched: genBasic, genBinaryInput, genPollCtrl, powerCfg, ssIasWd, ssIasZone and a temperature cluster. One device can need several binding entries during configure, and under the rule above they land in that device’s own table.
Two limits on that. The cluster list comes from a single report, not from Zigbee2MQTT documentation. And the issue is from 2024 and closed, so use it as evidence for how configure behaves, not for how any current firmware behaves.
Adapter matters, and that’s the odd part
The same 2024 report is where the sourcing gets interesting. Configure failed with TABLE_FULL on a Z-Stack adapter (CC2652P) and on an SLZB-06M using the ember driver, while the ezsp driver configured the device successfully.
That result doesn’t fit a pure device-side limit. The sensor’s binding table doesn’t change size when you swap the coordinator. Either the status came from somewhere other than the device’s binding table, or the attempts differed in a way the report doesn’t show. I’d treat it as one unexplained data point, not as evidence that coordinators carry a hidden binding ceiling.
A coordinator table that does block pairing: TCLK
There is a second failure that looks nearly identical from the outside. An open 2026 feature request (last activity 2026-09-27) describes force-removed devices leaving orphaned Trust Center Link Key entries in the coordinator’s security table. One reporter’s CC2652P on Z-Stack eventually filled that table and could no longer pair new devices until the stale entries were cleared by hand.
This is the one case in these sources where a coordinator-side table is reported to block new pairing. It is the security table, not the binding table, and the causes and remedies differ.
| Symptom | Table | Where it lives | Source status |
|---|---|---|---|
| Bind or configure fails with TABLE_FULL | Binding table | The binding’s source device | Stack docs; one 2024 report with unexplained adapter dependence |
| Pairing blocked after many force-removes | TCLK (security) table | Coordinator | One open feature request (CC2652P, Z-Stack) |
| Joins stop near 39 devices, no announce | Not identified | Coordinator side, by inference | One closed issue, no stated root cause |
Do not treat these as one problem with one fix. Clearing stale security entries says nothing about a device’s binding table, and the reverse is also true. None of the reports gives a verified table size for a specific adapter or firmware.
What you can and can’t check from the frontend
Zigbee2MQTT’s frontend doesn’t show TCLK-table occupancy. The open feature request exists because users can’t see or clear those entries themselves, and the sources don’t describe a binding-table occupancy view either.
What you can read is the log and the bind response: which request carried the TABLE_FULL, and which device it was addressed to. The binding guide linked above covers the failed array in the bind response, which names the clusters that didn’t bind.
If a join fails with no activity at all, the binding table is not the suspect; a coordinator-side resource is. If that follows a long history of force-removes on a Z-Stack coordinator, the TCLK report fits. If a bind fails with TABLE_FULL on a working device, start with that bind’s source device. These are inferences from the reports and the spec, not diagnostics.
What to try
No maintainer-documented fix or published table size for Z-Stack or Ember turned up in the sources behind this article, so treat everything below as reasoning, not confirmed procedure.
- Bind TABLE_FULL on one device. Free the source device’s table by unbinding targets or clusters you no longer use on it. Zigbee2MQTT’s binding guide documents unbind. Unbinding also removes the reporting configuration the bind set up, unless you pass skip_disable_reporting.
- Pairing blocked after many force-removes. Follow the open TCLK feature request; no built-in cleanup tool exists as of its last activity. Our remove vs force remove explainer covers what removals clean up on the device and database side. The coordinator’s key table is the part it doesn’t address.
- Joins stop at a fixed count with no announce. Check adapter firmware and Zigbee2MQTT release notes for that symptom, and read the end of the ZBT-2 thread. The 2024 ezsp-versus-ember result makes a driver or stack change one data point to know about. Back up first: the coordinator backup and restore guide covers it, and flags Z-Stack to Ember as a cross-driver move that isn’t officially supported.
- Coordinator replacement. Only for the coordinator-side cases, and only once you’ve ruled out the above. For adapter-choice context see our ZBDongle-E vs ZBDongle-P comparison.
FAQ
What does TABLE_FULL mean in Zigbee2MQTT logs?
It means a table ran out of room. In a bind or configure response it is the binding’s source device reporting that its own binding table is full. Coordinator stacks use similar statuses for internal tables, so check which request the line belongs to.
Does my coordinator’s rated device capacity tell me how many devices I can pair?
It tells you how many devices the coordinator is rated to carry, nothing more. The ZBT-2 report shows joins stopping far below the rating for a reason the issue never states.
Does removing devices free up space for new ones?
Not reliably for the TCLK case. The open feature request reports that force-removed devices can leave stale key entries on a Z-Stack coordinator, so force-removing more devices may not free the table that is blocking pairing.
Is this a Zigbee2MQTT bug or a coordinator hardware limit?
The sources don’t settle it. A device-side bind TABLE_FULL is normal Zigbee behaviour. The TCLK case is a missing cleanup tool. The ~39-device join stall has no published root cause.
What this research verified
The bind-response mechanism, that the storing device answers TABLE_FULL about its own table, comes from Zigbee stack documentation. The configure cluster list and the adapter dependence rest on one closed 2024 issue. The ~39-device ZBT-2 stall rests on one closed 2026 issue with no visible maintainer root cause. The TCLK failure rests on one open 2026 feature request. The EmberZNet adapter page confirms device-count ratings and no binding-table figure. None of this was reproduced on a test bench, and no coordinator’s table sizes were measured.
Everything involved is local to your coordinator, your devices and Zigbee2MQTT. After any change, check whether a new device completes its interview and whether the earlier bind requests still fail in your log.
Whether the ZBT-2 stall gets a named cause, and whether a frontend view of TCLK occupancy ever ships, are the two open questions worth watching. Neither has been resolved as of this writing.