[gdluck]

Requested by A

What is the problem

The corpus has one F455 capture from 2026-10-09 (issue_674) and one config-entry trace, but no capture of what the F455 firmware answers to each status request MyHOME uses, and none of MyHOME driving every device type through an F455. The F455 has no image in own-firmware-oracle, so live captures are the only evidence for it.

Part of #466

---

What is the solution

Add two verbatim captures from one Legrand F455 (firmware 1.0.76) on the F461 test plant's shared SCS bus (lights 06 / 07 / 09#4#01, F418 dimmer 0010, shutter 05, standalone zone 2, 3550 central unit #0, zone 4, 4611 IR detector 344). The F455's address and MAC and the primary F461's MAC are synthetic (192.0.2.55, 00:03:50:00:11:06, 00:03:50:00:11:07); nothing else is changed. Both files carry only F455 traffic.

1. tests/fixtures/traces/issue_466/F455_full_debug_log_2026-11-06T16-24-46.log: the Home Assistant 2026.11.0 core log of the F455 entry at DEBUG, covering a reload, myhome.sweep_bus, lights on/off, dimmer plain ON / 50 % / 100 % / off, shutter open / stop / close, and the zone 2 setpoint to 22.5 °C and back (MyHOME 2.0.0b17, OWNd 2.0.0b13). It is a .log like the issue_674 F455 log, so the trace matrix script (which attributes every .txt to F454 on this base) leaves the matrix unchanged. The F455 row already exists.
2. tests/fixtures/traces/issue_466/F455_direct_requests_2026-11-06.jsonl: status requests sent directly to the F455 with OWNd, one record per request (ACK, elapsed seconds, collected replies) and per event-session frame. Status requests only; WHO 4 dimension 22, *#16*0*5## and WHO 13 dimensions 10/11/12 were never sent.
3. tests/fixtures/traces/issue_466/README_f455_live_2026-11-06.md (provenance and findings) and tests/test_issue_466_f455_live_2026_11_06_trace.py (13 tests).

---

State Diagram

N/A — tests and fixtures only; no runtime behaviour changes.

---

Hardware Verification

Captured live on the physical F455; every write was restored (dimmer memory left at 100 %, shutter closed, zone 2 setpoint back to 22.0 °C). What the F455 1.0.76 firmware does:

Request	F455 answer
*#4*Z*0##, *#4*Z*12##, *#4*Z*13##, *#4*Z*14##, *#4*Z*19##	answered on the command session in 0.09–0.12 s
*#4*Z##	all five frames on the event session, ACK only after 8.9–9.0 s (one second short of OWNd's 10 s window; the issue_674 timeouts)
*#4*0##	no frame, ACK after 9.1 s
*#4*#0##	central unit mode and flags in 1.08 s
*#4*Z*20##, *#4*0*20##, *#4*Z*60##	NACK in < 20 ms
*#4*Z#1*20##	answered (*#4*2#1*20*7##, *#4*4#1*20*0##)
*#1*0## / *#2*0##	the four lights in 1.34 s / the shutter in 1.22 s, terminated with an ACK
*#1*0010*1## on the OFF dimmer	answered with the dimension-4 form *#1*0010*4*100*2## (as on F454 and F459)
*#2*05*10##, *#18*51*51##, *#18*51*113##	no ACK inside OWNd's 10 s window (no position-reporting shutter, no meter)
*#5*0## / *#25*344##	ACK with no reply (3.9 s / 15 ms)
WHO 13 / 1013	type 200, firmware 1.0.76, uptime, object model 8 (F455)

What MyHOME does on it (debug log):

• The entry is configured on a shared bus as standby of the F461, whose entry was not loaded. MyHOME still skips every startup general request (Skipping WHO=1/2/4/5/16/18 discovery: follower gateway on shared bus) and prunes 9 entities "in favor of primary gateway". myhome.sweep_bus sends only WHO 13/1013 reads.
• The climate zones send only *#4*#0##, *#4*Z*11## and the refused *#4*Z*20##. No temperature, setpoint or zone-status request goes out, so the standalone zone 2 stays empty until something else puts its values on the bus.
• 44 of 44 inbound frames in the log and 52 of 52 event frames of the direct runs parse, identically on OWNd 2.0.0b13 and dev. MyHOME logs the WHO 1001 diagnostics as Unsupported message type at DEBUG.

The suggested fix for the climate polling goes in a separate PR built on these fixtures.

---

How is it tested

• tests/test_issue_466_f455_live_2026_11_06_trace.py (13 tests): green against the pinned OWNd 2.0.0b13 and against dev OWNd.
• scripts/sync_documentation.py --check and scripts/verify_ha_standards.py pass; ruff check and ruff format --check clean.

---

Where are the traces

tests/fixtures/traces/issue_466/F455_full_debug_log_2026-11-06T16-24-46.log and tests/fixtures/traces/issue_466/F455_direct_requests_2026-11-06.jsonl (SHA-256 pinned), described in tests/fixtures/traces/issue_466/README_f455_live_2026-11-06.md.

---

What does the Firmware Oracle / Encyclopedia say

1. OpenWebNet Encyclopedia (WHO = 4, who-4-temperature-control/dimensions.md): dimensions 0, 12, 13, 14, 19 are per-zone reads; dimension 20 is published as *#4*Z#N*20## (Z#N, Z#0, 0#0), which is the form the F455 answers. WHO = 1 (who-1-lighting/dimensions.md) records an F454 answering a dimension-1 read of an OFF dimmer with dimension 4; the F455 does the same.
2. Firmware Oracle: no F455 image is in the fleet (findings/F455/emulation-strategy.md only), so these captures are the first request-by-request F455 evidence.

---

Checklist

• PR Description: Follows the structured sections above.
• Trace-Backed (if protocol/device change): Real F455 captures.
• V2 Architecture: No entities touched (tests + fixtures only).
• Tests & Linters: pytest (on OWNd b13 and dev) and ruff pass.

🤖 Generated with Claude Code

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[gdluck]

@GreenGrassBlueOcean, could you give feedback on this corpus and on its companion fix #873?

For context: this is a real, physical Legrand F455 (firmware 1.0.76), not an emulation. It sits on the same SCS bus as our F461 test gateway, so it drives the same physical devices as the F461 fixtures already in the corpus: lights 06/07/09 behind an F422, the F418 dimmer 0010, shutter 05, standalone zone 2, the 3550 central unit and zone 4. Every frame in these two files was sent or received by the F455 alone. The F461 was not used for any of it.

Two points I'd especially value your view on:

1. The fix in fix(climate): ask silent F455 zones their state once after startup (#466) #873. It is limited to the F455: a temperature and setpoint read per zone, *#4*0## left out of the sweep, and the per-actuator *#4*Z#1*20## form. Each entry is tied to a request/response in F455_direct_requests_2026-11-06.jsonl.
2. Standby entries. The entry ran as standby of the F461 while the F461 entry was not loaded. MyHOME still skipped all startup discovery and pruned entities "in favor of primary gateway". Is that intended, or should a standby take over discovery when its primary is not running? I left it out of fix(climate): ask silent F455 zones their state once after startup (#466) #873.