Adapter: ebus

[Hasont]

@agrippinenser sagte in Adapter: ebus:

@hasont

also ich beschäftige mich auch erst kurz mit EBus, ich habe das so verstanden: nach Neustart des Services initialisiert sich das System poe a poe durch parsen von Nachrichten und bindet passende Konfigurationsdateien ein.
Das dauert ein Weilchen und etwas Geduld ist gefragt.

Mehrfachstart prüfen vielleicht:
pi@rpiEBus:~ $ top | grep ebusd
3998 root 20 0 316188 10292 6176 S 1,0 1,1 0:01.84 ebusd
3998 root 20 0 316188 10292 6176 S 0,7 1,1 0:01.86 ebusd
3998 root 20 0 316188 10292 6176 S 0,7 1,1 0:01.88 ebusd
3998 root 20 0 316188 10292 6176 S 1,0 1,1 0:01.91 ebusd
3998 root 20 0 316188 10292 6176 S 1,0 1,1 0:01.94 ebusd

Danke für die schnelle Hilfe. Hab den Befehl mal ausprobiert und Raspie neu gestartet.
Ergebnis hier als Code:

Hier läuft noch alles gut
pi@raspberrypi:~ $ top | grep ebusd
 1841 root      20   0   53356   6520   5208 S   0,3   0,2   3:22.17 ebusd
 1841 root      20   0   53356   6520   5208 S   0,3   0,2   3:22.18 ebusd
 1841 root      20   0   53356   6520   5208 S   0,3   0,2   3:22.19 ebusd
 
Ab hier dann Rasperie Reboot und es kommen die bereits genannten Fehler!
Ausgabe im IoBroker log: "2024-02-20 11:50:00.054	warn	instance system.adapter.ebus.0 already running with pid 1163"
pi@raspberrypi:~ $ top | grep ebusd
  424 root      20   0   34800   4992   4372 S   0,3   0,1   0:00.48 ebusd
  424 root      20   0   34800   4992   4372 S   0,3   0,1   0:00.49 ebusd
  424 root      20   0   34800   4992   4372 S   0,3   0,1   0:00.50 ebusd
  
Ab hier dann EBUS stop und start und die Fehler sind weg das 424 hat sich in 1304 geändert!!
pi@raspberrypi:~ $ /etc/init.d/ebusd stop
Stopping ebusd (via systemctl): ebusd.service==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ===
Legitimierung ist zum Stoppen von »ebusd.service« notwendig.
Authenticating as: ,,, (pi)
Password:
==== AUTHENTICATION COMPLETE ===
pi@raspberrypi:~ $ /etc/init.d/ebusd start
Starting ebusd (via systemctl): ebusd.service==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ===
Legitimierung ist zum Starten von »ebusd.service« notwendig.
Authenticating as: ,,, (pi)
Password:
==== AUTHENTICATION COMPLETE ===
.pi@raspberrypi:~ $ top | grep ebusd
 1304 root      20   0   34916   4232   3760 S   0,7   0,1   0:00.03 ebusd
 1304 root      20   0   34916   4232   3760 S   0,3   0,1   0:00.04 ebusd
 1304 root      20   0   34916   4232   3760 S   0,3   0,1   0:00.05 ebusd

Denke die 424 und 1304 ist sowas wie ne Prozess ID.
Ob der Prozess nun doppelt läuft kann ich nicht erkennen.
Ev. hat ja noch jemand ne andere Idee was das sein könnte. Ist jedesmal nachvollziehbar.
Nach Neustart vom Raspie kommt also immer der Fehler und nach Beenden und Starten vom EBUS
ist der Fehler weg.

LG Horst

[Agrippinenser]

@hasont aber du hast den Autostart schon "eingebaut" ?

4. Make the daemon autostart with 'systemctl enable ebusd'
sudo systemctl enable ebusd

[Hasont]

@agrippinenser sagte in Adapter: ebus:

@hasont aber du hast den Autostart schon "eingebaut" ?

4. Make the daemon autostart with 'systemctl enable ebusd'
sudo systemctl enable ebusd

Hab den Autostart nochmal eingegeben, bleibt aber dabei.
Fehler erst weg wenn eBus aus und eingeschaltet wird.
Hoffentlich starte ich den jetzt nicht dreimal;-)

