seit mehr als einem Jahr ist es sehr ruhig um RedMatic geworden. Die ehemals aktuelle node-red Version 1.2.9 ist mittlerweile angestaubt (3.x steht vor der Tür) und immer mehr Nutzer klagen über fehlenden Support. Bisher hat sich keiner gefunden, der in die Bresche springt und Hilfestellung oder Weiterentwicklung leistet.
Ich habe mir schon mehrfach den Aufbau von RedMatic angeschaut und muss leider gestehen, dass mir da so einiges an KnowHow fehlt, um einen 1:1 Klon zu bauen. Ich denke mal, so geht es vielen anderen auch. Es ist schon erstaunlich, wieviel (leider umdokumentiertes) Wissen in diesem vermeintlich kleinen Stück Software steckt.
Daher möchte ich mal diskutieren, wie ein neu aufgebautes RedMatic aussehen könnte und welche Ziele verfolgt werden könnten
Ziele
Aus meiner Einführung ergeben sich für mich wenigstens diese:
- RedMatic wiederbeleben
- Build Prozess voll transparent machen
- Komplexität reduzieren
Zuerst will ich mal die für mich wichtigsten Teile von RedMatic auflisten. Daraus lässt sich dann evtl. eine Aufgabenlisten ableiten
- Node.js & npm
- node-red
- node-red-contrib-ccu
- redmatic-webapp
- redmatic-homekit
- mitgelieferte contribs mit Binär-Modulen
Bisher ist RedMatic auf diesen CCU-Varianten zu haben:
- armv7l (CCU3, piVCCU3, RaspberryMatic for rpi2, tinkerboard, ...)
- aarch64 (RaspberryMatic for rpi3, rpi4)
- x86_64 (RaspberryMatic for ova, intelnuc, ...)
- Fokusierung auf ARM -> x86_64 sollte ein natives node-red auf dem host oder im container/VM nutzen können
- Nutzung vorhandener Node.js & npm Versionen -> in RedMatic wurde ja eine eigene Node-Version mitgeliefert. Ist das überhaupt nötig, wenn doch z.B RaspberryMatic (ich denke auch, die normale CCU3) eine halbwegs aktuelle Version mitbringt?
- Lieferung einer nativen Toolchain (+Python) für binäre Module -> Ein großes Problem sind die nativen Module, die in verschieben packages drin stecken. Selbst node-red baut so einiges an nativen Modulen. Eine native Toolchain würde hier einen ganz anderen Ansatz darstellen. Im Prinzip müsste ein entsprechendes Addon gar nicht mehr node-red mitliefern, sondern eben aufbauend auf einer mitgelieferten Toolchain die Installation einer gewissen node-red Version auf Basis von npm anstoßen.
- Verzicht auf Paketierung von node-red-contrib-ccu, da ein sehr guter Ersatz mit CCU-Jack existiert -> Der Nutzer kann dies über die Palette nachinstallieren
- Verzicht auf Paketierung von redmatic-homekit -> Der Nutzer kann dies über die Palette nachinstallieren oder durch Alternativen wie z.B. NRCHKB ersetzen
- Streichung der redmatic-webapp -> das hat aus meiner Sicht kaum jemand verwendet
- Streichung aller mitgelieferten contribs -> der Nutzer kann diese über die Palette nach installieren
Das heißt jetzt übrigens nicht, dass ich mich hinsetze und das ganze Ding baue. Ich würde aber zumindest den gedanklichen Unterbau für einen Neustart helfen zu bauen. Und wenn sich daraus was ergibt und es ggfs. ein paar Interessenten gibt, dann sehen wir weiter.
Was meint ihr?