Summary
On a TaHoma gateway accessed through the Local API, /setup returns devices where a subset are gateway-internal objects whose deviceURL starts with ogp:// and which do not carry a controllableName (also missing definition / type). get_setup() (and get_devices()) call converter.structure(response, Setup) / converter.structure(response, list[Device]), and cattrs raises a KeyError while structuring these stub devices — which aborts the entire setup, so no device loads at all.
In my dump: 14 of 30 devices are such ogp:// stubs without controllableName.
Reported stack (via Home Assistant overkiz integration, local API):
KeyError: 'controllableName' # (also 'definition' / 'type') in structure_Device
This is not the Rexel client-selection bug (KeyError: 'auth_implementation') fixed by home-assistant/core#175409 (which changes overkiz/__init__.py client factory). Here the crash is inside pyoverkiz converter.structure on real /setup payloads whose devices legitimately lack controllableName.
Stub device shape (redacted)
The 14 skipped objects are ogp://… gateway-internal entries, e.g. deviceURL: ogp://<PIN>/2550513B, ogp://<PIN>/6BFA79ED, ogp://<PIN>/6CEA3AD2, … — no controllableName / definition / type keys. Real controllable devices (io://…) are unaffected. A full redacted /setup JSON (PIN/tokens masked) can be attached on request.
Proposed fix
In get_setup and get_devices, skip (or tolerate) devices without controllableName before converter.structure — they are gateway-internal ogp:// objects, not controllable devices. A firmware that returns such stubs should not break the whole setup.
Workaround in use
Wrapping OverkizClient._get to filter response["devices"] (setup) / the list (setup/devices) on presence of controllableName before deserialization restores a working setup and cleanly loads the real devices (cover.portail, Velux, …).
Environment
- pyoverkiz via Home Assistant
overkiz integration, Local API mode
- TaHoma gateway firmware (returns
ogp:// stub devices)
Summary
On a TaHoma gateway accessed through the Local API,
/setupreturns devices where a subset are gateway-internal objects whosedeviceURLstarts withogp://and which do not carry acontrollableName(also missingdefinition/type).get_setup()(andget_devices()) callconverter.structure(response, Setup)/converter.structure(response, list[Device]), and cattrs raises aKeyErrorwhile structuring these stub devices — which aborts the entire setup, so no device loads at all.In my dump: 14 of 30 devices are such
ogp://stubs withoutcontrollableName.Reported stack (via Home Assistant overkiz integration, local API):
Distinct from #2164 / home-assistant/core#175409
This is not the Rexel client-selection bug (
KeyError: 'auth_implementation') fixed by home-assistant/core#175409 (which changesoverkiz/__init__.pyclient factory). Here the crash is inside pyoverkizconverter.structureon real/setuppayloads whose devices legitimately lackcontrollableName.Stub device shape (redacted)
The 14 skipped objects are
ogp://…gateway-internal entries, e.g.deviceURL: ogp://<PIN>/2550513B,ogp://<PIN>/6BFA79ED,ogp://<PIN>/6CEA3AD2, … — nocontrollableName/definition/typekeys. Real controllable devices (io://…) are unaffected. A full redacted/setupJSON (PIN/tokens masked) can be attached on request.Proposed fix
In
get_setupandget_devices, skip (or tolerate) devices withoutcontrollableNamebeforeconverter.structure— they are gateway-internalogp://objects, not controllable devices. A firmware that returns such stubs should not break the whole setup.Workaround in use
Wrapping
OverkizClient._getto filterresponse["devices"](setup) / the list (setup/devices) on presence ofcontrollableNamebefore deserialization restores a working setup and cleanly loads the real devices (cover.portail, Velux, …).Environment
overkizintegration, Local API modeogp://stub devices)