Update to Node.js 12 or 14 - RaspberryMatic ova/nuc Support einstellen?

[hobbyquaker]

Problem: der x86/i686 (32bit) Support wurde wohl eingestellt - damit wäre es dann nicht mehr möglich die RaspberryMatic ova/nuc Varianten zu unterstützen. Allerdings wird das eh nur von <1% aller RedMatic User eingesetzt - insofern ist das denke ich verschmerzbar.

nodejs/build#885

TBD: 32bit node auf travis oder mit github actions selbst bauen?

[hobbyquaker]

Selbst bauen wohl auch Problembehaftet nodejs/node#33019

[EduardSarjadjuk]

Ich würde mich sehr über ein weiteren Support freuen ;)!

[hobbyquaker]

Es wird vorerst leider keine Builds mehr für die RaspberryMatic ova und intelnuc Varianten mehr geben.
Die Unterstützung im Build-Prozess bleibt erhalten, sollte es auf https://unofficial-builds.nodejs.org/ wieder einen x86 32 Bit Linux Build von Node.js geben wird automatisch auch wieder ein ova/intelnuc Build erstellt. Ich befürchte aber das sieht schlecht aus, Node.js hat den 32 Bit Support offiziell eingestellt und die aktuellen Versionen bauen wohl auch nicht mehr.

Eine andere mögliche Lösung könnte könnte evtl. sein dass @jens-maus eine x86 64 Bit Variante von RaspberryMatic erstellt.

Für die User bleibt als mögliche (und empfohlene) Alternative im Moment nur der Umstieg auf eine zweite VM um ein "normales" Node-RED anstatt RedMatic zu nutzen.
Node-red-contrib-ccu, redmatic-homekit und node-red-contrib-zigbee können dabei auch unabhängig von RedMatic eingesetzt werden.

[jens-maus]

@hobbyquaker Oh, das ist aber schade. Nun, eine x86 64bit Variante von RaspberryMatic scheitert leider bisher daran das OCCU bis jetzt exklusiv 32bit binaries liefert und Buildroot von Haus aus kein multiarch mit 64bit System und 32bit userland anbietet und ich da erst etwas für basteln müsste. Wie wäre es aber "einfach" eine RedMatic Version mit der jeweils von RaspberryMatic bzw. CCU mitgebrachten nodejs version auszuliefern? Im Buildroot build von RaspberryMatic/CCU wird nodejs ja selbst von den sourcen als 32bit gebaut und so ausgeliefert. Das könntest du doch einfach nutzen, oder?

[hobbyquaker]

Das hat leider ne Menge "Pferdefüße" RedMatic auf Basis unterschiedlicher Node.js Versionen bereitzustellen, wäre ein größerer Umbau des Build-Prozess, machbar, aber nicht trivial und in mehrerlei Hinsicht kompromissbehaftet.

Der eigentlich springende Punkt ist hier aber eher, dass der Support für Node.js 10 (das bereits in "Maintenance" ist) von vielen Entwicklern bereits eingestellt wurde und es einige Node-RED Nodes gibt die auf Node 10 nicht mehr genutzt werden können. Würde die CCU zumindest Node 12 mitbringen wäre das noch ein Kompromiss um etwas Zeit zu gewinnen, aber noch ein RedMatic dass auf Node 10 fußt zu bauen macht heute imho schon keinen Sinn mehr, auf Node 8 (was afaik noch von der CCU mitgeliefert wird) wäre es sogar garnicht mehr möglich...

[jens-maus]

@hobbyquaker Nun, zumindest RaspberryMatic kommt ja sogar in aktuellen Versionen mit nodejs 12.16.1 daher. Das die CCU3 immer noch auf nodejs v8 hängt liegt einfach an der bereits älteren buildroot umgebung die da immer noch eingesetzt wird. Ein Update davon (und somit natürlich von nodejs) ist prinzipiell in Sicht, wann das allerdings dann von eQ3 final umgesetzt wird weiss ich nicht und kann ich folglich dann auch nicht sagen. Aber da es hier im Ticket ja um RaspberryMatic geht, vielleicht kannst du ja zumindest dafür eine Lösung finden.

[hobbyquaker]

