Add support for HW5103 HMUs

[burmistrzak]

Follow-up for #472 to ensure changes stay in their own branch.

Please see the original PR for FAQ.

[burmistrzak]

@kgeree Had to do some cleanup to keep different PRs separate. 😅
You'll find the latest patches here, and pre-compiled CSVs here.
Simply clone the repo, switch to the csvgen branch, point ebusd to ebusd-configuration/outcsv/@ebusd/ebus-typespec, and reload.

[burmistrzak]

@chrizzzp Feel free to give this one a try.
Also, does SourceTempInput work for you?

[kgeree]

@kgeree Had to do some cleanup to keep different PRs separate. 😅 You'll find the latest patches here, and pre-compiled CSVs here. Simply clone the repo, switch to the csvgen branch, point ebusd to ebusd-configuration/outcsv/@ebusd/ebus-typespec, and reload.

thanks, I gave it a try and looks quite nice.

A few comments:

1. I see there is "CurrentPowerConsumption" and also "CurrentConsumedPower" - whats the difference? I get "Unknown" for "CurrentPowerConsumption"
   

2. I see still "hwc" instead of DHW in "Status" and "Statuscode". 

3. Can we remove the "value" suffix for the values? At least in HomeAssistant it looks ugly - and useless...
   
   (also would be applicable for other CSVs (700,720,ctlv*,basv*...)

Otherwise nice work on cleaning this up so far! Thx!

[chrizzzp]

@burmistrzak

Also, does SourceTempInput work for you?

No, all "Source"-related definitions don't work on my system. I guess these values are relevant only for geothermal heat pumps?

*r,,,,,,B51A,05,,,IGN:3,,,,,,,,,,,,,,,,,,,,,
r,,SourceTempInput,,,,,FF3222,,,D2C,,°C,,,,,,,,,,,,,,,,,,,
r,,SourceTempOutput,,,,,FF3227,,,D2C,,°C,,,,,,,,,,,,,,,,,,,
r,,SourcePressure,,,,,FF323E,,,D2C,4,bar,,,,,,,,,,,,,,,,,,,

[chrizzzp]

@kgeree @burmistrzak

1. I see there is "CurrentPowerConsumption" and also "CurrentConsumedPower" - whats the difference? I get "Unknown" for "CurrentPowerConsumption"

The first is the current electrical power consumption truncated to whole kW.
The latter is the same in Watt, so higher precision. But this value seems to be available only for newer hmu software versions (SW>=902)?
I think the choice of the similar names is a bit unfortunate?

[burmistrzak]

No, all "Source"-related definitions don't work on my system. I guess these values are relevant only for geothermal heat pumps?

@chrizzzp Thanks for checking! Exactly what I thought.

[burmistrzak]

1. I see there is "CurrentPowerConsumption" and also "CurrentConsumedPower" - whats the difference? I get "Unknown" for "CurrentPowerConsumption"
   @kgeree Thanks for testing!

As @chrizzzp said, one is in Watt, the other in kW.
Might be related to software version indeed.
Can you please log everything your VR 921 is periodically requesting?

2. I see still "hwc" instead of DHW in "Status" and "Statuscode".

That's expected, because I reuse existing value templates that still use hwc.
We'll have to ask @john30 about that.

3. Can we remove the "value" suffix for the values? At least in HomeAssistant it looks ugly - and useless...
   (also would be applicable for other CSVs (700,720,ctlv*,basv*...)

Not an issue on my end. Make sure you're running the lastest ebusd, and HASS-MQTT config.
Also, here's my env config:

      EBUSD_CONFIGPATH: "/config/ebusd-configuration/outcsv/@ebusd/ebus-typespec"
      EBUSD_MQTTJSON: ""
      EBUSD_MQTTINT: "/etc/ebusd/mqtt-hassio.cfg"
      EBUSD_MQTTVAR: "filter-name=^*,filter-non-circuit=vwz|hmu,filter-non-name=^Z2|^Z3|^Hc2|^Hc3"

[kgeree]

1. I see there is "CurrentPowerConsumption" and also "CurrentConsumedPower" - whats the difference? I get "Unknown" for "CurrentPowerConsumption"
   @kgeree Thanks for testing!

As @chrizzzp said, one is in Watt, the other in kW. Might be related to software version indeed. Can you please log everything your VR 921 is periodically requesting?

2. I see still "hwc" instead of DHW in "Status" and "Statuscode".

That's expected, because I reuse existing value templates that still use hwc. We'll have to ask @john30 about that.

3. Can we remove the "value" suffix for the values? At least in HomeAssistant it looks ugly - and useless...
   (also would be applicable for other CSVs (700,720,ctlv*,basv*...)

Not an issue on my end. Make sure you're running the lastest ebusd, and HASS-MQTT config. Also, here's my env config:

      EBUSD_CONFIGPATH: "/config/ebusd-configuration/outcsv/@ebusd/ebus-typespec"
      EBUSD_MQTTJSON: ""
      EBUSD_MQTTINT: "/etc/ebusd/mqtt-hassio.cfg"
      EBUSD_MQTTVAR: "filter-name=^*,filter-non-circuit=vwz|hmu,filter-non-name=^Z2|^Z3|^Hc2|^Hc3"

Thanks, indeed, I had an older mqtt-hassio.cfg. Updating that solved the "value" suffix issue.

Can you please log everything your VR 921 is periodically requesting?

How to do that? I get the following erroor for CurrentPowerConsumption:
2025-01-28 09:39:20.344 [update error] unable to parse poll-read hw5103 CurrentPowerConsumption from 3108b5160114 / 00: ERR: invalid position

[GuyHarg]

Hi @burmistrzak I seem to have a similar but slightly different setup to you guys on this thread but I definitely have HMU HW 5103 so your PRs are of keen interest to me thank you. I have an aroTHERM+ 5kW (HMU00) + what Vaillant tells me is 1st gen VRC 720F (no version) (BASV0) + 3-zone circuit box VR_71 + control unit VWZIO + sensoNET (NETX2) running on Raspi + HA + ebusd addin showing info as:

address 00: master #1
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=HMU00;SW=0607;HW=5103", loaded "vaillant/08.hmu.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=BASV0;SW=0217;HW=8803", loaded "vaillant/15.basv.csv"
address 26: slave, scanned "MF=Vaillant;ID=VR_71;SW=0104;HW=0503", loaded "vaillant/26.vr_71.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=0202;HW=0103", loaded "vaillant/76.vwzio.csv"
address f1: master #10
address f6: slave #10, scanned "MF=Vaillant;ID=NETX2;SW=4035;HW=5703"

I’m still using JonesPD’s config rep but wondering two things 1) would your most recent config csv rep work with my setup and 2) I’d be interested in helping to debug/discover my config file setup if that would help your efforts? Was a bit green on the coding / ebusd operation etc but coming up to speed now.

[GuyHarg]

@kgeree Had to do some cleanup to keep different PRs separate. 😅 You'll find the latest patches here, and pre-compiled CSVs here. Simply clone the repo, switch to the csvgen branch, point ebusd to ebusd-configuration/outcsv/@ebusd/ebus-typespec, and reload.

I cloned the csvgen branch onto HA and pointed config at the typespec directoryu via ebusd addin and restarted. Both 15 and 76 didn’t load config files. @kgeree you have similar HA setup any advice?

[burmistrzak]

How to do that? I get the following erroor for CurrentPowerConsumption: 2025-01-28 09:39:20.344 [update error] unable to parse poll-read hw5103 CurrentPowerConsumption from 3108b5160114 / 00: ERR: invalid position

@kgeree The 00 response indicates that the register is not implemented.
For logging, set the log level to notice, and grep "cmd: f108b5" the respective ebusd log file.
That should tell us which registers your gateway is polling.

[burmistrzak]

I’m still using JonesPD’s config rep but wondering two things 1) would your most recent config csv rep work with my setup and 2) I’d be interested in helping to debug/discover my config file setup if that would help your efforts? Was a bit green on the coding / ebusd operation etc but coming up to speed now.

