[gdluck]

Requested by A

Status: draft, blocked by design until the OWNd pin bump. Two required checks of this repository are red on this branch by construction (see Testing): they run the MyHOME suite, whose scripts/update_gateway_profiles.py hard-codes the F461 and MyHomeServer1 discovery rows as [1, 2, 4, 16, 18] and whose tests compare that row with profile.supports_who. The MyHOME companion that changes those rows is a draft that is red against the pinned OWNd for the same reason; the pair lands together with the OWNd release that includes this PR.

Summary

Beyond the startup sweep (already gated by MyHOME#794's sweep_omits), this fixes a shared-bus delegation gap in MyHOME's topology.py: gateway_supported_whos() strips {5, 16, 22} by hand for the MyHomeServer1 but had no override for the F461, so on a shared F461 + MH202 (or F454) bus the Tier 1 F461 won Primary and kept 16 in its WHOs, which stopped the MH202 from taking WHO 16 (F441M matrix sound) by sec_whos - pri_whos. With WHO 16 gone from F461Profile, the delegation follows the profile.

F461Profile and MyHomeServer1Profile list WHO 16 (Sound System) in supported_who. Neither gateway has a WHO 16 translator: all 86 WHO 16 inputs of the oracle suites are refused on both (and the four status requests re-sent live on 2026-10-24, *#16*0*5##, *#16*0*1##, *#16*1*5##, *#16*0*12##, NACK in 3-9 ms on F461 2.0.11 and MyHomeServer1 3.87.13), so MyHOME's startup sweep sends a *#16*0*5## that is always NACKed, a standby F461 / MyHomeServer1 claims WHO 16 events it has no translator for, and a configured WHO 16 media player produces nothing but refused frames (OpenWebNet-HA/MyHOME#424 describes the plants that speak only WHO 22). Their sound system is WHO 22, which both forward.

Refs OpenWebNet-HA/MyHOME#424, OpenWebNet-HA/MyHOME#459, OpenWebNet-HA/MyHOME#794 (the gate that reads the profile), OpenWebNet-HA/MyHOME#799 (the live NACKs).

Changes

• OWNd/profiles.py: _WITHOUT_WHO16 = (WHO_SOUND,); the F461 and MyHomeServer1 supported_who drop it (next to the existing WHO_LOAD_CONTROL exclusion). WHO 22 stays listed and supports_audio is unchanged, so features_summary and the README profile table do not change. No new flag: supported_who already carries the meaning, and supports_who(16) is what MyHOME's sweep, sweep_bus service, standby ownership and topology delegation read.
• Not changed, on purpose:
  • MH202 keeps WHO 16. Its oracle refuses WHO 16 commands too, but a live MH202 relays WHO 16 state frames from an F441M matrix (*#16*41*1*1##, *#16*41*1*6##; OpenWebNet-HA/MyHOME#669 trace), and supported_who also decides which gateway owns those events on a shared bus. The docstring records this. One inference, stated as such: whether an F461 / MyHomeServer1 would relay WHO 16 events from an F441M on its bus is untested (no such plant is available); the removal rests on the missing bt_difson translator, the refused inputs and the OpenWebNet-HA/MyHOME#459 statement. If the maintainers prefer to keep event ownership, a tri-state flag is the alternative.
  • F459 / F460 have no dedicated profile and resolve to GenericGatewayProfile, whose default keeps WHO 16 for the F454 / MH200N class.
• python scripts/sync_documentation.py --update reports the README already in sync (the profile table lists features, not WHOs). CHANGELOG.md: entry under [Unreleased] / Fixed.

Topology side effect in MyHOME (from the review of the MyHOME uses of supported_who): topology.py already strips 16 / 22 for a MyHomeServer1; with this change an F461 primary lets a WHO-16-capable follower own WHO 16 (and 22) events, which is correct, and a same-tier F454 / F461 pair now picks the F454 by WHO count instead of by MAC. The standby failover (gateway_events.py) no longer lets a standby F461 / MyHomeServer1 claim WHO 16 events it cannot relay. One cost: a WHO 16 media player configured against one of these gateways polls *#16*ZONE*5## per zone at startup (media_player.py) instead of one refused sweep frame; such a player cannot work on these gateways anyway, and the MyHOME side gates that poll.

Alternative considered and not chosen: keep WHO 16 in supported_who and add a tri-state supports_who16_status_request = False flag that OpenWebNet-HA/MyHOME#794 reads for the *#16*0*5## gate. That would keep this repository's CI green today, but it would leave supported_who advertising a WHO that no capture or published source supports (the #100 rule: supported_who lists only what a capture or a published spec supports), and it would leave the standby / topology ownership of WHO 16 events on these gateways in place. The removal rests on: 86 of 86 WHO 16 oracle inputs refused on both images, no bt_difson in either firmware image, and two live NACKs on two models.

State Diagram

stateDiagram-v2
    direction TB

    state "1. MyHOME startup sweep per WHO in profile.supported_who (gateway.py)" as Sweep {
        [*] --> Who16
        Who16 --> Sent : before - 16 in F461Profile / MyHomeServer1Profile\n*#16*0*5## sent, NACK in 3-5 ms , F461 2.0.11, MyHomeServer1 3.87.13
        Who16 --> Skipped : after - 16 not in supported_who\nlog Skipping WHO=16 discovery - not supported by F461 profile. - nothing sent
        [*] --> Who22
        Who22 --> SentOk : unchanged - WHO 22 stays listed, supports_audio True
    }

    state "2. Standby / topology ownership of WHO 16 events on a shared bus (gateway_events.py, topology.py)" as Own {
        [*] --> F461primary
        F461primary --> Follower : after - a WHO-16-capable follower , F454, MH200N, MH202, ... owns WHO 16 + 22
        F461primary --> Itself : before - the F461 claimed WHO 16 events it cannot relay
    }

Loading

Where are the traces

Subsystem	Capture	Plant	Frames verified by this PR
WHO 16 status request on the F461	trace PR: OpenWebNet-HA/MyHOME#799 (open), f461_live_2026-10-23 run 1 (run1_oracle_replay_readonly)	BTicino F461 2.0.11	*#16*0*5## NACK within 5 ms; all 18 WHO 16 requests of the run NACK in under 10 ms
WHO 16 status request on the MyHomeServer1	trace PR: OpenWebNet-HA/MyHOME#799 (open), myhomeserver1_live_2026-10-24 run 2 (run2_reads_thermo_sound_alarm_lights)	MyHomeServer1 3.87.13 (the oracle emulates 2.82.06)	*#16*0*5## and *#16*101*5## NACK in 3 ms (immediate refusal, no bus timeout)
earlier MyHomeServer1 report	upstream MyHOME fixture tests/fixtures/traces/issue_466/MyHomeServer1_dead_zone_nacks_2026-09-29T22-45.txt ("Gateway rejected status request *#16*0*5## (NACK, 0 response(s))")	MyHomeServer1	*#16*0*5##
MH202 relaying WHO 16 (why MH202 keeps it)	upstream MyHOME fixture tests/fixtures/traces/mh202_sound_intercom_ducking (OpenWebNet-HA/MyHOME#669)	MH202 + F441M	*#16*41*1*1##, *#16*41*1*6##

What does the Oracle say

Every WHO 16 frame in the suites, results/F461/020011/oracle/full/*.tsv and results/MyHomeServer1/028206/oracle/full/*.tsv: 86 distinct WHO 16 inputs per gateway (77 of them in sound-who16-source, the rest in trace-corpus and the other suites), all nack / silent, i.e. the translator never puts them on the bus. First rows of sound-who16-source.tsv on both:

Frame	F461 020011	MyHomeServer1 028206
*#16*0*5##	nack / silent	nack / silent
*#16*100*5##	nack / silent	nack / silent
*#16*101*#10*1##	nack / silent	nack / silent
*#16*101*#6*0*107000##	nack / silent	nack / silent
... (73 more)	nack / silent	nack / silent

Firmware images (own-firmware-oracle README.md, firmware table): F461 020011 ships bt_luci, bt_device, bt_termo, bt_multi, bt_supervisione, coso (plus bt_daemon, openserver, scsserver); MyHomeServer1 028206 the same set; neither ships bt_difson (the WHO 16 translator that F453, F453AV, F454, MH200 and MH200N do ship). The F461 openserver [Stackopen] section in oracle/targets/F461/020011.yaml registers bt_multi for WHO 22 and no client for WHO 16.

WHO 22 (sound-who22, 63 inputs per gateway): put on the bus by both for 60 of the 63 inputs (44 ack/out, 16 nack/out; 1 ack/silent, 2 nack/silent; identical on F461 020011 and MyHomeServer1 028206), which is why WHO 22 and supports_audio stay. On the OpenWebNet-HA/MyHOME#459 quote: the maintainer wrote there that the MyHomeServer1 firmware "discards 5, 16, 22"; this PR uses it for 16 (and 5 is handled by OpenWebNet-HA/MyHOME#794 / OpenWebNet-HA/MyHOME#803), while for 22 the published sound-who22 rows show the frames forwarded, so WHO 22 is kept. No WHO 22 frame was sent to the live MyHomeServer1 (a real home), so that disagreement is settled by the oracle rows only.

Revision 6ab9deb + cb5e3ef (review 5684987167). The _WITHOUT_WHO16 comment and the F461 / MyHomeServer1 profile docstrings no longer state the MyHomeServer1's WHO 22 plant behaviour as settled: what is measured is the emulated 028206 image's bt_multi translating WHO 22 onto the bus (sound-who22, ack/out), so WHO 22 is left untouched here; live routing on production plants is out of scope (MyHOME#459 reports it discarded, MyHOME's topology strips 22 on it). The clean rebase onto master (CHANGELOG.md) follows once the force push is authorised.

Testing

• tests/test_profiles.py: new test_who16_is_not_advertised_where_the_oracle_refuses_it (F461, MyHomeServer1, MHS1, MyHome Server 1: no WHO 16, WHO 22 kept, supports_audio is True) and test_who16_stays_on_gateways_that_forward_it (F454, MH200N, MH200, H4684, F453, F453AV, H4890, MH202); test_profile_lookup_accepts_common_name_variants updated for the MyHomeServer1 alias.
• Fail before / pass after: on master 5 of the module's 70 tests fail (the four not supports_who(WHO_SOUND) cases and the alias test); on this branch all 70 pass. tests/test_firmware_oracle_conformance.py (26) still passes.
• Full suite: 1919 passed, 1 skipped (master: 1907 passed, 1 skipped); 100 % statement coverage, mypy clean, ruff clean, scripts/sync_documentation.py --check and scripts/verify_library_standards.py pass.
• CI after the MyHOME companion (chore(profiles): derive the discovery rows from the OWNd profile (prep for OWNd #142) MyHOME#808, merged 2026-10-26): the Golden corpus & smoke gates job turns green on rebase (MyHOME now derives the discovery rows from profile.supports_who); the MyHOME test suite job keeps exactly one failure by design until the OWNd pin bump, tests/test_sync_documentation.py::test_check_all_documentation_real_tree ("Gateway Discovery table out of sync in docs/getting-started/hardware-compatibility.md": the committed doc still shows WHO 1, 2, 4, 16, 18 for the F461 and MyHomeServer1, regenerated at the pin bump). Verified locally on 2026-10-26: MyHOME v2-phase1-architecture f4a5a907 against this head: 1 failed (that doc check), 4990 passed, 1 skipped.

Live retest (2026-10-24)

Confirmed for this startup configuration: with this profile, four starts of the integration sent no *#16*0*5## (HA bus-monitor history) and logged Skipping WHO=16 discovery: not supported by F461 profile; the zone and humidity requests were still sent. Other gateway models were not tested live.

Companion

MyHOME companion: OpenWebNet-HA/MyHOME#808 (chore(profiles): derive the discovery rows from the OWNd profile (prep for OpenWebNet-HA/OWNd#142), merged 2026-10-26): scripts/update_gateway_profiles.py and tests/test_gateway_profiles.py derive the F461 / MyHomeServer1 discovery rows from profile.supports_who instead of a static list, so it is green against the pinned OWNd 2.0.0b11 and against this branch; hardware-compatibility.md regenerates to WHO 1, 2, 4, 18 at the pin bump that includes this PR (sequencing: #808 → this PR → OWNd release → pin bump). OpenWebNet-HA/MyHOME#794 gates the startup *#16*0*5## request on profile.supports_who(16) with a MyHOME fallback table until this lands.

🤖 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]

Rebased on master 87cafc3 (after #136): the CHANGELOG [Unreleased] entry and the heating.py regex block now sit beside the merged dimension-22 guard; content unchanged, suite and 100 % coverage green.

[GreenGrassBlueOcean]

Firmware and trace evidence for removing WHO_SOUND (16) from F461Profile and MyHomeServer1Profile while keeping it on MH202Profile is solid: neither F461_020011 nor SMARTGW_028206 packages bt_difson or libcoso/libplug_multi_{stm,syn,tr}.so (whereas MH202_010024 ships libplug_multi_{stm,syn,tr}.so inside coso, explaining why MH202 relays F441M state frames in OpenWebNet-HA/MyHOME#669 despite NACKing commands in the oracle).

Beyond startup sweeps (which OpenWebNet-HA/MyHOME#794 already gated via sweep_omits), this fixes a real shared-bus delegation gap in MyHOME (custom_components/myhome/topology.py): gateway_supported_whos() had a manual whos -= {5, 16, 22} override for MyHomeServer1 but none for F461. Because F461 is Tier 1, on a shared F461 + MH202 (or F454) bus F461 wins Primary and previously kept 16 in pri_whos, preventing MH202 from taking WHO 16 (F441M matrix sound) delegation via sec_whos - pri_whos.

Two points before approving:

1. Do not overstate MyHomeServer1 WHO 22 plant behavior in _WITHOUT_WHO16 / MyHomeServer1Profile comments (OWNd/profiles.py):

   • Lines 189–190 and 632–633 state "Their sound system is WHO 22 (sound-who22), so supports_audio stays True and WHO 22 stays listed" right next to citing MyHOME#459: "firmware discards 5, 16, 22" (and MyHOME's topology.py explicitly strips 22 on MyHomeServer1).
   • Please keep the wording bounded to what is measured vs out of scope for this PR: in own-firmware-oracle 028206 (sound-who22), bt_multi translates WHO 22 commands onto the bus (ack/out), so this PR leaves WHO 22 untouched; whether live MyHomeServer1 3.87.x routes WHO 22 on production plants is separate from WHO 16 and shouldn't be stated as settled in MyHomeServer1Profile's docstring.

2. Rebase onto master (12fef0c8) & update PR notes:

   • Please rebase onto 12fef0c8 (CHANGELOG.md conflict). Since OpenWebNet-HA/MyHOME#808 is now merged on MyHOME, Golden corpus & smoke gates (verify_profiles_against_oracle) should turn green on rebase, leaving only MyHOME's hardware-compatibility.md doc-sync check red by design until the OWNd pin bump. Worth updating the PR Summary / CI note accordingly (including the shared-bus F461 delegation impact, since MyHOME#794 already covered the startup sweep).

[gdluck]

Point 1 is in 6ab9deb + cb5e3ef: the _WITHOUT_WHO16 comment and the F461 / MyHomeServer1 profile docstrings now say only what the oracle measured (the emulated 028206 image's bt_multi translates WHO 22 onto the bus, so WHO 22 is left as it is) and that live WHO 22 routing on a production MyHomeServer1 is out of this PR's scope. No code change; 2052 passed, ruff / mypy / docs check clean.

Point 2: the description's Summary now carries the shared-bus delegation gap you described (F461 Primary keeping 16 in pri_whos blocked the MH202's WHO 16 delegation), the Companion says #808 is merged, and the CI note says the golden-corpus job turns green on rebase with only MyHOME's hardware-compatibility.md doc check red by design until the pin bump (verified locally: 1 failed, 4990 passed against this head). The rebase onto 12fef0c8 needs a force push, which I will do as soon as the branch owner authorises it.

[gdluck]

Rebased onto master 4213cab (three commits a86a683 + 3856275 + 2210296, authorship reset, no merge commit); 2137 passed, ruff / mypy / docs check clean. With #808 merged on MyHOME and #150 here, the only expected red is MyHOME's hardware-compatibility.md doc check until the pin bump.

[gdluck]

@GreenGrassBlueOcean the one red job here (MyHOME conformance / MyHOME test suite, test_check_all_documentation_real_tree) is caused by this PR, not pre-existing drift: MyHOME generates its startup-discovery table from the OWNd profiles, so dropping WHO 16 from the F461 and MyHomeServer1 changes two rows of docs/getting-started/hardware-compatibility.md. Companion PR with the regenerated table (no hand edits): OpenWebNet-HA/MyHOME#830. The job checks out MyHOME's v2-phase1-architecture, so it stays red until that one merges, or until the workflow is dispatched with myhome_ref set to the companion branch. Sorry for calling it expected drift earlier.

[gdluck]

Correction to my previous comment: OpenWebNet-HA/MyHOME#830 is closed. MyHOME already anticipates this PR at the pin bump (pinned_whos in scripts/update_gateway_profiles.py, test_discovery_table_with_ownd_matches_the_committed_docs): the committed discovery table follows the pinned OWNd==2.0.0b11, and the two rows are regenerated with the pin bump once this PR is in a release. So the MyHOME test suite red here is the designed signal of a pending pin-bump doc change, not something to fix on either side now.

[gdluck]

Why the MyHOME conformance / MyHOME test suite job is red here, and why it stays red until the pin bump.

The job installs this checkout in place of MyHOME's pinned OWNd==2.0.0b11 and runs MyHOME's whole suite. One test fails, tests/test_sync_documentation.py::test_check_all_documentation_real_tree (5072 passed): "Gateway Discovery table out of sync in docs/getting-started/hardware-compatibility.md". MyHOME generates that table from OWNd's gateway profiles, so dropping WHO 16 from the F461 and MyHomeServer1 profiles changes two rows (queried WHOs 1, 2, 4, 18; *#16*0*5## no longer listed as dropped).

MyHOME is built to handle exactly this at the pin bump: scripts/update_gateway_profiles.py keeps a pinned_whos row per gateway, and tests/test_gateway_profiles.py::test_discovery_table_with_ownd_matches_the_committed_docs (its docstring names this PR) requires the committed table to match the pinned OWNd, allowing only the rows whose profile differs from pinned_whos to diverge against a newer OWNd. The committed table and pinned_whos are regenerated together when MyHOME's pin moves to a release that carries this PR. Regenerating the table now breaks MyHOME's own CI (six jobs, tried as OpenWebNet-HA/MyHOME#830, closed).

So the red is the designed signal of a pending pin-bump doc change in MyHOME, not a defect in this PR or in MyHOME; the other seven jobs are green.

[GreenGrassBlueOcean]

Thanks @gdluck — the WHO = 22 docstring/comment scope in 2210296 looks good, and OpenWebNet-HA/MyHOME#831 (eca7e510) is now merged into v2-phase1-architecture:

• scripts/sync_documentation.py::get_gateway_discovery_block() now follows pinned_whos while manifest.json still pins OWNd==2.0.0b11 (so both OWNd's myhome-conformance workflow and MyHOME's OWNd@master vs no-OWNd CI jobs agree on the committed hardware-compatibility.md table during the pre-release window, then automatically enforce regenerating hardware-compatibility.md + pinned_whos / sweep_omits as soon as manifest.json bumps to OWNd==2.0.0b12).
• Re-running MyHOME conformance against eca7e510 (job 123671128145) is green — all 8/8 checks on 2210296 now pass.

Could you rebase fix/profiles-f461-mhs1-no-who16 onto current master (f3efc1d, 1-line CHANGELOG.md conflict) and mark #142 ready for review? (protected-branches enforces require_last_push_approval, so keeping the rebase push on your side lets me approve and merge as soon as CI finishes.)

[GreenGrassBlueOcean]

@gdluck can you please rebase

[gdluck]

Rebased onto master f3efc1d: the one-line CHANGELOG conflict resolved by keeping both ### Fixed bullets, no other change (2210296 -> e00b725, three commits, authored by gdluck). 2352 passed locally; marked ready for review.

[GreenGrassBlueOcean]

Rebase onto master (f3efc1d) verified (2210296 → e00b725):

• CHANGELOG.md: Clean 1-line conflict resolution under [Unreleased] / ### Fixed, retaining the #138 WHO 4 Dimension 14 #-prefixed setpoint entry alongside the F461Profile / MyHomeServer1Profile WHO 16 removal entry.
• Code & tests (OWNd/profiles.py, tests/test_profiles.py): Identical to 2210296 — _WITHOUT_WHO16 = (WHO_SOUND,) drops WHO 16 from F461Profile and MyHomeServer1Profile while keeping WHO 22 / supports_audio untouched (with WHO 22 docstrings/comments bounded to oracle bt_multi measurements per review #5684987167), retains WHO 16 on MH202Profile (MyHOME#669 F441M relay), and pins both sets in tests/test_profiles.py.
• CI: All 8/8 gates (Python 3.11–3.14 tests & coverage, static analysis, package build, golden corpus & smoke gates, and downstream MyHOME test suite) are green on e00b725.

Approving and merging now.