Vaillant VR_71: Mc{1,2,3}Operation status receives value 4 (not in onoff enum) -> HA 'invalid option'

[buliwyf42]

Summary

On a real VR_71 install the room controller writes status = 4 to Mc{1,2,3}Operation, but the field is typed onoff (0=off;1=on). ebusd therefore passes the raw 4 through and Home Assistant's enum sensor rejects every such update:

[homeassistant.components.mqtt.sensor] Ignoring invalid option received on topic
'ebusd/vr_71/Mc1Operation', got '4', allowed: off, on
[homeassistant.components.mqtt.sensor] Ignoring invalid option received on topic
'ebusd/vr_71/Mc2Operation', got '4', allowed: off, on

Definition

src/vaillant/26.vr_71.tsp:

model Mc1Operation {   // b523 0200 (Mc2 = 0201, Mc3 = 0202)
  status: onoff;       // -> compiled CSV: status,,UCH,0=off;1=on
  ...
}

Observed on the bus

• Device: MF=Vaillant;ID=VR_71;SW=0203;HW=5904 (slave 0x26)
• Source: the room controller (master 0x10) writes these telegrams.
• Over ~10 days of raw capture the master-side status byte was:
  • Mc1Operation: 0x00 ~91680×, 0x04 23×
  • Mc2Operation: 0x00 ~91743×, 0x04 19×
  • 0x04 occurs in short bursts roughly once per day around 10:00; 0x01 (on) was never observed — only 0 and 4.
• pump/mixer are slave-response fields and stay within range; only the master status field carries 4.

Question

What does status = 4 mean for a VR_71 mixer circuit? Given that 0x01 never appears and 0x04 does, 0=off;1=on looks incomplete/incorrect for this field. For reference, the Vaillant HMU pump/status field uses 0=off;1=on;2=overrun;4=hwc, so 4 here might indicate a hot-water/special mode — but that is unconfirmed for a mixer circuit.

Because status uses the shared onoff type, a proper fix probably means giving the Mc status its own enum (e.g. 0=off;1=on;…;4=<meaning>) rather than extending the global onoff.

Workaround

Locally I extended the field to 0=off;1=on;4=unknown so HA stops rejecting the value. Happy to relabel 4 once its meaning is known, and to capture more samples or correlate the timing of status=4 with circuit/DHW activity if that helps.

[Hoppur]

I've seen this for inactive circuits for 5 minutes each day and am suspecting a maintenance mode to keep the valve operable.
My assumption:

status	m	UCH	0=off;1=on;4=keepValveOperable

By the way, is your value for "pump" in that same message delivering any information? Mine is a constant 1 for every 3 circuits. "mixer" seems fine, it varies and fits to the info in the ctlv3.

[chrizzzp]

@Hoppur

Same here with "pump" status never changing, even when the mixer circuit is switched off (standby), e.g. due to outside temperature being high enough.

[buliwyf42]

Thanks @Hoppur — that matches what I see here.

• Same daily pattern: status=4 shows up in a short burst once per day (~10:00 local) on circuits that are otherwise off, and the value is only ever 0 or 4 — 1 (on) never occurs. A daily "keep valve operable" maintenance run fits this very well.
• pump: same as you and @chrizzzp — constant 1/on here (Mc1 and Mc2) regardless of circuit state, so it carries no useful information. (Mc3 never appears on my system — that circuit is unused.) mixer does vary (currently -100) and looks meaningful.

So 0=off;1=on;4=keepValveOperable looks right. Since status currently uses the shared onoff type, I'll open a PR adding a dedicated enum for the Mc status so this doesn't change every other on/off field.

[tinelstudio]

My VR 71 reports status = 2, when my circuit is running for cooling. Before, the value was 1, when it was running in heating mode. Otherwise (when pump is off) it reports 0.

So here:
0 = off
1 = heating, supply target 42.5–44.0 °C
2 = cooling, supply target 10.0 °C
I have never seen 4. But I'm using my own software so I fixed it with "circuit is active whenever status > 0". I'm pretty sure I can capture it, though. Worth mentioning here, because I relied on this code as documentation.

System: Vaillant VR 71 with a VRC 700, heat pump VWF, 3.5 years old. This circuit is for heating and cooling via Vaillant convector aroVAIR.

[buliwyf42]

Thanks @tinelstudio — that's a value the PR did not cover, so it is in now.

#621 now adds cooling: 2 as well, so the generated definition reads
0=off;1=on;2=cooling;4=keepValveOperable for Mc{1,2,3}Operation.status.

