Damit heißt es aber für mich: gehe zurück auf Anfang 😭😭.
Wenn sich kein eBus-Profi bei mir meldet, dann komme ich wohl nicht weiter. Ich habe noch mal Weishaupt angeschrieben, aber bin da nicht so optimistisch. Die hatten mal ein Kommunikations-Modul, das gibt es aber nicht mehr ....

Alles geht ohne Löten und Programmierkenntnisse. Der Chip ist per Weboberfläche erreichbar, damit kann man Heizungswerte auslesen und ändern: Beispiel

Über die Weboberfläche kann man direkt Parameter definieren, die per MQTT versenden werden sollen.

Ich visualisiere die Daten in Grafana:

Alle Informationen gibt es hier: https://docs.bsb-lan.de/de/index.html

Habe mal einen ganz schnellen Blick auf das BSB-Lan-Projekt geworfen. Mit solcher Hardware hatte ich bisher noch keinen Kontakt. Und beim 1. Durchsehen bin ich auch noch nicht ganz schlau draus geworden :( . Kannst Du mir da ein wenig unter die Arme greifen und mir mal sagen, was Du an Hardwarekomponenten eingesetzt hast? Werde mich auf jeden Fall weiter damit beschäftigen, denn die Daten aus der Heizung will ich auch haben :) .

Danke für die Info 👍.

WRS-EM

Ich habe 2 WRS-EM in meiner Anlage installiert.

eBUS signal: no signal

Ich glaube aber mittlerweile, dass meine Weishaupt WTU gar keinen "echten eBus" hat.

Sieht so aus. Solange hinter "eBUS signal" nicht "acquired" steht, erübrigt sich alles weitere.

EDIT: Du benötigst ein WRS-EM oder WCM-EM Erweiterungsmodul.

ebusd device string: "192.168.178.39:9999" or "mdns:7c2c6761e8fc" since ebusd 24.1
ebusd connected: yes (inactive)
eBUS signal: no signal

Das ist alles auf meinem RPi im ebusd eingetragen, ich erhalte von dort Statusmeldungen über MQTT:
ebusd2/global/version = ebusd 25.1.25.1-8-g83e25278
ebusd2/global/running = true
ebusd2/global/signal = false

Die grüne LED des Shield blinkt auch regelmäßig.

Ich glaube aber mittlerweile, dass meine Weishaupt WTU gar keinen "echten eBus" hat. Ich habe heute das BSB-Lan Projekt gefunden. Das unterstützt anscheinend den alten Weishaupt LPB-Bus: LPB/M.
Ich versuche mal den BSB-Lan adapter zu erhalten.

Die grünen LED's blinken zwar, aber das Webinterface kann sich offenbar nicht mit dem Ebus verbinden.

Das ergibt noch keinen Sinn, die Weboberfläche verbindet sich nicht bis ebus. Kommst du auf die Weboberfläche des Shields? Wenn ja, was steht unter hinter "eBUS signal" und "ebusd device string"? Ist dieser String beim ebusd Dienst eingetragen?

Den ersten Adapter habe ich mittlerweile erfolgreich mit meiner Weishaupt WRSOL 2.1. Solarthermieregelung verbunden, hier kann ich Prozesswerte auslesen und es funktionrt einwandfrei, aber an der WTU scheitere ich.

Vielleicht ist die Anlage einfach zu alt...

Falls jemand erfolgreich eine Weishaupt WTU mit ebus verbunden hat, lasst es mich bitte wissen.

Nach meinem Verständnis kommen die ebus-Signale nicht oder nicht richtig im ebusd an.

adminuser@ebusd:~$ ebusctl --port=8888 --server=192.168.50.xxx i
version: ebusd 23.1.23.1-8-g9c0af7b9
update check: version 23.3 available
device: udp:192.168.50.244:8888
access: *
signal: no signal
reconnects: 0
masters: 1
messages: 11
conditional: 0
poll: 0
update: 4
address 31: master #8, ebusd
address 36: slave #8, ebusd, scanning

Die Zeile signal: no signal sagt aus meiner Sicht alles aus: da wird nichts erkannt 🤔.

