Added config file for VRC710 functionality. #411

R0Y4LTS · 2024-03-21T20:33:39Z

No description provided.

- restored _template.csv to previous commit

New messages Created unknown messages inc file Used defaults

Conversion factor 0.125 instead of 0.0625

LukasGrebe · 2024-10-05T21:39:58Z

.gitignore

 *~
 /ebusd-configuration-*.deb
 /ebusd-configuration-*.tgz
+.DS_Store


use a global git ignore on your system and don't make it project specific ;-)

john30 · 2024-12-27T06:15:21Z

ebusd-2.1.x/de/vaillant/15.emm.csv

+
+*[SW],scan,,,SW,,,,,,,,,
+
+*r,,,,,08,"B524","02000000",,,IGN:4,,,


all of the messages have 08 set as target, to basically the config is for 08 (a heater) and not 15 (a controller).
so something is totally awkward with that.
please share the scan result and some example hex sequences to clarify this

I'll try to clarify.
Yes, all messages have 08 as target. From my observations the 15 device (EMM0, VRC710) changes the behavior / unlocks certain behavior of the 08 device. So the messages are only available, when EMM0 and BAI are online. So what is needed is a mechanism to define a message that is dependent on versions of more than one circuit / device. In this case 08 and 15.
This is why I decided to define message in a 15 configuration file with 08 as target.

But to be honest, I'm not sure if really all messages are only available if both circuits are online.

hm interesting. please share your scan result.
this is really weird and I have not seen such before, so this needs to be sorted out carefully

scan id = no data stored
scan.05 = no data stored
scan.08 = Vaillant;BAI00;1003;7603
scan.08 id = 21;23;23;0010043897;0001;009317;N9
scan.15 = Vaillant;EMM00;0104;8503
scan.15 id = 21;23;24;0020274790;0082;027273;N1
scan.f6 = Vaillant;NETX2;4035;5703
scan.f6 id = 21;23;32;0020260962;0933;127538;N5

Not sure what you're talking about. Can you clarify?

I guess he meant something like this: john30/ebusd#50 ...seems to be possible to change addresses. And if you have done something like this, it will of course mix up everything.
Anyway did you or anyone else made some progress with the vrc 710?

Despite the expressed disbelief on the correctness of 08 target I can confirm the findings of @R0Y4LTS.
Using the CSV files in this pull request I was able to read reasonable looking values.

