Feedback 2.0 Alpha 1

[derNeueDet]

Cool dein Docker Image, nur eine Sache muss man noch beachten, falls jemand auf die Idee kommt, den Docker Container parallel zu einer anderen openWB Instanz auf einem Raspi laufen zu lassen. Die MQTT und WS Ports 1883 und 9001 sind dann schon belegt und der Start des Containers wird schief gehen.

VG
Det

[mallesepp]

Hallo zusammen,
auch ich bin am Testen der neuen Version auf einem seperaten Raspi.
Leider zeigt es bei mir bis jetzt keine Daten. Habe Fronius Symo mit
Smartmeter. Die IP habe ich eingetragen. Was muss ich noch machen
das mir Verbrauchs- und Erzeugungsdaten angezeigt werden!
Danke und liebe Grüße.

[Bastelfrosch]

Guten Morgen zusammen,

@openWB

die Heartbeat-Überwachung an sich ist eine coole Sache.
Aus rein praktischer Sicht ist dies zu empfehlen, damit protokollierte Ladevorgänge an einem getrennten Satellit unterbunden werden.
Aus Sicht des Lastmanagements ist dies ebenfalls eine tolle Sache.
Ich habe seinerzeit bei Bekanntwerden der Details zu den Updates mal Rücksprache mit dem Netzbetreiber gehalten. Hier ist es jedenfalls so, dass es keine "Ein-Fehler-Sicherheit" beim Lastmanagement als Vorgabe vom Netzbetreiber gibt.
Auch haben die bereits installierten Ladepunkte auch mit neuer Software Bestandsschutz.
Daher wäre es, insbesondere für den Alpha- und Betatest sehr von Interesse, den Satellit zu Testzwecken verwenden zu können und die spätere Heartbeat-Einbindung, welche nach m.K. nur mit einer Hardware-Nachrüstung klappen würde, optional zu integrieren.

[vuffiraa]

Moin,

auch ich habe die 2.0 bei mir in einem Docker-Container zum Laufen überreden können. Mein Ausgangspunkt war das Projekt https://hub.docker.com/r/ingmarstein/openwb. Das hatte ich schon für die 1.9er Version angepasst und konnte auch ein 2.0er Image erzeugen. Der Container läuft dann lokal auf meinem Rechner mit einem gemounteten Git Repository. Dadurch kann ich direkt am Code arbeiten und die Auswirkungen sehen. @yankee vielleicht können wir unsere Ansätzen mal übereinanderlegen und abgleichen.

@mallesepp Die Fronius-Module haben noch ein paar Probleme in der 2.0. Ich habe dazu im Github auch schon ein Issue #230 aufgemacht. Je nach Ausgang kann ich dann auch die Module anpassen, da ich eh schon ein paar Änderungen für Fronius bereitgestellt habe.

VG

[LutzB]

Danke für eure zahlreichen Rückmeldungen!

Ich versuche mal ein paar davon zu beantworten bzw. den Hintergrund zu erklären.

Sind die MQTT Pfade gleich geblieben? (ich nutze für EVU + PV MQTT)

Nein, da hat sich einiges geändert. Die Pfade sind jetzt abhängig davon, in welcher Reihenfolge die Geräte/Komponenten angelegt werden. Bei den MQTT Komponenten steht immer direkt dabei, welche Pfade zu verwenden sind.

Gibt es eine VM oder ein Hyper-V Image schon zum testen ?

Bis jetzt gibt es nur ein Image speziell für den Raspberry Pi, da dieser bereits bei allen openWB verbaut ist. Es ist natürlich denkbar, gerade im Hinblick auf die Pro ohne Raspi, die Regelung in einer VM oder einem Container aus einem Server/NAS laufen zu lassen. Dafür fehlen uns jedoch Erfahrungen mit den Techniken und einiges in der Regelung (z.B. Taster, LEDs) ist doch arg an die Hardware gebunden. Dafür müssten Alternativen gefunden werden.
Persönlich fände ich es gut, wenn wir die Regelung universell auf fast jeder Hardware laufen lassen könnten.

Ich habe das Imgage installiert und dann gibt's zwei mal 192.168.193.5 im Netz...

Stimmt leider aktuell. Die Einstellungen für das Netzwerk fehlen noch. Als Übergangslösung bitte in der runs/atreboot.sh die Zeile 46 anpassen oder ganz entfernen, falls kein fertiges Kit ausgelesen werden muss.

Welche Nebenwirkungen hat eine umschalten der OpenWB in den "Nur Ladepunkt" Modus.
Ich möchte jederzeit durch abschalten des "Nur Ladepunkt" Modus wieder zur funktionierden 1.9x zurückkehren können.
Was ist mit den statitschtiscen Daten, die sind dann wohl futsch oder zumindest löchrig?

Ja, die Statistik/Historie hat dann Bereiche ohne Daten. Das betrifft jedoch nur die aktuellen Leistungen. Da die Monats- und Jahresdiagramme anhand der Zählerstände berechnet werden, kommt in Summe zumindest das selbe Ergebnis raus. Man erhält dann lediglich einen hohen Peak, wenn der Modus wieder zurückgesetzt wird.
Anders sieht es bei Modulen aus, die simulierte Zählerstände verwenden. Da die anhand der aktuellen Leistung berechnet werden und diese nicht erfasst wird, kommt es zwangsläufig zu Lücken und Fehlern.

Dass die kompilierte Webseite da drin ist, wird der Größe des Repositories jedenfalls nicht unbedingt gut tun, weil hier große Diffs entstehen die sich nicht gut kompilieren lassen und ist meines Erachtens auch keine gute Idee. So gesehen finde ich bei kritischer Betrachtung die Idee einfach "git clone" zu verwenden generell nicht optimal. Aber gut, es funktioniert.