Die LED's auf dem Adapter haben folgenden Status:
gelb: leuchtet permanent -> Stromversorgung ok
blau: blinkt im Abstand von ca. 3s kurz auf -> Verbindung Ethernet ok
grün: blinkt mit geringer Leuchtkraft sehr schnell, in unregelmäßigen Abständen blinkt sie hell auf; das ist ebus-read, es kommt also etwas an ...
rot: ist aus -> ebus write

Als Verbindung zwischen der Heizung und dem Adapter habe ich eine 4-adrige Telefonleitung verwendet, die parallel an den Klemmen der Heizung für den ebus angeschlossen ist (ich habe aktuell keinen passenden Stecker für die Buchse in der Heizung). Nach meinem bisherigen Verständnis vom ebus kann man das so anschließen, oder nicht? Ich habe je 2 Leitungen zusammengefasst zu einer Leitung (und ja, ich habe auf beiden Seiten die gleichen Adern gepaart 😉).

Den Vorschlag von @wendy2702 mit tcdump habe ich noch nicht umgesetzt, da im Netzwerk ja erst gar nichts ankommt.

Welche Möglichkeiten habe ich, die ebus-Verbindung weiter zu prüfen / testen um dem Fehler auf die Spur zu kommen?

Ist das ein USB Stick? Sorry sollte das schon wo erwähnt sein.

Wenn die Kommunikation über TCP/UDP also Netzwerk läuft würde sich noch ein TCPdump auf dem Interface anbieten mit anschließender Analyse in Wireshark

nmap -sU -p 8888-8889 192.168.50.244
Starting Nmap 7.80 ( https://nmap.org ) at 2023-02-05 10:41 UTC
Nmap scan report for 192.168.50.244
Host is up (0.00015s latency).

PORT     STATE  SERVICE
8888/udp closed ddi-udp-1
8889/udp closed ddi-udp-2
MAC Address: AE:B0:53:26:13:60 (Unknown)

Bei beiden Ports steht closed. Verstehe ich das falsch oder sind die Ports wirklich geschlossen und ich bekomme deshalb kein Signal?
Im log tauchen aber keine Fehler auf:

2023-02-05 10:41:00.559 [bus notice] re-opened udp:192.168.50.244:8888
2023-02-05 10:42:51.689 [main notice] update check: revision 23.1 available

@lueghi sagte in Probleme mit Installation ebusd:

EBUSD_OPTS="--scanconfig=full --accesslevel=* -d udp:192.168.50.244:8888 --httpport=8889 -l /var/log/ebusd.log --configpath=/etc/ebusd"

Ich habe eine USB version ...

Aber warum udp: , in der Beschreibung steht ens: :

Die ebusd device Konfiguration lautet z.B. -d ens:192.168.178.2:9999, wobei 192.168.178.2 durch die richtige IP-Adresse ersetzt werden muss.

Das hatte ich auch schon versucht, dann erhalte ich folgende Meldung:

device: 192.168.50.244:8888, enhanced, invalid

Da ist dann das Device nicht ok.
Wenn ich ens:udp:192... mache erhalte ich folgende Ausgabe von ebusctl i:

version: ebusd 23.1.23.1-8-g9c0af7b9
device: udp:192.168.50.244:8888, enhanced
access: *
signal: no signal
reconnects: 0
masters: 1
messages: 0
conditional: 0
poll: 0
update: 0
address 31: master #8, ebusd
address 36: slave #8, ebusd

Das no signal bleibt leider .....

EBUSD_OPTS="--scanconfig=full --accesslevel=* -d udp:192.168.50.244:8888 --httpport=8889 -l /var/log/ebusd.log --configpath=/etc/ebusd"

Ich habe eine USB version ...

Aber warum udp: , in der Beschreibung steht ens: :

Die ebusd device Konfiguration lautet z.B. -d ens:192.168.178.2:9999, wobei 192.168.178.2 durch die richtige IP-Adresse ersetzt werden muss.

Aber ich habe das gleiche Ergebnis: no signal

Irgendwelche weiteren Ideen ....

unpriviligierten LCX

Stell auf privilegiert um.

Container auf proxmox

device: udp:192.168.50.244:8888

Kenne proxmox nicht , aber muß man nicht den Port durchgereicht !? ( Nicht die Firewall gemeint )