Improved HMU config

[pulquero]

This config in combination with john30/ebusd#1213 does not cause any issues for my setup.

Highlights:

• messages ordered by ID
• consistent naming convention, useful for filtering
• removed non-applicable messages for this hw/sw combination

[john30]

completed with 2a3c77f

[burmistrzak]

@chrizzzp Do any of these registers below work for you?
Also, what is the exact makeup of your system?

I'm trying to gauge if a HW-specific PR for our HMU00 model would be sensible.

hmu SourceTempOutput: ERR: invalid position
hmu Fan2Starts: ERR: invalid position
hmu Fan2Hours: ERR: invalid position
hmu CompressorHysteresisCooling: ERR: invalid position
hmu CompressorHysteresisHc: ERR: invalid position
hmu ConsumptionThisYear10: ERR: invalid position
hmu ConsumptionThisYear11: ERR: invalid position
hmu ConsumptionThisYear12: ERR: invalid position
hmu ConsumptionThisYear1: ERR: invalid position
hmu ConsumptionThisYear2: ERR: invalid position
hmu ConsumptionThisYear3: ERR: invalid position
hmu ConsumptionThisYear4: ERR: invalid position
hmu ConsumptionThisYear5: ERR: invalid position
hmu ConsumptionThisYear6: ERR: invalid position
hmu ConsumptionThisYear7: ERR: invalid position
hmu ConsumptionThisYear8: ERR: invalid position
hmu ConsumptionThisYear9: ERR: invalid position
hmu ConsumptionTotal: ERR: invalid position
hmu Fan2Hours: ERR: invalid position
hmu Fan2Starts: ERR: invalid position
hmu HcBivalencePoint: ERR: invalid position
hmu HcModeActive: ERR: invalid position
hmu HeatCurve: ERR: invalid position
hmu HwcBivalencePoint: ERR: invalid position
hmu HwcChargeHysteresis: ERR: invalid position
hmu HwcModeActive: ERR: invalid position
hmu ImmersionHeaterMode: ERR: invalid position
hmu MaxFlowTemp: ERR: invalid position
hmu MinFlowTemp: ERR: invalid position
hmu SourcePressure: ERR: invalid position
hmu SourceTempOutput: ERR: invalid position
hmu Status02: ERR: invalid position
hmu Status16: ERR: invalid position
hmu Status: ERR: invalid position
hmu SummerSwitchOffTemp: ERR: invalid position
hmu TargetTempHc: ERR: invalid position
hmu TargetTempHwc: ERR: invalid position
hmu YieldThisYear10: ERR: invalid position
hmu YieldThisYear11: ERR: invalid position
hmu YieldThisYear12: ERR: invalid position
hmu YieldThisYear1: ERR: invalid position
hmu YieldThisYear2: ERR: invalid position
hmu YieldThisYear3: ERR: invalid position
hmu YieldThisYear4: ERR: invalid position
hmu YieldThisYear5: ERR: invalid position
hmu YieldThisYear6: ERR: invalid position
hmu YieldThisYear7: ERR: invalid position
hmu YieldThisYear8: ERR: invalid position
hmu YieldThisYear9: ERR: invalid position
hmu YieldTotal: ERR: invalid position

[chrizzzp]

@burmistrzak

Except the Fan2* values all do not work on my system (Arotherm split VWL 105/5 AS S2, hydraulic station VWL 127/5 IS). My heat pump has two fans. Some of these values might only apply if the heat generator works in stand-alone mode (no system regulator present, so they might not be generally wrong).

[burmistrzak]

@chrizzzp That‘s what I thought. Are you using jonesPD‘s version of 08.hmu?

@john30 Would it be possible to use conditions to check for the presence of a system regulator? Would be nice to enable certain definitions in the existing HMU configuration only for standalone systems.

[chrizzzp]

@burmistrzak

That‘s what I thought. Are you using jonesPD‘s version of 08.hmu?

Well, I use a (local) fork with lots of edits concerning yet unidentified messages. But the functional part is very similar to jonesPD's version (some non-working definitions commented out).

[john30]

@chrizzzp That‘s what I thought. Are you using jonesPD‘s version of 08.hmu?

