Geräte, Wechselrichter, E-Auto flexibler

[drbacke]

Die Klassen sollten in Zukunft austauschbar sein. Bspw. sollte es einen Generic Inverter geben, mit dem von mir beschriebenen Verhalten. Es wäre aber auch denkbar, dass wir in Zukunft unterschiedliche Wechselrichter einfügen. Bei den Prioritäten (Load, PV usw.) aber auch im generellen Verhalten können hier Unterschiede bestehen. Genauso mit den E-Autos und Geräten. Bei Haushaltsgeräten wäre es auch denkbar, dass man mehrere generische Haushaltsgeräte mit Verbrauch / Verbrauchsprofil einfügt und dann erst im Nachgang eine Liste mit konkreten Geräten anlegt, wo die Werte dann festgelegt werden.
Der Punkt kann gut in Subbranches aufgeteilt werden.

[apetersson]

DIe Abstraktion vieler Geräte ist die Kernaufgabe von iobroker. Ev wäre es ein quick-win die Kompatibilität vorerst via iobroker simple http interface zu ermöglichen, zumindest in meinem Haushalt wäre das ideal

[drbacke]

Ich denke, dass ist ein ganz anderes Problem.

[aperiodicchain]

Ich denke, das Projekt sollte sich hier (und am Besten recht bald) auf ein design pattern festlegen damit das nicht sofort in Kraut und Rüben ausartet und das auch gleich so implementieren als Referenz.

Beispielsweise kann es eine abstract base class Inverter geben mit Standardmethoden, die ein WR üblicherweise hat, und GenericInverter als erste Implementierung dieser ABC (so dass das EOS ohne Weiteres funktioniert).

Da es ja erwünscht ist, dass neue Entwickler relativ leicht "ihren neuen Inverter/EV/WP/..." zum Projekt hinzufügen können, schlage ich das Strategy pattern vor, initial etwas Mehraufwand, dann aber relativ leicht anpassbar and neue (viele!) Geraete.

PS: es sollten auch type hints benutzt werden jetzt wo es noch nicht soviel Aufwand bedeutet mMn :)

[drbacke]

Dann ran an den Code. Gute Tipps helfen hier wenig, es benötigt Entwickler

[dlips]

Hi, ich habe mal ein bisschen brain storming gemacht wie so ein dynamisches Plugin System aussehen koennte, siehe mein repo hier https://github.com/dlips/plugin_system_draft

Die verschiedenen Komponenten/Plugins werden von einer PluginRegistry geladen und koennen anschliessend ueber eine PluginFactory erstellt werden. In dem Beispiel kann man die Komponenten in einem yaml File aufsetzen und dort auch die komponentenspezifische Konfiguration hinterlegen. Jede Komponente hat eine Id, somit kann es z.B. auch mehrere Batterien, PV Anlagen usw. im System geben. Je nach dem was man fuer sein eigenes System braucht.

Ich habe noch einige Fragezeichen wie die Schnittstelle zwischen EMS und Plugins/Komponenten aussehen kann. Bisher habe ich schon einmal zwei Arten von Vorhersagen gefunden. Einmal gibt es statische Vorhersagen wie z.B. Wetter, Temperator, PVErtrag, Dynamischer Strompreis, welche von Ausserhalb kommen und sich waehrend eine Optimierungsdurchgangs nicht aendern. Dann gibt dynamische Modelle, ueber die wir innerhalb des Systems die Kontrolle haben und Ziel der Optimierung sind. Die dynamischen Vorhersagen nutzen als Input die statischen Vorhersagen und eine Kontrollstrategie, welche z.B. bestimmt wann der Batteriespeicher oder das E-Auto geladen wird oder wann die steuerbaren Haushaltsgeraete anspringen. Die Kontrollstrategie ist dann was der Algorithmus minimiert. Bei der Abstraktion der Kontrollstrategie gibt es bei mir noch die Groesste Verwirrung. Zum einen gibt es Geraete die sich zu einem Bestimmten Zeitpunkt einschalten und dann laufen ohne abgeschaltet zu werden. Es gibt Geraete wie der Batteriespeicher, welche flexible ein- und ausgeschaltet werden koennen und dann gibt es sicherlich noch Geraete welche sich kontinuierlich ansteuern lassten. Wie man das am Besten unter einen Hut bringt, da habe ich noch keine Ahnung.

Ok, das war jetzt viel bla bla. Was haltet ihr generell von der Idee eines flexible Komponenten/Plugin Systems?