Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add baseline support for HW5103 HMUs #472

Closed
wants to merge 14 commits into from

Conversation

burmistrzak
Copy link

@burmistrzak burmistrzak commented Jan 15, 2025

Improves compatibility with modern heat pump HMUs by removing unsupported, outdated, and unreliable registers.
More registers will be added as they are discovered and verified.

Q: Why is a specific definition needed?
A: The default 08.hmu configuration includes a lot of registers that are either no longer supported by modern HMU revisions, or provide lower resolution data. Reading unsupported registers also causes unnecessary traffic on the bus.

Q: Why not use conditions in 08.hmu and be done with it?
A: The origin of some problematic registers is hard track down, and the respective product ids are unfortunately mostly unknown. If we can determine these identifiers, 08.hmu will be improved as well.

Q: Why are all VWZ-related registers missing?
A: As far as we know, the HMU is not the actual source of these registers. Consequently, they're removed and will be replaced by a dedicated VWZ/VWZIO configuration with more stable/reliable registers, directly read from the unit itself.

Q: Why are the registers related to (VWZ) standalone-mode missing?
A: See above, but we also currently don't know the correct register to determine whether a system regulator is present.

Setup used for testing & verification:

address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=HMU00;SW=0902;HW=5103", loaded "vaillant/08.hmu.hw5103.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=BASV3;SW=0760;HW=7304", loaded "vaillant/15.basv3.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address 71: master #9
address 76: slave #9, scanned "MF=Vaillant;ID=VWZIO;SW=0902;HW=5103"
address f1: master #10
address f6: slave #10, scanned "MF=Vaillant;ID=NETX3;SW=0124;HW=0404"

@burmistrzak
Copy link
Author

Pinging @chrizzzp, @pulquero, @rmalbrecht, and @JGJ156 for feedback. Would any of you be willing to give this one a try?
If required, I can pre-compile the CSV files for you. 😊

I'm looking to finally get solid baseline support for these newer HMUs merged, so error-free operations is critical.

@chrizzzp
Copy link

chrizzzp commented Jan 16, 2025

@burmistrzak

Good job! Yes, precompiled CSVs would be good.

BTW: What is the suggested way to edit/create the .tsp files?
And how do you compile them? I haven't looked into this too much yet. I just saw there are several tools available...

@burmistrzak
Copy link
Author

burmistrzak commented Jan 16, 2025

Good job! Yes, precompiled CSVs would be good.

@chrizzzp Thx! I‘ll push a separate branch and let you know.

BTW: What is the suggested way to edit/create the .tsp files? And how do you compile them? I haven't looked into this too much yet. I just saw there are several tools available...

Well, a bit of TypeScript knowledge and an up-to-date Node.js installation are required.
You clone the main repo, and install the dependencies with npm install. Once that’s done, use npm run to see what actions are available. To compile some CSVs, npm run compile-en is your friend. 😊
More documentation can be found here: https://github.com/john30/ebusd-configuration/blob/master/guidelines.md#converting-to-csv

While it’s possible to automatically convert CSV to TSP, I prefer to do it manually, using files from the main repo as a template.

@burmistrzak
Copy link
Author

@chrizzzp There you go: https://github.com/burmistrzak/ebusd-configuration/tree/csvgen
You'll need to set outcsv/@ebusd/ebus-typespec as your config directory and reload/restart.

If you want, symlink 15.ctlv2 to 15.basv3. Feature set should probably be similar to what you use now. 😉

@burmistrzak
Copy link
Author

@chrizzzp Can you share which VWZ configuration you’re using?
Also, do SystemPressure, ReturnFlowTemp, SupplyFlowTemp, ReturnTemp, SupplyTemp, and CondensorOutletTemp return usable and/or valid data for you?

On a somewhat related note:
I‘ve investigated the official eBus KNX gateway‘s firmware to see how they‘re do things under the hood.
AFAICT, only support for system regulators is implemented. So it seems like the only sanctioned 3rd-party eBus integration is indeed not allowed to talk with equipment directly.

However, the Vaillant internet gateways do regularly poll the entire system, probably to gather diagnostics?
Fully decoding these messages might yield some interesting results… 👀

@chrizzzp
Copy link

@burmistrzak

@chrizzzp Can you share which VWZ configuration you’re using? Also, do SystemPressure, ReturnFlowTemp, SupplyFlowTemp, ReturnTemp, SupplyTemp, and CondensorOutletTemp return usable and/or valid data for you?

Yes, all work and give valid/reasonable data.
I had previously posted the working part of my 76.vwz00.csv: #407 (comment)

I have a quite bunch of messages still not decoded, are you interested in these as well?

On a somewhat related note: I‘ve investigated the official eBus KNX gateway‘s firmware to see how they‘re do things under the hood. AFAICT, only support for system regulators is implemented. So it seems like the only sanctioned 3rd-party eBus integration is indeed not allowed to talk with equipment directly.

Interesting, but I doesn't surprise me. I think they don't want the people to "mess" with the devices directly. If everything stays under the regime of the system regulator it's sort of safe...

However, the Vaillant internet gateways do regularly poll the entire system, probably to gather diagnostics? Fully decoding these messages might yield some interesting results… 👀

That's what I started with the RunData/RunStats registers... These were all registers polled by the internet gateway.
I'm currently investigating in the b516 registers of the hmu which are polled every night around midnight by the system regulator. But progress is slow...

@chrizzzp
Copy link

