ZGP (Zigbee Green Power, a.k.a. Zigbee GreenPower) technology is used by a few ultra-low power devices (including the popular “Friends of Hue” partner batteryless wireless switches) and ZGP specification is a part of the official Zigbee 3.0 standard so it is today already supported by most modern Zigbee Coordinator adapters.
Fact is that Home Assistant’s ZHA integration (which is based on zigpy) is today missing ZGP device support, and I believe this limitation might in some cases be a showstopper and the reason why some people choose to go with Zigbee2MQTT or simply buy Philips Hue Bridge instead of going with Home Assistant’s own native ZHA integration (even though it is the only Zigbee integration officially supported by the Home Assistant’s team developers and Nabu Casa).
“ZHA does currently not support devices that can only use the ZGP (“Zigbee Green Power”) profile which is used in a few batteryless self-powered or energy harvesting devices, (such as for example; Philips Hue Click, Philips Hue Tap, and some “Friends of Hue” partnership switches).”
Reason for that is that the “zigpy” code library which the ZHA depends on does not yet support ZGP:
I know that for this to be added Home Assistant needs more volunteering Python developer(s) with personal interest in the development of the ZHA integration and the zigpy libraries that it depends on, as it will take someone with time and skills to delve into low-level Zigbee support to rewrite the code from that existing code pull request and open a new code pull request for the zigpy library (ZHA dependency) or write completly new code that will be acceptable for merger.
Anyway, you can find a list of many Zigbee Green Power devices in this zigpy feature request issue for ZGP:
Be aware that zoic21 did submit an pull request which would add initial ZGP support but that code may not be acceptable for merger. He is asking for help there to test that code is OK and this new feature do not break anything:
Summery; Zigbee Green Power ZGP), a.k.a. “Zigbee GreenPower”, is a subset feature of Zigbee the that allows for extreme low-power and energy-harvesting technology to be used directly with the Zigbee stack. Most common examples of Zigbee Green Power devices for home automation are rocker wall switches which use batteryless self-powered technology (from EnOcean) to work without a battery.
Wireless ZGP devices (end devices) for home automation devices may be powered by either different self-powered energy harvesting solutions or switches and sensors that can operate for up to a decade on a single battery coin-cell battery. Energy harvesting technology enables the maintenance-free battery-less / battery-free devices (end devices) such as switches and remotes operating in a Zigbee network. Zigbee Green Power V2 is included as a subset in the Zigbee 3.0 specification (Z3), however that is based on Zigbee Green Power V2 energy-harvesting technology that was a subset of the previous Zigbee PRO standard.
Friends of Hue partnership switches from ABB (Sweden), Illumra (USA), Kichler (USA), MAKRIS by Imoon (Italy), Vimar (Italy), Busch-Jaeger (Germany), Senic (Germany), Niko (Belgium), Sunricher (Hong Kong), Koizumi (Japan), Legrand (France), and John Lewis (UK) which I believe all use either the older EnOcean PTM 215ZE module or the newer EnOcean PTM 216Z module.
Any news on this add-on ?? Will there be a release, I’m not quite following all actions on Git… (not sure what’s happening there with all the technical terms…
This can not ve solved by some ”addon”, instead ZGP is this is something that must be implemented in the zigpy library that the ZHA integration depends on, as mentioned in my original post above.
Anyway, last I heard a developer was still working on it but he want and needs help with code review as well as help from users willing to test it with ZGP and other devices to check for bugs/regressions. Again, you can follow the progress here:
If you do not understand what they are discussion then you can at least see that pull request #656 for zigpy remains as “Open” status (which means that it has not yet been accepted), so you can first track it there to watch if and when it get changes from “Open” to “Merged” status. If and when that happens then need to wait until the next release of that zigpy library and then for Home Assistant core to update to that version of zigpy, only once all that is done will the initial feature for this be available in the next Home Assistant after than, but please understand and remember that even if and when that happens this should initially be seen as an experimental feature and as such might not be stable in the beginning.
I think that the patch from the pull request works and I understand that the Jeedom Zigbee plugin which uses a patched fork of the zigpy library that has ZGP active in their fork using the patch for the mentioned pull request. I believe they will only use that fork until merged upstream:
However, sadly I don’t believe that any of the ZHA or zigpy developers are activly working on on looking at that code for zigpy, nor are they reading posts from this forum.
Again you should really be following the progress on this development via the PR on zigpy GitHub here:
PS: Understand that zigpy is open source library only being worked on by volenteers in their spare time.
Unfortunately, there is no timeframe since no zigpy developer(s) is currently working on code for ZGP.
puddly posted comment https://github.com/zigpy/zigpy/issues/656#issuecomment-947951634 (in PR https://github.com/zigpy/zigpy/pull/656) that the current patch code from that pull request can not be accepted today as it is until it has been slightly re-written as the code patch for it will need to be cleaned up to be more readable by someone (e.i. a volunteering Python developer) before it can be acceptable for re-review before it can be merged, so new developer volunteer(s) are wanted to fix/change the previously submitted code patch!
puddly also mentioned in that same comment that zigpy developers have since that original patch was originally submitted done a ton of other underlying background work in refactoring the zigpy library code which could indirectly make a new patch for ZGP be easier to implementation (and even more unrelated changes have been merged into zigpy for the better since puddly’s comment), such as code restructuring and refactoring, cleanups, and other improvements or changes to the zigpy library and its radio libraries, many smaller and a few major, that in all should in theory now make it possible to write cleaner code patches today if someone like to step up and pick up this project again.
By the way, one of the major other indirectly related changes is that zigpy has otherwise been updated to be compliant with the Zigbee Cluster Library Specification revision 7 (ZCL7) and Zigbee Cluster Library Specification revision 8 (ZCL8) which among other things does state that every Zigbee 3.0 device with routing capabilities (router or coordinator) must implement Green Power Basic Proxy (GPBP) v1.1.1 functionality for forwarding compatibility (i.e. ZGP routing capability) to be granted Zigbee 3.0 Certification in order to further support Zigbee Green Power capabilities.
PS: Remember ZHA/zigpy are currently just a hobby projects developed by volunteers without pay, as such new features will probably only be priotized if volteering developers have a personal interest in it.
PPS: I believe one thing that could maybe could help speed this along would be to donate ZGP devices to lead developers puddly and Adminiuga as might increase their interest if they owned ZGP devices.
The last I heard/read was that developer(s) volunteers were still wanted/needed to clean up the code patch from the pull request previously submitted by zoic21 to the zigpy library and re-submit new a PR.
@majkrzak apparently commented in that discussion a few days ago offering to volunteer but seems he noted that do not exactly know what to fix/change in order to make it acceptable for a new review:
There is further general development discussion about it in the feature request for for it in zigpy repo:
I recently purchased the new SkyConnect coordinator, partly as a way of supporting Nabu Casa, and partly to get onto what I believed would be the best supported Zigbee coordinator for H.A.
After receiving it I learned that it uses a chipset that still only has experimental support in Z2M. So I converted my H.A. setup to use ZHA. That generally works great – and actually seems more stable and responsive then Z2M – but I’m no longer able to use my six green-power based control buttons (all based on EnOcean PTM 215Z)
If SkyConnect and ZHA are meant to power the premier H.A. experience, then this issue with no green power support really needs to get resolved.
Suggest that you also post that comment to this inofficial SkyConnect forum thread as I do not think there is any official feedback communication channel for Nabu Casa support of the SkyConnect(?):
ZHA integration follows the official Zigbee specification standards and uses one Zigbee Coordinator to set up and control a Zigbee network. Once ZHA has been installed and the Zigbee Coordinator is configured you will be able to directly join/pair Zigbee Router Device and Zigbee End Device products to that Zigbee network, regardless of the manufacturer and brand of that Zigbee-based product. Please see the respective sections below for compatible Zigbee radio modules hardware (physical radio adapter) and information on supported Zigbee devices.
Before installing the integration you will need to buy and connect a Zigbee Coordinator adapter to the computer running the Home Assistant installation. The general recommendation is to buy a newer model of Zigbee Coordinator adapter hardware and to flash the latest firmware to it, the reason that is it will usually offer better interoperability with all functions of most Zigbee 3.0 compliant devices on the market.
Supported devices are Zigbee Router Devices, which are normally mains-powered that act as Zigbee signal repeaters within the Zigbee network mesh to extend its range and improve coverage, and Zigbee End Devices, which will not act as Zigbee signal repeaters and are usually but not always battery-operated sensors.
### Limitations
Note that ZHA only supports connecting one dedicated Zigbee Coordinator adapter with a single Zigbee network and that the Zigbee Coordinator adapter cannot already be connected or used by any other application. Any devices that are or have previously been connected to another Zigbee implementation will also need to first be reset to their factory default settings before they can be paired/joined to ZHA, please see each device manufacturer’s documentation.
ZHA does not yet support devices that can only use the (“Zigbee Green Power”) profile which is used in a few batteryless self-powered or energy harvesting devices, (such as for example; Philips Hue Click, Philips Hue Tap, and some “Friends of Hue” partnership switches). The reason for this is that ZGP profile support has not yet been implemented in the zigpy library.
ZHA does not support devices that can only use the ZSE (“Zigbee Smart Energy”) profile because “Zigbee SE” is not part of the Zigbee 3.0 specification standard and thus not implemented in the Zigbee stack of commonly available Zigbee Coordinator adapters.
Not sure, I do not yet own any ZGP (Zigbee Green Power) devices so I can not actually test it myself.
Maybe all you who do own ZGP devices now test pairing/joining it to Home Assistent 2023.7 and report their results to to zigpy developers as “device support request” issues to zha-device-handlers repo?
It does look like initial ZGP support has very recently been added to zigpy (the Zigbee stack library that the ZHA integration depends on), which is only bumped in Home Assistant 2023.7 release (and later).
So at least now there a chance that ZHA and zha-device-handlers (zha-quirks) developers could add handler/converter code to support a ZHA Device Handler (ZHA quirk) for individual ZGP devices, (though the ZHA integration code might still need some new additions too).
I would suggest try to post feedback and details to that new or existing device support request and then wait to see if ZHA/zigpy developers are interested in looking at it, perhaps together with developers there you can resolve the missing pieces for specific devices (but be aware that since ZGP is not exactly standard Zigbee devices so could very well be that they will need to have that specific device you want working themself for them to develop needed support for it).
Suggest that you all go ahead post new “device support request” issues to the zha-device-handlers repository on GitHub with details on your setup, debug logs and troubleshooting steps (as mentioned, you need to be using Home Assistant 2023.8.1 release or later) → Issues · zigpy/zha-device-handlers · GitHub
In addition, requirement for end-users will be to have a relatively modern Zigbee Coordinator adapter with a not-too-old firmware on it so be sure to report the exact radio adapter and Zigbee Coordinator firmware version tested with, as all Zigbee Green Power will not work with older radios or old Zigbee Coordinator firmware.
Also, note that new ZGP devices could also need both a custom ZHA Device Handlers (a.k.a quirks) and modifications to the ZHA integration in the Home Assistant core, so it will be important that you all try open device requests as new issues if your ZGP device is pairing/joining but then not fully working correctly and not showing all entities expected or there is nothing showing in event data. Again, follow the ZHA docs section about ”How to add support for new and unsupported devices” → https://www.home-assistant.io/integrations/zha#how-to-add-support-for-new-and-unsupported-devices
