Abitration lost Vaillant ecoTEC plus VCW 206/5-5

[mwolle]

Hello,
i have some problems with the connection/ scanning of eBus participants. Following configuration:
ebus-Koppler by ESERA, ebusd Version 23.3
log:
2024-01-19 11:50:00.902 [main debug] >>> i
2024-01-19 11:50:00.902 [main debug] <<< version: ebusd 23.3.23.3
update check: OK
device: tcp:192.168.178.33:5000, TCP
access: *
signal: acq ...
2024-01-19 11:50:00.903 [network info] [00025] connection closed
2024-01-19 11:50:01.109 [bus debug] arbitration won
2024-01-19 11:50:01.109 [bus debug] arbitration delay 4 micros
2024-01-19 11:50:01.109 [bus debug] switching from ready to send command
2024-01-19 11:50:01.114 [bus debug] send/receive symbol latency 5 ms
2024-01-19 11:50:01.120 [bus debug] send/receive symbol latency 5 ms
2024-01-19 11:50:01.125 [bus debug] send/receive symbol latency 5 ms
2024-01-19 11:50:01.131 [bus debug] send/receive symbol latency 5 ms
2024-01-19 11:50:01.131 [bus debug] switching from send command to send command>
2024-01-19 11:50:01.136 [bus debug] send/receive symbol latency 5 ms
2024-01-19 11:50:01.136 [bus debug] switching from send command CRC to receive >
2024-01-19 11:50:01.206 [bus debug] notify request: ERR: read timeout
2024-01-19 11:50:01.206 [bus info] scan c3 cmd: 31c3070400
2024-01-19 11:50:01.206 [bus debug] ERR: read timeout during receive command AC>
2024-01-19 11:50:01.206 [bus debug] start request 31
2024-01-19 11:50:01.206 [bus debug] arbitration start with 31
2024-01-19 11:50:01.648 [bus debug] arbitration won
2024-01-19 11:50:01.648 [bus debug] arbitration delay 10 micros
2024-01-19 11:50:01.649 [bus debug] switching from ready to send command
2024-01-19 11:50:01.655 [bus debug] send/receive symbol latency 5 ms
2024-01-19 11:50:01.662 [bus debug] send/receive symbol latency 7 ms
2024-01-19 11:50:01.668 [bus debug] send/receive symbol latency 5 ms
2024-01-19 11:50:01.673 [bus debug] send/receive symbol latency 5 ms
2024-01-19 11:50:01.673 [bus debug] switching from send command to send command>
2024-01-19 11:50:01.679 [bus debug] send/receive symbol latency 5 ms
2024-01-19 11:50:01.679 [bus debug] switching from send command CRC to receive >
2024-01-19 11:50:01.749 [bus debug] notify request: ERR: read timeout
2024-01-19 11:50:01.749 [bus info] scan c4 cmd: 31c4070400
2024-01-19 11:50:01.749 [bus debug] ERR: read timeout during receive command AC>
2024-01-19 11:50:01.749 [bus debug] start request 31
2024-01-19 11:50:01.750 [bus debug] arbitration start with 31
2024-01-19 11:50:01.767 [network debug] dead connection removed - 0
2024-01-19 11:50:02.230 [bus debug] ERR: CRC error during receive command CRC, >
2024-01-19 11:50:02.240 [bus debug] ERR: ACK error during receive command ACK, >
2024-01-19 11:50:02.470 [bus debug] arbitration won
2024-01-19 11:50:02.470 [bus debug] arbitration delay 5 micros
2024-01-19 11:50:02.470 [bus debug] switching from ready to send command
2024-01-19 11:50:02.476 [bus debug] send/receive symbol latency 5 ms
2024-01-19 11:50:02.482 [bus debug] send/receive symbol latency 5 ms
2024-01-19 11:50:02.487 [bus debug] send/receive symbol latency 5 ms
2024-01-19 11:50:02.493 [bus debug] send/receive symbol latency 5 ms
2024-01-19 11:50:02.493 [bus debug] switching from send command to send command>
2024-01-19 11:50:02.498 [bus debug] send/receive symbol latency 5 ms
2024-01-19 11:50:02.498 [bus debug] switching from send command CRC to receive >
2024-01-19 11:50:02.568 [bus debug] notify request: ERR: read timeout
2024-01-19 11:50:02.569 [bus info] scan c5 cmd: 31c5070400
2024-01-19 11:50:02.569 [bus debug] ERR: read timeout during receive command AC>
2024-01-19 11:50:02.569 [bus debug] start request 31
2024-01-19 11:50:02.569 [bus debug] arbitration start with 31
.
.
.
2024-01-19 11:50:03.650 [bus debug] notify request: ERR: read timeout
2024-01-19 11:50:03.650 [bus info] scan c7 cmd: 31c7070400
2024-01-19 11:50:03.650 [bus debug] ERR: read timeout during receive command AC>
2024-01-19 11:50:03.650 [bus debug] start request 31
2024-01-19 11:50:03.650 [bus debug] arbitration start with 31
2024-01-19 11:50:04.091 [bus debug] arbitration lost
2024-01-19 11:50:04.091 [bus debug] ERR: arbitration lost during ready, retry
2024-01-19 11:50:04.164 [bus debug] ERR: read timeout during receive command, s>
2024-01-19 11:50:04.164 [bus debug] start request 31
2024-01-19 11:50:04.164 [bus debug] arbitration start with 31
2024-01-19 11:50:04.647 [bus debug] arbitration lost
2024-01-19 11:50:04.648 [bus debug] ERR: arbitration lost during ready, retry
2024-01-19 11:50:04.720 [bus debug] ERR: read timeout during receive command, s>
2024-01-19 11:50:04.720 [bus debug] start request 31

