93_DbLog - kleine, evtl. nützliche Wünsche

Begonnen von chris1284, 26 Dezember 2014, 10:05:46

Vorheriges Thema - Nächstes Thema

chris1284

Moin,
Ich habe die tage mal mein dblogfile angesehen und es war mit knapp 3gb recht groß in knapp einem Jahr, fhem dadurch etwas träge (Plots).
Mir fiel auf das man für gezieltes loggen mit dblog im Gegensatz zu FileLog viel mehr Aufwand betreiben muss um dies zu konfigurieren.
(bei FileLog einfach autocreate aus und nicht mehr kümmern, bei zu loggenden devices einfach das File mit entsprechenden readings die zu loggen sind definieren)

Das fängt damit an das man DbLog nicht ohne regexp definieren kann. ohne regexp würde DbLog erst einmal nichts loggen, wäre aber bereit zur Nutzung. das wäre ein optimaler Ausgangspunkt.
In devices kann man nur mit DbLogExclude arbeiten, ein DbLogInclude wäre wünschenswert. Warum? Am Beispiel eines HM-CC-RT Clima-Channel oder Sysmon-Device ist das einfach erklärt.

Bei sysmon will ich nun cpu_temp, cpu0_freq und cpu1_freq loggen. ich muss also ein

attr Sysmon DbLogExclude cpu_bogomips,cpu_temp_avg,eth0,eth0_diff,eth0_ip,fhemuptime,fhemuptime_text,idletime,idletime_text,loadavg,perl_version,power_ac_stat,power_ac_text,power_battery_info,power_battery_stat,power_battery_text,power_usb_stat,power_usb_text,ram,root,stat_cpu,stat_cpu0,stat_cpu0_diff,stat_cpu0_percent,stat_cpu0_text,stat_cpu1,stat_cpu1_diff,stat_cpu1_percent,stat_cpu1_text,stat_cpu_diff,stat_cpu_percent,stat_cpu_text,swap,uptime,uptime_text,wlan0,wlan0_diff bei einem device mit 40 readings sehr umständlich
nehmen statt der einfachen Version wenn es einen DbLogInclude gäbe

attr Sysmon DbLogInclude cpu_temp, cpu_freq,cpu1_freq
oder device komplett
attr Sysmon DbLogInclude .*
mein aktueller Workaround:
dblog logged alles, neue devices bekommen autom. ein blog exclude verpasst.
-> evtl. auch eine Option: in dblog eine Art attr <dblog> autolog off / oder 0 was dazu führt das DbLogInclude .* autom. gesetzt wird.

Bestehenden devices habe ich DbLogExclude .* per attr .* DbLogEnclude .* und erstmal grob die wieder inkludiert die ich loggen will deleteattr TYPE=CUL_HM DbLogEnclude
nun wäre der schritt noch alle nicht gewünschten readings zu excluden.

Ein define dblog DbLog <conffile> .*:(temperature|valveposition|humidity).* wäre genau so umständlich wie das 3 Zeilen Exclude im Sysmon wenn man viele untersch. devices hat die man teilweise vollständig loggen will. mehrere regexp in der DEF gehen scheinbar auch nicht, so das man ggf, div. typen angeben kann + div. Namensgebungen

sowas wie define <> dblog file TYPE=CUL_HM, .*._HZ_Clima, az_.*.:temperature, bla:bla

roedert

Sinnvoller ist es meist, die gewünschten Readings in der DB-Log-Definition zu hinterlegen.
In den einzelnen Devices ist dann keine weiter Definition für DbLog erforderlich.
Sieht bei mir zB so aus

def DbLog DbLog dblog.conf .*(Katzenklappe.Sensor|Thermostat_Climate|Fenster(|.L|.M|.R)|_Pwr|Heizung(|.L|.R)_Clima|Luefter|Kuehlschrank|Spuelmaschine|Gas7[02]|Strom(70|72|.EDV)|Helligkeit|[Tt]emperatur|Temp|Wetter|Twilight|dunkel|Klingeltaster):(ValvePosition|window|consumption.*|controlMode|cooling|working|current|desired-temp|humidity|inside|kWh_[tl].*|level|measured-temp|power|temperature|total|twilight|time_[01]|ring).*

Benni

Hallo,

nachdem ich kürzlich auch auf dblog umgestellt habe bin ich auf diesen Thread gestoßen und dachte mir, den muss man doch nochmal hoch holen.

