Einbindung PV-Prognose und Tuning (solcast "Rooftop" API)

[aiole]

Sehe ich ähnlich. Genug features - jetzt code-Optimierung.

Allerdings hat openWB bereits den Schritt getan, mit dem sich openHAB, iobroker, FHEM usw. bis jetzt eher schwer tun.

Als gesamtheitlicher, leicht zu konfigurierender Energiemanager für:
* mehrere BEV
* unterschiedliche PV
* verschiedene Speicher
* div. Smarthomekomponenten
zu agieren.

Den Schritt wollen wir aber doch sicher nicht rückwärts gehen und das o.g. System überlassen, oder?
Von der Logik würden sie m.E. dort zwar eher hinpassen, aber wenn dort nur wenig "im Angebot" ist, macht's eben openWB direkt .

VG aiole

[LutzB]

Sehe ich ähnlich. Genug features - jetzt code-Optimierung.

Meine Meinung.

Allerdings hat openWB bereits den Schritt getan, mit dem sich openHAB, iobroker, FHEM usw. bis jetzt eher schwer tun.

Als gesamtheitlicher, leicht zu konfigurierender Energiemanager für:
* mehrere BEV
* unterschiedliche PV
* verschiedene Speicher
* div. Smarthomekomponenten
zu agieren.

Die Ansätze sind ja auch verschieden. Ein SmartHome System wird immer allgemeingültig bleiben und in der Basisinstallation niemals Regelalgorithmen für eine Wallbox mitliefern. Dafür liegt der Fokus auf der Unterstützung möglichst vieler Geräte.
OpenWB hingegen ist als autarke Lösung als Wallbox entwickelt worden. Es macht Sinn, dass die zur Regelung notwendigen Komponenten direkt angesprochen werden, um keine unnötigen Verzögerungen oder weitere Komponenten, die potentiell ausfallen können, einzubinden.
Die Frage ist nur: wo ist da die Grenze? Welche Komponenten sind essentiell für einen autarken Betrieb notwendig und was geht über den eigentlichen Einsatzzweck hinaus und ist woanders besser aufgehoben? Das sieht sicher jeder anders. Das schöne bei offener Software ist doch, dass prinzipiell jeder sein gewünschtes Feature selber implementieren kann.

Den Schritt wollen wir aber doch sicher nicht rückwärts gehen und das o.g. System überlassen, oder?
Von der Logik würden sie m.E. dort zwar eher hinpassen, aber wenn dort nur wenig "im Angebot" ist, macht's eben openWB direkt .

Ein wichtiges Argument von Kevin ist immer, dass er potentiell für alle Features bei den verkauften Wallboxen Support leisten muss. Damit hat er leider Recht, da doch sehr viele Anwender (zu Recht) verlangen, dass ein gekauftes Produkt doch bitte auch zu funktionieren hat. Mit der Code-Optimierung, sollte daher eine Plugin-Schnittstelle geschaffen werden und die einzelnen Module, Komponenten, Regelalgorithmen, etc. dorthin ausgelagert werden. Wenn das umgesetzt ist, kann man unterscheiden zwischen "offiziell unterstützten" Modulen und weiteren, die etwas als "Beta" oder "Community Supported" eingestuft werden. Jeder kann dann auswählen, was er davon nutzen möchte und der Support von Kevin bleibt auf die offiziellen Module beschränkt.

Nur mal so als Idee. Es wurde ab und zu schon von "die 1.8 kann das dann" gesprochen. Gibt es zur 1.8 schon Infos? Ich würde mich gerne intensiver mit der Entwicklung beschäftigen, hänge jedoch etwas in der Luft, da ich keine Ahnung habe, was geplant ist und wie detailliert der Fahrplan schon steht.

Gruß,
Lutz

p.S.: Ich denke, die Diskussion gehört nicht mehr hier hin und sollte in einem eigenen Thread besprochen werden. Kann ein Moderator vielleicht die entsprechenden Beiträge verschieben?

[liZErd]

Bevor hier geschlossen/verschoben wird muss ich auch noch meinen Senf dazu geben.

