openWB Forum

Hallo,
mich beschäftigen im Moment zwei Fragen:

1. Welches Modul (im Idealfall mit JSON) entspricht bereits allen Anforderungen für openWB 2.0, sodass es als Vorlage verwendet werden kann/sollte? Für das generische JSON-Modul wird auf ein PR verwiesen, aber nicht wo genau. Gibt es sonst irgendeine Form von Dokumentation/Anleitung?
2. Das Enphase Envoy (dafür würde ich das Modul erstellen) gibt mit der selben Anfrage sowohl Bezug, Erzeugung (und wenn vorhanden Batteriestatus) zurück. Es heißt aus Erfahrungen anderer Projekte, man soll maximal eine Anfrage pro Sekunde an das Gerät stellen. Es ist also nicht sinnvoll das in separate Module aufzuteilen. Ich vermute es gibt andere Wechselrichtersysteme bei denen das ähnlich ist. Was ist "best-practice" um Bezug, PV (und Batterie) in einem Modul zu kombinieren? Falls es sowas doch noch nicht gibt, meine Lösungsidee ohne die Struktur von openWB ändern zu müssen: Ein Dummy-PV-Modul das z.B. heißt "über Bezugsmodul" und nur die Aufgabe hat, die zu Einstellung setzen, das dass Bezugsmodul auch den PV-Wert in die ramdisk schreibt. Wäre das sinnvoll?

Vielen Dank
Stefan

Ok danke, das klärt Frage Nr. 2 und scheint eine saubere Lösung zu sein.

Gibt es bereits Module die diese neue Architektur nutzen? In dem Repo scheinen ja alle Module entfernt worden zu sein (mir ist nicht klar ob evu_kit ein Hilfsmodul ist oder für bestimmte Hardware). Da ist von Solaredge die Rede, das ist aber noch nicht fertig oder liegt das in irgendeinem anderen Repository?

Das EVU Kit in seiner ursprünglichen Form ist eine Hardware mit fixer IP,Port und Unit ID für den entsprechenden Zähler. Über die Zeit sind hier 3 unterschiedliche Zähler Modelle eingeflossen, vermutlich auf Grund der Verfügbarkeit.
Da die Hardware auch sonst gerne eingesetzt wird, aber die EVU Kit Module nur genau die oben genannten fixen Einstellungen erlauben, habe ich mich mal dran gemacht, die EVU Flex Module zu bauen, leider erst vor kurzem, sodass sie obsolet werden, wenn die zu V2 kompatiblen Module in den Master gemerged werden.

Aktuell ist die neue Modulstruktur noch nicht im Master, von daher würde ich warten, bis die ersten Module drin sind.

VG
Det

Die neue Struktur ist jetzt im Master, leider verstehe ich sie nicht so ganz. Es gibt dann für ein Modul (bzw. Package) eine Klasse, die aber nicht von irgendwas erbt (habe nicht viel Python-Erfahrung, aber das wäre mein Gedanke, abstrakte Klassen/Interfaces für EVU, PV, Battery, SoC etc. von denen geerbt werden kann bzw. die implementiert werden).
Wie werden die Komponenten eines Moduls/Packages definiert? Welche Funktion der Klasse wird wann aufgerufen? Wie werden die Werte gesetzt, da schreibt jetzt ja nichts mehr direkt in die ramdisk.

Viele Grüße
Stefan

In die Ramdisk wird wohl über commons/store.py geschrieben, je nach Version in die Ramdisk (1.9) oder in den Broker (v2).

Aber mehr lese ich dazu auch noch nicht raus.

VG
Det

Mittlerweile ist jetzt ein weiteres Modul hinzugekommen (Alpha ESS), leider verstehe ich den Aufbau noch nicht so ganz, der Code ist auch nicht kommentiert. Dort scheinen PV/EVU/Batterie drei getrennte Teile zu sein. Gibt es irgendeine Form von Dokumentation oder Beispiele, wie man ein Modul schreibt, dass alles in einem macht?

Viele Grüße
Stefan