Add support for `basv3` #482

burmistrzak · 2025-01-27T17:39:37Z

This PR aims to be the most feature-complete and robust definition for the VRC720 sensoCOMFORT line of system regulators.
It's also entirely written in TypeSpec, and already prepared to take advantage of the upcoming range validation feature for numeric values.

Follow-up for #462 to keep patches manageable.

burmistrzak · 2025-01-27T18:09:24Z

@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 · 2025-01-28T17:24:20Z

@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 · 2025-01-28T22:43:14Z

@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 · 2025-01-29T03:17:23Z

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 · 2025-01-29T08:11:50Z

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:

Can't read Errorhistory, while it shouldn't be empty. I get:
[mqtt error] read 720 Errorhistory: ERR: end of input reached
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.

Z*QuickVetoDuration should have a unit "hours" or "h" as currently its just a number.
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 · 2025-01-29T19:30:34Z

@kgeree Nice, thanks the detailed feedback!

I‘ll investigate the Errorhistory – might have to remove it temporarily.
Interesting… Seems indeed to be a parsing issue. There’s data in PhoneNumber2, so that’s good news.
Good catch! Will be fixed.
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 · 2025-01-29T19:33:07Z

@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 · 2025-01-30T17:23:42Z

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

jonesPD · 2025-01-30T18:11:36Z

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?

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 · 2025-01-30T19:26:19Z

@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 · 2025-01-30T19:53:54Z

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 · 2025-01-30T20:22:24Z

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 · 2025-01-31T00:19:59Z

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 · 2025-01-31T06:59:16Z

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 · 2025-01-31T19:42:46Z

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. 😉

kgeree · 2025-02-08T18:16:31Z

@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?

nicely working:

Any chance it'd work the same way for error history?

burmistrzak · 2025-02-08T19:06:55Z

nicely working

@kgeree Great! ✌️

Any chance it'd work the same way for error history?

Maybe..?
Do me a favor, leave the error active and run the following: ebusctl hex 15b503020101
Then, clear the error and run it again. Post whatever gets returned by the system regulator.

kgeree · 2025-02-08T20:10:53Z

nicely working

@kgeree Great! ✌️

Any chance it'd work the same way for error history?

Maybe..? Do me a favor, leave the error active and run the following: ebusctl hex 15b503020101 Then, clear the error and run it again. Post whatever gets returned by the system regulator.

Seems i get some inconsistent readings..

Error on:

hex 15b503020101
08025920080225fd01

hex 15b503020101
08000000000000ffff

hex 15b503020101
08020521060824fd01

hex 15b503020101
08022108031124fd01

hex 15b503020101
08022108031124fd01

hex 15b503020101
08025920080225fd01

hex 15b503020101
08025920080225fd01

Error off:

hex 15b503020101
08025920080225fd01

hex 15b503020101
08025920080225fd01

hex 15b503020101
08025920080225fd01

hex 15b503020101
08025920080225fd01

hex 15b503020101
08020521060824fd01

hex 15b503020101
08023718080225fd01

hex 15b503020101
08023718080225fd01

hex 15b503020101
08000000000000ffff

hex 15b503020101
08025920080225fd01

burmistrzak · 2025-02-08T21:05:28Z

@kgeree Ok, decoding based on currently available definitions yields:

NN INDEX STATUS TIME_ DATE____ ERROR    
08 02    59     20 08 02 25 fd 01

What is shown under error history on the system regulator itself?

chrizzzp · 2025-02-09T08:22:36Z

@burmistrzak @kgeree

I think in order to get proper values for historic entries an index has to be added.

errors.inc
r,,errorhistory,Error history,,,,01,index,m,UCH,,,,,,errorhistory2

_templates.csv:
errorhistory2,status;time3;date2;error,,,

e.g.

ebusctl r -f -c ctlv2 -i 0 errorhistory
ebusctl r -f -c ctlv2 -i 1 errorhistory
ebusctl r -f -c ctlv2 -i 3 errorhistory
...

This would translate to:

hex 15b50303010101
hex 15b50303010102
hex 15b50303010103

In my case (no errors in regulator history) this yields for all values:

0800ffffffffffffff

kgeree · 2025-02-09T12:58:30Z

@kgeree Ok, decoding based on currently available definitions yields:
NN INDEX STATUS TIME_ DATE____ ERROR    
08 02    59     20 08 02 25 fd 01
What is shown under error history on the system regulator itself?

