feat(heimdallr): patch zha lib to add zboss radio type (Zigbee via ZBOSS NCP) #13

Merged

litelotus merged 1 commit from feat/heimdallr-home-automation into main

2026-09-04 20:56:25 +00:00

litelotus commented

2026-09-04 20:56:16 +00:00

Owner

Zigbee on heimdallr's nRF52840 dongle (ZBOSS NCP firmware) needs zha to know the zboss radio type — upstream zigpy/zha never merged it.

Root cause chain (diagnosed live on heimdallr):

HA is actually running fine (the earlier 'won't start' was recovery mode from the trusted_proxies bug, already fixed in #12)
Runtime PYTHONPATH has zha 1.3.1 + zigpy-zboss 1.2.0 (extraPackages worked) — verified against the real systemd env (164 paths)
zigpy-zboss imports cleanly on Python 3.14 (the py3.11 enum issue from the repo issue is gone in 1.2.0)
But RadioType in zha/application/const.py is a hardcoded enum: ezsp/znp/deconz/zigate/xbee → radio_type: zboss rejected → zha setup fails

Fix (puddly's approach from kardia-as/zigpy-zboss#20, applied via home-assistant's packageOverrides hook):

zboss-radio-type.patch: add import zigpy_zboss.zigbee.application + zboss = ("ZBOSS", ...) enum member
Propagate zigpy-zboss into the patched zha's build inputs
Skip test_gateway::test_radio_type (asserts exact enum list)

Verified: patched zha 1.3.1 builds (1192 tests pass + 1 skipped), RadioType.zboss present in the new closure, HA config flow accepts radio_type: zboss (vol.In([t.name for t in RadioType])), config is declarative so the service restart applies it automatically.

Zigbee on heimdallr's nRF52840 dongle (ZBOSS NCP firmware) needs zha to know the `zboss` radio type — upstream zigpy/zha never merged it. **Root cause chain (diagnosed live on heimdallr):** - HA is actually running fine (the earlier 'won't start' was recovery mode from the trusted_proxies bug, already fixed in #12) - Runtime PYTHONPATH has zha 1.3.1 + zigpy-zboss 1.2.0 (extraPackages worked) — verified against the real systemd env (164 paths) - zigpy-zboss imports cleanly on Python 3.14 (the py3.11 enum issue from the repo issue is gone in 1.2.0) - But `RadioType` in zha/application/const.py is a hardcoded enum: ezsp/znp/deconz/zigate/xbee → `radio_type: zboss` rejected → zha setup fails **Fix** (puddly's approach from kardia-as/zigpy-zboss#20, applied via home-assistant's `packageOverrides` hook): - `zboss-radio-type.patch`: add `import zigpy_zboss.zigbee.application` + `zboss = ("ZBOSS", ...)` enum member - Propagate zigpy-zboss into the patched zha's build inputs - Skip `test_gateway::test_radio_type` (asserts exact enum list) **Verified:** patched zha 1.3.1 builds (1192 tests pass + 1 skipped), RadioType.zboss present in the new closure, HA config flow accepts `radio_type: zboss` (`vol.In([t.name for t in RadioType])`), config is declarative so the service restart applies it automatically.

litelotus added 1 commit

2026-09-04 20:56:16 +00:00

feat(heimdallr): patch zha lib to add zboss radio type

ci/crow/push/check Pipeline failed

Details

f539a483b8

zigpy-zboss (already packaged + in extraPackages) imports cleanly on
python 3.14, but zha's RadioType enum has no zboss member upstream, so
ZHA rejects radio_type: zboss. Apply puddly's patch (kardia-as/zigpy-zboss#20)
via home-assistant packageOverrides: add zigpy_zboss import + enum member.
Skip test_gateway::test_radio_type which asserts the exact enum list.

Verified: patched zha 1.3.1 builds, all tests pass, RadioType.zboss present;
zigpy_zboss.zigbee.application.ControllerApplication imports on 3.14.

litelotus merged commit d23509a9e0 into main

2026-09-04 20:56:25 +00:00

litelotus referenced this pull request from a commit

2026-09-04 20:56:27 +00:00

Merge pull request 'feat(heimdallr): patch zha lib to add zboss radio type (Zigbee via ZBOSS NCP)' (#13) from feat/heimdallr-home-automation into main

litelotus referenced this pull request

2026-09-04 22:24:18 +00:00

fix(heimdallr): bump zigpy-zboss to 2.0.3 (OTA config API crash) #18