I deliberately kept 1 labelled on instead of renaming it to heating: before this
branch the field used the shared onoff type, so a rename would change the reported
state on every existing installation (and break anything keyed on it). The
heating-vs-cooling meaning is in the doc comment instead.

One caveat on my side: I cannot reproduce 2 here. Cooling is disabled on my Hc2 —
I am still waiting for the Vaillant coding plugs — so my circuits only ever show 0,
1 and the daily 4 burst. Value 2 therefore rests entirely on your report; if you
do manage to capture the raw message, that would confirm it nicely.

[tinelstudio]

Just a thought: 3 might be the freeze protection mode.

Capture from a few minutes ago, when cooling kicked off:

10 26 b5 23 04 02 01 00 00 9e 00 02 01 9c 2b
10 26 b5 23 04 02 01 02 14 27 00 02 01 9c 2b
...
10 26 b5 23 04 02 01 02 14 27 00 02 01 64 d3
...
10 26 b5 23 04 02 01 02 14 27 00 02 01 5a ed
...
10 26 b5 23 04 02 01 02 14 27 00 02 01 3c 8b
...
10 26 b5 23 04 02 01 02 14 27 00 02 01 23 94
...
10 26 b5 23 04 02 01 02 14 27 00 02 01 19 ae

8th byte: 2
9th byte: 10 °C (set min temp for the convector cooling)

BTW, I have another installation (VR 71, VRC 720, VWL aroTHERM split) reporting the same thing. Some examples from 2026-06-09, when I was capturing data:

10 26 B5 23 04 02 00 02 28 0D 00 02 01 F6 41
...
10 26 B5 23 04 02 00 02 28 0D 00 02 01 FB 4C
...
10 26 B5 23 04 02 00 02 28 0D 00 02 01 00 B7
...
10 26 B5 23 04 02 00 02 28 0D 00 02 01 EC 5B

8th byte: 2
9th byte: 20 °C (set min temp for floor cooling)

[buliwyf42]

@tinelstudio thanks for the raw captures — that settles 2 completely. I decoded them against the message definition and every byte lines up:

Your first system (b523 0201 = Mc2Operation):

10 26 b5 23 04 02 01 00 00  9e 00 02 01 9c 2b   <- before
10 26 b5 23 04 02 01 02 14  27 00 02 01 9c 2b   <- cooling
              ^^ ^^ NN=04   master payload = ID(02 01) + status + flowtempdesired

• 02 01 = the message ID, so this is Mc2.
• status (UCH) = 0x02 → 2
• flowtempdesired (D1C) = 0x14 = 20 → D1C is /2 → 10.0 °C — exactly the convector cooling setpoint you quote.

Your second system (b523 0200 = Mc1Operation):

• status = 0x02 → 2
• flowtempdesired = 0x28 = 40 → /2 → 20.0 °C — again exactly your floor-cooling setpoint.

The slave part corroborates it too: pump = 0x01 (on) throughout, and mixer (SCH) walks 0x9c = -100 → 0x64 = +100 → 0x5a/0x3c/0x23/0x19 = +90/+60/+35/+25 as the run settles. That is a mixer being driven open and then modulated, i.e. a real active circuit — not a stray value on an idle one. Two independent installations (VRC 700 and VRC 720), same value, same meaning.

So 2 = cooling is confirmed by measurement rather than by inference, and #621 already carries it:

status,,UCH,0=off;1=on;2=cooling;4=keepValveOperable

On 3 = freeze protection: plausible, but I would rather not put a guessed label into a shared definition — an unknown value passes through as a raw number and is easy to spot, whereas a wrong name is not. If you (or anyone else) ever catch a b523 020x frame with status = 3, please post it here the same way you did above and I will add it.

Status on my side: the Vaillant coding plugs I was waiting for are now fitted, but cooling is still not released on the bus here — hmu SetMode.releasecooling reads 0 in every frame, Status07 heatermain_b4_cooling never sets, and my Mc{1,2}Operation.status still only shows 0, 1 and the daily 4 burst. So the release evidently has to be switched on in the controller as well; until I get that far, 2 rests on your capture, which is now solid enough on its own.

[buliwyf42]

@tinelstudio — follow-up to my earlier comment here, where I wrote that cooling was disabled on my system and that value 2 therefore rested entirely on your report. That is no longer true: I can now confirm 2 from my own bus, on a third independent installation.

Getting there took the whole chain — Vaillant coding resistors (0020269259) fitted in the outdoor units, "Aktive Kühlung" set at the inner unit's display, and a restart of the network gateway before the controller would offer cooling at all. Once it did, the first cooling run started this evening and produced exactly what you described.

