Fragen zur Mitarbeit an der SW
Verfasst: Mo Sep 20, 2021 8:56 pm
Moin,
im Thread "Passworteingabe (Screenlock) abschalten" hatte ich ja schon geschildert, wie ich Hals über Kopf dazu kam, die "Hersteller-SD"-Karte gegen ein Rasbian Buster mit selbstaufgesetztem System zu ersetzen. Das hat natürlich - auch jenseits des Screensavers - nicht ganz reibungslos geklappt, aber läuft jetzt so weit, dass die Gäste morgen kommen können (Ein Youtube-Kanal zur Nachhaltigkeit).
Im Einzelnen ist mir Folgendes aufgefallen:
- Das Install-Script "openwb-install.sh" ist buggy. Konkret:
soll die Module nur hinzufügen, wenn sie noch nicht in der /etc/modules stehen. Es wird nach "i2c-bcm2835" gegreppt, aber dann "snd-bcm2835" reingeschrieben. Was richtig ist, konnte ich nur raten.
- Die "dtparam"-Parameter sind zumindest mit "Buster" da deplatziert und gehören in die /boot/config.txt.
- Unter anderem "ging nichts", weil sich irgendwie ein "(null)" in den mosquito-Broker geschlichen hatte. Damit stürzte runs/mqttsub.py dann bei jedem 5-minütigen Neustart mit einer Cast-Exception ab. Ich habe ein "except" am Ende des gigantischen Parsers eingefügt, damit Schrott ohne Absturz ignoriert wird, und alles lief wieder. Aber wenn man schon einmal in den Code (als absoluter Python-Frischling) guckt (ich bin Java, Java, Java, dann Perl & C), dann war ich schon überrascht über diese Fülle von
versus einem (in meinen Augen) performanterem, kürzeren und übersichtlicheren:
Das runs/mqttsub.py ist jetzt ein Beispiel:
- Ich denke, Robustheit gegen Schrottdaten ist immer gut.
- Aber (in meinen Augen) "hübscher" machen?
Weiter ist mir nicht klar: Wie funktioniert das Projekt überhaupt? Ich kenne von FHEM eine Fülle von Informationen für "Wenn Du mitmachen möchtest". Und es gibt heikle, inoffizielle Bereiche wie "Das ist von Rudi himself, don't even think of changing!". Auf der anderen Seite erscheint mir die Contributor-Gemeinde bei OpenWB doch recht übersichtlich - vor allem, wenn es nicht um "Treiber" für ein Gerät geht ("Module").
Bevor ich jetzt weiter lästere:
Die GUI ist wirklich hübsch und gelungen! Ich gucke lieber auf den Status von OpenWB im Color-Theme, als auf das, was ich mir in den letzten 1,5 Jahren mit FHEM und Grafana selber gebastelt habe! Und: die OpenWB funktioniert.
Dies Lob vorausgeschickt: Eine Mischung aus Respekt vor der Maximal-Ausnutzung von bash-Skripten und Gruseln vor dem "Deutschlandtakt" (dem 10-Sekunden-Intervall - das Wort kriege ich nicht mehr aus dem Kopf) hat sich bei mir aufgedrängt. Es mag um absolute Peanuts gehen, die eine schnellere Regelung des PV-Ladens erbringt - aber wenn ich auf "Stop" beim Licht drücke, erwarte ich, dass das Licht nicht in 0-10 Sekunden ausgeht, sondern gefühlt sofort. Das ist natürlich absoluter Core und nicht irgendein Treiber.
Insofern weiß ich auch nicht, inwieweit jetzt einerseits Mitarbeit da erwünscht ist - andererseits ist dieses große Update "OpenWB 2.0" offenbar nicht im offiziellen github. Es macht daher auch nicht unbedingt Spaß, sich Gedanken zu machen, wenn nicht klar ist, was beim Wechsel von Nightly auf OpenWB 2.0 denn "weggeworfen" wird.
An folgenden Stellen würde ich ggf. gerne an den "Core" ran:
- M.E. ist ein benutzerdefiniertes akzeptiertes "Netz/PV"-Ratio nötig. Die OpenWB schaltet 1 A auch bei 3-phasigem Laden zurück, sobald 1 Watt Netzimport anliegt. Dafür auf 689 PV-Watt zu verzichten, ist nicht ökonomisch.
- Es ist ein hochkomplexes Thema, aber m.E. gehört zu einer optimalen Lösung ein PV-Prediktor, ein Hausstrom-Prediktor, und eine "Feedback-Detection" zum vorgegebenen Ladestrom. Beispiel: Mit einer Waschmaschine in der Hin-Pause-Her-Pause-Phase kommt die Steuerung gut aus dem Konzept und schafft es teilweise, in der Pause auf "Dreh hoch" zu gehen, um dann den nächsten Waschmaschinen-Motor-Zyklus mit einer um 1 A erhöhten Ladeleistung zusammenfallen zu lassen, und sich beim nächsten Messwert wiederum ganz erschreckt zu reduzieren. Ob das besser geht, müsste man simulieren.
- Auf Benutzerkommandos (PV / Sofort / u.s.w.) muss sofort reagiert werden.
Passe ich mit den Zielen überhaupt zur OpenWB-Community?
im Thread "Passworteingabe (Screenlock) abschalten" hatte ich ja schon geschildert, wie ich Hals über Kopf dazu kam, die "Hersteller-SD"-Karte gegen ein Rasbian Buster mit selbstaufgesetztem System zu ersetzen. Das hat natürlich - auch jenseits des Screensavers - nicht ganz reibungslos geklappt, aber läuft jetzt so weit, dass die Gäste morgen kommen können (Ein Youtube-Kanal zur Nachhaltigkeit).
Im Einzelnen ist mir Folgendes aufgefallen:
- Das Install-Script "openwb-install.sh" ist buggy. Konkret:
Code: Alles auswählen
if grep -Fxq "i2c-bcm2835" /etc/modules
then
echo "...ok"
else
echo "i2c-dev" >> /etc/modules
echo "i2c-bcm2708" >> /etc/modules
echo "snd-bcm2835" >> /etc/modules
echo "dtparam=i2c1=on" >> /etc/modules
echo "dtparam=i2c_arm=on" >> /etc/modules
fi
- Die "dtparam"-Parameter sind zumindest mit "Buster" da deplatziert und gehören in die /boot/config.txt.
- Unter anderem "ging nichts", weil sich irgendwie ein "(null)" in den mosquito-Broker geschlichen hatte. Damit stürzte runs/mqttsub.py dann bei jedem 5-minütigen Neustart mit einer Cast-Exception ab. Ich habe ein "except" am Ende des gigantischen Parsers eingefügt, damit Schrott ohne Absturz ignoriert wird, und alles lief wieder. Aber wenn man schon einmal in den Code (als absoluter Python-Frischling) guckt (ich bin Java, Java, Java, dann Perl & C), dann war ich schon überrascht über diese Fülle von
Code: Alles auswählen
if (a and b):
...
if (a and c):
...
if (a and d):
...
Code: Alles auswählen
if (a):
if (b):
...
if (c):
...
if (d):
...
- Ich denke, Robustheit gegen Schrottdaten ist immer gut.
- Aber (in meinen Augen) "hübscher" machen?
Weiter ist mir nicht klar: Wie funktioniert das Projekt überhaupt? Ich kenne von FHEM eine Fülle von Informationen für "Wenn Du mitmachen möchtest". Und es gibt heikle, inoffizielle Bereiche wie "Das ist von Rudi himself, don't even think of changing!". Auf der anderen Seite erscheint mir die Contributor-Gemeinde bei OpenWB doch recht übersichtlich - vor allem, wenn es nicht um "Treiber" für ein Gerät geht ("Module").
Bevor ich jetzt weiter lästere:
Die GUI ist wirklich hübsch und gelungen! Ich gucke lieber auf den Status von OpenWB im Color-Theme, als auf das, was ich mir in den letzten 1,5 Jahren mit FHEM und Grafana selber gebastelt habe! Und: die OpenWB funktioniert.
Dies Lob vorausgeschickt: Eine Mischung aus Respekt vor der Maximal-Ausnutzung von bash-Skripten und Gruseln vor dem "Deutschlandtakt" (dem 10-Sekunden-Intervall - das Wort kriege ich nicht mehr aus dem Kopf) hat sich bei mir aufgedrängt. Es mag um absolute Peanuts gehen, die eine schnellere Regelung des PV-Ladens erbringt - aber wenn ich auf "Stop" beim Licht drücke, erwarte ich, dass das Licht nicht in 0-10 Sekunden ausgeht, sondern gefühlt sofort. Das ist natürlich absoluter Core und nicht irgendein Treiber.
Insofern weiß ich auch nicht, inwieweit jetzt einerseits Mitarbeit da erwünscht ist - andererseits ist dieses große Update "OpenWB 2.0" offenbar nicht im offiziellen github. Es macht daher auch nicht unbedingt Spaß, sich Gedanken zu machen, wenn nicht klar ist, was beim Wechsel von Nightly auf OpenWB 2.0 denn "weggeworfen" wird.
An folgenden Stellen würde ich ggf. gerne an den "Core" ran:
- M.E. ist ein benutzerdefiniertes akzeptiertes "Netz/PV"-Ratio nötig. Die OpenWB schaltet 1 A auch bei 3-phasigem Laden zurück, sobald 1 Watt Netzimport anliegt. Dafür auf 689 PV-Watt zu verzichten, ist nicht ökonomisch.
- Es ist ein hochkomplexes Thema, aber m.E. gehört zu einer optimalen Lösung ein PV-Prediktor, ein Hausstrom-Prediktor, und eine "Feedback-Detection" zum vorgegebenen Ladestrom. Beispiel: Mit einer Waschmaschine in der Hin-Pause-Her-Pause-Phase kommt die Steuerung gut aus dem Konzept und schafft es teilweise, in der Pause auf "Dreh hoch" zu gehen, um dann den nächsten Waschmaschinen-Motor-Zyklus mit einer um 1 A erhöhten Ladeleistung zusammenfallen zu lassen, und sich beim nächsten Messwert wiederum ganz erschreckt zu reduzieren. Ob das besser geht, müsste man simulieren.
- Auf Benutzerkommandos (PV / Sofort / u.s.w.) muss sofort reagiert werden.
Passe ich mit den Zielen überhaupt zur OpenWB-Community?