76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[klaus.schauer]

Wie 300P schon eingeschätzt hat, wäre die tatsächliche Anzahl der benutzten Phasen relevant.
Für die KI ist die Korrelation zwischen der Phasenanzahl und der Leistung pro Zeiteinheit der relevante Zusammenhang.
Für die Prognose ist dann die Projektion der verwendeten Phasen in die nächsten Stunden von gewisser Relevanz. Aber es gibt natürlich noch mehr Werte. Die Phasenanzahl wird eine Unterstützungsfunktion haben und nicht die höchste Relevanz.

Ich frage mich seit einiger Zeit, ob all die vielen und immer mehr werdenden Eingangswerte für die KI nicht des Guten zu viel werden? Die Phasenanzahl ist dafür ein gutes Beispiel. Der Verlauf der angeforderten Leistung mag neben der eingespeicherten Energie noch sinnvoll sein. Der Parameter Phasenanzahl ist völlig überflüssig!

Zudem gibt es inzwischen Wallboxen z. B. Elli, die dem Fahrzeug die AC-Ladeleistung auch unter 1400 W stufenlos vorgeben können. Das Fahrzeug muss dazu die entsprechenden Protokolle nach ISO 15118‑20 unterstützen. Die Phasenanzahl lässt sich bei der Elli-Wallbox auch nur auf dem Umweg über die Auswertung der Phasenströme ermitteln.

[DS_Starter]

Moin,

Der Verlauf der angeforderten Leistung mag neben der eingespeicherten Energie noch sinnvoll sein. Der Parameter Phasenanzahl ist völlig überflüssig!

Nicht ganz. Für eine zukünftige Abschätzung Energieaufnahme pro Stunde kann es sinnvoll sein zu wissen, welche Energie in der Vergangenheit pro Stunde unter Verwendung von wieviel Phasen aufgenommen wurde. So kann bei der Inferenz auf Grundlage der aktuell (dynamisch) eingestellten Phasenanzahl auf die max. mögliche Energieaufnahme pro Zeiteinheit geschlossen werden.
Zumindest theoretisch.

Die Phasenanzahl lässt sich bei der Elli-Wallbox auch nur auf dem Umweg über die Auswertung der Phasenströme ermitteln.

Wo es nicht geht, lässt man es einfach weg.

Ich frage mich seit einiger Zeit, ob all die vielen und immer mehr werdenden Eingangswerte für die KI nicht des Guten zu viel werden?

Bis jetzt sind diese Eingangswerte sinnstiftend.
Bezüglich der Phasen wird man sehen. Zunächst werden die Daten nur gesammelt um sie später im Training/Inferenz verwenden zu können.
Dann wird sich zeigen ob sie hilfreich sind. Wenn nicht, ist es kein Problem sie nicht zu verwenden.

[Wolle02]

@Wolle02,

Seit ein paar Tagen stelle ich bei mir ein komisches Verhalten der realen Consumerwerte fest.

Das ist ein berechneter Wert aus den ganzen Wertequellen. Zusammensetzung im Wiki beschrieben.

Um nicht raten zu müssen, wäre es gut in der Nacht mal ein Debug collectData aufzuzeichen.
Dann sieht man die Eingangswerte und kann es nachrechnen.

Vermutlich gibt es einen Geisterwert "die Batterie lädt" und entzieht so dem Haus Energie die eigentlich Verbrauch darstellt. Es wäre eine mögliche Erklärung.

Moin Heiko,

ich habe jetzt letzte Nacht mal collectData laufen lassen und hänge das Log mal an; ebenso die Con-Grafik von heute Nacht.
Wenn ich das richtig interpretiere liegt die Anzeige des niedrigen Verbrauchs an der geringen festgestellten BatOut-Energie, z.B. um 04:59:42 Uhr von 50 Wh, was zu EnergyConsumption result -> 61 Wh führt. Das ist natürlich viel zu wenig und auch seltsam, weil im Log gleichzeitig current Power Battery (all) -> BatIn: 0 W (Node2Inv2DC: 0 W), BatOut: 454 W (DC2Inv2Node: 0 W) festgestellt wird, also 454 W. Dieser Wert entspricht von der Größe her auch der Realität.
In dem Zusammenhang habe ich festgestellt, dass die specialReadings

Code Auswählen Erweitern

special_todayBatIn_01
689.1 Wh

special_todayBatOut_01
458.5 Whnicht stimmen. Bis aktuell wurden 7 kWh in die Batterie geladen und nicht knapp 690 Wh.
Kann man den Grund auch irgendwo im Log sehen?

