76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[Wolle02]

Naja, wenn meine Batterie morgens um 10.00 Uhr noch 76 % SoC hätte würde SF bei mir wahrscheinlich auch die Ladeleistung abregeln, damit erst am Nachmittag die 88 % erreicht wären.    Meine Batterie hat morgens noch 10 % und wenn ich dann wie heute noch das Auto laden muss wird sie halt gar nicht voll.
Man muss bei solchen Tests natürlich schon von gleichen Rahmenbedingungen ausgehen; jedenfalls bei mir ist dafür die Jahreszeit bereits zu spät.

Momentan kann ich nur von meiner Beobachtung berichten, dass im Sommer die Laderegelung nicht soweit begrenzt hat wie es erforderlich gewesen wäre, damit die Batterie nicht schon um 16:00 Uhr immer voll gewesen wäre, sondern aufgrund der Einstellung loadTarget=100:-2 erst zwei Stunden vor Sonnenuntergang. Naja, lässt sich jetzt nicht mehr reproduzieren.  Aber anhand meiner beigebrachten Logfiles kann st du ja sehen, dass vor einer Woche noch die Batterie schon um 15:00 Uhr voll war, obwohl als Targettime 17 ocklock eingestellt war. Da hätte die Laderegelung ja mehr begrenzen müssen.

[DS_Starter]

Ich möchte das Ergebnis auch nicht schuldig bleiben.
Ca. 16:43 wurde das Ziel erreicht. Ein wenig zu früh, denn das Ziel war 17:00.
Wichtig war zu demonstrieren, dass die zielgerichtete Abregelung so wie erwartet funktioniert.

Das klappt natürlich nur wenn Überschuß prognostiziert ist. Wenn durch (prognostizierte) starke Verbräuche eine Zielerreichung kalkulatorisch nicht gegeben ist, kann die Regelung auch keine Wunder vollbringen und agiert situationsbezogen. Schwierig sind auch wechselnde Bedingungen die sich über den Tag hinweg unvorhersehbar ergeben. Damit muß man dann leben.
Ich nehme bei mir loadTarget wieder heraus und nutze den Standard des Moduls.

[TheTrumpeter]

Die Funktionen untersuche ich gerade versuche auch das noch in den Griff zu bekommen. Ein geringes Wachstum an dieser Stelle ist gerechtfertigt, da hier die Daten zur Langzeitspeicherung akkumuliert werden. Nur 3MB scheint mir zu viel zu sein.

Das Problem konnte ich nun mit einem BlockingCall-Workaround beseitigen.
Update liegt im Contrib.

Ich bin jetzt nicht zu 100% sicher, ob das auch schon Teil der offiziellen Version 2.10.5 ist, die am 28.09.2026 ausgerollt wurde?

Jedenfalls hat sich der RAM-Verbrauch seit diesem Update deutlich verbessert. Zwar ist der steile Anstieg in den ersten ca. 36 h nach dem Update weiterhin gegeben, bleibt dann aber auf einem niedrigeren Niveau stehen als davor, der weitere Anstieg ist dann deutlich flacher als davor. Zumindest deuten die aktuellen Messwerte darauf hin, mal sehen wie es in den nächsten Stunden bzw. Tagen weitergeht.

[DS_Starter]

Moin,

