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