fix(profiles): automate README profiles table and derive features from profile fields

[GreenGrassBlueOcean]

Description

This PR automates the Hardware Gateway Profiles table in README.md, derives profile feature summaries directly from declared capabilities, resolves profile registry duplication, and enables hardware-verified WHO 16 (sound system) support on the MH200N gateway.

---

Summary of Changes

1. Hardware-verified WHO 16 audio support on MH200N:

   • Set supports_audio = True and added WHO_SOUND to MH200NProfile.supported_who.
   • Hardware verification: Verified on a live installation (MH200N gateway + F500N tuner + 4 stereo room amplifiers) answering *#16*0*5## cleanly with 0 NACKs in ~1.2 s, returning full device and state inventory (standby, playback, volume, and WHO 22 mirroring; see MyHOME#427 comment 5848181845).
   • Updated MH200NProfile docstrings and test assertions accordingly.

2. Automated README Profiles Table:

   • Added scripts/update_readme_profiles.py to generate and synchronize the Hardware Gateway Profiles table in README.md from declared profile properties.
   • Enclosed table in README.md between <!-- START_GATEWAY_PROFILES_TABLE --> and <!-- END_GATEWAY_PROFILES_TABLE -->.
   • Added --check mode for CI and pre-commit checks.
   • Added automated verification in scripts/verify_library_standards.py and tests/test_profiles.py (test_readme_gateway_profiles_table_is_in_sync) to prevent documentation drift.

3. Derive Features from profile capability fields:

   • Added self-documenting summary properties to GatewayProfile: concurrency_summary, queue_delay_summary, keepalive_summary, and features_summary.
   • Replaced queue delay heuristics (command_queue_delay >= 0.15) with direct capability derivations (supports_hmac, requires_password, supports_native_transitions, supports_extended_frames, supports_who(WHO_SOUND) or supports_audio, extra_features).
   • Added extra_features: tuple[str, ...] = () to GatewayProfile (used by MH201Profile for Clock diagnostics).
   • Removed hardcoded features_summary overrides on MH201Profile and GenericGatewayProfile; GenericGatewayProfile now cleanly defaults to "Conservative fallback".
   • Preserved WHO_SOUND on GenericGatewayProfile for downstream MyHOME startup discovery sweeps.

4. Single source of truth for profile registry:

   • Replaced duplicate profile constructors with CANONICAL_PROFILE_ORDER and canonical_profiles() reading directly from _PROFILES[key].
   • Added test_canonical_order_covers_registry ensuring CANONICAL_PROFILE_ORDER covers all declared profiles in _PROFILES.

5. F455 keepalive & keepalive summary:

   • Added event_keepalive_interval = 90 to F455Profile matching the F454 / F461 family.
   • Renamed opaque "Profile" keepalive summary label to "OS TCP only".

---

Verification

• Unit tests: All 846 tests pass (pytest tests).
• Standards & linting: scripts/verify_library_standards.py and scripts/update_readme_profiles.py --check pass with 0 errors.

[codecov-commenter]

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

Codecov Report

❌ Patch coverage is 97.36842% with 1 line in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
OWNd/profiles.py	97.36%	0 Missing and 1 partial ⚠️

📢 Thoughts on this report? Let us know!

[fedem95]

The README automation is a good idea and verifies (839 passed locally, --check in sync, CI 8/8), but I'd hold the MH200N part.

In #54 the MH200N was left without WHO 16 on a specific condition: "one *#16*0*5## from the #422 plant would settle it." The docstring now says WHO 16 is verified on live installations, but I can't find an MH200N answer to *#16*0*5## anywhere — not in #53, #422, #425 or #453. What #422 shows (that the plant has audio) was already known when we decided to wait. There's also a twist: @wave68runner's audio sits on a separate bus behind an interface (*16*3*11#4#1##), so even the correct *#16*0*5## without the interface suffix might be NACKed on that very plant. On MH200N plants without audio, being wrong costs one ~2 s NACK per startup (#425). The mh_status helper in the audio-test build sends exactly that frame, so one run on his plant, with and without #4#1, would settle it.

On the generator: the Features column isn't derived from the profiles, it's reverse-engineered from the old text. "Legacy password auth" and "Sound system (WHO 16)" are keyed on command_queue_delay >= 0.15, so a profile that only has a 150 ms delay gets both, while MH201, MyHomeServer1 and F454, which also support WHO 16, don't show it. MH201 and Generic are hard-coded strings. The table can no longer drift, but it can now be wrong in a new way. Deriving each item from a real field (supports_hmac, supports_who(16), …) would fix that.

Two smaller things:

• CANONICAL_PROFILES is a second list next to _PROFILES. They match today, but a profile added only to _PROFILES would silently drop out of the table; a test asserting both sets are equal would close that.
• the generated table shows F455 with no keepalive, while F454 and F461 have 90 s and the old README said 90 s for F455 too. Intended?

[GreenGrassBlueOcean]

Thanks @fedem95, completely agreed on all points.

I have updated the PR accordingly:

1. Held MH200N WHO 16 change:

   • Reverted MH200NProfile to supports_audio=False and removed WHO_SOUND.
   • Restored original unverified docstring and test_mh200n_audio_stays_off_until_checked.
   • We will wait for the live capture of *#16*0*5## (with/without #4#1) before touching WHO 16 on MH200N.

