Hallo,
Ich versuche, die externe Integration ebusd von @Will_71 (ghcr.io/william-de71/gladys-ebusd:0.1.0) zu nutzen, und der Test schlägt fehl, obwohl alles auf meiner Seite korrekt zu sein scheint. Können Sie mir sagen, ob das Problem von der Integration kommt?
Umgebung
- Gladys Assistant 5.3.2 auf Gladys OS (Raspberry Pi 5, Raspberry Pi OS Trixie 64-Bit, mit Raspberry Pi Imager geflasht). Container:
gladys,watchtower,ebusd,gladys-ext-william-de71-gladys-ebusd. - ebusd
john30/ebusd26.1.26.1 in Docker auf demselben Pi (192.168.1.13):
docker run -d --name=ebusd --restart=unless-stopped -p 8888:8888 john30/ebusd --scanconfig -d ens:192.168.1.14:9999 - Adapter: eBUS Adapter Stick C6 (ESP32-C6), Firmware 20261109, per Wi-Fi (192.168.1.14), Protokoll Enhanced über TCP. Statusseite des Adapters: « ebusd connected: yes », « eBUS signal: no signal » (normal, siehe unten).
Adapter-Einstellungen (Enhanced Protocol, TCP):
- Heizkessel: Vaillant, noch nicht angeschlossen (ich bereite die Installation vor, bevor ich ihn anschließe). Das eBUS-Signal ist daher derzeit « no signal ».
Integrationseinstellungen
Adresse von ebusd: 192.168.1.13 (ohne http://), Port 8888, Benutzername und Passwort leer, « Änderungen zulassen » deaktiviert. Die Konfiguration wird ohne Probleme gespeichert.
Was ich beobachte
Der Test zeigt ebusd antwortet nicht auf 192.168.1.13:8888 (element not found) an, und das Badge bleibt auf « Getrennt »:
Einige Minuten zuvor erschien mit derselben Konfiguration eine andere Meldung: « ebusd antwortet, hört aber nichts auf dem eBUS: Überprüfen Sie den Adapter und seine Verkabelung ». Keine Fehler in docker logs gladys-ext-william-de71-gladys-ebusd (nur [gladys-sdk] connected to Gladys).
Was zeigt, dass ebusd erreichbar ist und funktioniert
docker exec ebusd ebusctl info:
version: ebusd 26.1.26.1
device: 192.168.1.14:9999, TCP, enhanced, firmware 1.1[6b09].1[6b09]
signal: no signal
reconnects: 0
masters: 1
messages: 11
address 31: master #8, ebusd
address 36: slave #8, ebusd
docker exec ebusd ebusctl find:
Broadcast Datetime = no data stored
Broadcast Error = no data stored
Broadcast Id = no data stored
Broadcast IdAnswer = no data stored
Broadcast Signoflife = no data stored
Memory Eeprom = no data stored
Memory Ram = no data stored
Ebusd antwortet korrekt und kennt nur seine 7 internen Nachrichten, ohne dass ein Vaillant-Gerät vorhanden ist, da der Heizkessel nicht angeschlossen ist.
nc -vz 192.168.1.13 8888vom Pi aus: erfolgreich.- Vom Innenraum des Integrationscontainers (
net.connectunter Node):172.30.0.1:8888OK und192.168.1.13:8888OK. - Ebusd läuft seit mehreren Stunden ohne Neuanmeldung.
Meine Hypothese
element not found scheint eine Antwort von ebusd auf einen Befehl zu sein, der auf ein nicht vorhandenes Element abzielt. Ich habe es manuell reproduziert:
docker exec ebusd ebusctl find -c bai
ERR: element not found
(bai ist der Schaltkreis des Vaillant-Kessels, der bei mir nicht vorhanden ist, da er nicht angeschlossen ist.) Allerdings funktioniert ein einfaches ebusctl find und gibt diesen Fehler nicht zurück. Die Integration behandelt diese Antwort möglicherweise als Ausfall („ebusd antwortet nicht“), obwohl ebusd sehr wohl antwortet und lediglich signalisiert, dass das Element noch nicht existiert.
Meine Fragen
- Erhält die Integration tatsächlich diese Antwort (
ERR: element not found, beispielsweise bei einer Schaltkreis-Suche wiebai)? In diesem Fall könnte sie dann als „kein Gerät gefunden“ statt als Ausfall behandelt werden, wenn der Bus leer ist? - Muss der Kessel angeschlossen und von ebusd erkannt werden, damit der Test erfolgreich ist?
- Gibt es eine Möglichkeit, detailliertere Logs im Container der Integration zu erhalten?
Ich kann weitere Logs oder Screenshots bereitstellen. Vielen Dank im Voraus!
jetzt funktioniert es.