Clean up and add missing hmu.HW5103/b51a/05ff32 variables

[stgm]

I'm looking to clean up and add for b51a/05ff34 and b51a/05ff35, too, but thought I'd share these first.

Added:

• TargetTempHwc
• TargetTempHc
• AirIntakeTemp
• Hours
• HoursHc
• HoursCool
• HoursHwc

All validated on SW0905, HW5103.

Removed:

- CompressorBlocktime (did not work! did it work for you @burmistrzak ?)

Renamed:

• SupplyTempWeighted -> TargetFlowTemp
  • Don't know where the other name came from, but I've been using it as Target flow temp, and that's also the name used in 08.hmu.

Writing:

Is it appropriate to also have write rules for TargetTempHwc/Hc, HeatCurve, CompStartIntegral, MaxFlowTemp, MinFlowTemp? I have been using these to control my heat pump (I have no thermostat) and if the write rule is in the default config, it's easier obviously.

For a follow-up, see below #604 (comment)

@burmistrzak @kgeree @GuyHarg maybe you can also have a look.

[stgm]

Validation:

~  % echo read -V -c hmu TargetTempHwc | nc 127.0.0.1 8888      
hmu TargetTempHwc [b51a05ff3207/ff020520033002600410] temp=[2003]50.00 °C [Target Hwc temperature]

~  % echo read -V -c hmu TargetTempHc | nc 127.0.0.1 8888 
hmu TargetTempHc [b51a05ff321c/ff023ef000a000e00108] value=[f000]15.00 °C [temperature]

~  % echo read -V -c hmu TargetFlowTemp | nc 127.0.0.1 8888
hmu TargetFlowTemp [b51a05ff321f/ff083eb0040000000000] value=[b004]75.00 °C [temperature]

~  % echo read -V -c hmu AirIntakeTemp | nc 127.0.0.1 8888 
hmu AirIntakeTemp [b51a05ff3226/ff083ec7000000000000] value=[c700]12.44 °C [temperature]

~  % echo read -V -c hmu Hours | nc 127.0.0.1 8888        
hmu Hours [b51a05ff3240/ff0827dd030000000000] value=[dd030000]989 h [hours]

~  % echo read -V -c hmu HoursHc | nc 127.0.0.1 8888 
hmu HoursHc [b51a05ff3241/ff0827c3020000000000] value=[c3020000]707 h [hours]

~  % echo read -V -c hmu HoursCool | nc 127.0.0.1 8888
hmu HoursCool [b51a05ff3243/ff082700000000000000] value=[00000000]0 h [hours]

~  % echo read -V -c hmu HoursHwc | nc 127.0.0.1 8888 
hmu HoursHwc [b51a05ff3244/ff082751000000000000] value=[51000000]81 h [hours]

Validation for removal of CompressorBlockTime: (seems to be a bug on my heat pump)

~  % echo read -h 08b51a0405ff321e | nc 127.0.0.1 8888
ERR: element not found

[stgm]

Maybe it's easiest to also include the generated CSV:

type,circuit,level,name,comment,qq,zz,pbsb,id,*name,part,type,divisor/values,unit,comment
*r,
*w,
*uw,
*[id_sw],scan,,,,SW
[id_sw>=902]r,,,CompressorHc,,,,b511,1801,ign,,IGN:1,,,,runtime,,ULG,,min,minutes,cycles,,ULG,,,start count
[id_sw>=902]r,,,CompressorHwc,,,,b511,1802,ign,,IGN:1,,,,runtime,,ULG,,min,minutes,cycles,,ULG,,,start count
r,,,TargetTempHc,room target temperature,,,b51a,05ff321c,ign,,IGN:3,,,,value,,D2C,,°C,temperature
w,,,TargetTempHc,room target temperature,,,b51a,06ff321c,value,,D2C,,°C,temperature
r,,,TargetTempHwc,cylinder target temperature,,,b51a,05ff3207,ign,,IGN:3,,,,value,,D2C,,°C,temperature
w,,,TargetTempHwc,cylinder target temperature,,,b51a,06ff3207,value,,D2C,,°C,temperature
r,,,YieldHcDay,,,,b51a,05ff3200,ign,,IGN:3,,,,value,,UIN,10,kWh,
r,,,YieldCoolDay,,,,b51a,05ff3201,ign,,IGN:3,,,,value,,UIN,10,kWh,
r,,,YieldHwcDay,,,,b51a,05ff3202,ign,,IGN:3,,,,value,,UIN,10,kWh,
r,,,YieldHcMonth,,,,b51a,05ff320e,ign,,IGN:3,,,,value,,UIN,10,kWh,
r,,,CopHcMonth,,,,b51a,05ff320f,ign,,IGN:3,,,,value,,UIN,10,,
r,,,YieldHc,,,,b51a,05ff3210,ign,,IGN:3,,,,value,,UIN,,kWh,
r,,,CopHc,,,,b51a,05ff3211,ign,,IGN:3,,,,value,,UIN,10,,
r,,,YieldHwcMonth,,,,b51a,05ff3212,ign,,IGN:3,,,,value,,UIN,10,kWh,
r,,,CopHwcMonth,,,,b51a,05ff3213,ign,,IGN:3,,,,value,,UIN,10,,
r,,,YieldHwc,energy yield hot water,,,b51a,05ff3216,ign,,IGN:3,,,,value,,ULG,,kWh,
r,,,CopHwc,,,,b51a,05ff3217,ign,,IGN:3,,,,value,,UIN,10,,
r,,,Hours,operating hours,,,b51a,05ff3240,ign,,IGN:3,,,,value,,ULG,,h,hours
r,,,HoursHc,operating hours heating,,,b51a,05ff3241,ign,,IGN:3,,,,value,,ULG,,h,hours
r,,,HoursCool,operating hours cooling,,,b51a,05ff3243,ign,,IGN:3,,,,value,,ULG,,h,hours
r,,,HoursHwc,operating hours hot water,,,b51a,05ff3244,ign,,IGN:3,,,,value,,ULG,,h,hours
r,,,CompressorBlocktime,,,,b51a,05ff321e,ign,,IGN:3,,,,value,,UIN,,min,
r,,,TargetFlowTemp,target flow temperature,,,b51a,05ff321f,ign,,IGN:3,,,,value,,D2C,,°C,temperature
r,,,FlowTemp,current flow temperature,,,b51a,05ff3220,ign,,IGN:3,,,,value,,D2C,,°C,temperature
r,,,EnergyIntegral,current energy integral,,,b51a,05ff3221,ign,,IGN:3,,,,value,,SIN,,°min,
r,,,CurrentYieldPower,current yielded energy from the environment,,,b51a,05ff3223,ign,,IGN:3,,,,value,,SCH,10,kW,
r,,,CurrentConsumedPower,current power consumption,,,b51a,05ff3224,ign,,IGN:3,,,,value,,SCH,10,kW,
r,,,CurrentCompressorUtil,current compressor utilization,,,b51a,05ff3225,ign,,IGN:3,,,,value,,D2C,,%,
r,,,AirIntakeTemp,air intake temperature,,,b51a,05ff3226,ign,,IGN:3,,,,value,,D2C,,°C,temperature
r,,,YieldCoolingMonth,,,,b51a,05ff322a,ign,,IGN:3,,,,value,,UIN,10,kWh,
r,,,CopCoolingMonth,,,,b51a,05ff322b,ign,,IGN:3,,,,value,,UIN,10,,
r,,,YieldCooling,,,,b51a,05ff322c,ign,,IGN:3,,,,value,,UIN,10,kWh,
r,,,CopCooling,,,,b51a,05ff322d,ign,,IGN:3,,,,value,,UIN,10,,
r,,,BuildingCircuitFlow,,,,b51a,05ff323c,ign,,IGN:3,,,,value,,UIN,,l/h,
[id_sw>=902]r,,,FlowPressure,,,,b51a,05ff323d,ign,,IGN:3,,,,value,,D2C,4,bar,
r,,,TotalEnergyUsage,,,,b51a,05ff324d,ign,,IGN:3,,,,value,,UIN,,kWh,
r,,,RunDataCompressorSpeed,,,,b509,5402000d0a,ign,,IGN:4,,,,value,,EXP,,rps,
r,,,RunDataEEVPositionAbs,(EEV Position in different scale?),,,b509,540200280a,ign,,IGN:4,,,,value,,UIN,,,
r,,,RunDataFan1Speed,,,,b509,540200470a,ign,,IGN:4,,,,value,,EXP,,rpm,
r,,,RunDataFan2Speed,,,,b509,540200490a,ign,,IGN:4,,,,value,,EXP,,rpm,
r,,,RunDataStatuscode,,,,b509,540200530d,ign,,IGN:4,,,,value,,UIN,34=frost_protect;100=standby;101=heat_compressor_shutdown;102=heat_compressor_blocked;103=heat_prerun;104=heat_compressor_active;107=heat_overrun;111=cool_compressor_shutdown;112=cool_compressor_blocked;113=cool_prerun;114=cool_compressor_active;117=cool_overrun;125=heat_immersion_heater_active;132=hwc_compressor_blocked;133=hwc_prerun;134=hwc_compressor_active;135=hwc_immersion_heater_active;137=hwc_overrun;141=heat_immersion_heater_shutdown;142=heat_immersion_heater_blocked;151=hwc_immersion_heater_shutdown;152=hwc_immersion_heater_blocked;202=air_purging_program_active;240=compressor_oil_heating_active;252=fan1_blocked;255=fan1_airinlet_too_high;256=fan1_airinlet_too_low;260=fan2_blocked;275=building_circuit_flow_too_low;277=building_circuit_pump_fault;280=frequency_converter_fault_compressor;281=frequency_converter_fault_mains_voltage;282=frequency_converter_fault_overheating;283=deicing_time_too_long;284=deicing_flow_temp_too_low;285=compressor_outlet_temp_too_high;286=hot_gas_temp_switch_open;287=fan1_wind;288=fan2_wind;289=current_limt_active;302=high_pressure_switch_open;303=compressor_outlet_temp_too_high_1;304=evaporation_temp_too_low;305=condensation_temp_too_low;306=evaporation_temp_too_high;308=condensation_temp_too_high;312=building_circuit_return_temp_too_low;314=building_circuit_return_temp_too_high;351=immersion_heater_flow_temp_too_high;516=deicing_active;575=frequency_converter_fault;581=connection_fault_frequency_converter;590=four_port_valve_position_fault,,HMU Status code
r,,,RunDataHighPressure,,,,b509,5402006a09,ign,,IGN:4,,,,value,,EXP,,bar,pressure
r,,,RunDataCompressorInletTemp,,,,b509,5402009808,ign,,IGN:4,,,,value,,EXP,,°C,temperature
r,,,RunDataCompressorOutletTemp,,,,b509,540200a208,ign,,IGN:4,,,,value,,EXP,,°C,temperature
r,,,RunDataEEVOutletTemp,,,,b509,540200ac08,ign,,IGN:4,,,,value,,EXP,,°C,temperature
r,,,RunStatsHMUHours,,,,b509,540200b80b,ign,,IGN:4,,,,value,,UIN,,h,hours
r,,,RunStatsHcHours,,,,b509,540200b90b,ign,,IGN:4,,,,value,,UIN,,h,hours
r,,,RunStatsHwcHours,,,,b509,540200bc0b,ign,,IGN:4,,,,value,,UIN,,h,total runtime of Hwc mode
r,,,RunStatsCompressorHours,,,,b509,540200c20b,ign,,IGN:4,,,,value,,UIN,,h,hours
r,,,RunStatsCompressorStarts,,,,b509,540200c30b,ign,,IGN:4,,,,value,,UIN,,,start count
r,,,RunStatsBuildingPumpHours,,,,b509,540200c40b,ign,,IGN:4,,,,value,,UIN,,h,hours
r,,,RunDataBuildingCPumpPower,,,,b509,540200c509,ign,,IGN:4,,,,value,,EXP,,%,
r,,,RunStatsBuildingCPumpStarts,,,,b509,540200c50b,ign,,IGN:4,,,,value,,UIN,,,total starts of building circuit pump
r,,,RunStats4PortValveHours,,,,b509,540200c80b,ign,,IGN:4,,,,value,,UIN,,h,hours
r,,,RunStats4PortValveSwitches,,,,b509,540200c90b,ign,,IGN:4,,,,value,,UIN,,,start count
r,,,RunStatsFan1Hours,,,,b509,540200d70b,ign,,IGN:4,,,,value,,UIN,,h,hours
r,,,RunStatsFan1Starts,,,,b509,540200d80b,ign,,IGN:4,,,,value,,UIN,,,start count
r,,,RunStatsFan2Hours,,,,b509,540200d90b,ign,,IGN:4,,,,value,,UIN,,h,hours
r,,,RunStatsFan2Starts,,,,b509,540200da0b,ign,,IGN:4,,,,value,,UIN,,,start count
r,,,RunDataAirInletTemp,,,,b509,540200de08,ign,,IGN:4,,,,value,,EXP,,°C,temperature
r,,,PowerConsumptionHmu,,,,b516,14,ign,,IGN:1,,,,value,,EXP,1000,kW,
r,,,DateTime,date/time,,,b504,00,dcfstate,,UCH,0=nosignal;1=ok;2=sync;3=valid,,DCF receiver state,btime,,BTI,,,time,bdate,,BDA,,,date,temp,,D2B,,°C,temperature
r,,,Status16,outside temperature,,,b504,16,value,,D2C,,°C,temperature
uw,,,SetMode,Operation mode,,,b510,00,hcmode,,UCH,0=auto;1=off;2=heat;3=water,,boiler mode,flowtempdesired,,D1C,,°C,temperature,hwctempdesired,,D1C,,°C,temperature,hwcflowtempdesired,,UCH,,°C,temperature,ign,,IGN:1,,,,disablehc,,BI0,,,,disablehwctapping,,BI1,,,,disablehwcload,,BI2,,,,ign_1,,IGN:1,,,,remotecontrolhcpump,,BI0,,,,releasebackup,,BI1,,,,releasecooling,,BI2,,,
w,,install,SetMode,Operation mode,,,b510,00,hcmode,,UCH,0=auto;1=off;2=heat;3=water,,boiler mode,flowtempdesired,,D1C,,°C,temperature,hwctempdesired,,D1C,,°C,temperature,hwcflowtempdesired,,UCH,,°C,temperature,ign,,IGN:1,,,,disablehc,,BI0,,,,disablehwctapping,,BI1,,,,disablehwcload,,BI2,,,,ign_1,,IGN:1,,,,remotecontrolhcpump,,BI0,,,,releasebackup,,BI1,,,,releasecooling,,BI2,,,
r,,,Status01,Vorlauftemperatur/Rücklauftemperatur/Aussentemperatur/WW Temperatur/Speichertemperatur/Pumpenstatus,,,b511,01,temp,,D1C,,°C,flow temperature,temp_1,,D1C,,°C,return temperature,temp_2,,D2B,,°C,outside temperature,temp_3,,D1C,,°C,hot water temperature,temp_4,,D1C,,°C,storage temperature,pumpstate,,UCH,0=off;1=on;2=overrun;4=hwc,,pump status
r,,,Status02,Betriebsart/Maximaltemperatur/ReglerCurrentTemp/Maximaltemperatur/ReglerCurrentTemp,,,b511,02,hwcmode,,UCH,0=disabled;1=on;2=off;3=auto,,hot water mode,temp,,UCH,,°C,max temperature,temp_1,,D1C,,°C,current temperature,temp_2,,UCH,,°C,max temperature,temp_3,,D1C,,°C,current temperature
r,,,Status,Status,,,b511,03,temp,,D2C,,°C,temperature,press,,FLT,,bar,pressure,press_1,,FLT,,bar,pressure,hcmode,,UCH,0=off;1=cooling;3=heat;4=water,,boiler mode,hex,,HEX,,,
uw,,,StatusCirPump,Status circulation pump,,,b512,00,value,,UCH,0=off;100=on,,
r,,,Currenterror,Current errors,,,b503,0001,error,,UIN,,,error number,error_1,,UIN,,,error number,error_2,,UIN,,,error number,error_3,,UIN,,,error number,error_4,,UIN,,,error number
r,,,Errorhistory,Error_History,,,b503,0101,index,m,UCH,,,,status,,UCH,,,Status,time,,VTM,,,time,date,,HDA:3,,,date,error,,UIN,,,error number
w,,install,Clearerrorhistory,Clear error history,,,b503,0201,cleared,s,UCH,0=no;1=yes,,

