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.