2. Features derived from real profile fields:

   • Dropped delay heuristics (command_queue_delay >= 0.15).
   • features_summary now evaluates supports_hmac, requires_password, supports_native_transitions, supports_extended_frames, supports_who(WHO_SOUND) or supports_audio, and extra_features.
   • Added extra_features: tuple[str, ...] = () to GatewayProfile; configured MH201Profile(..., extra_features=("Clock diagnostics",)).
   • Dropped features_summary property overrides on MH201Profile and GenericGatewayProfile; GenericGatewayProfile now naturally falls through to "Conservative fallback".
   • MyHomeServer1, F454, F455, F461, MH202, MH201 now correctly reflect WHO 16 audio support in the table.

3. Single source of truth for profiles:

   • Replaced duplicate constructors in CANONICAL_PROFILES with CANONICAL_PROFILE_ORDER and canonical_profiles() reading _PROFILES[key].
   • Added test_canonical_order_covers_registry asserting set(CANONICAL_PROFILE_ORDER) == set(_PROFILES).

4. F455 keepalive & naming:

   • Added event_keepalive_interval = 90 to F455Profile matching the F454/F461 family.
   • Renamed "Profile" to "OS TCP only" in keepalive_summary.

5. Validation:

   • All 846 unit tests passing.
   • Standards validator and update_readme_profiles.py --check in sync.
   • LF line endings enforced across generated markdown.

[GreenGrassBlueOcean]

@fedem95 Just to add some context on the reasoning: while we don't have status RX traces for the MH200N yet, we do have verified traces for the original MH200 where *#16*0*5## answered cleanly for every amplifier and source in ~0.55 s (#53), and there isn't any architectural indication that BTicino altered that WHO 16 query behavior on the MH200N successor.

That being said, holding it here is still completely the right call: between the potential ~2 s NACK penalty at startup on installations without sound diffusion (#425) and the interface routing topology (*16*...#4#1##) on @wave68runner's plant, waiting for concrete mh_status captures before enabling it in the declarative profile keeps everything safe and verified.

[GreenGrassBlueOcean]

@fedem95 We now have the definitive physical MH200N capture settling WHO 16.

Contributor @manfredgittmaier-afk on MyHOME#427 (comment 5848181845) just executed *#16*0*5## against a live installation (MH200N gateway + F500N tuner + 4 stereo room amplifiers):

1. Clean response without NACK: Responds in ~1.2 s with 0 NACKs.
2. Complete device & state inventory:
   • Standby run: Returns *16*3*101## (tuner source ON) and *16*13*41##, *16*13*21##, *16*13*11##, *16*13*31## (amplifiers 41, 21, 11, 31 OFF).
   • Playback run: Returns *16*3*101## (tuner source ON), *16*3*41## (amplifier 41 ON), followed by OFF frames for the remaining zones and subsequent volume report *#16*41*1*10##.
3. WHO=22 Mirroring: Confirms each WHO 16 response is mirrored on WHO 22 (*#22*2#1*12*...## for sources, *#22*3#<A>#1*12*...## for amplifiers).

With this concrete evidence in hand:

• MH200NProfile has been updated with supports_audio = True and WHO_SOUND in supported_who.
• README gateway profiles table regenerated via scripts/update_readme_profiles.py (table --check in sync).
• All 846 unit tests passing.

[GreenGrassBlueOcean]

@fedem95 can you please do a review?

[xtimmy86x]

I reviewed the latest revision. The MH200N capture in MyHOME#427 answers the earlier WHO 16 concern, and the generated table now reflects the declared profile fields. Thanks for addressing that feedback.

One point before approval: adding event_keepalive_interval=90 to F455 changes runtime behavior. It causes OWNd to send *#*1## on the event session every 90 seconds. Has this been verified on an F455? If not, I’d leave that setting unchanged here and handle it separately after a hardware test.

Minor documentation suggestion: “Event keepalive” would make the README column clearer, since “OS TCP only” refers specifically to the event session behavior.

[fedem95]

The MH200N capture in MyHOME#427 settles my earlier point: I checked the raw trace, *#16*0*5## answered in 0.13-1.2 s with no NACK and a full source/amplifier list. The generator now reads real fields, CANONICAL_PROFILE_ORDER is tied to the registry by a test, and 844 pass locally with the table in sync. Thanks.

On F455 I agree with @xtimmy86x, and that one's on me: my "Intended?" was a question about the old README, not a request to change runtime behaviour. There isn't a single F455 capture in the repo (it's one of the zero-trace gateways in MyHOME#466), so a 90 s *#*1## keepalive on its event session is untested. I'd revert event_keepalive_interval on F455 here and let the table say what the profile actually does; a hardware test can change it later.

+1 to "Event keepalive" as the column name.

Happy to approve once the F455 keepalive is back out.

[GreenGrassBlueOcean]

@fedem95 done in 924177f: F455's event_keepalive_interval is back out (it now shows "OS TCP only" until a hardware capture says otherwise), and the README column is renamed to "Event keepalive". The table is regenerated and in sync, and the suite passes locally (845 passed, 1 skipped). Ready for another look.

[GreenGrassBlueOcean]

@fedem95 can you please take a look i really want to release b14

[fedem95]

Sorry @GreenGrassBlueOcean I missed the notification, the F455 keepalive is back out (one line, nothing else in the profile touched), F454/F461/MH200N keep their 90 s, the column reads "Event keepalive" and the table is in sync. 844 passed locally, CI 8/8, merges cleanly with master. All my points on this PR are closed — thanks for the patience.
For me is ok

[GreenGrassBlueOcean]

@fedem95 Thank you for taking the time to review this—it really improved the quality of the PR. I know availability can be tight while we're pushing hard in this dev sprint, so your input is highly appreciated!