Reverse engineering b516 energy statistics
filippz opened this issue · comments
Long story short - I've found a way to read gas/electricity consumption from my VUI 25/32 CS/1-5 (MF=Vaillant;ID=BAI00;SW=0807;HW=7603) and I need a little advice on what would be the best way to implement the support for it.
I was having an issue reading reading gas/electricity as I would get ERR: invalid position in decode when trying to read PrEnergyCountHc1/PrEnergyCountSum1 and all the rest of PrEnergyCount/PrEnergySum values. This seem to be common occurrence (for example: #437, john30/ebusd#620, john30/ebusd#1126,...) with one common "denominator": HW version of all those reports seem to be 7603
By looking at the communication between bai and ctlv2 I saw some unsupported commands/messages that pointed me to the right track with the following conclusions:
ctlv2sendsbai30 commands each one for a single Wh value for:
heating/hot water (2) x
gas/electricity/total (3) x
previous month/current month/previous year/current year/total (5)- commands are
b516with 100Xffff0Y0ZWV3Q as a payload where (with the kind help of @chrizzzp):
X (period): 0=All, 1=Day, 2=Month, 3=Year
Y (source): 1=Solar, 2=Environmental, 3=Electricity, 4=Gas, (9=unidentified heat pump-related)
Z(usage): 0=All, 3=Heating, 4=Hot water, 5=Cooling
W/V/Q: - Month/Year/Day:- for All (X=0):
- W,V,Q: ignored
- for Year (X=3):
- W,V: ignored
- Q: 0=Previous, 2=Current
- for Month/Day (X=2, X=1)
- for Months 1-7:
- W: Month * 2 (2/4/6/8/a/c/e for months 1/2/3/4/5/6/7) + increased by one for X=1 and second part of the month
- Q: 0=Previous Year, 2=Current Year
- V: ignored for X=2
- for Month 8-12:
- W: (Month-8) * 2 (0/2/4/6/8 for months 8/9/10/11/12) + increased by one for X=1 and second part of the month
- Q: 1=Previous Year, 3=Current Year
- V: ignored for X=2
- for Day (X=1) - only last 16 days are available
- V is combined with Q/W values to determine Year/Month
- for the first part of the month (days 1-15):
- V: 1-f (days 1-15)
- for the second part of the month (days 16-31)
- V: 0-f
- W: is increased by one to specify second part of the month
- for Months 1-7:
- for All (X=0):
- replies are 11 bytes long where the last 4 bytes are Wh value in EXP format
payload examples:
1001ffff03005732 - daily sum of electrical energy consumption on Feb 23 of the current year
1002ffff02038031 - monthly environmental yield used for heating in Dec of previous year
1003ffff04040032 - this years gas consumption used for water heating
1000ffff01000030 - total solar yield of the system (since installation)
example command:
ebusctl hex 08b516081001ffff03005732
To support this, I've added:
- an
energyeentry to _templates.csv:
energye,EXP,,Wh, - 30 entries to bai.308523.inc like:
r,,EnergySumHcPreviousYear,,,,b516,1003ffff03032130,,,IGN:7;energye,,,
r,,FuelSumHcPreviousYear,,,,b516,1003ffff04032130,,,IGN:7;energye,,,
...
Since I use those in Home Assistan, I've had to add |fuel to the filter-name value and sensor,gas,total_increasing = fuel|,Wh$ line to type_switch-number in mqtt-hassio.cfg
Before I prepare a proper PR, I would like to hear some opinions if those entries make sense or there is a more logical approach? Should HW:7603 be addressed separately and PrEnergyCount/PrEnergySum moved outside bai.308523.inc or it can be in the same file (and filtered out with [HW=7603] or similar)?
Wow, excellent reverse engineering (I guess)! I was investigating into decoding the b516 energy statistics, too, for some time, but got stuck (#472 (comment)). Your work finally solved it! Thanks a lot!
Good news: they also work for my heat pump (hmu, MF=Vaillant;ID=HMU00;SW=0902;HW=5103) using the same regulator (ctlv2, but will most probably work also for the related basv, basv3, ctlv3,... regulators).
Observation: for heat pumps these registers also deliver the enviromental energy statistics (energy gained from the environment) - see below!
* commands are `b516` with 100**X**ffff0**Y**0**ZW**13**Q** as a payload where: **X**: 0=All, 2=Month, 3=Year (1 probably means Day)
So far I had no success in getting any non-zero values with X=1 (days). See below.
**Y**: 3=Electricity, 4=Gas
Y: 2=environmental yield
**Z**: 0=All, 3=Heating, 4=Hot water **W**: 2=Previous, 4=Current (only valid for Month, ie X=2, otherwise it has a value of 2) **Q**: 2=Previous, 4=Current (only valid for Year, ie X=3, otherwise it has a value of 2)
I would expect there should also be a W/Q-like specifier valid for Day (X=1). I will monitor ebus traffic to investigate into daily energy statistics.
* 30 entries to bai.308523.inc like:r,,EnergySumHcPreviousYear,,,,b516,1003ffff03032130,,,IGN:7;energye,,, r,,FuelSumHcPreviousYear,,,,b516,1003ffff04032130,,,IGN:7;energye,,, ...
Yes, probably the way to go for the moment. I'm not sure if the new TypeScript-based definitions are more flexible in this context. Maybe @burmistrzak can comment?
Before I prepare a proper PR, I would like to hear some opinions if those entries make sense or there is a more logical approach? Should HW:7603 be addressed separately and
PrEnergyCount/PrEnergySummoved outside bai.308523.inc or it can be in the same file (and filtered out with [HW=7603] or similar)?
I think it can be done using HW-specific 'conditions' in the csv.
Wow, excellent reverse engineering (I guess)! I was investigating into decoding the b516 energy statistics, too, for some time, but got stuck (#472 (comment)). Your work finally solved it! Thanks a lot!
Good news: they also work for my heat pump (hmu,
MF=Vaillant;ID=HMU00;SW=0902;HW=5103) using the same regulator (ctlv2, but will most probably work also for the related basv, basv3, ctlv3,... regulators).
Took me a while figure it out - it kinda helped that my kid was learning about IEEE 754 format a couple of weeks ago which I wasn't thinking about for some years. Since ctlv2 refreshes those values only at midnight and startup I was pulling ctlv2 from the wall and back a few times, but I'm glad it's working out for you also :) Also, I'd tell that regulators are not important here - since we're not talking with them, but we'll have to figure out for which devices/versions should this be used.
So far I had no success in getting any non-zero values with X=1 (days). See below.
It was just a guess, since my ctlv2 doesn't display daily values but I have those numbers on the boiler itself and I haven't tested it further because these are not important for my user case.
Y: 2=environmental yield
I have 0 experience with HP so this is good for those users but we need to se if those can be used universally (ie even on devices other than heat pumps) or need to be added separately. Do you get an reply for 4=Gas which simply returns 0 or you get an error?
I would expect there should also be a W/Q-like specifier valid for Day (X=1). I will monitor ebus traffic to investigate into daily energy statistics.
Please do - from my perspective W/Q don't make sense since I would simply expect one boolean value which would indicate current/previous and be ignored for total. So those W/Q values might have some additional function/values which in my case can simply be used for current/previous. If you're up to it - you can try pulling your ctlv2 from the wall and back to force refresh and catch those messages.
Yes, probably the way to go for the moment. I'm not sure if the new TypeScript-based definitions are more flexible in this context. Maybe @burmistrzak can comment?
That's why we're chatting here :) I don't really know that much about all of this so experienced users might do it differently.
I think it can be done using HW-specific 'conditions' in the csv.
I was assuming that we're speaking about HW=7603, but since it obviously includes more devices and not only bai maybe some "includes" that would be pulled from a couple of places would be in order.
Thanks for the feedback!
Y: 2=environmental yield
I have 0 experience with HP so this is good for those users but we need to se if those can be used universally (ie even on devices other than heat pumps) or need to be added separately. Do you get an reply for 4=Gas which simply returns 0 or you get an error?
For 4=Gas my HP returns 0.
Indeed it would be interesting to hear from people with e.g. geothermal HP, whether they also can read the corresponding values using the Y=2 (environmental yield) or a different parameter (source yield).
I would expect there should also be a W/Q-like specifier valid for Day (X=1). I will monitor ebus traffic to investigate into daily energy statistics.
Please do - from my perspective W/Q don't make sense since I would simply expect one boolean value which would indicate current/previous and be ignored for total. So those W/Q values might have some additional function/values which in my case can simply be used for current/previous. If you're up to it - you can try pulling your
ctlv2from the wall and back to force refresh and catch those messages.
You don't actually need to restart your ctlv2 everytime to catch these messages (i.e. pulling the regulator from the wall), all EBUS messages (known and unknown) can actually be found in the ebusd logfile (loglevel 'notice') and will appear every night shortly after midnight, as you've noticed, too. So you just have to wait for them...
For 4=Gas my HP returns 0.
Cool - I'd say that this means that there is no need for splitting the definitions across devices as they all support all commands and simply return 0 for stuff they don't use for their operation
So you just have to wait for them
Being from Balkans waiting it out simple wasn't on the table :) Logic was to force those messages at will and compare them with whatever ctlv2 was displaying at that time and see which replies contained different payloads and what changed on the display. I even tried changing time to 23:59 and wait it out a full minute but ctlv2 would change back time to real one just before 00:00 (this might be some ebusd magic). At that time the Neanderthal part of my genome prevailed and off the wall it went...
I think there is more information available than only from current and previous month/year. At least on my HP it seems more complex than:
**X**: 0=All, 2=Month, 3=Year (1 probably means Day) **Y**: 3=Electricity, 4=Gas **Z**: 0=All, 3=Heating, 4=Hot water **W**: 2=Previous, 4=Current (only valid for Month, ie X=2, otherwise it has a value of 2) **Q**: 2=Previous, 4=Current (only valid for Year, ie X=3, otherwise it has a value of 2)
To illustrate: when requesting the annual data (X=3, Y=2/3, Z=0/3/4,W=2) for my setup:
Q=0/1 result in same (previous years?) value
ebusctl hex 08b516081003ffff03002130 / 0b0301ff03002130fc0d0a4a
ebusctl hex 08b516081003ffff03002131 / 0b0301ff03002130fc0d0a4a
Q=2/3 result in (current years?) value
ebusctl hex 08b516081003ffff03002132 / 0b0300ff0300213231895d49
ebusctl hex 08b516081003ffff03002133 / 0b0300ff0300213231895d49
Q=4/5... result in 0 (see below!)
I have no idea why the same values are stored in consecutive registers (Q=0/1, 2/3).
The slight differences between them (for the current year values) reflect the current standby power consumption of the HP, as I am requesting with Z=0).
BTW: I get more data when iterating W and Q (X=3, Y=2/3, Z=0/3/4):
W=0/1 and Q=0/1: deliver same (previous years?) value as W=2/3 and Q=0/1
08b516081003ffff03000130 / 0b0301ff03002130fc0d0a4a
08b516081003ffff03000131 / 0b0301ff03002130fc0d0a4a
08b516081003ffff03001130 / 0b0301ff03002130fc0d0a4a
08b516081003ffff03001131 / 0b0301ff03002130fc0d0a4a
W=0/1 and Q=2/3: deliver (almost) same (this years?) values
08b516081003ffff03000132 / 0b0300ff03002132b3a55d49
08b516081003ffff03000133 / 0b0300ff03002132b3a55d49
08b516081003ffff03001132 / 0b0300ff03002132b5a55d49
08b516081003ffff03001133 / 0b0300ff03002132b6a55d49
W=2/3 and Q=0/1: deliver same (previous years?) value
08b516081003ffff03002130 / 0b0301ff03002130fc0d0a4a
08b516081003ffff03002131 / 0b0301ff03002130fc0d0a4a
08b516081003ffff03003130 / 0b0301ff03002130fc0d0a4a
08b516081003ffff03003131 / 0b0301ff03002130fc0d0a4a
W=2/3 and Q=2/3: deliver (almost) same (this years?) value
08b516081003ffff03002132 / 0b0300ff0300213229a75d49
08b516081003ffff03002133 / 0b0300ff030021322aa75d49
08b516081003ffff03003132 / 0b0300ff030021322ba75d49
08b516081003ffff03003133 / 0b0300ff030021322ba75d49
W=0/1 and Q=4/5... result in 0
W=2/3 and Q=4/5... result in 0
W=4/5 and Q=4/5... result in 0
etc.
Interestingly, when interating W from 0 to F (hex) with Q=2 I get the same (non-zero) values:
08b516081003ffff03000132 / 0b0300ff030021325aa75d49
08b516081003ffff03001132 / 0b0300ff030021325aa75d49
08b516081003ffff03002132 / 0b0300ff030021325aa75d49
08b516081003ffff03003132 / 0b0300ff030021325aa75d49
08b516081003ffff03004132 / 0b0300ff030021325aa75d49
08b516081003ffff03005132 / 0b0300ff030021325ba75d49
08b516081003ffff03006132 / 0b0300ff030021325ba75d49
08b516081003ffff03007132 / 0b0300ff030021325da75d49
08b516081003ffff03008132 / 0b0300ff030021325da75d49
08b516081003ffff03009132 / 0b0300ff030021325ea75d49
08b516081003ffff0300A132 / 0b0300ff030021325ea75d49
08b516081003ffff0300B132 / 0b0300ff0300213260a75d49
08b516081003ffff0300C132 / 0b0300ff0300213261a75d49
08b516081003ffff0300D132 / 0b0300ff0300213262a75d49
08b516081003ffff0300E132 / 0b0300ff0300213262a75d49
08b516081003ffff0300F132 / 0b0300ff0300213263a75d49
Similarily for Q=1:
08b516081003ffff03002131 / 0b0301ff03002130fc0d0a4a
08b516081003ffff03003131 / 0b0301ff03002130fc0d0a4a
08b516081003ffff03004131 / 0b0301ff03002130fc0d0a4a
...
08b516081003ffff0300F131 / 0b0301ff03002130fc0d0a4a
So:
- I get valid annual values only for Q=0/1 and Q=2/3, reflecting the previous and current year.
- I get the same annual values for W=0-F.
Now, for monthly data (X=2, Y=2/3, Z=0/3/4, Q=0) iterating W:
08b516081002ffff03000130 / 0b12ffff0300113000000000
08b516081002ffff03001130 / 0b12ffff0300113000000000
08b516081002ffff03002130 / 0b020dff03002130609fe348
08b516081002ffff03003130 / 0b020dff03002130609fe348
08b516081002ffff03004130 / 0b020cff0300413080f65f48
08b516081002ffff03005130 / 0b020cff0300413080f65f48
08b516081002ffff03006130 / 0b020bff0300613040098c48
08b516081002ffff03007130 / 0b020bff0300613040098c48
08b516081002ffff03008130 / 0b020aff03008130c08e3b48
08b516081002ffff03009130 / 0b020aff03008130c08e3b48
08b516081002ffff0300A130 / 0b0209ff0300a130006e9747
08b516081002ffff0300B130 / 0b0209ff0300a130006e9747
08b516081002ffff0300C130 / 0b0208ff0300c130009b7247
08b516081002ffff0300D130 / 0b0208ff0300c130009b7247
08b516081002ffff0300E130 / 0b0207ff0300e33000c05244
08b516081002ffff0300F130 / 0b0207ff0300e33000c05244
yield: 7 individual (non-zero) values.
...and monthly data (X=2, Y=2/3, Z=0/3/4, Q=1) iterating W:
08b516081002ffff03000131 / 0b0206ff030004310080b643
08b516081002ffff03001131 / 0b0206ff030004310080b643
08b516081002ffff03002131 / 0b0205ff0300273100277b47
08b516081002ffff03003131 / 0b0205ff0300273100277b47
08b516081002ffff03004131 / 0b0204ff03004131807bef47
08b516081002ffff03005131 / 0b0204ff03004131807bef47
08b516081002ffff03006131 / 0b0203ff0300613120799948
08b516081002ffff03007131 / 0b0203ff0300613120799948
08b516081002ffff03008131 / 0b0202ff03008131e081d948
08b516081002ffff03009131 / 0b0202ff03008131e081d948
08b516081002ffff0300A131 / 0b12ffff0300a13100000000
08b516081002ffff0300B131 / 0b12ffff0300b13100000000
08b516081002ffff0300C131 / 0b12ffff0300c13100000000
08b516081002ffff0300D131 / 0b12ffff0300d13100000000
08b516081002ffff0300E131 / 0b12ffff0300e13100000000
08b516081002ffff0300F131 / 0b12ffff0300f13100000000
yield: 5 individual (non-zero) values.
7+5=12
I think these registers contain last years monthly values, split over the two adress ranges (Q=0 and Q=1).
Q=2: (this year)
"previous month":
08b516081002ffff03002132 / 0b0201ff03002132800ccc48
08b516081002ffff03003132 / 0b0201ff03002132800ccc48
"this month":
08b516081002ffff03004132 / 0b0200ff030041327eadee48
08b516081002ffff03005132 / 0b0200ff0300413245b4ee48
W=6/7...F results in 0, also for Q=3
I think these (Q=2 and Q=3) are the monthly registers for the current year. Since we have now the second month of the year all registers W>5 are zero.
To summarize:
Q=0/1 previous year
Q=2/3 this year
.
W: 0-F (hex) monthly registers
I suspect for previous years monthly values:
Q=0
W=2/3 January
W=4/5 February
W=6/7 March
W=8/9 April
W=A/B May
W=C/D June
W=E/F July
Q=1
W=0/1 August
W=2/3 September
W=4/5 October
W=6/7 November
W=8/9 December
Similar for this years monthly values:
Q=2
W=2/3 January
W=4/5 February
etc.
Q=3
W=0/1 August
W=2/3 September
etc.
What do you think?
Could you try to confirm this on your bai unit to figure out if this is specific to the HP units?
Concerning Q: maybe more then two years are recorded, then Q could become >3 (like Q=4 with your bai unit. How many years do you have your system running?)
for monthly data (X=2, Y=2/3, Z=0/3/4, Q=0) iterating W
I think you're right - I tested the theory by adding all the 12 monthly values for energy last year and this matches the value returned by 1003ffff03002130. That would then make 2 x 12 entries naming the month explicitly...
Concerning Q: maybe more then two years are recorded, then Q could become >3 (like Q=4 with your bai unit. How many years do you have your system running?)
My system also reports the same for Q0/1 and Q2/3 - Since cltv2 sends Q0/2 I only considered those values.
Q4/5 returns 0 for me despite my unit being from 2023. I think system might just keep current/previous and total since 1000ffff03002132 (total electric energy) gives me more than 1003ffff03002130 + 1003ffff03002132 (previous + current year).
Thanks for checking!
I think you're right - I tested the theory by adding all the 12 monthly values for energy last year and this matches the value returned by 1003ffff03002130. That would then make 2 x 12 entries naming the month explicitly...
Yes, and even more if you want the complete monthly data:
x3 (for Z: 0=All, 3=Heating, 4=Hot water) = 72
x2 (for Y: 3=Electricity, 4=Gas or 2=Environment) = 144
I'm not sure I want this in my CSV...
However, there is an -i (index) option in the 'ebusctl read' command (https://github.com/john30/ebusd/wiki/3.1.-TCP-client-commands#read) which could be used to reduce the number of required message definitions in the CSV. It's used for instance to read the 'errorhistory' or the timers in the regulators.
Concerning Q: maybe more then two years are recorded, then Q could become >3 (like Q=4 with your bai unit. How many years do you have your system running?)
My system also reports the same for Q0/1 and Q2/3 - Since
cltv2sends Q0/2 I only considered those values. Q4/5 returns 0 for me despite my unit being from 2023. I think system might just keep current/previous and total since 1000ffff03002132 (total electric energy) gives me more than 1003ffff03002130 + 1003ffff03002132 (previous + current year).
So how about the Q=4 readings you mentioned above? Do they work?
Q: 2=Previous, 4=Current (only valid for Year, ie X=3, otherwise it has a value of 2)
So how about the Q=4 readings you mentioned above? Do they work?
Sorry - my original post had a copy/paste error (fixed it now) - ctlv2 uses Q=0 for this year and Q=2 for previous one. Q=4 returns 0 for me.
For now I'm leaving W in original post as is - March starts tomorrow and we'll confirm if new queries from ctlv2 will be with W=6 as expected based on your findings.
I'm not sure I want this in my CSV...
I'm only using two total gas values (heating + hot water) for HomeAssistant as they're enough to monitor gas usage and I'm measuring electricity with Shelly Pro EM and not monitoring individual device usages. I guess that for the typical user this might be just enough.
We would also need to change the title of this issue as it turns out this is relevant to much more devices that I anticipated...
For now I'm leaving W in original post as is - March starts tomorrow and we'll confirm if new queries from
ctlv2will be with W=6 as expected based on your findings.
Confirmed by looking at the messages from ctlv2 this morning - I've updated first post accordingly.
W+Q: - Month/Year:
* for Year (X=3): * W: has a fixed value of 2 * Q: 0=Previous, 2=Current
As written in my post above, for annual values (X=3) W does not need to be a fixed value (W=2), any value of W will give the same result. I assume the same is true for Q and W with the total values (X=). Haven't checked this, though.
BTW: I just noticed the b516 registers can also be read from the hydraulic station (inside unit) of my HP (MF=Vaillant;ID=VWZ00;SW=0522;HW=5103) which houses the backup (immersion) heater. The energy statistics are then for the backup heater. So another device supporting this - nice!
And: Since HP can also cool, there should also be separate cooling energy statistics. I suspect there is another Z value for this (0=All, 3=Heating, 4=Hot water, ?=Cooling). Will look for this at a warmer time of the year (I normally don't use cooling).
As written in my post above, for annual values (X=3) W does not need to be a fixed value (W=2), any value of W will give the same result. I assume the same is true for Q and W with the total values (X=). Haven't checked this, though.
I'd prefer to use values that cltv2 is using as "safe" ones. As you noted, it might be totally irrelevant, but it might be relevant to certain device only while others ignore it, or these might be "reserved for future use" and may change over time. If we encounter any regulation device that sends different values we could investigate further if those devices do get back different values.
BTW: I just noticed the
b516registers can also be read from the hydraulic station (inside unit) of my HP
I was pondering if ebus has anything that might help to figure out if the device supports this kind of commands - ie by sending a single b516 and see if the device replies with a valid reply then load appropriate inc/csv files...
I'd prefer to use values that
cltv2is using as "safe" ones.
OK, I see this point.
BTW: I just noticed the
b516registers can also be read from the hydraulic station (inside unit) of my HPI was pondering if ebus has anything that might help to figure out if the device supports this kind of commands - ie by sending a single
b516and see if the device replies with a valid reply then load appropriate inc/csv files...
I don't think it is possible within ebusd right now. Only way I think is to probe product/HW/SW IDs (from scanning result) and then use conditions to include certain CSV files, like used here: https://github.com/eBUS/ebus.github.io/blob/main/next/en/vaillant/08.bai.csv
BTW: could you try the following b516 register on your bai unit which yields the current electrical power in W (on my HP system)? I'm just wondering how 'universal' the b516 registers are.
*r,,,,,,B516,,,,IGN:1,,,,,,,,,,,,,,,,,,,,,
r,,CurrentConsumedPowerWatt,,,,,14,,,EXP,,,current consumed electrical power (Watt),,,,,,,,,,,,,,,,,,
could you try the following
b516register on yourbai
I get an error (maybe I'm doing something wrong?):
ebusctl read -f -V CurrentConsumedPowerWatt
ERR: invalid position in decode: bai CurrentConsumedPowerWatt
And the log is:
2025-03-02 11:30:33.806 [update error] unable to parse read bai CurrentConsumedPowerWatt from 3108b5160114 / 00: ERR: invalid position
2025-03-02 11:30:33.806 [bus notice] >3108b516011451<000000>00
2025-03-02 11:30:33.806 [main error] read bai CurrentConsumedPowerWatt: decode ERR: invalid position
I get an error (maybe I'm doing something wrong?):
Ok thanks. No, the message sent by the master looks OK (08b5160114). Obiously, it doesn't work for your unit. We previously found for the HP units that this register was introduced with later firmwares (SW>9).
There is a second register which yields the current electrical power from the b509 region (a block which contains a lot of diagnostic data) working also with older firmwares of our HP units. Not sure, whether the b509 data are really device-specific, though.
*r,,,,,,B509,540200,,,IGN:4,,,,,,,,,,,,,,,,,,,,,
r,,RunDataCurrentConsumedPower,,,,,5B0D,,,EXP,,W,current consumed electrical power (Watt),,,,,,,,,,,,,,,,,,
- Z: 0=All, 3=Heating, 4=Hot water
I could now confirm for the Arotherm heat pump:
Z=5 - Cooling energy statistics
Even the mixer function module VR71 (FM5, MF=Vaillant;ID=VR_71;SW=0104;HW=0503) has its own b516 energy statistics (power consumption around 2 kWh/month), counting maybe the power consumptions of the connected pumps/mixer unit? Another proof that this register block is indeed present in many devices. Maybe you should rename the PR with something like "general b516 energy statistics"?
The 'total system electrical energy' values given by the regulator indeed seem to be the sum of the energies consumed (and reported) by the individual devices.
BTW: everytime just before the energy statistics are polled at midnight from the different devices, the regulator sends a "generic" b516 11 message to the slaves. The response seems to be always the same, maybe some sort of configuration...? Do you find this message, too?
2025-03-02 00:00:01.262 [update notice] received unknown MS cmd: 1008b5160111 / 09020309100934090a09
2025-03-02 00:00:01.530 [update notice] received unknown MS cmd: 1026b5160111 / 090103010e0130010301
...
2025-03-02 23:59:59.025 [update notice] received unknown MS cmd: 1008b5160111 / 09020309100934090a09
2025-03-02 23:59:59.294 [update notice] received unknown MS cmd: 1026b5160111 / 090103010e0130010301
BTW: everytime just before the energy statistics are polled at midnight from the different devices, the regulator sends a "generic"
b516 11message to the slaves. The response seems to be always the same, maybe some sort of configuration...? Do you find this message, too?
@chrizzzp Yup, have it here as well.
ebusd-1 | 2025-02-26T23:00:02.145817884Z 2025-02-27 00:00:02.145 [update info] received MS cmd: 1008b5160111 / 09020309100934090a09
ebusd-1 | 2025-02-26T23:00:02.145913754Z 2025-02-27 00:00:02.145 [update notice] received unknown MS cmd: 1008b5160111 / 09020309100934090a09
ebusd-1 | 2025-02-27T23:00:01.102186537Z 2025-02-28 00:00:01.101 [update info] received MS cmd: 1008b5160111 / 09020309100934090a09
ebusd-1 | 2025-02-27T23:00:01.102264981Z 2025-02-28 00:00:01.101 [update notice] received unknown MS cmd: 1008b5160111 / 09020309100934090a09
ebusd-1 | 2025-02-28T23:00:00.705780479Z 2025-03-01 00:00:00.705 [update info] received MS cmd: 1008b5160111 / 09020309100934090a09
ebusd-1 | 2025-02-28T23:00:00.705908386Z 2025-03-01 00:00:00.705 [update notice] received unknown MS cmd: 1008b5160111 / 09020309100934090a09
ebusd-1 | 2025-03-01T23:00:01.288851736Z 2025-03-02 00:00:01.288 [update info] received MS cmd: 1008b5160111 / 09020309100934090a09
ebusd-1 | 2025-03-01T23:00:01.288913920Z 2025-03-02 00:00:01.288 [update notice] received unknown MS cmd: 1008b5160111 / 09020309100934090a09
ebusd-1 | 2025-03-02T23:00:01.468220624Z 2025-03-03 00:00:01.467 [update info] received MS cmd: 1008b5160111 / 09020309100934090a09
ebusd-1 | 2025-03-02T23:00:01.468323697Z 2025-03-03 00:00:01.467 [update notice] received unknown MS cmd: 1008b5160111 / 09020309100934090a09
ebusd-1 | 2025-03-03T23:00:01.037594141Z 2025-03-04 00:00:01.037 [update info] received MS cmd: 1008b5160111 / 09020309100934090a09
ebusd-1 | 2025-03-03T23:00:01.037713751Z 2025-03-04 00:00:01.037 [update notice] received unknown MS cmd: 1008b5160111 / 09020309100934090a09
Z=5 - Cooling energy statistics
Added to first post - thanks.
Maybe you should rename the PR with something like "general
b516energy statistics"?
We're still not at PR stage, but we're getting close. For this discussion maybe "Reveres engineering b516 energy statistics" would be OK?
BTW: everytime just before the energy statistics are polled at midnight from the different devices, the regulator sends a "generic"
b516 11message to the slaves. The response seems to be always the same, maybe some sort of configuration...? Do you find this message, too?
Yes - mine is always 1008b5160111 / 090105040e0430040a04. I ignored these earlier, but now I'm thinking that in this way the cltv2 is actually asking bai what statistic can be read from it and based on the reply it actually goes into reading them out. I guess at some point (if the assumption is correct) we might first query the device with b516 11 and only then load the appropriate ebusd definitions. Out of curiosity I might change the display language to see if the reply changes...
What is returned when you asked your boiler for some unsupported value? E.g.:
Z=5
ebusctl decode exp $(ebusctl hex 08b516081000ffff03052132 | tail -c 10)
0.0
I'd say that all b516 devices simply return 0 for unsupported statistics (as noted earlier by @chrizzzp: For 4=Gas my HP returns 0.)
Would be great to have a single TypeSpec definition for as many units as possible.
Yes it would. If you're up to it you're more than welcome to prepare the actual commits/PR since I don't have too much experience with all of this and my boiler probably has only a small subset of statistics that your HP is able to provide.
Z=5 - Cooling energy statistics
Added to first post - thanks
Could you also add:
Y=2 environmental energy
This is the energy heat pumps extract from the air (or ground source).
Thanks.
Y=2 environmental energy
Added - I also changed the tile while at it...
Thanks.
Added - I also changed the tile while at it...
There's a typo in the title, should be 'reverse' I guess?
I explored a bit more of the b516 registers. I observed in the logs that even the regulator (MF=Vaillant;ID=CTLV2;SW=0514;HW=1104) provides energy statistics, although it has a rather low power consumption (around 0.6 kWh per month).
-
electrical energy consumption (Y=3)
e.g. total consumption:
15b516081000ffff03002132 / 0b0000ff0300643200429346 -
new: solar energy from solar water circuit (Y=1) controlled by the
ctlv2
(in my special case the solar circuit is actually a water-bearing chimney, but this is not important here, usually these solar circuits are connected to solar heat panels on the roof, feeding a storage water cylinder)
f115b516081000ffff01000000 / 0b0000ff010064308079084a
I found this by tracking the traffic between the internet gateway VR921 (master ID f1) and the ctlv2 (slave ID 15). And no, the gateway does not deliver b516 energy statistics...
Obviously, the gateway (Vaillant server) reads the total values (X=0) slightly different than the regulator: the last four bytes (including W/Q) are set to 0000 (not 2132, like the regulator polls total values). This means for total values, the last four bytes can probably be ignored.
And the byte following the ffff seems to be variable, too (8 and 4 in the following examples).
f108b516081000ffff84030000 / 0b1000ff8403643000000000
f108b516081000ffff84040000 / 0b1000ff8404643000000000
f108b516081000ffff83030000 / 0b0000008303643084e4be49
f108b516081000ffff83040000 / 0b0000038304643000000000
f108b516081000ffff83050000 / 0b00000683056430ffff2e44
f108b516081000ffff42030000 / 0b0000014203643012b18e4a
f108b516081000ffff42040000 / 0b0000044204643000000000
f108b516081000ffff42050000 / 0b0000074205643000000000
Interestingly, Vaillant does not seem to know I don't have a gas boiler...
The last block using Y=9 is interesting again. I'm not sure what kind of 'total' energies it shows. Maybe you can have a look on your units?
BTW: for my system only the heat pump returns energy values with Y=9. All other devices (vwz00, ctlv2, vr_71) return 0.
Edit: Seems to be related to environmental energy (similar energies, however they are different).
f108b516081000ffff49030000 / 0b000002490364303888ae4a
f108b516081000ffff09040000 / 0b00000509046432e9eb6949
f108b516081000ffff49050000 / 0b00000849056430ffdfab45
@chrizzzp Supporting energy stats for system regulators seems to be the most promising first step, IMHO.
It’s also safer than polling the heat generator directly.
What stats are available from your regulator?
@filippz We probably shouldn’t poll that many (~30) registers regularly… 😅
Might be better to simply define the registers and tag them as u (i.e. update/passive) only.
While I generally agree we shouldn't mess with the heat generators too much by generating a lot of ebus traffic, I think in the special case of the b516 energy statistics we are bound to poll them from the circuits directly, if we want the full data. Based on my ebus traffic analysis, during the nightly poll my regulator (ctlv2) seems to read from the heat pump only:
- monthly electrical energy values of the current and previous month (all modes/heating/dhw/cooling)
- annual electrical energy values of the current and previous year (all modes/heating/dhw/cooling)
- system cumulative electrical energy values (all modes/heating/dhw/cooling)
- monthly environmental energy values of the current and previous month (all modes only)
- annual environmental energy values of the current and previous year (all modes only)
- system cumulative environmental energy value (all modes only)
Statistics 1. to 3. are also polled every night from vwz00 and vr_71, but these data don't appear directly but - I assume - are used to calculate total electrical energy values for the complete system (as shown in the regulator).
This "reduced" set of energy data seems to be polled by the "current" generation of regulators (ctlvx, basvx, ...), while other ("previous") regulators indeed polled more values (e.g. monthly data for the complete two years, as shown in the picture below for the VRC700 regulator). I wonder why Vaillant didn't implement these detailed statistics also in the newer regulators...
Note: Interestingly, according to my logfiles Vaillant (i.e. VR921) polls only total values (no annual/monthly data). So it seems they generate their own statistics shown in their MyVaillant app.
However, if we want to limit the polls to the "newer" regulators, we'll have to find the 'copy' registers in the regulators, which contain the energy statistics, because the b516 block of e.g. the ctlv2 contains only the particular energy statistics of the regulator circuit (and solar circuit in my case), not the statistics from the heat generator circuits etc.
Anyway, a few of these 'copy' registers for the ctlvx/basvx are known, some are missing (e.g. for cooling and all modes):
15.ctlv2.csv:
*r,,,,,,B524,02000000,,,IGN:4,,,
*w,,,,,,B524,02010000,,,,,,
r,,SolarYieldTotal,total solar yield,,,,3D00,,,energy4,,,solar yield total
r,,YieldTotal,total environmental yield,,,,3E00,,,energy4,,,envrionment yield total
r;w,,PrEnergySumHcThisMonth,this months energy consumption heating,,,,4F00,,,energy4,,,current month electricity consumption heating
r;w,,PrEnergySumHwcThisMonth,this months energy consumption hot water,,,,5000,,,energy4,,,current month electricity consumption hot water
r;w,,PrEnergySumHcLastMonth,last months energy consumption heating,,,,5300,,,energy4,,,last month electricity consumption heating
r;w,,PrEnergySumHwcLastMonth,last months energy consumption hot water,,,,5400,,,energy4,,,last month electricity consumption hot water
r;w,,PrEnergySumHc,total energy consumption heating,,,,5700,,,energy4,,,total year electricity consumption heating
r;w,,PrEnergySumHwc,total energy consumption hot water,,,,5800,,,energy4,,,total year electricity consumption hot water
In my oppinion we should leave polling the complete b516 registers optional, e.g. by putting all these registers in a separate e.g. b516_statistics.inc CSV, to be invoked "per request" by the different circuits. The good thing is that the b516 registers really seem to be "universal" for many circuits and will result in a zero-value response (no error message) if a certain energy statistic is not present on a particular device. Consequently, one b516_statistics.inc could be used for all devices.
There's a typo in the title, should be 'reverse' I guess?
Fixed - thanks.
2. new: solar energy from solar water circuit (Y=1)
Added to first post.
The last block using Y=9 is interesting again. I'm not sure what kind of 'total' energies it shows. Maybe you can have a look on your units?
bai returns 0 - I guess my combo with only gas boiler + regulator is the most simple one of the lot so a lot of readings don't make too much sense but won't throw an error, or mess something up.
We probably shouldn’t poll that many (~30) registers regularly… 😅
Might be better to simply define the registers and tag them asu(i.e. update/passive) only.
Agreed - I only really use 2 (total electrical energy and gas). 30 commands/replies is what my ctlv2 does but just once a day.
I guess we could try using TypeScript to to define a couple of arrays (X,Y,Z,W+Q) and use for loops to loop trough those arrays and dynamically generate all the combinations/definitions. But as you noted - the real questions is whether there is any reason to have all the definitions, or just the "most useful ones".
BTW: Here are some more registers from the ctlv2 which should contain the energy statistics for the gas consumption of the bai units. Wanna try?
*r,,,,,,B524,02000000,,,IGN:4,,,
*w,,,,,,B524,02010000,,,,,,
r;w,,PrFuelSumHcThisMonth,this months fuel consumption heating,,,,4E00,,,energy4,,,current month fuel consumption heating
r;w,,PrFuelSumHwcThisMonth,this months fuel consumption hot water,,,,5100,,,energy4,,,Current Month fuel consumption hot water
r;w,,PrFuelSumHcLastMonth,last months fuel consumption heating,,,,5200,,,energy4,,,last month fuel consumption heating
r;w,,PrFuelSumHwcLastMonth,last months fuel consumption hot water,,,,5500,,,energy4,,,last month fuel consumption hot water
r;w,,PrFuelSumHc,total fuel consumption heating,,,,5600,,,energy4,,,total year fuel consumption heating
r;w,,PrFuelSumHwc,total fuel consumption hot water,,,,5900,,,energy4,,,total year fuel consumption hot water
r;w,,PrFuelSum,total fuel consumption,,,,5D00,,,energy4,,,total year fuel consumption
Template:
energy4,ULG,,kWh,
Agreed - I only really use 2 (total electrical energy and gas). 30 commands/replies is what my
ctlv2does but just once a day. I guess we could try using TypeScript to to define a couple of arrays (X,Y,Z,W+Q) and use for loops to loop trough those arrays and dynamically generate all the combinations/definitions. But as you noted - the real questions is whether there is any reason to have all the definitions, or just the "most useful ones".
@filippz We can certainly define every single register. I‘ll probably do it by hand though. 🤓
As long as these registers are passive, they’ll only show up if actually supported and polled by other devices on the bus.
This should be the safest, and most efficient option to get those energy stats.
@chrizzzp I think Vaillant realized that they can get away with much less bus traffic, and still provide somewhat usable energy stats. 😅
Best route forward, IMO, is to define all registers, but not actively poll them ourselves.
AFAICT, energy stats from system regulators don’t seem to be that useful after all.
@filippz
I am newbie in using John30's ebusd but very interested in being able to collect energy data from my gas boiler.
My model is VMW 32CS/1-5 (N-ES) ("MF=Vaillant;ID=BAI00;SW=0806;HW=7603") and the regulator is VRT 380f but haven't show energy statistics.
I've played with X=1 but I only get a nonzero value for 08b516081001ffff04036132. I get 41 Kwh. It is a value that can be for a day but I couldn't check for which correspond. From the boiler's panel I only have for the Heating circuit a yesterday gas consuption of 27 Kwh.
Interesting find. I also get a few non-zero values from my heat pump with X=1. Of course, not for gas (Y=4), but for electricity (Y=3), environmental energy (Y=2) and the "environmental-related", yet unknown energy (Y=9). And so far only for 'heating' (Z=3) and 'all' (Z=0, same as for heating).
Haven't iterated W/Q yet...
08b516081001ffff03036132 / 0b0109000303613200081f46
08b516081001ffff02036132 / 0b010901020361320096fe46
08b516081001ffff09036132 / 0b0109020903613200011547
Could these be yesterdays energies?
I've played with X=1 but I only get a nonzero value for 08b516081001ffff04036132. I get 41 Kwh.
I've tried with ebusctl decode exp $(ebusctl hex 08b516081001ffff04036132 | tail -c 10) and I get 33733 Wh back (34kWh) which doesn't correspond to any value for today/yesterday displayed on the boiler.
Haven't iterated W/Q yet...
For me, only W/Q combo that doesn't return 0.0 for X=1 is 6/2 - I wonder if W13Q should be something other than 13....
I wonder if W13Q should be something other than 13....
I thought the value of “13” was fixed.
Iterating with the first digit “1” and for gas consumption of the heating circuit and current month:
08b516081001ffff04036132 | 41750 |
08b516081001ffff04036232 | 49036 |
08b516081001ffff04036332 | 49840 |
08b516081001ffff04036432 | 33700 |
08b516081001ffff04036532 | 28729 |
08b516081001ffff04036632 | 30838 |
08b516081001ffff04036732 | 34571 |
08b516081001ffff04036832 | 42183 |
08b516081001ffff04036932 | 27697 | matches my gas consumption the day before yesterday
08b516081001ffff04036a32 | 38103 | matches my gas consumption yesterday
08b516081001ffff04036b32 | 0.0 | I have not turned it on today
08b516081001ffff04036c32 | 0.0 |
08b516081001ffff04036e32 | 0.0 |
08b516081001ffff04036f32 | 0.0 |
later with more time I will continue testing.
Obviously we work in parallel... ;-)
which doesn't correspond to any value for today/yesterday displayed on the boiler.
Correct, when reading them today these values do not change.
For me, only W/Q combo that doesn't return 0.0 for X=1 is 6/2 - I wonder if W13Q should be something other than 13....
I (also) now iterated the first digit after W and got non-zero values (see below). I think we need to extend the variable names: I suggest V for the digit following W (as XYZ is already taken...) and U for the second digit.
100Xffff0Y0ZWVUQ
I get 11 non-zero values with X=1, Y=2/3/9, Z=0/3/4, W=6, U=3, Q=2 when iterating V from 1 to B (hex), e.g.
08b516081001ffff03036132 / 0b010a000303613200081f46
08b516081001ffff03036B32 / 0b01000003036b32b6c1c445
08b516081001ffff04036932 | 27697 | matches my gas consumption the day before yesterday
08b516081001ffff04036a32 | 38103 | matches my gas consumption yesterday
08b516081001ffff04036b32 | 0.0 | I have not turned it on today
Same here (but for electric energy).
Since we have the 11th of March today I think these correspond to the daily statistics for the current month!
So tomorrow we should have a non-zero value for V=C (12th)...
...and maybe U is incremented after the the 15th of the month.
Yes, I think this is the case and confirms @filippz initial guess, that X=1 refers to daily statistics. So, U and V are used to index the days.
For X=0/2/3 I get identical energy values for every "day".
Found some more non-zero daily statistcis with W=5, and V ranging from 8 to C.
ebusctl decode exp $(ebusctl hex 08b516081001ffff03005732 | tail -c 10) / 0.0
ebusctl decode exp $(ebusctl hex 08b516081001ffff03005832 | tail -c 10) / 16971
ebusctl decode exp $(ebusctl hex 08b516081001ffff03005932 | tail -c 10) / 9415
ebusctl decode exp $(ebusctl hex 08b516081001ffff03005A32 | tail -c 10) / 8145
ebusctl decode exp $(ebusctl hex 08b516081001ffff03005B32 | tail -c 10) / 13692
ebusctl decode exp $(ebusctl hex 08b516081001ffff03005C32 | tail -c 10) / 12052
ebusctl decode exp $(ebusctl hex 08b516081001ffff03005D32 | tail -c 10) / 0.0
These seem to be the daily energies from the last 5 days of the previous month (february). Interestingly, there don't seem to be more values from last month.
Question: are only the values from the last 16 days (11+5) stored? We should see tomorrow if any of the W=5 values changes or is reset to zero...
@filippz Just let me know when you think we’re ready for a TypeSpec implementation. 😊
It should be feasible to have a single energy stats definition file that can be included where needed.
Question: are only the values from the last 16 days (11+5) stored? We should see tomorrow if any of the W=5 values changes or is reset to zero...
Just checked it:
a) yesterdays first value of last month 'daily energy' history (16 days ago) is zero today.
ebusctl decode exp $(ebusctl hex 08b516081001ffff03005832 | tail -c 10) / 0.0
ebusctl decode exp $(ebusctl hex 08b516081001ffff03005932 | tail -c 10) / 9415
b) todays (current) value in this month 'daily energy' history (V= 'C') is a non-zero value now
ebusctl decode exp $(ebusctl hex 08b516081001ffff03006C32 | tail -c 10) / 2059.79
So, now we have 4 values for last month (W=5) and 12 values for this month (W=6) in the daily history, which means the values of the last 15 days + todays value are stored.
Open questions:
-
is W used for the daily statistics to index the month as we found for the monthly statistics (I suspect so)?
-
is Q used to index first (Jan-Jul) and second (Aug-Dec) half of the year as found for the monthly statistics?
e.g.
Q=2
W=2/3 January
W=4/5 February
W=6/7 March
W=8/9 April
W=A/B May
W=C/D June
W=E/F July
Q=3?
W=0/1 August
W=2/3 September
W=4/5 October
W=6/7 November
W=8/9 December -
if V reaches value 'F'? (after day 15 of each month): is U iterated or rather the "second" value of W is used for the days 16-31? Is suspect the latter which would also explain why two values of W encode for each month (in the monthly statisctics), because two 16-byte blocks are needed to fit the daily energy values for 31 days.
Just let me know when you think we’re ready for a TypeSpec implementation. 😊
It should be feasible to have a single energy stats definition file that can be included where needed.
Now, with the daily energy statistics available, this will be a challenge, I think. Although only 16 days are stored in the daily energy history (as it seems now) the address range for these 16 days is "floating", as every day seems to have its own register. I wonder whether this can be accounted for in TypeSpec...
Maybe reading out the b516 energy statistics needs a completely different ("dynamic") approach?
My comparative between today and yesterday (only for Y:4=Gas, Z:3=Heating):
| hex | yesterday | today |
|---|---|---|
| 08b516081001ffff04035132 | 0.0 | 0.0 |
| 08b516081001ffff04035232 | 0.0 | 0.0 |
| 08b516081001ffff04035332 | 0.0 | 0.0 |
| 08b516081001ffff04035432 | 0.0 | 0.0 |
| 08b516081001ffff04035532 | 0.0 | 0.0 |
| 08b516081001ffff04035632 | 0.0 | 0.0 |
| 08b516081001ffff04035732 | 0.0 | 0.0 |
| 08b516081001ffff04035832 | 0.0 | 0.0 |
| 08b516081001ffff04035932 | 0.0 | 0.0 |
| 08b516081001ffff04035a32 | 19184 | 0.0 |
| 08b516081001ffff04035b32 | 19926 | 19926 |
| 08b516081001ffff04035c32 | 943 | 943 |
| 08b516081001ffff04035d32 | 0.0 | 0.0 |
| 08b516081001ffff04035e32 | 0.0 | 0.0 |
| 08b516081001ffff04035f32 | 0.0 | 0.0 |
| 08b516081001ffff04036132 | 41750 | 41750 |
| 08b516081001ffff04036232 | 49036 | 49036 |
| 08b516081001ffff04036332 | 49840 | 49840 |
| 08b516081001ffff04036432 | 33700 | 33700 |
| 08b516081001ffff04036532 | 28729 | 28729 |
| 08b516081001ffff04036632 | 30838 | 30838 |
| 08b516081001ffff04036732 | 34571 | 34571 |
| 08b516081001ffff04036832 | 42183 | 42183 |
| 08b516081001ffff04036932 | 27697 | 27697 |
| 08b516081001ffff04036a32 | 38103 | 38103 |
| 08b516081001ffff04036b32 | 0.0 | 34793 |
| 08b516081001ffff04036c32 | 0.0 | 0.0 |
| 08b516081001ffff04036e32 | 0.0 | 0.0 |
| 08b516081001ffff04036f32 | 0.0 | 0.0 |
In my case, I believe that yesterday's value will be enough for register it in HA.
Thanks, your analysis confirms what I observed.
In my case, I believe that yesterday's value will be enough for register it in HA.
The problem: the Ebus register for "yesterday" (daily energy) is different for every day and therefore cannot simply be used as a "general" HA entity definition in the CSV.
@chrizzzp
Today's testing continues to confirm the assumptions for the values for W="6", days of the current month.
Regarding the values for W="5" I don't quite understand it. I explain:
- Before yesterday, V="a" had the value 19184 and yesterday it became 0.
- Before yesterday and yesterday, V="b" had the value 19926 and today it became 0.
- It is not clear what these values correspond to because I haven't had a way to check them.
@filippz
I would like to test with local configuration files but I don't known what is the logic to add the entries to _templates.csv and bai.308523.inc. Also the changes in mqtt-hassio.cfg
You tested by using:
r,,EnergySumHcPreviousYear,,,,b516,1003ffff03032130,,,IGN:7;energye,,,
but @chrizzzp mention that there is an -i (index) option:
*r,,,,,,B516,,,,IGN:1,,,,,,,,,,,,,,,,,,,,,
r,,CurrentConsumedPowerWatt,,,,,14,,,EXP,,,current consumed electrical power (Watt),,,,,,,,,,,,,,,,,,
Could you tell me some reference to understand how to build these files (including the template) to be able to test locally?
@filippz
I interested in known What will be your proposal for this PR?
Do you have enough information or do you think more testing and analysis is needed?
If you need any proof from my side, let me know.
Nice progress with daily values!
While I do think that documenting all the findings (like the role of VU) is important, we have already had discussions whether there is any real world usage case in which defining all those messages makes sense. I for example use only two messages (total gas consumption for hot water and heating) and use HA which stores those values in it's database with date/time after which they can be used in a much more friendly manner.
Earlier, @burmistrzak suggested defining all the messages as passive so everyone can use them only when actually needed, but if we want to use days we would have 366 definitions (multiplied with different combinations) while as @chrizzzp and @djramipro note only the values of last 15 days are available.
Earlier, I've misread TypeSpec for TypeScript and concluded that I could use loops to iterate over "index values" of X, Y, Z, W+Q,... we know/need but I don't see loops in TypeSpec. I could reuse my LibreOffice Calc file to generate CSV entries with some modifications for time being.
I would like to test with local configuration files
I'm still using my first version described in first post (now fixed), so basically:
- append ebusd-2.1.x/en/vaillant/_templates.csv with
energye,EXP,,Wh, - append ebusd-2.1.x/en/vaillant/bai.308523.inc with
r1,,FuelSumHc,,,,b516,1000ffff04032132,,,IGN:7;energye,,,
r1,,FuelSumHwc,,,,b516,1000ffff04042132,,,IGN:7;energye,,,
- change mqtt-hassio.cfg add
|fuelto thefilter-namevalue andsensor,gas,total_increasing = fuel|,Wh$line totype_switch-number
In HA you should now see ebusd bai FuelSumHc and ebusd bai FuelSumHwc
@chrizzzp has a more elegant solution as you noted but I'm still using the old one as I was thinking of going the TypeScript loops route until I figured out that I was googling for TypeScript instead of TypeSpec
Regarding the values for W="5" I don't quite understand it. I explain:
* Before yesterday, **V="a"** had the value 19184 and yesterday it became 0. * Before yesterday and yesterday, **V="b"** had the value 19926 and today it became 0. * It is not clear what these values correspond to because I haven't had a way to check them.
Explanation is that the unit seems to store only the last 15 days (+ today), while it resets values older than 15 days (i.e. values become zero, as you observed). So we have sort of "rolling" data for the last 15 days, all other are reset to zero (I don't know why they don't store all days of the year...).
According to the current understanding, W=5 corresponds to the 'second block' of February (W=4/5) and the last three values of W=5 (V=d/e/f) remained zero, because February had only 28 days. Within the next days we will see all of these W=5 energy values become zero day by day, while more from W=6 ('first block' of March) will appear. As soon as we arrive in the 'second block' of March, W should be 7 (I guess after the 15th of March).
While I do think that documenting all the findings (like the role of VU) is important, we have already had discussions whether there is any real world usage case in which defining all those messages makes sense.
I totally agree. I think we should make all decoding information available in some way. Besides providing definitions for e.g. the total values as examples we could document all possible options as remarks, so everyone can create the definitions they're interested in.
(On could also write a script which creates these definitions based on parameters given...). Just an idea.
I've made a python script available at https://gist.github.com/filippz/c0d04e4d607e27fc6b89d127db0ee941 that generates names/payloads.
It has no support for days (X=1) and I've I've skipped Cooling on Fuel/Gas as an illogical combination (Y=4 and Z=5) which still leaves 405 combinations.
It should be fairly easy to generate actual CSV lines from it, but the generated values need testings and before all reduction to a reasonable number of useful combinations. For me "reasonable number" is just 2 as I only monitor gas consumption for heating and hot water - for HP this would be obviously more, but probably not hundreds...
Great, thanks for sharing this!
What I noticed so far:
- Incrementing W (and, V if incorporated later) should be in hexadecimal (not decimal). For example:
'SolarCurrentYearMonth4': '1002ffff01008132'
'SolarCurrentYearMonth5': '1002ffff010010132'
should be:
'SolarCurrentYearMonth4': '1002ffff01008132'
'SolarCurrentYearMonth5': '1002ffff0100A132'
- There's a typo:
'Enivormental...'
should be
'Environmental'
- I would use the suffix 'System' (or 'Total' or something like this) for all total values with X=0
- I would use the suffix 'Sum' (or something like this) for values with Z=0 (but so far these values are not included in the script)?
@chrizzzp Fixed.
Z=0 were included in the script for example as ElectricalCurrentYear and after the changes it's now named ElectricalSumCurrentYear - in both cases with 1003ffff03000132 as payload.
According to the current understanding, W=5 corresponds to the 'second block' of February (W=4/5) and the last three values of W=5 (V=d/e/f) remained zero, because February had only 28 days. Within the next days we will see all of these W=5 energy values become zero day by day, while more from W=6 ('first block' of March) will appear. As soon as we arrive in the 'second block' of March, W should be 7 (I guess after the 15th of March).
Just confirmed today, 16th of march, after V has reached value 'f' yesterday (with W=6). Today the 'second block' of march has started and W is incremented to 7 (V=0).
ebusctl decode exp $(ebusctl hex 08b516081001ffff03007032 | tail -c 10) / 11505.2
@filippz Maybe we should update the first post to summarize our findings.
And confirmed from my side:
/ # ebusctl decode exp $(ebusctl hex 08b516081001ffff04036132 | tail -c 10) 0.0 (1st of March)
/ # ebusctl decode exp $(ebusctl hex 08b516081001ffff04036232 | tail -c 10) 0.0 (2nd of March)
/ # ebusctl decode exp $(ebusctl hex 08b516081001ffff04036332 | tail -c 10) 49840
...
/ # ebusctl decode exp $(ebusctl hex 08b516081001ffff04036f32 | tail -c 10) 40991 (15th of March)
/ # ebusctl decode exp $(ebusctl hex 08b516081001ffff04037032 | tail -c 10) 30287 (16th of March)
@filippz AFAIK, we’ll have to eventually write out all different register combinations. One way or another. 😅
Passive registers are not actively polled. ebusd is only listening for these registers on the eBus.
So if some register is not supported by a particular device, it simply won’t show up on the bus, cause any errors, or be added to the internal cache.
Edit: I might be able to abuse your Python script to generate a TypeSpec file as a starting point.
Sorry for not being able to dedicate some time to this - I had other unexpected things to solve (mental/physical exercise in figuring out how AdBlue is used in TDI engines)
Maybe we should update the first post to summarize our findings.
You're referring to "V" and "U" for daily values? Can you suggest what to actually change in the first post - I haven't really worked with daily values so I guess you're be able to provide more meaningful explanation
AFAIK, we’ll have to eventually write out all different register combinations
I might be able to abuse your Python script to generate a TypeSpec file as a starting point.
Please do! The primary reason for it's creation is to demonstrate all the possible values (without the support for daily values) and when the agreement about actual usefulness of those is agreed the it can be adapted to generate actual values for commit/PR. I've also seen that it's possible to generate TypeSpec from CSV so it might be easier to generate CSV entries and convert it to TypeSpec
And totally off topic: do any of you actually use HP for cooling? I'm in the process of planing heating/cooling systems for a family home and there is a lot of conflicting opinions especially in the area of using HP for cooling so experience of more sophisticated users like yourselves would help a lot.
Please do! The primary reason for it's creation is to demonstrate all the possible values (without the support for daily values) and when the agreement about actual usefulness of those is agreed the it can be adapted to generate actual values for commit/PR. I've also seen that it's possible to generate TypeSpec from CSV so it might be easier to generate CSV entries and convert it to TypeSpec
@filippz Yes, CSV-to-TypeSpec works reasonably well.
We certainly can add all registers, doesn’t really matter when they’re defined as passive. 😊
And totally off topic: do any of you actually use HP for cooling? I'm in the process of planing heating/cooling systems for a family home and there is a lot of conflicting opinions especially in the area of using HP for cooling so experience of more sophisticated users like yourselves would help a lot.
Our aroTHERM plus is configured for cooling, but our first summer with this thing is still ahead of us. We‘ll be trying out underfloor cooling, mainly in the living room.
Theoretically, excess PV energy and cooling are a match made in heaven, but I‘m not sure how effective it actually will be… 🤞
And totally off topic: do any of you actually use HP for cooling? I'm in the process of planing heating/cooling systems for a family home and there is a lot of conflicting opinions especially in the area of using HP for cooling so experience of more sophisticated users like yourselves would help a lot.
Our aroTHERM plus is configured for cooling, but our first summer with this thing is still ahead of us. We‘ll be trying out underfloor cooling, mainly in the living room. Theoretically, excess PV energy and cooling are a match made in heaven, but I‘m not sure how effective it actually will be… 🤞
My HP is also prepared to cool (it needs a special coding resistor), but I have only partially tested it as my house is not fully prepared for cooling yet. One issue I see with this type of cooling is the relative humidity of the air and the corresponding dew point which (if not monitored) could easily lead to condensation problems. My underfloor heating is underneath a wooden floor so I definitely don't want any condensate water there. Alternatives are HP-driven convectors that cool the air (and not the floor), e.g. the Vaillant aroVAIR units.
I was told from a Vaillant engineer one should not expect the same cooling capacities from a HP-driven cooling systems as those a regular AC unit can provide. The temperature gradient is really smaller here and AFAIK in floor cooling no active dehumidification takes place (I think the convectors do dry the air).
So I assume while one can indeed lower the room temperature with HPs in floor cooling mode, it will not "feel" as cool as the relative humidity increases with lower temperature (unless dehumidifaction is involved). But as I said, no real practical experience from my side...
You're referring to "V" and "U" for daily values? Can you suggest what to actually change in the first post - I haven't really worked with daily values so I guess you're be able to provide more meaningful explanation
OK, here's my suggestion for the summary including the daily energy statistics in order to update the first post:
commands from b516 with payload: 100Xffff0Y0ZWV3Q with
X (energy statistics by): 0=Total, 1=Day, 2=Month, 3=Year
Y (energy source): 1=Solar, 2=Environmental, 3=Electricity, 4=Gas, (9=unidentified heat pump-related)
Z (energy usage): 0=Sum, 3=Heating, 4=Hot water, 5=Cooling
W (month index): from 2 to F=January to July, from 0 to 9=August to December (depending on Q)
- two W values per month, only last 24 month are stored
- 1st half year (Q=0/2): W=2/3 January, W=4/5 February, W=6/7 March, W=8/9 April, W=A/B May, W=C/D June, W=E/F July
- 2nd half year (Q=1/3): W=0/1 August, W=2/3 September, W=4/5 October, W=6/7 November, W=8/9 December
V (day index): from 0 to F (depending on W)
- only last 16 days are stored
- 1st half of month (first/even W value): 1=day 1 ... F=day 15
- 2nd half of month (second/uneven W value): 0=day 16 ... F=day 31
Q (year index): 0/1=previous year, 2/3=current year
- only last two years are stored
- previous year: Q=0: Jan-Jul, Q=1: Aug-Dec
- current year: Q=2: Jan-Jul, Q=3: Aug-Dec (to be confirmed)
payload examples:
1001ffff03005732 - daily sum of electrical energy consumption on Feb 23 of the current year
1002ffff02039131 - monthly environmental yield used for heating in Dec of previous year
1003ffff04042132 - this years gas consumption used for water heating (DHW)
1000ffff01002132 - total solar yield of the system (since installation)
example command:
ebusctl hex 08b516081001ffff03005732
@filippz
Just edited my previous post with a suggestion for the summary including the daily energy statistics in order to update the top post. Let me know if there are any errors.
Just edited my previous post with a suggestion
Would you mind updating your script to also include daily stats?
@chrizzzp @burmistrzak
I've updated the first post with your suggestions but rearranged it a bit. I'm off to update the script with daily values and see if there is any mismatched with the contents of the first post.
I've updated the first post with your suggestions but rearranged it a bit. I'm off to update the script with daily values and see if there is any mismatched with the contents of the first post.
OK, maybe you could remove the striked-out entries (or keep them separate)? They might confuse people and the formatting gets lost during copy/paste.
Edit: And mabye you could add the information that for daily stats only the last 16 days are stored.
OK, maybe you could remove the striked-out entries (or keep them separate)? They might confuse people and the formatting gets lost during copy/paste.
Edit: And mabye you could add the information that for daily stats only the last 16 days are stored.
Done - thanks.
I'm off to update the script with daily values
@burmistrzak
Script has been updated - it now generates 11565 combinations 🤦
Script has been updated - it now generates 11565 combinations
Impressive... thanks for the update! I think we can halmost half this number just by discarding almost all of the daily statistics for the previous year (Q=0/1). As only 16 days are stored we only need the last 16 days of the previous year. All other daily stats values from the previous year will always be zero.
Still too much to be included in CSVs...
Generally, as @filippz mentioned earlier, the real world benefit of most of the b516 energy statistics is questionable. Although it is satisfying to have them decoded and I think it's good to share them, I believe all that is needed (and most important) are the total ('System') energy values, from which all other values can be deduced outside of ebusd (as long a the total values are tracked on a daily basis). So this would be the following 15 payloads (taken from the script output):
1000ffff01000030 SolarSumSystem
1000ffff01030030 SolarHeatingSystem
1000ffff01040030 SolarHotWaterSystem
1000ffff01050030 SolarCoolingSystem
1000ffff02000030 EnvironmentalSumSystem
1000ffff02030030 EnvironmentalHeatingSystem
1000ffff02040030 EnvironmentalHotWaterSystem
1000ffff02050030 EnvironmentalCoolingSystem
1000ffff03000030 ElectricalSumSystem
1000ffff03030030 ElectricalHeatingSystem
1000ffff03040030 ElectricalHotWaterSystem
1000ffff03050030 ElectricalCoolingSystem
1000ffff04000030 FuelSumSystem
1000ffff04030030 FuelHotWaterSystem
1000ffff04040030 FuelHotWaterSystem
BTW: for definition naming in the CSV I suggest to change the order of the name-parts and (Edit: no maybe not the best idea) add a prefix that distinguishes these definitions as energy statistics, e.g. EStat, Energy or similar.
Something like this (@filippz I know, this might need some rearrangements in your script...):
SolarSumSystem -> EnergySolarSumSystem
SolarHeatingSystem -> EnergySolarHeatingSystem
etc.
All other values could be easily extracted from the script output if someone is interested in them.
What do you think?
As only 16 days are stored we only need the last 16 days of the previous year.
I did think of that, but it might be that some devices (either existing or possibly future ones) do/will keep track of more than 16 days. On the other hand, the same logic could be applied to Q values as some devices might keep track of more than 1 year in the past...
I believe all that is needed (and most important) are the total ('System') energy values
Agreed. IMHO those are all that is needed - for example, since I'm monitoring electricity with Shelly I'm only interested in gas consumption on my boiler, and I'm just using r1 for reading gas consumption for heating and hot water polling which renders quite nicely in HA (one random day displayed):
If we decide to use only those System values then previously discussed day definitions might be irrelevant.
add a prefix that distinguishes these definitions as energy statistics, e.g.
EStat,Energyor similar.
I've saw entries prefixed with PrEnergy in bai csv, but I didn't figure out what what Pr would stand for. On the other hand, I deliberately avoided using Energy since I'm not entirely sure how it would affect mqtt-hassio.cfg so I changes it like this (form the first post):
Since I use those in Home Assistan, I've had to add |fuel to the filter-name value and sensor,gas,total_increasing = fuel|,Wh$ line to type_switch-number in mqtt-hassio.cfg
I'm fairly certain that using EStat (or something like that) wouldn't break anything
As only 16 days are stored we only need the last 16 days of the previous year.
I did think of that, but it might be that some devices (either existing or possibly future ones) do/will keep track of more than 16 days. On the other hand, the same logic could be applied to Q values as some devices might keep track of more than 1 year in the past...
OK, then it's good to have them in the script if required. I also favor not putting daily statistics in the CSVs...
I've saw entries prefixed with PrEnergy in bai csv, but I didn't figure out what what Pr would stand for. On the other hand, I deliberately avoided using
Energysince I'm not entirely sure how it would affect mqtt-hassio.cfg so I changes it like this (form the first post):
'Pr' could stand for 'PredictiveMaintenanceData'.
We could also adopt this prefix, but would have to makes sure they are not mixed up with other Pr* data which are sometimes from different b5 blocks. Then maybe 'PrEnStat' or something like this...
If we follow existing conventions then we should probably also substitute the following?
heating -> hc
hot water -> dhw
'Pr' could stand for 'PredictiveMaintenanceData'.
@chrizzzp That‘s a new one for me. 😅
Anyhow, the aforementioned 15 registers look like a solid starting point!
I assume all of them are updated regularly, without polling?
On the other hand, I deliberately avoided using Energy since I'm not entirely sure how it would affect mqtt-hassio.cfg so I changes it like this (form the first post):
@filippz Using something like e.g. EnergyStats* as a prefix shouldn’t be a problem, AFAICT.
Theoretically, no changes to the MQTT config required. Ideally, the names we settle on are globally (i.e. project-wide) unique.
If we follow existing conventions then we should probably also substitute the following?
heating -> hc hot water -> dhw
Let’s keep heating b/c of cooling, and change hot water to hwc.
I assume all of them are updated regularly, without polling?
In my case they are being queried by ctlv2 on either start of ctlv2 or midnight when ctlv2 requests fresh data. I didn't see bai sending them periodically by itself.
sing something like e.g.
EnergyStats*as a prefix shouldn’t be a problem, AFAICT.
Theoretically, no changes to the MQTT config required. Ideally, the names we settle on are globally (i.e. project-wide) unique.
IIRC I needed to adopt mqtt-hassio.cfg in order to get proper units (Wh) and to able to add gas consumption to the appropriate area of HA Energy sensors which HP don't have and therefore might not need any changes in mqtt-hassio.cfg - to be safe I intentionally avoided using Energy in that context:
Let’s keep
heatingb/c ofcooling, and change hot water tohwc.
In my view we should either use:
- all "short notation", like Hc, Hwc and Cc (as in Cooling circuit, same as Hc might be Heating circuit)
- all "long notation" like Heating, HotWater and Cooling (like script is doing right now)
In any case - I suppose we'll get some more feedback once we create the PR, so it might not be that important to "get it" perfect for the initial commit/PR.
'Pr' could stand for 'PredictiveMaintenanceData'.
That‘s a new one for me. 😅
I assumed this from some bai definition files (e.g. here).
Let’s keep heating b/c of cooling, and change hot water to hwc.
In my view we should either use:
all "short notation", like Hc, Hwc and Cc (as in Cooling circuit, same as Hc might be Heating circuit)
all "long notation" like Heating, HotWater and Cooling (like script is doing right now)
I'm fine with any. From my side I think we're done here. If you need any help preparing the PR please let me know. We should probably mention that besides heat generators (bai, hmu, vwz) also regulators (e.g. VRC720) and mixer units (e.g. VR71) have their own b516 energy statistics and contribute (albeit with a low amount) to the total (electrical) energy of a heating system.
Finally found other guys trying to solve the same problem :) I have the same gas heater "MF=Vaillant;ID=BAI00;SW=1104;HW=7603" and energy reading doesn't work:
bai PrEnergyCountHc1 = (ERR: invalid position for 3108b509030df600 / 00)
bai PrEnergyCountHc2 = (ERR: invalid position for 3108b509030df800 / 00)
bai PrEnergyCountHc3 = (ERR: invalid position for 3108b509030dfa00 / 00)
bai PrEnergyCountHwc1 = (ERR: invalid position for 3108b509030dc600 / 00)
bai PrEnergyCountHwc2 = (ERR: invalid position for 3108b509030dc800 / 00)
bai PrEnergyCountHwc3 = (ERR: invalid position for 3108b509030dca00 / 00)
bai PrEnergySumHc1 = (ERR: invalid position for 3108b509030df500 / 00)
bai PrEnergySumHc2 = (ERR: invalid position for 3108b509030df700 / 00)
bai PrEnergySumHc3 = (ERR: invalid position for 3108b509030df900 / 00)
bai PrEnergySumHwc1 = (ERR: invalid position for 3108b509030dc500 / 00)
In addition I have "MF=Vaillant;ID=CTLV3;SW=0709;HW=3704" VRC720 SensoComfort unit but in terms of energy consumption it only returns one parameter:
ctlv3 PrEnergySum = (ERR: invalid position for 3115b52406020000005c00 / 00)
ctlv3 PrEnergySumHc = 111
ctlv3 PrEnergySumHcLastMonth = no data stored
ctlv3 PrEnergySumHcThisMonth = no data stored
ctlv3 PrEnergySumHwc = no data stored
ctlv3 PrEnergySumHwcLastMonth = no data stored
ctlv3 PrEnergySumHwcThisMonth = no data stored
ctlv3 PrFuelSum = no data stored
ctlv3 PrFuelSumHc = no data stored
ctlv3 PrFuelSumHcLastMonth = no data stored
ctlv3 PrFuelSumHcThisMonth = no data stored
ctlv3 PrFuelSumHwc = no data stored
ctlv3 PrFuelSumHwcLastMonth = no data stored
ctlv3 PrFuelSumHwcThisMonth = no data stored
So I can't practically read any energy consumption data into my smart home system.
Can't wait for your PR :)
and energy reading doesn't work:
bai PrEnergyCountHc1 = (ERR: invalid position for 3108b509030df600 / 00)
bai PrEnergyCountHc2 = (ERR: invalid position for 3108b509030df800 / 00)
These definitions might be valid only for certain (older?) types of heat generators. They also don't work for the recent heat pump units (hmu). That's why this issue was started (now solved). The energy statistics are available from the b516 block (not b509).
In addition I have "MF=Vaillant;ID=CTLV3;SW=0709;HW=3704" VRC720 SensoComfort unit but in terms of energy consumption it >only returns one parameter:
ctlv3 PrEnergySumHc = 111
ctlv3 PrEnergySumHcLastMonth = no data stored
ctlv3 PrEnergySumHcThisMonth = no data stored
...
Did you try to actively poll these? E.g. with
ebusctl r -f -c ctlv3 PrEnergySumHcLastMonth
@chrizzzp now I managed to switch from Docker-run ebusd to locally installed and made recommended modifications.
Question: very recently (beginning of a month?) I noticed my heater display and VRC720 device show majority of gas/electricity consumption parameters as empty (zero)!?!? Only total consumption is kept correctly. Is it possible ebusd wiped/overwrote those values in my system by error? (this happened before enabling custom configuration btw).
Regarding the new custom configuration I tried:
ebusctl r -f -c bai FuelSumHc
1.00761e+07
Is this value returned ok? It looks way too small ...
Btw @filippz could you share your CSV for energy consumption reads using b516 block? I am new to this and not quite sure how to modify it.
Question: very recently (beginning of a month?) I noticed my heater display and VRC720 device show majority of gas/electricity consumption parameters as empty (zero)!?!? Only total consumption is kept correctly. Is it possible ebusd wiped/overwrote those values in my system by error? (this happened before enabling custom configuration btw).
I'm not sure what you mean by 'custom configuration' (local CSVs?) but this should not happen. Although it is theoreticall possible to issue unintended write commands using the hex mode of ebusctl (did you use it?) if there are typos, I'm not aware of a command that erases most of the statistics. The statistics show in the regulator are updated every night after midnight. Did you check whether they are back?
You could also check directly in the heater statistics if these values are really zero.
e.g.
ebusctl decode exp $(ebusctl hex 08b516081003ffff04032132 | tail -c 10)
should give you this years total gas consumption used for heating.
Regarding the new custom configuration I tried: ebusctl r -f -c bai FuelSumHc 1.00761e+07
Is this value returned ok? It looks way too small ...
Well, could you post the definition line of FuelSumHc from the CSV?
What I assume: in contrast to the b516 statistics (in Wh), the above values are given in kWh (template energy or energy4?). Your reading would then correspond to 10'076'100 kWh. Does this make more sense? I'm not used to such high numbers, but maybe your house is a bit bigger than mine...
could you share your CSV for energy consumption reads using b516 block
I'm using only two gas/fuel values:
r1,,FuelSumHc,,,,b516,1000ffff04032132,,,IGN:7;energye,,,
r1,,FuelSumHwc,,,,b516,1000ffff04042132,,,IGN:7;energye,,,
You need to define energie in _templates.csv:
energye,EXP,,Wh,
Please note that those names may/will change in the future (for now they would be FuelHeatingSystem and FuelHotWaterSystem based on the following script: https://gist.github.com/filippz/c0d04e4d607e27fc6b89d127db0ee941)
@burmistrzak
Took me some time to set up VS Code (still struggling with the whole thing) but eventually I was able to get it going for a brief moment - just enough to prepare something that seem to be working. Any pointers?
import "@ebusd/ebus-typespec";
import "./_templates.tsp";
using Ebus;
using Ebus.Str;
namespace Vaillant;
/** b516 Energy statitics */
@zz(0x08)
namespace test {
model energye {
@maxLength(7) ign: IGN;
/** Wh */
value: Num.EXP;
}
@base(MF, 0x16, 0x10)
model r_1 {}
@inherit(r_1)
@ext(0x00, 0xff, 0xff, 0x04, 0x03, 0x00, 0x30)
model FuelHeatingSystem {
value: energye;
}
@inherit(r_1)
@ext(0x00, 0xff, 0xff, 0x04, 0x04, 0x00, 0x30)
model FuelHotWaterSystem {
value: energye;
}
}
I'm not sure what you mean by 'custom configuration' (local CSVs?) but this should not happen. Although it is theoreticall possible to issue unintended write commands using the
hexmode ofebusctl(did you use it?) if there are typos, I'm not aware of a command that erases most of the statistics. The statistics show in the regulator are updated every night after midnight. Did you check whether they are back?
Yes, local CSVs as per instructions. No I haven't used hex mode as I am not familiar with it yet. Statistics today are somewhat improved on the regulator (still off), but very bad on the heater itself (gas consumption for today is showing ok, but yesterday/lastmonth/lastyear is 0, total is correct).
You could also check directly in the heater statistics if these values are really zero.
e.g.
ebusctl decode exp $(ebusctl hex 08b516081003ffff04032132 | tail -c 10)
This particular one returns "57320".
should give you this years total gas consumption used for heating.
Well, could you post the definition line of
FuelSumHcfrom the CSV?
Sure, this is the one:
r1,,FuelSumHc,,,,b516,1000ffff04032132,,,IGN:7;energye,,,
What I assume: in contrast to the
b516statistics (in Wh), the above values are given in kWh (templateenergyorenergy4?). Your reading would then correspond to 10'076'100 kWh. Does this make more sense? I'm not used to such high numbers, but maybe your house is a bit bigger than mine...
Hmm actually my total consumption is ~10.000 kWh so looks like it's 10'076'100 Wh.
You could also check directly in the heater statistics if these values are really zero.
e.g. ebusctl decode exp $(ebusctl hex 08b516081003ffff04032132 | tail -c 10)
This particular one returns "57320".
Hm.... too small number (57.3 kWh) for the first three month, I guess?
Just checking: time and date settings are OK (and were always OK) on heater and regulator?
ure, this is the one:
r1,,FuelSumHc,,,,b516,1000ffff04032132,,,IGN:7;energye,,,What I assume: in contrast to the
b516statistics (in Wh), the above values are given in kWh (templateenergyorenergy4?). Your reading would then correspond to 10'076'100 kWh. Does this make more sense? I'm not used to such high numbers, but maybe your house is a bit bigger than mine...
Ah, I see. You're already using the "new" b516 energy stats. Then the number is of course in Wh.
Hmm actually my total consumption is ~10.000 kWh so looks like it's 10'076'100 Wh.
correct
You could also check directly in the heater statistics if these values are really zero.
e.g. ebusctl decode exp $(ebusctl hex 08b516081003ffff04032132 | tail -c 10)This particular one returns "57320".
Hm.... too small number (57.3 kWh) for the first three month, I guess?
That's why I am quite nervous about what could erase/manipulate data around April 1st, because previously all was showing correct. See attached pics.
That's why I am quite nervous about what could erase/manipulate data around April 1st, because previously all was showing correct. See attached pics.
I see, this is something we should keep an eye on. Do you have any recordings (history data) for the values that have re-zero'd in your home automation system to track when the data were set to zero?
And again, can you be sure that your date/time is correct / was never reset?
I see, this is something we should keep an eye on. Do you have any recordings (history data) for the values that have re-zero'd in your home automation system to track when the data were set to zero?
Unfortunately I don't as I've just been setting it all up.
And again, can you be sure that your date/time is correct / was never reset?
I checked now and it is correctly set. I never run any ebuds command to manipulate datetime.
Btw I tried to run various combinations of "yesterday" fuel consumption (gas) - derived from "ebusctl decode exp $(ebusctl hex 08b516081001ffff04036132 | tail -c 10)" but getting 0.0 despite heater display shows '32 kWh'. Could it be that regulator VRC720 stats are somehow "fighting" with heater stats?
I've checked my devices and they seem to be fine so I doubt that you managed somehow inadvertently reset those values. I thinks that the @chrizzzp could be right with regard to date/time - if date was/is off then those values (as in last month) could be actually display values from unexpected month. While experimenting I've tried to set my VRC720 to 23:59 so I force it to reload values from bai but it would always somehow sync to the actual time - since both of VRC720 and bai are not connected to internet I assumed that ebusd via ebus adapter is the one actually setting/injecting date/time.
08b516081001ffff04036132
This (accoring to my script) is EnergyFuelHeatingCurrentYearMonth3Day1 - so you're asking data for March 1 of this year, but according to our experiments only last 16 days are actually available. For yesterday (April 3) the query would be 08b516081001ffff04038332
I've checked my devices and they seem to be fine so I doubt that you managed somehow inadvertently reset those values. I thinks that the @chrizzzp could be right with regard to date/time - if date was/is off then those values (as in last month) could be actually display values from unexpected month. While experimenting I've tried to set my VRC720 to 23:59 so I force it to reload values from bai but it would always somehow sync to the actual time - since both of VRC720 and bai are not connected to internet I assumed that ebusd via ebus adapter is the one actually setting/injecting date/time.
Time settings are managed by VRC720 and are correct. I haven't touched it since last year and haven't disconnected or restarted regulator so this is a big mystery what could have happened.
08b516081001ffff04036132
This (accoring to my script) is EnergyFuelHeatingCurrentYearMonth3Day1 - so you're asking data for March 1 of this year, but according to our experiments only last 16 days are actually available. For yesterday (April 3) the query would be 08b516081001ffff04038332
Ah, thanks for correction. Running for April 3rd now returns "32410" which is correct. I will have to do more checks but what I am mostly nervous about is erased readings for this year and especially zero readings on the main unit.
Time settings are managed by VRC720 and are correct. I haven't touched it since last year and haven't disconnected or restarted regulator so this is a big mystery what could have happened.
I event thought that it might have something to do with summer time switch which happened this weekend. I'm really unsure how it would actually affect you but it's a strange coincidence...
Anyways, I'm only polling total values in HA and let SQL store data there. Earlier we discussed that we'll introduce only total values in ebusd-configuration and just document all the possible values here - as there are too many of them without real use case.
since both of VRC720 and bai are not connected to internet I assumed that ebusd via ebus adapter is the one actually setting/injecting date/time.
On my system I have an external temperature sensor (Vaillant VRC-DCF 9535) which is also radio receiver for a DCF time signal. I think this is usually the source of the time and date (unless you don't have it)?
I have an external temperature sensor (Vaillant VRC-DCF 9535) which is also radio receiver for a DCF time signal
I have some sort of external temperature sensor but it's placement is stopping me from actually indemnifying the exact model and it's not present on ebus. In any case I wasn't aware of DFC77 until now, and your explanation is spot on - thanks!
In my case the sensor is placed incorrectly to the east and in the mornings it's exposed to direct sunlight which makes it detect completely wrong temperature which interferes with operation of the system (for example, it's supposedly 27°C outside at the moment - in reality it's no more than half of that).
In my case the sensor is placed incorrectly to the east and in the mornings it's exposed to direct sunlight which makes it detect completely wrong temperature which interferes with operation of the system (for example, it's supposedly 27°C outside at the moment - in reality it's no more than half of that).
Yes, this is unfortunate. Maybe you can add some sort of shield to it or relocate it to the north side. In my case it's also not perfect, it is in 1m height at the west side, although there is some shade. It results in a delayed heating start in the evenings. Sometime I will re-position the sensor...
event thought that it might have something to do with summer time switch which happened this weekend. I'm really unsure how it would actually affect you but it's a strange coincidence...
Hmm didn't think about summer time auto-switch ... but if no-one else experiences such issues, it would be highly unusual.
Anyways, I'm only polling total values in HA and let SQL store data there. Earlier we discussed that we'll introduce only total values in ebusd-configuration and just document all the possible values here - as there are too many of them without real use case.
I don't use HA but Taphome and I would benefit in accessing stats for today/yesterday/thismonth/lastmonth/thisyear/lastyear to detect drifts and potentially alert on strange patterns.
Anyway my VRC720 also displays room humidity but I haven't seen any such parameter in 15.ctlv2/3.csv or anywhere else. Is it possible somehow to check/detect this parameter? Again not critical for my use case, but I am curious :)
Finally, just wondering if any of you are using/planning to use HA to control Vaillant device fully (saving room temps, schedules, other write-operations) to practically simulate Mobile App or it's purely to read and digest data in HA.
And another query: For VRC720 (15.ctlv2.csv or 15.ctlv3.csv) all energy readings don't work (ERR: read timeout). I see registry is B524. Is it similar problem as with bai b516 vs bai b509 registry? Anyone knows?
r;w,,PrFuelSumHcThisMonth,this months fuel consumption heating,,,,4E00,,,energy4,,,current month fuel consumption heating
r;w,,PrEnergySumHcThisMonth,this months energy consumption heating,,,,4F00,,,energy4,,,current month electricity consumption heating
r;w,,PrEnergySumHwcThisMonth,this months energy consumption hot water,,,,5000,,,energy4,,,current month electricity consumption hot water
r;w,,PrFuelSumHwcThisMonth,this months fuel consumption hot water,,,,5100,,,energy4,,,Current Month fuel consumption hot water
r;w,,PrFuelSumHcLastMonth,last months fuel consumption heating,,,,5200,,,energy4,,,last month fuel consumption heating
r;w,,PrEnergySumHcLastMonth,last months energy consumption heating,,,,5300,,,energy4,,,last month electricity consumption heating
r;w,,PrEnergySumHwcLastMonth,last months energy consumption hot water,,,,5400,,,energy4,,,last month electricity consumption hot water
r;w,,PrFuelSumHwcLastMonth,last months fuel consumption hot water,,,,5500,,,energy4,,,last month fuel consumption hot water
r;w,,PrFuelSumHc,total fuel consumption heating,,,,5600,,,energy4,,,total year fuel consumption heating
r;w,,PrEnergySumHc,total energy consumption heating,,,,5700,,,energy4,,,total year electricity consumption heating
r;w,,PrEnergySumHwc,total energy consumption hot water,,,,5800,,,energy4,,,total year electricity consumption hot water
r;w,,PrFuelSumHwc,total fuel consumption hot water,,,,5900,,,energy4,,,total year fuel consumption hot water
r;w,,PrEnergySum,total energy consumption,,,,5C00,,,energy4,,,total year electricity consumption
r;w,,PrFuelSum,total fuel consumption,,,,5D00,,,energy4,,,total year fuel consumption
Anyway my VRC720 also displays room humidity but I haven't seen any such parameter in 15.ctlv2/3.csv or anywhere else. Is it possible somehow to check/detect this parameter? Again not critical for my use case, but I am curious :)
Yes, it's decoded but not yet in the main repo.
r,,,Z1RoomHumidity,room humidity zone 1,,,b524,020003002800,value,,IGN:4,,,,value,,EXP,,%,percentage
See the respective PR by @burmistrzak.
CSV is here (can also be used for ctlv2):
Finally, just wondering if any of you are using/planning to use HA to control Vaillant device fully (saving room temps, schedules, > other write-operations) to practically simulate Mobile App or it's purely to read and digest data in HA.
Yes, I use HA & ebusd e.g. to heat up an 800 L buffer cylinder using the HP with energy from photovoltaics (when there is enough excess energy). Works with a set of automations in HA. And I have created several HA dashboards allowing display statistics, actual sensor values and adjusting of all kinds of settings in the regulator/HP. I also trigger and adjust silent mode via HA scripts (MQTT). I basically discarded the app and also don't need to access the regulator any more. It's a lot more conveinient in HA...
And another query: For VRC720 (15.ctlv2.csv or 15.ctlv3.csv) all energy readings don't work (ERR: read timeout). I see registry is B524. Is it similar problem as with bai b516 vs bai b509 registry? Anyone knows?
r;w,,PrFuelSumHcThisMonth,this months fuel consumption heating,,,,4E00,,,energy4,,,current month fuel consumption heating r;w,,PrEnergySumHcThisMonth,this months energy consumption heating,,,,4F00,,,energy4,,,current month electricity consumption heating r;w,,PrEnergySumHwcThisMonth,this months energy consumption hot water,,,,5000,,,energy4,,,current month electricity consumption hot water
With my VRC720/2 regulator the following work (I have a heat pump, no gas boiler):
15.ctlv2.csv:
*r,,,,,,B524,02000000,,,IGN:4,,,
*w,,,,,,B524,02010000,,,,,,
r;w,,PrEnergySumHcThisMonth,this months energy consumption heating,,,,4F00,,,energy4,,,current month electricity consumption heating
r;w,,PrEnergySumHwcThisMonth,this months energy consumption hot water,,,,5000,,,energy4,,,current month electricity consumption hot water
r;w,,PrEnergySumHcLastMonth,last months energy consumption heating,,,,5300,,,energy4,,,last month electricity consumption heating
r;w,,PrEnergySumHwcLastMonth,last months energy consumption hot water,,,,5400,,,energy4,,,last month electricity consumption hot water
r;w,,PrEnergySumHc,total energy consumption heating,,,,5700,,,energy4,,,total year electricity consumption heating
r;w,,PrEnergySumHwc,total energy consumption hot water,,,,5800,,,energy4,,,total year electricity consumption hot water
I noticed a strange problem with the decoding of uw-type (update-write) messages when incorporating b516 energy statistics into my local csv files.
Does anyone of you track the SetMode messages (containing e.g. the desired flow temperature) sent frequently from the regulator to the heat generator via MQTT / HA / ... ?
In the bai.csv (or hcmode.inc) this message is defined as uw (update-write) message, so whenever the regulator sends this one to the heat generator the displayed value(s) of the corresponding HA entity should also be updated (actual writing via ebusd is not permitted for uw message types.)
From the official repo 08.bai.csv:
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,,,
In my local ebusd-configuration files it's in the hcmode.inc:
uw,,SetMode,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,,,,
The problem:
I now observed a strange behaviour that whenever I add a message definition from the b516 energy statistics block to the CSV, e.g.
r,,EnStatElectricalSumSystem,,,,b516,1000ffff03002132,,,IGN:7;energye,,,
After restart of ebusd the csv are read without any errors but message of the uwtype are not decoded any longer by ebusd. Instead they appear as unknown update-writes in the ebusd logfile, e.g.
[update notice] received unknown MS cmd: 1008b51009000034ffffff060000 / 0101
When I comment out the above EnStatElectricalSumSystem definition from the CSV (and restart ebusd) the uw-type message values are properly decoded and updated via MQTT again.
[update notice] received update-write hmu SetMode QQ=10: auto;26.0;-;-;0;1;1;0;0;0
This is not limited to the SetMode message, other messages of the uw-type are also affected.
Strangely, this "loss" of (uw-type) messages doesn't occur if I add other message definitions (non-b516) to the csv, e.g. from the b509 block.
Can anyone of you reproduce/confirm this behaviour? At the moment I'm quite puzzled and wonder if this is actually an ebusd issue we should report to @john30 ? It's strange that it seems to happen only after addition of b516 energy statistics messages. Is there something obvious I don't see...?
Still on the same issue...
In the meantime I set up an second (virtual) HA machine with ebusd addon (as a non-productive environment to do some testing) and use the original CSVs (from the next repository) and original mqtt-hassio.cfg from ebusd 24.1.
But the above issue (see previous post) seems to persist: as soon as I add the line
r,,,EnStatsElectricalSumSystem,,,,b516,1000ffff03002132,value,,IGN:7,,,,value,,EXP,,Wh,
to the 08.hmu.csv the uw-type messages are not decoded any longer... e.g.
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,,,
They appear in the ebusd logfile as undecoded messages, but are not transported over MQTT any longer (not visible in MQTT explorer).
[update notice] received unknown MS cmd: 1008b51009000034ffffff060000 / 0101
What's strange that it seems to occur only when putting b516 energy statistic definitions in the CSV... When removed from CSV, everything is back normal.
Any ideas anyone?
@filippz Have a chance that PR will be prepared in soonest time ?
Have a chance that PR will be prepared in soonest time
A couple of things to need to be defined first:
- the actual name of the tsp/csv file - something like b516.tsp might be OK. We might also split it to HP and gas boilers separately because they have different energy sources and just some overlap between the two
- where/how to include the tsp/cvs - we might include just a couple of devices first that we actually tested and know they support b516 energy statistics, possibly with "conditional" includes (depending on SW/HW version for example)
- the actual contents of the tsp file (which in turn generates csv) - I've prepared a sample tsp file here: #490 (comment) but there were no comments on it. In the meantime I've prepared full tsp file with all "System" values
- there is also a need for a separate PR in https://github.com/john30/ebusd to add gas in Wh support in
mqtt-hassio.cfg(relevant only for gas boilers and Home Assistant) - @chrizzzp also noticed some issues with uw messages when b516 are added to csv which we should confirm/resolve in order not to break something
So probably not very soon, but you should be able to add manually the needed entries you need fairly easy following the instructions/examples earlier in this discussion
I've made a commit in my fork (https://github.com/filippz/ebusd-configuration/commits/master/) which introduces b516_inc.tsp that I plan to make into a PR. I've included b516_inc.tsp into 08.bai.tsp and 08.hmu.tsp unconditionally - if anyone needs it somewhere else please let me know so I can add it there.
The commit generates the following entries into 08.bai.csv and 08.hmu.csv (as there is no support for emiting !include) :
r,,,SolarHeatingSystem,,,,b516,1000ffff01030030,ign,,IGN:7,,,,energye,,EXP,,Wh,
r,,,SolarHotWaterSystem,,,,b516,1000ffff01040030,ign,,IGN:7,,,,energye,,EXP,,Wh,
r,,,EnvironmentalSumSystem,,,,b516,1000ffff02000030,ign,,IGN:7,,,,energye,,EXP,,Wh,
r,,,EnvironmentalHeatingSystem,,,,b516,1000ffff02030030,ign,,IGN:7,,,,energye,,EXP,,Wh,
r,,,EnvironmentalHotWaterSystem,,,,b516,1000ffff02040030,ign,,IGN:7,,,,energye,,EXP,,Wh,
r,,,EnvironmentalCoolingSystem,,,,b516,1000ffff02050030,ign,,IGN:7,,,,energye,,EXP,,Wh,
r,,,ElectricalSumSystem,,,,b516,1000ffff03000030,ign,,IGN:7,,,,energye,,EXP,,Wh,
r,,,ElectricalHeatingSystem,,,,b516,1000ffff03030030,ign,,IGN:7,,,,energye,,EXP,,Wh,
r,,,ElectricalHotWaterSystem,,,,b516,1000ffff03040030,ign,,IGN:7,,,,energye,,EXP,,Wh,
r,,,ElectricalCoolingSystem,,,,b516,1000ffff03050030,ign,,IGN:7,,,,energye,,EXP,,Wh,
r,,,FuelSumSystem,,,,b516,1000ffff04000030,ign,,IGN:7,,,,energye,,EXP,,Wh,
r,,,FuelHeatingSystem,,,,b516,1000ffff04030030,ign,,IGN:7,,,,energye,,EXP,,Wh,
r,,,FuelHotWaterSystem,,,,b516,1000ffff04040030,ign,,IGN:7,,,,energye,,EXP,,Wh,Testing and comments are welcome.
Testing and comments are welcome.
Finally found some time to test the definitions. I added the definitions to the 08.hmu.csv using the latest ebusd (25.1) and latest mqtt-hassio.cfg on my "test" HA installation. The template definition of energye is not needed with the new CSVs anymore. All working fine - nice work!
@chrizzzp also noticed some issues with uw messages when b516 are added to csv which we should confirm/resolve in order not to break something
Interestingly, this issue was not there any longer with the latest version of ebusd 25.1 and the original mqtt-hassio.cfg (only filter names removed to get all messages: filter-name =). Have to check whether this is really related to the latest version or a problem of a (modified) mqtt-hassio.cfg that I'm using on my "productive" HA installation (still running ebusd 24.1). However, I think this issue is no longer a show-stopper for the PR any longer.
I've changed the code a bit so B516_inc is not emitted into the CSV and now the b516 values are seen as ebusd bai/hmu ...and not ebusd B156_inc ... (#490 (comment) has been updated accordingly)
My ebusd has been updated with the latest ebus.github.io configuration files and b516 values (generated from b516_inc.tsp) has been added to 08.bai.csv manually and I've added them to Energy tab in HA - they seem to be working fine.
noob here... so please bear with me....
I tried to test this in my non-typical system with local config files ( 24.1 version):
symbol rate: 91
max symbol rate: 228
min arbitration micros: 15
max arbitration micros: 679
min symbol latency: 6
max symbol latency: 49
scan: finished
reconnects: 19
masters: 7
messages: 1417
conditional: 0
poll: 546
update: 25
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=HMU00;SW=0522;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=0100;HW=5904", loaded "vaillant/26.vr_71.csv"
address 30: master #3
address 31: master #8, ebusd
address 35: slave #3, scanned "MF=Vaillant;ID=VR_92;SW=0514;HW=1204", loaded "vaillant/35.vr_92.csv"
address 36: slave #8, ebusd
address 52: slave, scanned "MF=Vaillant;ID=VR_70;SW=0101;HW=5804", loaded "vaillant/52.vr_70.csv"
address 53: slave, scanned "MF=Vaillant;ID=VR_70;SW=0101;HW=5804", loaded "vaillant/53.vr_70.csv"
address 70: master #4
address 71: master #9
address 75: slave #4, scanned "MF=Vaillant;ID=VR_92;SW=0514;HW=1204", loaded "vaillant/75.vr_92.csv"
address 76: slave #9, scanned "MF=Vaillant;ID=VWZ00;SW=0522;HW=5103", loaded "vaillant/76.vwz.csv"
address f1: master #10
address f6: slave #10, scanned "MF=Vaillant;ID=NETX2;SW=4036;HW=5703", loaded "vaillant/f6.netx2.csv"
I expected to work as per the re-engineered config lines, but I can see no entities in HA and I still have some errors, which seem related to the topic I guess:
received unknown MS cmd: f115b516081000ffff01000000 / 0b0000ff01009b3200000000
received unknown MS cmd: f108b516081000ffff42030000 / 0b00000142039732a01eb94a
received unknown MS cmd: f108b516081000ffff42040000 / 0b0000034204973200000000
received unknown MS cmd: f108b516081000ffff42050000 / 0b0000054205973200f0d246
received unknown MS cmd: f108b516081000ffff49030000 / 0b1000ff4903973200000000
received unknown MS cmd: f108b516081000ffff49040000 / 0b1000ff4904973200000000
received unknown MS cmd: f108b516081000ffff49050000 / 0b1000ff4905973200000000
received unknown MS cmd: f108b516081000ffff83030000 / 0b00000083039732a084284a
received unknown MS cmd: f108b516081000ffff83040000 / 0b0000028304973200000000
received unknown MS cmd: f108b516081000ffff83050000 / 0b0000048305973200007a45
received unknown MS cmd: f108b516081000ffff84030000 / 0b1000ff8403973200000000
received unknown MS cmd: f108b516081000ffff84040000 / 0b1000ff8404973200000000
if this is any help at all...
I expected to work as per the re-engineered config lines, but I can see no entities in HA and I still have some errors, which seem related to the topic I guess:
received unknown MS cmd: f115b516081000ffff01000000 / 0b0000ff01009b3200000000 received unknown MS cmd: f108b516081000ffff42030000 / 0b00000142039732a01eb94a received unknown MS cmd: f108b516081000ffff42040000 / 0b0000034204973200000000 received unknown MS cmd: f108b516081000ffff42050000 / 0b0000054205973200f0d246 received unknown MS cmd: f108b516081000ffff49030000 / 0b1000ff4903973200000000 received unknown MS cmd: f108b516081000ffff49040000 / 0b1000ff4904973200000000
These are not errors, they are log entries showing requests from the VR921 internet gateway (i.e. Vaillant) for b516 energy statistics. As they are different to the b516 definitions proposed in this PR (#490 (comment)) they are not decoded by ebusd.
If you don't see any entities in HA: check the ebusd logfile for error messages after the start of ebusd as soon as the 08.hmu.csv is read in. If there are errors with the definitions ebusd will stop loading this particular CSV. It's also useful to check with netcat (nc) or ebusctl whether the b516 definitions are actually available in ebusd (e.g. find command, see https://github.com/john30/ebusd/wiki/3.1.-TCP-client-commands).