Leistungsprognose für Wechselrichter

[CaptainHook]

Moin Heiko, Moin Christian,

lustig, dass ihr beiden hier schreibt. Ich habe letztens schon versucht die KI von Christian in Heikos Modul "einzubauen".
Dazu habe ich die Skripte von Christian leicht angepasst um z.B die Werte von Today_HourXX_PVreal zu nutzen statt die Werte aus Wechselrichter und DC Batterie Ladung zu verrechnen usw. Zudem lass ich die Ergebnisse der KI in ein in ein Dummy Device schreiben.


Ferner hab ich das Modul von Heiko erweitert um ein weiteres "currentRadiationDev" ähnlich dem von DWD, nur ließt dieses die Werte aus dem Dummy und rechnet nichts.

Vorteil aus meiner durch das DBRep-Device läuft der KI-Teil non-Blocking (korrigiere mich wenn ich falsch liege).

Bei Interesse kann ich gerne genaueres Erklären oder die Anpassungen zur Verfügung stellen.

Viele Grüße,
Stephan

[ch.eick]

@ch.eick,
3 Minuten Laufzeit wäre im FHEM Kontext schon deutlich zu lang weil FHEM ohne Nebenprozess dann so lange blockieren würde. Allerdings wird hier alles im RAM, also deutlich schneller, ausgeführt. Wir werden sehen wie sich das Ganze ausspielt, aber vermutlich werde ich noch auf BlockingCall umstellen. Dann sind wir auf der sicheren Seite. Gerade wenn ein nicht so leistungsfähiger Server eingesetzt wird.

Die DbRep Auswertung ist ja nonblocking und läuft als MySQL procedure in der Datenbank. Auf meinem RPI4 ist dann zwar 100% CPU und auch fast 100% RAM usage, FHEM läuft jedoch weiter.
Wie das mit dem Python Call ist kann ich nicht wirklich sagen, ich stelle jedoch zum Zeitpunkt der Ausführung keine hänger im FHEM fest.
Hier mal meine FHEM Definition für die KI Prognose

Code Auswählen Erweitern

defmod LogDBRep_PV_KI_Prognose DbRep LogDB
attr LogDBRep_PV_KI_Prognose DbLogExclude .*
attr LogDBRep_PV_KI_Prognose allowDeletion 0
attr LogDBRep_PV_KI_Prognose comment Version 2023.02.23 12:00\
\
Hier wird die Vorbereitung für die KI PV-Leistungsprognose durchgeführt\
\
sqlCmd call dwd_load(curdate(),'none');;\
[none|show] zum Anzeigen des Ergebnisses\
\
executeAfterProc:\
<absoluter Skript Name> <DbLog IP-Adresse> <FHEM IP-Adresse> <DbRep Name> <Wechselricher Name> <Prefix Reading Name>
attr LogDBRep_PV_KI_Prognose executeAfterProc "/opt/fhem/python/bin/PV_KI_Prognose.py 192.168.178.40 192.168.178.40 LogDBRep_PV_KI_Prognose WR_ctl Yield_fc"
attr LogDBRep_PV_KI_Prognose room System
attr LogDBRep_PV_KI_Prognose verbose 3

Für die Zukunft werde ich zumindest erstmal die MySQL Datenbank auf mein NAS verlagern.

[ch.eick]

Moin Heiko, Moin Christian,

lustig, dass ihr beiden hier schreibt. Ich habe letztens schon versucht die KI von Christian in Heikos Modul "einzubauen".
Dazu habe ich die Skripte von Christian leicht angepasst um z.B die Werte von Today_HourXX_PVreal zu nutzen statt die Werte aus Wechselrichter und DC Batterie Ladung zu verrechnen usw. Zudem lass ich die Ergebnisse der KI in ein in ein Dummy Device schreiben.


Ferner hab ich das Modul von Heiko erweitert um ein weiteres "currentRadiationDev" ähnlich dem von DWD, nur ließt dieses die Werte aus dem Dummy und rechnet nichts.

