openWB Software LARGE - mit Node-Red im Bauch

[hominidae]

....analog zu VenusOS von Victron möchte ich das Feature vorschlagen, Node-Red in der Software der openWB mit auszuliefern (ich hoffe der kleine rPi 3b schafft das).

Victron hat hierfür zwei Images, "normal" und "Large", welches NR enthält.

Da MQTT in der openWB ja schon an Bord ist, wäre es auch ein leichtes - auch analog Victron - nach und nach eigene Nodes für die Features/Daten/Schalter der openWB in einer Bibliothek bereit zu stellen (node-red-contrib-openWB) um es den weniger IT-/Programmier-affinen Usern zu ermöglichen, eigene Regeln/Features hinzuzufügen oder aus der Wissenssammlung zu nutzen.

[Gero]

Die Idee, Node Red mit auf den Raspi zu packen hatte ich auch schon mal. Als ich mir dann aber bei der Nachinstallation von halbgarem node-red-contrib Zeugs die Notwendigkeit zum Safe-Mode-Start eingefangen habe, habe ich eingesehen, dass das irgendwie doch schon Support-Aufwand erzeugt.

Die Idee mit den zwei Versionen finde ich aber gut. Nur ist die Zielgruppe derer, die keinen extra-Raspi für node Red laufen lassen wollen dummerweise genau die, die sich mit der Materie nicht so genau auskennt und den Support-Aufwand erzeugt.

Ich weiss nicht, ob und wie man eine node Red Installation irgendwie so absichern / konfigurieren kann, dass man sie im Zweifelsfalle einfach neu drüberinstalliert bekokmmt. Also per einfachem Mausklick oder auch vollautomatisch, wenn die openWB beim
Reboot erkennt, dass das node Red nicht mehr hochkommt, dass dann eine Neuinstallation durchgeführt wird. Man verliert so seine Flows, die kann man aber ja per „export“ backupen.

Ich denke dass ohne eine solche Logik openWB da keine Lust drauf haben wird.

Aber generell unzerstütze ich die Idee, da man so ja ein paar sehr individuelle Wünsche so einfach nachgereicht bekommt.

[hominidae]

Ja, das sind wichtige Überlegungen.
Natürlich muss es "Idotensicher" sein und bei Wechselwirkungen mit dem "Original-OS" einfach ein/ausschalt/neu-installierbar.-

Ich weiss nicht, wie das bei VenusOS gemacht ist....aber da könnte man ja mal nachgucken, wenn man versiert genug ist.
Da ich NR noch für andere Dinge nutze und deshalb nicht auf via Victron GX/Venus-OS, kann ich auch nicht sagen, wie es sich anfühlt.
Allein die Idee mit dem small/large Image finde ich gut, für die openWB auf dem Weg zu einem vollwertigen EMS.

Meine erste idee dazu wäre NR im Container (Docker / LXC, ...) die Flows und Libraries (standard und contribs gfls nochmal getrennt) müssten dann ausserhalb des Containers gehalten werden um nach einem Neustart/Container-Image Update noch vorhanden zu sein.
Zugriff auf native Hardware (IO-Ports u.ä.) der openWB würde ich nicht erlauben...Netzwerk klar und mit modbus-tcp und mqtt kann man 90% erschlagen.

[aiole]

Gibt es bei Victron auch einen so potenten Nutzer-Tec-Support wie bei openWB? Die wirklich wichtigen Infos konnte ich mir bis dato nur aus deren Online-Hilfe (ESS), dem Forum und den vielen externen YT-Videos ziehen.

Ich denke, das wird mit openWB schwierig, zumal nur ein Bruchteil der Leute NR nutzen würden - geschweige sauber programmieren könnten. Nicht falsch verstehen - ich nutze Venus OS - Large und finde das gut. Ich sehe mich aber nicht als Normaluser.

Außerdem gäbe es mit integriertem NR eine erhöhte Schreibzugriffszahl auf der SDC, was zu reduzierter Lebensdauer führen könnte. Spätestens da müsste klar sein, dass der Support für die openWB-Software und die Gewährleistung für die SDC weg sind. Die openWB-Partner hätten da vermutlich auch etwas dagegen, wenn sie ggf. öfter helfen müssten.

Die Victron-Leute sind fein raus und haben NR schon als Option im Large drin.
Für alle anderen ist ein extra RPi (oder VM/Container) sicher auch möglich, zumal dieser eine klare Abgrenzung in HW und SW erlaubt. Vor allem auch, wenn sich openWB weiter Richtung EMS entwickeln sollte, wo aktuelle NR-Aufgaben mit übernommen werden. Beim Lade-Lastmanagement der sw2 ist das jetzt schon der Fall. Dafür braucht es schon kein NR mehr.

[hominidae]