ja in der V2.10.5 ist sehr viel Optimierung im Speicherbereich enthalten (siehe #7071).
Wenn ich mir dein Plot anschaue, kann der Anstieg m.M. nach nicht allein durch SF begründet sein. Nach einem Restart bauen sich die Arenen schnell auf, dadurch der steile Anstieg, der dann aber deutlich abflachen (Datenakkumulation über den Tag), im Idealfall dann aber konstant bleiben sollte.

Auf meinem großen System habe ich allein 5 SF Devices werkeln und viele andere Module:

Code Auswählen Erweitern

System Info
ConfigType: configFile
SVN rev: 31694
OS: linux
Perl: 5.36.0
uniqueId: 137...
 
Modules Model Count
Alarm 1
Analyze 1
Astro 1
CUL 2
CUL_HM
CCU-FHEM 1
HM-CC-RT-DN 7
HM-ES-PMSW1-PL 2
HM-LC-BL1-FM 2
HM-LC-BL1PBU-FM 1
HM-LC-JA1PBU-FM 6
HM-LC-SW1-FM 3
HM-LC-SW1-PL-DN-R1 5
HM-LC-SW4-DR-2 2
HM-OU-CFM-PL 1
HM-PB-2-WM55-2 2
HM-RC-2-PBU-FM 4
HM-RC-2-PBU-FM-2 1
HM-RC-8 1
HM-RC-SEC4-3 2
HM-SEC-SC-2 18
HM-SEC-SD-2 6
HM-SEN-MDIR-O-2 2
HM-SEN-MDIR-WM55 1
HM-TC-IT-WM-W-EU 8
DWD_OpenData 3
Dashboard 1
DbLog
MYSQL 3
DbRep
Agent 2
Client 159
FHEM2FHEM 1
FHEMWEB 4
FS20
fs20piri 4
FULLY 3
FileLog 1
GasCalculatorHM 1
HMCCU 1
HMCCUCHN 6
HMCCURPCPROC 3
HMLAN 2
HMinfo 1
HTTPAPI 1
HTTPMOD 10
HTTPSRV 2
HUEBridge 2
HUEDevice 8
3261048P6 2
4090531P9 1
DLOFFSET10110 1
DLOFFSET102 1
DLOFFSET2201 1
DLOFFSET2212 1
LCA006 1
LCL001 2
LST002 1
LTA001 3
LTW013 2
PHDL00 2
RWL021 1
TS011F 4
IT 8
itswitch 5
Installer 1
Log2Syslog
Collector v28.9.234.0.0.0 6
Sender v28.9.234.0.0.0 5
MQTT2_CLIENT 2
MQTT2_DEVICE 23
SHGS-1 1
SHPLG-S 5
SHSW-1 2
SHSW-PM 2
Victron Cerbo GX Splitter 1
eBus_bai_Pressure 1
eBus_bai_jsonmap 1
eBus_daemon_splitter 1
shellydimmer 1
tasmota_8ch_unified_icon 1
zigbee2mqtt_AlarmSensor 1
zigbee2mqtt_bridge 1
zigbee2mqtt_plug_w_energy_measuring 6
MQTT2_SERVER 1
NUT 1
Nmap 2
PylonLowVoltage 9
RESIDENTS 1
ROOMMATE 3
SMAEM
EM / HM 2.0 < 2.03.4.R 1
SMAInverter
STP 5000TL-20 1
SONOS 1
SONOSPLAYER
Sonos_S12 2
Sonos_S14 1
Sonos_S38 2
Sonos_Sub 1
SSCal
Diary 3
SSCam
Airlive - AirCam POE-2600HD 1
Airlive - BU-3025 2
HIKVISION - DS-2CD2032-I 1
HIKVISION - DS-2CD2042WD-I 1
Reolink - RLC-810A 1
SVS 1
SSCamSTRM
generic 7
lastsnap 5
master 8
mjpeg 6
ptzcontrol 1
snapgallery 4
switched 5
SSChatBot
ChatBot 1
SSFile
unspecified 1
SVG 47
SYSMON 1
SolarForecast
DWD 1
OpenMeteoDWDEnsembleAPI 1
OpenMeteoWorldAPI 1
SolCastAPI 1
VictronKiAPI 1
SysStatHM 4
TPLinkHS110
HS100(EU) 1
HS110(EU) 1
TelegramBot 1
Unifi 1
Verkehrsinfo 1
Watches
DIGITAL 2
MODERN 3
STATION 2
Weather
OpenWeatherMapAPI 1
ZWDongle 1
ZWave
FIBARO System FGFS101 Zwave+ Flood Sensor 2
HANK Electronics Ltd HKZW-SO05 Smart Plug 3
allowed 2
at 118
autocreate 1
cmdalias 19
dummy 40
eventTypes 1
holiday 1
notify 228
readingsGroup 35
readingsProxy 12
remotecontrol 1
sequence 5
serviced 1
siri 1
structure 9
telnet 1
weblink 18
weekprofile 1

Ein RAM Anstieg findet statt, ist aber relativ flach gegenüber deinem Plot und interessanterweise ist seit vergangenem Tageswechsel kein Anstieg mehr da. Eingesetzt ist hier bereits SF 2.10.6. Wobei dort keine weiteren Speicheroptimierungen enthalten sind.
Aber ich habe in allen meinen System einen Change drin den ich hier kommuniziert habe.
Weiterhin habe ich jetzt auf allen meinen Systemen das Standardmodul eventTypes disabled.

[Wolle02]

Das klappt natürlich nur wenn Überschuß prognostiziert ist....
 

Ich denke auch, dass hier im Zusammenspiel von PV-Prognose und Con-Prognose das Problemchen bei mir liegt. Ich habe mich auch an den nachträglich eingebauten Schlüssel weightOwnUse erinnert, der ja laut Doku fest legt, wie stark der erwartete eigene Hausverbrauch bei der Berechnung der optimalen Lade- und Entladesteuerung berücksichtigt wird. Das wäre ja eventuell genau der Hebel bei mir. Beim herumspielen mit den Werten habe ich aber leider festgestellt, dass eine Erhöhung des Wertes den Zeitpunkt wann die Batterie voll ist noch weiter nach vorne schiebt. Zulässig sind leider nur positive Werte. Wäre es an dieser Stelle möglich eventuell auch negative Werte zuzulassen, um so die Gewichtung in die andere Richtung zu verschieben?

[TheTrumpeter]

Aber ich habe in allen meinen System einen Change drin den ich hier kommuniziert habe.

Interessant.
Hast Du damit den langsame kontinuierliche Anstieg wegbekommen?

Ich habe mal in die Vergangenheit geschaut, es gab bei mir immer schon einen langsamen Zuwachs, aber diesen massiven Anstieg in den ersten Stunden gab es nicht. Das ist erst seit dem Juli dieses Jahres so, wobei ich da wie schon vor ein paar Tagen nachgeschaut eigentlich keine großen Änderungen gemacht habe, schon gar nicht außerhalb SF. Insofern wundert mich, dass Dein System dieses Verhalten so gar nicht zeigt.

[DS_Starter]

Hast Du damit den langsame kontinuierliche Anstieg wegbekommen?

Ich kann es dir nicht sagen ob genau die eine oder andere Maßnahme zum Erfolg beigetragen hat. Manche Dinge sind auch nicht wirklich erklärbar wie der abrupte Übergang eines Anstieges in eine reine Seitwärtsbewegung genau um Mitternacht in meinem Screenshot des großen Produktivsystems.
Ein leichter! Anstieg ist normal weil die Tagesdaten akkumuliert werden. Auch untersuche ich andere Module und habe ebenfalls Speicherleaks schon entdeckt die ich teste und nach und nach kommuniziere. Es ist also ein Maßnahmepaket welches helfen kann. Es liegt sicherlich bei jeden User eine spezifische Situation vor.

[DS_Starter]

@Wolle02,

Wäre es an dieser Stelle möglich eventuell auch negative Werte zuzulassen, um so die Gewichtung in die andere Richtung zu verschieben?

Das würde rein mathematisch dazu führen, dass der PV-Überschuß höher wird als die PV-Erzeugung. Das ist unlogisch und würde mit an Sicherheit grenzender Wahrscheinlichkeit an irgendeiner anderen Stelle zu merkwürdigen Effekten führen.