`gpepIncomingMessageHandler` fails to parse GPDFs from Friends of Hue switches (EZSP v ? - ZBT-1)

[nmingam]

TL;DR

A community tester running the Green Power branch of zigpy (zigpy/zigpy#1814) on a Silabs ZBT-1 stick has a Busch-Jaeger 6716 U "Friends of Hue" switch send a valid GP Commissioning frame. The NCP forwards it to the host through gpepIncomingMessageHandler (frame ID 0x00C5), but bellows drops the frame with ValueError: Data is too short, so zigpy never sees it.

The zigpy side of the work is ready and tested against the captured payload. This issue is the blocker on the bellows side.

Related prior reports, both about the same callback:

• Support for ZigBee "Green Power" devices such as the Hue Tap Switch #110 (2018) initial GP support request.
• Error pairing friend of hue switch #229 same "not a valid EmberStatus" pattern with a Niko FoH switch.

The failing log

Reported by @dmatscheko in zigpy/zigpy#1814
(comment):

2026-04-22 20:22:30.643 WARNING (MainThread) [bellows.ezsp.protocol]
Failed to parse frame gpepIncomingMessageHandler:
b'7ccdec0086f8710186f871010000000000ffffffffe0ffffffffff2e02c5f21ce9ae2f9e4f85f15de37c1ccbd943870013911aec1d00000411011121314151617226062636465666768'
Traceback (most recent call last):
  File ".../bellows/ezsp/protocol.py", line 164, in __call__
    result, data = t.deserialize_dict(data, rx_schema)
  File ".../bellows/types/__init__.py", line 9, in deserialize_dict
    value, data = type_.deserialize(data)
  File ".../zigpy/types/basic.py", line 927, in deserialize
    raise ValueError("Data is too short")
2026-04-22 20:22:30.648 WARNING (MainThread) [bellows.ezsp] Failed to parse frame, ignoring

Environment:

• bellows: 0.49.0 (zha==1.1.2 in Home Assistant 2026.4.2)
• zigpy: 1.2.2 (same pin) + PR #1814 branch for the GP sink code.
• Adapter: Silabs ZBT-1 (EZSP v?? firmware, exact version to be confirmed by the tester).
• Device: Busch-Jaeger 6716 U Friends of Hue switch (battery-less, source ID 0x0171F886).

The frame is actually well-formed

I decoded the raw payload by hand against the ZGP spec (tables 53-55). Every field is consistent with a real GP Commissioning frame, so the NCP did its job. The NCP firmware does expose GP frames on this stick:

Field	Value
sourceId	0x0171F886
deviceId	0x02 (Generic 2-state switch)
gpdSecurityFrameCounter	0x00001DEC
GPDCommandID	0xE0 (Commissioning)
Encrypted GPD key	1ce9ae2f9e4f85f15de37c1ccbd94387
KeyMIC	0x1A911300
NumGPDCommands	17
GPD commands	0x10–0x17, 0x22, 0x60–0x68