UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[Lueghi]

Hallo iobroker-Freunde,

ich brauche heute mal jemanden, der mich beim ebus grundsätzlich an die Hand nimmt. Ich weiss, dass ist kein reines iobroker-Thema, aber ich habe gelesen, dass hier einige von euch auch mit dem ebus arbeiten und hoffe daher auf Hilfe ...

Warum will ich ebus:
ich möchte gerne Daten aus meiner Weishaupt-Anlage (WT-15, Heizung und Warmwasser) visualisieren.

Zuerst einige Informationen zu meiner Installation.

Hardware:

• ebus-Adapter V3.1 von john mit Netzwerkanschluss, IP 192.168.50.244
• Anschluss Weishaupt - ebus-Adapter: Telefonkabel, 4-adrig, nur 2 Adern genutzt

Software:

• Debian 11 in einer VM unpriviligierten LCX-Container auf proxmox, IP 192.168.50.249
• ebusd installiert mit Konfigurationsdateien von JOEK3r für Weishaupt-Heizung (https://github.com/J0EK3R/ebusd-configuration-weishaupt) im Verzeichnis /etc/ebusd/weishaupt
• EBUSD_OPTS="--scanconfig=full --accesslevel=* -d udp:192.168.50.244:8888 --httpport=8889 -l /var/log/ebusd.log --configpath=/etc/ebusd"

Habe mir die Informationen soweit zusammen gesucht. Bin mir aber nicht sicher, ob das alles so richtig ist. Ich bekomme nämlich keine Verbindung zum ebus/Heizung. Wenn ich den ebus-Adapter mit Strom versorge, dann leuchtet die blaue LED sehr hell (Bootloader-Modus ?) Nach einer kurzen Zeit blinkt die grüne LED sehr schnell, die blaue binkt hin und wieder auf. Netzwerk-LED's leuchten auch wie sie sollen, ping ist auch ok.

Ausgabe von ebusctl i:

root@ebusd:/home/adminuser# ebusctl i
version: ebusd 23.1.23.1-3-gaf614ae1
device: udp:192.168.50.244:8888
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

Für die Definition des device habe ich schon diverse Varianten ausprobiert, bei dieser Konfiguration habe ich zumindest kein "invalid" hinter dem Devicenamen. Und wenn ich das richtig verstanden habe, ist ja egal ob man die Adern am Adapter vertauscht hat oder nicht. Habe das ausprobiert, aber das Blinken der LED's ist identisch.

Die Netzwerkadresse wird per DHCP vergeben und braucht daher nach meinem Verständnis nicht per ebuspicloader definiert zu werden.

Und hier komme ich nicht weiter. Die Zeile signal: no signal sagt ja eigentlich alles. Ist da in der Konfiguration etwas falsch oder was kann ich tun um dem Fehler auf die Spur zu kommen bzw. was braucht ihr noch an Infos um mir helfen zu können?

Gruß Stefan
[edit 2023-01-16] geändert auf LCX-Container [/edit]

[Lueghi]

kleine Ergänzung:

...

• Debian 11 in einer VM unpriviligierten LCX-Container auf proxmox, IP 192.168.50.249
  ...

Beschreibung korrigiert;
in der Firewall sind die Ports 8888-8890 auch freigeschaltet.

[Thomas Braun]

@lueghi

Tu dir einen Gefallen und leg dir einen Standarduser an und eimer da nicht als root durch den Container.

[Lueghi]

@thomas-braun
Danke für den Hinweis.
Den gibt es sogar schon und den nutze ich im normalerweise auch .... 🙂.

[Thomas Braun]

@lueghi

Und warum dann oben nicht?
Es gibt keinen Grund direkt als root zu agieren. Gewöhn dir den Mist ab.

[Lueghi]

Kann mir denn keiner Tipps geben, was ich tun kann um dem Problem auf die Spur zu kommen?

[Glasfaser]

@lueghi sagte in Probleme mit Installation ebusd:

Container auf proxmox

device: udp:192.168.50.244:8888

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

[Thomas Braun]

@lueghi sagte in Probleme mit Installation ebusd:

unpriviligierten LCX

Stell auf privilegiert um.

[Lueghi]

@thomas-braun
Ich habe auf privilegiert umgestellt und mußte alles neu installieren. Ist das normal bei einer Umstellung?

Aber ich habe das gleiche Ergebnis: no signal :confused:

Irgendwelche weiteren Ideen ....

[Lueghi]

@glasfaser
soweit ich das bisher verstehe, braucht man da nichts durchreichen. Die anderen Container gehen ja auch ....

[Glasfaser]

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

[Lueghi]

@glasfaser sagte in Probleme mit Installation ebusd:

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

[Lueghi]

Habe noch ein wenig getestet. Ich glaube, ebusd hat keinen Zugriff auf die Ports auf dem Adapter:

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]

Kann mir wirklich keiner weiterhelfen 😟?

[wendy2702]

@lueghi du könntest mal schauen ob die Ports schon anderweitig belegt sind?

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

[Lueghi]

@wendy2702
Die Randbedingungen sind - aus meiner Sicht - alle im 1. Post aufgezeigt.
Der Tipp mit TCdump ist gut, das werde ich mal versuchen.

[Lueghi]

Ich muss dieses alte Thema noch mal aus der Versenkung holen und hoffe auf das geballte Wissen hier. Hatte nach großem Frust das Thema ebusd erst mal zur Seite gelegt ...

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?

[Freeride79]

@lueghi Ich versuche auch schon seit einiger Zeit, meine Weishaupt WTU per eBUS Adapter auszulesen.
Einmal mit dem eBUS Adapter Shield v5, und seit kurzem mit dem Nachfolgemodell, dem eBUS Adapter Shield C6. Es funktioniert leider nicht. Die grünen LED's blinken zwar, aber das Webinterface kann sich offenbar nicht mit dem Ebus verbinden.

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.

[Marc Berg]

@freeride79 sagte in Probleme mit Installation ebusd / Weishaupt:

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?

[Freeride79]

@marc-berg Sorry, ich war nicht präzise. Ich komme auf die Weboberfläche des Shields.
Folgende Meldungen sehe ich dort:

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.