Die Diffs sind trotz Kompilierung relativ übersichtlich, da Webpack einzelne "Chunks" für jede Seite bildet. Einziger großer "Klotz" sind derzeit die eingebundenen Node.js Module und da besonders Bootstrap. Das könnte man noch drastisch entschlacken, wenn nur das importiert wird, was auch genutzt wird. Den Aufwand habe ich mir aktuell vorerst gespart, da nach Möglichkeit noch ein Upgrade auf Bootstrap 5 kommt.
Wie könnte denn alternativ ein Update-System funktionieren? Wir sind für alles offen.

Es sind offenbar noch diverse alte (Frontend-)Skripte vorhanden bei denen ich davon ausgehe, dass die nicht mehr gebraucht werden?! Ich habe da noch nicht ganz geblickt.
Es sind auch noch jede Menge PHP-Dateien da. Und Apache wird verwendet. Ich nehme an das fliegt noch alles raus? Ich blicke nicht ganz ob das tatsächlich noch verwendet wird. Für die Übersicht wäre es jedenfalls schön, wenn nurnoch Code im Repo ist, der auch gebraucht wird....

Ja, wir hatten schon etwas aufgeräumt, aber noch nicht komplett. Teilweise ist noch Altlast von 1.9 drin, speziell was das Display und die Hauptseite betrifft. Der Apache wird weiter verwendet, irgendwer muss ja die Seiten bereitstellen. Alternative Lösungen? Nginx, lighttpd oder einen node.js Server? Da fehlen uns die Erfahrungen.

[openWB]

Ich habe seinerzeit bei Bekanntwerden der Details zu den Updates mal Rücksprache mit dem Netzbetreiber gehalten. Hier ist es jedenfalls so, dass es keine "Ein-Fehler-Sicherheit" beim Lastmanagement als Vorgabe vom Netzbetreiber gibt.

Wir haben hier unterschiedliche Rückmeldungen erhalten.

Daher wäre es, insbesondere für den Alpha- und Betatest sehr von Interesse, den Satellit zu Testzwecken verwenden zu können und die spätere Heartbeat-Einbindung, welche nach m.K. nur mit einer Hardware-Nachrüstung klappen würde, optional zu integrieren.

Eine Hardwareänderung ist nicht erforderlich. Lediglich ein Software Update des Netzwerk/Modbus Adapters

[yankee]

Wie könnte denn alternativ ein Update-System funktionieren? Wir sind für alles offen.

Mit Hilfe einer GitHub-Action ein fertiges ZIP-file (oder TAR oder...) bauen wo alles drin ist, was gebraucht wird und irgendwo (zum Beispiel unter den Github-releases) zum Download bereitstellen. Dann einfach nurnoch das Zip runterladen und entpacken.

Das hätte den Vorteil, dass man sehr flexibel damit ist den build-Prozess zu erweitern ohne dass dafür Software auf dem Pi nötig wäre. Und es wird kein kompilierter Output im Git benötigt.

Eine nicht ganz unähnliche Alternative wäre statt einer Zip-file ein Dockerimage zu bauen, welches dann zum Beispiel im docker-hub gehostet werden kann. Der Update auf dem Pi würde sich dann auf ein update vom Docker-Image beschränken. In dem Fall müsste man sich dazu allerdings noch ein paar Gedanken zur Systemkonfiguration machen. Letzteres würde der Struktur sicherlich gut tun und allgemein mehr Flexibilität bieten, aber kostet zusätzlich Zeit zu auch zu machen.

Ja, wir hatten schon etwas aufgeräumt, aber noch nicht komplett. Teilweise ist noch Altlast von 1.9 drin, speziell was das Display und die Hauptseite betrifft. Der Apache wird weiter verwendet, irgendwer muss ja die Seiten bereitstellen. Alternative Lösungen? Nginx, lighttpd oder einen node.js Server? Da fehlen uns die Erfahrungen.

Das Projekt ist jetzt (serverseitig) fast komplett in Python geschrieben. Ich würde anregen dabei zu bleiben und alles in Python zu schreiben. Das vereinfacht es auch, dass die Komponenten miteinander reden, wenn alles in der gleichen Sprache ist.

Selbst Erfahrungen damit habe ich (noch) nicht, aber was man sich dazu ansehen könnte wäre FastAPI, Tornado, Quart und.... uff... viele mehr.
Templates und so werden wohl nicht mehr gebraucht, weil das jetzt alles Vue.js übernimmt. Insofern muss der Server nur eine Rest-API bereitstellen. Dafür reicht ein kleines Micro-Framework mit nicht all zu viel unnötiger Komponenten. Irgendwas von dem ganzen was gut dokumentiert ist, einfach zu benutzen und am besten noch weiterentwickelt wird. Soweit ich sehe sind viele der Frameworks in der Nutzung recht ähnlich...

[derNeueDet]

@openWB Team: Kann ich in der 2.0 Alpha das update.sh Script auf dem Raspi direkt aufrufen, um einen Update auf die aktuelle Version zu bekommen, oder ist das noch ein altes SW Fragment, das noch nicht angepasst ist?

VG
Det

[LutzB]

Rein theoretisch ist es angepasst, aber noch nicht getestet. Ich würde aktuell eher manuell den aktuellen Stand vom Repo holen.

In /var/www/html/openWB wechseln, den openwb2 Service beenden und dann git pull. Anschließend am Besten einen Reboot oder zumindest die atreboot.sh vor dem Neustart des Service ausführen.

[derNeueDet]

Ich teste nachher mal das Update Script.
Wenn es schief geht, bekomm ich das auch schnell wieder hin.

Wo werden denn die Konfigurationen abgelegt?