76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[Parallix]

Ich hatte es irrtümlich schon mal bei "ausgegrauten" Symbolen auch schon mal gedacht bzw. angebracht....aber das war es dann wohl nicht also ->> auf Heikos Reaktion warten...

Ja, und für Heiko hier noch direkt etwas an Zusatzinfo:

• KI-Features in SF wurden meinerseits nicht aktiviert
• Die PV-Erzeugungsprognose funktioniert soweit einwandfrei. Der Absolutwert der Abweichung liegt in aller Regel unter 10%.
• Jetzt, nachdem die Sonne untergegangen ist, ändert sich der seltsame SoC-Forecast nicht: Aktuell haben die BATs eine SoC von 70% und morgen früh direkt um 8:00 Uhr sind's schon 100%

[DS_Starter]

@Parallix, welche Ladestrategie ist eingestellt (Schlüssel loadStrategy)?

PS: Die Rückmeldungen zum Lade-Controller werde ich in den nächsten zwei Wochen angehen.

Das läuft bei seit mehreren Wochen sehr gut.

[DS_Starter]

Möglicherweise habe ich einen kleinen Bug gefunden.
Version 2.10.3 liegt im contrib.

[Parallix]

Möglicherweise habe ich einen kleinen Bug gefunden.
...

Danke für die schnelle Rückmeldung. Leider bleibt die Ausgabe inhaltlich unverändert:

Wetterbedingt ist heute hier bei uns ein wirklich schlechter Tag in Bezug auf die PV-Erzeugung prognostiziert. Mit Erzeugungswerten von [0.2, 0,6, 0.9] kWh für die Bins [8:00, 9:00, 10:00] decke ich im besten Fall gerade einmal meine Hauslast.

Trotz einem Start-SoC von gerade einmal 33% jetzt um 7:56 Uhr prognostiziert SF für das Ende des aktuellen und aller folgenden Bins einen SoC von 100%.   

Übrigens bestimmt SF aktuell (8:09 Uhr) auch die optimalen Ladeleistungen nicht korrekt. Lt. aktueller Empfehlung sollen 73W für jede meiner zwei BATs ausreichen um das eingestellte Ladeziel (100%) von aktuell 33% aus zu erreichen.   

[300P]

Also bei mir sieht (trotz des sch... Wetters) in der Grafik (bei / für mich) alles okay aus:
Screenshot

[Parallix]

Also bei mir sieht (trotz des sch... Wetters) in der Grafik (bei / für mich) alles okay aus:
Screenshot

Wenn's so bei mir aussähe, wäre ich auch zufrieden. Anbei meine Grafik.

PS: Kann ich die PV-Erzeugungsgrafik eigentlich auch so erstellen lassen, dass zwei Tage im Voraus angezeigt werden. Das wäre praktisch, da dann schnell abgelesen werden können, ob mein EV heute, morgen oder übermorgen ohne Netzbezug geladen werden könnte.

[DS_Starter]

Moin,

bei mir ebenfalls ok. Ich hatte auch vor dem kleinen Fix keine Beschwerden bei mir.
Die Wetterverhältnisse sind bei uns heute auch nicht gut. Die SOC-Prognose ist dennoch realistisch.

Also nochmal die Frage welche Ladestrategie ist eingestellt?  Bzw. zeige uns mal bitte das/die Attr ctrlBatSocManagementXX.
Weiterhin wäre es dann sicherlich sinnvoll, ctrlDebug=batteryManagement mitlaufen zulassen, um mal ein paar Anhaltspunkte zu bekommen was die Bat-Steuerung so "denkt".

Deine Anzeige sind kWh? Aus dem unteren Balkendiagramm werde ich nicht schlau. Was ist dort dargestellt?

PS: Kann ich die PV-Erzeugungsgrafik eigentlich auch so erstellen lassen, dass zwei Tage im Voraus angezeigt werden.

Nein, es wird max. ein 24h-Fenster abgeboten. Man kann es mit graphicControl->hourCount verkleinern. 
Kleiner Kniff...mit graphicShowNight=01 werden die Nachtstunden ausgeblendet und synchronisiert was das Stundenfenster streckt, aber es bleiben 24 in Summe.

