Add support for basv3

[burmistrzak]

Follow-up for #462 to keep patches manageable.

[burmistrzak]

@john30 What's your policy regarding register names?
I'd prefer to simply copy what is being shown on the system regulator's screen, whenever possible. Thoughts?

[burmistrzak]

@GuyHarg If all goes well, and depending on how your VRC 720 is supported, basv3 might become the less-specific basv config, with some conditions added for older devices. 🤞

[john30]

@john30 What's your policy regarding register names? I'd prefer to simply copy what is being shown on the system regulator's screen, whenever possible. Thoughts?

I'd rather stick to short names for common things like heat circuit="hc", hot water circuit="hwc" etc as otherwise the names grow awfully and unnecessary long, see here https://github.com/john30/ebusd-configuration#component-type-names

and for ease of use messages revealing a single value only should carry the field name "value".

also I'd rather prevent reinvention of the same, i.e. if a message with a suitable name exists elsewhere: use it and rather later do refactoring overall (as is ongoing with the typespec conversion)

[burmistrzak]

I'd rather stick to short names for common things like heat circuit="hc", hot water circuit="hwc" etc as otherwise the names grow awfully and unnecessary long, see here https://github.com/john30/ebusd-configuration#component-type-names

@john30 Roger that! I‘ll try to keep them short.

and for ease of use messages revealing a single value only should carry the field name "value".

Already the case for all my definitions. 👌

also I'd rather prevent reinvention of the same, i.e. if a message with a suitable name exists elsewhere: use it and rather later do refactoring overall (as is ongoing with the typespec conversion)

Sounds good! It’s certainly easier to refactor when naming is consistent.

Lastly, as there isn’t a good generic configuration for the BASV* range of devices, maybe we’ll use this one?

[kgeree]

hi @burmistrzak, till now i was using CTLV2 config from jonesPD's repo for my regulator, which is (i think a quite early VRC70) identified as "720" in ebusd and I though I give it a try with this basv3 config. I have to say it works almost flawlessly. :)

Few things I noticed:

1. Can't read Errorhistory, while it shouldn't be empty. I get:
   [mqtt error] read 720 Errorhistory: ERR: end of input reached

2. Have some small issue with PhoneNumber1-2 amd Z*Name1-2
   e.g. for phone number I have set 10 digits, in PhoneNumber1 I can see the first 6 digits of it and PhoneNumber2 unable to parse:

2025-01-29 08:54:07.847 [update error] unable to parse poll-read 720 PhoneNumber2 from 3115b52406020000007000 / 09030070003432343400: ERR: invalid position
2025-01-29 08:54:07.847 [mqtt error] decode 720 PhoneNumber2: ERR: invalid position

Similar issue for Zone names.

3. Z*QuickVetoDuration should have a unit "hours" or "h" as currently its just a number.

4. DewPointOffset -> Isn't it the Dewpoint only which is displayed? ...and Offset for it is set elsewhere? (I was not able to check it on the regulator as I'm remote) Makes me a bit confused together with the Hc*DewPointOffset values...

All in all I think this could be used as a baseline even for devices identified as "720", "ctlv*", "basv*"?

[burmistrzak]

@kgeree Nice, thanks the detailed feedback!

1. I‘ll investigate the Errorhistory – might have to remove it temporarily.
2. Interesting… Seems indeed to be a parsing issue. There’s data in PhoneNumber2, so that’s good news.
3. Good catch! Will be fixed.
4. Hmm, great question! Maybe @jonesPD knows where DewPointOffset came from?

As these system regulators have a lot in common, I can certainly see that happening. 😊

Edit: Did you properly clone my fork and checkout the testing branch? I can't really explain what's going on with No. 2 otherwise...

Edit 2: Various fixes are now available in testing. FYI, you might have to delete the MQTT device from HASS.

[burmistrzak]

@john30 Do we already have an option to specify min/max/step values for registers?
And if so, do these bounds get passed along via MQTT to HASS?