[stgm]

Note: in my system the CompressorBlockTime is still requested by the VWZIO successfully for the monitoring function:

2026-05-05 15:16:17.846 [update notice] received unknown MS cmd: 7108b51a040501321e / 0a01083400000000000000
2026-05-05 15:16:19.323 [update notice] received unknown MS cmd: 7108b51a04050a321e / 0a0a083400000000000000

I just can't request it from the ebusd master.

[burmistrzak]

@stgm IMHO, polling the heat pump unit directly (outside register blocks used for diagnostics/internet gateway, e.g. B509) should be considered not safe by default. That's because these registers tend to change a bit with each PCB revision and are usually not designed to be polled externally.

I'd suggest to document your findings, tag them with your SW version and declare them to be passive. The most compatible/safe approach would be B509. Everything else is much more fragile.

If you'd like to contribute to research, take a look at https://github.com/Project-Helianthus as well.

See #595 (comment) for a bit more context. ☺️

[stgm]

@burmistrzak Thank you. A few follow-up questions then to understand the context.

1. I assumed it was safe adding these because a lot of the b51a are already in this config and all of these are already in the base hmu config. Are there values in my PR specifically that you think are suspect?

2. What would "unsafe" mean in this context? I'm polling the first three values from this PR and ~7 other variables every 10 seconds, and this has been running well for a month or so.