[Parallix]

Moin,

bei mir ebenfalls ok. Ich hatte auch vor dem kleinen Fix keine Beschwerden bei mir.
Die Wetterverhältnisse sind bei uns heute auch nicht gut. Die SOC-Prognose ist dennoch realistisch.

Vor meinem Urlaub (im August) war auch alles in Ordnung, jedenfalls habe ich nichts seltsames gesichtet, was aber auch daran gelegen haben kann, dass der SOC meiner BATs zum Tagesstart zumeist noch bei ca. 70% lag.
 
Bis auf ein einspielen von freigegebenen Updates (und Dein gestriges Update von SF im Contrib) habe ich zwischenzeitlich auch nichts verändert.

Also nochmal die Frage welche Ladestrategie ist eingestellt?  Bzw. zeige uns mal bitte das/die Attr ctrlBatSocManagementXX.

Sorry, hätte ich eigentlich längst machen sollen. Hier die für beide BATs identischen Einstellungen:

Code Auswählen Erweitern

lowSoc=5
upSoC=80
maxSoC=100
careCycle=1
loadAbort=100:686:100
loadStrategy=optPower
loadTarget=95
safetyMargin=0:0
weightOwnUse=95
stepSoC=5Battery_OptimumTargetSoC_01 und Battery_OptimumTargetSoC_02 stehen aktuell bei mir beide auf 100%

Vielleicht liegt es an meiner möglicherweise untypischen Einstellung von  careCycle und stepSoC? Aufgrund meines Ladecontrollers wäre aus meiner Sicht  careCycle=5 und stepSoC=20 sinnvoll. SF lässt leider aber nur einen stepSoC in [0,5] zu.

Weiterhin wäre es dann sicherlich sinnvoll, ctrlDebug=batteryManagement mitlaufen zulassen, um mal ein paar Anhaltspunkte zu bekommen was die Bat-Steuerung so "denkt".

Schalte ich jetzt ein.

[DS_Starter]

Aufgrund meines Ladecontrollers wäre aus meiner Sicht  careCycle=7 und stepSoC=20 sinnvoll.

Das Produkt aus careCycle * stepSoC soll 100 ergeben (siehe Commandref). Das ist bei dir übrigens mit careCycle=1 und stepSoC=5 nicht der Fall, d.h. die Bat sollte lt. Vorgabe täglich den maxSoC erreichen.

Trotzdem komme ich immer noch nicht mit deinem unteren Balkendiagramm klar. Dort werden doch keine Batterie % dargestellt?

[Parallix]

Aufgrund meines Ladecontrollers wäre aus meiner Sicht  careCycle=7 und stepSoC=20 sinnvoll.

Das Produkt aus careCycle * stepSoC soll 100 ergeben (siehe Commandref). Das ist bei dir übrigens mit careCycle=1 und stepSoC=5 nicht der Fall, d.h. die Bat sollte lt. Vorgabe täglich den maxSoC erreichen.

Ja, dort steht "soll", aber nicht "muss". Wie in meinem Beitrag oben ergänzt hat dies auch einen Grund. Wenn das "soll" aber ein "muss" ist, so wäre eine erweiterter Einstellbereich für stepSoC (siehe meine Ergänzung oben) sehr hilfreich.
Edit: Noch besser wäre es (bei einem "muss") natürlich, wenn stepSoC direkt aus dem careCycle abgeleitet würde, oder?

Trotzdem komme ich immer noch nicht mit deinem unteren Balkendiagramm klar. Dort werden doch keine Batterie % dargestellt?

Ja, das ist richtig, da ich die Grafik nicht überfrachten möchte. Bei den grünen BAT-Symbole wird aktuell SoC-Prognose 100% angezeigt und beim jeweils ersten davon (aktuelles Bin) zusätzlich SoC-Aktuell 44%

[DS_Starter]

Ja, dort steht "soll", aber nicht "muss". Wie in meinem Beitrag oben ergänzt hat dies auch einen Grund. Wenn das "soll" aber ein "muss" ist, so wäre eine erweiterter Einstellbereich für stepSoC (siehe meine Ergänzung oben) sehr hilfreich.

