93_DbLog contrib v5.12.0 - SVG Datenlieferung über SubProzess zum Testen

[DS_Starter]

Schon längere Zeit arbeitete ich an einer Lösung um die Datenlieferung für SVG Plots über den vorhandenenen SubProzess
realisieren zu können.
Zur Zeit werden mit FHEMWEB plotfork=0 die Daten synchron immer wieder von der Datenbank abgefragt was suboptimal ist und zu Verzögerungen/Blockierungen führenkann.
Mit plotfork=1 wird dieser Nachteil beseitigt, allerdings wird der Vorteil mit dem Nachteil des (temporären) Speichermehrverbrauchs durch Perl fork erkauft.
Die Version 5.12.0 bietet sowohl den Vorteil einer größtenteils von der DB entkoppelten unverzögerten Datenlieferung
und vermeidet den Nachteil der forkens durch die Nutzung des verbundenen SubProzesses.

Das DbLog Modul besitzt in der neuen Version das Attribut plotCacheLifetime. Per default ist es mit "0" nicht aktiviert und DbLog verhält
sich bezüglich SVG Datenlieferung wie bisher.

Mit Setzen plotCacheLifetime > 0 wird ein SVG-Cache innerhalb DbLog und eine veränderte SVG-Datenlieferung aktiviert.

plotCacheLifetime <Sekunden>

    Cacht die an SVG-Plots gelieferten Daten. Solange ein Cache-Eintrag jünger als plotCacheLifetime Sekunden ist, wird eine identische Plot-Anfrage (gleiche Devices/Readings und gleicher Zeitraum) direkt aus dem Cache beantwortet, ohne Datenbankzugriff.
    Ist ein Cache-Eintrag älter als plotCacheLifetime, wird die nächste Anfrage dafür trotzdem sofort aus dem (dann veralteten) Cache-Eintrag beantwortet, während im Hintergrund über den DbLog-SubProzess asynchron ein Refresh geholt wird (stale-while-revalidate). Die darauffolgende Anfrage wird dann aus dem aktualisierten, frischen Cache-Eintrag beantwortet.
    Dies erfordert das Attribut plotfork=0 im/den betreffenden FHEMWEB-Device(s): Der Cache lebt im Geräte-Hash von DbLog und ist für einen von plotfork abgespaltenen Kindprozess nicht sichtbar - dortige Cache-Schreibzugriffe gehen beim Beenden des Kindprozesses verloren. Ist dennoch plotfork=1 gesetzt, wird einmalig eine Warnung geloggt und der Cache für dieses FHEMWEB-Device umgangen.
    (default: 0 - deaktiviert, jede Plot-Anfrage fragt wie bisher direkt die Datenbank ab)
 
 
Der Lieferprozess verändert sich dadurch wie folgt:

    1. **SVG** ruft wie bisher aus DbLog unverändert `get <DbLog> - INT <from> <to> <readings...>` auf.
   
   2. **DbLog** prüft zuerst den Cache (`$hash->{HELPER}{PLOTCACHE}`, Schlüssel
       aus Zeitraum/Device/Readings/Tabelle):
      
       - **frischer Treffer** (jünger als `plotCacheLifetime`): sofortige Rückgabe, kein DB-Zugriff.
       - **veralteter Treffer**: der alte Wert wird sofort zurückgegeben (keine Blockierung),
         zusätzlich wird im Hintergrund ein Refresh angestoßen (weiter mit Schritt 3).
       - **kein Treffer** (Signatur nie gesehen): synchroner Fetch mit Cache-Befüllung (weiter mit Schritt 3).
   
   3. **SubProzess** neue Operation `refreshplotdata`): baut die
       SQL-Statements über dieselben Funktionen wie der synchrone Pfad und führt sie über die eigene, langlebige
       DB-Verbindung aus und schickt die Rohzeilen zurück.
   
   4. **DbLog** Elternprozess empfängt die Rohzeilen und ruft `_DbLog_plotData` im
       **Replay-Modus** (`prefetched`) auf: exakt dieselbe Verarbeitungslogik (delta-h/delta-d,
       RegExp, Aggregation) wie im synchronen Pfad, nur mit vorab gelieferten Zeilen statt
      Live-DB Zugriff. Das Ergebnis wird im Cache abgelegt.
   
   5. **SVG** erhält beim nächsten Aufruf den nun aktualisierten, frischen Cache-Eintrag.
   
   
Damit der Cache nicht unkontrolliert wächst, werden gecachte Daten mit TTL=60 Minuten gelöscht.

Die Version 5.12.0 liegt in meinem contrib. Wer sie ausprobieren möchte, muß bitte nach dem Download FHEM neu starten.
Danach läuft alles wie bisher gewohnt weiter.
Erst mit Setzen von plotCacheLifetime=X (z.B. 30) UND Setzen von plotfork=0 im FHEMWEB Device wird die neue Technologie aktiviert.

Das Attribut sampleDataCacheLifetime aktiviert einen Caching-Mechanismus für den integrierten Plot-Editor und beschleunigt das Handling.


ToDos: - der configCheck ist noch nicht auf die Technologie angepasst.
       - ideal wäre ein direktes asynchrones return der Daten aus dem SubProzess in einen SVG Einstiegspunkt. Aber das würde eine
         zeitgleiche Änderung von SVG und vermutlich auch svh.js bedeuten was ich nicht allein ausführen kann.      

LG,
Heiko