Raw telegrams here (VR 71 + sensoCOMFORT 720, aroTHERM plus VWL 75/6 A monobloc, mixed circuit on underfloor heating):

10 26 b5 23 04 02 00 02 28 0d 00 02 01 3c 8b 00     Mc1
10 26 b5 23 04 02 01 02 28 1b 00 02 01 3c 8b 00     Mc2
                  ^^ ^^ ^^ ^^
                  id  |  status=02
                      |  flowtempdesired 0x28 = 40 -> D1C /2 = 20.0 °C

Side by side with the second capture you posted:

yours:  10 26 B5 23 04 02 00 02 28 0D 00 02 01 F6 41
mine:   10 26 b5 23 04 02 00 02 28 0d 00 02 01 3c 8b

Same message ID, same status = 2, same 0x28 = 20.0 °C setpoint — only the mixer position differs (0xF6 = -10 on yours, 0x3c = +60 on mine at that moment). Over the run my mixer walks -100 -> +55 -> +60 -> +50 with pump = on throughout, which is the modulation pattern you would expect from a circuit that is actually working, not a stray value on an idle one.

Decoded by ebusd with the #621 definition:

vr_71 Mc1Operation = cooling;20.0;on;60
vr_71 Mc2Operation = cooling;20.0;on;60

Context from the rest of the bus at the same second, which independently corroborates that this is real cooling rather than a mislabelled state:

19:28:35.718  hmu SetMode      auto;20.0;-;-;1;1;1;0;0;1     <- releasecooling 0 -> 1
19:28:36.577  hmu Status07     ... heatermain_b4_cooling = on
19:28:40.756  vr_71 Mc1Operation  cooling;20.0;on;-100
              ctlv2 Hc1Status = 1, Hc2Status = 1, flow setpoint 20 °C

So three subsystems agree within five seconds: the heat pump gets the cooling release, its display status word sets the cooling bit, and both mixer circuits go to status = 2.

That makes 0=off;1=on;2=cooling;4=keepValveOperable in #621 confirmed by measurement on three installations (yours ×2, mine), rather than two reports plus an inference. Thanks for pushing on it — I would have shipped the enum without 2 otherwise.

Still no sighting of 3 here, so your freeze-protection guess remains untested; I have left it out of the PR for the reason given earlier.

[buliwyf42]

Edited: this comment originally repeated the confirmation from my comment above and carried three wrong numbers. Replaced with the correction and the part that was actually additive.

Correction

• The window I counted was ~20 h (raw log starts 2026-08-29 13:12 local), not 48 h.
• First cooling telegram on Mc1Operation is 2026-08-29 19:28:40.760, not 19:34:31.
• I wrote that Mc2Operation "never" reported 2. That is wrong, and it contradicts the Mc2 telegram quoted in my previous comment: Mc2 reported status = 2 five times, 19:28:41.068 to 19:29:20.598. "Cooling allowed" was still enabled on that circuit (radiators) and the controller dropped it after ~40 s; it has since been disabled.

Counts, 2026-08-29 13:12:51 .. 2026-08-30 10:26:33

Mc1Operation (b523 0200):  off 3104   cooling 4542   (no 1, no 4 in this window)
Mc2Operation (b523 0201):  off 7644   cooling    5   (no 1, no 4 in this window)

Raw master telegrams, target as UCH with divisor 2:

1026b523040200 0000 88 ...   status=0x00 off,     target  0.0 °C
1026b523040200 0222 07 ...   status=0x02 cooling, target 17.0 °C
1026b523040200 0228 0d ...   status=0x02 cooling, target 20.0 °C

Why this installation is a useful second data point

@tinelstudio cools through aroVAIR convectors at a 10.0 °C supply target. This system cools through underfloor heating, where the target has to stay above the dew point, and it modulates between 17.0 and 20.0 °C. Two emitter types, very different setpoints, same status = 2 — so 2 = cooling is a property of the mixer-circuit status field rather than an artefact of one installation.

System here: VR 71 (MF=Vaillant;ID=VR_71;SW=0203;HW=5904, config FM5) with a sensoCOMFORT 720 (VRC 720) — note this differs from @tinelstudio's VRC 700 — driving a cascade of 2 x aroTHERM plus VWL 75/6 A (R290). Hc1 = underfloor, Hc2 = radiators.

No sighting of 3 here (only 0 and 2 in this window; the daily 4 burst as described earlier in the thread), so the freeze-protection guess stays untested.

#621 has been sitting mergeable without review since 2026-06-22 — anything I can do to help move it along?