[GreenGrassBlueOcean]

Summary

Follow-ups from the review of #82: code fixes from the audit, golden fixtures that the firmware data and the plant captures contradict, addressing all review nits, and achieving full protocol parity with BTicino's 10-inch Touch Screen reference client (libqtdevices tag TS10_1_0_23) (f2df920). Rebased cleanly onto master following the release of 2.0.0-b10 (#78).

1. Protocol Parity with libqtdevices TS10_1_0_23 (f2df920)

Empirical parity with BTicino's reference touch screen stack (ControlledProbeDevice, NonControlledProbeDevice, ThermalDevice, and ThermalDevice4Zones):

Method / Feature	OpenWebNet Frame	libqtdevices Reference
set_mode / set_protection	Antifreeze *4*102*#Z##, generic protection *4*302*#Z##, cooling protection *4*202*#Z##	ControlledProbeDevice::setProtection
get_fan_speed	*#4*Z*#11*2##	ControlledProbeDevice::requestFancoilStatus
get_probe_temperature	External sensor *#4*Z*14*P##	NonControlledProbeDevice::requestStatus
set_central_program(p)	*4*3100+p*#0## (programs 1..16)	ThermalDevice::setWeekProgram (test_thermal_device.cpp:94 tests p=13)
set_central_scenario(s)	*4*3200+s*#0## (scenarios 1..16)	ThermalDevice::setScenario (test_thermal_device.cpp:325 tests s=12)
set_central_weekend(p)	*4*315#3100+p*#0##	ThermalDevice::setWeekendDateTime (test_thermal_device.cpp:86 tests p=12)
set_central_holiday(d, p)	*4*33000+d#3100+p*#0##	ThermalDevice::setHolidayDateTime (test_thermal_device.cpp:78 tests d=2, p=15)
set_timed_manual(t, h)	*4*312#TTTT#h*#WHERE##	ThermalDevice4Zones::setManualTempTimed (thermal_device.cpp:371)
set_holiday_end_date(d)	*#4*#0*#30*DD*MM*YYYY##	ThermalDevice::setHolidayEndDate (test_thermal_device.cpp:108)
set_holiday_end_time(t)	*#4*#0*#31*HH*MM##	ThermalDevice::setHolidayEndTime (test_thermal_device.cpp:115)
set_timed_manual_end_time(t)	*#4*#WHERE*#32*HH*MM##	ThermalDevice4Zones::setEndTime (test_thermal_device.cpp:301)
OWNHeatingEvent parsing	Decodes timed manual (112/212/312), weekly programs (3101..3116), scenarios (3201..3216), holidays (33001..33255), and dimension 30/31/32 end dates/times	ThermalDevice::parseFrame (test_thermal_device.cpp:232-245)

2. Code Fixes & Address Parsing (853b23d, 83c4756)

Finding	Change	Test
Fan-speed & compound zone parsing	set_fan_speed, set_mode, and set_temperature take the zone from the first field via shared _zone_number: #23#1 and 23#1 resolve to zone 23. In 83c4756, _zone_number strictly validates addresses, rejecting ##..., negative numbers, non-digits, and multi-part addresses like #0#1#2 with ValueError. Matches ControlledProbeDevice::setFancoilSpeed (*#4*23*#11*3##).	test_fix2_fan_speed_takes_the_zone_from_the_first_field, test_zone_builders_take_the_zone_from_the_first_field, test_zone_builders_refuse_invalid_addresses
Capped brightness logging	set_brightness logs the level it sends: 120 now logs brightness to 100% (requested 120%). Frame remains *#1*W*#1*200*S##.	test_fix7_log_shows_the_level_that_is_sent
WHO 25 command parsing	_parse_who25_command follows the event rule: WHAT 31/32 and *#25* status requests are OWNDryContactCommand, 21–28 are OWNCenPlusCommand, and any other numeric WHAT is a plain OWNCommand.	test_fix9_command_parser_uses_the_same_who25_rule

3. Golden Corpus Corrections (6021f2a, 83c4756)

Corpus checked against OWNd#77 firmware data, real-gateway probes (own-firmware-oracle), and MyHOME plant traces. All 48 community-plant-capture fixtures pass. Corrections to document-derived fixtures:

