76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Dann nimm dir Battery_ChargeOptTargetPower_01:300 explizit in event-min-interval testweise mit hinein wie bei mir.

[DS_Starter]

Habe bei mir jetzt spaßeshalber

  event-min-interval=.*:300,Current_Surplus:300,Current_BatCharge_01:300

gesetzt.
Klappt genauso problemlos.

[300P]

Battery_ChargeOptTargetPower_01:300

Ergänzt:

Code Auswählen Erweitern

attr Forecast event-min-interval .*:300,state:5,Battery_ChargeOptTargetPower_01:300,Battery_ChargeOptTargetPower_02:300


Ergebnis:
bislang kein Treffer18:11 Uhr



oder liegt es am download (evtl. mit Fehler)
Aber da geht nix heute per download aus dem Contrib - Fehler 503 - No Server......

[DS_Starter]

Sehr komisch ... auf die harte Tour

event-on-update-reading=Battery_ChargeOptTargetPower_01

setzen.
Du hast nach dem Update bestimmt restartet, oder?

[300P]

Weiterhin gähnende leere nach mehr als 5 Minuten..... (Filter = .*Forecast.*)
Im Kontrolfenster kommen Einträge (auch ohne ...OptPower...)    (Filter: .*Battery_ChargeOptTargetPower_.*) 


Ja - 100 % - heute auch schon nochmals.


event-on-update-reading=Battery_ChargeOptTargetPower_01

ist ab jetzt drin
 

[300P]

Ei der Daus:

Nach :
event-on-update-reading=Battery_ChargeOptTargetPower_01

[Flachzange]

So ist mal drei Tage still hier, dann kann ja mal wieder

@Flachzange, @all,

in meinem contrib liegt ein Update der V2.9.2.
Intergriert ist eine Lösung für das File/DB-Readproblem.

Danke Heiko. Das funktioniert jetzt.


Ich habe mir periodicWriteMemcache() noch einmal angesehen, weil die Funktion bei mir in apptime weiterhin auffällig war.

Vor der Änderung:

max      421 ms
average  224.89 ms

Im Event Monitor war dabei zu sehen, dass ein einzelner periodischer Cache-Write vier Events erzeugt:

wrote cachefile circular successfully
wrote cachefile pvhist successfully
wrote cachefile solcastapi successfully
wrote cachefile messages successfully

Diese Events melden aus meiner Sicht keine fachliche Zustandsänderung, sondern nur erfolgreiches internes Housekeeping. Trotzdem laufen sie jeweils durch den normalen FHEM-Eventdispatcher.

Das ist relevant, weil FHEM den Haupt-Eventloop seriell verarbeitet. Ein periodicWriteMemcache() mit durchschnittlich rund 225 ms bedeutet also, dass FHEM während dieses Zeitfensters mit diesem Vorgang beschäftigt ist. Timer oder andere Events, die genau dann anfallen, können erst anschließend verarbeitet werden.

Ich habe deshalb testweise nur diese Erfolgsevents bei den Aufrufen aus periodicWriteMemcache() unterdrückt. Die eigentliche Cache-Persistenz bleibt unverändert.

Danach:

max      32 ms
average  23.77 ms

Das entspricht etwa:

Durchschnitt: -89 %
Maximum:      -92 %

Die Funktion läuft damit bei mir im Mittel ungefähr Faktor 9,5 schneller.

Soweit ich im Modulcode sehen kann, werden diese wrote cachefile ... successfully-Events intern von SolarForecast nicht für die Ablaufsteuerung benötigt. Das Schreiben der Daten ist bereits abgeschlossen, bevor das Event erzeugt wird.
 
Mein Vorschlag wäre daher, bei periodicWriteMemcache() auf die einzelnen Erfolgsevents zu verzichten. Andere, explizit ausgelöste Cache-Writes könnten ihre Events weiterhin behalten. Ich beschränke den Änderungsvorschlag bewusst auf periodicWriteMemcache(), weil dort regelmäßig mehrere rein technische Erfolgsevents in einem automatischen Housekeeping-Lauf entstehen und genau dieser Pfad in apptime dauerhaft auffällig war;

Aktuell habe ich dafür den bereits vorhandenen vierten Parameter $nolog verwendet. Semantisch wäre upstream eventuell ein eigener Schalter wie $noevent oder $silent sauberer.:

Code Auswählen Erweitern

singleUpdateState(
    {
        hash  => $hash,
        state => "wrote cachefile $cachename successfully",
        evt   => 1
    }
) if(!$nolog);

Code Auswählen Erweitern

writeCacheFile($hash, 'circular',   $pvccache.$name,    1);
writeCacheFile($hash, 'pvhist',     $pvhcache.$name,    1);
writeCacheFile($hash, 'solcastapi', $scpicache.$name,   1);
writeCacheFile($hash, 'messages',   $messagecache.$name, 1);