Edit: I guess this answers my first question? 👀
But not so much the second. The idea would be to prevent HASS from setting invalid values.
Also, does ebusd validate incoming data based on the TypeSpec?

Edit 2: It appears that min/max/step values specified in TypeSpec, are not yet actively used?

Edit 3: Just saw that support for range is currently in development. Great! I‘ve already added min/max/step to my configuration where appropriate, and was then able to generate CSVs with withMinMax=true set. 💪

[burmistrzak]

@kgeree Were you able to checkout the testing branch? It includes the latest HMU, VWZIO, and VRC 720 configs.

[jonesPD]

2. Have some small issue with PhoneNumber1-2 amd Z*Name1-2
   e.g. for phone number I have set 10 digits, in PhoneNumber1 I can see the first 6 digits of it and PhoneNumber2 unable to parse:

2025-01-29 08:54:07.847 [update error] unable to parse poll-read 720 PhoneNumber2 from 3115b52406020000007000 / 09030070003432343400: ERR: invalid position
2025-01-29 08:54:07.847 [mqtt error] decode 720 PhoneNumber2: ERR: invalid position

Afaik each register can only a limited set of characters, so two registers are needed for the whole number. However, if you don't program a long enough number in the regulator, you can't read the second register because it is empty. Have you checked this scenario?

4. DewPointOffset -> Isn't it the Dewpoint only which is displayed? ...and Offset for it is set elsewhere? (I was not able to check it on the regulator as I'm remote) Makes me a bit confused together with the Hc*DewPointOffset values...

You can set a dew point offset for each heating circuit per the definition in the VRC720 manual: the minimum supply flow temperature in cooling mode is determined by the calculated dew point + this offset

[kgeree]

@kgeree Were you able to checkout the testing branch? It includes the latest HMU, VWZIO, and VRC 720 configs.

not yet...will try later. However looking at the vwzio, I think I have some more values..not sure if you can utilize something, they're all working for me (its a CSV that still needs the tempate files...)
76.vwzio.hw5103.csv