Ja, das mit dem Support ist so ein zweischneidiges Schwert.
..und - nix für ungut - die Doku von Victron ist schon erstklassig.

Ich denke auch das kaum ein "normaler" Victron Installateur, ähnlich wie ein openWB Partner hier Support für NR / OS-large gibt.
Victron hat trotzdem gemacht. Community ist doch Teil des OSS-Gedanken.

Das Thema Lastmanagement. als kleiner Seitenhieb - sorry - kann auch nicht jeder openWB Partner. das habe ich gerade live für eine WEG ausprobiert.
Letzlich wird es - wenn es so kommt - wieder mit meinen Eli des Vertrauens gemacht, der kein openWB Partner ist.

Ein openWB LARGE Image mit entsprechenden Infos zum "Kleingedruckten und Risiken & Nebenwirkungen" würde den Support-Gedanken von openWB nicht schmälern.
Aber viele User denken, dass sie Programmierkenntnisse brauchen um einen UseCase umzusetzen...mit NR stimmt das aber nicht...ich habe bisher noch jeden Flow ohne einen "Function Node" - für den man Javascript Kenntnisse braucht - hinbekommen.

Klar, extra Hardware ist auch immer möglich, aber der Zugang über ein Image ist einfach ein Anderer.
Ich mache mir eher Sorgen, dass der RPi 3B da drin zu knappe Ressourcen hat.
Das Thema SD-Karte ist nicht von der Hand zu weisen, aber NR läuft im RAM und mit Anbindung über Netz/MQTT wird doch die SD nicht in Mitleidenschaft gezogen, oder swap-ed sich das OS zu Tode?
Ich schwöre bei sowas auf RPi-Clone mit EMMC - evtl. wird es auf dem Weg zum EMS auch mal Zeit für ein Hardware-Upgrade der openWB Series 2??? Aber das ist ja nicht das Thema hier.

[aiole]

Ja, das mit dem Support ist so ein zweischneidiges Schwert.
..und - nix für ungut - die Doku von Victron ist schon erstklassig.

Wird Zeit, dass so etwas auch bei openWB kommt. Es gibt etliche Leute, die dabei helfen wollen, aber es fehlt noch das passende Doku-tool.

Ich denke auch das kaum ein "normaler" Victron Installateur, ähnlich wie ein openWB Partner hier Support für NR / OS-large gibt.
Victron hat trotzdem gemacht. Community ist doch Teil des OSS-Gedanken.

Das würden die openWB-Partner und der openWB-Support auch nicht für NR geben. Ich sehe eher die Gefahr, dass der Profi-Support von openWB mit zusätzlichen NR-Anfragen überfordert wird. Die meisten NR-Dinge sind ja "Spezial-tools" oder "Mods", die zunächst nichts mit der Serien-openWB-sw2-Programmierung zu tun haben. Da hat jeder NR-ler eigene Ideen, die erstmal vom Gegenüber identifiziert werden müssen.

Das Thema Lastmanagement. als kleiner Seitenhieb - sorry - kann auch nicht jeder openWB Partner. das habe ich gerade live für eine WEG ausprobiert.
Letzlich wird es - wenn es so kommt - wieder mit meinen Eli des Vertrauens gemacht, der kein openWB Partner ist.
Aber das ist ja nicht das Thema hier.

Das hängt oft vom openWB-Partner ab. Es gibt welche, die haben größere Installationen am Wickel und nutzen es bereits erfolgreich. Andere sind mehr auf kleinere Installationen spezialisiert, aber auch dort kommen jetzt die Lastbeschränkungen (Stichwort §14a EnWG) und das LM wird zunehemend wichtig.

Ein openWB LARGE Image mit entsprechenden Infos zum "Kleingedruckten und Risiken & Nebenwirkungen" würde den Support-Gedanken von openWB nicht schmälern.

Das Kleingedruckte wird meist nicht gelesen und dann wird der Support munter mit NR-Anfragen angefragt. Jede Antwort, dass NR nicht supportet wird, ist eine zuviel. Hinzukommend dann die Interaktionsdinge mit openWB - z.B. über MQTT. Das kann die Schnelligkeit und die Qualität des normalen Supportes derb herunterziehen.

Aber viele User denken, dass sie Programmierkenntnisse brauchen um einen UseCase umzusetzen...mit NR stimmt das aber nicht...ich habe bisher noch jeden Flow ohne einen "Function Node" - für den man Javascript Kenntnisse braucht - hinbekommen.

Dennoch zähle ich das bereits zum Programmieren .
Die Effekte aus NR-oWB-Interaktion kann man dem Support m.E. nicht zumuten. Das ist ähnlich WLAN. Der Support soll dort Netzwerkprobleme der Kund:inenn lösen, die nichts mit der sw2 zu tun haben. Deshalb ist das bei sw2 sicher rausgeflogen.

