F455 multiple timeouts

Hi. I tried to install v2 on a friend plant and keep getting timeouts every few seconds

home-assistant_2026-10-09T17-34-15.609Z.log

thanks for the trace!!

Now its stable, but the start was awful

f455 is terrible gateway

F455	010102 (1.1.2)	Bare-metal ARM Cortex-M	3	Monolithic .bin	Flash image F455_1_1_2.bin (301 KB, no OS)	Pending Emulation (Bare-metal MCU — zero matrix value)

@gdluck

Thanks again @gdluck for the log! We conducted a thorough protocol trace analysis on the 315 log events and identified exactly why the start was so painful, and opened PR #675 with a fix + authentic trace fixture.

Why was the start so slow (~2.7 minutes of timeouts)?

Your friend's installation has 16 heating zones (zones 35 to 50) and an F455 gateway:

Protocol Asymmetry Between Gateways:
- In standard OpenWebNet WHO 4 (WHO_4 2.pdf), dimension-less status requests *#4*WHERE## are only defined for WHERE = 0 (general plant sweep) and WHERE = #0 (central unit). Individual zone status requests *#4*Z## (zones 1..99) are not part of the standard SCS bus protocol.
- Physical thermostats (LN4691, 3550, etc.) on the SCS bus have no telegram handler for dimension-less *#4*Z##.
- On physical bridge gateways (F455, F454, MH200N, MH202), incoming command frames are forwarded directly to the SCS bus. Because the bus is silent, the gateway sends no response back to Home Assistant.
- On MyHomeServer1 (which we analyzed in fix(climate): keep AUTO zones on season frames, write generic setpoint mode #649), a software daemon (bt_luci) intercepts *#4*Z## and replies directly from its internal cache with dimensions *#4*Z*0*...##, *#4*Z*12*...##, *#4*Z*14*...##, etc.
The 160-Second Serial Timeout Cascade:
- When Home Assistant loaded the 16 climate entities at startup, it scheduled status polls for each zone (*#4*35##, *#4*36##, etc.).
- OWNd command session waited COMMAND_TIMEOUT = 10 seconds per request.
- After 10.08 seconds of silence:
  WARNING (MainThread) [custom_components.myhome] [F455 gateway - 192.168.1.136] Timed out awaiting the complete response for '*#4*35##'; command session closed.
- OWNd had to drop the socket, re-establish a TCP connection, complete HMAC-SHA256 authentication, and then attempt the next zone query.
- For 16 zones: 16 × 10.08 s = 161.3 seconds (~2.7 minutes) of serial timeouts locking up command queue 0! Any light or cover command sent during this period was stuck in line.
Spontaneous Telemetry Was Already Received:
- The trace shows that upon startup, the general sweep *#4*0## was sent and the physical thermostats broadcasted their full state spontaneously on the monitor session (dimensions 0, 12, 13, 14, 19, 20).
- Thus, individual *#4*Z## point-to-point queries were not only failing, but completely redundant.

The Fix (PR #675)

Identified physical gateways (F455, F454, MH200, MH201, MH202, etc.) via a new supports_zone_status property.
Disabled _poll_on_add and point-to-point async_update() status requests on physical gateways, relying on the startup sweep and spontaneous monitor updates instead.
Added the authentic F455 trace fixture and deterministic replay test suite in tests/test_issue_674_f455_climate_trace.py.

fix(climate): eliminate 10s command session timeouts on F455 and phys…

test(climate): fix F455 replay dispatcher signal and enforce strict s…

Merge pull request #675 from OpenWebNet-HA/test/issue-674-f455-climat…