3. Was your CompressorBlocktime an oversight or does it indeed work on some software versions. It's not working on mine but I do have a fairly new SW version.

4. You call b509 an "approach", do you mean that you can sometimes find the same values in multiple "blocks" (is that the right word)?

One reason to contribute is that I have a working setup using quite a few of the missing values and it works, but it's quite annoying that the current config is so bare-bones :-)

[burmistrzak]

1. I assumed it was safe adding these because a lot of the b51a are already in this config and all of these are already in the base hmu config. Are there values in my PR specifically that you think are suspect?

@stgm I assume everything undocumented and/or unused by myVaillant connect to be not safe for active polling. Observing i.e. passive is always fine though.
I unfortunately don't have my notes on hand to give you more specific feedback.

Maybe @chrizzzp can help you out. 😉

2. What would "unsafe" mean in this context? I'm polling the first three values from this PR and ~7 other variables every 10 seconds, and this has been running well for a month or so.

Unsafe means that polling some registers could mess with the internal logic of the heat pump and lead to unintended behavior (fans not spinning, valves opening, etc.) or the unit resetting because of uncaught errors.

3. Was your CompressorBlocktime an oversight or does it indeed work on some software versions. It's not working on mine but I do have a fairly new SW version.

IIRC, older software versions work fine.