Ich bin (zwar nur als Nutzer, Feedbackschreiber und gelegentlich Tester) von Anfang an dabei und kann meinen Vorrednern zu 100% zustimmen. Das System in dieser Form ist sowohl im Unterbau mit den ganzen Modulen/MQTT/... als auch in der Anwendung mit den ganzen Einstellungen schon recht komplex, und selbst als Nutzer muss man ziemlich genau wissen was man tut und wie alles (grob) funktioniert. Die Stärke von openWB ist, dass sie als unabhängige Wallbox mit integrierten Smart-Funktionen funktioniert, mit der Möglichkeit über die API an übergeordnete Managementsysteme angebunden zu werden. Dazu sind einige grundlegende Regelfunktionen und vielleicht auch das eine oder andere smarte Add-On Feature nötig, im Grunde geht es aber darum, dass die zur Wallbox-Funktion benötigten Module zuverlässig funktionieren.

Meiner Meinung nach sollten sich möglichst viele Kombinationen an PV-Installationen (samt Speicher und ggf. anderen Erzeugern) abbilden lassen. In einem wirklich modularen Ansatz könnte man damit die openWB auch mit sehr "exotischen" Kombinationen ins Laufen bringen (Stichwort mehrere Speicher, die sich dann einfach einstellen ließen. Oder auch mehrere PV-Anlagen, wie im Forum gerade aktiv diskutiert wird), indem man einfach entsprechende zusätzliche Module konfiguriert.

[aiole]

Bevor hier geschlossen/verschoben wird muss ich auch noch meinen Senf dazu geben.

Jup - das Thema bekommt noch einen eigenen Titel.

Ich bin (zwar nur als Nutzer, Feedbackschreiber und gelegentlich Tester) von Anfang an dabei und kann meinen Vorrednern zu 100% zustimmen. Das System in dieser Form ist sowohl im Unterbau mit den ganzen Modulen/MQTT/... als auch in der Anwendung mit den ganzen Einstellungen schon recht komplex, und selbst als Nutzer muss man ziemlich genau wissen was man tut und wie alles (grob) funktioniert. Die Stärke von openWB ist, dass sie als unabhängige Wallbox mit integrierten Smart-Funktionen funktioniert, mit der Möglichkeit über die API an übergeordnete Managementsysteme angebunden zu werden. Dazu sind einige grundlegende Regelfunktionen und vielleicht auch das eine oder andere smarte Add-On Feature nötig, im Grunde geht es aber darum, dass die zur Wallbox-Funktion benötigten Module zuverlässig funktionieren.

Meiner Meinung nach sollten sich möglichst viele Kombinationen an PV-Installationen (samt Speicher und ggf. anderen Erzeugern) abbilden lassen. In einem wirklich modularen Ansatz könnte man damit die openWB auch mit sehr "exotischen" Kombinationen ins Laufen bringen (Stichwort mehrere Speicher, die sich dann einfach einstellen ließen. Oder auch mehrere PV-Anlagen, wie im Forum gerade aktiv diskutiert wird), indem man einfach entsprechende zusätzliche Module konfiguriert.

Ja - deshalb sehe ich oWB mittlerweile als gesamtheitliche Managmentzentrale für ENERGIE. Solange die Schnittstellen passen, ist das m.E. eine sehr gute Wahl, denn die anderen Smarthomesysteme können ja trotzdem interagieren.

VG aiole

[hominidae]

@hominidae
[...]
Was dagegen sicher hilfreich wäre ist, wenn Du den code selbst vorbereitet, so dass nur noch Anpassarbeiten nötig sind.
Jeder der Entwickler hat hier sein Spezialgebiet. Du bist dann "Mr. PV-Prognose". Wenn Du Dich mit Node-Red auskennst und Dir das feature sehr wichtig ist, dann baue diese Lösung dort erstmal lauffähig vor. Danach kannst Du sie mit Unterstützung der SW-Gurus hier in oWB implementieren.

VG aiole

...so, mal als erste Info für Euch, die Umsetzung.

Ich habe in Node-Red zwei Teile gebaut:

• Ein Flow zum Absaugen der aktuellen PV-Einspeisung und umwandlen in die Messwerte zum PV-Tuning des RoofTop-Accounts (Measurements)
• Ein Flow zum Abfragen der aktuellen Vorhersagen