and this repeats again and again.

My config:
EBUSD_OPTS="--scanconfig=full --configpath=https://cfg.ebusd.eu/ --accessleve=* -d tcp:192.168.XXX.XX:5000 --address=31 --latency 5000 --acquiretimeout=15000 --loglevel=debug --httpport=8889"

version: ebusd 23.3.23.3
update check: OK
device: tcp:192.168.178.33:5000, TCP
access: *
signal: acquired
symbol rate: 31
max symbol rate: 43
min arbitration micros: 3
max arbitration micros: 52
min symbol latency: 5
max symbol latency: 32
scan: finished
reconnects: 0
masters: 1
messages: 11
conditional: 0
poll: 0
update: 4
address 31: master #8, ebusd
address 36: slave #8, ebusd, scanning

i can't identify a problem, i change the cable, i change the koppler vom ECO305 to 12002, i set the threshold, nothing helps.

[gmbo]

Ich nutze zwar den ebus-adapter v5 von John30 für eine atmoTEC exclusiv VCW DE 204/4-7-HL hatte bis vorhin aber die gleichen Probleme.
Auch ich dachte erst an Busverkabelung, konnte aber eigentlich nicht direkt sein, da die LEDs des Adapters sich wie an einem laufenden Bus blinkten und ja die Abfrage einen Master und einen Slave des Adapters zeigten. Dann war ich der Meinung, dass wohl bei Vaillant der externe eBus erst funktioniert wenn Der analoge Regler mit seiner 789 schnittstelle gegen einen mit eBus ausgetausch wäre. Nach vielen Suchen fand ich den ersten Tip: Benutze den enhanced Mode.

Leider führte das nicht direkt zum Erfolg. Erst als ich in der Konfigurationsdatei --receivetimeout=100000 --latency=10000 einfügte bekam ich die Heizung angezeigt.

Meine Konfig ist jetzt:
EBUSD_OPTS="--device=enh:192.168.xxx.xxx:9999 --receivetimeout=100000 --latency=10000 --mqtttopic=ebusd/%circuit/%name --mqtthost=192.168.xxx.xxx --mqttport=1883 --mqttuser=USER --mqttpass=Passw0rd --accesslevel=* --scanconfig=full"

$ ebusctl i
version: ebusd 23.3.23.3
update check: OK
device: 192.168.xxx.xxx:9999, TCP, enhanced, firmware 1.1[4106].1[4106]
access: *
signal: acquired
symbol rate: 23
max symbol rate: 61
scan: finished
reconnects: 1
masters: 2
messages: 224
conditional: 3
poll: 0
update: 10
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0703;HW=7401", loaded "vaillant/bai.308523.inc" ([HW=7401]), "vaillant/08.bai.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd, scanning

Danach machte ich viele Versuche etwas geziehlt zu lesen mit wenig Erfolg, da ich wohl nicht den richtigen Namen eingesetzt hatte.

Die Namen konnte ich dann durch weitere Suche in Foren mit find auslesen.

ebusctl find -F circuit,name,comment
brachte mir eine lange Liste mit Namen die ich dann abfragen konnte.

bai,AccessoriesOne,d.27 Option relais 1
bai,AccessoriesTwo,d.28 Option relais 2
bai,ACRoomthermostat,d.08 Room thermostat 230 V
bai,averageIgnitiontime,d.64 average ignition time
....

Aber auch hier erhielt ich oft eine Fehlermeldung

