93_DbLog - Überlegungen zur Optimierung (RPI und andere Systeme)

[DS_Starter]

Hi Pyro,

du hast also eine Art Zusatzfunktion im Kopf die ein Nutzer explizit ausführen kann weil er zum Beispiel die gewünschte Device:Reading-Kombi in der current-Tabelle nicht findet ?
Oder ist die Idee das bisherige Schreiben in die current-Tabelle generell umzubauen und durch den "select distinct" zu ersetzen ?

LG
Heiko

[Pyromane]

Hallo Heiko,

du hast also eine Art Zusatzfunktion im Kopf die ein Nutzer explizit ausführen kann weil er zum Beispiel die gewünschte Device:Reading-Kombi in der current-Tabelle nicht findet ?

ja, das entspricht meiner Vorstellung.

Gruß
Pyro

[DS_Starter]

Das wäre mal zu überlegen und zu testen wie gut oder schlecht das funktioniert. Da die besherige Arbeitsweise erhalten bleibt und quasi nur ein "Auffüllen" der current aus den vorhandenen Werten in der history durchgeführt wird, könnte ich mir das recht gut vorstellen.
Ein Manko welches ich sehe ist, dass eventuell die Leseperformance der current und somit die Performance bei der SVG-Erstellung leidet da ja bisher keine Empfehlung für einen Index auf die current vorliegt. Das ist ja bei wenigen Datensätzen auch nicht nötig. Möglicherweise bläht sich die current dadurch aber gewaltig auf. Es kann ja sein, dass in der history-Tabelle sehr viele Device:Reading-Kombis vorhanden sind von Devices, die es im System evtl. garnicht mehr gibt (Altlasten) weil der User im Laufe der Zeit viel im System geändert hat ohne Datenbereinigung in der DB zu betreiben usw.

Aber ein interessanter Ansatz, mal schauen.

Mich würde interessieren was andere User dazu sagen ?

LG
Heiko 

[JoeALLb]

Nur um andere Möglichkeiten aufzuzeigen:

- Man könnte die current komplett durch einen View auf die history-Tabelle ersetzen, der genau diese Informationen generiert.
- Man könnte die Current im async-Modus immer beim Schreiben in die DB aus dem memcache heraus aktualisieren bzw. mit befüllen. Ein "set dblogDevice recreateCurrentCache" könnte diesen aus der DB neu erzeugen, falls der cache mal corrupt geworden ist.
- Da die Current-Tabelle nie besonders groß wird, könnte man diese auch komplett im Speicher behalten. -> Diese müsste beim Start von fhem oder besser noch erst beim Öffnen des Ploteditors befüllt befüllt werden.

Eventuell würde ich durch eine Änderung/Verbesserung hier auch dieses Feature nutzen , was mir aber im Ploteditor eigentlich fehlt ist eine Suche über die Devices,
denn eine übervolle Combobox halte ich eher für unpraktisch.

Just my 5 ct, ...

Grüße
Joe

[fhemxperte]

Für mich wäre eine Funktion wie "RemoveCharacterValues" noch interessant. Vielleicht auch für jemand anders?

Aktuell führe ich dies mittels einem AT aus. Vorteil ist, dass falls mal nicht-numerische Werte in die Loggingspalte VALUE kommen, diese damit gelöscht werden. Somit geben die SVG Funktionen auch keine Fehler bzw. Warnings mehr aus. Meistens passiert mir das bei der Neuanlage von Devices.

define AT_DBLogging_FixCharValuesCurrent at *00:50:00 set DBLogging userCommand "DELETE FROM current WHERE VALUE NOT REGEXP '^[+\-]?[0-9]+\\.?[0-9]*$'";;

define AT_DBLogging_FixCharValuesHistory at *00:45:00 set DBLogging userCommand "DELETE FROM history WHERE VALUE NOT REGEXP '^[+\-]?[0-9]+\\.?[0-9]*$'";;

[JoeALLb]

Für mich wäre eine Funktion wie "RemoveCharacterValues" noch interessant. Vielleicht auch für jemand anders?

das geht jetzt schon über valueFN. hier kannst du einfach alle Zahlen ausschneiden (also Werte abschneiden) und den Rest verwerfen,
oder eben das Loggen ganz unterbinden.

[fhemxperte]

ValueFN kannte ich noch nicht, funktioniert prima! Danke für den Tipp. Bei mir sollen halt nur auswertbare Decimalwerte im Logging landen. Falls einer möchte, hiermit habe ich das gelöst und es wird direkt angezeigt von welchem Device eine falsche Meldung kommt:

{
   if ($VALUE =~ m/^[-+]?\d+(\.\d+)?$/) {
      #Log 3, "DBLogging: Value ".$VALUE." from device ".$DEVICE." was logged.";
   } else {
      Log 3, "DBLogging: Value ".$VALUE." from device ".$DEVICE." was not logged.";
      $IGNORE=1;
   }
}

[JoeALLb]

Danke fürs teilen!

...Bei mir sollen halt nur auswertbare Decimalwerte im Logging landen.

