eBUS Adapter 3.0 Inbetriebnahme

[TobiasR]

Hallo,
John hat mir auf die Sprünge geholfen. Ich muss natürlich den ebusd auf dem Raspberry installieren.
Jetzt habe ich dort  aber das Problem dass er nicht startet.

Code Auswählen Erweitern

pi@ioBroker:~ $ sudo service ebusd start
Job for ebusd.service failed because the control process exited with error code.
See "systemctl status ebusd.service" and "journalctl -xe" for details.


Code Auswählen Erweitern


░░ A start job for unit ebusd.service has finished with a failure.
░░
░░ The job identifier is 7658 and the job result is failed.
Dec 18 07:32:01 ioBroker CRON[5192]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
Dec 18 07:32:01 ioBroker CRON[5193]: (root) CMD (/bin/mount -a > /dev/null 2>&1)
Dec 18 07:32:01 ioBroker CRON[5192]: pam_unix(cron:session): session closed for user root
Dec 18 07:32:04 ioBroker systemd[1]: ebusd.service: Scheduled restart job, restart counter is at 103.
░░ Subject: Automatic restarting of a unit has been scheduled
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ Automatic restarting of the unit ebusd.service has been scheduled, as the result for
░░ the configured Restart= setting for the unit.
Dec 18 07:32:04 ioBroker systemd[1]: Stopped ebusd, the daemon for communication with eBUS heating systems..
░░ Subject: A stop job for unit ebusd.service has finished
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ A stop job for unit ebusd.service has finished.
░░
░░ The job identifier is 7723 and the job result is done.
Dec 18 07:32:04 ioBroker systemd[1]: Starting ebusd, the daemon for communication with eBUS heating systems....
░░ Subject: A start job for unit ebusd.service has begun execution
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ A start job for unit ebusd.service has begun execution.
░░
░░ The job identifier is 7723.
Dec 18 07:32:04 ioBroker ebusd[5195]: /usr/bin/ebusd: error while loading shared libraries: libssl.so.3: cannot open shared object file: No such file or directory
Dec 18 07:32:04 ioBroker systemd[1]: ebusd.service: Control process exited, code=exited, status=127/n/a
░░ Subject: Unit process exited
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ An ExecStart= process belonging to unit ebusd.service has exited.
░░
░░ The process' exit code is 'exited' and its exit status is 127.
Dec 18 07:32:04 ioBroker systemd[1]: ebusd.service: Failed with result 'exit-code'.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ The unit ebusd.service has entered the 'failed' state with result 'exit-code'.
Dec 18 07:32:04 ioBroker systemd[1]: Failed to start ebusd, the daemon for communication with eBUS heating systems..
░░ Subject: A start job for unit ebusd.service has failed
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ A start job for unit ebusd.service has finished with a failure.
░░
░░ The job identifier is 7723 and the job result is failed.

Kann mir da bitte jemand einen Tipp geben?

[aia]

ich hab den ebus adapter 3.1, letzte firmware und funktioniert soweit auch alles.

konfiguriert hab ich eine fixe ip, mir ist jetzt aber was komisches aufgefallen.

scheinbar gib es trotz konfigurierter fixer ip laufend dhcp requests.
lt. meiner firewall
DROP Bridge A1-DHCP-3: forward: in:ether2(ether2) out:ether5, src-mac ae:b0:53:32:15:10, dst-mac ff:ff:ff:ff:ff:ff, eth-proto 0800, UDP, 10.0.0.7:68->255.255.255.255:67, len 299

kommt im prinzip jede minute 1x

hat da jemand vielleicht eine idee dazu??

[denni]

Hab den Fehler gefunden, hatte keinen Treiber installiert. Hab das leider nirgends lesen können.

Kannst du sagen welchen Treiber du installiert hast? Ich habe aktuell das selbe Problem.

Danke dir. Grüße

[weini]

Hallo!

