[Vaillant HMU HW2204] ~30% of MS commands unmodeled in 08.hmu.csv (generic model mismatch)

[Narcotic82]

Device identification

From ebusctl info:

• ebusd version: 26.1.26.1
• Address 0x08: MF=Vaillant;ID=HMU00;SW=0129;HW=2204 — loaded vaillant/08.hmu.csv
• Address 0x15 (CTLS3, for reference): MF=Vaillant;ID=CTLS3;SW=0809;HW=8104 — loaded vaillant/15.ctls3.csv
• Serial (HMU): 0010038166
• reconnects: 0, signal acquired, 533 messages loaded (252 poll, 19 update) — bus/config are healthy, this isn't a connectivity issue

Setup

• ebusd running in Docker (john30-ebusd-1)
• --configpath=/etc/ebusd/config/en --scanconfig=none
• Using the current vaillant/08.hmu.csv (English, pulled from the CDN mirror at ebus.github.io) — ebusctl info reports a newer version is available upstream, but I diffed it against the CDN's latest and it's content-identical (locale-only differences), so this isn't a stale-config issue either
• 33h continuous log analyzed, no bus dropouts, error rate normal (~0.13%)

The issue

Roughly 30% of all MS (master-slave) traffic to this HMU is logged as "unknown MS cmd" — not bus noise/collisions (those are separately and correctly logged as [bus error]), but valid, correctly-received messages under known PBSB command codes for which the specific id byte(s) sent by this HMU aren't defined in the CSV.

I checked the TypeSpec sources (src/vaillant/08.hmu.tsp) and confirmed the generic Hmu model has no Id.Id.hw conditions — it's applied to all HW variants except HW5103, which has its own dedicated correction file (08.hmu.HW5103.tsp). There's no HW2204-specific variant, so these commands go undecoded.

Breakdown of unknown commands (33h log, ~42.5k unknown lines total)

PBSB	Count	Example request	Example response	Notes
b511	13,808	1076b5110101	092224c41aff530000ff	Same PBSB as defined Status01 (id=01), but this variant appends an extra 01 byte — a parameterized/zone-indexed call not covered by the base Status01 definition
b512	12,245	1076b512030f0001	079a0200140111ff	Same PBSB as defined StatusCirPump (id=00), different id/param structure
b510	11,832	1076b51009000000ffffff050000	0101	Same PBSB as defined SetMode (id=00), this uses id=09... — looks like a different sub-command under the same command family
b507	2,007	1008b507020946	02df03
b505 (broadcast)	1,975	10feb505025c00	—
b513	395	1008b513020528	0101
b508 (broadcast)	198	10feb508020900	—
b516	94	1076b516081000ffff03052134	0b1000ff0305013500000000
b509	4	1076b509040e0f0000	00

The bulk (b510/b511/b512) look like alternate/extended sub-commands of already-defined message families (SetMode, Status01, StatusCirPump) rather than entirely new command codes — possibly zone-parameterized or firmware-revision-specific variants.

Question

Has anyone else with a HW2204 HMU run into this? Is there any existing (even partial/unofficial) decoding of these id variants I could compare against, or is this simply undocumented territory that nobody has mapped for this hardware revision yet?

Happy to run further diagnostics (ebusctl read -f, correlating specific bytes with known device state changes, etc.) if that helps move this forward. Would also be willing to help draft a 08.hmu.HW2204.tsp correction file once/if these are understood, similar to the existing HW5103 one.

Thanks!