@GuyHarg 👋

1. As long as your ebusd & HASS versions are up-to-date, yes. However, because your VRC 720 is a bit older, you would have to symlink basv3.csv to basv0.csv to benefit from recent developments. VWZIO support is coming soon.
2. Absolutely! We need more folks with different software revisions for testing. 💪

[burmistrzak]

I cloned the csvgen branch onto HA and pointed config at the typespec directoryu via ebusd addin and restarted. Both 15 and 76 didn’t load config files.

@GuyHarg Should be a quick fix. Run inside ebusd-configuration/outcsv/@ebusd/ebus-typespec/vaillant either ln -s 15.basv3.csv 15.basv0.csv for the latest version, or ln -s 15.700.csv 15.basv0.csv for the previous configuration.

[GuyHarg]

1. As long as your ebusd & HASS versions are up-to-date, yes. However, because your VRC 720 is a bit older, you would have to symlink basv3.csv to basv0.csv to benefit from recent developments. VWZIO support is coming soon.

Thx do I need to symlink 08.hmu.csv to 08.hmu.hw5103.csv as well, or is it more a case of trying to combine those files for my system to fix all the hmu data points showing up in MQTT explorer under homeassistant? In MQTT explorer under ebusd/hmu there are a few unknowns as well.

[GuyHarg]