4. You call b509 an "approach", do you mean that you can sometimes find the same values in multiple "blocks" (is that the right word)?

Yes, but some blocks are seemingly intended for specific (unknown) purposes/consumers and polling them can cause problems. The B509 block is, as far as we know, used for remote monitoring/local diagnostics and designed to be polled regularly.

One reason to contribute is that I have a working setup using quite a few of the missing values and it works, but it's quite annoying that the current config is so bare-bones :-)

Feel free to tell us more (versions, components, etc.) about your setup!
I feel your frustration. That's why there's a new initiative to document important register blocks in a more systematic manner.

[stgm]

Two-part setup:

1. Vaillant hardware:

   • Arotherm 55/6 "hmu00", SW0905, HW5103
   • VWZ AI /3 "vwzio", SW0202, HW0103
   • no thermostat!!

   Important to understand here is that the VWZ AI is acting in its active controller mode, because there is no thermostat. From my experiments it is clear that TargetTempHwc and TargetTempHc are kept on the HMU and changed by the VWZ AI if changed on the display. So in fact the HMU is running the algorithm, from parameters that may be set from the VWZ AI.

   This is why it makes sense to at least read these from the HMU. In my dashboard app I read everything from the HMU except things like OutdoorTemp, ThreeWayValve, for which the VWZ AI is obviously the primary source.

   Obviously N=1, but reading these registers does not change any behavior in the heat pump. However...

2. My own thermostat. I am actually controlling everything by doing write actions to, among a few other variables, TargetTempHc and TargetTempHwc. These have a separate write address. And it works fine if there is no Vaillant thermostat to take over. I've seen older questions from people who wrote these values but their thermostat kept taking over :-) But this is secondary in my request and I haven't added write rules to the PR because I get the sense this is not actively promoted. Although it would be much easier if the write options were indeed in the default config (maybe with a condition that no thermostat is present).

In summary: I'm not observing MyVaillant connect but instead the interactions between the VWZ AI and the HMU.

P.S. Seems that some of these values are not in the Helianthus docs for b51a, maybe because everyone is actually using the thermostat?

[burmistrzak]

@stgm Yeah, most folks have a thermostat/regulator setup. 😅

It might be possible to handle VWZ AI's controller mode by adding conditions, however you'll have to first find a register that indicates whether VWZ is in standalone mode. Once we have that, you can add all those registers specific to controller mode, without breaking other setups along the way.

[stgm]

@burmistrzak Fair enough, I guess, for such a public base repo.

Actually, when the thermostat (or I) sends a SetMode-like command (b510-00) this is the "thermostat will arrange everything from now on"-override. You may have seen this - it is the basis of thermostat control for the Arotherm. When that command is sent every 15 minutes or so, the VWZ AI display reflects that the thermostat is in full control. More importantly: at that point my hmu stops accepting reads and writes to TargetTempHwc, TargetTempHc, HeatCurve, and probably a few related ones.

Maybe that's already what's needed here? Although for documentation purposes you'd like to be able to alert ebusd users that the command does not make sense but could work in a specific context.

If this passive rejection is not deemed enough, do you have any similar basic params in mind for which the register is known? I'll take a look around, but if you have any specific pointers that would be much appreciated.

[burmistrzak]

@stgm These are interesting insights, thanks for sharing!
However, something more concrete like an enum or boolean, clearly indicating standalone mode, is required here.
Random example: @condition(Mc.CfgHeatSinkType.value, "1")

I don't have a VWZ AI, so I'm not familiar enough to help you with specific register blocks. Sorry!

[michaelzeipert-cmyk]

Hi all, i am missing These two rows in the current csv:

r,,,RunDataFlowTemp,,,,b509,540200fc08,ign,,IGN:4,,,,value,,EXP,,°C,"current flow temp, accurate to 2 decimal places"
r,,,RunDataReturnTemp,,,,b509,5402000609,ign,,IGN:4,,,,value,,EXP,,°C,"current return temp, accurate to 2 decimal places"

I would appreciate if these parameters could be added again.

[stgm]

@michaelzeipert-cmyk I guess that's already being discussed at #595. This PR only considers b51a/05ff32 messages. That was my intention anyway.

[stgm]

