Add get_raw_erd_value() for appliance-specific ERD decoding#111
Open
carles2m wants to merge 1 commit into
Open
Add get_raw_erd_value() for appliance-specific ERD decoding#111carles2m wants to merge 1 commit into
carles2m wants to merge 1 commit into
Conversation
Preserves the raw hex string received for each ERD alongside the decoded value in a parallel cache. Exposes it via a new GeAppliance.get_raw_erd_value() method. Motivation: ErdCode is a flat, appliance-type-agnostic enum, so each hex code is registered once with one converter. Some appliances reuse existing hex codes with different semantics (e.g. standalone gas cooktops emit 0x5520 / 0x5105 with cooktop-specific meaning, while upstream decodes those as COOKTOP_STATUS / UPPER_OVEN_KITCHEN_TIMER with oven/hood semantics). Today a downstream integration has no way to get at the raw bytes after the global converter has run. The new method is an opt-in escape hatch: consumers that know their device's actual schema can call get_raw_erd_value() and decode the bytes themselves, while the existing decoded cache and all existing callers continue working unchanged. - ~15 LOC, no breaking change - No new dependencies - 4 unit tests covering registered/unregistered codes, overwrite, and the never-received None case
carles2m
added a commit
to carles2m/ha_gehome
that referenced
this pull request
Apr 19, 2026
ErdApplianceType.GAS_COOKTOP = "0D" has existed in gehomesdk since 2021 but has never been mapped to a device handler. Result: standalone gas cooktops authenticate, appear in the appliance list, and receive ERD updates, but fall through to the inert ApplianceApi base and produce zero entities. Standalone gas cooktops use the feature flag DEVICE_GATEWAY_V1_BLE_ADVERTISE_ONLY_SENSOR (BLE-to-cloud gateway rather than native WiFi), implement a reduced ERD surface (no per-burner detail, no COOKTOP_STATUS_EXT), and reuse familiar hex codes with different byte semantics. Three of the five ERDs we need (0x5020, 0x5105, 0x5520) are registered in gehomesdk's ErdCode enum with converters that produce oven/hood-shaped objects meaningless on this appliance. We read their raw bytes via appliance.get_raw_erd_value() and decode per the gas-cooktop schema. Entities exposed (reverse-engineered from a Monogram ZGU36ESLSS): - Cooktop On (binary_sensor, 0x5520 byte 0) - Locked (binary_sensor, LOCK class, 0x5900; read-only, see below) - Kitchen Timer (number, writable 0-599 min, 0x5105) - Kitchen Timer Alarm (binary_sensor, SOUND class, 0x5020 byte 0) - Cooking Minutes (sensor, total_increasing, min uom, 0x5902) NOT implemented: writable lock. Brillion rejects gehomesdk's writes to 0x5900 with 400 "erd is not writable" even though the SmartHQ app can lock. Per-OAuth-client-id writability policy; lock stays a read-only BinarySensor. SmartHQ's UI is also one-way (can lock, can't remotely unlock) for safety. Dependency: simbaja/gehome#111 adds GeAppliance.get_raw_erd_value() used by this PR. That SDK change must land first and manifest.json requirements must be bumped to the corresponding gehomesdk release.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
ErdCodeis a flat, appliance-type-agnostic enum — each hex code is registered once with one converter. Some appliances reuse existing hex codes with different semantics:DEVICE_GATEWAY_V1_BLE_ADVERTISE_ONLY_SENSORfeature flag) emit0x5520as a simple cooktop-on aggregate byte, but upstream decodes0x5520asCOOKTOP_STATUSwith per-burnerCooktopStatus(...)semantics that are meaningless on the gas cooktop.0x5105as rawuint16kitchen-timer minutes; upstream decodes0x5105asUPPER_OVEN_KITCHEN_TIMER(timedeltaseconds).0x5020with a simple alarm byte; upstream decodes0x5020asHOOD_TIMER.Downstream integrations today have no way to get at the raw bytes after the global converter has run — the decoded value is already the wrong shape.
Fix
Preserve the raw hex string for every ERD in a parallel cache and expose it via a new
GeAppliance.get_raw_erd_value()method:Usage (downstream)
Context
This is Phase 1 of adding
GAS_COOKTOP(ErdApplianceType.GAS_COOKTOP = "0D") support toha_gehome— see sibling issues simbaja/ha_gehome#305 (F&P cooktop unmapped) and simbaja/ha_gehome#482 (Café gas range cooktop sensors stuck off). Phase 2 would be anha_gehomePR adding aGasCooktopApidevice handler that usesget_raw_erd_value()to decode the cooktop-specific bytes. I'll file that PR if/when this one lands.Tested end-to-end against a live ZGU36ESLSS running a local backport of this change for 2+ days.