Z1DayTemp (and Z2/Z3) decode error on Vaillant BASS0 SW=0217/HW=8803 — correct ID appears to be 2200, not 0700

[tuca27]

System info

ebusd version: 26.1.26.1
Adapter: eBUS Adapter Shield C6 (network, TCP enhanced)

Scanned devices:

• address 08: MF=Vaillant;ID=HMU00;SW=0517;HW=5103, loaded vaillant/08.hmu.HW5103.csv
• address 15: MF=Vaillant;ID=BASS0;SW=0217;HW=8803, loaded vaillant/15.bass.csv
• address 26: MF=Vaillant;ID=VR_71;SW=0203;HW=5904, loaded vaillant/26.vr_71.csv
• address 76: MF=Vaillant;ID=VWZ00;SW=0517;HW=5103, loaded vaillant/76.vwz.csv

Heat pump: Saunier Duval Genia Air Split HA 12-5 OS (same platform family as Vaillant aroTHERM).

Problem

Reading Z1DayTemp (and Z2DayTemp, Z3DayTemp) via the currently loaded vaillant/15.bass.csv definition consistently fails:

ebusctl read -f -c bass Z1DayTemp
ERR: invalid position in decode

The current definition uses ID 0700:

r5,bass,Z1DayTemp,Solltemperatur Zone 1,,15,b524,020003000700,ign,s,IGN:4,,,,value,s,EXP,,°C,day setpoint for zone 1

Finding

Defining a temporary read-only message with ID 2200 instead of 0700 (same PBSB b524, same structure otherwise) decodes correctly and returns a plausible value:

ebusctl define -r "r,bass,Z1DayTempTest,test,,15,b524,020003002200,ign,,IGN:4,,,,value,,EXP,,°C,day setpoint zone1 test"
ebusctl read -f -V Z1DayTempTest
bass Z1DayTempTest value=23 °C [day setpoint zone1 test]

This matches a pattern mentioned in other community threads (e.g. #234, #209 on this same BASV0/BASS0 SW=0217/HW=8803 combination), where the same "invalid position" symptom is reported for z1DayTemp, and a configuration example for a newer-generation Vaillant controller uses ID 2200 for the equivalent working z1DayTemp message (as opposed to 0200 for z1CoolingTemp), suggesting this may be a generation-specific ID shift not yet reflected in the BASS0 SW0217/HW8803 CSV.

Write side — unresolved

I was NOT able to get a working write for this field with the corrected ID:

ebusctl define -r "w,bass,Z1DayTempFix,...,020003002200,ign,,IGN:4,,,,value,,EXP,,°C,..."
ebusctl write -c bass Z1DayTempFix 24
empty

No corresponding traffic appears on the bus log for the write attempt — it seems the write never gets transmitted, rather than being NAK'd by the controller. I don't have enough knowledge of the protocol internals to determine the correct write frame structure.

Request

Could someone confirm whether 2200 is the correct ID for Z1/2/3DayTemp on BASS0 SW=0217/HW=8803, and if so, update vaillant/15.bass.csv (or the current TypeSpec source)? Also, any guidance on the correct write-message structure for this field on this specific firmware would be greatly appreciated — happy to test further with ebusctl define if someone can point me toward the correct format.

Happy to provide ebusctl scan / ebusctl info output, raw grab captures, or anything else useful for diagnosis.

[tuca27]

Update: extensive testing, root cause identified (not an ebusd/CSV issue)

After more testing, I found the actual root cause, and it's unrelated to the decode bug I originally reported.

The parameter: Hc1RoomTempSwitchOn

My physical controller has an installer-level menu (Circuit 1 → "Alim. temp. amb." in Spanish) with 3 selectable options:

Menu label (ES)	ebusd rcmode value
Inactivo	off
Activo	modulating
Ampliado	thermostat

My system was set to Ampliado (thermostat) by default/install. In this mode, the zone setpoint is apparently owned by the physical room unit (MiPro/VR91), and the BASS's demand-calculation logic does NOT use Z1CoolingTemp/Z1DayTemp at all — regardless of whether the write succeeds.

Confirmed writes succeed at the protocol level (raw bus capture)

Using ebusctl grab result all, I confirmed both fields are correctly written and ACK'd by the controller:

3115b5240a0201030002000000a041 / 020003 : bass Z1CoolingTemp = 20.0, ACK
3115b5240a0201030007000000a041 / 020203 : bass Z1DayTemp = 20.0, ACK

So the write mechanism itself works fine — this rules out any encoding/framing issue on the write side.

Switching to "Activo" (modulating) — partial success, still no functional control

I switched Circuit 1 to modulating via the installer menu and confirmed via bus:

ebusctl read -f -m 0 -c bass Hc1RoomTempSwitchOn
modulating

With modulating active, I wrote both Z1CoolingTemp and Z1DayTemp to 20°C (actual room temp was ~26°C, a 6°C deviation that should trigger maximum demand). Confirmed via bus capture that both writes were accepted:

Z1CoolingTemp = 20.0 (confirmed via read)
Z1ValveStatus = 1 (open)
Hc1MixerMovement = active (mixing valve moving)
Hc1PumpStatus = 2 (overrun) — NEVER transitions to 1 (active), even after 20+ minutes
Z1RoomTemp: no meaningful change over 20 minutes (26.19°C → 26.06°C, within normal noise)

The zone valve opens and the mixer moves, but Hc1PumpStatus never activates and the room temperature doesn't respond — even with a large, unambiguous deviation and both setpoint fields aligned.

I also tested Z1QuickVetoTemp and ManualCooling (the "cool for N days" override) via bus — both are accepted (done) but don't produce the same effect as triggering them from the physical controller.

Conclusion

On this specific hardware/firmware (BASS0;SW=0217;HW=8803), external eBUS writes to zone setpoint fields (Z1CoolingTemp, Z1DayTemp, Z1QuickVetoTemp) are accepted and stored, but do not appear to influence the actual demand/control algorithm — not even after switching the "room temp switch-on" mode from thermostat to modulating. I could not get any of the tested combinations to produce a real change in Hc1PumpStatus or room temperature.

At this point I've reverted everything to the original configuration (thermostat, 26°C). Posting this in case it saves someone else the two days I spent on it — happy to provide more raw captures if anyone wants to dig further into the write-side protocol.