Ich habe meinen eBus Adapter 3.0 seit 2021 mit einer Wolf CGB-2 im Einsatz.
Da ich die WLAN Variante verwendet, habe ich --latency immer auf 100 gestellt.

Normalerweise möchte ich nur Werte auslesen. Für einen einzigen Usecase würde ich aber gerne die Solltemperatur für das Warmwasser setzen. Das Schreiben auf dem Ebus hat aber nie geklappt und ist bei Wolf auf Grund der nicht so perfekten CSVs viel Trial & Error.

Jetzt hab ich mich wieder drangesetzt und dabei festgestellt, dass ich plötzlich schreiben kann, wenn ich die --latency auf 10000 erhöhe. Ist das "normal" / erklärebares Verhalten?

Weiter ist mir aufgefallen, dass ich die --latency auf 100 (wie bisher) oder auf 10000 setzen kann. Wenn ich sie aber auf 1000 setze, dann startet mir der ebusd nicht mehr (Debian Bullseye Pakete auf Raspi, aktuelle Version).

Viele Grüße,
weini

[tomhead]

Hallo!

Ich habe meinen eBus Adapter 3.0 seit 2021 mit einer Wolf CGB-2 im Einsatz.

Viele Grüße,
weini

Hallo Weini, könntest du vielleicht mal hier deine csv's teilen, ich habe auch eine Wolf CGB-2 (dazu noch CHA-10) und habe mit meinen csv'sbisher nur wenig auslesen können.
Vielen Dank u. Grüße

[weini]

Sehr gerne.
Mit meiner Konfig funktioniert das lesen recht gut. Schreiben ist für mich aber immer noch so gut wie unmöglich. Mit der Feinjustierung der Latenz bin ich da zwar prinzipiell weitergekommen, aber die Werte die ich ändern will, lassen sich leider nicht schreiben.

[bumaas]

Ich scheitere leider an der Inbetriebnahme des Adapters 3.1 (07/2022), der in einem Raspberry aufgesteckt ist. Die Leds des Adapters leuchten wie sie sollen (grün blinkt), aber ebusctl liefert "no signal"

Code Auswählen Erweitern

version: ebusd 23.3.23.3
update check: OK
device: /dev/ttyAMA0, serial speed, enhanced
access: *
signal: no signal
reconnects: 0
masters: 1
messages: 11
conditional: 0
poll: 0
update: 4
address 04: slave #25, ebusd
address ff: master #25, ebusd

Am Ebus selber kann es meiner Meinung nach nicht liegen, denn ein älterer Adapter V2 lief daran bislang daran ohne Probleme.

Ich habe den Raspberry Pi 3 Model B Rev 1.2 frisch mit Debian GNU/Linux 12 (bookworm), arm64 neu aufgesetzt und dmesg zeigt die erwartete Ausgabe:

Code Auswählen Erweitern

dmesg|grep ttyAMA0 liefert

Code Auswählen Erweitern

[    2.867335] 3f201000.serial: ttyAMA0 at MMIO 0x3f201000 (irq = 99, base_baud = 0) is a PL011 rev2

Code Auswählen Erweitern

ps aux | grep -v grep | grep "ebusd"liefert

Code Auswählen Erweitern

root        1764  0.1  0.9 307932  8632 ?        Ssl  13:35   0:00 /usr/bin/ebusd -d enh:/dev/ttyAMA0 --latency=40 --address=ff --scanconfig --accesslevel=*
Soweit sieht es in meinen Augen schon ganz gut aus.

Im Logfile gibt es jedoch Fehlereinträge:

Code Auswählen Erweitern