Vorteil aus meiner durch das DBRep-Device läuft der KI-Teil non-Blocking (korrigiere mich wenn ich falsch liege).

Bei Interesse kann ich gerne genaueres Erklären oder die Anpassungen zur Verfügung stellen.

Viele Grüße,
Stephan

Es ist doch immer gut, wenn man zusammen arbeitet. Die ursprüngliche Prognose, vor dem Modul, ist ja mal aus meinem Skript gekommen. Ich habe mich dann nur wieder raus genommen, da ich DbLog basiert arbeite und keine externen Dienste für die Prognosen verwenden möchte. Dann kam die KI Prognose und ich konnte die manuelle Berechnung verlassen.

Ob alles im DbRep nonblocking ist weiß ich nicht so wirklich, da zum Schluss ja noch das Python Skript über executeAfterProc ausgeführt wird.

Die Synchronisierung mit weiteren FHEM Devices erforgt dann über das reading PV_KI_Prognose, was jeweils einen Event erzeugt.

[ch.eick]

Dazu habe ich die Skripte von Christian leicht angepasst um z.B die Werte von Today_HourXX_PVreal zu nutzen statt die Werte aus Wechselrichter und DC Batterie Ladung zu verrechnen usw.

Hier muss man halt darauf achten, wie der PV Ertrag ausgewiesen wird. Bei Kostal, mit Hochvolt Accu, wird der Accu erst beim entladen in den Ertrag gerechnet und beim Laden fehlt er dann. So passiert es, dass der Ertarg erst am folgetag erscheint, bzw. die ganze Nacht als Ertrag ausgewiesen wird.

[DS_Starter]

@Stephan,

Bei Interesse kann ich gerne genaueres Erklären oder die Anpassungen zur Verfügung stellen.

Natürlich, ich nehme Anregungen gerne entgegen und versuche sie, wenn möglich, allgemeingültig umzusetzen.
Manchmal ist es zu speziell und baue dann eine Schnittstelle für enhanced FHEM-User ein. 
Ich schaue hier die nächsten Tage bestimmt immer mal rein. 

Code Auswählen Erweitern

Ob alles im DbRep nonblocking ist weiß ich nicht so wirklich, da zum Schluss ja noch das Python Skript über executeAfterProc ausgeführt wird.
Ja, alles mit "Set". Aktivitäten in den Attr wie executeAfterProc, executeBeforeProc etc. sind von der Implementierung des ausgeführten Codes abhängig. Aus DbRep-Sicht also unbestimmt.

@Christian,
mit welchen Parametern fütterst du momentan die KI?
Ich verwende zur Zeit PVReal, Bewölkung, Regen, Temperatur, Strahlung und die Stunde des Tages als Input zum Training.

[CaptainHook]

Hier muss man halt darauf achten, wie der PV Ertrag ausgewiesen wird. Bei Kostal, mit Hochvolt Accu, wird der Accu erst beim entladen in den Ertrag gerechnet und beim Laden fehlt er dann. So passiert es, dass der Ertarg erst am folgetag erscheint, bzw. die ganze Nacht als Ertrag ausgewiesen wird.

ja, danke für den Hinweis. Im Modul 76_SolarForecast sollte das im Reading Today_HourXX_PVreal den zur Stunde erzeugte PV Ertrag enthalten.

Diesen nutzte ich im SQL Script als Grundlage für den Teil '-- yield from Plenticore with Accu'

Bei mir ist der PV-Wechselrichter und Batterie Wechselrichter getrennt (AC Kopplung) daher sollte das zumindest bei mir so passen.

Mir gefällt, dass das Modul 76_SolarForecast so modular aufgebaut ist und man alles problemlos konfigurieren kann.

Die KI Lösung von dir habe ich mehr oder weniger erst durch Zufall gefunden, da ich mich gerade sowohl beruflich als auch privat mit KI beschäftige und angefangen hatte selbst etwas in der richtig zu erstellen.

Und leider habe ich die Anleitung im Wiki und in dem Thread ab Hier nicht zu 100% verstanden. Aber am Ende lief es

