Battery-less Zigbee Green Power switches use a different pairing process from ordinary Zigbee devices. This includes EnOcean-style PTM215Z/PTM215ZE paddles, Legrand’s Self-e range, and Sunricher GP switches. If a switch will not pair with Zigbee2MQTT, or works only close to the coordinator, check the coordinator’s chipset and whether a Green Power proxy router is nearby. Z-Stack and EmberZNet adapters handle these devices differently.
Zigbee2MQTT’s documentation describes Green Power and lists routers that can act as proxies. The adapter-specific pairing reports discussed below come from GitHub threads.
How Green Power reaches the Zigbee network
Green Power (GP) is a separate Zigbee sub-protocol for devices with no battery, or with too little energy to run a full Zigbee radio stack: kinetic switches, small solar sensors and similar. A standard Zigbee end device joins the network and talks to it through the mesh. A GP device can’t. It sends short, lightweight frames that normal Zigbee devices don’t route. Only a radio that hears a frame directly can act on it, unless a GP proxy picks the frame up and forwards it. In practice, the proxy is most often an IKEA, Philips Hue or Innr router.
GP devices do not support Zigbee bindings, and Zigbee2MQTT leaves them out of its network map and device scan. Their absence from those views does not mean pairing failed.
Why the coordinator matters: EmberZNet vs Z-Stack
Most USB Zigbee coordinators run one of two chip and stack families. Silicon Labs EmberZNet runs on the Home Assistant Connect ZBT-1 (formerly SkyConnect) and the Sonoff ZBDongle-E. Texas Instruments Z-Stack, on the CC2652 chip, runs on the Sonoff ZBDongle-P and other CC2652 sticks. Sonoff sells both of its dongles as the “Zigbee 3.0 USB Dongle Plus”, which confuses a lot of troubleshooting threads. Our ZBDongle-E vs ZBDongle-P comparison covers how to tell them apart.
ConBee sticks are a third family (deCONZ). Neither of the threads below covers them, so this article makes no claim about ConBee and Green Power.
Neither family runs a Green Power proxy in the coordinator’s own firmware. The difference is on the Zigbee2MQTT side. On Z-Stack, Zigbee2MQTT handles GP frames the coordinator hears directly. On EmberZNet, a gap in that handling means pairing needs an outside proxy router.
What the sources say about each family
Z-Stack/CC2652. A GitHub discussion titled “CC2652 Z-Stack coordinator 3.x.0 firmware does not currently support ZGP?” is the source most often cited for “Z-Stack can’t do Green Power”. The title reflects where things stood when it was opened. Participants found that TI’s coordinator firmware doesn’t enable the GP proxy code, which appears only in TI’s sink examples. The thread then reports a fix in Zigbee2MQTT 1.28.1, which shipped a change to zigbee-herdsman, the library Zigbee2MQTT uses to talk to the adapter. After upgrading, users in the thread paired Sunricher Green Power push buttons and switches on Sonoff dongle coordinators. The coordinator firmware still isn’t a proxy. Zigbee2MQTT processes the GP commissioning frames itself.
EmberZNet. A GitHub issue opened on 2026-09-13 documents that GP channel discovery can’t succeed on EmberZNet coordinators, including the ZBDongle-E. The exception is when a separate router with a fully working GP Basic Proxy and temp-master role is in range. A GP device looking for its network sends a Channel Request (frame 0xE3) and expects a Channel Configuration (0xF3) in reply. The issue traces the failure to zigbee-herdsman’s Ember adapter: it doesn’t drive the coordinator’s GP commissioning or temp-master functions, so the request is never handed up and the reply never goes out. The issue describes this as a missing integration on the Zigbee2MQTT side, not a device bug. It’s marked closed, but the thread text we could see shows no resolution, so treat the gap as open until a Zigbee2MQTT changelog names it.
A community forum report describes the same switch failing to pair with a ZBT-1 on EmberZNet, then pairing with a CC2652P-based ZBDongle-P on Z-Stack. That is consistent with the adapter difference described in the GitHub threads, though it is only one user’s report.
Without a proxy in range, a GP switch may work only where its coordinator can hear the frames directly. That could explain a switch working nearby and failing farther away. This is an inference from the protocol behaviour, not a test result reported by the GitHub threads.
The fix for EmberZNet, and for out-of-range devices: a proxy router
Place a GP-capable IKEA, Philips Hue, or Innr router within radio range of the switch. It needs to hear the GP device, so placing it close to the coordinator alone may not help. The reports describe this as the working path for EmberZNet, and as the way to extend coverage beyond the coordinator’s direct range on Z-Stack.
| Setup | What handles GP commissioning | What the sources report |
|---|---|---|
| EmberZNet alone (ZBT-1/SkyConnect, ZBDongle-E) | Nothing: Zigbee2MQTT’s Ember adapter doesn’t drive the coordinator’s GP commissioning | Channel discovery can’t complete; the forum ZBT-1 pairing failed |
| Z-Stack alone (ZBDongle-P, other CC2652 sticks), Zigbee2MQTT 1.28.1 or later | Zigbee2MQTT itself, for frames the coordinator hears directly | Users report pairing Sunricher GP switches; the forum CC2652P pairing succeeded |
| Either family, plus an IKEA/Hue/Innr router in range of the device | The proxy router forwards GP frames | The documented path, with one older report of a Hue router not forwarding (below) |
If you already have one of those bulbs, plugs or repeaters near where the GP switch will live, check that first before deciding the coordinator is faulty.
What a proxy router won’t fix
A proxy router solves the discovery and forwarding problem. It doesn’t touch two other reports about GP handling in Zigbee2MQTT.
The first is a permit_join bypass. A GitHub issue reports that GP devices, tested with an EnOcean PTM216Z, can join while permit_join is off. It traces the behaviour to zigbee-herdsman’s shared Green Power code, which processes commissioning frames (0xE0) without checking whether joining is allowed. Because the code is shared, the report concerns both Z-Stack and EmberZNet. The sources reviewed for this article do not confirm whether a fix has shipped.
If the permit_join bypass is still present in your version, a GP device can join your network outside your normal pairing window. That matters if you treat permit_join being off as a security boundary rather than a pairing convenience. Our permit_join security explainer covers what that boundary does and doesn’t protect.
The second is about proxy routers themselves. One issue describes a GP switch with a strong link to a nearby Hue bulb (LQI around 150), yet its GP data reached the coordinator only directly, at LQI around 8 from a far room. That suggests the Hue router wasn’t forwarding the frames. The issue was tagged fixed-in-dev, later closed, and last active in January 2024, and the thread shows no resolution detail. Treat it as a reason to check the device’s link after pairing, not as a current verdict on Hue routers.
Choosing a coordinator for Green Power devices
If you’re picking a coordinator with GP switches in mind, the chipset family matters. On current sources, a Z-Stack stick such as the ZBDongle-P can pair GP devices directly when they’re in range of it. An EmberZNet stick such as the ZBT-1 or ZBDongle-E needs a proxy-capable router near each GP device until the channel-discovery gap is closed.
Before replacing a working EmberZNet coordinator, try a proxy-capable router near the switch. It can address the reported pairing gap and improve GP coverage without migrating the network. Check the adapter handling and proxy support rather than relying on a coordinator’s “Green Power compatible” label.
The fixes discussed here concern Zigbee2MQTT and zigbee-herdsman, rather than a coordinator firmware change: the reported Z-Stack fix arrived with Zigbee2MQTT, and the EmberZNet issue concerns its adapter integration. For other firmware questions, see our coordinator firmware update guide. Standard Zigbee 3.0 commissioning with install codes is a separate process with its own adapter requirements.
Common questions
- What is a Zigbee Green Power device? A battery-less or self-powered Zigbee device, usually a kinetic switch, that uses a lightweight sub-protocol instead of joining the network as a full Zigbee end device.
- Does Zigbee2MQTT support Green Power switches? Yes. On Z-Stack coordinators, users report direct pairing since Zigbee2MQTT 1.28.1, provided the switch is in range of the coordinator. On EmberZNet coordinators, you currently need a proxy-capable router (IKEA, Hue or Innr) in range of the switch.
- Why won’t my Green Power switch pair with Zigbee2MQTT? On an EmberZNet coordinator (ZBT-1/SkyConnect, ZBDongle-E), most likely the channel-discovery gap described above: without a proxy router nearby, commissioning can’t finish. On a Z-Stack coordinator, check that Zigbee2MQTT is 1.28.1 or later and that the switch is within direct range of the coordinator or a proxy router.
- Do I need a Hue or IKEA bulb nearby for Green Power devices to work? On EmberZNet, currently yes. On Z-Stack, only if the switch is out of the coordinator’s direct range. Place the router near the GP device, not necessarily near the coordinator.
- Which Zigbee2MQTT coordinator works best with Green Power devices? On current sources, Z-Stack/CC2652 sticks, because they can pair GP devices without extra hardware. EmberZNet sticks work with a proxy router. ConBee/deCONZ isn’t covered by the sources used here.
Sources and remaining uncertainties
This guide is based on Zigbee2MQTT’s documentation, the GitHub discussion about Z-Stack support, the issues about EmberZNet channel discovery, permit_join handling, and Hue-router forwarding, plus one community forum report. It does not include a hands-on Green Power pairing test. The range explanation is an inference, and the 1.28.1 fix version is reported by users in the discussion rather than independently checked against the release notes.
Everything described here happens on the local mesh. No part of it, including the proxy-router workaround, depends on a cloud service.
The sources leave three questions unresolved: whether EmberZNet channel discovery has been fixed, whether the permit_join bypass has been fixed, and how ConBee/deCONZ adapters handle GP devices. A fix to the described EmberZNet integration gap would arrive through Zigbee2MQTT, so check its release notes before assuming a proxy is no longer required.