CTLV2 + VWZIO: missing humidity readout and cooling activation difference between VRC700 and eBUSd

[mainmind83]

Setup

address 15: slave #2, scanned "MF=Vaillant;ID=CTLV2;SW=0514;HW=1104", loaded "vaillant/15.ctlv2.csv"
address 76: slave #9, scanned "MF=Vaillant;ID=VWZIO;SW=0111;HW=0103", loaded "vaillant/76.vwzio.csv"
address e8: slave, scanned "MF=Vaillant;ID=FMU00;SW=0204;HW=6502"
Scan.76 Id = 21;21;41;0010019709;3100;005531;N3

Problem

The VRC700 displays room humidity on screen (49% in our case), but there is no way to read it via eBUSd:

• ebusctl find -d -c vwzio returns only the scan result — 76.vwzio.csv has no data messages defined beyond device identity
• ebusctl read -f -c ctlv2 Z1RoomHumidity → ERR: element not found
• ebusctl read -f -c vwzio RoomHumidity → ERR: element not found
• MaxRoomHumidity (ctlv2) is the configured limit, not the actual reading

Practical impact

MaxRoomHumidity acts as a cooling lockout threshold. With actual humidity at 49% and the limit set to 40%, the heat pump refused to start in cooling mode — hmu State stuck at ready despite correct commands confirmed on the bus:

ebusctl write -c ctlv2 Z1OpMode off    # confirmed: off
ebusctl write -c ctlv2 Z1SFMode party  # confirmed: party
ebusctl read -f -c hmu State           # returns: 0;25;off;ready

The lockout was only bypassed using the "cool for a few days" function directly on the VRC700 physical panel. Raising MaxRoomHumidity to 60 via eBUSd did not immediately resolve the lockout — possibly because the actual humidity value is not readable via eBUSd and the controller applies the check internally before accepting the cooling demand.

Relation to discussion #1482

In discussion #1482 a working definition was found for CTLV3:
r,ctlv3,z1RoomHumidity,z1RoomHumidity,31,15,B524,020003002800,value,,IGN:4,,,,value,,EXP,,%,z1 Room Humidity

It is unclear whether:

1. The same message ID (020003002800) applies to CTLV2 (SW=0514, HW=1104)
2. The humidity value originates from the VWZIO device or from an internal VRC700 sensor

Request

• Add humidity readout definition to 76.vwzio.csv if the value comes from VWZIO
• Or confirm whether the CTLV3 definition from vaillant vrc 720 (15.ctlv3.csv) read RoomHumidity #1482 is compatible with CTLV2 so it can be added to 15.ctlv2.csv

Happy to test any candidate definition and report back.

[andreiandreiandreiandreiandrei]

Hi,

Humidity originates from the VRC720 controller sensor. The definition is confirmed to work on VRC720/2 (ctlv2).

So, if you start ebusd server with --enabledefine and define (replace ctlv3 with ctlv2 in the definition), you should receive results.

$ ebusctl define -r "r5,ctlv3,z1RoomHumidity,z1RoomHumidity,31,15,B524,020003002800,value,,IGN:4,,,,value,,EXP,,%,z1 Room Humidity"

$ ebusctl find z1roomhumidity
ctlv3 z1RoomHumidity = 77

$ ebusctl read -f -V z1roomhumidity
ctlv3 z1RoomHumidity value=77 % [z1 Room Humidity]

[mainmind83]

Thank you for the quick confirmation!

We tested the adjusted definition on CTLV2 (SW=0514, HW=1104):

ebusctl define -r "r5,ctlv2,z1RoomHumidity,z1RoomHumidity,31,15,B524,020003002800,value,,IGN:4,,,,value,,EXP,,%,z1 Room Humidity"

Since the definition is now confirmed for both CTLV2 and CTLV3, would it make sense to include it directly in the official CSV definitions in ebusd-configuration? That way all CTLV2/CTLV3 users would get humidity readout out of the box, without needing --enabledefine or manual definitions.

---

On a related note: we are also investigating how to reliably trigger the switch from heating to cooling mode via eBUSd on a Vaillant aerothermal heat pump (aroTHERM).

Our current approach is Z1OpMode=off + Z1SFMode=party, which is confirmed correct on the bus, but the heat pump stays in ready state and does not start cooling. The only reliable trigger we found is using the "Cool for a few days" function directly on the VRC700 physical panel.

Do you have any insight into what additional register or sequence the VRC700 sets internally when activating that function, that eBUSd alone does not replicate?

[mainmind83]

The problem

When using "Cool for a few days" directly on the VRC700, the heat pump starts cooling correctly (hmu State = cooling). But sending Z1OpMode=off + Z1SFMode=party via eBUSd keeps the unit in ready state indefinitely — even though both values are confirmed correct on the bus:

$ ebusctl read -f -c ctlv2 Z1OpMode
off
$ ebusctl read -f -c ctlv2 Z1SFMode
party
$ ebusctl read -f -c hmu State
0;25;off;ready

We attempted to read CoolingStartPeriod directly using --enabledefine (now active on our setup):

ebusctl define -r "r1,ctlv2,CoolingStartPeriod,cooling period start,,,,DA00,,,HDA:3,,,start date of cooling"

