Add support for Vaillant V32;121;9802 (address 18) — no matching definition file

[jsimon-a11y]

Device info

Scan result from micro-ebusd (firmware 20260317, ESP32-C6):

18: *fail, Vaillant;V32;121;9802, MF fail

• eBUS address: 18 (hex: 12)
• • Manufacturer: Vaillant
• • • Device type: V32 (VR32 zone module, circuit 2 — CV boiler)
• • • • SW version: 121
• • • • • HW version: 9802

System context

• Vaillant heat pump (HMU00;902;5103, loaded 508.hmu.HW5103) at address 08
• • Vaillant CTLV2 controller (514;1104, loaded 515.ctlv2) at address 15
• • • Vaillant VR_70 mixer (109;2903, loaded 552.vr_70) at address 52
• • • • Vaillant VWZIO zone I/O (202;103, loaded 576.vwz) at address 76
• • • • • V32 at address 18 — no definition found

micro-ebusd behaviour

reload -d 12 returns reload messages but the device stays as *fail — confirmed no CDN entry exists for this firmware ID.

Direct read attempts via hex 1208070400 result in ERR: read timeout — the V32 does not respond to direct read commands.

Passive messages observed

The following unknown messages were passively received from the V32 (seen in REPL):

ebusd: received unknown 1008b5110100 / 09ef0109000108000000
ebusd: received unknown 7108b51a0304f632 / 0ef607c0cfc07b3c00b01b20000000

Request

Please add a definition file for V32;121;9802 (address 12 hex / 18 decimal). The existing 08.v3x.csv may be a starting point — this device likely needs a 12.v3x.csv or similar entry on the CDN keyed to address 12.

Happy to provide additional raw bus captures if needed.

[jsimon-a11y]

Follow-up: raw bus capture analysis

After enabling raw logging on the adapter, here is a 2-minute capture of passive bus traffic providing much more context about what the V32 is doing on the bus.

Dominant message: 7108b5110107 — V32 to heatpump (every ~3 seconds)

QQ=71 (V32), ZZ=08 (heatpump HMU), PB=b5, SB=11, cmd=0107

23:45:06  7108b5110107 / 0a205d02c1081e0000000
23:45:18  7108b5110107 / 0a1e5d02c1081e0000000   byte[1]: 0x20->0x1e = 32->30
23:45:24  7108b5110107 / 0a1f5d02c1081e0000000
23:45:37  7108b5110107 / 0a1e5d02c1081e0000000
23:45:51  7108b5110107 / 0a1e5e02c1081e0000000
23:45:55  7108b5110107 / 0a1d5e02c1081e0000000   byte[1]: 0x1e->0x1d = 30->29
23:46:08  7108b5110107 / 0a1c5e02c1081e0000000   byte[1]: 0x1d->0x1c = 29->28

byte[1] decreases steadily (32->31->30->29->28 decimal). This is almost certainly a flow temperature setpoint or demand level in degC. byte[2] (5d->5e) increases slowly, likely return temp. This message appears to be the cascade/zone coupling signal — the V32 forwarding CV heat demand to the heatpump every 3 seconds.

Multi-packet status burst: 7108b51a0304 (23:45:18-20)

Sequential register reads b5->b9, V32 reporting CV boiler status to heatpump:

7108b51a0304b532 / 0eb507c0cfc07b3c00b01b2000000
7108b51a0304b633 / 0eb60000c08b02000000000000000
7108b51a0304b734 / 0eb7cf2000c002210100180006d80
7108b51a0304b835 / 0eb800000000000100900100001000
7108b51a0304b936 / 0eb90000000000000000000000000

Decoded context during capture

• hmu/SetMode: flowtempdesired:37, hcmode:auto
• • hmu/Status01: temp:38.5, temp_1:34, pumpstate:on
• • • vr_70/Mc2Operation: status:off, flowtempdesired:0, pump:on, mixer:-100
• • • • broadcast/Outsidetemp: 5.4 degC
        Note: the VR70 mixer is fully closed (mixer:-100, flowtempdesired:0) while the V32 is still sending demand to the heatpump directly via 7108b5110107. This confirms the V32 is operating as an independent master on the cascade, not through the VR70 zone circuit.