HMU and 720 looks good for the first sight (however I'm using ebusd in r/o mode yet) so can't speak for the write options...

[burmistrzak]

However looking at the vwzio, I think I have some more values..not sure if you can utilize something, they're all working for me

@kgeree The b514 block should be considered unsafe for normal polling. That's why we're already looking into the config/diagnostics b509 block for more safe registers.

See here:

ebusd-configuration/src/vaillant/08.hmu.tsp

Line 791 in 08a68f1

// Test menus on VWZ. EnableTest message needs to be sent before each of the read messages work.

[kgeree]

okay...I gave it a try, have the following results:
PowerConsumptionVwz - not found, I guess its the same issue like for the HMU

[update error] unable to parse poll-read vwzio PowerConsumptionVwz from 3176b5160114 / 00: ERR: invalid position
[mqtt error] decode vwzio PowerConsumptionVwz: ERR: invalid position

and I get "null" for the following:
DiagCondensorOutletTemp
DiagFlowTemp
DiagSystemPressure

(but i think vwzio shall not be discussed in this PR)

[burmistrzak]

okay...I gave it a try, have the following results: PowerConsumptionVwz - not found, I guess its the same issue like for the HMU

@kgeree Yes, likely.

and I get "null" for the following: DiagCondensorOutletTemp DiagFlowTemp DiagSystemPressure

You get null, but no errors in log, right?

(but i think vwzio shall not be discussed in this PR)

Yeah, #481 is definitely a better fit. 😊
Btw. I recommend you switch to the more stable preview branch. Simply do git pull && git checkout preview

[kgeree]

You get null, but no errors in log, right?

right, null, but no errors. BTW is there a way to show "null" in HomeAssistant as well? then I'd get "Unknown" only if there is really an error on the ebus layer...

[burmistrzak]

right, null, but no errors.

@kgeree Alright, that’s good news! The b509 is seemingly behaving as we have theorized.

BTW is there a way to show "null" in HomeAssistant as well? then I'd get "Unknown" only if there is really an error on the ebus layer...

There’s probably a way to do that, but it likely requires modifying the MQTT-HASSIO configuration (value template, etc.)... I‘d say that‘s something to look at when we’ve worked out all other issues. 😉

[burmistrzak]

@jonesPD @kgeree I think I've found the problem... 😅

TypeSpec-generated CSVs now include STR:6, thus expecting six bytes:

r,,,PhoneNumber1,phone number 1 (first part),,,b524,020000006f00,value,,IGN:4,,,,value,,STR:6,,,phone number
w,,,PhoneNumber1,phone number 1 (first part),,,b524,020100006f00,value,,STR:6,,,phone number
r,,,PhoneNumber2,phone number 2 (second part),,,b524,020000007000,value,,IGN:4,,,,value,,STR:6,,,phone number
w,,,PhoneNumber2,phone number 2 (second part),,,b524,020100007000,value,,STR:6,,,phone number

While the old CSVs were more permissive with STR:*, having no fixed length:

r;w,,PhoneNumber1,phone number 1,,,,6F00,,,STR:*,,,installer's telephone number,,,,,,,,,,,,,,,,,,
r;w,,PhoneNumber2,phone number 2,,,,7000,,,STR:*,,,installer's telephone number,,,,,,,,,,,,,,,,,,

@john30 How would I specify a field template in TypeSpec that allows STR to be at most six bytes long, but with no minimum/fixed length?

[chrizzzp]

@burmistrzak

1. I'll investigate the `Errorhistory` – might have to remove it temporarily.

I didn't find the corresponding entries in the CSVs you generated, but I had noticed earlier that the errorhistory definition is device-specific. See here:
#330 (comment)

I created different errors.inc for the different devices and had to add another template, but I'm sure this can be done more elegantly with conditions...

errors_vr71_ctlv2.inc:

# error history for vr_71 and ctlv2
*r,,,,,,"B503","01",,,,,,,,,
r,,errorhistory,Error history,,,,01,index,m,UCH,,,,,,errorhistory2

errors_hmu_vwz.inc:

# error history for hmu and vwz
*r,,,,,,"B503","01",,,,,,,,,
r,,errorhistory,Error history,,,,01,index,m,UCH,,,,,,errorhistory

_templates.csv:

time2,VTM,,,time
time3,BTM,,,time
date,HDA:3,,,date
date2,BDA:3,,,date
errorhistory,status;time2;date;error,,,
errorhistory2,status;time3;date2;error,,,

[kgeree]

Slightly off: anyone using the VRC720* with ReovAir system? (via V32 bus coupler). I'd like to know how to initiate Ventilation boost via ebusd.. Setting Z*SFmode to "ventilation" doesn't do the trick. With that I can see the status changes to "ventilation" and even in MyVaillant app I see Ventilation boost ongoing, but the RecovAir volume flow / airlflow doesn't change at all....

[burmistrzak]

@kgeree AFAIK, Ventilation boost only affects your heating zone. Unfortunately named, I guess. 😅

This function switches off the heating for 30 minutes. After this (or as soon as you cancel), it will resume the preset operation mode.
Frost protection, domestic hot water preparation and circulation all remain active during ventilation boost.

[kgeree]

@kgeree AFAIK, Ventilation boost only affects your heating zone. Unfortunately named, I guess. 😅

This function switches off the heating for 30 minutes. After this (or as soon as you cancel), it will resume the preset operation mode.
Frost protection, domestic hot water preparation and circulation all remain active during ventilation boost.

Thats fine. But still not :)
I mean, its kinda stupid. The way in the app to effectively start the Ventilation boost is select at least one Zone and the "Ventilation system" - whatever it switches...

If I don't switch the "Ventilation System" as well, its the same when I only switch the Z*FSMode to ventilation via ebusd --> App shows ventilation boost active but nothing happens...
So some extra switch (SFMode??) is missing somewhere IMO