2024-07-13 14:12:55.423 [network debug] SSL state 9=SSLv3/TLS read server session ticket: type 0x1001=loop,connect, val>2024-07-13 14:12:55.423 [network debug] SSL state 1=SSL negotiation finished successfully: type 0x1002=exit,connect, va>2024-07-13 14:12:55.443 [network debug] SSL state 1=SSL negotiation finished successfully: type 0x1001=loop,connect, va>2024-07-13 14:12:55.443 [network debug] SSL state 1=SSL negotiation finished successfully: type 0x1001=loop,connect, va>2024-07-13 14:12:55.443 [network debug] SSL state 9=SSLv3/TLS read server session ticket: type 0x1001=loop,connect, val>2024-07-13 14:12:55.443 [network debug] SSL state 1=SSL negotiation finished successfully: type 0x1002=exit,connect, va>2024-07-13 14:12:55.464 [network debug] SSL state 1=SSL negotiation finished successfully: type 0x4008=write,alert, val>2024-07-13 14:12:55.465 [main info] successfully read file memory.csv
2024-07-13 14:12:55.465 [main info] read config files, got 11 messages
2024-07-13 14:12:55.465 [bus notice] bus started with own address 31/36
2024-07-13 14:12:55.465 [bus error] device status: missing enhanced byte 2
2024-07-13 14:12:55.465 [bus error] device status: missing enhanced byte 2
2024-07-13 14:12:55.465 [bus error] device status: missing enhanced byte 2
2024-07-13 14:12:55.465 [bus error] device status: missing enhanced byte 2
2024-07-13 14:12:55.465 [bus error] device status: missing enhanced byte 2
2024-07-13 14:12:55.465 [bus error] device status: missing enhanced byte 2
...
Hat jemand einen Tipp, an welcher Stelle das Problem nun zu suchen ist?

Vielen Dank

Burkhard

Hat jemand eine Idee, wo ich nun ansetzen müsste?

[Reini88]

Hallo Burkhard,

bei dir lautet der Devicename "-d enh:/dev/ttyAMA0",
bei mir dagegen "-d ens:/dev/ttyAMA0".

Ich bin kein ebusd-Experte, aber vielleicht liegt da ja dein Problem.

[bumaas]

bei dir lautet der Devicename "-d enh:/dev/ttyAMA0",
bei mir dagegen "-d ens:/dev/ttyAMA0".

Oh je, das habe ich überhaupt nicht gesehen. Das war es.

Nun kommt eine erweiterte Ausgabe

Code Auswählen Erweitern

version: ebusd 23.3.23.3
device: /dev/ttyAMA0, serial high speed, enhanced, firmware 1.1[8419].2[847f]
access: *
signal: acquired
und der scan des Busses liefert ein Ergebnis. Jetzt kann es weitergehen

Vielen Dank!

[john30]

bei dir lautet der Devicename "-d enh:/dev/ttyAMA0",
bei mir dagegen "-d ens:/dev/ttyAMA0".

Oh je, das habe ich überhaupt nicht gesehen. Das war es.

Code Auswählen Erweitern

version: ebusd 23.3.23.3
device: /dev/ttyAMA0, serial high speed, enhanced, firmware 1.1[8419].2[847f]
access: *
signal: acquired

genau, einfach der Anleitung folgen dann klappts schon

[Comarrid]

Hallo,

es freut mich zu hören, dass dein Adapter angekommen ist und du ihn bereits erfolgreich per USB eingebunden hast. Vielen Dank auch für das positive Feedback an das Team!

Zu deinem Problem: Es klingt so, als ob du Schwierigkeiten mit dem Laden der .csv-Dateien hast. Hier sind einige Ansätze, die dir vielleicht weiterhelfen könnten:

Dateipfade überprüfen: Stelle sicher, dass die Pfade zu deinen .csv-Dateien korrekt in deiner Konfiguration angegeben sind. Manchmal kann ein kleiner Tippfehler oder ein falscher Pfad dazu führen, dass die Dateien nicht gefunden werden.

Dateiberechtigungen: Überprüfe, ob die Dateien die richtigen Berechtigungen haben. Der Benutzer, unter dem FHEM läuft, benötigt Lesezugriff auf die Dateien.