burmistrzak · 2025-02-09T18:25:02Z

@kgeree Thx! Can you please run ebusctl hex 15b50303010101 and post the results?
I need to check if the datatype/length for error is correct.

kgeree · 2025-02-09T19:36:00Z

@kgeree Thx! Can you please run ebusctl hex 15b50303010101 and post the results? I need to check if the datatype/length for error is correct.

here you go:

hex 15b50303010101
08023718080225fd01

burmistrzak · 2025-02-09T20:02:27Z

@kgeree Alright, decoding based on the definition @chrizzzp provided:

NN STATUS TIME_ DATE____ ERROR
08 00     ff ff ff ff ff ff ff
08 02     37 18 08 02 25 fd 01

~~This leads me to believe that error should be of type UCH instead of UIN, i.e. one byte vs. two bytes in length.~~

Edit: Question now is the meaning of status... Can you simulate another type of fault? We maybe see a different code.

Edit 2: Messed up the conversion above by including the index. It's now fixed. Regarding status, that field might mean the following none=0; ongoing=1; resolved=2, but that's just a somewhat educated guess. 😉

burmistrzak · 2025-02-09T20:55:10Z

@kgeree New build on the preview branch now includes ErrorHistory, give it a shot! 🙌

You'll have to manually read history entries, as they aren't polled automatically. E.g.:

ebusctl r -f -c basv3 -i <INDEX> ErrorHistory

The value of <INDEX> can be everything from 0...65534, FYI.

kgeree · 2025-02-10T08:17:34Z

@kgeree New build on the preview branch now includes ErrorHistory, give it a shot! 🙌

You'll have to manually read history entries, as they aren't polled automatically. E.g.:
ebusctl r -f -c basv3 -i <INDEX> ErrorHistory
The value of <INDEX> can be everything from 0...65534, FYI.

for me index is working up to 9 (10 entries - just as it is shown on the regulator as well)

read -f -c 720 -i 9 ErrorHistory
9;resolved;12:56;05.04.2024;RECOVAIR_comm_error

read -f -c 720 -i 10 ErrorHistory
ERR: argument value out of valid range in decode: 10;none;00:00;

BTW its called "Fault history" on the regulator :)
do you know how to pass the index to fetch it via mqtt from HA?

burmistrzak · 2025-02-10T15:13:35Z

@kgeree Yea, Fault History is the correct terminology. 😅
It’s strange you get an error at index 10, when I do not…

ebusctl read -f -c basv3 -i 10 ErrorHistory
10;none;-:-;-.-.-;-

ebusd ebusctl hex 15b5030301010a
0800ffffffffffffff

Can you please share the output of hex 15b5030301010a on your system?
It also seems like you‘re running an outdated ebusd version, because its not properly replacing 0xff with -:- during decode… 🤔

Edit: Regarding MQTT, there‘re good docs available. E.g.: To send the index along with your /get request, you simply put the number in the MQTT payload.

burmistrzak · 2025-02-10T15:34:22Z

@kgeree On a related note, setting the unit for Z*QuickVetoDuration to hours, makes it a non-writable counter in HASS. So we either have to remove the unit again, or switch to an Enum for example.
@chrizzzp Thoughts?

kgeree · 2025-02-10T15:37:15Z

Can you please share the output of hex 15b5030301010a on your system?

hex 15b5030301010a
08000000000000ffff

version: ebusd 24.1.p20241115

chrizzzp · 2025-02-10T16:47:07Z

On a related note, setting the unit for Z*QuickVetoDuration to hours, makes it a non-writable counter in HASS. So we either have to remove the unit again, or switch to an Enum for example.
@chrizzzp Thoughts?

Yes, this is unfortunate. One could also include the unit 'hours' in the name: e.g. Z*QuickVetoHours to circumvent, but an Enum is probably better as the values are restricted anyway (0.5 - 12 in 0.5 increments, default 3).

burmistrzak · 2025-02-10T17:14:47Z

hex 15b5030301010a
08000000000000ffff
version: ebusd 24.1.p20241115

@kgeree Huh, that’s interesting. Instead of 0xff, your VRC720 is using 0x00, which seemingly is incorrect. Might be down to an older firmware. Doesn’t really matter though, since we can retrieve all available data.

Can you please simulate another fault – do not clear it, and post the corresponding history entry as hex?
Then, resolve the fault, check the fault history once more, and post it as well.
In theory, there should be A) new entry, with a different status code when the fault is resolved, or B) the initial history entry gets updated with a new status code.

