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);

[DS_Starter]

Diese Events melden aus meiner Sicht keine fachliche Zustandsänderung, sondern nur erfolgreiches internes Housekeeping.

Ich bin sogar geneigt diese Events generell herauszunehmen. Es gibt im Fehlerfall einen Logeintrag, den man bei Bedarf mit einem notify abgreifen kann.
Mit dem state-Event wird die Aktualisierung der Grafik in der Raumansicht ausgelöst, was vermutlich der Grund für die relativ hohe Verzögerung ist (je nach Umfang der Grafik und der Systemleistungsfähigkeit). Aber dafür reicht der Event des normalen Zyklus.



 

[DS_Starter]

@all,

in meinem contrib liegt die V2.10.1.
Ich habe die besprochenen state-Events (und noch einige weitere) entfernt.
Bis jetzt zeigen sich keine negativen Auswirkungen.

LG,
Heiko

[Flachzange]

Danke, sieht gut aus.

[300P]

n meinem contrib liegt die V2.10.1.
Ich habe die besprochenen state-Events (und noch einige weitere) entfernt.
Bis jetzt zeigen sich keine negativen Auswirkungen.

Doch - mein RPI4 hat angekündigt das er jetzt zwischendurch einen Kaffee trinken gehen will, da er jetzt alle 15 Sekunden zwischen 0.5 - 1.7 Sekunden "totalen Leerlauf" beim "special_runTimeCentralTask" hat - was das nur kosten wird.       

Total average phase times: 0.916 s (compared to special_runTimeCentralTask). ->>> war vor ein paar Wochen noch ca. 1.0 sek - 2.7 Sekunden bei mir.  

DANKESCHÖN !!!!🤩🤩🙏

PS:
Bin aber weiter parallel dabei mit FHEM in einen QNAP-Container umzuziehen - dann werd ich ihm wohl den Stecker ziehen       

[DS_Starter]

Ich habe die V 2.10.1 mit den kleinen Verbesserungen eingecheckt. Wird morgen früh wie gewöhnlich im Update sein.

[300P]

Hallo Zusammen!

so - bin gestern dann von meinem RPI4 auf einen Qnap-LXD-Container mit aktuellem Debian-Bookworm umgestiegen.

Der Performance-Sprung ist bislang noch nicht so richtig für greifbar, hatte mir dadurch etwas mehr versprochen.
Gefühlt sind Grafiken und Anzeigenaufbau und allgemeine Laufzeiten etwas geschmeidiger - aber da warte ich für eine endgültige Angabe noch ein paar Tage ab.

Hier der direkte Laufzeitvergleich in SF auf/in dem LXD-Container :
->> Total average phase times: 0.860 s (compared to special_runTimeCentralTask) V2.10.1 am 23.08.2026 ( nach ca. 1 Tag Laufzeit)

gegenüber kurz vorher auf dem RPI4 mit:
->> Total average phase times: 0.916 s (compared to special_runTimeCentralTask) V2.10.1  am 21.08.2026  ( auch ca. 1 Tag Laufzeit)
Aber Ergebnis das kann auch schon allein schon an den letzten cash-Optimierungen von Heiko beim letzten update liegen. Der Cache macht schon sehr sehr viel aus!!!

Ansonsten aber ein relativ einfacher Umzug mittels Filezilla-Kopieorgie vom RPI4 direkt auf die LXD.
Nur das Fritzbox-Device meckerte rum das ich ein perl-Modul vergessen hab vorher dafür zu installieren.

Eventuell feile ich noch etwas an den Einstellungen des Container - mal schauen ob ich da noch was finde das wirklich was bringt.

Gruß am kalten Sonntag mit etwas Sonne
300P

[DS_Starter]

Hallo zusammen, @300P,

es kommt sicherlich darauf an ob dein QNAP eine x86 CPU oder einen ARM Prozessor hat. Im letzteren Fall würde ich behaupten dass RPi4 und QNAP ARM ebenbürtig sind?

LG,
Heiko

[300P]

Ich hab mal den Schlaumeier im Netz gefragt

->> Meinen QNAP ist nicht viel schneller als der RPI4 mit SSD-Platte

Die konkreten Geschwindigkeits-Vorteile des QNAP:
Festplatten- und NAS-Durchsatz: Beim Raspberry Pi hängt die SSD an USB 3.0, was Bandbreite und CPU-Overhead erhöht. Die QNAP nutzt echte SATA-Anschlüsse (inkl. RAID-Unterstützung). Das bringt konstantere Transferraten (z.B. volle 1 Gbit/s oder 2.5 Gbit/s Netzwerkauslastung ohne Schwankungen) und bessere Schreib/Lese-Latenzen bei vielen kleinen Dateien.

Alles andere wie Videotranscoding / Virtiualisierung ist bei FHEM als WEBSERVER ja nicht anfallend.

Da ich keine "heiße rennende QNAP-Höllenmaschine" sondern ein etwas betagteres QNAP-System habe.....ist die darin vorhanden X86-CPU n.m.M. als gleichwertig anzusehen.

Also werde ich wohl damit nicht viel an CPU-Geschwindigeitsvorteil haben werden......

ABER :
->> jetzt brauche ich mir auch da keine Sorgen über Backups mehr machen, meine FHEM-MariaDB läuft schon seit 2020 da drauf.
->>Raid5-System SSD mit ständig bereitstehender "Ersatzplatte" und (GFS) backup strategy als Snapshot etc.