Hardware is an 'ecoTEC plus' with 'VRC 710' connected using 'Esera EBC 100 eBus Koppler USB' with Vaillant 'VR 940f' cable (#0010035754), default configuration options without address assignments defined.

This is excellent work by @R0Y4LTS and a good start for supporting VRC 710 eventually.

@R0Y4LTS wie bekomme ich deine Änderungen sauber auf meine Kiste?
Habe auch eine ecotec und bei mir ist fast alles futsch. Es lief mit der 22 alles bestens aber dann kam eines Tages ein Update und nichts geht mehr so richtig. 😢
Habe jetzt alles auf HA und Proxmox umgestellt, vorher was alles auf einem PI mit ioBroker.
Ebusd läuft zwar aber ich bekomme noch sehr viele Fehler und es fehlen noch viele Daten wie zB der Wasserdruck. Welchen ich schmerzlich vermisse, weil ich so immer erst merke das Wasser auf die Anlage muss wenn es kalt wird oder kein warmes Wasser mehr aus dem Hahn kommt.

Ich habe die Konfigurationsdateien einfach an den Ort kopiert, an dem ebusd nach Konfigurationsdateien sucht.

john30

Despite the expressed disbelief on the correctness of 08 target I can confirm the findings of @R0Y4LTS.
Using the CSV files in this pull request I was able to read reasonable looking values.

did you use the files as is @doubleO8, i.e. do you also have a EMM in the system? would be good if you could share your scan result as well

john30 · 2025-09-27T13:30:43Z

ebusd-2.1.x/de/vaillant/15.emm.csv

+r,,SpecOpModeAbsentHWStart,Sonderbetriebsart Abwesenheit Warmwasser Start,,,,"0900",,,HDA:3,,,
+r,,SpecOpModeAbsentHWEnd,Sonderbetriebsart Abwesenheit Warmwasser Ende,,,,"0a00",,,HDA:3,,,
+r,,SpecOpModeHWFast,Sonderbetriebsart Warmwasser schnell,,,,"0d00",,,UCH,06=EIN;00=AUS,,
+r,,SpecOpModeAbsentHW.1,Sonderbetriebsart Abwesenheit Warmwasser,,,,"1000",,,U3R,,,


whats the meaning of those, any unit?
same for subsequent messages (like .2 and basically all with U3R type without unit/comment)

I assume this is the status of the absent mode of hot water.
I didn't investigate further.
Seems to be 0, if inactive and a fixed value when active:

pi@raspberrypi2:~/ebusd-2.1.x/de/vaillant $ ebusctl find SpecOpModeAbsent emm SpecOpModeAbsentHW.1 = 1452080 emm SpecOpModeAbsentHW.2 = 1452072 emm SpecOpModeAbsentHWEnd = 28.09.2025 emm SpecOpModeAbsentHWStart = 27.09.2025 emm SpecOpModeAbsentZone1.1 = 1452072 emm SpecOpModeAbsentZone1.2 = 1452080 emm SpecOpModeAbsentZone1End = 28.09.2025 emm SpecOpModeAbsentZone1Start = 27.09.2025 emm SpecOpModeAbsentZone1Temp = no data stored pi@raspberrypi2:~/ebusd-2.1.x/de/vaillant $ ebusctl find SpecOpModeAbsent emm SpecOpModeAbsentHW.1 = 0 emm SpecOpModeAbsentHW.2 = 0 emm SpecOpModeAbsentHWEnd = 01.01.2015 emm SpecOpModeAbsentHWStart = 01.01.2015 emm SpecOpModeAbsentZone1.1 = 0 emm SpecOpModeAbsentZone1.2 = 0 emm SpecOpModeAbsentZone1End = 01.01.2015 emm SpecOpModeAbsentZone1Start = 01.01.2015 emm SpecOpModeAbsentZone1Temp = no data stored

Activation value seems to change with every activation.

pi@raspberrypi2:~/ebusd-2.1.x/de/vaillant $ ebusctl find SpecOpModeAbsent emm SpecOpModeAbsentHW.1 = 1454600 emm SpecOpModeAbsentHW.2 = 1454596 emm SpecOpModeAbsentHWEnd = 29.09.2025 emm SpecOpModeAbsentHWStart = 27.09.2025 emm SpecOpModeAbsentZone1.1 = 1454596 emm SpecOpModeAbsentZone1.2 = 1454600 emm SpecOpModeAbsentZone1End = 29.09.2025 emm SpecOpModeAbsentZone1Start = 27.09.2025 emm SpecOpModeAbsentZone1Temp = no data stored

john30 · 2025-09-27T15:19:33Z

could you also provide some basic info like the output of "ebusctl info" or the log showing the load process @R0Y4LTS ?

R0Y4LTS · 2025-09-27T17:47:35Z

This is the output of ebusctl info:

version: ebusd 23.3.23.3
update check: version 25.1 available, device firmware 1[560f] available, broadcast.csv: newer version available, memory.csv: different version available, vaillant/bai.308523.inc: different version available, vaillant/broadcast.csv: different version available, vaillant/errors.inc: different version available, vaillant/general.csv: different version available, vaillant/hcmode.inc: different version available, vaillant/service.inc: different version available
device: /dev/ttyAMA0, serial high speed, enhanced, firmware 8.1[4106].1[4106]
signal: acquired
symbol rate: 39
max symbol rate: 169
min arbitration micros: 3
max arbitration micros: 386
min symbol latency: 0
max symbol latency: 14
scan: finished
reconnects: 0
masters: 6
messages: 420
conditional: 3
poll: 7
update: 10
address 00: master #1
address 03: master #11
address 04: slave #25, scanned "MF=Vaillant;ID=NETX2;SW=4037;HW=5703"
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=1003;HW=7603", loaded "vaillant/bai.308523.inc", "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=EMM00;SW=0104;HW=8503", loaded "vaillant/15.emm.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address f1: master #10
address f6: slave #10, scanned "MF=Vaillant;ID=NETX2;SW=4037;HW=5703"
address ff: master #25

john30 · 2025-09-28T04:51:23Z

thanks for the input @R0Y4LTS, this helps a lot getting it right.

I'm sure the absence status is revealed in another status message of the bai with a value not seen so far (probably in some hcmode or hcmode2 field). the new absence messages you found with the high numeric value I'd rather leave out as they seem to be some internal countdown timer or such.

SpecOpModeAbsentZone1Temp has no data at all? then better leave that out as well. or did you really see some data in there when you defined the message?

john30 · 2025-09-28T05:13:48Z

could you share some of the energy count readings? did you try dividing each value by the factor mentioned in the message, e.g. is the value of ConsumedPrimaryEnergyHeating / 0.125 shown somewhere on the display?
maybe it is an EXP field type. if you share some hex data of those I can check (or you could comment one of those lines and then use "ebusctl grab result decode" to see what it might be in EXP once it appeared). you could as well use "ebusctl decode EXP XXXXXXXX" to decode a hex sequence as EXP to check

R0Y4LTS · 2025-09-28T07:00:08Z

I'm sure I had seen a temp value in the past for SpecOpModeAbsentZone1Temp which let me interpret this as temperature.
At the moment heating is switched off. This could be the reason.

R0Y4LTS · 2025-09-28T07:57:09Z

The ConsumedPrimaryEnergyX message is not completely understood by me yet. I compared the differences with the energy status data in the app. I found out a factor that seems to fit. But it changes over time. It was 0.0625, 0.125, 0.25. Now it seems to be 0.5.
The change is not deterministic to me. It could be transmitted in another message, be an algorithm thing or misinterpretation of the value.
Nevertheless the app is able to calculate consumed primary energy of it.

These are my current values:

pi@raspberrypi2:~ $ ebusctl find Consumed

emm ConsumedElectricalEnergyHeating = 1201486798
emm ConsumedElectricalEnergyHW = 1189727627
emm ConsumedElectricalEnergyOfSomething = 0
emm ConsumedPrimaryEnergyHeating = 1252430804
emm ConsumedPrimaryEnergyHW = 1250060750

1250057034 was the value at the start of the day for hot water.

(1250060750 - 1250057034) * 0,5 =1.858

Value in the app 1,9 kWh

What's the easiest way to get hex values if the message is already interpreted by an config file?

john30 · 2025-09-28T07:59:10Z

What's the easiest way to get hex values if the message is already interpreted by an config file?

you can use "ebusctl find -h Consumed"

R0Y4LTS · 2025-09-28T08:00:18Z

pi@raspberrypi2:~ $ ebusctl find -h Consumed
emm ConsumedElectricalEnergyHeating = f108b516081000ffff83030000 / 0b00000083033c33ee3c9d47
emm ConsumedElectricalEnergyHW = f108b516081000ffff83040000 / 0b00000383043c338bcde946
emm ConsumedElectricalEnergyOfSomething = f108b516081000ffff83050000 / 0b1000ff83053c3300000000
emm ConsumedPrimaryEnergyHeating = 3108b516081000ffff84030000 / 0b00000184033c33d493a64a
emm ConsumedPrimaryEnergyHW = 3108b516081000ffff84040000 / 0b00000484043c33ce69824a

john30 · 2025-09-28T08:11:52Z

it seems to be in EXP format indeed, as:
"decode exp CE69824A" = 4.27338e+06 = 4273380
"decode exp 4A5B824A" = 4.27152e+06 = 4271520
and the difference is 1860, i.e. 1.86 kWh
do you have more values from the start of the day from the other messages (decoded or not does not matter)?
and could 4.3 MWh be the total?

john30 · 2025-09-28T17:20:43Z

I've completely reworked it now in commit 1789377. this might need the enhancement in john30/ebusd@9b511cf in order to work, would be good if you could check it.
in order to get the resulting csvs, just checkout this repo, run "npm i" and "npm run compile", then the resulting csvs are in the subfolder mentioned in the output

R0Y4LTS · 2025-09-28T18:01:51Z

and could 4.3 MWh be the total?

Yes, you are right! Actually, it's the total consumed energy for hot water.

john30 · 2025-09-30T04:03:04Z

and could 4.3 MWh be the total?

Yes, you are right! Actually, it's the total consumed energy for hot water.

great. so that's fine.
I've also added a lot of messages from ctlv2 with "(untested)" in the comment. would be great if you could give those a try as well in order to verify they're working as well.
the latest version is already published in the next endpoint, so you can simply use that one

doubleO8 · 2025-10-01T20:26:11Z

The files are used as is (as given by this PR).

# SHA 256 sums of used files
$ sha256sum vaillant/bai.308523.inc vaillant/15.emm.csv vaillant/08.bai.csv
3bfeef9cbdd38f0bee5bd69033aba5ae42dea9b7754e9357ec8dc957f88cc4e2  vaillant/bai.308523.inc
75036e15c6ea311688ae37952ae95d046382adda0959108c8abbb4db32ab4a6d  vaillant/15.emm.csv
4881e2cdd42101c7120ee959d9db3eeff997a76383a7f9cb743b6e4250e0e1c4  vaillant/08.bai.csv

Scan result et al:

$ ebusctl info
version: ebusd 25.1.25.1
device: /dev/serial/by-id/usb-ESERA_GmbH_eBus_Coupler....
access: *
signal: acquired
symbol rate: 23
max symbol rate: 150
min arbitration micros: 2
max arbitration micros: 881
min symbol latency: 3
max symbol latency: 11
scan: finished
reconnects: 0
masters: 4
messages: 408
conditional: 3
poll: 0
update: 10
address 00: master #1
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=1201;HW=7603", loaded "vaillant/bai.308523.inc", "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=EMM00;SW=0104;HW=8503", loaded "vaillant/15.emm.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd, scanning

$ ebusctl find SpecOpModeAbsent
emm SpecOpModeAbsentHW.1 = 0
emm SpecOpModeAbsentHW.2 = 0
emm SpecOpModeAbsentHWEnd = 01.01.2019
emm SpecOpModeAbsentHWStart = 01.01.2019
emm SpecOpModeAbsentZone1.1 = 0
emm SpecOpModeAbsentZone1.2 = 0
emm SpecOpModeAbsentZone1End = 01.01.2019
emm SpecOpModeAbsentZone1Start = 01.01.2019
emm SpecOpModeAbsentZone1Temp =  (ERR: invalid position for 3108b5240602000000f600 / 080300f60000007041)

$ ebusctl find -h Consumed
emm ConsumedElectricalEnergyHeating = 3108b516081000ffff83030000 / 0b00000083034133b9489f47
emm ConsumedElectricalEnergyHW = 3108b516081000ffff83040000 / 0b0000038304413386fb3044
emm ConsumedElectricalEnergyOfSomething = 3108b516081000ffff83050000 / 0b1000ff8305413300000000
emm ConsumedPrimaryEnergyHeating = 3108b516081000ffff84030000 / 0b00000184034133b619944a
emm ConsumedPrimaryEnergyHW = 3108b516081000ffff84040000 / 0b00000484044133008c5848

(Just ping if you need any additional output values)

john30 · 2025-10-19T07:18:25Z

The files are used as is (as given by this PR).

I was asking for verifying the newly generated ones: https://ebus.github.io/next/

Added config file for VRC710 functionality.

d6f5ed5

R0Y4LTS closed this Mar 22, 2024

R0Y4LTS reopened this Mar 22, 2024

R0Y4LTS added 4 commits March 22, 2024 20:13

+ added new messages to emm

7add4b8

- restored _template.csv to previous commit

Reordered messages

e600590

New messages Created unknown messages inc file Used defaults

Added new messages

888df43

Changed comment for ConsumedPrimaryEnergyHW

7a36c07

Conversion factor 0.125 instead of 0.0625

LukasGrebe reviewed Oct 5, 2024

View reviewed changes

john30 requested changes Dec 27, 2024

View reviewed changes

john30 reviewed Sep 27, 2025

View reviewed changes

john30 added a commit that referenced this pull request Sep 28, 2025

rework #411, add temporary workaround for unesired bai conditional load

1789377

john30 added a commit that referenced this pull request Sep 30, 2025

stash probably droppable message from PR #411

ff54c53


		*[SW],scan,,,SW,,,,,,,,,

		*r,,,,,08,"B524","02000000",,,IGN:4,,,

Added config file for VRC710 functionality. #411

Are you sure you want to change the base?

Added config file for VRC710 functionality. #411

Uh oh!

Conversation

R0Y4LTS commented Mar 21, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

john30 left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

john30 commented Sep 27, 2025

Uh oh!

R0Y4LTS commented Sep 27, 2025

Uh oh!

john30 commented Sep 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

john30 commented Sep 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

R0Y4LTS commented Sep 28, 2025

Uh oh!

R0Y4LTS commented Sep 28, 2025

Uh oh!

john30 commented Sep 28, 2025

Uh oh!

R0Y4LTS commented Sep 28, 2025

Uh oh!

john30 commented Sep 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

john30 commented Sep 28, 2025

Uh oh!

R0Y4LTS commented Sep 28, 2025

Uh oh!

john30 commented Sep 30, 2025

Uh oh!

doubleO8 commented Oct 1, 2025

Uh oh!

john30 commented Oct 19, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

john30 left a comment •

edited

Loading

john30 commented Sep 28, 2025 •

edited

Loading

john30 commented Sep 28, 2025 •

edited

Loading

john30 commented Sep 28, 2025 •

edited

Loading