@GuyHarg Should be a quick fix. Run inside ebusd-configuration/outcsv/@ebusd/ebus-typespec/vaillant either ln -s 15.basv3.csv 15.basv0.csv for the latest version, or ln -s 15.700.csv 15.basv0.csv for the previous configuration.

Ran the first cmd still no basv file loaded. I was previously picking up 15.basv.csv is that interchangeable with basv0? The command will be effective even when I run the app via HA ebusd addin yes?

Also a problem I have is trying to wrap my head around the whole system/data flow - I guess everyone has the same when they start? Is there a good reading area to get up to speed? Or really john30 wikis etc?

[burmistrzak]

Thx do I need to symlink 08.hmu.csv to 08.hmu.hw5103.csv as well, or is it more a case of trying to combine those files for my system to fix all the hmu data points showing up in MQTT explorer under homeassistant? In MQTT explorer under ebusd/hmu there are a few unknowns as well.

@GuyHarg No, 08.hmu.hw5103.csv will be picked up automatically. You had to symlink only the other config because it was previously a link as well.

For best results, delete the hw5103 MQTT device from HASS and restart ebusd.
After that, give it some time to poll registers. You‘ll find any errors in the ebusd log file.

[burmistrzak]

Ran the first cmd still no basv file loaded. I was previously picking up 15.basv.csv is that interchangeable with basv0? The command will be effective even when I run the app via HA ebusd addin yes?

@GuyHarg Yes, 15.basv.csv will match BASV*, unless there’s a more specific file available. The previous 15.basv.csv was/is symlinked to 15.700.csv.

Also a problem I have is trying to wrap my head around the whole system/data flow - I guess everyone has the same when they start? Is there a good reading area to get up to speed? Or really john30 wikis etc?

Not entirely sure what you’re asking about. Do you mean where’s the MQTT data coming from?
The wiki is a good starting point.

[TheEragon]

Hello @burmistrzak ,

I tried using your csvgen branch but 08.hmu.hw5103.csv is not picked up, any idea what might be wrong?

address 08: slave #11, scanned "MF=Vaillant;ID=HMU00;SW=0901;HW=5103", loaded "vaillant/08.hmu.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=CTLV2;SW=0514;HW=1104", loaded "vaillant/15.ctlv2.csv"
address 26: slave, scanned "MF=Vaillant;ID=VR_71;SW=0201;HW=0503", loaded "vaillant/26.vr_71.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=NETX2;SW=4035;HW=5703"

[burmistrzak]

I tried using your csvgen branch but 08.hmu.hw5103.csv is not picked up, any idea what might be wrong?

@TheEragon Thanks for testing!
Have you tried restarting/reloading ebusd?
Also, did you set the config path to ebusd-configuration/outcsv/@ebusd/ebus-typespec?