@burmistrzak I am considering that there may not be a register signifying this mode, such that a condition could be made. To be clear: the HMU tracks this mode, not the VWZIO. So I expect the register to be in the HMU, but given how it works (see below) there may not be a register at all.

1. Thermostat or someone sends SetMode (b510/00) to the hmu
2. For 15 minutes
   • the hmu starts doing exactly what SetMode requests
   • the hmu stops sending certain status messages to the vwzio every 10 seconds
     • untested claim: this is the cue that makes vwzio change its UI
3. As soon as the hmu starts sending those status messages to the vwzio, so by default, the hmu accepts messages like in this PR from the vwzio. These are accessible from the vwzio main menu and/or monitoring menu.

I would be interested in a statement on how the maintainer(s) of this repo would like to see this. Do you want to be as complete as reasonably possible in terms of messages decoded? Do you need these to be update-read? Do you want write rules in the repo? Or are these messages just not meant to be this repo at all?

cc @john30

[chrizzzp]

@stgm Just my two cents:

My system: Arotherm Split VWL 105/5 AS S2 (ID=HMU00;SW=0902;HW=5103), Hydraulik Station VWL 127/5 US (ID=VWZ00;SW=0522;HW=5103), VRC720/2 regulator, FM5 (VR71) module, VR921 gateway
(so no stand-alone system, different hydraulic station)

hmu TargetTempHwc contains no data
3108b51a0405ff3207 / 02ff01
hmu TargetTempHc contains no data
3108b51a0405ff321c / 02ff01
hmu CompressorBlockTime gives reasonable data (also when read from ebuds adapter as master, non-zero value when HP is in blocked state)
3108b51a0405ff321e / 0aff083402000000000000

All other (AirIntakeTemp, Hours, HoursHc, HoursCool, HoursHwc) readings work and give reasonable values.

I agree, SupplyTempWeighted should be renamed TargetFlowTemp. Not sure how it got there.

BTW: on my system with a regulator and mixed heating circuit the B510 00 (SetMode) command is sent every 10 seconds (!) from the regulator to HMU and VWZ00.

Regarding safely polling values from the b51a block: I've never had any issues and still actively poll several values from there since more than two years. But there were concerning reports (e.g. here and here) that raise the question whether the issue arose from several masters (regulator/VWZ and ebusd) polling from these HMU registers at the same time. I must confess I don't think this enigmatic issue was fully investigated and solved.

As @burmistrzak already mentioned, most of these values can also be read from the b509 block (prefix RunData and RunStats) and this is actually how the internet gateway does it, so this should be safe.

[stgm]

@chrizzzp Thanks, that's great!

You have the regulator, and you confirm that in your SW version the TargetTempH*c aren't readable, like in mine when I send the SetMode. Very interesting.

And good to know that SetMode is sent every 10 seconds, too. That makes sense given that the hmu also updates the vwzio every 10 seconds. I could only confirm the timeout of 15 minutes.

I'll leave CompressorBlockTime untouched then. Might be a bug in my SW version then, given that the vwzio is able to show it to me.

In that case I'm looking for guidance on whether the configuration in this repo should at least provide these variables in order to be able to decode them when they are sent via the vwzio (update-read?); or that these variables are considered way out of scope. My target was to have them all in the repo, including write rules even. But it's not my repo of course :-)

[chrizzzp]

@stgm I think you are one of the few people operating the heat pump without a regulator, therefore I think your experience is very valuable here. :-) Albeit a bit off-topic, I would be interested which definitions you actively controlled by writing to them in order to adjust your system to your heating demands. Do you need regular adjustments (write commands) or only occasionally?

