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.
Summary
On a real VR_71 install the room controller writes
status = 4toMc{1,2,3}Operation, but the field is typedonoff(0=off;1=on). ebusd therefore passes the raw4through and Home Assistant's enum sensor rejects every such update:Definition
src/vaillant/26.vr_71.tsp:Observed on the bus
MF=Vaillant;ID=VR_71;SW=0203;HW=5904(slave0x26)0x10) writes these telegrams.statusbyte was:Mc1Operation:0x00~91680×,0x0423×Mc2Operation:0x00~91743×,0x0419×0x04occurs in short bursts roughly once per day around 10:00;0x01(on) was never observed — only0and4.pump/mixerare slave-response fields and stay within range; only the masterstatusfield carries4.Question
What does
status = 4mean for a VR_71 mixer circuit? Given that0x01never appears and0x04does,0=off;1=onlooks incomplete/incorrect for this field. For reference, the Vaillant HMU pump/status field uses0=off;1=on;2=overrun;4=hwc, so4here might indicate a hot-water/special mode — but that is unconfirmed for a mixer circuit.Because
statususes the sharedonofftype, a proper fix probably means giving the Mc status its own enum (e.g.0=off;1=on;…;4=<meaning>) rather than extending the globalonoff.Workaround
Locally I extended the field to
0=off;1=on;4=unknownso HA stops rejecting the value. Happy to relabel4once its meaning is known, and to capture more samples or correlate the timing ofstatus=4with circuit/DHW activity if that helps.