Fragen zur Mitarbeit an der SW

Fragen zur Nutzung, Features, usw..
gvz
Beiträge: 72
Registriert: So Sep 12, 2021 8:28 am
Wohnort: Grevenbroich

Fragen zur Mitarbeit an der SW

Beitrag von gvz »

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:

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
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

Code: Alles auswählen

if (a and b):
	...
if (a and c):
	...
if (a and d):
	...
versus einem (in meinen Augen) performanterem, kürzeren und übersichtlicheren:

Code: Alles auswählen

if (a):
	if (b):
		...
	if (c):
		...
	if (d):
		...
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?
OpenWB S2 (Touchscreen, RFID, Zähler, 11kW), 10 kWp PV ohne Speicher, ID.3
aiole
Beiträge: 7773
Registriert: Mo Okt 08, 2018 4:51 pm
Has thanked: 23 times
Been thanked: 35 times

Re: Fragen zur Mitarbeit an der SW

Beitrag von aiole »

Ich sehe es so, dass Verbesserungen für v1.9.xxx immer sinnvoll sind. Schließlich ist es ein gestandenes System - im Gegensatz zur Neuerscheinung v2.x. Dort wird zum Anfang sicher nicht alles reibungslos laufen.
FosCo
Beiträge: 186
Registriert: Di Jun 30, 2020 9:26 am

Re: Fragen zur Mitarbeit an der SW

Beitrag von FosCo »

Sehr interessante Gedanken, grade die Unsicherheit bzgl. 2.0 teile ich. Da ich auch "von FHEM komme", ist das Thema contribution anders - ich liebe git und PRs werden gut diskutiert und auch angenommen bei openWB. Andererseits warte ich händeringend auf die 2.0 im git, um das "neue" System dann zu verstehen und zu optimieren.

Die Beobachtungen der Regelung finde ich interessant, so genau habe ich nie darauf geachtet.
17kWp Ost/Süd/West, Kostal PIKO 17, (noch) Discovergy, 2x openWB series 2 custom, FHEM, Proxmox mit OpenWB 2.x und am Basteln
derNeueDet
Beiträge: 4447
Registriert: Mi Nov 11, 2020 7:16 pm
Has thanked: 5 times
Been thanked: 27 times

Re: Fragen zur Mitarbeit an der SW

Beitrag von derNeueDet »

Ich sehe im Code auch sehr viel gewachsenes der letzten Jahre. Da kann für v2.0 sicher viel verbessert werden. Und aus den Ankündigungen in einigen Threads wird sich wohl auch vieles ändern.
Ich halte mich eigentlich auch nur in den Modulen auf. In den Core habe ich ab und zu rein geschaut, aber da denke da gehört einiges an Erfahrung mit der Auslegung der Normen durch die Fahrzeughersteller dazu.
Ich bin auch nicht glücklich über die v2.0 hinter verschlossenen Türen. Ich baue auch gerade an Modulen, um die Geräte der EVU und PV Kits flexibler nutzen zu können. Und es wäre schön zu wissen, ob ich das gerade für die Tonne mache.

VG
Det
10kWp PV mit SMA Tripower 10000TL-10 (PE11 mit SDM72V2); 2,4kWp mit Solis 2.5 G6 (EE11 mit SDM120). OpenWB Standard+. EVU EM540 an einem Raspi mit Venus OS. BEV Mercedes EQA 300 (06/2024)
tensing2
Beiträge: 103
Registriert: Di Aug 24, 2021 8:57 am

Re: Fragen zur Mitarbeit an der SW

Beitrag von tensing2 »

Es fördert auch nicht grade die Motivation am Code etwas zu machen, wenn Pull-Requests für mehr als zwei Wochen ohne jeglichen Kommentar anscheinend ignoriert werden.
OpenWB Custom und OpenWB Pro, 6,8kWp RCT Power Storage DC mit 5,7kWh Batterie, 3KW Hoymiles PV
aiole
Beiträge: 7773
Registriert: Mo Okt 08, 2018 4:51 pm
Has thanked: 23 times
Been thanked: 35 times

Re: Fragen zur Mitarbeit an der SW

Beitrag von aiole »