Back to topic: IMO the definitions only valid in 'standalone mode' should remain in the base config of the HMU as they are valid registers for this device, but only used under certain circumstances (and it's good to keep this existing knowledge in place).

BTW, besides TargetTempHwc/TargetTempHc there are more definitions which only seem to work in standalone mode (because they are "overridden" by the respective settings from the regulator):

r,,,HeatCurve,,,,b51a,05ff352d,ign,,IGN:3,,,,,ign,,IGN:3,,,,,bcd,,BCD,10,,,heat curve 0.1 to 4.0
r,,,SummerSwitchOffTemp,,,,b51a,05ff352e,ign,,IGN:3,,,,,ign,,IGN:3,,,,,temp,,D2C,,,°C,Switch-off temperature summer
r,,,HcBivalencePoint,,,,b51a,05ff352f,ign,,IGN:3,,,,,ign,,IGN:3,,,,,temp,,D2C,,,°C,Central heating bivalence point
r,,,HwcBivalencePoint,,,,b51a,05ff3530,ign,,IGN:3,,,,,ign,,IGN:3,,,,,temp,,D2C,,,°C,Bivalence point domestic hot water
r,,,MaxFlowTemp,,,,b51a,05ff3532,ign,,IGN:3,,,,,ign,,IGN:3,,,,,temp,,D2C,,,°C,Maximum flow temperature
r,,,MinFlowTemp,,,,b51a,05ff3533,ign,,IGN:3,,,,,ign,,IGN:3,,,,,temp,,D2C,,,°C,Minimum flow temperature
r,,,HcModeActive,,,,b51a,05ff3534,ign,,IGN:3,,,,,ign,,IGN:3,,,,,yesno,,UCH,0=no;1=yes,,,Central heating mode active
r,,,HwcModeActive,,,,b51a,05ff3535,ign,,IGN:3,,,,,ign,,IGN:3,,,,,yesno,,UCH,0=no;1=yes,,,Domestic hot water mode active
r,,,HwcChargeHysteresis,,,,b51a,05ff3539,ign,,IGN:3,,,,,ign,,IGN:3,,,,,calibration,,D2C,,,K,Hysteresis Hwc charging
r,,,ImmersionHeaterMode,,,,b51a,05ff331e,ign,,IGN:3,,,,,ign,,IGN:3,,,,,onoff,,UCH,0=off;1=on,,,Immersion heater mode

If they are actively polled by the VWZIO in standalone-mode, then one could indeed define them as update-read (u) definitions as @burmistrzak mentioned - and can not throw errors when trying to actively read them. This would, of course, not allow write acess from the base repo.

BTW isn't the standalone mode selected in the initial setup assistant of the heat pump? If yes, one would assume there could indeed be registers set specific to this mode (indicating no regulator is present). You mentioned, there would be an UI difference in the VWZIO between 'standalone' and 'regulator' mode? Could you provide examples?

[stgm]

@chrizzzp Thanks.

I'm controlling by setting room temp (same algo as the official Vaillant regulator), setting lower dhw temp until 14:00 in the afternoon, extending runs by raising min flow temp while it's running. The heat pump more or less makes its own decisions (e.g. actually starting dhw when delta T is reached) and runs the energy-integral and provides the heat curve. So not quite hands-off, but at the same time, the hmu still does quite a bit.

The variables that you mention do not work while the regulator is active make sense. Did you actually test them? *(Actually, they are documented in the manual! So testing is nice but not required here.)

The standalone mode is indeed chosen in the install! The manual says: "If no system control is installed and this has been confirmed in the installation assistant, the following additional functions are displayed in the product's control panel". But, as I said, the thing still shoots into follow mode as soon as SetMode is sent to the heat pump. I can't test but I'm interested to know what happens in a system with regulator if the regulator stops working (e.g. battery dead for the wireless version).

I agree that the values should be there as they are actively used. I'd prefer the read version. I'll wait a little, and check for completeness of the b51a range in the mean time.

[stgm]

I'm wondering if it would be acceptable to hide the write rules behind a "controller" access level. So for variables like TargetTempHc but later also HeatCurve, SummerSwitchOffTemp etc.

[chrizzzp]

@stgm

The variables that you mention do not work while the regulator is active make sense. Did you actually test them? *(Actually, they are documented in the manual! So testing is nice but not required here.)

Yes, I tested them. They all give 02ff01 as response, so no data.

[stgm]

OK I've gone through all the user-level menus on the VWZ AI again, and all items are either already in the current hmu.HW5103 tsp OR they are added in this PR (with two notable exceptions, see at end).

I've kept read access for all (not update-read): not only because the original hmu tsp also provides all variables with read access but because the hmu.hw5103 also has all other similar variables with read access.

I don't see a risk for malfunctioning due to polling these messages. I've been polling the first three every 10 sec, and the vwzio polls these every 1,5-3 sec when you show them in a menu.

---

I would appreciate permission to also add write variants for the TargetTempHc and TargetTempHwc messages, though maybe under "controller" access level or something more appropriate.

---

*) The only missing items are:

• b51a05ff 32 1d for showing/setting cool mode (which allows cooling to be used; but I haven't tested with cooling and found the value mentioned nowhere else, so skipping)
• b51a05?? 35 3b that the vwzio uses to get dhw temp, which is weird because vwzio has the sensor (so not needed); plus I was not able to read it from ebusd

[john30]

@stgm just wanted to answer your email but maybe its better to put it here:
IMO writes are fine as long as they are associated with a user level of installer or at least service.

[stgm]

@john30 Any opinion on values that are only available when the thermostat/regulator is not in the system? At the very least I'd like to add a comment in the tsp but that does not carry over in the csv of course.

@burmistrzak suggested a condition but I think it's plausible that there is no register indicating absence of the thermostat.

[stgm]

@john30 @burmistrzak @chrizzzp

I think this is done. Only discussion point is the access level for the writes.

The two writes are not special - it's just room temp and cylinder temp. In the VWZ AI these are primary settings for users, no install level required. I also see that in the ctvl2 there are lots of write rules without an access level, so I guess this is not uncommon.

So, normally I would say that these values should also be unrestricted. I have therefore removed the access level for now. If you insist, I'm fine adding it. In that case I would suggest a separate "control" level.

[stgm]

OK, there is a register for presence of the regulator (thermostat) after all: 0x3528.
I could put the two non-installer writes behind a condition.
I'm not sure how the conditions are actually used, are they enforced by ebusd or are they just metadata for home assistant etc.?

[stgm]

For some reason I did not pick up StartCooling ManualCooling which is in the main control of the vwzio.
You can start cooling using that variable, and it will use the CoolTargetFlowTemp to control (so not based on a virtual room target, simply a circuit water temperature target).

This now added.

[chrizzzp]

OK, there is a register for presence of the regulator (thermostat) after all: 0x3528. I could put the two non-installer writes behind a condition. I'm not sure how the conditions are actually used, are they enforced by ebusd or are they just metadata for home assistant etc.?

@stgm
Nice, how did you identify the register? How is it decoded?
For my system (VRC720/2 present) it is:
08b51a0405ff3528 / 0aff020001000000010001

Conditions are applied within ebusd. Here's an example of the resulting CSV output:

# variable definition
*[hwcenabled],,,hwcenabled,,value
r,,,HwcEnabled,hwc enabled,,,b524,020001000100,ign,,IGN:4,,,,value,,UCH,0=no;1=yes,,
w,,,HwcEnabled,hwc enabled,,,b524,020101000100,value,,UCH,0=no;1=yes,,
# conditional definition
[hwcenabled=1]r,,,HwcCircPumpStatus,hwc circulation pump status,,,b524,020001000200,ign,,IGN:4,,,,value,,UCH,0=off;1=on,,
[hwcenabled=1]r,,,HwcOpMode,hwc operation mode,,,b524,020001000300,ign,,IGN:4,,,,value,,UIN,0=off;1=auto;2=manual,,
[hwcenabled=1]w,,,HwcOpMode,hwc operation mode,,,b524,020101000300,value,,UIN,0=off;1=auto;2=manual,,

The register definitions behind conditions will not be available in ebusd if the condition is not met.

[stgm]

@chrizzzp
I ran the install wizard and it works like the settings menu, continuously polling the value while it's displaying the current status (e.g. "Yes" or "No" in this case ;-)) So that made it very easy; and the install wizard doesn't change anything by itself, so no problem running it.

The decode is like other b51a values: in the 3rd byte of the raw answer there's 02 which means it's a setting (not a read-only status, which would have 08). Then 1 byte which is the type: 00 means enum. Then you have 2 bytes current value 0100, 2 bytes minimum allowed 0000 and 2 bytes maximum 0100. The last byte seems to be divider or step value.

So, you could read and write it just like ManualCooling in this PR, which is a similar boolean setting.

Another question: what is the use then of filtering in ebusd? I mean, I write apps that use ebusd to control stuff. No need to hide what's not possible, because I wouldn't try to use it like that. So what is it for? And, does ebusd enforce reading of values that are used in conditions? Even when the condition is at installer level? What if the value in the condition changes, how soon is this picked up? These are not values that change often, but nevertheless, it adds complexity.
There is surely some value in conditions, for human understanding, but I'd prefer comments for that. For automation I don't yet understand the real-world use.

[chrizzzp]

@stgm
Ok, so value 0000 means no regulator present and 0100 regulator present?

About conditions: from the Wiki:

Conditions allow to enable/disable a complete configuration part for e.g. a particular variant of a device.
A good example for this is a product line of heat pumps, each of which answers to the same query with different meanings of the returned values (e.g. evaporator temperature versus air outlet temperature).

They can e.g. be used to define conditions specific for a certain firmware-versions (newer than...) or (I think) also hardware-revisions, as e.g. used here.

They also have an impact e.g. in Home Assistant, if auto-discovery of entities is used (which is the default). The auto-generation of the full set of entities might overload the "unexperienced user" (or flood the HA dashboard). I don't know...

AFAIK reading of conditional defintion is not enforced by ebusd. I have not much experience using them, I think they are rarely used, so I don't know when they are picked up if a condition changes. These are probably questions to @john30...

[stgm]

Thanks @chrizzzp - I think it's good to have them answered :-)

I've seen the hardware revisions, and that makes more sense in the technical sense. The file will always be loaded after the HW/SW revision is known. I'm very curious as to how @john30 sees this for conditions depending on other ebus variables.

I have value 0000 indeed, so it should be as you say!
If the condition is not going to happen, I won't add the regulator here, but maybe in the other PR (installer-level b51a variables), just to be complete.