@john30 Would it be possible to use conditions to check for the presence of a system regulator? Would be nice to enable certain definitions in the existing HMU configuration only for standalone systems.

depends on how the presence can be detected

[john30]

YieldTotal should be the name to choose as this is used frequently. Filtering can be done using the circuit name anyway.

@john30 I see. But how would I filter out YieldTotal only from hmu00, while still including all other MQTT messages from basv3 and hmu00..? 🤔

each message carries its circuit, so e.g. in mqtt this would be the discriminator for multiple messages with the same name

[burmistrzak]

depends on how the presence can be detected

@john30 I was thinking about using the global Scan results to determine whether a system regulator is present on the bus.
Would be a sleek way to improve the overall compatibility of the HMU configuration.

Edit: Played around a bit, but unfortunately got stuck... Is it even possible to use@condition() that way?

[burmistrzak]

@john30 I went through the docs and do I understand correctly that e.g. Scan.Id.product can be used to check whether a particular device is on the bus?

Edit:
It seems like Scan.Id.product only works within the same circuit of a given message?
Also, != in @condition is apparently an invalid argument?
Example of a condition I tried: @condition(Scan.Id.product, "!='0020328845'")

[burmistrzak]

@chrizzzp IMHO, it's probably better to aim for maximum compatibility with the generic HMU definition and only include messages supported by both uniTOWER and VWZ AI.
See #316 (comment) for context.

More specific definitions should go into a separate configuration, meaning parts of e.g. fa74d0c likely need to be reworked. It’s a rather simple solution to get rid of most of these invalid position errors.

To sort out the rest, we’ll have to somehow detect when HMU is in standalone mode, i.e. no regulator is used. There’s actually an option (in the setup menu) to configure whether a system regulator is present. We just need to find the correct register and use it as a condition in the definition.

[chrizzzp]

@burmistrzak
Could be the way to go. At the moment I'm not sure how many different setups would have to be considered, e.g. I have a split system (consisting of hmu and a hydraulic station VWL, currently with circuit name vwz00). Maybe there are also specific registers set during the installation which allow differentiation.

[burmistrzak]

@chrizzzp Yes, under Installer Level > Setup assistant, is the option we need to find the register for!
I tried listening on the bus while clicking through the menu, but haven’t found anything useful yet.
Also, I seemingly can’t get ebusctl to print unknown messages in realtime… Any hints? 😅

To make conditions work, we’ll have to gather some product numbers of different setups. Can you share yours?

root@470d1f881ae9:/# ebusctl find | grep -i scan
Scan Id = no data stored
scan.08  = Vaillant;HMU00;0902;5103
Scan.08 Id = XX;XX;XX;0010021117;XXXX;XXXXXX;XX
scan.15  = Vaillant;BASV3;0760;7304
Scan.15 Id = XX;XX;XX;0020328845;XXXX;XXXXXX;XX
scan.76  = Vaillant;VWZIO;0902;5103
Scan.76 Id = XX;XX;XX;0010022066;XXXX;XXXXXX;XX
scan.f6  = Vaillant;NETX3;0124;0404
Scan.f6 Id = XX;XX;XX;8000015501;XXXX;XXXXXX;XX

[chrizzzp]

@burmistrzak

08;Vaillant;HMU00;0902;5103;21;21;44;0010021113;1610;XXXXXX;N3 (VWL 105/5 AS S2)
76;Vaillant;VWZ00;0522;5103;21;21;40;0010023523;3110;XXXXXX;N4 (VWL 127/5 IS)
15;Vaillant;CTLV2;0514;1104;21;21;35;0020260914;0953;XXXXXX;N8 (VRC 720/2)
26;Vaillant;VR_71;0104;0503;21;21;50;0020184846;0082;XXXXXX;N9 (VR71 = FM5)
f6;Vaillant;NETX2;4035;5703;21;21;31;0020260965;0938;XXXXXX;N5 (VR921)

To make it a bit more complicated: we've noticed earlier that different product IDs do not necessarily mean different product, but can also reflect different international versions of the same product.

See here...
stadid#2 (comment)

[burmistrzak]

To make it a bit more complicated: we've noticed earlier that different product IDs do not necessarily mean different product, but can also reflect different international versions of the same product.

@chrizzzp Well, at least we know where to find them. Manuals to the rescue! 😉