Ich wünsche mir eigentlich das selbe wie chris1284 und arbeite im Moment auch genau so: DBLog loggt alles und per und bei jedem einzelnen Device wird aber erst mal alles wieder per DBLogExclude ausgeschlossen. Bei Bedarf werden dann dort die RegEx(en) entsprechend angepasst, was aber bei einem Device mit vielen Readings, von denen man evtl. nur 2 oder 3 im Log braucht recht aufwändig sein kann. Außerdem ändern sich Readings ja auch gelegentlich mal. (Bspw. nach einem Update oder nach einem Peering)

Ich musste also relativ schnell feststellen, dass ein DBLogInclude die einfachere Methode sein könnte: Sprich standardmäßig wird nichts geloggt, außer dem was in DBLogInclude eingetragen ist.

Gruß Benni.

MarkusN

Moin,

ein dbloginculde hatte ich auch vor einiger Zeit mal vorgeschlagen. Mindestens genau so interessant wäre aber die Möglichkeit die Datenbank zu verdichten, soll heißen die Auflösung/Frequenz der Daten wird mit fortschreitender Zeit immer geringer. Vielleicht könnte sowas sogar ein Script übernehmen.

Grüße,

Markus

Benni

Das ist sicherlich interessant, wäre aber doch eigentlich eher Datenbankmanagement an sich und gehört damit m.E. nicht in das DBLog-Modul.

Gruß Benni.

Benni

#5
Hallo,

ich habe das bei mir mal ausprobiert und bei mir ein Attribut DbLogInclude eingebaut, ebenso wie ein Attribut am DbLog-Device (DbLogSelectionMode), mit dem das Handling der device-spezifischen Attribute DbLogExclude und DbLogInclude festgelegt werden kann.

Ich bin jetzt (noch) nicht so der Perl-Programmierer, deshalb kann man das eventuell auch noch eleganter lösen, es hat aber bei mir in ersten Tests soweit sehr gut funktioniert.

Ein Patch zur aktuell im SVN vorhandenen Version von 93_DbLog.pm habe ich mal angehängt. Es enthält auch die entsprechend erweiterte Doku in beiden Sprachen.

Vielleicht kann es ja so, oder so ähnlich in DbLog integriert werden. 8)

Kurz zur Funktionsweise:

Es gibt analog zu DbLogExclude eine Attribut DbLogInclude, das an alle devices propagiert wird.
Weiterhin gibt es, wie oben schon erwähnt ein neues Attribut DbLogSelectionMode, dass festlegt, wie DbLogExclude und DbLogInclude behandelt werden sollen:

DbLogSelectionMode kann dabei folgende 3 Werte haben:


  • Exclude: DbLog verhaelt sich wie bisher auch, alles was ueber die RegExp im DEF angegeben ist, wird geloggt, bis auf das, was ueber die RegExp in DbLogExclude ausgeschlossen wird. Das Attribut DbLogInclude wird in diesem Fall nicht beruecksichtigt
  • Include: Es wird nur das geloggt, was ueber die RegExp im DEF angegenben wurde und sonst nichts, es sei denn es wird ueber die RegExp in DbLogInclude eingeschlossen.Das Attribut DbLogExclude wird in diesem Fall nicht beruecksichtigt.
  • Exclude/Include: Funktioniert im Wesentlichen, wie "Exclude", nur das sowohl DbLogExclude, als auch DbLogInclude geprueft werden: Readings, die durch DbLogExclude zwar ausgeschlossen wurden, mit DbLogInclude aber wiederum eingeschlossen werden, werden somit dennoch geloggt.
Wird DbSelectionMode nicht angegeben, so wird Exclude als Default angenommen, damit verhält sich DbLog ohne die Angabe des Attributes also genau so wie bisher (=abwärtskompatibel).

chris1284

tobiasfaust ggf anschreiben  ;) damkt er die,wirklich nützlichen, änderungen einpflegt

Benni

Hallo Chris,

danke für den Hinweis, ich habe ihm mal eine PM geschickt.
Mal sehen, was draus wird :)

Gruß Benni.


Tobias

Maintainer: Text2Speech, TrashCal, MediaList

Meine Projekte: https://github.com/tobiasfaust
* PumpControl v2: allround Bewässerungssteuerung mit ESP und FHEM
* Ein Modbus RS485 zu MQTT Gateway für SolarWechselrichter

Benni

Freut mich! 8)
Kannst du denn schon sagen, wann das in etwa sein wird?


Benni

#10
Nachdem man ja nicht so genau weiß, wie lange es noch dauert, bis die Änderungen in die produktive Version integriert sein werden, veröffentliche ich hier auch mal noch das gesamte geänderte Modul (Basis war Version 6573 2014-09-19 17:08:11Z), damit evtl. gleich noch mehr Leute die Funktionalität testen können.

