NEWS
eCharts - kein sendTo nach Upgrade auf Node.js 22.x
-
Hi.
Warum soll ich den anderen Kernel verwenden, wenn doch wirklich alles fehlerfrei läuft, außer dem eChart, welches wohl eh nicht mehr richtig gepflegt wird.
Seit über einem Jahr werden falsche Datumsreihen in Bar-Charts gemeldet und es passiert wirlich garnix.
Zu den Kernel:
The Raspberry Pi 5 firmware defaults to loading kernel_2712.img because this image contains optimisations specific to Raspberry Pi 5 (e.g. 16K page-size). If this file is not present then the common 64-bit kernel (kernel8.img) will be loaded instead.
Google:
kernel_2712.img: Der Standard-64-Bit-Kernel für den Raspberry Pi 5 (BCM2712).
kernel8.img: Ein generischer 64-Bit-Kernel, der auf älteren Modellen genutzt wird und als Fallback fungiert.Sollte dann nicht mal der Adapter korrigiert werden? Und wieso lief es zuvor noch mit der 1.9.2?
Bin verwirrt... -
Hi.
Warum soll ich den anderen Kernel verwenden, wenn doch wirklich alles fehlerfrei läuft, außer dem eChart, welches wohl eh nicht mehr richtig gepflegt wird.
Seit über einem Jahr werden falsche Datumsreihen in Bar-Charts gemeldet und es passiert wirlich garnix.
Zu den Kernel:
The Raspberry Pi 5 firmware defaults to loading kernel_2712.img because this image contains optimisations specific to Raspberry Pi 5 (e.g. 16K page-size). If this file is not present then the common 64-bit kernel (kernel8.img) will be loaded instead.
Google:
kernel_2712.img: Der Standard-64-Bit-Kernel für den Raspberry Pi 5 (BCM2712).
kernel8.img: Ein generischer 64-Bit-Kernel, der auf älteren Modellen genutzt wird und als Fallback fungiert.Sollte dann nicht mal der Adapter korrigiert werden? Und wieso lief es zuvor noch mit der 1.9.2?
Bin verwirrt...@Erwin-Lindemann sagte in eCharts - kein sendTo nach Upgrade auf Node.js 22.x:
Warum soll ich den anderen Kernel verwenden,
Weil der statt mit 16k pagesize mit 4k gebaut wurde und libcairo2 damit (vermutlich) wieder läuft.
Und canvas dann gegen libcairo2 baut. Und dann auch echarts rennt. -
Hmm, das sehe ich aber eigentlich eher als Rückschritt an, nur weil der Adapter veraltete Sachen nutzt.
Ich glaub, da schmeiß ich lieber den Adapter raus und befasse mich endlich mit grafana... -
Hmm, das sehe ich aber eigentlich eher als Rückschritt an, nur weil der Adapter veraltete Sachen nutzt.
Ich glaub, da schmeiß ich lieber den Adapter raus und befasse mich endlich mit grafana...Der Adapter nutzt die vom Betriebssystem gestellten Libraries. Der kann für (vermutliche) Fehler beim Bau dieser Libs nichts.
Mach bei Raspberry OS ein Issue auf.Im übrigen verwendest du 'alte Sachen'. Installier da das aktuelle Release 'Trixie'.
Edit:
Siehe auch
https://github.com/ioBroker/ioBroker.echarts/issues/927 -
Trixie bringt keine signifikanten Neuerungen.
Und da ich einiges (außer ioBroker) installiert, konfiguriert und noch einiges Python Scripte laufen habe,
ist mal soeben ein Upgrade nicht mal g'schwind gemacht.
Und ja, ich würde komplett neu aufsetzen, da ein InPlace Upgrade immer noch nicht empfohlen wird. -
Trixie bringt keine signifikanten Neuerungen.
Und da ich einiges (außer ioBroker) installiert, konfiguriert und noch einiges Python Scripte laufen habe,
ist mal soeben ein Upgrade nicht mal g'schwind gemacht.
Und ja, ich würde komplett neu aufsetzen, da ein InPlace Upgrade immer noch nicht empfohlen wird.@Erwin-Lindemann sagte in eCharts - kein sendTo nach Upgrade auf Node.js 22.x:
Und ja, ich würde komplett neu aufsetzen, da ein InPlace Upgrade immer noch nicht empfohlen wird.
InPlace-Upgrade werden auch nie empfohlen werden. Deine Ausgangsbasis ist aber solide, sollte funktionieren.
Debian 12 wird im Sommer (wohl schon im Juni) das EndOfLife erreichen. Du solltest vorher den Absprung machen. -
Ich bin leider auch hier gelandet nachdem ich das Problem mit dem echarts Adapter jetzt seit August 25 habe. Inzwischen habe ich Meinen RasPi 5 mit Trixie komplett neu aufgesetzt und iobroker neu installiert. Auch hier ist nach wie vor das DLOPEN Problem beim echarts Adapter vorhanden. Kann es sein dass der Adapter gar nicht mehr gepflegt wird? Es gibt inzwischen dort ein neues Ticket (von vor 3 Wochen) weil das alte (von August 2025) inzwischen so weit unten ist das es wohl jemand übersehen hat. Von den Devs leider keine Antwort seit Monaten in den Tickets. Das "externe Render" Feature das mit 2.0.10 des Adapters angeblich wieder gefixt war geht inzwischen mit Trixie auch nicht mehr. Wie ich das verstehe ist das Problem nur dass der Adapter eine veraltete Version von libCanvas nutzt die bei Trixie jetzt inzwischen gefixt sein sollte mit der neusten Version. Kann das jemand bestätigen?
-
Ich bin leider auch hier gelandet nachdem ich das Problem mit dem echarts Adapter jetzt seit August 25 habe. Inzwischen habe ich Meinen RasPi 5 mit Trixie komplett neu aufgesetzt und iobroker neu installiert. Auch hier ist nach wie vor das DLOPEN Problem beim echarts Adapter vorhanden. Kann es sein dass der Adapter gar nicht mehr gepflegt wird? Es gibt inzwischen dort ein neues Ticket (von vor 3 Wochen) weil das alte (von August 2025) inzwischen so weit unten ist das es wohl jemand übersehen hat. Von den Devs leider keine Antwort seit Monaten in den Tickets. Das "externe Render" Feature das mit 2.0.10 des Adapters angeblich wieder gefixt war geht inzwischen mit Trixie auch nicht mehr. Wie ich das verstehe ist das Problem nur dass der Adapter eine veraltete Version von libCanvas nutzt die bei Trixie jetzt inzwischen gefixt sein sollte mit der neusten Version. Kann das jemand bestätigen?
@CommanderXXL sagte in eCharts - kein sendTo nach Upgrade auf Node.js 22.x:
Wie ich das verstehe ist das Problem nur dass der Adapter eine veraltete Version von libCanvas nutzt die bei Trixie jetzt inzwischen gefixt sein sollte mit der neusten Version. Kann das jemand bestätigen?
Bei mir läuft der Adapter jedenfalls unter Trixie auf einem RPi4. Allerdings hab ich mir den (für nodejs>22) ein wenig gepatcht.
Du kannst ja mal schauen, ob das bei dir rennt: -
@CommanderXXL sagte in eCharts - kein sendTo nach Upgrade auf Node.js 22.x:
Wie ich das verstehe ist das Problem nur dass der Adapter eine veraltete Version von libCanvas nutzt die bei Trixie jetzt inzwischen gefixt sein sollte mit der neusten Version. Kann das jemand bestätigen?
Bei mir läuft der Adapter jedenfalls unter Trixie auf einem RPi4. Allerdings hab ich mir den (für nodejs>22) ein wenig gepatcht.
Du kannst ja mal schauen, ob das bei dir rennt:@Thomas-Braun sagte in eCharts - kein sendTo nach Upgrade auf Node.js 22.x:
@CommanderXXL sagte in eCharts - kein sendTo nach Upgrade auf Node.js 22.x:
Wie ich das verstehe ist das Problem nur dass der Adapter eine veraltete Version von libCanvas nutzt die bei Trixie jetzt inzwischen gefixt sein sollte mit der neusten Version. Kann das jemand bestätigen?
Bei mir läuft der Adapter jedenfalls unter Trixie auf einem RPi4. Allerdings hab ich mir den (für nodejs>22) ein wenig gepatcht.
Du kannst ja mal schauen, ob das bei dir rennt:@Thomas-Braun das klingt ja spannend. Was hast du genau für NodeJS >=22 eingebaut? Wäre das vielleicht eine Option das als MR für den echten Adapter zur Verfügung zu stellen? Eventuell erbarmt sich ja doch noch ein Dev wenigstens den MR zu approven dann. Dann hätte jeder was davon und nicht nur die paar Leute die den Adapter aus einem Github Repo manuell installieren. Ich probiere es auf jeden Fall heute mal mit deinem Patch aus.
-
@Thomas-Braun sagte in eCharts - kein sendTo nach Upgrade auf Node.js 22.x:
@CommanderXXL sagte in eCharts - kein sendTo nach Upgrade auf Node.js 22.x:
Wie ich das verstehe ist das Problem nur dass der Adapter eine veraltete Version von libCanvas nutzt die bei Trixie jetzt inzwischen gefixt sein sollte mit der neusten Version. Kann das jemand bestätigen?
Bei mir läuft der Adapter jedenfalls unter Trixie auf einem RPi4. Allerdings hab ich mir den (für nodejs>22) ein wenig gepatcht.
Du kannst ja mal schauen, ob das bei dir rennt:@Thomas-Braun das klingt ja spannend. Was hast du genau für NodeJS >=22 eingebaut? Wäre das vielleicht eine Option das als MR für den echten Adapter zur Verfügung zu stellen? Eventuell erbarmt sich ja doch noch ein Dev wenigstens den MR zu approven dann. Dann hätte jeder was davon und nicht nur die paar Leute die den Adapter aus einem Github Repo manuell installieren. Ich probiere es auf jeden Fall heute mal mit deinem Patch aus.
Ich erzwinge da lediglich eine höhere Version von jsdom.
Also keine umwerfenden Änderungen, die einen PR notwendig machen sollten. -
@thomas-braun Also auch damit leider nix zu holen. Ich habe aber inzwischen in irgend einem Forum gefunden man soll angeblich node-canvas aus den sourcen neu bauen (mit --build-from-sources) und dann soll es klappen. Ich konnte das bisher nicht verifizieren da ich mir nicht sicher bin in welchem ordner ich den Befehl aufrufen muss für das node-canvas von echarts. Ich hatte früher mit npm Befehlen schon komische Seiteneffekte weil die Pakete irgendwie in verschiedenen Versionen in unterschiedlichen Ordnern lagen. Leider bin ich Linux und NPM mässig nicht ganz so fit. Daher wäre es cool wenn ein Profi das auf einem Pi 5 mal ausprobieren könnte und dann die Befehle bzw. Ordner zum Ausführen hier mal posten könnte.
-
@thomas-braun Also auch damit leider nix zu holen. Ich habe aber inzwischen in irgend einem Forum gefunden man soll angeblich node-canvas aus den sourcen neu bauen (mit --build-from-sources) und dann soll es klappen. Ich konnte das bisher nicht verifizieren da ich mir nicht sicher bin in welchem ordner ich den Befehl aufrufen muss für das node-canvas von echarts. Ich hatte früher mit npm Befehlen schon komische Seiteneffekte weil die Pakete irgendwie in verschiedenen Versionen in unterschiedlichen Ordnern lagen. Leider bin ich Linux und NPM mässig nicht ganz so fit. Daher wäre es cool wenn ein Profi das auf einem Pi 5 mal ausprobieren könnte und dann die Befehle bzw. Ordner zum Ausführen hier mal posten könnte.
@CommanderXXL
Versuche es damit.cd /opt/iobroker/node_modules/canvas/ sudo -u iobroker npm install --omit=dev -
@eduard77 danke. Es hat dann tatsächlich geklappt wenn man deine Befehle noch mit "--build-from-source" kombiniert hat.
Die tatsächliche Lösung für das "DLOPEN Failed" Problem und "ECharts startet nicht mehr" Problem ist also in der Tat:
cd /opt/iobroker/node_modules/canvas/ sudo -u iobroker npm install --omit=dev --build-from-sourceDamit startet dann ECharts wieder wie es soll. Ich teste jetzt ob auch das Rendern mit sendto wieder klappt.
-
Jawoll!!!! Ich kann bestätigen dass mit den Befehlen von oben tatsächlich dann nicht nur ECharts wieder startet, sondern auch das sendto rendern wieder klappt.
Danke an alle die hier unterstützt haben. Damit gibt es eine Lösung nach fast 7 Monaten um ECharts auf einem Raspberry Pi 5 wieder laufen zu lassen. Wie gesagt, in meinem Fall mit Trixie, ich denke aber es sollte auch mit altem Bookworm so klappen.
Support us
647
Online32.6k
Benutzer82.3k
Themen1.3m
Beiträge