Read the LCD_OV_WALL 8888 wall oven family (#572)

[mbillow]

Closes #572.

The NV51K777OS Flex Duo connects over 8888 and answers with its full body, but LCD_OV_WALL_16K had no family table (family_mapped: false). It was read with the identity-only table, so it came up as device_type: unknown with no entities.

Family table

• New LCD_OV_WALL table in legacy_http.py. The appliance uses the same field names the TP2X_DA-KS-WALLOVEN (NW9000KD) uses over CoAP, so each resource lands on that board's href.
  • Operation goes to /operational/state/vs/0, with power and the child lock fanned out to their own hrefs as on the washer.
  • The other resources are Mode, Oven, Temperatures, Doors, Configuration (/remotectrl/vs/0), Information, Diagnosis and Alarms.
• With that table, the existing for_device_by_resources signature (/oven/vs/0 plus Bake) types it as an oven, and it binds with nothing unbound.
• This firmware packs supportedModes into one comma-joined string, with NoOperation and Drain listed twice. A Resource can now name fields to split, via the new joined field. They're split, trimmed and deduplicated on read.

Diagnostics

• The 8888 transport's diagnostics now include unmapped_resources: the sections of the appliance's response that its family's table has no row for. Previously these were dropped without a trace.
  • Unmapped family: everything except identity.
  • Mapped family: anything new, e.g. EnergyConsumption on the washer.
• Nothing is read from them or guessed about them. The list just shows what a new row would need to cover.

Mode labels

• Added labels for SteamBake, SteamRoast, UpperSteamBake, Descale and Drain in all nine languages. The Samsung TP2X_DA-KS-WALLOVEN-000002 not responding to commands #300 wall oven shares the first four of these.
• Healthycook1–6, UpperHealthycook1–4, Autocook and PyroFree still show as raw codes, because the dump doesn't say what they are.

History

This branch briefly carried a rework of the 8888 transport. It chose tables by the appliance's type and read unnamed sections onto /<name>/vs/0. A code review found that the guessed resources could get controls that silently did nothing. We decided the 8888 path shouldn't guess at all, so both rework commits are reverted here.

Open questions for the reporter

• Writes are unconfirmed. Mode, setpoint and cook time follow the washer's aggregate PUT /devices/0, the same as the TP6X_RAC table. I'll ask the reporter to try them.
• Cavities. The dump has a single Temperatures entry, and the upper-cavity modes are mixed into one mode list. Nothing tells the lower or combined cavity apart, so the entities cover whichever cavity the oven reports. A dump taken with the divider out, or while a lower-cavity cook is running, would show whether there's more to read.
• Token. The reporter only got a token by doing it by hand. This PR doesn't touch the token exchange.

Other

• Updated the README's list of 8888 appliances. It still said only the WW6500 washer.

Tests

• Added tests/fixtures/oven_lcd_ov_wall_16k_8888.json: the verbatim transport.bodies block from the dump, with no serial or uuid.
• New TestLcdOvWall in test_legacy_http.py covers:
  • mapping at any capacity
  • the href set
  • splitting the joined mode string
  • typing as an oven with nothing unbound
  • a cook reading through this firmware's float temperatures
  • mode, setpoint and cook-time writes reaching the right wrappers
  • no washer power flag on an oven
• unmapped_resources is covered for an unmapped family (everything but identity) and for the mapped washer (only EnergyConsumption).
• ruff format --check, ruff check, ty check and pytest all pass locally (2632 passed).

🤖 Generated with Claude Code

https://claude.ai/code/session_016Zb8NJJgcZfhsT4KNQ51ab