Zur Installation:

  • Backup machen! (von FHEM und Datenbank in die geloggt wird)
  • Das hier angehängte Modul im fhem-Verzeichnis unter FHEM/ ablegen (i.d.R. /opt/fhem/FHEM) und FHEM neu starten (shutdown restart).
  • Modul-Doku lesen (in der Kommandozeile in FHEMWEB help DbLog eingeben.

!!! Unbedingt Beachten:

  • Bei einem regulären update des Moduls wird das nach obiger Methode installierte natürlich wieder überschrieben.
  • Eventuell wird die Implementierung vom eigentlichen Modul-Maintainer später nicht 1:1 übernommen, was dann zu Fehlfunktionen und erhöhtem Anpassungsaufwand nach einem regulären update führen kann.


Ich habe das Modul inzwischen übrigens in meiner produktiven FHEM-Installation laufen. 8)

ph1959de

Zitat von: Benni am 01 Mai 2015, 12:57:40
!!! Unbedingt Beachten:

  • Bei einem regulären update des Moduls wird das nach obiger Methode installierte natürlich wieder überschrieben.
  • Eventuell wird die Implementierung vom eigentlichen Modul-Maintainer später nicht 1:1 übernommen, was dann zu Fehlfunktionen und erhöhtem Anpassungsaufwand nach einem regulären update führen kann.

Um diese Probleme zu umgehen, kann man das (globale) Attribut exclude_from_update (siehe commandref) benutzen ... muss dann natürlich irgendwann mal wieder entfernt werden, sobald die Änderungen offiziell sind und im regulären Update kommen.

Peter
Aktives Mitglied des FHEM e.V. | Moderator im Forenbereich "Wiki"

Benni

#12
Zitat von: ph1959de am 01 Mai 2015, 16:24:17
Um diese Probleme zu umgehen, kann man das (globale) Attribut exclude_from_update (siehe commandref) benutzen ... muss dann natürlich irgendwann mal wieder entfernt werden, sobald die Änderungen offiziell sind und im regulären Update kommen.

Tatsächlich habe ich das bei mir auch so gemacht  8) und mir den Hinweis darauf auch absichtlich gespart. Denn wie du geschrieben hast, ist das nur ein Umgehen, bzw. Verscheiben der Probleme und man muss zusätzlich noch beachten, bzw. im Hinterkopf behalten, dass man ein reguläres Update damit verhindert.  ;)

Btw. ich weiß gar nicht, ob bei einem update check überhaupt auf  ein solche vom Update ausgeschlossenen Files hingewiesen wird oder nicht  ???
Hab's gerade getestet: Auf solche Files wird dabei nicht hingewiesen!

Tobias

#13
Hi,
testet mal bitte... hier sind mehrere Patches drin:

- SuppressUndef (http://forum.fhem.de/index.php/topic,36615.msg289041.html)
- Hinzufügen von Anfang und Ende-Werten beim Ploten in engen Grenzen (http://forum.fhem.de/index.php?topic=34006)
- 93_DbLog_DbLogInclude.diff
- 93_DbLog_dbReadings_using_DbLogType.diff


Nach OK, checke ich es ein...
Maintainer: Text2Speech, TrashCal, MediaList

Meine Projekte: https://github.com/tobiasfaust
* PumpControl v2: allround Bewässerungssteuerung mit ESP und FHEM
* Ein Modbus RS485 zu MQTT Gateway für SolarWechselrichter

Benni

Hallo Tobias,

es war bei DbLogInclude doch noch ein kleiner Fehler drin.  :-[
Beim reinen "Include" - Modus und Komplettausschluß aller events im DEF (bspw. mit none:none als RegEx) ist die Anwendung nie in den Überprüfungszweig gelaufen. Ich habe das entsprechend in Zeile 525 so angepasst, dass bei Include grundsätzlich auch die restliche Überprüfung durchgeführt wird.
(Es ist übrigens tatsächlich sogar so, dass bei Include die Angabe der RegEx in DEF grundsätzlich ignoriert wird, und auch nur geloggt wird, was per DbLogInclude eingeschlossen wird -> Doku angepasst)

Außerdem waren in der Doku noch ein paar Formatierungen nicht ganz in Ordnung, die habe ich ebenfalls gleich noch angepasst.

Ich hänge hier einfach mal das komplette Modul (auf Basis deiner Testversion) mit den o.a. Änderungen hier an.

Gruß Benni.