Ich habe devices, die leider manchmal irgendwelche Zusätze oder eben auch , statt . nutzen,
diese kann man hier auch noch schön abbilden/korrigieren.... aber das siehst Du dann ja schön in deinem Log.

[DS_Starter]

Hallo zusammen,

Rudi hat ja mit neuesten Blocking.pm ein neues Abbruchargument ausgeliefert.
Ich habe die V2.22.10 so erweitert dass bei einem evtl. Abbruch dieses Argument genutzt wird.
Es ist zwar nur eine kleine Änderung, aber möchte sie dennoch hier zum Test zur Verfügung stellen bevor ich einchecke.

Bitte checked es auch bei euch.

VG
Heiko

[Pyromane]

Hallo Heiko,

Test läuft.
Melde mich später mit dem Ergebnis.

Gruß
Pyro

[JoeALLb]

Hallo Heiko,

Bitte checked es auch bei euch.

danke, aber hast Du eine Idee, wie ich diesen Fall konstruieren kann?
Wenn ich korrekt verstehe müsste ich während dem schreiben in die MySQL-Datenbank diese abschalten... dafür hätte ich in meinen Beispielen keine 0.1s zeit...

sG
Joe

[DS_Starter]

Hi Joe,

den konkreten Fehlerfall zu provozieren ist mE nach schwierig. Ich will nur sicher gehen dass die Version bei euch, unter Umständen mit älteren Blocking.pm, problemlos läuft.
Man könnte theoretisch die fehlerhafte Blocking.pm Version 15172 vom 2017-10-02 benutzen die diesen Abbruch fälschlicherweise häufig wirft.
Aber das will ich eigentlich niemanden zumuten sich so zu verrenken. Ich habe sie aber noch parat wer möchte ...

LG
Heiko

[Amenophis86]

Ich weiß gerade nicht, ob ich mich dazu an dich, oder an Rudi wegen FHEMWEB wenden muss. Ich hätte gerne, dass bei den DBLog Device auch der Link für "Create SVG instance" angezeigt wird. Würde das erstellen von Plots ein wenig vereinfachen

EDIT:
OK, vergiss es. Es steht oben links bei DBLog und nicht unten dabei, wie ich es von FileLog gewohnt war

[DS_Starter]

Hallo zusammen,

ich habe mich mit dem Vorschlag von Pyro zum "Fillup" der current-Tabelle beschäftigt und auch eine Lösung implementiert.
Allerdings habe ich mich dafür entschieden diese Funktion in DbRep zu implementieren. Das hat unter anderem den Vorteil dass man die Fillup-Funktion durch die Attribute device, reading, timestamp_begin, timestamp_end begrenzen kann.

So werden z.B. die Device/Reading-Kombinationen aus der history ausgewertet/extrahiert die letzten Monat eingetragen wurden wenn  "timestamp_begin=previous_month_begin" und "timestamp_end=previous_month_end" gesetzt wurde. Das so eingestellte DbRep-Device kann man dann regelmäßig laufen lassen um die Funktion auszuführen.

Darüber hinaus gibt des im DbRep nun die Funktion "tableCurrentPurge" um die current Tabelle zu leeren. Das kann sinnvoll sein wenn sie zu groß geworden ist oder vllt. unerwünschte EInträge enthalten sind. Evtl. vorhandene Indizes bleiben erhalten.

D.h. es gibt nun in der DbRep V5.7.0 die Funktionen:

* set <dbrep-device> tableCurrentPurge - löscht den Inhalt der current-Tabelle
* set <dbrep-device> tableCurrentFillup - ergänzt den Inhalt der current Tabelle aus einem select der histrory-Tabelle unter Beachtung der Select-Eingrenzung durch device,reading und timestamps

Die DbRep-Version könnt ihr euch zum Test hier: https://forum.fhem.de/index.php/topic,53584.msg452567.html#msg452567 herunterladen.
Das DbLog-Device sollte auf jeden Fall im asynchronen Modus betrieben werden.

(konsequenterweise müsste ich im DbLog das Attr DbLogType noch um eine Auswahlmöglichkeit "samplefill/history" ergänzen. Bei dieser Auswahl wird die current nicht aktiv geloggt, aber bei der SVG-Erstellung ausgewertet. Damit könnte man sie ausschließlich regelmäßig über DbRep füllen).

Die DbLog-Version  V2.22.10  checke ich nachher noch ein.

Grüsse,
Heiko

[Pyromane]

Hallo Heiko,

Die DbLog-Version  V2.22.10  checke ich nachher noch ein.

hat sich bei mir absolut unauffällig verhalten.

Allerdings habe ich mich dafür entschieden diese Funktion in DbRep zu implementieren.

Das wäre dann wohl ein guter Grund mich mit DbRep zu beschäftigen.
Nur liegt derzeit mein Testsystem im Sterben(Festplatte oder SATA Controller) und mir fehlt gerade ein wenig die Zeit um mich darum zu kümmern.

Gruß und gute Nacht
Pyro