Es dauert etwa 10 Tage, nach dem ersten Senden von Messdaten, bis solcast das erste mal ein PV-Tuning durchführt.




Als Datenquelle dient die openWB, allerdings nur indirekt über die Toolchain Telegraf/InfluxDB, von hier: viewtopic.php?f=6&t=629
Damit kann man die für die Measurements geforderten Daten passend bereitstellen und in Node-Red abfragen, sowie die von Solcast abgefragten Vorhersage-Werte gleich einspeichern und visualisieren.

In der Influx-DB...sieht es auch gar nicht so schlecht aus.
Zum Beispiel, für HEUTE und den Rest der Woche:



...oder die vergangene Woche:



...oder nur heute:



...ich finde Werte zeigen, dass das Tuning von solcast sehr funktioniert.
Ich habe eine PV mit ziemlich exakter Aufteilung Ost/West.
Da der Roofftop Account nur eine Anlage simulieren kann, habe daher eine Anlage in Süd-Ausrichtung konfiguriert.
Durch die Measurements hat solcast dann gelernt, wie sie tatsächlich "funktioniert".

....so sieht jetzt mein OpenWB-Dashboard auf Grafana aus:



...es wäre jetzt ein Leichtes, die Solcast Werte (zB Tageswert - DailyYield oder Forécasts der jeweils nächsten 7 Tage als Werte im mqtt-Broker der openWB einzuliefern.
Bei Interesse poste ich die Node-Red Flows und Grafana - Dashboards gerne mal in einem extra fred inn der "Wissenssammlung".

LG,
hominidae

[aiole]

Jo - kannst Du gern machen. Ohne Anleitung werden sich vermutlich nicht so viele damit beschäftigen, aber wenn Du den neuen Faden fütterst, kann etwas daraus werden.
VG aiole

[hominidae]

...die Anleitung ist hier: https://discourse.nodered.org/t/power-f ... fana/28037

[dmq]

Danke Dir für deine Arbeit.

Haben die die Bedingungen währendessen bereits angepasst?

"10 API requests per site per day"

Das wird wahrscheinlich ähnlich laufen wie die Übernahme von Dark Sky durch Apple Aber es kommen bestimmt auch weitere Quellen.

Sobald ich die OpenWB habe, schaue ich mir das hier auch noch einmal näher an - node-red, Grafana etc. ist alles soweit im Einsatz.

Aber vom Prinzip bin ich auch Anhänger der UNIX Philosophie: "Do One Thing and Do It Well" (Ref.: https://en.wikipedia.org/wiki/Unix_phil ... Do_It_Well)

[hominidae]

Nein, es sind tatsächlich wohl immer noch 20 Anfragen/Tag beim rooftop/hobbyist Account.

Die 10x stehen (standen auch bei mir vor 3 Monaten) auf der Informationsseite...beim anmelden findet man es dann.
Du hast die ersten 3 Monate 1000x API-Anfragen in beliebiger Verteilung frei, danach 20x pro Tag.
Die Lieferung der Messwerte (measurements) zurück, für das PV Tuning über die APi wird in das Kontingent nicht mitgezählt.

Es funktioniert bei mir sehr gut. Das PV-Tuning für meine Anlage liegt so bei 95%.
1-2 API-Anfragen pro Tag schlagen mal fehlt...der Versuch wird aber wohl in das Kontingent mit reingezählt.
Ich habe in den Beispielen im node-red die Fehlversuche abgefangen...Counter/Zähler zur Übersicht eingebaut und einen Flow gebaut, der es erlaubt innerhalb zweier Zeitstempel (zB Sonnen-Auf/-Untergang) ein definierbare Zahl äquidistanter Abfragen zu machen.
Die sind bei mir auf 5x "estimates" und 10x "forecasts" eingestellt und ich bleibe bislang, inkl. Fehlversuche immer unter 20.
Measurements sende ich jede Stunde.

Es kommt auf den UseCase an...manche brauchen/wollen wohl auch nichtmal die 10 Anfragen, wie man im slocast-forum mitliest.

[dmq]

Ok, danke für den Hinweis. Ich schaue mir das mal näher an.