Das Problem wäre damit nur ein wenig verschoben, beginnend mit 12.17 gibt es kein x86 32 Bit Support mehr, 12.16.3 war die letzte Version die noch auf 32 Bit gebaut hat und sollte eigentlich auch schon nicht mehr eingesetzt werden (https://www.cybersecurity-help.cz/vdb/SB2020060305) ;-)

Was man jetzt tun könnte wäre den Build Prozess so umbauen dass für die ova/intelnuc Variante eben das veraltete 12.16.3 genutzt wird, aber ehrlich gesagt fehlt mir da die Motivation. Das ganze betrifft nur <1% der RedMatic User und ich halte die Alternative eine weitere dedizierte VM für Node-RED zu nutzen (anstatt RedMatic) eh für den "systemarchitektonisch" besseren Weg. Wenn man schon virtualisiert/containerisiert dann sollte man den Benefit den das mitbringt (seine Dienste zu separieren zu können) auch nutzen ;-)

[jens-maus]

Da bin ich natürlich prinzipiell bei dir, Sebastian. Allerdings gibt es schon einige Nutzer die gerne RedMatic direkt innerhalb von RaspberryMatic / CCU laufen lassen würden und wenn das mit halbwegs aufwand möglich wäre, sollte man es schon IMHO angehen. Und was nodejs 32bit support angeht, so werde ich mal schauen was das buildroot projekt so daraus macht, denn die sollten ja prinzipiell dann das selbe problem irgendwann haben. Zumindest aktuell aber bauen die nodejs noch für 32bit problemlos zusammen. Zusätzlich dazu bin ich natürlich auch parallel dazu bemüht irgendwann den Sprung auf ein vollwertiges 64bit OS in RaspberryMatic zu schaffen. Dafür müsste allerdings eQ3 dann OCCU auch als 64bit rausbringen oder ich es irgendwie schaffen eine multiarch umgebung in buildroot zu integrieren sodass die 32bit OCCU binaries trotzdem problemlos laufen.

[psi-4ward]

Da fände ich es noch zielführender eine RedMatic-OVA zu bauen. Wenn der Support seitens Node.js weg fällt, dann ist das so. Das OCCU Zeug ist doch recht outdated und da können wir nur versuchen eine legacy Umgebung zu schaffen um das alte Zeug am Leben zu halten und nicht aktuelle Software in die alte Umgebung zu pressen.

[hobbyquaker]

Über eine RedMatic OVA hab ich auch schon nachgedacht, aber da würden 3 Dinge wegfallen die RedMatic eigentlich ausmachen: keine Konfiguration nötig für node-red-contrib-ccu (Listen und Callback-Adresse ist ein Fallstrick für viele...), das RedMatic UI sowie den Komfort dass das CCU Backup RedMatic gleich mit sichert. Insofern wäre es eigentlich "nur" noch eine Node-RED OVA und hätte mit RedMatic nicht mehr viel zu tun. Dann könnte man aber eigentlich auch gleich den offiziellen Docker Container von Node-RED nutzen falls einem das händische Einrichten der Node.js/Node-RED Umgebung zu umständlich ist ;-)

[Schmello]

Grundsätzlich spricht auch nicht viel dagegen wenn es nicht mehr anders geht NodRed im Docker laufen zu lassen.
Doch ist es mir bisher nicht gelungen einen z.b. Zigbee Stick ans laufen zu bekommen.
Das einrichten von NodeRed im Docker auf einer Synology ist wirklich einfach. Doch wie bekommt man einen Stick ans laufen?
In einer VM auf einer Synology kann man einen USB Port auswählen. Denkbar einfach :)
Diese Option fehlt im Docker Setup.

[GeorgWolter]

Testcase bzw. Issue: Nach einem Update auf RedMatic 7 lässt sich RedMatic nicht mehr starten.
Bei mir läuft RaspberryMatic .1024 mit RedMatic 5.5.3 als VM (Synology DS720+ VMM, Intel Celeron J4125).
Ich habe die Release Notes gelesen aber verstehe nicht, ob das hier beschriebene Problem inzwischen behoben wurde.
Muss ich ggf. die komplette VM (RaspberryMatic-3.53.30.20201024.ova ) erneut herunterladen und in VMM aufsetzen?

[jens-maus]

@GeorgWolter Erst mit der nächsten kommenden RaspberryMatic Version 3.53.34.202011xx wird die OVA als vollwertiges 64bit OS ausgeliefert für die @hobbyquaker inzwische mit RedMatic 7 auch x86_64 Archive zur Verfügung stellt die dann damit wieder funktionieren.