[TheEragon]

Unfortunately, yes, and yes :(

[burmistrzak]

@TheEragon Can you tell me a bit more about your setup (versions, etc.)? Any errors in logs?
Also, do a git pull and checkout the new preview branch. It includes VWZIO support as well.

[TheEragon]

I'm running ebusd addon in Home assistant, with you testing branch I get the following output

2ad9b828-ebusd:/# ebusctl i
version: ebusd 24.1.p20241114
device: /dev/ttyACM0, serial high speed, enhanced, firmware 1.1[5114].1[5114]
access: *
signal: acquired
symbol rate: 46
max symbol rate: 189
min arbitration micros: 7
max arbitration micros: 24
min symbol latency: 4
max symbol latency: 6
scan: finished
reconnects: 0
masters: 5
messages: 702
conditional: 0
poll: 134
update: 29
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=HMU00;SW=0901;HW=5103", loaded "vaillant/08.hmu.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=CTLV2;SW=0514;HW=1104", loaded "vaillant/15.ctlv2.csv"
address 26: slave, scanned "MF=Vaillant;ID=VR_71;SW=0201;HW=0503", loaded "vaillant/26.vr_71.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=NETX2;SW=4035;HW=5703"

There are no errors in the log and config files are picked up without a problem

ebusd --foreground --mqtthost=core-mosquitto --mqttport=1883 --mqttuser=addons --mqttpass=feaHoighae8eethiphieR3rie0zaibuWeikielarae4keezuungoh2quai3Deeph --scanconfig --mqttjson --configpath=/config/ebusd-configuration/outcsv/@ebusd/ebus-typespec --accesslevel=* --mqttint=/config/mqtt-hassio.cfg --mqtttopic=ebusd --device=ens:/dev/ttyACM0 --log=all:notice
2025-01-29 20:44:10.819 [device notice] transport opened
2025-01-29 20:44:10.822 [main notice] ebusd 24.1.p20241114 started with broadcast scan on device: /dev/ttyACM0, serial high speed, enhanced
2025-01-29 20:44:10.824 [bus notice] bus started with own address 31/36
2025-01-29 20:44:10.824 [device notice] reset, supports info
2025-01-29 20:44:10.825 [device notice] extra info: firmware 1.1[5114].1[5114], jumpers 0x03
2025-01-29 20:44:10.826 [mqtt notice] connection established
2025-01-29 20:44:10.851 [bus notice] signal acquired

[burmistrzak]

@TheEragon Hmm, very strange.
Is the repo actually located at /config/ebusd-configuration and is it readable by the current user?
It really seems like you're still using the default repo..?

[kgeree]

How to do that? I get the following erroor for CurrentPowerConsumption: 2025-01-28 09:39:20.344 [update error] unable to parse poll-read hw5103 CurrentPowerConsumption from 3108b5160114 / 00: ERR: invalid position

@kgeree The 00 response indicates that the register is not implemented. For logging, set the log level to notice, and grep "cmd: f108b5" the respective ebusd log file. That should tell us which registers your gateway is polling.

hi @burmistrzak, not sure if it helps (its just from a few hours as the logs rolled quite quickly.

see the attached file for the polled messages
cat * | grep "cmd: f108b5" | cut -d" " -f 3- | uniq > f108b5.log
f108b5.log

[burmistrzak]

@kgeree Thanks, very helpful!
AFAICT, these six registers in the middle are the only ones containing any useful data. We’ll have to decode them. Maybe current power consumption is somewhere in there…

Unknown registers

f1 08 b509 05 540200 560d / 0e 02 01 56-0d ff ff ff ff ff ff ff ff ff ff f1 08 b516 08 1000ffff 84030000 / 0b 10-00-ff 84-03 3e_32 00 00 00 00 f1 08 b516 08 1000ffff 84040000 / 0b 10-00-ff 84-04 3e_32 00 00 00 00 f1 08 b516 08 1000ffff 83030000 / 0b 00_00 00 83-03 3e_32 20 3d 68 4a f1 08 b516 08 1000ffff 83040000 / 0b 00_00 02 83-04 3e_32 80 50 77 4a f1 08 b516 08 1000ffff 83050000 / 0b 00_00 04 83-05 3e_32 00 2f 0a 49 f1 08 b516 08 1000ffff 42030000 / 0b 00_00 01 42-03 3e_32 40 85 e9 4a f1 08 b516 08 1000ffff 42040000 / 0b 00_00 03 42-04 3e_32 60 3d 05 4b f1 08 b516 08 1000ffff 42050000 / 0b 00_00 05 42-05 3e_32 80 84 1b 4a f1 08 b516 08 1000ffff 49030000 / 0b 10-00-ff 49-03 3e_32 00 00 00 00 f1 08 b516 08 1000ffff 49040000 / 0b 10-00-ff 49-04 3e_32 00 00 00 00 f1 08 b516 08 1000ffff 49050000 / 0b 10-00-ff 49-05 3e_32 00 00 00 00

In the meantime, please do me the favor and try the following register:
ebusctl hex 08b509055402005b0d

[kgeree]

hex 08b509055402005b0d
0802015b0d00000841

do I find somewhere some description how to decode these? I'm open to it if I can help...

[burmistrzak]

do I find somewhere some description how to decode these? I'm open to it if I can help...

@kgeree Yes! Post the output of ebusctl grab result decode | grep -a -A 50 '08b509055402005b0d'

[kgeree]

grep -a -A 50 '08b509055402005b0d'

3108b509055402005b0d / 0802015b0d00000841 = 1
 BCD   02=2, 01=1, 00=0, 00=0, 08=8, 41=41
 BCD:2 0201=102, 0000=0, 0008=800, 0841=4108
 BCD:3 000008=80000, 000841=410800
 BCD:4 00000841=41080000
 BDY   02=Wed, 01=Tue, 00=Mon, 00=Mon
 BTI   000008="08:00:00"
 BTM   0201="01:02", 0000="00:00", 0008="08:00"
 D1B   02=2, 01=1, 5b=91, 0d=13, 00=0, 00=0, 08=8, 41=65
 D1C   02=1.0, 01=0.5, 5b=45.5, 0d=6.5, 00=0.0, 00=0.0, 08=4.0, 41=32.5
 D2B   0201=1.008, 015b=91.004, 5b0d=13.355, 0d00=0.051, 0000=0.000, 0008=8.000, 0841=65.031
 D2C   0201=16.12, 015b=1456.06, 5b0d=213.69, 0d00=0.81, 0000=0.00, 0008=128.00, 0841=1040.50
 DAY   0201="16.09.1900", 015b="15.10.1963", 5b0d="13.05.1909", 0d00="16.01.1900", 0000="03.01.1900", 0008="11.08.1905", 0841="01.08.1945"
 DTM   02015b0d="07.01.2435 16:02", 015b0d00="31.08.2010 19:45", 5b0d0000="03.01.2009 08:59", 0d000008="09.03.2264 18:21", 00000841="21.05.4083 23:28"
 EXP   02015b0d=6.74858e-31, 015b0d00=1.22651e-39, 5b0d0000=4.79104e-42, 0d000008=3.85187e-34, 00000841=8.5
 EXR   02015b0d=9.50355e-38, 015b0d00=4.02333e-38, 5b0d0000=3.9688e+16, 0d000008=3.94431e-31, 00000841=2.96094e-42
 FLR   0201=0.513, 015b=0.347, 5b0d=23.309, 0d00=3.328, 0000=0.000, 0008=0.008, 0841=2.113
 FLT   0201=0.258, 015b=23.297, 5b0d=3.419, 0d00=0.013, 0000=0.000, 0008=2.048, 0841=16.648
 HCD   02015b0d=13910102, 015b0d00=139101, 5b0d0000=1391, 0d000008=8000013, 00000841=65080000
 HCD:1 02=2, 01=1, 5b=91, 0d=13, 00=0, 00=0, 08=8, 41=65
 HCD:2 0201=102, 015b=9101, 5b0d=1391, 0d00=13, 0000=0, 0008=800, 0841=6508
 HCD:3 02015b=910102, 015b0d=139101, 5b0d00=1391, 0d0000=13, 000008=80000, 000841=650800
 HDA   02015b0d="02.01.2013"
 HDA:3 02015b="02.01.2091"
 HDY   02=Thu, 01=Wed, 00=Tue, 00=Tue
 HEX:8 02015b0d00000841="02 01 5b 0d 00 00 08 41"
 HTI   0d0000="13:00:00", 000008="00:00:08"
 HTM   0201="02:01", 0d00="13:00", 0000="00:00", 0008="00:08"
 MIN   0201="04:18", 0d00="00:13", 0000="00:00"
 NTS:8 02015b0d00000841="["
 PIN   0201=0201, 0000=0000, 0008=0008, 0841=0841
 S3N   02015b=5964034, 015b0d=875265, 5b0d00=3419, 0d0000=13, 000008=524288, 000841=4261888
 S3R   02015b=131419, 015b0d=88845, 5b0d00=5967104, 0d0000=851968, 000008=8, 000841=2113
 SCH   02=2, 01=1, 5b=91, 0d=13, 00=0, 00=0, 08=8, 41=65
 SIN   0201=258, 015b=23297, 5b0d=3419, 0d00=13, 0000=0, 0008=2048, 0841=16648
 SIR   0201=513, 015b=347, 5b0d=23309, 0d00=3328, 0000=0, 0008=8, 0841=2113
 SLG   02015b0d=224067842, 015b0d00=875265, 5b0d0000=3419, 0d000008=134217741, 00000841=1091043328
 SLR   02015b0d=33643277, 015b0d00=22744320, 5b0d0000=1527578624, 0d000008=218103816, 00000841=2113
 STR:8 02015b0d00000841="  [ "
 TEM_P 0201=02-002, 015b=22-001, 5b0d=26-091, 0d00=00-013, 0000=00-000, 0008=16-000, 0841=02-008
 TTM   02="00:20", 01="00:10", 5b="15:10", 0d="02:10", 00="00:00", 00="00:00", 08="01:20", 41="10:50"
 U3N   02015b=5964034, 015b0d=875265, 5b0d00=3419, 0d0000=13, 000008=524288, 000841=4261888
 U3R   02015b=131419, 015b0d=88845, 5b0d00=5967104, 0d0000=851968, 000008=8, 000841=2113
 UCH   02=2, 01=1, 5b=91, 0d=13, 00=0, 00=0, 08=8, 41=65
 UIN   0201=258, 015b=23297, 5b0d=3419, 0d00=13, 0000=0, 0008=2048, 0841=16648
 UIR   0201=513, 015b=347, 5b0d=23309, 0d00=3328, 0000=0, 0008=8, 0841=2113
 ULG   02015b0d=224067842, 015b0d00=875265, 5b0d0000=3419, 0d000008=134217741, 00000841=1091043328
 ULR   02015b0d=33643277, 015b0d00=22744320, 5b0d0000=1527578624, 0d000008=218103816, 00000841=2113
 VTI   0d0000="00:00:13", 000008="08:00:00"
 VTM   0201="01:02", 0d00="00:13", 0000="00:00", 0008="08:00"
f108b50905540200560d / 0e0201560dffffffffffffffffffff = 2

[burmistrzak]

@kgeree Is it plausible that your HMU was consuming about 8.5 W at that time? Ignoring the first four bytes, and interpreting as EXP (i.e. 00000841=8.5) seem to suggest so.

Please try this with your VWZ: ebusctl hex 76b509055402005b0d
If both registers work and indeed return correct data, we‘ll have a winner. 😉

[kgeree]

@kgeree Is it plausible that your HMU was consuming about 8.5 W at that time? Ignoring the first four bytes, and interpreting as EXP (i.e. 00000841=8.5) seem to suggest so.

Please try this with your VWZ: ebusctl hex 76b509055402005b0d If both registers work and indeed return correct data, we‘ll have a winner. 😉

I think I've seen somewhere ~8 W consumption at stand-by..so could be valid.

hex 76b509055402005b0d
0802015b0d00000000

cat grab |grep -a -A 50 '76b509055402005b0d'
3176b509055402005b0d / 0802015b0d00000000 = 1
 BCD   02=2, 01=1, 00=0, 00=0, 00=0, 00=0
 BCD:2 0201=102, 0000=0, 0000=0, 0000=0
 BCD:3 000000=0, 000000=0
 BCD:4 00000000=0
 BDY   02=Wed, 01=Tue, 00=Mon, 00=Mon, 00=Mon, 00=Mon
 BTI   000000="00:00:00", 000000="00:00:00"
 BTM   0201="01:02", 0000="00:00", 0000="00:00", 0000="00:00"
 D1B   02=2, 01=1, 5b=91, 0d=13, 00=0, 00=0, 00=0, 00=0
 D1C   02=1.0, 01=0.5, 5b=45.5, 0d=6.5, 00=0.0, 00=0.0, 00=0.0, 00=0.0
 D2B   0201=1.008, 015b=91.004, 5b0d=13.355, 0d00=0.051, 0000=0.000, 0000=0.000, 0000=0.000
 D2C   0201=16.12, 015b=1456.06, 5b0d=213.69, 0d00=0.81, 0000=0.00, 0000=0.00, 0000=0.00
 DAY   0201="16.09.1900", 015b="15.10.1963", 5b0d="13.05.1909", 0d00="16.01.1900", 0000="03.01.1900", 0000="03.01.1900", 0000="03.01.1900"
 DTM   02015b0d="07.01.2435 16:02", 015b0d00="31.08.2010 19:45", 5b0d0000="03.01.2009 08:59", 0d000000="01.01.2009 00:13", 00000000="01.01.2009 00:00"
 EXP   02015b0d=6.74858e-31, 015b0d00=1.22651e-39, 5b0d0000=4.79104e-42, 0d000000=1.82169e-44, 00000000=0.0
 EXR   02015b0d=9.50355e-38, 015b0d00=4.02333e-38, 5b0d0000=3.9688e+16, 0d000000=3.9443e-31, 00000000=0.0
 FLR   0201=0.513, 015b=0.347, 5b0d=23.309, 0d00=3.328, 0000=0.000, 0000=0.000, 0000=0.000
 FLT   0201=0.258, 015b=23.297, 5b0d=3.419, 0d00=0.013, 0000=0.000, 0000=0.000, 0000=0.000
 HCD   02015b0d=13910102, 015b0d00=139101, 5b0d0000=1391, 0d000000=13, 00000000=0
 HCD:1 02=2, 01=1, 5b=91, 0d=13, 00=0, 00=0, 00=0, 00=0
 HCD:2 0201=102, 015b=9101, 5b0d=1391, 0d00=13, 0000=0, 0000=0, 0000=0
 HCD:3 02015b=910102, 015b0d=139101, 5b0d00=1391, 0d0000=13, 000000=0, 000000=0
 HDA   02015b0d="02.01.2013"
 HDA:3 02015b="02.01.2091"
 HDY   02=Thu, 01=Wed, 00=Tue, 00=Tue, 00=Tue, 00=Tue
 HEX:8 02015b0d00000000="02 01 5b 0d 00 00 00 00"
 HTI   0d0000="13:00:00", 000000="00:00:00", 000000="00:00:00"
 HTM   0201="02:01", 0d00="13:00", 0000="00:00", 0000="00:00", 0000="00:00"
 MIN   0201="04:18", 0d00="00:13", 0000="00:00", 0000="00:00", 0000="00:00"
 NTS:8 02015b0d00000000="["
 PIN   0201=0201, 0000=0000, 0000=0000, 0000=0000
 S3N   02015b=5964034, 015b0d=875265, 5b0d00=3419, 0d0000=13, 000000=0, 000000=0
 S3R   02015b=131419, 015b0d=88845, 5b0d00=5967104, 0d0000=851968, 000000=0, 000000=0
 SCH   02=2, 01=1, 5b=91, 0d=13, 00=0, 00=0, 00=0, 00=0
 SIN   0201=258, 015b=23297, 5b0d=3419, 0d00=13, 0000=0, 0000=0, 0000=0
 SIR   0201=513, 015b=347, 5b0d=23309, 0d00=3328, 0000=0, 0000=0, 0000=0
 SLG   02015b0d=224067842, 015b0d00=875265, 5b0d0000=3419, 0d000000=13, 00000000=0
 SLR   02015b0d=33643277, 015b0d00=22744320, 5b0d0000=1527578624, 0d000000=218103808, 00000000=0
 STR:8 02015b0d00000000="  [ "
 TEM_P 0201=02-002, 015b=22-001, 5b0d=26-091, 0d00=00-013, 0000=00-000, 0000=00-000, 0000=00-000
 TTM   02="00:20", 01="00:10", 5b="15:10", 0d="02:10", 00="00:00", 00="00:00", 00="00:00", 00="00:00"
 U3N   02015b=5964034, 015b0d=875265, 5b0d00=3419, 0d0000=13, 000000=0, 000000=0
 U3R   02015b=131419, 015b0d=88845, 5b0d00=5967104, 0d0000=851968, 000000=0, 000000=0
 UCH   02=2, 01=1, 5b=91, 0d=13, 00=0, 00=0, 00=0, 00=0
 UIN   0201=258, 015b=23297, 5b0d=3419, 0d00=13, 0000=0, 0000=0, 0000=0
 UIR   0201=513, 015b=347, 5b0d=23309, 0d00=3328, 0000=0, 0000=0, 0000=0
 ULG   02015b0d=224067842, 015b0d00=875265, 5b0d0000=3419, 0d000000=13, 00000000=0
 ULR   02015b0d=33643277, 015b0d00=22744320, 5b0d0000=1527578624, 0d000000=218103808, 00000000=0
 VTI   0d0000="00:00:13", 000000="00:00:00", 000000="00:00:00"
 VTM   0201="01:02", 0d00="00:13", 0000="00:00", 0000="00:00", 0000="00:00"
f115b52406020000004800 / 06010048000000 = 1

[chrizzzp]

@burmistrzak @kgeree
My (split) unit delivers the current power consumption in Watt both under the b509 register (08b509055402005b0d) and the b516 register (08b5160114). Interestingly, the VR921 gateway uses the latter one for polling,
See here:
#330 (comment)
The b516 copy seems to be present only with newer hmu firmwares?

[burmistrzak]

My (split) unit delivers the current power consumption in Watt both under the b509 register (08b509055402005b0d) and the b516 register (08b5160114).

@chrizzzp Yep, our monoblock also has both registers available.

Interestingly, the VR921 gateway uses the latter one for polling,

The newer VR940f does the same.

The b516 copy seems to be present only with newer hmu firmwares?

That seems to be the case, yes.
We can either try identifying these unknown registers, in the hope of finding a b516 equivalent for older systems, or simply use the b509 block instead for everything. 😉

[burmistrzak]

@kgeree Parsing the hex the same way as before, your uniTOWER was consuming 00000000=0.0 Watt. 😅

[burmistrzak]

Comparing the current power consumption registers from b509 and b516

root@63e1166edcc5:/# ebusctl hex 08b5160114
090187260a4400000000
09 01 [87260a44] 00 00 00 00 ≈ 552.6 Watt (HMU)

root@63e1166edcc5:/# ebusctl hex 08b509055402005b0d
0802015b0df2a60944
08 02 01 5b 0d [f2a60944] ≈ 550.6 Watt (HMU)

root@63e1166edcc5:/# ebusctl hex 76b5160114
09000000404000000000
09 00 [00004040] 00 00 00 00 ≈ 3 Watt (VWZIO)

root@63e1166edcc5:/# ebusctl hex 76b509055402005b0d
0802015b0d00000000
08 02 01 5b 0d [00000000] ≈ 0 Watt (VWZIO)