Btw. I‘m not entirely sure why we‘re reading values belonging to VWZ from HMU? It’s quite clear that e.g. VWZIO is the inside unit (in my case uniTOWER plus) housing the 3-way valve, immersion heater, etc... So what’s the deal with that? It it because the actual VWZ registers are unknown?

[chrizzzp]

@burmistrzak

I assume you aim to create product-specific hmu configurations as done for the bai devices (gas boilers)?

https://github.com/eBUS/ebus.github.io/blob/main/en/vaillant/08.bai.csv

[chrizzzp]

Btw. I‘m not entirely sure why we‘re reading values belonging to VWZ from HMU? It’s quite clear that e.g. VWZIO is the inside unit (in my case uniTOWER plus) housing the 3-way valve, immersion heater, etc... So what’s the deal with that? It it because the actual VWZ registers are unknown?

Could you give an example which vwz value you read from the hmu?

As far as I know (in my system) the hmu and vwz have the same PCBs (according to same spare part product number of PCB). So all read/write command can be targeted at both circuits - theoretically - they have the same registers. However, the setups can be different (e.g. connection of immersion heater, DCF sensor, water pump to the PCB...) in different products.

Here are the registers I read from the vwz (respective hmu registers can be polled but do not deliver respective values and vice versa), the associated devices/sensors are in the vwz:

*r,,,,,,B504,,,,,,,,,,,,,,,,,,,,,,,,,
r,,DcfTimeDateTemp,time date,,,,00,,,dcfstate:DCF_state;btime:time;bdate:date;temp2:outdoortemp,,,
*r,,,,,,B509,54,,,IGN:4,,,,,,,,,,,,,,,,,,,,,
r,,RunDataReturnFlowTemp,,,,,02000609,,,tempv,,
r,,RunDataSystemPressure,,,,,02007409,,,pressv,,
r,,RunDataImmersionHeaterActive,,,,,0200AD0D,,,onoff,,
r,,RunDataCondensorOutletTemp,,,,,0200B608,,,tempv,,
r,,RunStatsVWZHours,,,,,0200B80B,,,UIN;IGN:2,,hours
r,,RunStatsHcHours,,,,,0200B90B,,,UIN;IGN:2,,hours
r,,RunStatsImmersionHeaterHours,,,,,0200BD0B,,,UIN;IGN:2,,hours
r,,RunStatsImmersionHeaterStarts,,,,,0200C00B,,,cntstarts2;IGN:2,,
r,,RunStatsPrioritySwitchingValveOps,,,,,0200C10B,,,cntstarts2;IGN:2,,
r,,RunStatsBuildingCircuitPumpHours,,,,,0200C40B,,,UIN;IGN:2,,hours
r,,RunDataBuildingCircuitPumpPower,,,,,0200C509,,,EXP,,%
r,,RunStatsBuildingCPumpStarts,,,,,0200C50B,,,cntstarts2;IGN:2,,
r,,RunDataSupplyFlowTemp,,,,,0200FC08,,,tempv,,
*r,,,,,,B512,,,,,,,,,,,,,,,,,,,,,,,,,
r,,StatusVWZ_001,,,,,0F0001,,,UCH;UCH;UCH;temp:supplyimmersionheater;press10:WaterPressure;UCH,,
*r,,,,,,B514,05,,,IGN:2,,,,,,,,,,,,,,,,,,,,,
r,,PrioritySwitchingValve,T.1.02 DHW prioritising diverter valve,,,,0203ffff,,,UIN,0=heating circuit;1=warm water circuit,,,,,,,,,,,,,,,,,,,,,,,,,
r,,SupplyTemp,,,,,2803FFFF,,,temps2,10,,Supply temperature (°C),,,,,,,,,,,,,,,,,,
r,,ReturnTemp,,,,,2903FFFF,,,temps2,10,,Return temperature (°C),,,,,,,,,,,,,,,,,,
r,,HwcTemp,,,,,2C03FFFF,,,temps2,10,°C,SWW Tank temperature (°C),,,,,,,,,,,,,,,,,,
r,,CondensorOutletTemp,,,,,3B03FFFF,,,temps2,10,°C,Condensor outlet temperature (°C),,,,,,,,,,,,,,,,,,
r,,OutdoorTemp,T.1.69 Outdoor temperature,,,,4503ffff,,,SIN,10,°C,,,,,,,,,,,,,,,,,,,,,,,,
r,,EnergySupplyCompanyBlockingS21Status,,,,,4803FFFF,,,UCH,0=open;1=closed,,,,,,,,,,,,,,,,,,,,
r,,MultifunctionConnectorOutput1_X13Status,,,,,7703FFFF,,,onoff,,,Multifunction connector 1: Zone valve; cooling signal; intermediate heat exchanger pump,,,,,,,,,,,,,,,,,,
r,,TemperatureSwitchElectricHeaterStatus,,,,,7C03FFFF,,,UCH,0=open;1=closed,,,,,,,,,,,,,,,,,,,,
r,,MultifunctionConnectorInput1Status,,,,,7D03FFFF,,,onoff,,,Multifunction input 1 (ME or X41 terminals): Manual circulation switch-on; PV Ready Warmwater; Cooling Mode,,,,,,,,,,,,,,,,,,
r,,MultifunctionConnectorOutput2Status,,,,,7E03FFFF,,,onoff,,,Multifunction output 2: Circulation pump; anti-legionella pump; zone valve; dehumidifying unit,,,,,,,,,,,,,,,,,,
r,,MultifunctionConnectorOutput0Status,,,,,7F03FFFF,,,onoff,,,Multifunction output 0,,,,,,,,,,,,,,,,,,
r,,CondensorInletTemp,,,,,8103FFFF,,,temps2,10,°C,Condensor inlet temperature (°C),,,,,,,,,,,,,,,,,,
r,,SupplyTempElectricHeater,,,,,8203FFFF,,,temps2,10,°C,Supply temperature electric heater (°C),,,,,,,,,,,,,,,,,,
*r,,,,,,B51A,05,,,IGN:3,,,,,,,,,,,,,,,,,,,,,
r,,FlowPressure,,,,,FF323D,,,D2C,4,bar,,,,,,,,,,,,,,,,,,,
r,,RunningHoursImmersionHeater,,,,,FF3246,,,UIN,,hours,,,,,,,,,,,,,,,,,,,
r,,TotalEnergyUsageImmersionHeater,,,,,FF3249,,,UIN,,kWh,,,,,,,,,,,,,,,,,,,
r,,ImmersionHeaterStarts,,,,,FF324A,,,UIN,,,,,,,,,,,,,,,,,,,,,
r,,PrioritySwitchingValveOps,,,,,FF324B,,,UIN,,,,,,,,,,,,,,,,,,,,,
r,,ImmersionHeaterPower,,,,,FF324C,,,D1B,10,kW,in kW,,,,,,,,,,,,,,,,,,
r,,ImmersionHeaterOutsideTemp,,,,,FF325C,,,temps2,10,°C,,,,,,,,,,,,,,,,,,,
r;w,,MainsBlocktimeMinDuration,,,,,FF3319,,,UCH,,min,Minimum block time duration (in minutes),,,,,,,,,,,,,,,,,,
r;w,,ImmersionHeaterPowerLimit,,,,,FF331A,,,UIN,,kW,,,,,,,,,,,,,,,,,,,
r;w,,MainsBlocktimeMaxDuration,,,,,FF342D,,,UCH,,hrs,Maximum block time duration (in hours),,,,,,,,,,,,,,,,,,
r;w,,HwcMode,,,,,FF3444,,,UCH,0=eco;1=normal;2=balance,,Domestic hot water mod (eco/normal/balance),,,,,,,,,,,,,,,,,,

[chrizzzp]

Btw. I‘m not entirely sure why we‘re reading values belonging to VWZ from HMU?

OK, just thought about it again. I discovered earlier that the vwz pushes some vwz data every 10 seconds to the hmu. So maybe they can then be polled from the hmu...? Check the StatusPushVWZ message below:

hcmode.inc:

*r,,,,,,B511,,,,,,,,,,,,,,,,,,,,,,,,,
*uw,,,,,,B510,,,,,,,,,,,,,,,,,,,,,,,,
uw,,SetOperatingMode,Operation Mode,,,,00,,,hcmode,,,,flowtempdesired,,temp1,,,,hwctempdesired,,temp1,,,,hwcflowtempdesired,,temp1,,,,,,IGN:1,,,,disablehc,,BI0,,,,disablehwctapping,,BI1,,,,disablehwcload,,BI2,,,,,,IGN:1,,,,remoteControlHcPump,,BI0,,,,releaseBackup,,BI1,,,,releaseCooling,,BI2,,,,
r,,Status00,,,,,00,S00_SupplyTemp,,temp,,,,WaterPressure,,press10,,bar,,S00_CompressorModulation,,percent1,,,,CompressorState,,UCH,0=off;1=Heating Prerun;4=Heating;5=Heating Overrun;8=Blocked;21=Water Prerun;24=Water heating;28=Water Blockedxxx;31=deactivated;110=Defrosting,,,HeatingState,,UCH,0=Off;8=Standby;9=Heating,,,field6,,UCH,,,,Defrost,,UCH,0=inactive;32=active,,,S00_CompressorPower,,percent1,,,
r,,Status01,Vorlauftemperatur/Rücklauftemperatur/Aussentemperatur/WW Temperatur/Speichertemperatur/Pumpenstatus,,,,01,,,temp1:supply;temp1:return;temp2:outdoortemp;temp1:dhwtemp;temp1:cyltemp;pumpstate,,,
r,,Status07,,,,,07,power,,UCH,,%,Compressor power,energy,,energy,10,kWh,daily environmental energy yield,disp1ay_b0_heaterenabled,,BI0,0=off;1=on,,,display_b1,,BI1,0=off;1=on,,,display_b2_backupheater,,BI2,0=off;1=on,,,display_b3,,BI3,0=off;1=on,,,display_b4,,BI4,0=off;1=on,,,display_b5_noisereduction,,BI5,0=off;1=on,,,display_b6_dhwecomode,,BI6,0=off;1=on,,,display_b7,,BI7,0=off;1=on,,,DisplayHeaterMain,,state07heatermode,,,,DisplaySystemPressure,,UCH,30,bar,,DisplayHeaterBackup,,state07heatermode,,,,
*uw,,,,,,"B512",,,,,,,
uw,,StatusPushVWZ,VWZ data pushed every 10s to HMU,,,,11,,,temp:SupplyTemp;temp:ReturnTemp;temp:CondensorOutletTemp;temp:CondensorInletTemp;press10:WaterPressure;flowrate:SystemFlow;UCH;UCH,,
uw,,StatusCirPump,Status circulation pump,,,,00,,,UCH,0=off;100=on,,

[burmistrzak]

I assume you aim to create product-specific hmu configurations as done for the bai devices (gas boilers)?

@chrizzzp If I can get away with just adding some @condition to existing definitions, I‘d rather do that.
It really depends on how much is actually different. I probably start with a HW-specific configuration for our line of aroTHERM (plus) units.

[burmistrzak]

@pulquero Does YieldTotal and all those yearly stats work for you? 👀
For others and myself, a lot of registers are seemingly still unsupported…

[burmistrzak]

As far as I know (in my system) the hmu and vwz have the same PCBs (according to same spare part product number of PCB). So all read/write command can be targeted at both circuits - theoretically - they have the same registers.

@chrizzzp I‘m not entirely sure what’s going on here. Both PCBs might be the same, but clearly perform different functions based on the loaded software and/or coding resistors.

However, the setups can be different (e.g. connection of immersion heater, DCF sensor, water pump to the PCB...) in different products.

AFAIK, external components are always connected to the inside VWZ unit.
It seems plausible that sensor data gets regularly pushed to the outside unit, thus making it (by accident) available to be polled by ebusd?

Here are the registers I read from the vwz (respective hmu registers can be polled but do not deliver respective values and vice versa), the associated devices/sensors are in the vwz:

Do all of them return valid values, i.e. no error?
My theory is that we have found the actual register, when it still returns valid data, even in cases where a function is unsupported (e.g. Fan2 on my unit).

[chrizzzp]

As far as I know (in my system) the hmu and vwz have the same PCBs (according to same spare part product number of PCB). So all read/write command can be targeted at both circuits - theoretically - they have the same registers.