v2.x bindet sicher massiv Kapazität. Man will sicher nicht mit einer "Gurke" antreten.
philipp123
Beiträge: 1034
Registriert: Mi Jul 21, 2021 3:00 pm

Re: Fragen zur Mitarbeit an der SW

Beitrag von philipp123 »

tensing2 hat geschrieben: Di Sep 21, 2021 7:41 am Es fördert auch nicht grade die Motivation am Code etwas zu machen, wenn Pull-Requests für mehr als zwei Wochen ohne jeglichen Kommentar anscheinend ignoriert werden.
Das kann ich nur unterschreiben. Der PR 1559 mit der Go-e-Simulation läuft echt sauber. Ich möchte das neue Modul definitiv nicht mehr hergeben.
LP1: openWB series2 custom mit Phasenumschaltung
LP2: go-e V2
Kostal Plenticore Plus
e-up BJ 2021, SOC mit OVMS
EQB 250 BJ 2023, SOC mit Mercedes ME über Home Assistant
EVU mit Tasmato-Lesekopf auf SmartMeter
9 x Smarthome mit Shellys
grothauu
Beiträge: 79
Registriert: Do Dez 24, 2020 6:14 am
Has thanked: 1 time

Re: Fragen zur Mitarbeit an der SW

Beitrag von grothauu »

Ich persönlich habe auch eine OpenWB wegen dem OPEN gekauft und hoffe, dass diese Philosophie mit 2.0 nicht unter die Räder kommt. Die von gvz vorgebrachten Punkte sind vollumfänglich nachzuvollziehen und die Angebote eine breitere Community aufzubauen würde ich sehr begrüßen. Die E Mobilität steht erst am Anfang und gerade ein Projekt wie OpenWB hat das Potenzial gute Entwickler als Nutzer und Beitragende anzuziehen.
Der Status quo der Software ist gut hat aber in einigen Punkten durchaus Luft nach oben. Punkte wie prediction usw. löse ich derzeit durch mqtt zur Box im Rahmen meines Smarthomes inkl. weather forecast. Das ist sicher nicht Jedermanns Sache.
OpenWB s2+, ioBroker Integration, PV10kWp Fronius, Ioniq 5
tensing2
Beiträge: 103
Registriert: Di Aug 24, 2021 8:57 am

Re: Fragen zur Mitarbeit an der SW

Beitrag von tensing2 »

Gab es eigentlich mal eine offizielle Aussage, warum 2.0 im Geheimen entwickelt wird?
Ich kann es mir nur so erklären, dass der Code eben nicht mehr OpenSource sein wird. Alles andere macht doch keinen Sinn. Ob sie dann den Namen ändern?
OpenWB Custom und OpenWB Pro, 6,8kWp RCT Power Storage DC mit 5,7kWh Batterie, 3KW Hoymiles PV
gvz
Beiträge: 72
Registriert: So Sep 12, 2021 8:28 am
Wohnort: Grevenbroich

Re: Fragen zur Mitarbeit an der SW

Beitrag von gvz »

Moin, ich habe mich über die Rückmeldungen von so verschiedenen Nutzern/Aktiven gefreut und bin damit motiviert, einfach mal auf Basis des bestehenden GitHubs loszulegen!
Ich bin übrigens gerne bereit, auch PRs zu testen, wenn sie auf mein Environment zutreffen.

Ich stelle mich dann mal kurz vor:
- Georg Z., 52 Jahre, EFH, 10 kWp PV SolarEdge ohne Speicher, ID.3, Grevenbroich
- OpenWB Series 2 mit RFID und geeichtem Zähler, 16/Phase max.
- Beim FHEM Maintainer des 47_OBIS-Moduls, außerdem Hilfsarbeiter-Historie bei der alexa-fhem-Anbindung
- Integration: FHEM schreibt über MQTT die EVU und PV-Werte, dabei kommt EVU von 47_OBIS und PV von MODBUS/TCP plus Shelly, außerdem etwas mit Alexa gebastelt ("Alexa, schalte Überschussladen auf 6 (Ampere)")
OpenWB S2 (Touchscreen, RFID, Zähler, 11kW), 10 kWp PV ohne Speicher, ID.3
Antworten