[DS_Starter]

@Stephan,

Ferner hab ich das Modul von Heiko erweitert um ein weiteres "currentRadiationDev" ähnlich dem von DWD, nur ließt dieses die Werte aus dem Dummy und rechnet nichts.

Kurzer Hinweis. Ich habe vor den aktuellen Setter und Reading "currentRadiationDev" in "currentAPI" umzubauen weil es der Weiterentwicklung angemessen ist. Später kommt dann "currentRadiationDev" in einem neuen Kontext, so wie du jetzt bereits umgesetzt hast, wieder dazu.
Da diese Änderungen aber automatisch vorgenommen werden ohne dass der User eingreifen muss, würde deine Anpassung verloren gehen.
Ich schlage vor du benennst dein zusätzliches "currentRadiationDev" irgendwie um, damit du bei einem späteren Update nicht auf die Nase fällst.

LG

[ch.eick]

Code Auswählen Erweitern

Ob alles im DbRep nonblocking ist weiß ich nicht so wirklich, da zum Schluss ja noch das Python Skript über executeAfterProc ausgeführt wird.
Ja, alles mit "Set". Aktivitäten in den Attr wie executeAfterProc, executeBeforeProc etc. sind von der Implementierung des ausgeführten Codes abhängig. Aus DbRep-Sicht also unbestimmt.

Im Python lese ich dann nur die MySQL Datenbank, die vorher einen neue Tabelle erstellt hat.
Danach gibt es nur noch setreadings zum FHEM um dort zu synchronisieren und den jeweiligen Verarbeitsschritt mitzuteilen.

Somit sollte das komplett nonBlocking sein. Nur die CPU und RAM Auslastung wäre bei einem RPI4 am Limit, was man mit dem Verlagern der DbLog (im Docker) verbessern kann. Auch das KI Prognose Skript könnte man extern vom FHEM ausführen, da es ja direkt aus der MySQL liest.

@Christian,
mit welchen Parametern fütterst du momentan die KI?
Ich verwende zur Zeit PVReal, Bewölkung, Regen, Temperatur, Strahlung und die Stunde des Tages als Input zum Training.

Ich erstelle eim DbLog eine Tabelle, die ich dann aus dem Python in die KI einlese.

Code Auswählen Erweitern