@chrizzzp I‘m not entirely sure what’s going on here. Both PCBs might be the same, but clearly perform different functions based on the loaded software and/or coding resistors.

Well, depends what you mean with different functions. Of course, hmu-specific registers don't make sense to read from the wvz, but - generally- the vwz (VWL, to be precise) is also a heat generator (immersion heater) and therefore can deliver at least some energy/power/flow temp values as the hmu does. The RunData/RunStats registers are good examples of common function:

RunStatsHcHours

hmu: 08b50905540200b90b / 080201b90b44260000 (9796 hours)
vwz:  76b50905540200b90b / 080201b90b34000000 (52 hours)

Other registers read from vwz will return zero or '-' if the corresponding value from the hmu is e.g. specific for compressor (and vice versa).

AFAIK, external components are always connected to the inside VWZ unit. It seems plausible that sensor data gets regularly pushed to the outside unit, thus making it (by accident) available to be polled by ebusd?

I think so.

Here are the registers I read from the vwz (respective hmu registers can be polled but do not deliver respective values and vice versa), the associated devices/sensors are in the vwz:

Do all of them return valid values, i.e. no error?

Yes, all of them return valid (non-zero, non-'-') values.

My theory is that we have found the actual register, when it still returns valid data, even in cases where a function is unsupported (e.g. Fan2 on my unit).

Yes, I think this is correct. So what value do you get if you read the Fan2 registers on your system?

If I try to read a temperature sensor which is not present in my system (but technically could be present) I also get a "valid" answer (usually -99°C corresponding to the response data 22fc).

[burmistrzak]

Well, depends what you mean with different functions. Of course, hmu-specific registers don't make sense to read from the wvz, but - generally- the vwz (VWL, to be precise) is also a heat generator (immersion heater) and therefore can deliver at least some energy/power/flow temp values as the hmu does. The RunData/RunStats registers are good examples of common function:

Ah, I now see what you mean! Makes sense to use the same registers for similar things. 😊

Yes, all of them return valid (non-zero, non-'-') values.

Perfect!

Yes, I think this is correct. So what value do you get if you read the Fan2 registers on your system?

Here’s what I get:

hmu Fan1Starts = f108b51a0405ff3452 / 0aff0828ae040000000000
hmu RunStatsFan1Starts = 3108b50905540200d80b / 080201d80bae040000
hmu Fan2Starts = f108b51a0405ff345f / 02ff01
hmu RunStatsFan2Starts = 3108b50905540200da0b / 080201da0b00000000

We should probably investigate the RunStats* address space further. Quite interesting stuff like energy integral & Co. might still be hiding there. 👀

[chrizzzp]

We should probably investigate the RunStats* address space further. Quite interesting stuff like energy integral & Co. might still be hiding there. 👀

I agree. A few more were already discovered (currently under review to be included in jonesPD repo):
https://github.com/jonesPD/ebusd-configuration/pull/6/files

I'm sure you know this one from the 08.hmu.csv:

r,,EnergyIntegral,,,,,FF3221,,,integral,,°min,current energy integral in °min,,,,,,,,,,,,,,,,,,

But maybe there is a "high-precision" copy in the RunData range as well...

[burmistrzak]

But maybe there is a "high-precision" copy in the RunData range as well...

@chrizzzp Would be amazing!
With some trial-and-error, I’ve already seen some unknown values, but nothing concrete yet.

I‘ll be logging what parameters my VR940 is periodically requesting, maybe something interesting comes up. 🤞

[john30]

depends on how the presence can be detected

@john30 I was thinking about using the global Scan results to determine whether a system regulator is present on the bus. Would be a sleek way to improve the overall compatibility of the HMU configuration.

Edit: Played around a bit, but unfortunately got stuck... Is it even possible to use@condition() that way?

it is now with the new @conditionExt() as of [email protected]

[burmistrzak]

it is now with the new @conditionExt() as of [email protected]

@john30 Excellent addition, thx!

Edit: How would I negate @conditionExt() to check whether a particular device does not exist on the bus?

[john30]

it is now with the new @conditionExt() as of [email protected]

@john30 Excellent addition, thx!

Edit: How would I negate @conditionExt() to check whether a particular device does not exist on the bus?

negations are not possible at the moment (at all)