[Agrippinenser]

@hasont

nun - ich würde deinerseits kurz die SD inkl. ebusd neu aufsetzten - dann wird es laufen. Zeitaufwand gering

[leonundjulie]

Hallo. Ich musste meinen RASPI PI4 neu aufsetzen.

Zum Thema ebusd lief schon mal alles unter BULLSEYE. Im Rahmen der Neuinstallation bin ich auf BOOKWORM umgestiegen. Ob das eine mit dem anderen zu tun hat ... who knows. Fakt ist, dass ich Problem mit meiner ebusd Konfiguration habe. letztlich ist es so, dass ich mit dem Thema befasse, weil ich aus meiner Gasheizing, Typ CG11 von WOLF die Werte auslesen will, um sie im iOBroker zu verwenden.

Nur warum bekomme ich es jetzt nicht wieder hin? Ich strauchle schon vor dem iOBroker.

Ich habe mal diverse Fotos gemacht, die meine Konstellation beschreiben sollen ... Bilder sagen mehr als tausend Worte:

Mein Konfigurationsstring

Und die CSV-Dateien liegen hier:

Folgende Antworten erhalte ich:

Ich glaube, dass es ein Problem mit meinem Konfigurationsstring gibt - oder warum sehe ich nach ebusctl i keine CSV informationen und weiter unter auch nichts von Kromschroeder & co (hatte ich in meiner alten Konfiguration unter BULLSEYE).

[MassiveAttack]

@leonundjulie
zugriffsrechte auf dein verzeichnis /etc/ebusd/ sind gegeben?
lass mal --configpath aus deiner config aus, und schau ob was automatisch geladen wird

[leonundjulie]

@massiveattack Linux für Anfänger: wie stelle ich fest, welche Zugriffsrechte gegeben sind? Welche müssen es sein? Wie ändere ich sie?

Ok, wie man feststellt welche Rechte gegeben sind, ist mir klar. Aber welche müssen sein?

[leonundjulie]

@leonundjulie bei mir sieht es so aus (mal die Hirarchie runtergebrochen)

Die CSV-Dateien habe alle daie selben Rechte

Die Verzeichnisse ebusd und die darunter liegenden Verzeichnisse WOLF und VAILANT haben die selben Rechte, nur KROMSCHROEDER sieht leicht anders aus

[MassiveAttack]

@leonundjulie

versuch mal "chmod 777 -R" für den ordner kromschroeder
ansonsten lass die config einfach weg, wird ohnehin online geladen

mit dem user root solltest du nichts machen, vor allem wenn du nicht sattelfest bist

[Kanumouse]

Seit gestern funktioniert der Adapter plötzlich nicht mehr bzw. kann die Daten vom ebusd nicht meht lesen.

Beim Befehl "ebusctl info" ist noch alles in Ordnung.

Wenn ich die Daten direkt über die Adresse "http://192.168.xxx.xx:8889/data" aufrufe kommt folgender Fehler: SyntaxError: "JSON.parse: bad control character in string literal at line 2834 column 19 of the JSON data"

Kann ir Jemand sagen, wo die Ursache liegen könnte?

[AleXburnA]

Hier ebenfalls das Gleiche. Der Adapter funktioniert seit gestern schlagartig nicht mehr.
Bei mir sind die Daten vom ebusd (via 192.168.xxx.xxx:8889/data) allerdings aktuell und sie funktionieren.

Ich habe sowohl meinen ebusd-Raspi neu gestartet, als auch meinen ioBroker Container. Wenn ich den ebus-Adapter im iobroker auf DEBUG stelle, sehe ich auch dort die aktuellen Daten - aber die Objekte im iobroker werden eben nicht mehr aktualisiert.

Es scheint als wären wir nicht allein: https://github.com/rg-engineering/ioBroker.ebus/issues/86
Den letzten Beiträgen zufolge besteht bei ihnen das gleiche Problem seit 10.07.24.

Standarduser created this issue in rg-engineering/ioBroker.ebus

closed Adapter speichert keine Daten mehr #86

[icebear]

@alexburna