[burmistrzak]

@chrizzzp I‘ll give that a try! errorhistory on the VRC720 should be more reliable across heatpump variants, right? The system regulator acts as a kind of proxy, so we don’t have to deal with every new software revision. 😉

[burmistrzak]

Thats fine. But still not :) I mean, its kinda stupid. The way in the app to effectively start the Ventilation boost is select at least one Zone and the "Ventilation system" - whatever it switches... If I don't switch the "Ventilation System" as well, its the same when I only switch the Z*FSMode to ventilation via ebusd --> App shows ventilation boost active but nothing happens... So some extra switch (SFMode??) is missing somewhere IMO

@kgeree Ah, I see.
Unfortunately don't have a ventilation system connected, but I did some preliminary research into the VR940f:

15.basv3

via NETX3

f1 15 b524 07  02010000 f900 01 / 02 00 00  xUnknownF9 Ventilation Boost on
f1 15 b524 07  02010000 f900 00 / 02 00 00  xUnknownF9 Ventilation Boost off

While these registers are different, I don't think they are exactly what we're looking for...

You'll need to grep "cmd: f115b5240702010000" for me, after you've enabled/disabled ventilation from within the app.
It's also possible that it's a direct command to the ventilation system, thus bypassing the regulator completely. Do you have that additional or a similar option on the actual system regulator as well?

[chrizzzp]

@burmistrzak

I‘ll give that a try! errorhistory on the VRC720 should be more reliable across heatpump variants, right? The system regulator acts as a kind of proxy, so we don’t have to deal with every new software revision. 😉

This would be the ideal case... I'm not so sure if all errors really arrive at (and are recorded in) the regulator. I remember having a 'missing sensor' error of the HWC sensor (supposed to be connected to the vwz) that did not show up in the VRC720, but only in the vwz... I think this should be checked. So what's the easiest way to generate 'non-critical' error messages? 😉

[burmistrzak]

This would be the ideal case... I'm not so sure if all errors really arrive at (and are recorded in) the regulator. I remember having a 'missing sensor' error of the HWC sensor (supposed to be connected to the vwz) that did not show up in the VRC720, but only in the vwz... I think this should be checked. So what's the easiest way to generate 'non-critical' error messages? 😉

@chrizzzp I'd say disconnecting an optional temperature sensor, e.g. in buffer cylinder maybe? Alternatively the DCF signal?

[burmistrzak]

@chrizzzp So both, VR71 and CTLv2 share the same type of errorhistory, correct?
Adding them to the main errors_inc.tsp will however be tricky, because conditions cannot currently be negated... 🤔

[chrizzzp]

@burmistrzak

So both, VR71 and CTLv2 share the same type of errorhistory, correct?

Correct!

[stadid]

@burmistrzak

I‘ll give that a try! errorhistory on the VRC720 should be more reliable across heatpump variants, right? The system regulator acts as a kind of proxy, so we don’t have to deal with every new software revision. 😉

This would be the ideal case... I'm not so sure if all errors really arrive at (and are recorded in) the regulator. I remember having a 'missing sensor' error of the HWC sensor (supposed to be connected to the vwz) that did not show up in the VRC720, but only in the vwz... I think this should be checked. So what's the easiest way to generate 'non-critical' error messages? 😉

@burmistrzak, @chrizzzp

As to my current understanding regulator do not act as error proxy (in terms of "mirroring" heater(s) errors in some regulator register), nor it stores error history. Only current error is useful for now.

Regulator has his own error codes. At least for 720 family I've got the list. See below.
Error_codes-VRC720(f)-VRT380(f)-VR92(f).xlsx

[burmistrzak]

@stadid Very important insights, thx!
I assume, you got those codes from the manual(s), right?

[stadid]

@burmistrzak

I assume, you got those codes from the manual(s), right?

