I was refering to the pairing instructions from the Z2M link you posted earlier. Since Z2M uses another default Zigbee channel then ZHA, I can imagine that it is good start the reset the switch: “In case you want to pair it to a different channel you have to factory reset the device. This can be done by pressing all buttons (A0, A1, B0 and B1) simultaneously for at least 7 seconds.”
Z2M uses channel 11 and ZHA channel 15 (by default). As I read it, the appropriate pairing sequence should be:
Press top left (A0)
Press and hold top left (A0) for about 10 seconds
press top right (B0) and bottom left (A1) at the same time
press top left (A0) Note: Please make sure the module is positioned the right way up.
I have no idea if it makes any difference but I would give it a try.
In my case ZHA uses also Zigbee Channel 11 so it should not make a difference. When i have time i can test it again but i expect that i will not make a difference.
Question is if ZHA needs a different pairing sequence as Philips Hue has also a different pairing sequence compared to Z2M?
No, the method for factory resetting and putting devices into pairing/joining mode is entirely device firmware specific which is totally independent of which Zigbee gateway solution you are using. So you just need to read/follow the device hardware manufacturer manual for the specific device for how to factory reset it and how to put it into pairing/joining mode.
I think i made some progress as i see messages in the logs which could not parsed. So looks like the device can communicate with HA if am not wrong
Log1
Logger: bellows.ezsp.protocol
Source: runner.py:179
First occurred: 09:58:40 (25 occurrences)
Last logged: 10:03:19
Failed to parse frame gpepIncomingMessageHandler: b'7fd6d5003e1f71013e1f71016b02010000d5090000138a2d22a2ff00'
Failed to parse frame gpepIncomingMessageHandler: b'7cd6d6003e1f71013e1f71016b00000000ffffffffe0ffffffffff2e02c5f2a835585ccd1a43d08badddcf2ace49e86f22d7b0d609000004111011121314151617226062636465666768'
Failed to parse frame gpepIncomingMessageHandler: b'7fd6d7003e1f71013e1f71016b02010000d709000068c5233053ff00'
Failed to parse frame gpepIncomingMessageHandler: b'7fd7d8003e1f71013e1f71016b02010000d8090000100c9299c5ff00'
Failed to parse frame gpepIncomingMessageHandler: b'7fd6d9003e1f71013e1f71016b02010000d909000014baa9d58bff00'
Log2
Logger: homeassistant
Source: /usr/src/homeassistant/homeassistant/runner.py:137
First occurred: 09:58:41 (20 occurrences)
Last logged: 10:03:19
Error doing job: Exception in callback ThreadsafeProxy.__getattr__.<locals>.func_wrapper.<locals>.check_result_wrapper() at /usr/local/lib/python3.11/site-packages/bellows/thread.py:110
Traceback (most recent call last):
File "/usr/local/lib/python3.11/asyncio/events.py", line 80, in _run
self._context.run(self._callback, *self._args)
File "/usr/local/lib/python3.11/site-packages/bellows/thread.py", line 111, in check_result_wrapper
result = call()
^^^^^^
File "/usr/local/lib/python3.11/site-packages/bellows/ezsp/__init__.py", line 339, in frame_received
self._protocol(data)
File "/usr/local/lib/python3.11/site-packages/bellows/ezsp/protocol.py", line 180, in __call__
result, data = self.types.deserialize(data, schema)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/bellows/types/__init__.py", line 9, in deserialize
value, data = type_.deserialize(data)
^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/zigpy/types/struct.py", line 302, in deserialize
value, data = field.type.deserialize(data)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/zigpy/types/basic.py", line 851, in deserialize
item, data = cls._item_type.deserialize(data)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/zigpy/types/basic.py", line 190, in deserialize
raise ValueError(f"Data is too short to contain {byte_size} bytes")
ValueError: Data is too short to contain 1 bytes
I have a LED Trading 9126 (or is it a 9133) push button coupler, and I’m seriously considering to go back to z2mqtt tonight, because I need it working yesterday. Would be really nice to get this going. Green Power devices sound nice anyway. Lots of FOH hardware that we are missing here.
If anyone else has “Friends of Hue” (FOH) devices that are white-label products made in partnership with Philips/Signify and based on the standard EnOcean PTM 215Z module with just a custom switch cover (like example Niko 91004, NodOn CWS-4-1-01_HUE, Vimar 03906, Sunricher SR-ZGP2801K4-FOH-E, LED-Trading 9125, Feller 4120.2.S.FMI.61) then I suggest that you test pairing/joining it to ZHA and post feedback in zha-device-handlers repo about which exact Zigbee Coordinator and firmware you tested with → [Device Support Request] Add Friends of Hue Zigbee Green Power EnOcean Switch · Issue #2477 · zigpy/zha-device-handlers · GitHub
FYI, there is now an initial code pull request draft for the zigpy library to add initial support for a proper ZGP (Zigbee Green Power) implementation. From the comments it is still unclear which Zigbee stacks will work (e.i. radio type of Zigbee Coordinator radio adapters), and likely it will initially not be supported to pair ZGP devices directly with the Zigbee Coordinator and instead the initial implementation might only support ZGP end devices via ZGP proxy devices (e.i. Zigbee 3.0 compatible Zigbee Router devices acting as a ZGP proxy).
If you can program in Python and are interested in helping out with the implementation then note that the developer of that new code pull request for zigpy is currently only asking for help from other developers in reviewing his code patches there (end-users should not post there unless already know how to contribute with code testing without handholding), so testers without coding expertise should wait until this first pull request has been merged and the ZHA integration has been updated with newer zigpy release version that has it merged/committed → Zigbee Green Power Support by konistehrad · Pull Request #1282 · zigpy/zigpy · GitHub
Please, if you just want to ”+1” or discuss off-topic workarounds that are not actually not directly related to zigpy then this specific issue in the zigpy repository is not the place to do that. Please don’t post here, instead post in Home Assistant community forum.
FYI, while it was initially looking like only newer Silicon Labs EFR32MGxx and Texas Instrument CC26xx/CC13xx based adapters would get ZGP support in the work-in-progress patch that the zigpy developers are working on, Dresden-Elektronik’s has now also released ConBee III (ConBee 3) Zigbee Coordinator adapter with ZGP-capable firmware. (I assume this means that ConBee 2 and RaspBee 2 or older deconz adapter are likely to not ever get support for ZGP support under ZHA, but at least there is hope for ConBee fans):
Following this thread for a while now - hoping to get my friends-of-hue wall switch operational with ZHA. Looks like this is where the magic is happening now: https://github.com/home-assistant/core/pull/106118
Would be awesome if this could make it into one of the upcoming HA releases!
No that actually unrelated (which is mentioned if you read the comments there), instead you need to wait for this upstream pull request to be completed and then merged into the zigpy library → https://github.com/zigpy/zigpy/pull/1282
I read that a tree fell on his house so I am sure that he has been busy with that, so yeah, have patience. He has posted here that he still plan to get back to it when ge can:
The CSA ( Connectivity Standards Alliance, formerly the Zigbee Alliance) has hower since released updated Green Power Revision 1.1.2 specifications for Zigbee-based Energy-harvesting Technology:
The latest revision of the Green Power standard, Revision 1.1.2 (Zigbee PRO Green Power feature specification Basic functionality set version 1.1.2) introduces additional features and scripts that simplify testing and allow Green Power developers to use the same unified test harness for Green Power receiver products as used for the traditional Zigbee protocol.
Unfortunate not any good news as konistehrad only posted in the pull request that he is swamped with other stuff but can assist if someone else qould be willing to pick up leading the development.