Adapter: ebus
-
Hallo in die Runde der „EBUS Adapter Nutzer“.
Wegen des Hinweis im IOBroker Prozokoll wollte ich heute mein ebusd auf 24.1 updaten. Mein Raspi 4 ist wie folgt konfiguriert: 64 Bit Bookworm
Ergo habe ich folgendes ebusd Paket versucht einzuspielen:
Warum habe ich die Fehlermeldung bekommen? Was mache ich falsch? -
Da antworte ich mir mal selber :-).
Man muss natürlich die richtigen Adressen verwenden, sonst wird das natürlich nichts. Hier die Befehle zum Installieren der aktuellen Version 24.1 auf einem RASPI PI mit 64Bit Bookworm.
Ohne MQTT:
-
wget https://github.com/john30/ebusd/releases/download/24.1/ebusd-24.1_arm64-bookworm.deb
-
sudo dpkg -i ebusd-24.1_arm64-bookworm.deb
Mit MQTT:
-
wget https://github.com/john30/ebusd/releases/download/24.1/ebusd-24.1_arm64-bookworm_mqtt1.deb
-
sudo dpkg -i ebusd-24.1_arm64-bookworm_mqtt1.deb
-
-
Verständnisfrage: wie häufig holt der EBUS-Adapter welche Werte vom ebusd Daimion ab? Ich frage, weil - wie im Foto zu sehen - Werte nur in dem Moment dokumentiert wurden, als ich im Terminal diese über ebusctl r …. manuell abgefragt habe. Das hat der EBUS-Adapter im IOBroker wohl mitbekommen, Datenpunkte erzeugt, Werte mit Zeitstempel dokumentiert.
Ist es so, dass ich diese Werte über ein im IOBRoker definiertes Skript zB minütlich abholen muss?
Wenn das so für den EBUS-Adapter sein sollte, werden die Werte von EBUSD mit MQTT regelmäßig an den IOBroker gesendet? Oder muss da auch ein Skript definiert werden?
-
@leonundjulie
Also technisch gesehen ist es so, dass der ebus-Adapter alle Werte so abholt, wie sie beim ebusd vorliegen. Nicht mehr und nicht weniger.
Wenn Du also ebusd -r ausführst, dann liegt ein neuer Wert vor, den der Adapter dann abholt.Wenn Du Werte zyklisch abrufen willst, dann kann das auf verschiedene Weise geschehen. Ein gängiger Weg ist, dass der Adapter ebusd anregt, bestimmte Werte abzurufen, die der Adapter dann bei ebusd abfragt. Dafür gibt es in den Instanz-Einstellungen des ebus-Adapters eine Seite, wo man die entsprechenden Datenpunkte eintragen kann. Auch das Abfrageintervall lässt sich dort einstellen.
Je nachdem, wieviele Daten du abfragst, könnte ein Intervall von einer Minute viel zu knapp sein. Das musst du aber selbst herausfinden.Ich hoffe, das war einigermaßen verständlich, sonst kann @Rene_HM das vielleicht auch noch etwas fachlich korrekter erklären.
-
@hiltex Danke für den Ansatz. Ich habe nochmals den gesammten Beitrag mit seinem über 600 Posts durchgelesen, aber nichts gefunden wie man das Dir angeregte konkret umsetzne muss.
Ich habe zunächst einmal die Objekte beobachtet und sehe, dass der Adapter grundsätzlich arbeitet - meine Basis Konfiguruation korrekt ist. Alle 5 Minuten - so wie eingestellt -
Ich bekomme also kontunierlich neue Werte für die KESSELTEMPERATUR. Aber die VORLAUFTEMPERATUR SOLL/IST ändern sich seit Tagen nicht.@rene_hm Gibt es eine Beschreibung wie ich mein Beispiel, also die VORLAUFTEMPERATUR_SOLL auf dieser Seite der ebus-Instanz eintragen muss?
-
gibt einfach bei > Gerät, in dem nach Parametern gesucht wird < dein/deine Geräte wie sie ebusd liefert, also z.B HMU00 oder ctlv2 ein und klick auf "Paramter suchen". So wie hier:
Wenn du alles richtig gemacht hast dann trägt der Adapter alle gefunden Parameter von alleine ein.
Dann musst du noch in der ersten Spalte bei 'aktiv' das Kästchen entweder aktivieren oder deaktivieren für die Werte die du haben willst oder nicht.
-
@icebear Danke für den Input, den ich mal ganz stumpf umgesetzt habe. Wobei ich schon gern wüsste wofür ctlv2 und HMU00 stehen.
Fakt ist, egal ob cih das eine oder das andere oder - wie im Screenshot zu sehen - beides eingebe, ich bekomme als Feedbak nach betätigen des Buttons "Paramter suchen" nur ein OK (unten links im Screenshot)
Und nun?
-
Achso, ich dachte das wäre klar.
Hier mal ein Screenshot von meinem Objekt Baum im ebus-Adapter:
Ich frag ja mit dem ebusd Adapter mit den xx.csv Dateien mein Vaillant Wärmepumpe Arotherm und den Unitower ab. Dort heißen die Geräte halt HMU = WP Ausseneinheit aroTHERM 75/6 , ctlv2 = uniTower Innengerät vr_71 = Steuereinheit.
-
@icebear ok. Ich habe eine Gastherme von WOLF vom Typ CBG-K-20. Aber nach langen suchen vor Monaten habe ich entsprechende CSV-Files am Start.. Mit Deinem Tip habe ich den ebus-Adapter ergänzt:
Und im Ergebnis sehe ich jetzt folgendes:
Ich bekomme also meine Werte in den IOBroker ... HEUREKA.
Auf zum letzten Puzzleteil: was muss getan werden, damit auch diese Werte zB alle 5 Minuten eingelsen werden so wie die in der Kategorie BROADKAST?
Nachbrenner: das sagt das Protokoll:
es wird einmal gelesen, dann erfolgen keine Updates mehr, auch nicht für BROADCAST, obwohl ich es erwate, dass alle 5 Minuten gelesen wird:
-
Hallo,
ich setzte den ebus Adapter in der Version 3.38 auf meinem iobroker ein.
Mir fällt auf, das folgende Datenpunkte mit einer Warnmeldung im Protokoll stehen.
ebus.0 2025-01-19 12:27:30.399 warn no update since 17.1.2025, 20:48:16 v32.messages.HeatRecovery.lastup
ebus.0 2025-01-19 12:27:30.377 warn no update since 17.1.2025, 20:48:15 v32.messages.FrostProtectionElement.lastup
ebus.0 2025-01-19 12:27:30.203 warn no update since 17.1.2025, 20:50:02 v32.messages.BypassMaxDiffTemp.lastup
ebus.0 2025-01-19 12:27:27.161 warn no update since 16.1.2025, 09:52:16 700.messages.HwcStorageTempTop.lastup
ebus.0 2025-01-19 12:27:27.131 warn no update since 16.1.2025, 17:53:20 700.messages.HwcStorageTempBottom.lastup
ebus.0 2025-01-19 12:27:27.070 warn no update since 16.1.2025, 09:52:17 700.messages.HcStorageTempTop.lastup
ebus.0 2025-01-19 12:27:27.039 warn no update since 16.1.2025, 09:52:17 700.messages.HcStorageTempBottom.lastup
ebus.0 2025-01-19 12:27:26.626 warn no update since 18.1.2025, 20:03:46 700.messages.AdaptHeatCurve.lastupDiese Datenpunkte hatte ich zum Testen mal konfiguriert, aber wieder entfernt.
Ich habe in der Instanz ebus.0 die Konfiguration gespeichert, den Adapter deinstalliert, geprüft ob alle Objekte entfernt wurden
und anschließend den Adapter erneut installiert.
Zunächst habe ich die Konfiguration wieder importiert, jedoch blieben die Warnmeldungen im Protokoll erhalten.
Daher den Adapter noch mal deinstalliert und von Hand neu konfiguriert.
Das macht es leider auch nicht besser.
Die Warnmeldungen der entfernten Datenpunkte bleiben erhalten.Hat hier jemand eine Idee?
Gruß aus dem sonnigen OWL
Andreas -
@andreasw63 ich hatte - wie im Beitrag davor geschrieben - den gleichen Fehler. Bei mir liegt wahrscheinlich noch ein anderes Problem vor. Wichtig ist in dem Zusammenhang, die richtige TCP- Adresse zu verwenden … bei war 8890 eingetragen, richtig ist aber die typische Adresse 8888
Bei mir werden immer noch drei Werte als zu lange nicht geändert angezeigt, was aber daran liegt dass sie nicht abgefragt werden …. Daran arbeite ich gerade noch
-
@leonundjulie beantwortet das Thema “warum werde die Werte nicht gelesen” selber, damit auch andere den Weg zum Ziel finden.
Der Fehler “Werte werden nicht aktualisiert” hat seine Ursache darin, dass der IBroker Adapter EBUS von mir nicht richtig konfiguriert wurde.
Basis für die Einstellung ist die RICHTIGE Übernahme der Terminalauisgabe auf ebusctl f -F name,comment. Bei mir kommt da folgendes:
Die falschen Eintragungen im IO Adapter EBUS:
Die richtigen Eintragungen im IO Adapter EBUS:
Die Erkenntnis ist also die, das FEUERUNG das Gerät ist, aus dem die manuel abzufragenden Werte kommen … macht man es so, wird regelmäßig richtig Gelsen und ich habe die gewünschte Werte.
-
Hallo leonundjulie,
danke für deine Antworten.
Wenn ich es richtig sehe, wird der eine Port zum Lesen der Daten verwendet:
"HTTP Port zum Lesen von Daten" = 8889
"TCP (Telnet) Port Schreiben von Daten" = 8888Grundsätzlich kann ich die erforderlichen Datenpunkte auslesen.
Ich habe das Problem, das bei entfernte Datenpunkten der Hinweis im Protokoll
des iobroker steht, das die Aktualisierung schon einige Tage her ist.
Diese Datenpunkte sind in der Instanz des Adapters NICHT eingetragen.Gruß Andreas
-
@andreasw63 Danke für Deine Antwort. Ich werde gleich mal ausprobieren, ob ich den letzten Fehler, der im Protokoll ausgewiesen wird, so auch noch aus der Welt bekomme.
Denn in meine Konfiguration auf einem RASPI PI4 mit einem 64BIT BOOKWORM OS auf dem EBUSD und IOBroker installiert sind, funktioniert in puncto EBUS und EBUSD ansonsten alles
Der Fehler: bis auf zwei Werte bekomme ich alle Werte meiner WOLF Gastherme CGB (-k)-20 ohne Probleme ausgelesen.
Dieses Bild zeigt die beiden Datenpunkte, die nicht aktualisiert werden.
Das zweite Bild zeigt, dass SIGNOFLIFE alle 5 Minuten (das ist das bei mir eingestellte Abrufintervall) als fehlerhaft dokumentiert wird.
-
Hallo leonundjulie,
ist der Wert "signofile" in deiner ebus Instanz eingetragen?
Bei meiner Installation ist es so, das im Logfile nur Werte "angemerkt" werden, die mal eingetragen waren aber mittlerweile entfernt wurden !!!!
Gruß Andreas
-
@andreasw63 , ja der Wert ist eingetragen.
Den Gedanken, dass SIGNOFLIFE von vorherigen „übrig geblieben“ sei, hatte ich auch und den Datenpunkt gelöscht …. Ich weiß nicht wie lange es dauerte, aber nach einer Zeit x war er und somit auch die Fehlermeldungen wieder da.
Also habe ich ihn jetzt nochmals gelöscht -> beim nächsten Zyklus war er wieder da.
Hat noch jemand eine Idee?
-
@leonundjulie
Das Verhalten ist bei meiner Installation genau so.
Ich habe den Entwickler des Adapters auf Github gefragt:
https://github.com/rg-engineering/ioBroker.ebus/issues/391Ich bin auf die Antwort gespannt.
open warn no update since #391
-
@andreasw63
Nachdem die Parameter aus der Instanz-Konfiguration gelöscht wurden, muss auch der ebusd neu gestartet werden, sonst werden die Datenpunkte wieder angelegt. -
@marc-berg …. Auch das hilft nicht. Ich habe EBUSD für 10 Sekunden ausgeschaltet, zwischenzeitlich den DP SIGNOFLIFE gelöscht - Anmerkung: in der Instanz EBUS ist von mir nie ein SIGNOFLIFE definiert worden. Fazit: beim nächsten Abrufzyklus waren der DP und die Fehlermeldung wieder da.
-
@leonundjulie sagte in Adapter: ebus:
Anmerkung: in der Instanz EBUS ist von mir nie ein SIGNOFLIFE definiert worden
Hier: https://forum.iobroker.net/post/1241062
hast du es noch anders geschrieben.
Wie dem auch sei, dein Fall und der von @AndreasW63 scheint unterschiedlich gelagert zu sein. Den Fehler bei @AndreasW63 konnte ich so 1:1 nachstellen.