No. Found this info by accident on the Internet. Haven't seen any error codes description in the regulator manuals.
This file seems to be some kind of internal use reference for the service engineers.

[burmistrzak]

No. Found this info by accident on the Internet. Haven't seen any error codes description in the regulator manuals. This file seems to be some kind of internal use reference for the service engineers.

@stadid Huh, that’s interesting.
At least for the VRC 720f/3, those error codes, including their description and potential fixes, are listed on page 62 of the manual.

Somewhat related question, if I may:
Have you ever seen any docs regarding the b509 block for heatpump units?
While I too prefer the system regulator approach, some data (energy integral, CoP, etc.) is seemingly only available from the units themselves.

[stadid]

@burmistrzak

At least for the VRC 720f/3, those error codes, including their description and potential fixes, are listed on page 62 of the manual.

Interesting, I've checked manual for 720/2 and it has only error description text, not the code number.

Somewhat related question, if I may:
Have you ever seen any docs regarding the b509 block for heatpump units?

Unfortunately, no.
BTW, take a look at the attached document.
It's very old and seems to be irrelevant to the subject, but maybe it adds something to the general understanding of the problem.

Vaillant_ebus-2.pdf

[burmistrzak]

@stadid Yea, I know about this doc. Sadly, heat pumps seem to use other, mostly unknown registers in the b509 block…
Scanning the entire range of unexplored addresses, while totally doable, is probably not the safest way of doing things.

Ideally, we wouldn’t have to talk to heat pump units directly, instead letting e.g. the system regulator do the heavy lifting of actually acquiring data.
I don’t think this is the case, but do system regulators at all request operational/diagnostics data? 🤔

[stadid]

@burmistrzak

I don’t think this is the case, but do system regulators at all request operational/diagnostics data? 🤔

If we talk about energy / fuel consumption, forward/return line temp(where applicable) or current heat generator status code/ error, I believe yes, regulator requesting this data with different frequency across the day. I think @chrizzzp mentioned this already. According to my understanding, regulator by himself do not store this data permanently, only acting as a "buffer" or for displaying this data on his screen.
I've also seen reports when the native app got the energy consumption statistics from the heater while regulator was not connected to the system. It meas that Vaillant cloud could get those values directly from equipment without regulator. So, the obvious approach is to sniff data between the internet gateway and the heat pump and compare data with what app is showing. The other approach is to sniff data between the regulator and the heat pump and also try to figure out what is requested /answered.

In case you are asking about some specific parameters of the heat generator my guess is if they are not used/displayed by regulator, most probably they are not requested.

[burmistrzak]

@stadid Thanks for the detailed response!
Well, besides sniffing traffic, another approach would be to analyze the serviceDIALOG diagnostics software.

It's highly likely that a database of at least b509 registers is included with this tool.
The VR 15 (0020247921) diagnostics adapter can apparently be ordered/purchased, but I don't know if the actual software is included...

[burmistrzak]

@kgeree New version with support for CurrentError is now available on the preview branch.
Can you try this one? Maybe simulate an error by temporarily disconnecting the VR71?

[stadid]

@burmistrzak

@stadid Thanks for the detailed response! Well, besides sniffing traffic, another approach would be to analyze the serviceDIALOG diagnostics software.

It's highly likely that a database of at least b509 registers is included with this tool. The VR 15 (0020247921) diagnostics adapter can apparently be ordered/purchased, but I don't know if the actual software is included...

Good approach!
Not sure if they ship it with software and is device config database actual or is it updated from their server.

[burmistrzak]

@stadid Unfortunately, the eBus adapter (and software?) is quite expensive for what it is. Around 400 EUR. 🙃
There’s effectively no publicly available documentation of the diagnostics software itself. Not even a single screenshot.
I was only able to find a grainy photo of a service laptop on a Czech Facebook page…

Edit: In case it’s not possible to analyze the software itself, it might be possible to ask the installer to check/readout the heat pump with their tool during routine maintenance, and log everything on the bus using ebusd in the background. 😏