Hedda
(Hedda)
August 16, 2023, 1:18pm
43
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
opened 08:19AM - 15 Jul 23 UTC
### Problem description
Zigbee Information from NodOn EnOcean Friends Of Hue sw… itch could not parsed
### Solution description
Add new ZHA device
### Screenshots/Video
<details><summary>Screenshots/Video</summary>
[Paste/upload your media here]
</details>
### Device signature
<details><summary>Device signature</summary>
```json
[Paste the device signature here]
```
</details>
### Diagnostic information
<details><summary>Diagnostic information</summary>
```json
[Paste the diagnostic information here]
```
</details>
### Logs
<details><summary>Logs</summary>
```
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'
```
`
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
`
`
Logger: zigpy.zcl
Source: runner.py:179
First occurred: 00:51:21 (119 occurrences)
Last logged: 10:03:19
[0x94AC:242:0x0021] Unknown cluster command 0 b'\x88T>\x1fq\x01\xd4\t\x00\x00\x17\x00\xac\x94\xff'
[0x94AC:242:0x0021] Unknown cluster command 0 b'\x88T>\x1fq\x01\xd5\t\x00\x00\x13\x00\xac\x94\xff'
[0x94AC:242:0x0021] Unknown cluster command 0 b'\x88T>\x1fq\x01\xd7\t\x00\x00h\x00\xac\x94\xff'
[0x94AC:242:0x0021] Unknown cluster command 0 b'\x88T>\x1fq\x01\xd8\t\x00\x00\x10\x00\xac\x94\xff'
[0x94AC:242:0x0021] Unknown cluster command 0 b'\x88T>\x1fq\x01\xd9\t\x00\x00\x14\x00\xac\x94\xff'
`
</details>
### Custom quirk
<details><summary>Custom quirk</summary>
```python
[Paste your custom quirk here]
```
</details>
### Additional information
_No response_
1 Like
Hedda
(Hedda)
November 12, 2023, 7:44am
44
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
zigpy:dev
← konistehrad:zgp
opened 08:07PM - 10 Nov 23 UTC
Copied from the originating comment. Goals for this fork are as follows:
- Im… plement the minimum functionality to conform to being a Green Power Target as per the Green Power Specification
- Create a GreenPowerController class that will do state tracking as per Figures 67-68 of the ZGP spec
- Create ZHA-compatible Devices that are transparently usable by consuming code
Specifically, this means we do not directly receive or transmit Green Power frames. We ask Green Power Proxy devices on the network to do that. The code intends to be flexible enough to allow for that in the future to become a Green Power Target+ device, though that will involve work in all of the implementing `ControllerApplication`s and their respective NCPs.
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.
End-users can also find more information in the GitHub feature tracker issues but also refrain from posting there → https://github.com/zigpy/zigpy/issues/341
The way to only ”+1” this without spamming the developers then is to simply press the thumbs up emoji on the GitHub posts.
Again, also wote and post in the(se) existing Home Assistant community forum thread(s) as that is still the best way to show your interest in this.
1 Like
Hedda
(Hedda)
December 4, 2023, 8:37am
45
Hedda:
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
Zigbee Green Power Support by konistehrad · Pull Request #1282 · zigpy/zigpy · GitHub
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):
Hapeter
(Peter)
February 19, 2024, 6:44pm
46
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!
1 Like
Hedda
(Hedda)
February 19, 2024, 7:32pm
47
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
Hapeter
(Peter)
February 20, 2024, 6:32pm
48
OK, thanks for clarifying. That one doesn’t seem to have as much activity in the last couple of weeks. Patience…
Hedda
(Hedda)
February 20, 2024, 10:41pm
49
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:
opened 12:45PM - 02 Dec 23 UTC
integration: zha
### The problem
I am trying to pair a MOES self-power zigbee switch. However, t… he pairing doesn't work. In the logs, I see the following messages every time I trigger the pairing (pressing the switch in pairing mode):
Two presses:
~~~
2023-12-02 13:35:49.289 DEBUG (bellows.thread_0) [bellows.uart] Data frame: b'44d8b1a9912a69526094e657d3033e3be51873abedce677402399c690381c05814e6dce67c74cd1df0529d5b51d3555e743b049ae1cef8a70e1f17b1e0015d6e6630cb8ab225cd15aa7dae7e11c7fb7e'
2023-12-02 13:35:49.289 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'8520dd7e'
2023-12-02 13:35:49.295 WARNING (MainThread) [bellows.ezsp.protocol] Failed to parse frame gpepIncomingMessageHandler: b'7ce03900ac727956ac7279565400000000ffffffffe0ffffffffff2b0289f38b0ac62580f4d717f0fcb20200a170944cb93f42390400007165726837706f78404750303030318e'
2023-12-02 13:35:49.295 ERROR (MainThread) [homeassistant] 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 345, in frame_received
self._protocol(data)
File "/usr/local/lib/python3.11/site-packages/bellows/ezsp/protocol.py", line 97, 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/bellows/types/basic.py", line 102, in deserialize
raise ValueError(f"Data is too short: expected {length}, got {len(data)}")
ValueError: Data is too short: expected 178, got 29
2023-12-02 13:35:50.238 DEBUG (bellows.thread_0) [bellows.uart] Data frame: b'54d8b1a9912a69521b94e5f650273d9a663c73abedce677402399c690381c05814e6dce67c0a0f14279ba3470a72414519b7a9f5b4e9d4facc6417b1e0015d6e6630cb8ab225cd15aa7dae7ec3013e7e'
2023-12-02 13:35:50.238 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'8610be7e'
2023-12-02 13:35:50.240 WARNING (MainThread) [bellows.ezsp.protocol] Failed to parse frame gpepIncomingMessageHandler: b'7ce04200afd3fa72afd3fa725400000000ffffffffe0ffffffffff2b0289f3f5c8cff249cacb4c51e8a96f8c0c1fc16b956280420400007165726837706f78404750303030315c'
2023-12-02 13:35:50.241 ERROR (MainThread) [homeassistant] 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 345, in frame_received
self._protocol(data)
File "/usr/local/lib/python3.11/site-packages/bellows/ezsp/protocol.py", line 97, 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/bellows/types/basic.py", line 102, in deserialize
raise ValueError(f"Data is too short: expected {length}, got {len(data)}")
ValueError: Data is too short: expected 169, got 29
~~~
### What version of Home Assistant Core has the issue?
core-2023.11.3
### What was the last working version of Home Assistant Core?
_No response_
### What type of installation are you running?
Home Assistant OS
### Integration causing the issue
Zigbee
### Link to integration documentation on our website
https://www.home-assistant.io/integrations/zha/
### Diagnostics information
[home-assistant_zha_2023-12-02T12-34-06.817Z.log](https://github.com/home-assistant/core/files/13536275/home-assistant_zha_2023-12-02T12-34-06.817Z.log)
### Example YAML snippet
_No response_
### Anything in the logs that might be useful for us?
_No response_
### Additional information
_No response_
Hedda
(Hedda)
March 5, 2024, 8:50pm
50
FYI, it looks like development might have started up again on this ZGP pull request:
zigpy:dev
← konistehrad:zgp
opened 08:07PM - 10 Nov 23 UTC
Copied from the originating comment. Goals for this fork are as follows:
- Im… plement the minimum functionality to conform to being a Green Power Target as per the Green Power Specification
- Create a GreenPowerController class that will do state tracking as per Figures 67-68 of the ZGP spec
- Create ZHA-compatible Devices that are transparently usable by consuming code
Specifically, this means we do not directly receive or transmit Green Power frames. We ask Green Power Proxy devices on the network to do that. The code intends to be flexible enough to allow for that in the future to become a Green Power Target+ device, though that will involve work in all of the implementing `ControllerApplication`s and their respective NCPs.
2 Likes
Hedda
(Hedda)
March 25, 2024, 12:24pm
51
FYI, from the comment here by konistehrad related to ZHA Device Handlers version 2 (ZHA-Quirks V2) architectural design developer discussion it sounds as he now has some time again to continue working on his ZGP pull request for zigpy:
Hedda
(Hedda)
May 8, 2024, 1:25pm
52
Still no news in Zigbee Green Power Support by konistehrad · Pull Request #1282 · zigpy/zigpy · GitHub so we do not know when or if that PR will get merged into zigpy.
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.