Ich habe es mir nochmal angeschaut. Ein "muss" Kriterium an dieser Stelle wäre richtig und ich werde einen Check einbauen.
Ein erweiterter stepSoC-Bereich wäre auch möglich, allerdings nur in validen Schritten zur Einhaltung der beschriebenen Bedingung (siehe Anhang).
Gebrochene Zahlenwerte sind mathematisch zwar möglich, sind in diesem Kontext aber inhaltlich und bezüglich der Benutzerfreundlichkeit/Gebrauchstauglichkeit nicht zielführend.
Eine automatische Ableitung beider Werte voneinander wäre nur machbar wenn einer der Parameter "führend" wäre. Aber da der User unterschiedliche Präferenzen haben kann, ist im Modul nur ein Überprüfung der Gesamtbedingung sinnvoll.

Die Fehleinstellung ist höchstwahrscheinlich die eigentliche Ursache bei dir. Stelle die Werte so ein, dass die Bedingung erfüllt wird und dann schauen wir nochmal.
Ich kümmere mich um eine Anpassung im Modul wie gerade analysiert.

[Parallix]

Ja, dort steht "soll", aber nicht "muss". Wie in meinem Beitrag oben ergänzt hat dies auch einen Grund. Wenn das "soll" aber ein "muss" ist, so wäre eine erweiterter Einstellbereich für stepSoC (siehe meine Ergänzung oben) sehr hilfreich.

Ich habe es mir nochmal angeschaut. Ein "muss" Kriterium an dieser Stelle wäre richtig und ich werde einen Check einbauen.
Ein erweiterter stepSoC-Bereich wäre auch möglich, allerdings nur in validen Schritten zur Einhaltung der beschriebenen Bedingung (siehe Anhang).
Gebrochene Zahlenwerte sind mathematisch zwar möglich, sind in diesem Kontext aber inhaltlich und bezüglich der Benutzerfreundlichkeit/Gebrauchstauglichkeit nicht zielführend.
Eine automatische Ableitung beider Werte voneinander wäre nur machbar wenn einer der Parameter "führend" wäre. Aber da der User unterschiedliche Präferenzen haben kann, ist im Modul nur ein Überprüfung der Gesamtbedingung sinnvoll.

Die Fehleinstellung ist höchstwahrscheinlich die eigentliche Ursache bei dir. Stelle die Werte so ein, dass die Bedingung erfüllt wird und dann schauen wir nochmal.
Ich kümmere mich um eine Anpassung im Modul wie gerade analysiert.

Am einfachsten wäre es jetzt für mich es wohl erst einmal mit careCycle=0 zu versuchen. stepSoC kommt dann keine Bedeutung mehr zu, oder?

Übrigens: Nachkommastellen machen bei careCycle wirklich keinen Sinn. Etwas anders sieht es bei stepSoC aus. Statt zu prüfen wäre es aus meiner Sicht aber sicherer, den Wert via stepSoC = 100/careCycle zu berechnen.

[lawern]

Hallo DS_Starter,

ich verwende SolarForecast 2.10.2 auf einem ziemlich betagten Raspberry Pi 2 mit
knapp 1 GB RAM. Bei mir hat der OOM-Killer FHEM in zwei Wochen 21 Mal abgeschossen,
und beim Suchen bin ich über eine Stelle im Modul gestolpert, die den Speicherbedarf
kurzzeitig verdoppelt. Auf normaler Hardware merkt das vermutlich keiner.

Nach dem Training holt aiFinishTrain das Modell über readCacheFile wieder in den
Elternprozess rein (2.10.2, Zeilen 11930 und 11942):

Code Auswählen Erweitern