You'll need to set outcsv/@ebusd/ebus-typespec as your config directory and reload/restart.

Thanks. I will try these CSVs locally...

@kgeree
Copy link

kgeree commented Jan 17, 2025

hi all,

I thought I give a try to these CSVs, but I get quite a lot of "Unknown" values in home assistant for the following:

CompressorHysteresisCooling
CompressorHysteresisHc
ConsumptionThisYear* energy
currenterror error
DateTime temp2
errorhistory *
Fan2* (thats ok as I have 1 fan unit)
FlowPressure
HcBivalencePoint
HeatCurve
HwcBivalencePoint
HwcChargeHysteresis
HwcModeActive
ImmersionHeaterMode
MaxFlowTemp
MinFlowTemp
RunStatsCompressorHc cycles
RunStatsCompressorHc runtime
RunStatsCompressorHwc cycles
RunStatsCompressorHwc runtime
SetMode hwctempdesired
SetMode hwctempdesired
SourcePressure
SourceTempOutput
State onoff
State state
Status hcmode2
Status press
Status temp
Status01 temp2
Status02 *
Status16 temp
SummerSwitchOffTemp
TargetTempHc
TargetTempHwc
YieldThisYear* energy
YieldTotal energy

see ebusd error log:
ebusd-errors.log

Part of these (if not all?) I'm able to read from 76.vwzio.

I have the following setup:

Vaillant aroTHERM plus VWL 75/6
Vaillant uniTOWER plus VIH QW 190/6E
SensoComfort VRC720 (could be an early version..? as it is identified as 15.720 but seemingly works quite well with the 15.ctlv2 config.
Vaillant VR71 module (within the uniTOWER)
Vaillant RecovAIR 260 behind a VR32 bus coupler
Vaillant VR921 SensoNet

in EBUSd as:

08.hmu HW:5103 SW:0607
76.vwzio HW:5103 SW:0607
15.720 HW:7703 SW:0122
26.vr_71 HW:0503 SW:0104
18.v32 (recovair) HW:9802 SW:0117
f6 (sensonet) HW:5703 SW:4035

@kgeree
Copy link

kgeree commented Jan 17, 2025

sorry...my bad, I've tried with the wrong - 08.hmu, file, not the 08.hmu.hw5103.csv.
With 08.hmu.hw5103.csv, it looks better. The only Unknown values are:

CompressorRuntimeHc
CompressorRuntimeHwc
FlowPressure

ebusd-errors.log

@burmistrzak
Copy link
Author

Yes, all work and give valid/reasonable data.
I had previously posted the working part of my 76.vwz00.csv

From VWZ, ReturnTemp & SupplyTemp returns -99,0 and SupplyFlowTemp is null. What do you see? I‘m using the same register addresses.

I'm currently investigating in the b516 registers of the hmu which are polled every night around midnight by the system regulator. But progress is slow...

@chrizzzp I feel you… 😅
Please share the unknown VWZ registers as well.

I‘ll try to obtain a firmware image for the VR940f, but its update procedure seems to be really locked down. It’s an embedded Linux system, so dumping the flash memory might still be an option…

@JGJ156
Copy link

JGJ156 commented Jan 17, 2025

@burmistrzak regarding:
Pinging @chrizzzp, @pulquero, @rmalbrecht, and @JGJ156 for feedback. Would any of you be willing to give this one a try?

I need to build my knowledge more first, apologies for that. I'll work on some further message definitions.

@chrizzzp
Copy link

chrizzzp commented Jan 17, 2025

sorry...my bad, I've tried with the wrong - 08.hmu, file, not the 08.hmu.hw5103.csv. With 08.hmu.hw5103.csv, it looks better. The only Unknown values are:

CompressorRuntimeHc
CompressorRuntimeHwc
FlowPressure

Interesting, on my Arotherm Split system (ID=HMU00;SW=0902;HW=5103) they work:


3108b511021801 / 090044720100ee040000
3108b511021802 / 0900d109000006000000
3108b51a0405ff323d / 0aff082c74000000000000

@kgeree
Copy link

kgeree commented Jan 17, 2025

ID=HMU00;SW=0902;HW=5103

Might be due to the different SW version.. mine is: HW:5103 SW:0607

@burmistrzak
Copy link
Author

burmistrzak commented Jan 17, 2025

@kgeree Thx, for trying! 🙏
These unknown registers might indeed be model-specific (mono vs split), so I‘ll likely add a @condition to fix that.
Are you using the entire, pre-compiled config directory? #472 (comment)
Be aware that HASS might still display old/cached values, so checking MQTT directly is the safest option.

Edit: The aforementioned registers should work with aroTHERM plus. Please do not cherry-pick generated CSVs, instead point ebusd to outcsv/@ebusd/ebus-typespec. Otherwise, new template definitions will be missing.

@kgeree
Copy link

kgeree commented Jan 17, 2025

Please do not cherry-pick generated CSVs, instead point ebusd to outcsv/@ebusd/ebus-typespec. Otherwise, new template definitions will be missing.

I did.. see my 2nd comment. I also removed all ebusd devices from HA before loaded the new config. With that, I gave these unknown values still:
CompressorRuntimeHc
CompressorRuntimeHwc
FlowPressure

@burmistrzak
Copy link
Author

I did.. see my 2nd comment. I also removed all ebusd devices from HA before loaded the new config. With that, I gave these unknown values still: CompressorRuntimeHc CompressorRuntimeHwc FlowPressure

@kgeree Ha, interesting! Can you please try the following on your ebusd host (and share your results):

root@da3c40df8d5d:/# ebusctl hex 08b511021801

@burmistrzak burmistrzak changed the title Add baseline support for 08.hmu.HW5103 Add baseline support for HW5103 HMU & VWZ Jan 17, 2025
@kgeree
Copy link

kgeree commented Jan 17, 2025

I did.. see my 2nd comment. I also removed all ebusd devices from HA before loaded the new config. With that, I gave these unknown values still: CompressorRuntimeHc CompressorRuntimeHwc FlowPressure

@kgeree Ha, interesting! Can you please try the following on your ebusd host (and share your results):

root@da3c40df8d5d:/# ebusctl hex 08b511021801

not sure if I did that right, as I'm running it in HA and connection to it via TCP, with that I can read HEX using:

read -h 08b511021801
00

read -h 08b511021802
00

read -h 08b51a0405ff323d
02ff01

@burmistrzak
Copy link
Author

@kgeree Huh, seems indeed to be related to software version.
Can you share your product Ids? Like e.g.:

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

@kgeree
Copy link

kgeree commented Jan 17, 2025

find | grep -i scan

Scan Id = no data stored
scan.08  = Vaillant;HMU00;0607;5103
Scan.08 Id = 21;21;25;0010023443;1610;005293;N8
scan.15  = Vaillant;72000;0122;7703
Scan.15 Id = 21;21;17;0020260915;0953;007771;N9
scan.18  = Vaillant;V32;0117;9802
Scan.18 Id = 21;21;17;0010016046;0001;005161;N9
scan.26  = Vaillant;VR_71;0104;0503
Scan.26 Id = 21;21;30;0020184848;0082;007340;N9
scan.76  = Vaillant;VWZIO;0607;5103
Scan.76 Id = 21;21;21;0010022081;3100;005398;N2
scan.f6  = Vaillant;NETX2;4035;5703
Scan.f6 Id = 21;21;25;0020260962;0938;027622;N2

@burmistrzak
Copy link
Author

@kgeree Alright, I‘ll update the definition.
In the meantime, can you try this:

root@da3c40df8d5d:/# ebusctl hex 08b51405052a03ffff

@chrizzzp
Copy link

chrizzzp commented Jan 17, 2025

@burmistrzak

Huh, seems indeed to be related to software version.

Yes, very likely. I once had the PCB replaced in my hmu unit by a Vaillant service engineer. The new PCB had a newer firmware version (SW=0902) then the replaced (SW=06xx don't remember).
There are indications that newer firmwares allow aquisition of more data from the hmu, maybe because new registers are introduced. See here:
#330 (comment)

@chrizzzp
Copy link

@burmistrzak

From VWZ, ReturnTemp & SupplyTemp returns -99,0 and SupplyFlowTemp is null. What do you see? I‘m using the same register addresses.

vwz00 ReturnTemp = 32.1
vwz00 SupplyTemp = 32.1
vwz00 RunDataSupplyFlowTemp = 32.1505

Differences could be explained by the fact that VWZIO and VWZ00 are not the same products...

Please share the unknown VWZ registers as well.

Here you go (all currently commented as not actively polled, many are actually hmu-specific):

*r,,,,,,B509,,,,,,,,,,,,,,,,,,,,,,,,,
#r,,unknownMB509h2802,,,,,2802,,,HEX:*,,,,,,,,,,,,,,,,,,,,,
## Polls from VR921 every 10 mins
*r,,,,,,B509,54,,,IGN:4,,,,,,,,,,,,,,,,,,,,,
#r,,vUnknown0C05,,,,,02000C05,,,HEX:*,,
#r,,vUnknown0D08,,,,,02000D08,,,HEX:*,,
#r,,RunDataCompressorSpeed,(konstant 0),,,,02000D0A,,,tempv,,
#r,,RunDataEEVPositionAbs,,,,,280A,,,UIN,,,,,,,,,,,,,,,,,,,,,
#r,,RunDataFan1Speed,(konstant 0),,,,0200470A,,,HEX:*,,
#r,,RunDataFan2Speed,(konstant 0),,,,0200490A,,,HEX:*,,
#r,,vUnknown490D,(konstant 0),,,,0200490D,,,D1B,,
#r,,RunDataFlowTempDesired,,,,,02004A0D,,,tempv,,,,,,,,,,,,,,,,,,,,,
#r,,RunDataStatuscode,(no data vwz),,,,530D,,,scode;IGN:*,,,,,,,,,,,,,,,,,,,,,
#r,,vUnknown560D,,,,,0200560D,,,HEX:*,,
#r,,RunDataCurrentConsumedPower,(no data vwz),,,,02005B0D,,,powerv,,,current consumed electrical power (Watt),,,,,,,,,,,,,,,,,,
#r,,RunDataHighPressure,(no data vwz),,,,02006A09,,,pressv,,
#r,,RunDataunknown7c08,,,,,02007C08,,,EXP,,
#r,,RunDataCompressorInletTemp,,,,,9808,,,tempv,,,,,,,,,,,,,,,,,,,,,
#r,,RunDataCompressorOutletTemp,(no data vwz),,,,A208,,,tempv,,,from VR921 to HMU,,,,,,,,,,,,,,,,,,
#r,,RunDataCondensationTemp,,,,,0200A60E,,,tempv,,
#r,,RunDataEEVOutletTemp,(no data vwz),,,,AC08,,,tempv,,,,,,,,,,,,,,,,,,,,,
#r,,vUnknownBA09,(konstant 0),,,,0200BA09,,,EXP,,
#r,,vUnknownBB0B,,,,,0200BB0B,,,UIN;IGN:2,,
#r,,RunDataJDeltaPPumpUnknown,,,,,0200BC09,,,EXP,,,,,,,,,,,,,,,,,,,,,
#r,,RunstatsHwcHours,,,,,0200BC0B,,,UIN;IGN:2,,hours
#r,,RunDataJWaterThroughPut,,,,,0200BD09,,,EXP,,,,,,,,,,,,,,,,,,,,,
#r,,RunStatsCompressorHours,(konstant 0),,,,0200C20B,,,UIN;IGN:2,,
#r,,RunStatsCompressorStarts,,,,,0200C30B,,,UIN;IGN:2,,
#r,,RunStats4PortValveHours,,,,,0200C80B,,,UIN;IGN:2,,hours
#r,,RunStats4PortValveSwitches,(no data vwz),,,,0200C90B,,,cntstarts2;IGN:2,,
#r,,RunStatsFan1Hours,,,,,0200D70B,,,UIN;IGN:2,,
#r,,RunStatsFan1Starts,,,,,0200D80B,,,UIN;IGN:2,,
#r,,RunStatsFan2Hours,,,,,0200D90B,,,UIN;IGN:2,,
#r,,RunStatsFan2Starts,,,,,0200DA0B,,,UIN;IGN:2,,
#r,,RunDataAirIntakeTemp,(no data vwz),,,,DE08,,,tempv,,,,,,,,,,,,,,,,,,,,,
#r,,vUnknownE10B,,,,,0200E10B,,,UIN;IGN:2,,
#r,,vUnknownE20B,,,,,0200E20B,,,UIN;IGN:2,,
#r,,vUnknownE30B,,,,,0200E30B,,,UIN;IGN:2,,
#r,,vUnknownE40B,,,,,0200E40B,,,UIN;IGN:2,,
#r,,vUnknownE50B,,,,,0200E50B,,,UIN;IGN:2,,
#r,,vUnknownE60B,,,,,0200E60B,,,UIN;IGN:2,,
#r,,vUnknownEA0C,(konstant 0),,,,0200EA0C,,,HEX:*,,
# Status message for hydraulics,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
#*uw,,,,,,B512,,,,,,,,,,,,,,,,,,,,,,,,,
#uw,,StatusHydraulicsVWZ,,,,,1300,Pressure,m,UCH,10,bar,Systemdruck,Flow,m,UIN,,l/h,Durchflussrate,Unknown,m,UCH,,,,,,,,,
*r,,,,,,B512,,,,,,,,,,,,,,,,,,,,,,,,,
#r,,vUnknownB512_201,,,,,0F0201,,,UCH;UCH;UCH;temp;press10;UCH,,
*r,,,,,,B516,,,,IGN:1,,,,,,,,,,,,,,,,,,,,,
#r,,vUnknownB516_11,,,,,11,,,HEX:*,,
#r,,vUnknownB516_x1,,,,,1000ffff0305212e,,,HEX:*,,
#r,,vUnknownB516_x2,,,,,1000ffff49040000,,,HEX:*,,
#r,,vUnknownB516_x3,,,,,1002ffff0305412f,,,HEX:*,,
#r,,vUnknownB516_x4,,,,,1003ffff0305212c,,,HEX:*,,

Maybe we should create a different PR for the vwz?

@burmistrzak burmistrzak changed the title Add baseline support for HW5103 HMU & VWZ Add baseline support for HW5103 HMUs Jan 18, 2025
@burmistrzak
Copy link
Author

@chrizzzp Yes, dedicated VWZ/VWZIO configuration coming soon. We first have to cleanup the HMU clutter. 😅

@burmistrzak
Copy link
Author

@kgeree I‘ve generated a new set of CSVs. Shouldn’t throw errors anymore.
You might have to refresh HASS to see results.

@kgeree
Copy link

kgeree commented Jan 20, 2025

@kgeree I‘ve generated a new set of CSVs. Shouldn’t throw errors anymore. You might have to refresh HASS to see results.

yes, seems its working as intended. the properties are not showing up for me anymore.

@burmistrzak
Copy link
Author

@kgeree Great!
I‘ll try to find some alternative registers that are more widely supported, but provide similar data.

@burmistrzak
Copy link
Author

burmistrzak commented Jan 22, 2025

@chrizzzp Here're all (?) HMU register blocks that can be considered safe for polling.
I found them by logging everything the VR 940f was requesting.

In these four blocks (B509, B511, B516, B51A), we still have a few mysteries to uncover.
Everything else (e.g. B514) should probably be considered harmful and not polled by default.

Thankfully, Energy Integral is at FF3221 in the B51A block.
So there's no need for polling unsafe registers. 😄

08.hmu

QQ ZZ PBSB NN  DD            / NN DD

B509
f1 08 b509 05  54 02 00 0609 / 08 02_01 06-09 a4 84 0c 42   RunDataReturnTemp3digits
f1 08 b509 05  54 02 00 850b / 06 02_01 85-0b 22 00
f1 08 b509 05  54 02 00 f709 / 05 02_01 f7-09 01
f1 08 b509 05  54 02 00 4e0d / 05 02_01 4e-0d 00
f1 08 b509 05  54 02 00 040a / 05 02_01 04-0a 00
f1 08 b509 05  54 02 00 5e0f / 05 02_01 5e-0f 28
f1 08 b509 05  54 02 00 190a / 05 02_01 19-0a 00
f1 08 b509 05  54 02 00 e60b / 08 02_01 e6-0b 41 00 00 00
f1 08 b509 05  54 02 00 e50b / 08 02_01 e5-0b d9 0b 00 00   RunDataHCHours
f1 08 b509 05  54 02 00 e40b / 08 02_01 e4-0b d5 00 00 00
f1 08 b509 05  54 02 00 e30b / 08 02_01 e3-0b 23 00 00 00
f1 08 b509 05  54 02 00 e20b / 08 02_01 e2-0b 00 00 00 00
f1 08 b509 05  54 02 00 e10b / 08 02_01 e1-0b 00 00 00 00
f1 08 b509 05  54 02 00 a60e / 08 02_01 a6-0e 00 29 2b 42   RunDataFlowTemp
f1 08 b509 05  54 02 00 a90e / 08 02_01 a9-0e fc 71 a2 40   RunDataOverheatingActualValue
f1 08 b509 05  54 02 00 a70e / 08 02_01 a7-0e c0 5c c4 c0   RunDataEvaporationTemp
f1 08 b509 05  54 02 00 a80e / 08 02_01 a8-0e 00 00 00 00
f1 08 b509 05  54 02 00 560d / 0e 02_01 56-0d ff ff ff ff ff ff ff ff ff ff

B511
f1 08 b511 01  00    / 09 c2 01 0c 85 6e 09 00 20 6f   SetMode hcmode_inc
f1 08 b511 02  18 03 / 09 00 00 00 00 00 00 00 00 00
f1 08 b511 01  01    / 09 49 42 00 80 ff ff 01 00 ff   Status01 hcmode_inc (supply, return, etc.)

B516
f1 08 b516 01  14                    / 09 01 ab 31 51 44 00 00 00 00

B516
f1 08 b516 08  10 00 ff ff 84 030000 / 0b 10-00-ff-84-03 36_32 00 00 00 00
f1 08 b516 08  10 00 ff ff 84 040000 / 0b 10-00-ff-84-04 36_32 00 00 00 00
f1 08 b516 08  10 00 ff ff 83 030000 / 0b 00_00 00 83-03 36_32 73 85 9d 49
f1 08 b516 08  10 00 ff ff 83 040000 / 0b 00_00 03 83-04 36_32 bc 5e 1b 49
f1 08 b516 08  10 00 ff ff 83 050000 / 0b 00_00 06 83-05 36_32 00 00 00 00
f1 08 b516 08  10 00 ff ff 42 030000 / 0b 00_00 01 42-03 36_32 a1 3f 40 4a
f1 08 b516 08  10 00 ff ff 42 040000 / 0b 00_00 04 42-04 36_32 24 16 66 49
f1 08 b516 08  10 00 ff ff 42 050000 / 0b 00_00 07 42-05 36_32 00 00 00 00
f1 08 b516 08  10 00 ff ff 49 030000 / 0b 00_00 02 49-03 36_32 ca af 7f 4a
f1 08 b516 08  10 00 ff ff 49 040000 / 0b 00_00 05 49-04 36_32 eb 24 bc 49
f1 08 b516 08  10 00 ff ff 49 050000 / 0b 00_00 08 49-05 36_32 00 00 00 00

B51A
f1 08 b51a 04  05 ff32 24 / 0a ff 08 35 0a 00 00 00 00 00 00   CurrentConsumedPower
f1 08 b51a 04  05 ff32 41 / 0a ff 08 27 95 09 00 00 00 00 00   HcHours
f1 08 b51a 04  05 ff32 44 / 0a ff 08 27 19 02 00 00 00 00 00   HwcHours
f1 08 b51a 04  05 ff34 21 / 0a ff 02 25 3c 00 1e 00 64 00 05   EnergyIntegralStartCooling
f1 08 b51a 04  05 ff32 43 / 0a ff 08 27 00 00 00 00 00 00 00   CoolingHours
f1 08 b51a 04  05 ff32 40 / 0a ff 08 27 58 0c 00 00 00 00 00   TotalHours
f1 08 b51a 04  05 ff32 22 / 02 ff 01                           SourceTempInput
f1 08 b51a 04  05 ff32 27 / 02 ff 01                           SourceTempOutput
f1 08 b51a 04  05 ff34 00 / 0a ff 08 27 1b 08 00 00 00 00 00   CompressorHours
f1 08 b51a 04  05 ff34 01 / 0a ff 08 28 96 03 00 00 00 00 00   CompressorStarts
f1 08 b51a 04  05 ff32 4b / 02 ff 01                           PrioritySwitchingValveOps
f1 08 b51a 04  05 ff34 44 / 0a ff 02 00 00 00 00 00 02 00 01   HwcMode
f1 08 b51a 04  05 ff32 4a / 02 ff 01                           ImmersionHeaterStarts
f1 08 b51a 04  05 ff32 46 / 02 ff 01                           ImmersionHeaterHours
f1 08 b51a 04  05 ff34 5f / 02 ff 01                           Fan2Starts
f1 08 b51a 04  05 ff34 5e / 02 ff 01                           Fan2Hours
f1 08 b51a 04  05 ff34 07 / 0a ff 08 28 62 01 00 00 00 00 00   FourPortValveSwitches
f1 08 b51a 04  05 ff34 06 / 0a ff 08 27 16 00 00 00 00 00 00   FourPortValveHours
f1 08 b51a 04  05 ff34 1f / 0a ff 02 2d 84 03 c8 00 84 03 0a   BuildingCircuitMaxPressureDifference
f1 08 b51a 04  05 ff34 03 / 0a ff 08 28 3e 00 00 00 00 00 00   BuildingPumpStarts
f1 08 b51a 04  05 ff34 02 / 0a ff 08 27 e6 0b 00 00 00 00 00   BuildingPumpHours

@chrizzzp
Copy link

@burmistrzak

Thanks. Here are my comments...

08.hmu

QQ ZZ PBSB NN DD / NN DD

B509
f1 08 b509 05 54 02 00 850b / 06 02_01 85-0b 22 00
f1 08 b509 05 54 02 00 f709 / 05 02_01 f7-09 01
f1 08 b509 05 54 02 00 4e0d / 05 02_01 4e-0d 00
f1 08 b509 05 54 02 00 040a / 05 02_01 04-0a 00
f1 08 b509 05 54 02 00 5e0f / 05 02_01 5e-0f 28
f1 08 b509 05 54 02 00 190a / 05 02_01 19-0a 00
f1 08 b509 05 54 02 00 e60b / 08 02_01 e6-0b 41 00 00 00

I will be tracking these to find out what data they contain.

f1 08 b509 05 54 02 00 e50b / 08 02_01 e5-0b d9 0b 00 00 RunDataHCHours

This is probably if different hour counter, not for HC mode, so far unknown: see here: jonesPD#6 (comment)

f1 08 b509 05 54 02 00 e40b / 08 02_01 e4-0b d5 00 00 00
f1 08 b509 05 54 02 00 e30b / 08 02_01 e3-0b 23 00 00 00
f1 08 b509 05 54 02 00 e20b / 08 02_01 e2-0b 00 00 00 00
f1 08 b509 05 54 02 00 e10b / 08 02_01 e1-0b 00 00 00 00

I will be tracking these, too.

f1 08 b509 05 54 02 00 a60e / 08 02_01 a6-0e 00 29 2b 42 RunDataFlowTemp

This is actually CondensationTemp, see here: jonesPD#6 (comment)

f1 08 b509 05 54 02 00 a90e / 08 02_01 a9-0e fc 71 a2 40 RunDataOverheatingActualValue
f1 08 b509 05 54 02 00 a70e / 08 02_01 a7-0e c0 5c c4 c0 RunDataEvaporationTemp

f1 08 b509 05 54 02 00 a80e / 08 02_01 a8-0e 00 00 00 00

On my system this one gives a 4-byte answer, with no data.
08b50905540200080e / 040208080e

f1 08 b509 05 54 02 00 560d / 0e 02_01 56-0d ff ff ff ff ff ff ff ff ff ff

same for my system.

B511
f1 08 b511 01 00 / 09 c2 01 0c 85 6e 09 00 20 6f SetMode hcmode_inc
f1 08 b511 02 18 03 / 09 00 00 00 00 00 00 00 00 00
f1 08 b511 01 01 / 09 49 42 00 80 ff ff 01 00 ff Status01 hcmode_inc (supply, return, etc.)

B516
f1 08 b516 01 14 / 09 01 ab 31 51 44 00 00 00 00

This is the current electrical consumption in Watt (quite interesting as you can also see small standby-consumptions):

*r,,,,,,B516,,,,IGN:1,,,,,,,,,,,,,,,,,,,,,
r,,CurrentConsumedPowerWatt,(polled from VR921),,,,14,,,EXP,,,current consumed electrical power (Watt),,,,,,,,,,,,,,,,,,

B516
f1 08 b516 08 10 00 ff ff 84 030000 / 0b 10-00-ff-84-03 36_32 00 00 00 00
f1 08 b516 08 10 00 ff ff 84 040000 / 0b 10-00-ff-84-04 36_32 00 00 00 00
f1 08 b516 08 10 00 ff ff 83 030000 / 0b 00_00 00 83-03 36_32 73 85 9d 49
f1 08 b516 08 10 00 ff ff 83 040000 / 0b 00_00 03 83-04 36_32 bc 5e 1b 49
f1 08 b516 08 10 00 ff ff 83 050000 / 0b 00_00 06 83-05 36_32 00 00 00 00
f1 08 b516 08 10 00 ff ff 42 030000 / 0b 00_00 01 42-03 36_32 a1 3f 40 4a
f1 08 b516 08 10 00 ff ff 42 040000 / 0b 00_00 04 42-04 36_32 24 16 66 49
f1 08 b516 08 10 00 ff ff 42 050000 / 0b 00_00 07 42-05 36_32 00 00 00 00
f1 08 b516 08 10 00 ff ff 49 030000 / 0b 00_00 02 49-03 36_32 ca af 7f 4a
f1 08 b516 08 10 00 ff ff 49 040000 / 0b 00_00 05 49-04 36_32 eb 24 bc 49
f1 08 b516 08 10 00 ff ff 49 050000 / 0b 00_00 08 49-05 36_32 00 00 00 00

These are interesting, maybe they contain the energy statistics. Could you check when (and how often) these data are polled?

B51A
...

@burmistrzak
Copy link
Author

burmistrzak commented Jan 23, 2025

@chrizzzp Excellent additional context! 💪

These are interesting, maybe they contain the energy statistics. Could you check when (and how often) these data are polled?

Sure thing!
AFAICT, e.g. f1 08 b516 08 10 00 ff ff 49 030000 is polled every hour, with the most recent answer being 0b 00_00 02 49-03 37_32 0b 6b 82 4a

These three bytes seem to be the actual value: 0b 6b 82
Values from the previous hex dump: ca af 7f

Edit: I’m not entirely sure about the trailing 4a, might be part of the message…

@burmistrzak
Copy link
Author

@chrizzzp According to this document, the B509 block was/is used for diagnostics.

So it would make sense for these registers to be higher resolution and provide human-friendly null values when they’re supposed to be read by technicians, either on-site or remotely via gateway.

Registers mainly used for communications between units don’t necessarily need to look pretty.
Real eBus devices seemingly can handle the “correct register address, but not available/supported“ response of 02 ff 01, while ebusd simply throws an error.
A response of 00 probably means that the register is empty.

If we could take a closer look at the latest diagnostics software, we would likely be able to decode many more registers quite quickly… 😏

@chrizzzp
Copy link

chrizzzp commented Jan 24, 2025

@burmistrzak

According to this document, the B509 block was/is used for diagnostics.

Interesting document, didn't know this one yet. Will have a close look...

If we could take a closer look at the latest diagnostics software, we would likely be able to decode many more registers quite quickly… 😏

I think the software is called ServiceDialog, but it's not freely available, of course.

@burmistrzak
Copy link
Author

@chrizzzp Yes, it’s indeed called serviceDIALOG. They even have a fancy, magnetic eBus adapter (VR 15) of their own.

@burmistrzak
Copy link
Author

Real eBus devices seemingly can handle the “correct register address, but not available/supported“ response of 02 ff 01, while ebusd simply throws an error.
A response of 00 probably means that the register is empty.

@john30 There’s currently no option for such error handing in ebus-typespec, right? 👀

@john30
Copy link
Owner

john30 commented Jan 25, 2025

@chrizzzp According to this document, the B509 block was/is used for diagnostics.

no, b509 is mainly for reading/writing configuration registers

Registers mainly used for communications between units don’t necessarily need to look pretty. Real eBus devices seemingly can handle the “correct register address, but not available/supported“ response of 02 ff 01, while ebusd simply throws an error. A response of 00 probably means that the register is empty.

an empty response (with length of zero) usually means that the device does not support the register at all, whereas a default value (like ff01) still might have some information

@john30
Copy link
Owner

john30 commented Jan 25, 2025

Real eBus devices seemingly can handle the “correct register address, but not available/supported“ response of 02 ff 01, while ebusd simply throws an error.
A response of 00 probably means that the register is empty.

@john30 There’s currently no option for such error handing in ebus-typespec, right? 👀

this would rather mean to extend ebusd to handle empty responses in a different way. not related to the models in typespec from my point of view. and anyway, if a device does not support the model, then it is basically misplaced in the tsp and should be subject to some condition

@burmistrzak
Copy link
Author

no, b509 is mainly for reading/writing configuration registers

@john30 True, but manual configuration and/or diagnostics by technicians seems to be the most probable use case. Quoting the aforementioned document (p. 60):

The Get Device Configuration or Status command is used for requesting specific data from other eBus
devices. It is used by vrDialog software to read and display device configuration and status data on the
screen, or set device parameters. Each device has a number of parameters that can be read or set using this
command.

Device-to-device communication during normal operations appears to happen exclusively within other register blocks.

an empty response (with length of zero) usually means that the device does not support the register at all, whereas a default value (like ff01) still might have some information

That’s what I‘ve observed as well.
Zero length response means entirely unsupported.
The special response code ff01 likely means the register address is correct, but the function not supported by a specific device variant/mode.
Practical example: uniTOWER plus and aroTHERM plus share the same type of HMU board, but in different modes (probably configured via coding resistors). Trying to read ImmersionHeaterStarts from the outside unit will produce a ff01 response. The same request works just fine when addressed to the uniTOWER, where the immersion heater unit is actually connected.

@burmistrzak
Copy link
Author

this would rather mean to extend ebusd to handle empty responses in a different way. not related to the models in typespec from my point of view. and anyway, if a device does not support the model, then it is basically misplaced in the tsp and should be subject to some condition

@john30 Alright, so for some registers we already know the corresponding b509 block address, which provide valid/usable data even if a specific function (single fan vs. dual fan units) is not available.
The main downside of regular blocks like b51a is that they can return ff01, requiring conditions to work properly with all systems. Unfortunately, we don’t yet know enough product IDs to make this reliable.

My approach therefore is to prioritize registers from b509 wherever possible, as they seem to be more standardized across product revisions. Sounds good?

@chrizzzp
Copy link

@burmistrzak Some (not too interesting) preliminary results from tracking the b509 registers for some days (polling interval was 5 minutes):

B509
f1 08 b509 05 54 02 00 0609 / 08 02_01 06-09 a4 84 0c 42 RunDataReturnTemp3digits

This value I have to read from the vwz00 to get the return temperature (datatype EXP):

76b509055402000609 / 0802010609c6180942

When polled from the hmu I get:

08b509055402000609 / 0802010609ffffff7f.

So the reply ffffff7f means something like 'read is valid, but value not available from this circuit'. I get the same vice versa for values the hmu delivers (and vwz00 not).

f1 08 b509 05 54 02 00 850b / 06 02_01 85-0b 22 00

These values (assumed datatype UIN) remained constant the whole time: 30 (hmu) and 2028 (vwz00)

f1 08 b509 05 54 02 00 f709 / 05 02_01 f7-09 01

These binary values (UCH, 0=off, 1=on) also remained constant the whole time: on (hmu) and off (vwz00).

f1 08 b509 05 54 02 00 4e0d / 05 02_01 4e-0d 00

Same here, these binary values (UCH, 0=off, 1=on) also remained constant the whole time: on (hmu) and off (vwz00).

f1 08 b509 05 54 02 00 040a / 05 02_01 04-0a 00

These binary values (UCH, 0=off, 1=on) also remained constant the whole time: off (hmu and vwz00).

f1 08 b509 05 54 02 00 5e0f / 05 02_01 5e-0f 28

These values (assumed data type UCH) also remained constant the whole time: 40 (hmu and vwz00).

f1 08 b509 05 54 02 00 190a / 05 02_01 19-0a 00

The only interesting find: this binary value (UCH, 0=off, 1=on) from the hmu changes to on during de-icing of the hmu. Could be some sort of status of the 4-way-valve (outside unit). All other times it's off (vzw00 always off).

f1 08 b509 05 54 02 00 e60b / 08 02_01 e6-0b 41 00 00 00
f1 08 b509 05 54 02 00 e50b / 08 02_01 e5-0b d9 0b 00 00 RunDataHCHours
f1 08 b509 05 54 02 00 e40b / 08 02_01 e4-0b d5 00 00 00
f1 08 b509 05 54 02 00 e30b / 08 02_01 e3-0b 23 00 00 00
f1 08 b509 05 54 02 00 e20b / 08 02_01 e2-0b 00 00 00 00
f1 08 b509 05 54 02 00 e10b / 08 02_01 e1-0b 00 00 00 00

These registers all seem to count hours. I had tracked them previously, but so far could not assign them to any particular process/funtion:

*r,,,,,,B509,,,,,,,,,,,,,,,,,,,,,,,,,
r,,unknownMB509hE10B,,,,,E10B,,,UIN;IGN:2,,hours,Unknown from VR921 to HMU,,,,,,,,,,,,,,,,,,
r,,unknownMB509hE20B,,,,,E20B,,,UIN;IGN:2,,hours,Unknown from VR921 to HMU,,,,,,,,,,,,,,,,,,
r,,unknownMB509hE30B,,,,,E30B,,,UIN;IGN:2,,hours,Unknown from VR921 to HMU,,,,,,,,,,,,,,,,,,
r,,unknownMB509hE40B,,,,,E40B,,,UIN;IGN:2,,hours,Unknown from VR921 to HMU,,,,,,,,,,,,,,,,,,
r,,unknownMB509hE50B,,,,,E50B,,,UIN;IGN:2,,hours,Unknown from VR921 to HMU,,,,,,,,,,,,,,,,,,
r,,unknownMB509hE60B,,,,,E60B,,,UIN;IGN:2,,hours,Unknown from VR921 to HMU,,,,,,,,,,,,,,,,,,

f1 08 b509 05 54 02 00 a80e / 08 02_01 a8-0e 00 00 00 00

Contrary to one of my previous comments (where I had a type in the address), this register does return a value (so far 0 both for hmu and vwz00). Will track it...

08b50905540200a80e / 080201a80e00000000
76b50905540200a80e / 080201a80e00000000

@burmistrzak
Copy link
Author

f1 08 b509 05 54 02 00 0609 / 08 02_01 06-09 a4 84 0c 42 RunDataReturnTemp3digits

This value I have to read from the vwz00 to get the return temperature (datatype EXP):

76b509055402000609 / 0802010609c6180942

When polled from the hmu I get:

08b509055402000609 / 0802010609ffffff7f.

So the reply ffffff7f means something like 'read is valid, but value not available from this circuit'. I get the same vice versa for values the hmu delivers (and vwz00 not).

@chrizzzp Seems very plausible. For me, HMU has the return temperature, not VWZ.

f1 08 b509 05 54 02 00 850b / 06 02_01 85-0b 22 00

These values (assumed datatype UIN) remained constant the whole time: 30 (hmu) and 2028 (vwz00)

Have to check…

f1 08 b509 05 54 02 00 f709 / 05 02_01 f7-09 01

These binary values (UCH, 0=off, 1=on) also remained constant the whole time: on (hmu) and off (vwz00).

Same.

f1 08 b509 05 54 02 00 4e0d / 05 02_01 4e-0d 00

Same here, these binary values (UCH, 0=off, 1=on) also remained constant the whole time: on (hmu) and off (vwz00).

Here, both are off. 👀

f1 08 b509 05 54 02 00 040a / 05 02_01 04-0a 00

These binary values (UCH, 0=off, 1=on) also remained constant the whole time: off (hmu and vwz00).

Same.

f1 08 b509 05 54 02 00 5e0f / 05 02_01 5e-0f 28

These values (assumed data type UCH) also remained constant the whole time: 40 (hmu and vwz00).

Have to check…

f1 08 b509 05 54 02 00 190a / 05 02_01 19-0a 00

The only interesting find: this binary value (UCH, 0=off, 1=on) from the hmu changes to on during de-icing of the hmu. Could be some sort of status of the 4-way-valve (outside unit). All other times it's off (vzw00 always off).

Looks like it’s indeed a status flag. Nice find!

AFAICT, the b509 NN 54 02 00 DDDD block seems to be read only, so polling random addresses should be somewhat safe. 🤞

@burmistrzak burmistrzak deleted the add-hmu-hw5103 branch January 27, 2025 16:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants