76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[Parallix]

Da mein FHEM auf einem Banana Pro läuft und es gelegentlich bei Modbus-Abfragen zu einem Timeout kommt, versuche ich gerade Problemfälle in Sachen CPU- und Speichernutzung sowie Blockierungen zu identifizieren.

Hierbei ist mir nachfolgendes DEAD aufgefallen:

Code Auswählen Erweitern

GMFRUNNING:
       abortFn    FHEM::SolarForecast::_abortGetMessageFile
       bc_pid     30
       finishFn   FHEM::SolarForecast::_processMessageFile
       fn         FHEM::SolarForecast::_retrieveMessageFile
       loglevel   3
       pid        DEAD:26054
       telnet     telnetForBlockingFn_1789889458.07661_127.0.0.1_39932
       terminated 1
       timeout    30
       abortArg:
       arg:
         block      1
         name       SF
         tsnext     1789896826 
Auch frage ich mich, ob folgende Info

Code Auswählen Erweitern

    NOTIFYDEV  GW25,EnO_FSVA_1_M,EnO_FSVA_2_M,WebastoNext,EnO_FMS61NP_KlBadHeiz_Ch1,BydBat1,BydBat2bedeutet, dass jeglicher Event einer der o.g. Devices zu einer Verarbeitung in SF führt. Wenn ja, so interessiert mich, ob sich das ändern lässt, ohne das ich in den jeweiligen Devices mittels event-on-... konfiguriere. Gerade was z.B. den Wechselrichter (GW25) angeht, gibt es nämlich eine Vielzahl von Readings, die ich an anderer Stelle benötige, die aber nicht unbedingt zu einem Verarbeitung seitens SF führen (müssen).

[DS_Starter]

Auch frage ich mich, ob folgende Info
    NOTIFYDEV  GW25,EnO_FSVA_1_M,EnO_FSVA_2_M,WebastoNext,EnO_FMS61NP_KlBadHeiz_Ch1,BydBat1,BydBat2
bedeutet, dass jeglicher Event einer der o.g. Devices zu einer Verarbeitung in SF führt.

Nein.
Es bedeutet zunächst, dass SF grundsätzlich nur Events der dort angegebenen Devices vom FHEM-Kern durchgereicht bekommt. Es ist ein Filter der die generelle Last im System (durch SF) reduziert. Abhängig davon ob ein Entwickler NOTIFYDEV in seinen Modulen integriert hat, wirst du dieses Internal auch in anderen Devices finden.

Ob ein empfangener Event zu einer Verarbeitung in SF führt, ist von der asynchron-Einstellung des jeweiligen Consumers, Inverters etc. abhängig. Wenn asynchron=1 wird eine SF-Verarbeitung gestartet. asynchron=0 ist der Default.

Mit ctrlDebug=notifyHandling kannst du dir die Eventverarbeitung durch SF ansehen. Weiterhin kannst du dir mit

Code Auswählen Erweitern

get ... stepTimes ...
einen Überblick über die Verarbeitungsgeschwindigkeit der Bestandteile innerhalb SF verschaffen.

[Hadl]

Hallo,
ich nutze die Batteriesteuerung mit OTP schon länger, aber seit ca. 2 Wochen klappt das nichtmehr.
Jeweils zum Ende einer Stunde bekomme ich "target likely achievable? no" und einen sehr geringen "Ratio of remaining surplus", und dadurch eine hohe Ladeleistung.
Zum Beginn der neuen Stunde ist dann wieder Überschuss vorhanden und die Ladeleistung wird wieder beschränkt.

Code Auswählen Erweitern

2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ######################### Start Battery Management DebugLog #########################
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> SoC Step1 Bat 01 - basics -> setup values: lowSoc=5 %, upSoc=20 %, maxSoc=100 %, stepSoc=5 %, careCycle=25
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> SoC Step1 Bat 01 - basics -> pvHistory values: yesterday=19, batymaxsoc=94.9 %, batysetsoc=100 %
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> SoC Step1 Bat 01 - basics -> current values: SoC=83.3 %
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> SoC Step1 Bat 01 - basics -> Battery share factor of total required load: 1.00
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> SoC Step1 Bat 01 - basics -> today -> PV fc: 53900 Wh, con till sunset: 24 Wh, Surp: 53876 Wh
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> SoC Step1 Bat 01 - basics -> tomorrow -> PV fc: 64569 Wh, con till sunset: 2096 Wh, Surp: 62997 Wh (75% con)
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> SoC Step1 Bat 01 - basics -> selected energy for charging (the higher positive Surp value from above): 62997 Wh
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> SoC Step1 Bat 01 - basics -> expected energy for charging after application Share factor: 62997 Wh
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> SoC Step1 Bat 01 - compare with SoC history -> preliminary new Target: 100 %
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> SoC Step2 Bat 01 - basics -> Energy expected for charging: 62997 Wh, need until maxsoc: 1283 Wh
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> SoC Step2 Bat 01 - calc care SoC -> docare: 1, care SoC: 100 %, remain days until care SoC: 0, Target: 100 %
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> SoC Step3 Bat 01 - basics -> max SOC so that predicted PV can be stored: -720 %, newtarget: -720 %
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> SoC Step3 Bat 01 - charging probability -> docare: 1, Target: 100 % (no change)
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> SoC Step4 Bat 01 - basics -> docare: 1, lowSoc: 5 %, upSoc: 20 %
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> SoC Step4 Bat 01 - observe low/up limits -> Target: 100 %
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> SoC Step5 Bat 01 - rounding the SoC to steps of 5 % -> Target: 100 %
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> SoC Step6 Bat 01 - force charging request: yes (battery charge is below minimum SoC)
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeMgmt - Inverter 'Fronius_Symo1' cap: 10000 W, Power limit: 100 % -> Pmax eff: 10000 W
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeMgmt - Inverter 'Fronius_Symo2' cap: 12000 W, Power limit: 100 % -> Pmax eff: 12000 W
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeMgmt - Summary Power limit of all Inverter (except feed 'grid'): 22000 W
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeMgmt - The limit for grid feed-in is: 18800 W
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - selected charging strategy: smartPower
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - general load termination condition: 0
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - control time Slot - Slot start: 00:00, Slot end: 23:59
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - control barrier SoC: 50 % / 3840 Wh
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - control barrier Parameter: set:4444
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - Battery efficiency used: 87 %
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - weighted self-consumption: 0 %
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - Target load and target time: 100 % / 7680 Wh / -
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - Percentage of the total amount of charging energy required: 100.0 %
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - The PV generation, consumption and surplus listed below are based on the battery's share of the total amount of charging energy required!
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 - used safety margin: 20 %
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 - charging target: 7680 Wh, E requirement incl. efficiency: 1475 Wh -> target likely achievable? no
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 - Ratio of remaining surplus 130 Wh / energy requirement to achieve the load target: 8.82 %
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 20/10 - hod:11/00, lr/lc:1/1, SocS/E:6397/7680 Wh, SurpH/D:7794/130 Wh, OTP:3000/149 W
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 20/11 - hod:12/01, lr/lc:0/1, SocS/E:7680/7680 Wh, SurpH/D:0/0 Wh, OTP:0/- W
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 20/12 - hod:13/02, lr/lc:0/1, SocS/E:7680/7680 Wh, SurpH/D:0/0 Wh, OTP:0/- W

...

2026.09.20 11:00:04 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 - used safety margin: 20 %
2026.09.20 11:00:04 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 - charging target: 7680 Wh, E requirement incl. efficiency: 1475 Wh -> target likely achievable? yes
2026.09.20 11:00:04 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 - Ratio of remaining surplus 8933 Wh / energy requirement to achieve the load target: 605.75 %
2026.09.20 11:00:04 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 20/11 - hod:12/00, lr/lc:1/1, SocS/E:6397/7680 Wh, SurpH/D:8933/8933 Wh, OTP:1768/1473 W
2026.09.20 11:00:04 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 20/12 - hod:13/01, lr/lc:0/1, SocS/E:7680/7680 Wh, SurpH/D:0/0 Wh, OTP:0/- W
2026.09.20 11:00:04 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 20/13 - hod:14/02, lr/lc:0/1, SocS/E:7680/7680 Wh, SurpH/D:0/0 Wh, OTP:0/- WDu darfst diesen Dateianhang nicht ansehen.
Die Ladeleistung OTP wird daher zum Ende der Stunde immer ans Maximum gezogen und es wird "not Acchievable" angezeigt.
Heute war für PV sogar ein sehr guter Tag, es war reichlich Überschuss vorhanden.

An der SF Config habe ich seit einiger Zeit nichtsmehr geändert, woran könnte das liegen?
Auffällig ist das "SurpH/D" für alle Stunden außer der aktuellen immer 0 ist und "con till sunset" sehr gering ist.


Vielen Dank

Hadl

[DS_Starter]

Nabend Hadl,

Schön mal wieder von dir zu lesen.  Es gibt zwei Punkte die ich sehe ...

1. Die Debug-Meldung ist irreführend formuliert

Die Zeile

Code Auswählen Erweitern

SoC Step6 Bat 01 - force charging request: yes (battery charge is below minimum SoC)
Der Code vergleicht dort nicht mit dem lowSoc (5 %), sondern mit dem berechneten Ziel-SoC (target). Da der target in deinem Fall auf 100 % liegt und 83,3 % < 100 % ist, wird die Ladeanforderung korrekt gesetzt. Der Text "below minimum SoC" ist irreführend, das korrigiere ich in der nächsten Version.

2. Der eigentliche Punkt des Verhaltens (m.M. nach): careCycle und stepSoc

Im Log steht:

Code Auswählen Erweitern

calc care SoC -> docare: 1, care SoC: 100 %, remain days until care SoC: 0, Target: 100 %
remain days until care SoC: 0 bedeutet, dass der Pflegezyklus dauerhaft als überfällig gilt. Dadurch wird docare=1 gesetzt, was den Target-SoC auf 100 % erzwingt — unabhängig von Überschuss oder Tageszeit. Das hält die $soc < $target-Bedingung dauerhaft wahr und zieht in der OTP-Logik zum Stundenende die Ladeleistung ans Maximum, sobald der verbleibende Überschuss der aktuellen Stunde gegen null geht.

Die wahrscheinliche Ursache dafür:
Die Werte stepSoc=5 % und careCycle=25 verletzen eine interne Constraint, die vorschreibt dass stepSoc × careCycle = 100 sein muss (also z.B. 5 × 20 oder 4 × 25). Bei 5 × 25 = 125 ist die Berechnung des Pflegeintervalls nicht mehr stimmig.


Welche Version von SolarForecast ist bei dir aktiv? In der aktuellen Version wird diese Kombination bereits bei der Eingabe geprüft und bei Verletzung der Bedingung abgelehnt.
Korrigiere testweise entweder careCycle auf 20 (bei stepSoc=5) oder stepSoc auf 4 (bei careCycle=25).

Das sollte das Verhalten (vermutlich) normalisieren.

LG,
Heiko

[DS_Starter]

@all,

ich habe soben die V 2.10.4 eingecheckt.
Möglicherweise habe ich ein potentielles Speicherleck bei Verwendung von AI::FANN entdeckt und beseitigt.

Morgen wie gewöhnlich im Update enthalten.

[TheTrumpeter]

Speicherleck bei Verwendung von AI::FANN

Aja... beobachte schon länger stetig steigenden Speicherverbrauch.

Was den Momentanbezug angeht ... meine Batterieanlage funktioniert generell so, dass genau der benötigte Momentan-Netzbezug durch die Bat-Entladung kompensiert wird bis auf einen kleinen Restbetrag. Dazu bedarf es keiner besonderen Konfiguration oder Steuerung, sondern ist Bestandteil der grundlegenden Funktion des ESS. Die Bat entlädt so lange bis der eingestellte optimal SoC oder lowSoC erreicht ist.

Natürlich. Darum geht es mir wie gesagt auch gar nicht.