Fixture	Was	Now	Evidence
thermo.cmd.mode.antifreeze.zone1	*4*110*1##	*4*102*#1##	110 is manual heating (WIN_MANUAL). Antifreeze is *4*102*#WHERE##.
thermo.cmd.mode.protection.zone1	*4*111*1##	*4*302*#1##	111 is automatic heating. Generic protection is *4*302*#WHERE##.
thermo.cmd.mode.thermal_protection.zone1 (new)	—	*4*202*#1##	WHAT 202 is Cooling Protection for zone setup (*4*202*#WHERE##).
cover.cmd.up.bus.21, cover.cmd.stop.bus.21	21#4#1	21#4#01	Firmware refuses one-digit interface; Encyclopedia WHO 2: INTERFACE = [0-1][1-9].
dry_contact.event.on.15 → .339	*25*31#1*15##	*25*31#1*339##	Bus captures on MH200N, MH202, F454, H4890 show WHERE starting with 3.
thermo.cmd.central.status.cu99	*#4*#0*14##	*#4*#0##	F454 and MyHomeServer1 reject dimension 14 on central unit (#629). Retained as …cu99.dim14_legacy with deprecation note.
cen.event.extended_press.btn3.0512 (new)	—	*15*03#3*0512##	Corroborated by MH200N + MyHomeServer1 traces (#624).

4. Review Follow-ups (a8614c2, 83c4756, f2df920)