[alkazaa]

Hallo zusammen,

wie angekündigt, hatte ich heute meinen ersten produktiven Lauf mit der Implementierung des Ladecontrollers nach dem Konzept von Parallix (bereits in #5467 und in #5199 von ihm aufgezeigt).
....
Ich würde mich freuen wenn Parallix sich das Ganze auch mal anschaut.

Ich hatte schon vor einer Weile die Parallix-Methode als DOIF implementiert (bin aber noch in der Beobachtungsphase).
Hardware ist ein Fronius GEN 24 und eine BYD HVS Batterie. Die MaxCellVoltage wird alle 10 sec von der Batterie per modbus geliefert. Die schnelle update Rate ist wichtig, um auf das Ausbrechen der max. Zellspannung möglichst schnell zu reagieren.

Jetzt wollte ich das ganze innerhalb einer userFn umsetzen. Die wird aber bei mir nur alle 30 sec aktiv (asynchron=1 bei den relevanten devices). Und sowas wie das DOIF-Konstrukt [reading:device], mit dem das DOIF getriggert wird, gibt es in den userFn Routinen nicht, oder?

Müsste man nicht im setupBatteryDevXX einen key maxCellVolt=device:reading haben, um auf schnelles Ausbrechen der max. Spannung reagieren zu können?

-Franz

[DS_Starter]

@Wolle02,

der Wert von BatOut korreliert mit dem Stunden-Reading Today_HourXX_BatOut_XX.
Dieser Wert wiederum errechnet sich aus den gelieferten Daten des Readings im Schlüssel:

Code Auswählen Erweitern

setupBatteryDevXX->outtotal
Hier wäre anzusetzen. Dieser Wert muß ein stetig aufsteigender Zähler sein. Ein clear oder Rücksetzen zwischendurch wird zwar vom Modul toleriert, aber das führt dann zu dem von dir beobachteten Verhalten. Außerdem gibt es Protokollierungen im Log.
Weiterhin muß der Wert natürlich den richtigen Sachverhalt wiedergeben. Möglicherweise steigt er bei dir nicht so wie es die Realität ist.

Das deckt sich mit deinen Beobachtungen bzgl. specialReadings. Ich vermute es gibt 0-Resets wegen der Verletzung "stetig steigender Zähler".

LG,
Heiko

[DS_Starter]

Hallo Franz,

Jetzt wollte ich das ganze innerhalb einer userFn umsetzen. Die wird aber bei mir nur alle 30 sec aktiv (asynchron=1 bei den relevanten devices). Und sowas wie das DOIF-Konstrukt [reading:device], mit dem das DOIF getriggert wird, gibt es in den userFn Routinen nicht, oder?

Der Schlüssel asynchron=1 ist die einzige eingebaute Möglichkeit die SF-Schleife außerhalb von interval anzustarten.
Unter dem Aspekt ist es effektiver ein DOIF oder notify nach einem Batteriezellen-Event zu nutzen um die Sub anzustarten.

Müsste man nicht im setupBatteryDevXX einen key maxCellVolt=device:reading haben, um auf schnelles Ausbrechen der max. Spannung reagieren zu können?

Ja, wenn ich diese Technologie innerhalb von SF umsetzen würde. Allerdings wird nicht jeder User die Möglichkeit haben separate Zellenspannungen zu liefern.
Und dann ist da noch das Thema der Reaktionszeit auf eine geänderte Zellenspannung wie du schon geschrieben hast. Alles Fragen, die vor einem Einbau beantwortet werden müssen.

Man könnte z.B. die maximale Zellenspannung mit einem notify extern berechnen lassen sobald eine geänderte Zellenspannung mitgeteilt wird (bei mir sind es 135 Zellen) und diesen Max-Wert als userReading im BatterieDevice mit Event eintragen. Ist setupBatteryDevXX->asynchron=1 gesetzt, wird die SF-Schleife getriggert und kann den Wert auslesen sofern ich das implementiert habe (was noch nicht der Fall ist). Dann könnte SF diesen Technologie intern abbilden, weil nur ein Wert per Reading gelesen werden muß und dieser Wert unmittelbar den Max-Wert darstellt.

LG,
Heiko

[Wolle02]

@Wolle02,

der Wert von BatOut korreliert mit dem Stunden-Reading Today_HourXX_BatOut_XX.
Dieser Wert wiederum errechnet sich aus den gelieferten Daten des Readings im Schlüssel:

Code Auswählen Erweitern

setupBatteryDevXX->outtotal
Hier wäre anzusetzen. Dieser Wert muß ein stetig aufsteigender Zähler sein. Ein clear oder Rücksetzen zwischendurch wird zwar vom Modul toleriert, aber das führt dann zu dem von dir beobachteten Verhalten. Außerdem gibt es Protokollierungen im Log.
Weiterhin muß der Wert natürlich den richtigen Sachverhalt wiedergeben. Möglicherweise steigt er bei dir nicht so wie es die Realität ist.

Das deckt sich mit deinen Beobachtungen bzgl. specialReadings. Ich vermute es gibt 0-Resets wegen der Verletzung "stetig steigender Zähler".

LG,
Heiko

Ja, danke für den Fingerzeig. Es scheint am ModbusAttr Device zu liegen mit dem ich die BYD Batterie auslese. Hier scheinen die Werte, die von der Batterie kommen nicht zu stimmen. Warum auch immer.

[DS_Starter]

In meinem contrib liegt wieder ein Update der V 2.9.5.

- BEV Batteriedaten werden auch bei nicht aktivierten BEV-Consumer gespeichert
- Logausgabe des ausgeführten set reset Befehls zum Datenspeicher Management vor Ausgabe der Ergebnisse
- neuer Debug Modus aiData_long
- Verringerung der Log Frequenz bei Debug aiData und aiData_long
- List pvCircular, pvHistory um BEV accum_csmXX_<mode>_wseconds bzw. BEV csmXX_<mode>_points erweitert
- List pvHistory, aiRawData um Anzeige bevcsmPhasesXX erweitert
- vollständige Pipeline-Integration (Training + Inferenz) für die BEV opmode-Fraktionen 'auto' und 'prio' -> Retraining bei Verwendung bev-Flag nötig!
- bev-Consumer: Aufzeichnung der zum Laden verwendete Anzahl Phasen – reine Rohdatenerfassung für später
- NEU: neuer Get-Befehl 'stepTimes' zur detailliierten Anzeige von Phasenzeiten
- Model VictronKiAPI: Fix fehlenden success-Status in Victron VRM API Forecast Response wenn vorher Response fehlerhaft war
- weitere kleinere Patches

Neu ist ein Getter "get ... stepTimes".
Bis jetzt konnte man sich die Zeit ausgeben lassen, die ein SF-Zyklus benötigt.
Nun zeigt dieser Getter die Zeitbestandteile jeder relevanten Teilfunktion aufgeschlüsselt. Die Ausgabe kann man nach verschiedenen Spalten sortiert erstellen lassen.

In dem Beispiel ist zu erkennen, dass die meiste Zeit für das Generieren der Readings verwendet wird, gefolgt von getRoofTopData, dem Abruf und Verarbeitung der Strahlungs-API.

LG,
Heiko

[300P]

AHA - Den Übeltäter bei mir gefunden....

Ich weiß garnicht was da so bei mir in den Sternen alles so gelesen werden soll.... 

[DS_Starter]

Ich weiß garnicht was da so bei mir in den Sternen alles so gelesen werden soll....

Das sind die aktuellen Sonnenpositionen, Azimut und Altitude zzgl. Mondphasen.

Das ist offensichtlich rechenintensiv.
Mal sehen ob ich das cachen kann, ob es machbar ist.

[alkazaa]

Der Schlüssel asynchron=1 ist die einzige eingebaute Möglichkeit die SF-Schleife außerhalb von interval anzustarten.
Unter dem Aspekt ist es effektiver ein DOIF oder notify nach einem Batteriezellen-Event zu nutzen um die Sub anzustarten.

Ja, dann werde ich erstmal beim DOIF bleiben.
Da das System (Fronius GEN24 - BYD HVS) recht weit verbreitet zu sein scheint, werde ich meine Umsetzung bei Gelegenheit mal ins Forum stellen.
Z.B. in diesem "eingeschlafenen" thread. Der scheint mir gut dafür geeignet, auch um diesen hier nicht zu überfüllen.

Ja, wenn ich diese Technologie innerhalb von SF umsetzen würde. Allerdings wird nicht jeder User die Möglichkeit haben separate Zellenspannungen zu liefern.

Für die BYD HVS kommt man per ModbusAttr leicht an die Zellspannungen (inkl. maxVolt-Wert), falls der Solarteur die Batterie per LAN mit dem Hausnetz verbunden hat. Ist zwar nicht überall der Fall, wie ich vom System bei meinem Nachbarn weiß, kann man aber leicht nachrüsten.