Klar, extra Hardware ist auch immer möglich, aber der Zugang über ein Image ist einfach ein Anderer.
Ich mache mir eher Sorgen, dass der RPi 3B da drin zu knappe Ressourcen hat.

Kommt auf den Flow und die Effizienz dessen an. Ich habe ein Venus-OS large auf einen RPi-ZWEI laufen und das ist mit NR noch nicht ausgelastet.

Das Thema SD-Karte ist nicht von der Hand zu weisen, aber NR läuft im RAM und mit Anbindung über Netz/MQTT wird doch die SD nicht in Mitleidenschaft gezogen, oder swap-ed sich das OS zu Tode?
Ich schwöre bei sowas auf RPi-Clone mit EMMC - evtl. wird es auf dem Weg zum EMS auch mal Zeit für ein Hardware-Upgrade der openWB Series 2??? Aber das ist ja nicht das Thema hier.

Na ja - eine Mehrbelastung der SDC kommt durch NR garantiert.

Ein RPi-Derivat mit EMMC aufgelötet, fände ich nicht so gut - speziell wegen der Langzeitverfügbarkeit und Austauschoptionen der aktuellen RPi in ein paar Jahren. Es gibt ja schon EMMC-SDC, wenn auch gerade nicht verfügbar. -> https://www.berrybase.de/raspikey-plug- ... ry-pi-16gb

Die clones (mit und ohne EMMC) konnten sich nie wirklich gegen das Original durchsetzen. Für ein long term system sollte man da besser keine Experimente wagen. Auch reicht der RPi3(+) für sw2 voll aus. RPi4 + 5 würden bei den allermeisten Leuten zu viel Power vorhalten (+ erhöhter Energieverbrauch), was nicht nötig ist.
Die openWB-Modularität bis hin zu Einzelteilen finde ich persönlich ziemlich nachhaltig.

[openWB]

Bedenkt bei der Victron Lösung aber bitte das der Victron Support gänzlich anders aufgestellt ist.
Da geht der erste Weg immer zum Händler. Selbst wenn der nicht wirklich greifbar ist darf ein anderer Händler herhalten.
Die Händler werden dann von Victron betreut bzw. können Rückfragen. Nur in Extremfällen kommt man zu Victron direkt durch.
Das heißt die ganzen " ich habs verkonfiguriert " Tickets werden im First Level nicht bei Victron abgefedert.

Viele andere Argumente kamen ja schon.

[KLez]

....analog zu VenusOS von Victron möchte ich das Feature vorschlagen, Node-Red in der Software der openWB mit auszuliefern (ich hoffe der kleine rPi 3b schafft das).

Sorry... Das halte ich für Käse. Die meisten User brauchen es wahrscheinlich nicht und es würde die Support Anfragen für das OpenWB Team massiv steigern. Davon abgesehen haben die beiden Produkte erstmal nicht viel miteinander zu tun. Dann kommt der nächste der lieber ioBroker integriert hätte, oder HomeAssistant, oder OpenHAB, oder was auch immer.

Viel Sinnvoller: OpenWB als Docker Image bereitstellen! Hier hinkt OpenWB einfach dem Stand der Technik hinterher.
Dann könntest Du auf den verbauten Raspi z.B. ein Debian + Docker installieren und dann alle Images drauf packen Du die willst. Unter anderem eben auch NodeRed.

[hominidae]

Sorry... Das halte ich für Käse. Die meisten User brauchen es wahrscheinlich nicht und es würde die Support Anfragen für das OpenWB Team massiv steigern. Davon abgesehen haben die beiden Produkte erstmal nicht viel miteinander zu tun. Dann kommt der nächste der lieber ioBroker integriert hätte, oder HomeAssistant, oder OpenHAB, oder was auch immer.

Mir geht es nicht um Produkte, sondern ums Konzept. Ich brauche es auch selbst nichtmal, da ich NR eh extern auf nem grossen NAS einsetze.

Viel Sinnvoller: OpenWB als Docker Image bereitstellen! Hier hinkt OpenWB einfach dem Stand der Technik hinterher.

Ich denke nicht, das dem so ist.
Ich habe auch sowas nicht vorgeschlagen, weil es das untergräbt, was openWB zu openWB macht...die Hardware finanziert die Software.

[KLez]

Ich denke nicht, das dem so ist.
Ich habe auch sowas nicht vorgeschlagen, weil es das untergräbt, was openWB zu openWB macht...die Hardware finanziert die Software.

Naa, schon... Du bekommst heute fast alles als Docker Image. OpenWB aber nicht.
Ein Docker Image würde an dem Prinzip "Hardware finanziert Software" auch nichts ändern. Ich kann OpenWB ja auch jederzeit in einer VM installieren, aber Docker ist einfach um längen praktischer.