76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[grappa24]

moin,
Meine Prognose war die ganze Zeit recht gut, jetzt liegt sie heftig zu tief -130% am 10.03. und -107% am 11.03. mit jeweils der aktuellen contrib Version
Gruß Dieter

[DS_Starter]

Moin,

ja ich beobachte das auch. Ich habe die Drift-Korrektur bereits abgeschwächt, bin mit dem Ergebnis noch nicht zufrieden.
Bleibe da dran.

LG,
Heiko

[300P]

Die eingebaute Drift-Korrektur reagiert zu straff wie ich heute bei mir festgestellt habe.

Ja - ist so (gewesen.
Ich hatte begonnen schon an den Einstellparameter zu drehen und 5 Berechnung gestern angeworfen... (-50 % Abweichung gab es am Ende Gestern bei mir dann )
Berichte dann was heute rauskommt (ohne weitere Änderung)

[Parallix]

Kurze Frage (an Heiko):

Ist es möglich, dass Du in SF ein Attribut einbaust, mit dem eine Grundlast definiert werden kann, die dann als immer zu berücksichtigender Verbrauch von SF bei der Ladeplanung berücksichtigt wird. Für (m)einen Anwendungsfall wäre es noch besser, wenn ein Grundlast-Profil als Array mit 24 Elementen (ein Element pro Stunde) definiert werden kann oder ggf. sogar aus einem Reading bezogen werden kann.

Hintergrund: Abseits vorgenannter Grundlast ergibt sich der Verbrauch bei mir praktisch ausschließlich auf Basis von Verbrauchern, die nur bei zu erwartendem PV-Überschuss eingeschaltet werden. Letzteren ermittelt SF perfekt auf Basis des PV-Forecastings. Auf den Einsatz von KI-Einsatz möchte ich nicht nur aus Ressourcengründen verzichten, sondern auch deshalb, weil sich nahezu alle Vorgänge bei mir sehr gut mit klassischen Methoden modellieren lassen und das Regelverhalten daher konstant deterministisch ist, also nicht von Lernprozessen und deren Dauer abhängig ist.

[marboj]

Battery hat nur "pout". Oder meinst Du nicht, was sie gerade abgibt?

Hallo tomcat.x,

Heiko hatte mir die folgenden Infos gegeben:

Das ist praktisch das Solar-Ladegerät mit der Batterie. Hier muß sein:

- pvOut: die aktuelle Leistung aus PV-Erzeugung. Hier darf NUR die Solarzellenleistung drinstecken und
         keine anderen Bestandteile wie Batterieleistungsabgabe
- pin:  die aktuelle Batterieladeleistung, d.h. der Anteil der Solarleistung der in die Batterie geladen wird
        (kann alles sein) und/oder der Ladeanteil vom Wechselstromhausnetz falls dies zutreffen kann.
        Ist der Readingname "/power" so richtig?
- pout: die aktuelle Batterieentladeleistung, d.h. was die Batterie an das Hausnetz abgibt. Hier darf
        wiederum kein Solarzellenanteil drinstecken.

Wenn du diese Bedingungen einhältst, sollte die Flußdarstellung i.O. sein.

Den Parameter pvOut kann ich nicht setzen. Deswegen habe ich gefragt...

Gruß
Marco

[DS_Starter]

Hallo Marco,

die genannten Schlüsssel pvOut, pin, pout sind nur in den entsprechenden Devicetypen setzbar.
Also so wie tomcat.x bereits angedeutet hat -

pvOut     bei setupInverterDevXX
pin, pout bei setupBatteryDevXX

In der Hilfe ist aber genau beschrieben welche Schlüssel für welchen Gerätetyp setzbar sind.
Mir ging es darum dir nochmal ganz genau zu sagen was der Inhalt der Readings/Werte sein muß.

LG,
Heiko

[DS_Starter]

@Parallix,

Ist es möglich, dass Du in SF ein Attribut einbaust, mit dem eine Grundlast definiert werden kann, die dann als immer zu berücksichtigender Verbrauch von SF bei der Ladeplanung berücksichtigt wird. Für (m)einen Anwendungsfall wäre es noch besser, wenn ein Grundlast-Profil als Array mit 24 Elementen (ein Element pro Stunde) definiert werden kann oder ggf. sogar aus einem Reading bezogen werden kann.

Was spricht dagegen, wenn du dir einen ConsumerXX (als Dummy) anlegst und die Leistung entsprechend deines Grundbedarfs definierst. "power" ist zur Zeit ein fester Wert, kann aber bei Bedarf recht leicht erweitert werden um Quellenreadings zu verarbeiten. Den Inhalt kannst du dann aus einem Array errechnen und dort eintragen.

Mit pvshare=0 ist auch die Unabhängigkeit vom PV-Überschuß gegeben und du kannst diesen "Verbraucher" 24h am Tag planen und "einschalten" lassen. Das hat auch den Vorteil, dass Werte aus der Vergangenheit völlig konform mit den Modulprozessen einbezogen werden können um die Zukunft abzubilden.
So kannst du z.B. an einem WE den "Grundverbrauch" gezielt ändern und solche Dinge.

LG,
Heiko

[peterboeckmann]

Hallo Heiko,

ich habe plötzlich in SolarForecast für die vergangene Stunde einen Verbrauch von >12 MWh:
Du darfst diesen Dateianhang nicht ansehen.

Offenbar wurde der Zähler meiner PV-Erzeugung irgendwie zurückgesetzt.

Kann ich den Wert irgendwie einzeln korrigieren? Oder nur komplett mit der ganzen Stunde löschen?

Vielen Dank und viele Grüße,
Peter

[DS_Starter]

Hallo Peter,

für die pvHistory geht nur ganze Sunde löschen:

Code Auswählen Erweitern

set <name> reset pvHistory <Tag> <Stunde> (z.B. set <name> reset pvHistory 08 10)

Die KI Raw-Daten (nicht vergessen) geht die ganze Stunde löschen (delIndex) oder nur den Wert für con (delValue=con>=.....)

LG,
Heiko

[peterboeckmann]

Erinnere ich mich richtig, dass die Stunde, die um 12 begonnen hat, mit dem Index 13 gelöscht wird?

Also so?

Code Auswählen Erweitern

set SolarForecast reset pvHistory 11 13
Und die KI-Raw-Daten so?

Code Auswählen Erweitern

set SolarForecast reset aiData delValue=con>10000000
Viele Grüße,
Peter

[DS_Starter]

Erinnere ich mich richtig, dass die Stunde, die um 12 begonnen hat, mit dem Index 13 gelöscht wird?

Ja. Kannst dir einfach merken, es ist Stunde des Tagess (hour of day) beginnend mit 01 bis 24.

Und KI passt auch so.

[peterboeckmann]

Danke, das Löschen hat geklappt.

Direkt danach ist die Skalierung des zweiten Balkendiagramms gestört. Nicht schlimm, gibt sich bestimmt wieder.
Vielleicht ein Ansatz für die Fehlersuche?

Dargestellt sollten dort Verbrauchsprognose und realer Verbrauch sein.

Viele Grüße,
Peter

[Parallix]

@Parallix,

Ist es möglich, dass Du in SF ein Attribut einbaust, mit dem eine Grundlast definiert werden kann, die dann als immer zu berücksichtigender Verbrauch von SF bei der Ladeplanung berücksichtigt wird. Für (m)einen Anwendungsfall wäre es noch besser, wenn ein Grundlast-Profil als Array mit 24 Elementen (ein Element pro Stunde) definiert werden kann oder ggf. sogar aus einem Reading bezogen werden kann.

Was spricht dagegen, wenn du dir einen ConsumerXX (als Dummy) anlegst und die Leistung entsprechend deines Grundbedarfs definierst. "power" ist zur Zeit ein fester Wert, kann aber bei Bedarf recht leicht erweitert werden um Quellenreadings zu verarbeiten. Den Inhalt kannst du dann aus einem Array errechnen und dort eintragen.

Mit pvshare=0 ist auch die Unabhängigkeit vom PV-Überschuß gegeben und du kannst diesen "Verbraucher" 24h am Tag planen und "einschalten" lassen. Das hat auch den Vorteil, dass Werte aus der Vergangenheit völlig konform mit den Modulprozessen einbezogen werden können um die Zukunft abzubilden.
So kannst du z.B. an einem WE den "Grundverbrauch" gezielt ändern und solche Dinge.
...

Es spricht fast nichts dagegen, aber eben nur fast. Denn für die Verbrauchsprognose wird der Verbrauch aller Consumer summiert. Wünschenswert wäre es aber (zumindest in meinem Anwendungsfall), nur die Consumer bei der Verbrauchsprogose zu berücksichtigen, der eine Grundlast darstellen oder aber aktuell geplant sind.

Mir persönlich ist auch jetzt erst aufgefallen, dass SF zwar über einen einen (Sicherheits-)Faktor die Ladeleistungen anheben kann, aber keine additiven Ladeleistungskomponente berücksichtigen kann. Oder liegt ich hier falsch?

[DS_Starter]

Es spricht fast nichts dagegen, aber eben nur fast. Denn für die Verbrauchsprognose wird der Verbrauch aller Consumer summiert. Wünschenswert wäre es aber (zumindest in meinem Anwendungsfall), nur die Consumer bei der Verbrauchsprogose zu berücksichtigen, der eine Grundlast darstellen oder aber aktuell geplant sind.

Also ich müsste mich nochmal vergewissern, aber ich bin der Meinung, dass nur gaplante oder eingeschaltete Consumer für die Prognose berücksichtigt werden. Durch geschickte Planungsparamter wird der Consumer 7 x 24 mit kleinen Unterbrechnungen durchgeplant.
Zusätzlich gibt es ja noch den exconfc Schlüssel für eine Behandlung Richtung Exclude.

Vorteil der Verfahrens ist die komplette Einhaltung der SF-Prozesse bis hin zu den Darstellungen und Berücksichtigungen diverser Werteberechnungen.