Logdateien durchsuchen: Schau dir die Logdateien von FHEM an. Dort könnten Fehlermeldungen oder Hinweise darauf zu finden sein, warum die .csv-Dateien nicht geladen werden.

MQTT-Setup überprüfen: Da du MQTT erwähnst, vergewissere dich, dass die MQTT-Verbindung richtig konfiguriert ist und dass die Nachrichten korrekt gesendet und empfangen werden.

Format der .csv-Dateien: Manchmal kann auch das Format der .csv-Dateien ein Problem sein. Stelle sicher, dass die Dateien im richtigen Format vorliegen und keine zusätzlichen oder fehlenden Trennzeichen enthalten.

Falls du die obigen Schritte bereits überprüft hast und das Problem weiterhin besteht, könntest du versuchen, spezifische Fehlermeldungen oder Details hier zu posten. Das könnte helfen, das Problem gezielt anzugehen.

Ich hoffe, diese Ansätze helfen dir weiter. Viel Erfolg bei der weiteren Einrichtung!

Beste Grüße

[DerFranke]

Hallo John,
bisher konnte ich Vor- und Rücklauf immer durch:

Code Auswählen Erweitern

# Vorlauftemperatur
get Vorlauf cmd {"r -m 10 status01 temp1.0\n"}
get Vorlauf expect "\d+\.\d+\n"
get Vorlauf postproc { sprintf("%5.1f",$_) }
#
# Ruecklauftemperatur
get Ruecklauf cmd {"r -m 10 status01 temp1.1\n"}
get Ruecklauf expect "\d+\.\d+\n\n"
get Ruecklauf postproc { sprintf("%5.1f",$_) }
#
auslesen.
Irgendwie geht das seit ein paar Tagen nicht mehr (nach Raspi-Reboot) und in der 15.700.csv finde ich auch keinen passenden Wert.

Hast Du eine Idee / Vorschlag?

Code Auswählen Erweitern

address 04: slave #25, ebusd
address 08: slave #11, scanned "MF=Vaillant;ID=HMU01;SW=0304;HW=8802", loaded "vaillant/08.hmu.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0209;HW=4103", loaded "vaillant/15.700.csv"
address 71: master #9
address 76: slave #9, scanned "MF=Vaillant;ID=VWZIO;SW=0111;HW=0103"
address e8: slave, scanned "MF=Vaillant;ID=FMU00;SW=0203;HW=6502"
address ff: master #25, ebusd

Achso, nochwas:

Code Auswählen Erweitern

ebusctl find status01
hmu Status01 = 22.0;22.0;-;-;-;offfunktioniert. Komisch.

Viele Grüße

[john30]

Hallo John,
bisher konnte ich Vor- und Rücklauf immer durch:

Code Auswählen Erweitern

# Vorlauftemperatur
get Vorlauf cmd {"r -m 10 status01 temp1.0\n"}
get Vorlauf expect "\d+\.\d+\n"
get Vorlauf postproc { sprintf("%5.1f",$_) }
#
# Ruecklauftemperatur
get Ruecklauf cmd {"r -m 10 status01 temp1.1\n"}
get Ruecklauf expect "\d+\.\d+\n\n"
get Ruecklauf postproc { sprintf("%5.1f",$_) }
#
auslesen.
Irgendwie geht das seit ein paar Tagen nicht mehr (nach Raspi-Reboot) und in der 15.700.csv finde ich auch keinen passenden Wert.

Hast Du eine Idee / Vorschlag?

was kommt denn bei dem ausgelösten Kommando

Code Auswählen Erweitern

r -m 10 status01 temp1.0?

[DerFranke]

was kommt denn bei dem ausgelösten Kommando

Code Auswählen Erweitern

r -m 10 status01 temp1.0?

Can't read ./FHEM/-m 10 status01 temp1.0.pm

[DerFranke]

Hi John,
hast Du keinen Tip mehr?
Es ist wirklich schade, wenn der Adapter von heute auf morgen nicht mehr die gewünschten Daten auslesen läßt.