burmistrzak · 2025-02-10T17:27:20Z

Yes, this is unfortunate. One could also include the unit 'hours' in the name: e.g. Z*QuickVetoHours to circumvent, but an Enum is probably better as the values are restricted anyway (0.5 - 12 in 0.5 increments, default 3).

@chrizzzp That‘s what I was thinking as well, but naming the Enum is tricky. E.g.: 0_5h seems a bit silly..?

Btw. support for value ranges is coming to ebusd, and this PR is already prepared. 😉

kgeree · 2025-02-10T18:52:41Z

Can you please simulate another fault – do not clear it, and post the corresponding history entry as hex?

Is this what you mean?

read -f -c 720 -i 0 errorhistory
0;resolved;19:44;10.02.2025;RECOVAIR_comm_error

hex 15b50303010101
08025920080225fd01

read -f -c 720 CurrentErrors
RECOVAIR_comm_error;-;-;-;-

It seems it shows as "resolved" even if if the error still persists.

burmistrzak · 2025-02-10T22:36:37Z

@kgeree Almost. 😉
Here's a step-by-step:

Simulate a fault
Get the latest error history item hex 15b50303010100, and the previous one for good measure hex 15b50303010101
Resolve the fault
Repeat step No. 2
Post all four responses as hex

We're particularly interested in this byte here: 08 [02] 59 20 08 02 25 fd 01
It's also possible that the status byte is completely meaningless for our purposes...

kgeree · 2025-02-11T08:33:46Z

@kgeree Almost. 😉 Here's a step-by-step:

Simulate a fault

Get the latest error history item hex 15b50303010100, and the previous one for good measure hex 15b50303010101

Resolve the fault

Repeat step No. 2

Post all four responses as hex

We're particularly interested in this byte here: 08 [02] 59 20 08 02 25 fd 01 It's also possible that the status byte is completely meaningless for our purposes...

fault present:

hex 15b50303010100
08022509110225fd01

hex 15b50303010101
08024419100225fd01

fault resolved

hex 15b50303010100
08022509110225fd01

hex 15b50303010101
08024419100225fd01

so no change there

burmistrzak · 2025-02-11T14:25:12Z

@kgeree Thx! Looks like the status field is indeed used for something else… 😅

burmistrzak · 2025-02-16T05:02:22Z

@chrizzzp There‘re new options available in the myVaillant app!
Check under Settings > Control > Energy management > Expert settings > Domestic hot water.

I already tried capturing the register for Upper correction value, but nothing seem to come up..? 🤔
Maybe it’s just adjusting the max DHW temperature?

chrizzzp · 2025-02-16T13:59:20Z

@burmistrzak

Check under Settings > Control > Energy management > Expert settings > Domestic hot water.

As I have only temporary 'External DHW' via VR71 (heating circuit configured as external DHW), these settings don't show up for me in the app...

burmistrzak · 2025-02-16T15:12:07Z

As I have only temporary 'External DHW' via VR71 (heating circuit configured as external DHW), these settings don't show up for me in the app...

@chrizzzp Hmm, you mean Circuit type: DHW on the system regulator?

burmistrzak · 2025-02-16T15:14:41Z

There‘re new options available in the myVaillant app! Check under Settings > Control > Energy management > Expert settings > Domestic hot water.

I already tried capturing the register for Upper correction value, but nothing seem to come up..? 🤔 Maybe it’s just adjusting the max DHW temperature?

@kgeree Can you help out here? 😊

chrizzzp · 2025-02-16T15:27:11Z

@burmistrzak

Hmm, you mean Circuit type: DHW on the system regulator?

Correct, 'external DHW' is a rather personal nomenclature to differentiate it from the regular (internal) DHW circuit. It also operates an external valve.

kgeree · 2025-02-17T07:03:49Z

Energy management

I simply don't even have "Energy management" under Settings -> Control. :)
app version: v2.24.3 (23137) with VR921 GW

burmistrzak · 2025-02-17T13:45:17Z

Energy management

I simply don't even have "Energy management" under Settings -> Control. :) app version: v2.24.3 (23137) with VR921 GW

@kgeree Huh, strange. You do have the option Heating curve settings available, right?
Also, is EEBus (requires a compatible PV system) configured?

kgeree · 2025-02-17T21:23:49Z

Energy management