ebusctl read -f -V -c bai SerialNumber
ERR: wrong symbol received

eine direkte Wiederholung liefert dann ein gültiges Ergebnis.

ebusctl read -f -V -c bai SerialNumber
bai SerialNumber =30 30 30 30 36 39 31 33 [serial number of AI]

Ich hoffe, das hilft dir weiter.

Although I use the ebus adapter v5 from John30 for an atmoTEC exclusiv VCW DE 204/4-7-HL, I had the same problems until just now.
At first I also thought it was bus cabling, but it couldn't actually be direct, as the LEDs on the adapter were flashing as if they were on a running bus and the query showed a master and a slave of the adapter. Then I thought that the external eBus would only work at Vaillant if the analog controller with its 789 interface was replaced by one with eBus. After a lot of searching, I found the first tip: use the enhanced mode.

Unfortunately, this did not lead directly to success. Only when I inserted --receivetimeout=100000 --latency=10000 in the configuration file did I get the heating displayed.

My config is now:
EBUSD_OPTS="--device=enh:192.168.xxx.xxx:9999 --receivetimeout=100000 --latency=10000 --mqtttopic=ebusd/%circuit/%name --mqtthost=192.168.xxx.xxx --mqttport=1883 --mqttuser=USER --mqttpass=Passw0rd --accesslevel=* --scanconfig=full"

$ ebusctl i
version: ebusd 23.3.23.3
update check: OK
device: 192.168.xxx.xxx:9999, TCP, enhanced, firmware 1.1[4106].1[4106]
access: *
signal: acquired
symbol rate: 23
max symbol rate: 61
scan: finished
reconnects: 1
masters: 2
messages: 224
conditional: 3
poll: 0
update: 10
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0703;HW=7401", loaded "vaillant/bai.308523.inc" ([HW=7401]), "vaillant/08.bai.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd, scanning

I then made many attempts to read something in a targeted manner with little success, as I had probably not entered the correct name.

I was then able to read the names by further searching in forums with find.

ebusctl find -F circuit,name,comment
brought me a long list of names that I could then query.

bai,AccessoriesOne,d.27 Option relay 1
bai,AccessoriesTwo,d.28 Option relay 2
bai,ACRoomthermostat,d.08 Room thermostat 230 V
bai,averageIgnitiontime,d.64 average ignition time
....

But here, too, I often received an error message

ebusctl read -f -V -c bai SerialNumber
ERR: wrong symbol received

a direct repetition then provides a valid result.

ebusctl read -f -V -c bai SerialNumber
bai SerialNumber =30 30 30 30 36 39 31 33 [serial number of AI]

I hope this helps you.

Translated with DeepL.com (free version)

[mwolle]

Besten Dank für deine Hinweise, der enhanced Modus scheint nicht zu funktioniert, da konnte ich jetzt immer sehen, wie er die Verbindung aufbaut, aber sofort wieder ganz verliert und wieder von vorne startet. Aber ich habe jetzt die Latenz und Antwortzeit hochgesetzt...ich bin gespannt...

[mwolle]

Ich habe deine Parameter noch eingebaut, leider keine Änderung. Ich überlege gerade, ob es am Regler liegen kann. Das ist eine Funkfernbedienung (bzw. wie eine Funkfernbedienung), könnte es an der liegen? Das die nicht/ nicht schnell genug antwortet?

[gmbo]

Mir ist gerade noch etwas aufgefallen.
Ich musste noch ein ebusctl scan ausführen, erst danach erkannte er die Therme.

I've just noticed something else.
I had to run an ebusctl scan, only then did it recognize the Therme.

[mwolle]

ich starte den Service immer neu, nach Änderung der Konfiguration...leider bringen die Einstellungen derzeit keine Besserung.

[gmbo]

Mir war vorhin aufgefallen, dass ich die Therme nicht mehr erreichte als ich mit
raspi-config die Spracheinstellung auf de_DE.UTF-8 eingestellt und die config um
--configlang=LANG erweitert hatte.
Danach sah ich auch nach Neustart und Reboot nur noch den Adapter, obwohl ich an der Hardware Adapter Therme nichts geändert hatte.
also noch mal alle Befehle von Heute durchgegangen und festgestellt, dass
ebusctl scan
vor der Abfrage
ebusctl i
erst den Slave 8 sichtbar machte und alles wieder funktionierte.

[mwolle]

Tatsächlich gibt das keine Besserung. Das Verhalten ist derzeit immer gleich. Ich habe ein wenig den Regler im Verdacht, ob es an dem liegt.

[mwolle]

Der Regler ist ein CalorMatic 370F, könnte dass das Problem sein?