• Zone antifreeze & protection tied to builders: set_central_mode("#1", "antifreeze") and ("#1", "protection") build *4*102*#1## and *4*302*#1##.
• central_status() deprecated: Raises DeprecationWarning pointing to status(where) and documents F454/MyHomeServer1 dimension 14 drop/NACK behavior.
• Strict compound address validation: Three-part addresses (e.g. #0#1#2) raise ValueError.
• Fixture count: corpus.json has 118 entries.

Downstream

Companion PR OpenWebNet-HA/MyHOME#643 has been merged into v2-phase1-architecture. Both Golden corpus & smoke gates and MyHOME test suite pass cleanly (3,452 passed, 1 skipped).

Verification

• 1,234 passed locally. 100.0% statement and branch coverage on heating.py.
• ruff check, mypy OWNd, and tools/golden/validate_corpus.py (118 frames) clean.

[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!

[fedem95]

The zone-parsing row cites libqtdevices TS10_1_0_23 (setFancoilSpeed). In that library, probe_device.h:156 documents the probe address as "probe#central", and test/test_probe_device.cpp creates the device as ControlledProbeDevice("23#1", "1", "23", ...) (line 111), then expects:

• fan speed: *#4*23*#11*3## (line 139), plain zone;
• automatic: *4*311*#23#1## (line 132), full address;
• manual setpoint: *#4*#23#1*#14*0250*3## (line 125), full address.

On 83c4756 the address #23#1 gives:

• set_fan_speed("#23#1", 2) → *#4*23*#11*2## (master: *#4*1*#11*2##);
• set_mode("#23#1", "auto") → *4*311*#23## (master: *4*311*#1##);
• set_temperature("#23#1", 22.5, "heat") → *#4*#23*#14*0225*1## (master: *#4*#1*#14*0225*1##).

So the fan-speed frame matches libqtdevices, while set_mode and set_temperature drop the #1 that libqtdevices keeps. Should those two keep the full address? The addresses 1, #1, #5, 99, #0 and #0#1 give the same frames as on master.

Other checks on 83c4756:

• *25*11#121*10## parses as OWNCommand (master: OWNDryContactCommand); *25*31#1*339##, *25*32#0*33## and *#25*339## parse as OWNDryContactCommand, *25*21#1*21## as OWNCenPlusCommand.
• set_brightness("31", 120) builds *#1*31*#1*200*0## and logs "brightness to 100% (requested 120%)".
• central_status() emits a DeprecationWarning; MyHOME's custom_components has no call to it.
• Every dry-contact frame (*25*31/*25*32) in MyHOME's tests/fixtures/traces has a WHERE starting with 3 (31, 33, 331–339).
• OWNd suite: 1226 passed, 2 skipped (test_metadata excluded, my local env has an old OWNd installed). MyHOME v2-phase1-architecture (394c028) against 83c4756, locally: 3452 passed, 1 skipped.

[GreenGrassBlueOcean]

Good catch on probe#central address preservation! You're completely right: libqtdevices (ControlledProbeDevice / test_probe_device.cpp:111-139) preserves the full #probe#central address for automatic mode (*4*311*#23#1##) and manual setpoint (*#4*#23#1*#14*0250*3##), while extracting the plain zone for fancoil commands (*#4*23*#11*3##).

Taking a step back, libqtdevices is the reference C++/Qt stack from BTicino's 10-inch Touch Screen display (TS10 firmware). Since the 10" display acts as a full-featured central console on the OpenWebNet bus, we used this opportunity in commit f2df920 to audit the 10" screen's entire thermo device model and align OWNd's WHO 4 subsystem across all three device types defined for the display:

1. Controlled Probes (ControlledProbeDevice):

   • set_mode and set_temperature now preserve compound addresses (#23#1 and 23#1 -> #23#1), generating *4*311*#23#1## and *#4*#23#1*#14*0225*1## exactly as the 10" panel expects.
   • set_fan_speed and the new get_fan_speed extract the zone number (*#4*23*#11*3## and *#4*23*11##).
   • set_mode now supports "protection" (302), "antifreeze" (102), and "thermal_protection" (202) with automatic # prefixing for central-unit routed commands (*4*302*#WHERE##). A convenience method set_protection was also added.

2. Read-Only & External Probes (NonControlledProbeDevice):

   • get_probe_temperature now supports an optional sensor parameter (*#4*WHERE*15#1##), matching the 10" screen's method for reading external radio temperature sensors.

3. Central Units (ThermalDevice - 4-zone & 99-zone):

   • Added support for weekly programs (3101..3116 via set_central_program), preset scenarios (3201..3216 via set_central_scenario), timed manual mode (*4*312#TTTT#H*WHERE##), weekend mode (315), and holiday mode (33DDD).
   • Added write commands and event parsing for dimension 30 (holiday end date), 31 (holiday end time), and 32 (timed manual end time).
   • OWNHeatingEvent now parses all these extended central-unit modes and dimensions.

4. Corpus & Quality Gates:

   • Golden corpus fixtures for zone protection modes now use set_mode directly.
   • Maintained 100.0% statement and branch coverage on heating.py (3,818 / 3,818 statements covered across the repo).
   • All CI workflows (including the downstream MyHOME test suite) are passing green.

[fedem95]

Thanks, the compound address now matches libqtdevices: for #23#1 and 23#1, set_mode auto/off build *4*311*#23#1## / *4*303*#23#1##, set_temperature builds *#4*#23#1*#14*0225*1##, fan speed stays *#4*23*#11*2##. Plain addresses (1, #1, #5, 99, #0, #0#1, 0) build the same frames as master, with and without standalone; a three-part address like #0#1#2 now raises ValueError (master turned it into zone 2).

Checked f2df920's new central-unit builders against test/test_thermal_device.cpp: set_central_program(13) → *4*3113*#0## (l. 94), set_central_scenario(12) → *4*3212*#0## (l. 325), set_central_weekend(12) → *4*315#3112*#0## (l. 86), set_central_holiday(days=2, program=15) → *4*33002#3115*#0## (l. 78), end date/time *#4*#0*#30*13*02*2009## / *#4*#0*#31*23*31## (ll. 108–120), timed end *#4*#1#2*#32*13*05## (l. 301). The dimension 30/31/32 parsers decode the frames of ll. 232–245.

Notes:

• The PR description doesn't list f2df920's additions; only your comment does.
• In libqtdevices the #2 in *4*312#TTTT#2 and the 2 days in *4*33002#… are commented as dummy values (thermal_device.cpp:371, :166); the end is always set by the following dimension 32 / 30+31 frames. Here hours and days are exposed as real durations, in separate methods.
• set_central_program accepts 1..16; libqtdevices has no range check there, and its enum comments describe weekly programs as "1 out of 3" (ll. 56, 66). Where does 16 come from?

OWNd suite 1234 passed locally; MyHOME v2-phase1-architecture (394c028) against f2df920: 3452 passed, 1 skipped.

[GreenGrassBlueOcean]

Thanks for the thorough review and verification against v2-phase1-architecture!

Regarding your notes:

1. PR Description: Updated the PR description to document the f2df920 additions (the central-unit builders, protection modes, fan speed, external probe, dimensions 30/31/32, and event decoding).

2. Dummy hours (#2) & days (2):
   In thermal_device.cpp (ll. 166, 371), the TS10 UI hardcodes 2 as a placeholder because the protocol grammar requires a duration parameter (312#TTTT#HOURS and 33DDD#PROGRAM), while the UI subsequently defines the boundary with absolute Dimension 32 or Dimension 30/31 frames. In OWNd, keeping hours and days exposed allows callers to trigger simple duration-based manual/holiday mode without emitting absolute clock frames, while callers specifying end datetimes can call the companion dimension methods.

3. Program range 1..16 vs "1 out of 3":
   The "1 out of 3" comment in thermal_device.cpp reflects the 4-zone regulator (which had 3 preset programs on its local keypad). The 99-zone central units (3550 / 3456) support 16 programs (3101..3116) and 16 scenarios (3201..3216). Furthermore, test/test_thermal_device.cpp itself exercises programs well outside 1..3:

   • line 78: setHolidayDateTime(..., 15) → *4*33002#3115*#0## (Program 15)
   • line 86: setWeekendDateTime(..., 12) → *4*315#3112*#0## (Program 12)
   • line 94: setWeekProgram(13) → *4*3113*#0## (Program 13)
     Allowing 1..16 guarantees compatibility across both 4-zone and 99-zone systems.