CREATE TABLE IF NOT EXISTS `dwdfull` (
  `TIMESTAMP` datetime NOT NULL,
  `year`   int NOT NULL,
  `month`  int NOT NULL,
  `day`    int NOT NULL,
  `hour`   int NOT NULL,
  `TTT`    float  NOT NULL DEFAULT 0,
  `DD`     float  NOT NULL DEFAULT 0,
  `VV`     float  NOT NULL DEFAULT 0,
  `N`      float  NOT NULL DEFAULT 0,
  `Neff`   float  NOT NULL DEFAULT 0,
  `R101`   float  NOT NULL DEFAULT 0,
  `RRS1c`  float  NOT NULL DEFAULT 0,
  `SunD1`  float  NOT NULL DEFAULT 0,
  `Rad1h`  float  NOT NULL DEFAULT 0,
  `SunAz`  float  NOT NULL DEFAULT 0,
  `SunAlt` float  NOT NULL DEFAULT 0,
  `yield`  float  DEFAULT 0,
  `yield_max`  float  DEFAULT 0,
  `forecast`  float  NOT NULL DEFAULT 0,
  PRIMARY KEY (`TIMESTAMP`),
  INDEX (`TIMESTAMP`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin COMMENT='DWD Forecast';
Hierbei ist "yield" bereits die komplette PV-Anlage, also im Schwarm alle WRs zusammen und das dann bei Kostal noch um den Hausspeicher korrigiert. Wenn der Hausspeicher lädt, wird das dann DC/AC Seitig rechnerisch dazu gerechnet und beim Entladen entsprechend abgezogen, es geht ja hierbei um den Zeitpunkt der Prognose.
"yield_max" ist ein Maximum der jeweiligen Stunde in den Vortagen, damit die KI nicht so übertreibt.

Mein Link aus dem Post führt zu der Beschreibung mit meiner KI Prognose, die in vier Teile aufgeteilt ist.

[ch.eick]

Hier muss man halt darauf achten, wie der PV Ertrag ausgewiesen wird. Bei Kostal, mit Hochvolt Accu, wird der Accu erst beim entladen in den Ertrag gerechnet und beim Laden fehlt er dann. So passiert es, dass der Ertarg erst am folgetag erscheint, bzw. die ganze Nacht als Ertrag ausgewiesen wird.

ja, danke für den Hinweis. Im Modul 76_SolarForecast sollte das im Reading Today_HourXX_PVreal den zur Stunde erzeugte PV Ertrag enthalten.

Diesen nutzte ich im SQL Script als Grundlage für den Teil '-- yield from Plenticore with Accu'

Bei mir ist der PV-Wechselrichter und Batterie Wechselrichter getrennt (AC Kopplung) daher sollte das zumindest bei mir so passen.

Ja das passt dann

Mir gefällt, dass das Modul 76_SolarForecast so modular aufgebaut ist und man alles problemlos konfigurieren kann.

Die KI Lösung von dir habe ich mehr oder weniger erst durch Zufall gefunden, da ich mich gerade sowohl beruflich als auch privat mit KI beschäftige und angefangen hatte selbst etwas in der richtig zu erstellen.

Und leider habe ich die Anleitung im Wiki und in dem Thread ab Hier nicht zu 100% verstanden. Aber am Ende lief es

Man kann ja auch Rückfragen stellen

[CaptainHook]

Man kann ja auch Rückfragen stellen

Danke, das werde ich tun. Ich hatte mich gescheut, da es in dem Thema, zumindest meiner Empfindung nach, Hauptsächlich um Kostal Plenticore geht und mein "Problem"/Anwendungsfall zu speziell ist.
Sollte auch keine Beschwerde sein, ich arbeite mich gerne in fremden Quellcode ein und bin selbst Softwareentwickler daher möchte ich auch oft gerne Verstehen was im Hintergrund passiert. Und man lernt immer etwas dabei.

[ch.eick]

Hier mal ein Beispiel von gestern für die KI_Prognose
Du darfst diesen Dateianhang nicht ansehen.
An stark schwankenden Tagen sieht das natürlich genauso schlecht/gut aus wie bei der bisherigen selber berechneten Prognose aus.

[SparcWolf]

Moin Heiko,

nach dem Update auf <0.82.0> habe ich einige Meldungen im fhem.log gesehen.
    ... aiGetResult ERROR: Must add training instances before calling train() at ./FHEM/76_SolarForecast.pm line 10639
Ist das normal und kann ich das ignorieren?

Ich frage, weil ich mit der Installation von <AI::DecisionTree> ein wenig tricksen musste.
Das Debian Paket habe ich für Stretch nicht gefunden und habe dann das Modul über cpan installiert.

Grüße,
  Guido.

[DS_Starter]

Das ist erstmal ok, der KI fehlen noch Trainingsdaten. Aber da muss ich noch an den Ausgaben feilen, weil in dem Fall kein ERROR.

[kask]

Code Auswählen Erweitern

VictronVRM - INFO - The correction factors are now calculated and stored proactively independent of the autocorrection usage
Ich habe mein System umgezogen. Dann ging VRM nicht mehr. Habe die vrmcredentials jetzt neu gesetzt. Das sollte so reichen denke ich

oder auch nicht:

Code Auswählen Erweitern

https://vrmapi.victronenergy.com/v2/installations/xxxxxxxxx/stats?type=forecast&interval=hours&start=1693844252&end=1694017052: HTTP response code 404
Hat einer noch das Problem?

Edit.: War ein fehler in der ID ;(

[schwatter]

@DS_Starter


Morgen,
seit dem letzten Update hängt der Ki-Status bei gelb.
Am PC konnte ich sehen, das da Stand, KI funktioniert aber es bezieht keine Daten.
Wie kann ich die KI anstupsen?

Gruß schwatter