Skip to content

Add support for the LG WFV474PGV oven - #144

Open
jmhufford wants to merge 7 commits into
anszom:masterfrom
jmhufford:feature/wfv474pgv-oven-support
Open

Add support for the LG WFV474PGV oven#144
jmhufford wants to merge 7 commits into
anszom:masterfrom
jmhufford:feature/wfv474pgv-oven-support

Conversation

@jmhufford

Copy link
Copy Markdown

Adds a driver for the LG WFV474PGV double oven (deviceType 301) and wires it
into the Home Assistant bridge.

Everything was derived from live captures against a real appliance, and writes
are limited to command shapes actually observed on the wire. Fields we don't
yet understand stay visible through a diagnostic sensor rather than being
guessed at.

Exposes: cooktop status; per-cavity current/set temperature, state, mode,
and cook time; a settable timer; staged temperature, cook time, and Lower mode
selection; and Start and Cancel buttons per cavity.

Remote start is gated on the appliance reporting that cavity ready — both in
HA (the button goes unavailable) and again in the driver before sending.

31 tests, most built on captured frames, including both remote-start commands
reproduced byte-for-byte.

Jerome added 7 commits August 22, 2026 13:02
- Keep staged remote-start parameters across device reconnects so the
  fresh instance the bridge constructs on transport reopen no longer
  republishes defaults over the user's retained HA selections
- Force the remote-start readiness topics OFF at construction so a stale
  retained ON cannot enable the Start buttons before live status arrives
- Publish the full inner frame as undecoded_frame so the dedup cache no
  longer swallows distinct 0x72 one-shot events, and surface malformed
  or foreign frames there instead of dropping them silently
- Redact decoded bytes (cavity fields, timer, cooktop slots) from
  raw_status so per-second counters no longer defeat the publish cache
- Mask the apparent remote-started flag 0x80 in formatOvenMode so
  panel-started cooks decode instead of reporting Unknown
- Reject blank numeric payloads (Number('') coerces to 0, which means
  "no time limit" for cook time), validate against the constraints
  declared in the discovery config, and re-assert the previous retained
  value to HA when a write is rejected
- Restrict the acknowledgement match to the observed 0x43/0x44 families
- Deduplicate the per-cavity discovery config and setProperty dispatch
  behind shared generators, preserving deployed unique_ids
- Build test frames with encodePacket so they carry valid checksums
The staged remote-start parameters were left over from the protocol
captures: 170F for three minutes on Upper (the minimum-temperature test
cook) and Convection Roast at 350F with no time limit on Lower. Neither
is a sensible starting point for a freshly discovered appliance, and both
are user-visible in Home Assistant until the first write.

Default both cavities to 350F for ten minutes and Lower to Bake. Existing
appliances are unaffected, since they restore from the retained MQTT
topics.

Four tests were deriving their inputs from these defaults rather than
stating them. The two that reproduce real captured start frames now stage
the captured parameters explicitly, and the two mode tests use a value
distinct from the default so they still prove a revert instead of passing
trivially.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant