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

[DS_Starter]

Hallo enno,

prima, habe den Thread jetzt kurz überflogen. Scheinen ja noch mehr betroffene vorhanden zu sein und testen vllt. dann auch.

LG,
Heiko

[JoeALLb]

das Attribut "excludeDevs " füttert ganz trivial die devspec2array-Funktion. Die bringt dann das Ergebnis zurück.
Das sollte ganz normal funktionieren.

Danke für die Erklärung.
Es loggt aber KEIN Device, das das angegebene Filterreading nur "enthält". Ich bin davon ausgegangen, dass es dann lediglich
das angegebene Reading nicht loggt, nicht alle Readings.

sg
joe

[DS_Starter]

Hi Joe,

Es loggt aber KEIN Device, das das angegebene Filterreading nur "enthält". Ich bin davon ausgegangen, dass es dann lediglich
das angegebene Reading nicht loggt, nicht alle Readings.

Das Attribut heißt "excludeDevs" (exclude Devices) und ist wörtlich zu nehmen. Alle Devices, die in dem Attribut angegeben sind, werden vom Logging ausgeschlossen. devspec gibt auch ein oder meherere Devices zurück, die gemäß der devspec Angabe matchen. Diese Devices werden dann ausgeschlossen.

LG,
Heiko

[JoeALLb]

Hallo Heiko,

Verstehe... Dann schlage ich ein DbLogExkludeGlobal direkt im DbLog Device vor, um, analog zum normalen DbLogExklude beim Device gewisse Readings allgemein vom Logging auszuschließen.

Zur Hintergrunderklärung: ich bekomme viele KNX devices automatisch angelegt und möchte gewisse sinnlose Informationen einfach generell vom Logging ausschließen, bevor ich dazu komme das von Hand immer nachzuziehen.....


SG Joe

[DS_Starter]

Reicht es nicht bestimmte Readings im DEF generell auszuschließen ?
Zum Beispiel so um "done" nicht zu loggen:

Code Auswählen Erweitern


.*:(?!done).*


Das müsste m.M. nach ausreichen.

[kadettilac89]

Hi DS_Starter,

darf ich dich um ein kleines Update in der Commandref bitten? Ich habe es schon mehrfach gelesen, dass Anwender auf DBLog umstellen, jedoch noch die kurzen Felder in der Datenbank nutzen, und dadurch verschiedene Probleme hochkommen ... Readings abgeschnitten, Plots leer, ...

Hintergrund ist, dass der contrib-Ordner in der Fhem-Installation beim Update nicht beachtet wird. Somit wird manchmal ein veraltetes Script genutzt obwohl im Github eine korrekte Version liegt. Mein contrib-Ordner ist z. B. von Anfang 2015 obwohl die Installtion aktuell ist. Das Verhalten ist für User selten bekannt.

Den Wiki-Eintrag hast du mit erstellt, zumindest stehts du als Author mit dabei. Ähnlich im Commandref wäre gut.

Mein Vorschlag: in der Commandref ausschließlich auf die Scripts im Github verweisen, im Wiki ist der Link schon enthalten. Oder alternativ den Link auf github einfügen mit dem Hinweis, dass dieses Script dort immer das aktuelle ist, und im Fhem-Ordner ggf. nicht.

Beispiel eines solchen Posts ...
https://forum.fhem.de/index.php/topic,17201.msg777876.html#msg777876

Danke dir!

[JoeALLb]

Reicht es nicht bestimmte Readings im DEF generell auszuschließen ?
Zum Beispiel so um "done" nicht zu loggen:

Code Auswählen Erweitern


.*:(?!done).*


Das müsste m.M. nach ausreichen.

Hallo Heiko,
Funktioniert  bei mir nicht, danach zB alle Alarme von 1wire Sensoren nicht speichern möchte, da ich diese nicht nutze, und die Standard Alarmtemperatur ständig überschritten wird. Andere Alarme interessieren mich jedoch sehr. Aber auch dazu würde das globalExclude nicht ausreichen, dazu müsste es DEVSPEC:Reading verstehen können....

SG Joe

[DS_Starter]

Guten Morgen,

@kadettilac89 ... Ich habe die commandref dahingehend überarbeitet wie du vorgeschlagen hast. Es wird auf das Verzeichnis mit den aktuellen Scripten im SVG verlinkt. Die kann man sich dann anschauen oder runterladen.
Außerdem habe ich noch einen Abschnitt "Troubleshooting" am Anfang mit eingefügt, der Hilfestellung zur Vorgehensweise bei Problemen zu Beginn mit DbLog bieten soll. Die neue Version ist eingecheckt und  morgen früh im Update, schau mal ob es nun so für den User hilfreich ist.

@Joe, bin mir noch unsicher wie ich dir helfen kann.

Dann schlage ich ein DbLogExkludeGlobal direkt im DbLog Device vor, um, analog zum normalen DbLogExklude beim Device gewisse Readings allgemein vom Logging auszuschließen.

Wenn ich es richtig interpreriere, dann würde ein Attribut im DbLog, welches eine Liste der global auszuschließenden Readings enthält (ähnlich excludeDevs wobei natürlich keine devspec verwendet werden können), ausreichen um das Ziel zu erreichen. Richtig ?

LG,
Heiko

[JoeALLb]

@Heiko: korrekt! Kein globales Attribut für alle Devices, sondern nur für das DbLog-Device.

SG Joe

[DS_Starter]

Hallo Joe,

anbei die V3.9.0. Das Attribut excludeDevs ist erweitert um Readings auch ausschließen zu können.

excludeDevs

    attr <device> excludeDevs <devspec1>[#Reading],<devspec2>[#Reading],<devspec...>

    Die Device/Reading-Kombinationen "devspec1#Reading", "devspec2#Reading" bis "devspec..." werden vom Logging in die Datenbank global
    ausgeschlossen.
    Die Angabe eines auszuschließenden Readings ist optional.
    Somit können Device/Readings explizit bzw. konsequent vom Logging ausgeschlossen werden ohne Berücksichtigung anderer Excludes oder Includes 
   (z.B. im DEF). Die auszuschließenden Devices können als Geräte-Spezifikation angegeben werden. Für weitere Details bezüglich devspec siehe Geräte-
   Spezifikation.

    Beispiel
    attr <device> excludeDevs global,Log.*,Cam.*,TYPE=DbLog
    # Es werden die Devices global bzw. Devices beginnend mit "Log" oder "Cam" bzw. Devices vom Typ "DbLog" vom Logging ausgeschlossen.
    attr <device> excludeDevs .*#.*Wirkleistung.*
    # Es werden alle Device/Reading-Kombinationen mit "Wirkleistung" im Reading vom Logging ausgeschlossen.
    attr <device> excludeDevs SMA_Energymeter#Bezug_WirkP_Zaehler_Diff
    # Es wird der Event mit Device "SMA_Energymeter" und Reading "Bezug_WirkP_Zaehler_Diff" vom Logging ausgeschlossen.

Bitte mal testen ob alles so funktioniert wie beabsichtigt.

Grüße,
Heiko

[kadettilac89]

@kadettilac89 ... Ich habe die commandref dahingehend überarbeitet wie du vorgeschlagen hast. Es wird auf das Verzeichnis mit den aktuellen Scripten im SVG verlinkt. Die kann man sich dann anschauen oder runterladen.
Außerdem habe ich noch einen Abschnitt "Troubleshooting" am Anfang mit eingefügt, der Hilfestellung zur Vorgehensweise bei Problemen zu Beginn mit DbLog bieten soll. Die neue Version ist eingecheckt und  morgen früh im Update, schau mal ob es nun so für den User hilfreich ist.

Danke dir!

[JoeALLb]

Hallo,
Bin gerade erst heimgekommen, Werd's mir morgen gleich Mal testen!

Danke, SG Joe

[JoeALLb]

Hallo Heiko,

diese Lösung entspricht aber im Prinzip der Lösung, die Du weiter oben vogeschlagen hast, oder?

Code Auswählen Erweitern

.*:(?!done).*.
Sämtliche Devices vom Typ OWSERVER mit dem reading "alarm" kann ich damit jedoch nicht ausschließen: Ich bräuchte also eher die Screibweise:

Code Auswählen Erweitern

attr <device> excludeReads [<devspec>:]<Reading1>,[<devspec>:]<Reading2>,[<devspec>:]<Reading..>

um

Code Auswählen Erweitern

attr <device> excludeReads TYPE=OWSERVER:alarm

nutzen zu können.

Ein weiterer Wunsch:
Können wir aus

Code Auswählen Erweitern

    $exr    =~ s/\s/,/g;
durch

Code Auswählen Erweitern

    $exr    =~ s/(?:\s|\n)/,/g;

ersetzten, damit ich auch die mehrzeilige Konfiguration nutzen kann?Die ist für meine Anzahl an Devices viel übersichtlicher!

sG
Joe

[DS_Starter]

Hallo Joe,

jetzt habe ich es erst richtig verstanden was du willst bzw. brauchst.
In dem Fall könnte ich mir etwas überlegen das vorhandene Attribut excludeDevs zu erweitern und die dahinter
iegende Funktion auszubauen.
Ich melde mich wieder mit einer veränderten Version.

Grüsse,
Heiko

[DS_Starter]

Hallo Joe,

habe das Modul überarbeitet und in  #669 neu hochgeladen.
Weil die devspec bereits den Trenner ":" kennt, habe ich für die Trennung des Readings "#" eingeführt.
Mit verbose 4 wird im Logfile ausgegeben wenn etwas ausgeschlossen wurde.
Teste mal bitte erneut.

Grüße
Heiko