Ein Anteil meiner Netzentgelte ist abhängig von der Peak-Leistung des Netzbezugs, d.h. für das laufende Monat wird der höchste 15-min-Wert als Basis verwendet. In den Sommermonaten komme ich typischerweise mit dem Mindestwert von 1 kW durch. In diesen Monaten könnte selbst eine kleine Batterie auch den Nachtverbrauch problemlos decken, sodass keinerlei Eingriffe nötig wären. Gleichzeitig sollte selbst an "schlechten" Tagen tagsüber immer wieder bisschen nachgeladen werden können, sodass auch etwaige Bezugsphasen am Tag damit kompensiert werden könnten.
Im Winter könnte es aber sinnvoll sein, die Batterie nachts mit geringer Leistung vom Netz zu laden, um tagsüber Spitzen zu glätten und so von 4-5 kW Netzbezugsentgelt auf 2 kW runterzukommen.
Natürlich lohnt es sich nicht eine Batterie nur deshalb anzuschaffen, aber - falls ich sie anschaffe - wäre das ein zusätzlicher sinnvoller Anwendungsfall.

[DS_Starter]

Moin,

Aja... beobachte schon länger stetig steigenden Speicherverbrauch.

Kann aber auch noch andere Ursachen als SF AI::FANN haben. Gestern hatte ich z.B. noch ein potentielles Speicherleck im FHEM Kern selbst kommuniziert.
Also warten wir mal ab ob es schon der Weisheit letzter Schluß ist. Auch andere Module können noch problematische Speicher-Situationen hervorrufen.

Ein Anteil meiner Netzentgelte ist abhängig von der Peak-Leistung des Netzbezugs, d.h. für das laufende Monat wird der höchste 15-min-Wert als Basis verwendet....

Danke für die Erläuterung. Jetzt habe den Sinn des Anliegens besser verstande, denke ich.
 

[enno]

Moin,

ich bekomme stündlich folgende Warnung:

Code Auswählen Erweitern

PERL WARNING: Use of uninitialized value in string ne at fhem.pl line 5140.
2026.09.21 11:00:05.101 1: stacktrace:
2026.09.21 11:00:05.101 1:     main::__ANON__                      called by fhem.pl (5140)
2026.09.21 11:00:05.102 1:     main::readingsBulkUpdate            called by ./FHEM/76_SolarForecast.pm (36313)
2026.09.21 11:00:05.102 1:     FHEM::SolarForecast::_createReadingsFromArrayFast called by ./FHEM/76_SolarForecast.pm (12788)
2026.09.21 11:00:05.102 1:     FHEM::SolarForecast::__ANON__       called by ./FHEM/76_SolarForecast.pm (12828)
2026.09.21 11:00:05.102 1:     FHEM::SolarForecast::_ctStepTiming  called by ./FHEM/76_SolarForecast.pm (12788)
2026.09.21 11:00:05.102 1:     FHEM::SolarForecast::centralTask    called by ./FHEM/76_SolarForecast.pm (12499)
2026.09.21 11:00:05.102 1:     FHEM::SolarForecast::runTask        called by fhem.pl (4012)
2026.09.21 11:00:05.102 1:     main::CallFn                        called by fhem.pl (855)
Für die Suche habe ich mir an der Stelle ein Log eingebaut. Das sagt mir:

Code Auswählen Erweitern

SolarForecast DEBUG bulkUpdate: reading=[pvCorrectionFactor_11] new=[0.96 (automatic - old factor: 0.77, AI result used, Sun Alt range: 30, Cloud range: 75, Days in range: 4)] old=<undef> elem=[pvCorrectionFactor_11<>0.96 (automatic - old factor: 0.77, AI result used, Sun Alt range: 30, Cloud range: 75, Days in range: 4)] Die Warnung kommt wohl vom fehlenden old=<undef>. Was kann ich tun, um das gerade zu ziehen?

Gruss
  Enno

[DS_Starter]

Hallo enno,

die Warnung habe ich beseitigt und die Funktion _createReadingsFromArrayFast entsprechend gefixt.
Fix liegt in V 2.10.5 in meinem contrib vorab.

LG,
Heiko