I simply don't even have "Energy management" under Settings -> Control. :) app version: v2.24.3 (23137) with VR921 GW

@kgeree Huh, strange. You do have the option Heating curve settings available, right? Also, is EEBus (requires a compatible PV system) configured?

Heat curve settings I have, which is working badly...I once tried to change heat curve for 1 circuit and it changed for all 3 :|..since that I rather not touch...
EEBus I don't have.

burmistrzak · 2025-02-17T23:33:34Z

EEBus I don't have.

@kgeree I guess that’s the reason then.
Without some kind of energy management feature configured, it likely won’t show up.

burmistrzak added 7 commits January 27, 2025 17:02

Add baseline support for basv3

33ce9ca

Make template more generic

2fd7676

Add definitions from ctlv3

93d5350

Change opmode to opmode2

33b72bc

Add Z*Status, Z*RoomHumidity, and more templates

3b2f068

Add various timers

df0307d

Add QuickVeto, ESCO & more

40ab79f

burmistrzak mentioned this pull request Jan 28, 2025

Add support for HW5103 HMUs #481

Draft

Merge branch 'master' into add-basv3

3c74010

burmistrzak added 4 commits January 29, 2025 22:50

Minor fixes

35271a0

Rename & align registers

5521438

Fix duplicated id

1840a2d

Add register permissions & bounds

00311cc

burmistrzak added 2 commits January 31, 2025 22:32

Add conditions & cleanup

af83a11

More conditions & new zone status

58fd187

Add support for basv3 #482

Are you sure you want to change the base?

Add support for basv3 #482

Conversation

burmistrzak commented Jan 27, 2025 • edited Loading

burmistrzak commented Jan 27, 2025

burmistrzak commented Jan 28, 2025

john30 commented Jan 28, 2025

burmistrzak commented Jan 29, 2025

kgeree commented Jan 29, 2025

burmistrzak commented Jan 29, 2025 • edited Loading

burmistrzak commented Jan 29, 2025 • edited Loading

burmistrzak commented Jan 30, 2025

jonesPD commented Jan 30, 2025

kgeree commented Jan 30, 2025

burmistrzak commented Jan 30, 2025

kgeree commented Jan 30, 2025

burmistrzak commented Jan 31, 2025

kgeree commented Jan 31, 2025

burmistrzak commented Jan 31, 2025

kgeree commented Feb 8, 2025 • edited Loading

burmistrzak commented Feb 8, 2025

kgeree commented Feb 8, 2025

burmistrzak commented Feb 8, 2025

chrizzzp commented Feb 9, 2025 • edited Loading

kgeree commented Feb 9, 2025

burmistrzak commented Feb 9, 2025

kgeree commented Feb 9, 2025

burmistrzak commented Feb 9, 2025 • edited Loading

burmistrzak commented Feb 9, 2025 • edited Loading

kgeree commented Feb 10, 2025

burmistrzak commented Feb 10, 2025 • edited Loading

burmistrzak commented Feb 10, 2025

kgeree commented Feb 10, 2025

chrizzzp commented Feb 10, 2025 • edited Loading

burmistrzak commented Feb 10, 2025

burmistrzak commented Feb 10, 2025

kgeree commented Feb 10, 2025

burmistrzak commented Feb 10, 2025

kgeree commented Feb 11, 2025

burmistrzak commented Feb 11, 2025

burmistrzak commented Feb 16, 2025

chrizzzp commented Feb 16, 2025

burmistrzak commented Feb 16, 2025

burmistrzak commented Feb 16, 2025

chrizzzp commented Feb 16, 2025

kgeree commented Feb 17, 2025

burmistrzak commented Feb 17, 2025

kgeree commented Feb 17, 2025

burmistrzak commented Feb 17, 2025

Add support for `basv3` #482

Add support for `basv3` #482

burmistrzak commented Jan 27, 2025 •

edited

Loading

burmistrzak commented Jan 29, 2025 •

edited

Loading

burmistrzak commented Jan 29, 2025 •

edited

Loading

kgeree commented Feb 8, 2025 •

edited

Loading

chrizzzp commented Feb 9, 2025 •

edited

Loading

burmistrzak commented Feb 9, 2025 •

edited

Loading

burmistrzak commented Feb 9, 2025 •

edited

Loading

burmistrzak commented Feb 10, 2025 •

edited

Loading

chrizzzp commented Feb 10, 2025 •

edited

Loading