Das Problem scheint aber nicht unbedingt am Adapter zu liegen.
Seit Mittwoch hab ich in der myVaillant App auch keine Energiewerte usw mehr.
Heizung ist zwar aus aber WW zeigt in der App auch nichts an.

Ich hab gestern Abend mal meinen raspi mit ebusd Adapter neu gestartet, danach waren im ebus Adapter die aktuellen Werte drin. Heute Morgen hab ich dann nochmal geschaut, aber es sind immer noch die Werte von gestern Abend.

Grad nochmal in die App geschaut, jetzt sind die Werte für WW von gestern da, aber für heute steht wieder 'Verbrauchsdaten werden erhoben'

Edit: Hab grad auch nochmal geschaut, unter http://192.168.178.49:8889/data seh ich auch die aktuellen Daten, scheint doch ein Problem vom Adapter zu sein

[Kanumouse]

Ok, dann bin ich wenigstens nicht allein davon betroffen und es scheint ei grundsätzliches Problem zu sein - hilft uns alledings auch nicht weiter.
Muss erst einmal weiter suchen, wo das Problem liegen könnte.

[Kanumouse]

@alexburna
Im DEBUG-Modus des Adapters sehe ich auch alle Werte einlaufen.

[Lenny.CB]

@alexburna sagte in Adapter: ebus:

Hier ebenfalls das Gleiche. Der Adapter funktioniert seit gestern schlagartig nicht mehr.
Bei mir sind die Daten vom ebusd (via 192.168.xxx.xxx:8889/data) allerdings aktuell und sie funktionieren.

Ich habe sowohl meinen ebusd-Raspi neu gestartet, als auch meinen ioBroker Container. Wenn ich den ebus-Adapter im iobroker auf DEBUG stelle, sehe ich auch dort die aktuellen Daten - aber die Objekte im iobroker werden eben nicht mehr aktualisiert.

Es scheint als wären wir nicht allein: https://github.com/rg-engineering/ioBroker.ebus/issues/86
Den letzten Beiträgen zufolge besteht bei ihnen das gleiche Problem seit 10.07.24.

Ich hänge mich dran. Auch bei mir laufen keine Werte unter den Objekten ein.
Debug und via 192.168.xxx.xxx:8889/data alle i.O.

[Rene_HM]

@lenny-cb @AleXburnA @Kanumouse @icebaer
Hallo zusammen, ich sehe das Problem hier bei mir auch. Seit 10.7.2024 im 11:56 Uhr werden keine Daten mehr übernommen. Ich schaue mir das an...
Habt ihr evtl. ein anderes update (js-controller, admin, ...) gemacht?

[Lenny.CB]

@rene_hm sagte in Adapter: ebus:

@lenny-cb @AleXburnA @Kanumouse @icebaer
Hallo zusammen, ich sehe das Problem hier bei mir auch. Seit 10.7.2024 im 11:56 Uhr werden keine Daten mehr übernommen. Ich schaue mir das an...
Habt ihr evtl. ein anderes update (js-controller, admin, ...) gemacht?

jupp, beides js-controller und Admin. Bei mir waren aber einige Versionen dazwischen, da mein letztes Update 2-3- Monate zurück lang. (ich weiß, bin schlampig )
Bei mir war gestern gegen 21.30 Uhr Schluß. Das Update hatte ich auch erst danach gemacht.

Ein wechsel auf eine frühere eBus-Adapter-Version (bis 3.2.0 probiert) brachte keinen Erfolg.
Vlt. wegen den Update von Admin und js-controller???

[mameier1234]

@lenny-cb Bei mir kamen Daten bis gestern .. Da habe ich nur den Admin von 7.09 auf 7.12 aktualisiert..

Jetzt gerade Downgrade durchgeführt.. keine Änderung.

Der Ebus Adapter sagt im Log: ich habe die Daten.. er speichert aber nicht in den Datenpunkten.

[AleXburnA]

@rene_hm DANKE fürs Prüfen!
Ich habe die letzten Tage keinerlei Updates eingespielt, was auf einen Zusammenhang mit dem eBus Adapter deuten könnte. Erst nachdem er keine Daten mehr lieferte, habe ich admin auf die aktuelle Version v6.17.14 gehoben.

