If you’ve got a mix of Aqara and Xiaomi Zigbee gear and some of it keeps going “unavailable,” the usual advice is to add more devices to strengthen the mesh. That advice is only half right. Add the wrong kind of device and the mesh doesn’t get any stronger at all, because not every Zigbee device does the same job on the network: some are routers that carry traffic for the mesh, and some are end devices that just ride on it.
This is a framework, not a shopping list. Everything below runs on whatever you’ve already got — Zigbee2MQTT, ZHA, no cloud dependency either way — and the goal is to help you look at your own device list and know which entries are actually infrastructure and which are just passengers.
The one-sentence rule
Zigbee splits devices into two roles. Mains-powered devices are routers: they relay traffic for other devices and extend the mesh’s physical range. Battery-powered devices are end devices: they only talk to their parent, and they do nothing to extend coverage for anyone else. This is standard across the whole Zigbee ecosystem, not an Aqara or Xiaomi-specific behavior.
That rule gets you most of the way to a working mental model. The catch, for Aqara buyers specifically, is one category of device that looks mains-powered but isn’t classified as a router — and it’s a common enough purchase that it quietly wrecks a lot of people’s mesh planning.
This applies identically under Zigbee2MQTT or ZHA — router/end-device role is a Zigbee network property, not something either platform decides. Nothing here requires new hardware; it’s an audit of what you already have.
The exception that trips up buyers
Aqara’s “no-neutral” wall switches are wired directly into mains power at the switch box, which makes it reasonable to assume they’re routers. They’re not. Z2M’s own GitHub tracker documents this directly for the D1 no-neutral switches (QBKG21LM, QBKG22LM): despite being mains-adjacent, both are classified as end devices, not routers.
The reason comes down to current draw, not marketing. A no-neutral switch pulls its power through the load itself, using a small parasitic current when the connected light is off. That’s enough to run the switch’s own logic, but not enough to sustain the continuous draw a router needs to relay traffic for other devices on the mesh. A separate deep-dive on the no-neutral T1 switch module reaches the same conclusion working from ZHA rather than Z2M, which is a second, independent confirmation of the pattern rather than one source repeating itself.
Worth knowing: this is specifically about the no-neutral family. It doesn’t tell you anything about Aqara’s with-neutral switches, which have a full neutral wire available and a different power budget entirely — that’s a separate category, covered next.
What actually extends your mesh
The devices that behave as routers, following the mains-powered rule above, are the ones with an actual neutral wire or a dedicated power connection: Zigbee smart plugs, mains-powered light bulbs and LED strips, with-neutral wall switches, and mains-powered curtain motors. I’d phrase this as “typically routers” rather than a hard guarantee for every SKU in the catalog — the underlying principle is well established, but I haven’t gone through every current with-neutral model’s device page one by one to confirm each individually.
Curtain motors are the clean, sourced example. Aqara’s Smart Curtain Motor C3 (lumi.curtain.acn04) and Roller Shade Controller T1S (lumi.curtain.vagl02) both list as router-type, DC/mains-powered devices on their Zigbee2MQTT device pages. If you’re running either of those, or an Aqara Curtain Motor B1 with a proper power connection, it’s doing real work for your mesh’s range, not just controlling your curtains.
A Zigbee smart plug is the cheapest way to add a router where you actually need one, since it needs no wiring changes at all — just an outlet in the right spot.
What doesn’t, even if you have a lot of it
Battery-powered devices don’t extend the mesh, full stop, no matter how many of them you own. That covers door/window sensors, motion sensors, temperature/humidity sensors, vibration sensors, and buttons and cubes. It also covers the no-neutral switches from the section above, despite being wired in.
This is the part that trips people up: a home with fifteen Aqara sensors and three no-neutral switches can have an objectively weak mesh, because none of those eighteen devices are routers. Adding a sixteenth sensor won’t change that. If your Zigbee network is mostly battery devices and no-neutral switches, you likely have too few routers, and the fix is adding router-class devices, not more end devices of the same kind you already have.
The one documented quirk worth flagging
Most of the above is a stable rule with one narrow exception. There’s also a genuine edge case: the older ZNCLDJ11LM curtain motor has been observed switching between end-device and router roles depending on network conditions at the time of pairing, based on a Zigbee2MQTT GitHub discussion where one user’s device flipped roles between pairings with no reliable way to reproduce it. There’s no officially documented way to force it into one role or the other.
Don’t plan your mesh around a ZNCLDJ11LM as a guaranteed router. If it pairs as an end device on your network, you won’t get the coverage you were counting on, and there’s no confirmed setting to change that after the fact.
Treat this as a known quirk in one specific model, not a reason to distrust the router/end-device framework generally. Every other device discussed above has a stable, sourced classification.
Mesh-planning checklist
| Device category | Zigbee role | Why |
|---|---|---|
| Smart plugs, mains bulbs/LED strips, with-neutral switches | Typically router | Full mains connection, sustained current available |
| Mains-powered curtain motors (C3, T1S) | Router (confirmed) | Z2M device pages list router type, DC/mains powered |
| No-neutral wall switches (e.g. QBKG21LM, QBKG22LM) | End device | Wired to mains but parasitic current only sustains switch logic, not router duty |
| Battery sensors (door/window, motion, temp/humidity, vibration) | End device | Battery powered, no infrastructure role by design |
| Buttons and cubes | End device | Battery powered |
| ZNCLDJ11LM curtain motor | Varies (documented quirk) | Reported switching roles depending on pairing-time network conditions, no forced override |
Go through your own device list against that table. Count how many actual routers you have, not how many devices in total. If the router count is thin relative to your home’s size, that’s the gap to close before adding anything else.
When this shows up as symptoms
If you’re already seeing “unavailable” states or devices that quietly drop off and reappear, an end-device-heavy network with too few routers is one of the most common root causes. Our companion piece on Zigbee2MQTT ghost-device troubleshooting covers the fixes once you’ve confirmed the symptom; this article is meant to catch the underlying cause before you get there.
I think Aqara and Xiaomi could save buyers a lot of this confusion by just printing “router” or “end device” on the product page instead of leaving it to be reverse-engineered from a GitHub issue — the information clearly exists internally, it’s just not surfaced anywhere a shopper would see it before buying.
FAQ
Is a no-neutral Aqara switch a router or an end device? End device, for the no-neutral D1 switches Z2M’s tracker documents (QBKG21LM, QBKG22LM) — the mains wiring doesn’t change that classification.
Do battery-powered Zigbee sensors extend the mesh network? No. Battery devices are end devices by definition; they only communicate with their parent and add nothing to network range.
Why does my Aqara device keep going unavailable even though it’s plugged into power? If “plugged into power” means a no-neutral switch or a similarly parasitic-powered device, it isn’t acting as a router, and it won’t help other devices’ connectivity. Check whether your network actually has enough separate router-class devices.
What Aqara/Xiaomi devices should I buy to strengthen my Zigbee mesh? Smart plugs are the simplest option — no wiring changes, and a mains-powered plug reliably acts as a router. Mains-powered curtain motors and with-neutral switches work too if you already need one for its primary function.
Can a Zigbee device be both a router and an end device? Not simultaneously under normal operation, though the ZNCLDJ11LM curtain motor shows a device’s role can vary between pairings depending on network conditions at that specific point in time.
What’s verified, what stays local, what to check yourself
The router/end-device classifications for the D1 no-neutral switches (QBKG21LM, QBKG22LM) and the C3/T1S curtain motors come directly from Zigbee2MQTT’s device pages and a GitHub issue explaining the underlying mechanism, not from bench testing on this site. The ZNCLDJ11LM role-switching quirk is drawn from a Zigbee2MQTT GitHub discussion documenting the behavior — treat it as a known edge case, not a guarantee in either direction.
Everything discussed here operates entirely on your local Zigbee mesh under Z2M or ZHA — no cloud service is involved in router/end-device role assignment at any point.
What I didn’t extend past its sourcing: with-neutral switches, plugs, and bulbs are described as “typically” routers rather than confirmed per-model, and no classification is asserted here for models Z2M’s own pages weren’t checked against directly. If you’re planning around a specific SKU not named above, your own device’s Zigbee2MQTT page will list its power source and type directly — that’s a two-minute check worth doing before you buy on the assumption that “it’s wired in” automatically means “it’s a router.”