if ($cachename eq 'aitrained') {
    my ($err, $objref) = fileRetrieve ($file);        # 11930
    ...
    $data{$name}{aidectree}{aitrained} = $objref;     # 11942

Das fileRetrieve baut das neue Modell erstmal komplett auf, und solange hängt das alte
ja noch über aitrained dran. Weg ist es erst mit der Zuweisung in Zeile 11942. Heißt:
kurzzeitig liegen zwei komplette Modelle im RAM.

Bei mir macht das ordentlich was aus, weil das Ding im Speicher viel dicker ist, als
die Datei vermuten lässt:

Code Auswählen Erweitern

Datei AItra_SolarForecast_Forecast:   8,59 MB
nach Storable-retrieve im RAM:       46,9 MB
(10 Bäume, Baum 1 hat 8591 Knoten, aiRulesNumber 65460)

Und weil Perl freigegebenen Speicher nicht wieder ans System zurückgibt,
bleibt die Spitze dann für immer stehen.

Zum Nachstellen hab ich das Modell in einem kleinen eigenen Skript viermal
hintereinander geladen: Einmal in der Reihenfolge wie im Modul, einmal mit vorherigem
Freigeben. RSS nach jedem Durchlauf:

Code Auswählen Erweitern

                                 Start   Zyklus 1  Zyklus 2  Zyklus 3  Zyklus 4
Reihenfolge wie im Modul        5,5 MB    52,5      99,4      99,5      99,5
altes Objekt vorher freigeben   5,5 MB    52,5      52,6      52,6      52,6

Der Unterschied ist genau ein Modell.

Mein Vorschlag wäre eine Zeile vor dem fileRetrieve:

Code Auswählen Erweitern

delete $data{$name}{aidectree}{aitrained} if -s $file;

Das -s $file soll nur verhindern, dass das alte Modell wegfliegt, wenn gar keine Datei
zum Nachladen da ist.

Eingebaut hab ich es bei mir schon und mitgeschrieben, was der Speicher beim
nächtlichen Training macht (RSS plus ausgelagerte Seiten, alle 5 Minuten ein
Messpunkt). Sprung jeweils in der Trainingsnacht:

Code Auswählen Erweitern

vorher:   +46,6 MB  /  +22,0 MB  /  +20,3 MB
nachher:   +1,9 MB  /   +1,7 MB

Die Stufe ist damit weg.

Ganz aus dem Schneider bin ich allerdings noch nicht, bei mir wächst FHEM trotzdem
weiter. Das hat nach allem, was ich bisher gemessen habe, aber eine andere Ursache und
nichts mit dieser Stelle zu tun. Falls ich da was übersehe, sag gern Bescheid.

Danke jedenfalls für das Modul, ich nutze es sehr gerne.

Viele Grüße
Lars

[DS_Starter]

Statt zu prüfen wäre es aus meiner Sicht aber sicherer, den Wert via stepSoC = 100/careCycle zu berechnen.

Ja, aber nur wenn careCycle ein "führender" Wert ist. Manch einem User ist stepSoC zu granulareren Nutzung (Schrittweite) des optimalen SoC wichtiger und für ihn stepSoC der "führende" Wert und möchte diesen vorgeben. careCycle richtet sich dann danach, d.h.  careCycle = 100/stepSoC.
Da ich die Präferenz des Users nicht kenne, prüfe ich nur die Einhaltung der Abhängigkeit. Das reicht.

@Lars,
danke für den Hinweis, schaue ich mir an und übernehme den Fix wenn nichts dagegen spricht.
Zur Info ... aidectree wird mit Umstellung (irgendwann  ) auf AI::FANN für die PV Prognose ausgebaut.
Das nur nebenbei.

LG,
Heiko

[300P]

Also bei mir sieht (trotz des sch... Wetters) in der Grafik (bei / für mich) alles okay aus:
Screenshot

Wenn's so bei mir aussähe, wäre ich auch zufrieden. Anbei meine Grafik.

PS: Kann ich die PV-Erzeugungsgrafik eigentlich auch so erstellen lassen, dass zwei Tage im Voraus angezeigt werden. Das wäre praktisch, da dann schnell abgelesen werden können, ob mein EV heute, morgen oder übermorgen ohne Netzbezug geladen werden könnte.

PS:
Für mich sind diese Batterien in der angehängten Grafik doch auch "ausgegraut".....oder habe ich es mit den Augen.
Das erste Grün ist strahlend grün - danach sind dann (für mich) alle "ausgegraut".......
Du darfst diesen Dateianhang nicht ansehen.