This returned ERR: invalid argument — possibly because the hfrom template type (HDA:3) is not resolving correctly inline without the full _templates.csv context.

Questions

1. Do CoolingStartPeriod (DA00) and CoolingEndPeriod (DB00) exist in CTLV2 hardware, and should they be added to the official 15.ctlv2.csv?
2. Does the VRC700 write these period dates internally when activating "Cool for a few days", and is a valid date range required for the unit to accept cooling demand via eBUSd?
3. Could the missing Z1CoolingTimer also be relevant?
4. What is the correct ebusctl define syntax to read DA00/DB00 with HDA:3 type inline?

[mainmind83]

Confirmed working on CTLV2 (SW=0514, HW=1104):

ebusctl define -r "r5,ctlv2,z1RoomHumidity,z1RoomHumidity,31,15,B524,020003002800,value,,IGN:4,,,,value,,EXP,,%,z1 Room Humidity"
ebusctl read -f -c ctlv2 z1RoomHumidity
48

This confirms the definition works on CTLV2, not just CTLV3/VRC720. The value matches what the VRC700 physical display shows (~49%).

This should be added to the official 15.ctlv2.csv in ebusd-configuration.

Related: #1482

[mainmind83]

Further update: installer menu data

We now have access to the installer menu data directly from the VRC700 physical display. This provides official parameters that help clarify the cooling activation issue.

Relevant installer parameters (Circuit 1)

• Cooling possible: Yes
• Dew point control: Yes
• Min. cooling flow temp (nominal): 14°C → effective limit with 3K correction = 17°C
• Dew point correction: 3K
• Summer temp. limit (OT switch-off): 30°C
• Automatic cooling: Enabled
• OT start cooling: 15°C
• 24h accumulated outside temp: 26°C
• Current dew point: 14.5°C
• Current humidity: 49%HR

What this tells us

With accumulated outside temp at 26°C and the summer limit set to 30°C, the unit does not consider automatic cooling necessary. However, Z1SFMode=party should bypass this limit — and the values are confirmed correct on the bus — yet the unit stays in ready.

The effective minimum flow temp for cooling is 17°C (14°C + 3K dew point correction). When we attempted to trigger cooling via eBUSd, flow temp was at 35°C — well above this limit but that is the minimum, not a maximum startup threshold.

What still doesn't explain the behaviour

When "Cool for a few days" is activated from the VRC700 physical panel with identical bus values (Z1OpMode=off, Z1SFMode=party), the unit starts cooling correctly. The installer parameters above are the same in both cases.

We are unable to identify any register difference between the two methods. The VRC700 appears to apply some internal logic or sequencing when activating "Cool for a few days" that is not replicated by writing Z1OpMode and Z1SFMode via eBUSd alone.

[HBO2]

CTLV2 (VRC720): message definition for "Cooling start outside temperature" installer parameter?

Setup

Heat pump: Vaillant aroTHERM plus VWL 75/6 A (HMU SW=0902)
Controller: sensoCOMFORT VRC720 (CTLV2 SW=0514)
ebusd 26.1 (HA add-on), standard online config (15.ctlv2.csv + 08.hmu.csv), enhanced adapter

What I'm looking for

The installer-level parameter "Cooling start outside temperature" (Dutch panel:
"Koelen vanaf buitentemp.", German: "Kühlen ab Außentemperatur") — the threshold
the controller compares against the 24h-averaged outside temperature
(OutsideTempAvg) to release automatic cooling. I'd like to read it and,
eventually, write it via ebusd.

What I've verified so far

A full ebusctl find -c ctlv2 -w -f inventory of my loaded config contains
no message for this parameter. OutsideTempAvg itself is present (r1 poll)
and works fine.
Behaviour (observed live via listen + HA history): the parameter acts as a
start trigger with hysteresis, not a continuous gate. Lowering it below the
current 24h average on the panel immediately produced releasecooling=1 →
cool_prerun → cool_compressor_active; raising it back to above the average
did not stop the running cycle (shutdown came later via the internal flow
temperature protection, cool_compressor_blocked).
Panel changes do not cross the bus (verified with listen while changing
cooling-related setpoints on the sensoCOMFORT), so I can't discover the ID by
listening. I have no sensoNET/myVAILLANT gateway, so the app-based discovery
route from ebusd-configuration issue #423 isn't available to me.
--enabledefine is active and working on my setup: I just tested the
z1RoomHumidity definition from #1482 and it reads 53 %, exactly matching
the sensoCOMFORT panel value — so I can test candidate definitions
immediately.

Question

Does anyone know the register/message definition for this parameter — e.g. a
B524-style definition like the z1RoomHumidity one from discussion #1482, which
was confirmed working on CTLV2 SW=0514:

r5,ctlv2,z1RoomHumidity,z1RoomHumidity,31,15,B524,020003002800,value,,IGN:4,,,,value,,EXP,,%,z1 Room Humidity

Or a pointer to the right entry in src/vaillant/15.700.tsp?

I'm happy to test candidate definitions with --enabledefine and report back:
read-tracking against panel changes (current value should read 27 °C, and follow
when I change it on the panel), and — once reading is confirmed — a careful
single write test with panel verification.

Thanks!