JS-Controller ist bei mir seit einigen Wochen auf 5.0.19, Node.JS auf v18.20.3.

Ich denke das Node.JS Update (im Rahmen des buanet Docker Container Upgrades auf 9.1.2) war das letzte, was ich gemacht hatte. Das ist erst einige Tage her... evtl. hab ich das diesen Montag gemacht, weiß gar nicht mehr sicher. Auf jeden Fall wars nicht gestern. Aber auch das war nur ein Minor-Upgrade, ich war davor schon auf Node.JS 18

[Lenny.CB]

Bin aktuell auf folgenden Versionen:
eBus --> 3.2.3
Admin --> 7.0.12
js-controller --> 6.0.6

folgende Fehlermeldung bekomme ich.

ebus.0
2024-07-11 12:08:50.743	error	exception in ebusd_ReceiveData [Error [ERR_REQUIRE_ESM]: require() of ES Module /opt/iobroker/node_modules/iobroker.ebus/node_modules/flat/index.js from /opt/iobroker/node_modules/iobroker.ebus/main.js not supported. Instead change the require of index.js in /opt/iobroker/node_modules/iobroker.ebus/main.js to a dynamic import() which is available in all CommonJS modules.]

ebus.0
2024-07-11 12:07:50.731	error	exception in ebusd_ReceiveData [Error [ERR_REQUIRE_ESM]: require() of ES Module /opt/iobroker/node_modules/iobroker.ebus/node_modules/flat/index.js from /opt/iobroker/node_modules/iobroker.ebus/main.js not supported. Instead change the require of index.js in /opt/iobroker/node_modules/iobroker.ebus/main.js to a dynamic import() which is available in all CommonJS modules.]

ebus.0
2024-07-11 12:06:50.790	error	exception in ebusd_ReceiveData [Error [ERR_REQUIRE_ESM]: require() of ES Module /opt/iobroker/node_modules/iobroker.ebus/node_modules/flat/index.js from /opt/iobroker/node_modules/iobroker.ebus/main.js not supported. Instead change the require of index.js in /opt/iobroker/node_modules/iobroker.ebus/main.js to a dynamic import() which is available in all CommonJS modules.]

ebus.0
2024-07-11 12:05:50.561	error	exception in ebusd_ReceiveData [Error [ERR_REQUIRE_ESM]: require() of ES Module /opt/iobroker/node_modules/iobroker.ebus/node_modules/flat/index.js from /opt/iobroker/node_modules/iobroker.ebus/main.js not supported. Instead change the require of index.js in /opt/iobroker/node_modules/iobroker.ebus/main.js to a dynamic import() which is available in all CommonJS modules.]

ebus.0
2024-07-11 12:04:50.461	error	exception in ebusd_ReceiveData [Error [ERR_REQUIRE_ESM]: require() of ES Module /opt/iobroker/node_modules/iobroker.ebus/node_modules/flat/index.js from /opt/iobroker/node_modules/iobroker.ebus/main.js not supported. Instead change the require of index.js in /opt/iobroker/node_modules/iobroker.ebus/main.js to a dynamic import() which is available in all CommonJS modules.]

ebus.0
2024-07-11 12:03:50.449	error	exception in ebusd_ReceiveData [Error [ERR_REQUIRE_ESM]: require() of ES Module /opt/iobroker/node_modules/iobroker.ebus/node_modules/flat/index.js from /opt/iobroker/node_modules/iobroker.ebus/main.js not supported. Instead change the require of index.js in /opt/iobroker/node_modules/iobroker.ebus/main.js to a dynamic import() which is available in all CommonJS modules.]

ebus.0
2024-07-11 12:02:50.608	error	exception in ebusd_ReceiveData [Error [ERR_REQUIRE_ESM]: require() of ES Module /opt/iobroker/node_modules/iobroker.ebus/node_modules/flat/index.js from /opt/iobroker/node_modules/iobroker.ebus/main.js not supported. Instead change the require of index.js in /opt/iobroker/node_modules/iobroker.ebus/main.js to a dynamic import() which is available in all CommonJS modules.]

vielleicht hilft es was.