[Wunsch]93_DbLog - individuelles Loggen in selbstbenannten Tabelen

[chris1284]

Hi,

wäre es möglich eine Funktion einzubauen die es ermöglicht in selbstdefinierten Tabellen zu loggen?
ich fände es gut wenn ich zB: sagen könnte das alle RTs in table Heizung loggen, alle Wettersensoren  in table Wetter und wenn nichts definiert ist halt in die Standard Tables
es würde sich evtl anbieten wie beim, erst durch Einsatz des DbLog verfügbaren, Attribut DbLogExclude ein Attribut für DbTable zur Verfügung zu stellen mit dem man am device selbst per Attribut sagen kann wo es geloggt wird. Die Tabellen müssen auch nicht autom. erzeugt werden, kann der User ja selbst (muss er beim Einrichten DbLog eh).
Wäre wie ich finde eine nützliche Erweiterung.

Gruß

Christian

[JoeALLb]

Und die Plots müssten dann auch wissen,  aus welcher Tabelle gelesen werden sollte?
Welche Vorteil versprichst du dir dadurch?
Du könntest über die tabellenpartionierung die Daten jetzt schon Aufspaltung,  ohne Codeänderung an fhem.

Gesendet von meinem Xperia Pro mit Tapatalk

[chris1284]

Und die Plots müssten dann auch wissen,  aus welcher Tabelle gelesen werden sollte?

woher ein plot die Daten nehemn soll muss man in der Regelr doch eh festlegen.

Welche Vorteil versprichst du dir dadurch?

hast du dir ja quasi mit dem stichwort

tabellenpartionierung

schon selbst beantworte. kleinere tabellen, mehr performance.
und wenn man einem nicht sql-fachman die wahl lässt ob er betimmte sachen in einer extra tabelle speichert oder eine große patitioniert wird er wohl ersteres nehmen

genau dies prinzip mit extra tabellen wurde ja auch schon mit current und history verfolgt.

und nebenbei gefragt: gibt es eine Möglichkeit das loggen in Textfiles zentral zu deaktivieren oder muss ich das selbt für alle devices händisch machen?

[betateilchen]

Das ist doch absurd.

Wenn Du getrennte Logs haben willst, nimm einfach FileLog. DbLog hat ja genau den Vorteil, dass man eben nicht mehr mit einzelnen Logs rumhampeln muss.

Und das mit der Tabellenperfomance ist auch kein Argument. Ich habe DbLog mit 50 Mio Datensätzen aus 2000 Devices ohne Performanceprobleme getestet.

[Puschel74]

Hallo,

ich fände es gut wenn ich zB: sagen könnte das alle RTs in table Heizung loggen, alle Wettersensoren  in table Wetter und wenn nichts definiert ist halt in die Standard Tables

Wie betateilchen schon gesagt -

nimm einfach FileLog.

Ich versteh den Sinn dahinter nicht - wieso soll ich den Vorteil einer Datenbank (alles in einer Datei zu haben) wieder vernichten indem ich die Device wieder in eigene Tabellen loggen lasse?
Aber gut, ich verstehe hinter so vielem den Sinn nicht 

Grüße

[marvin78]

Der einzigen "Sinn", den ich mir vorstellen kann, ist beispielsweise, dass man Temperaturwerte etwas länger vorhalten will, als andere Werte und/oder sie in einem externen Tool auswerten möchte und die restlichen Daten dort nicht benötigt. Das kann man aber auch realisieren, in dem man diese Werte einfach in eine weitere Tabelle weg schreibt.

[chris1284]

Das ist doch absurd.

deine meinung ....

Wenn Du getrennte Logs haben willst, nimm einfach FileLog. DbLog hat ja genau den Vorteil, dass man eben nicht mehr mit einzelnen Logs rumhampeln muss.

andere vorteile bieten datenbanken ja auch nicht. und datenbanken mit mehreren tabellen, evtl auch noch verknüpft, totaler unsinn und völlig absurd. #
deine config-db hat glaube ich auch mehr als eine tablle ......

Und das mit der Tabellenperfomance ist auch kein Argument. Ich habe DbLog mit 50 Mio Datensätzen aus 2000 Devices ohne Performanceprobleme getestet.

schön, aber selbst du musst zugeben das eine abfrage über eine tabelle mit nur halbsovielen (zb. 25mio) datensätzen messbar schneller wäre (als bei 50 mio)

wie ich im vorschlag schrieb wäre es optional, also keine angst das dich einer zwingt das auch so zu machen....

Der einzigen "Sinn", den ich mir vorstellen kann, ist beispielsweise, dass man Temperaturwerte etwas länger vorhalten will, als andere Werte und/oder sie in einem externen Tool auswerten möchte und die restlichen Daten dort nicht benötigt.

danke, genau das ist szenario was ich am laufen habe. und genau da ist es schwachsinn mio-datensätze auszuwerten wenn ich nur eine handvoll brauche.
klar kann ich das auch datenbankseitig mit jobs in eine andere db/tabelle exportieren aber warum der aufwand wenn man schon beim loggen viele folgeschritte/mehrabreit verhindenr könnte. das "händische" kopierne erzeugt, ne nach dem wie aktuell die 2. tabelle sein soll, auch wieder unnötige last.

[marvin78]

Es müsste möglich sein ein zweites DbLog anzulegen mit dem du die benötigten Werte logst (andere DB nötig). Das ist natürlich nur ein Workaround.

[chris1284]

daran habe ich auch schon gedacht. konnte es leider noch nicht testen aber steht auf noch auf der liste.
@betateilchen: genau hier könntest du dein kommentar bezüglich nur einer datei einbringen. hier hätte man dann wirklich unnötigerweise 2 datenbankdateien!

[chris1284]

und noch ein anwendungsfall. ich logge von einer anderen fhem-instanz über netzwerk auf dem gleichen db-server wie der 1. instanz
hier habe ich nun ein 3. db-file (1. fhem dblog instanz 1, 2. betsimmte daten aus instanz 1 seperat, 3. log einer 2. instanz)

-> abhilfe würde auch hier zb die option der eigenen tabellenangabe bringen (wie zb.: history_pi, current_pi) und das nicht nur wie im 1. anwendungsfall für ein device sondern das ganze dblog
(2 attribute im device dblog könnten zur konfig dienen, eines für name history-tabelle, eines name current-tabelle).
ja auch hier könnte ich spiegeln, exportieren usw usw, eleganter wäre es dennoch direkt aus dem modul.
würde ich nun auch wieder von instanz 2 neben dem full-log ein spezielleres benötigen wäre das schon das 4 db-files obwohl man auch alles in eine db schrieben könnte (mit x tabellen)

[chris1284]

Für letzteren Einsatzzweck habe ich bereits selbst Änderungen hinzugefügt und es läuft bisher rund. Ich habe eine DB mit 4 Tabellen
history, current, historyPi, currentPi

ich habe:

define erweitert um 2 zusätzliche Optionen

define <name> DbLog configuration regexp (history:<Name>) (current:<Name>)"

werden die nicht genutzt wird weiterhin in "current" und "history" geschrieben
zu sehen in den internals als TABLECURRENT und TABLEHISTORY
alle stellen wo im Modul mit festen Tabellennamen  gearbeitet wurde, habe ich diese durch variablen ersetzt.

Evtl. kann sich Tobias das ja mal ansehen und falls gut mit übernehmen. Screenshot und Modul im Anhang. Getestet nur mit MySql

[betateilchen]

bei mir loggen drei fhem Installationen auf ein und dieselbe Datenbank (auf einem 4. System) - völlig ohne Probleme.

Zusätzlich werden einige immer nur kurzfristig (weniger als 48 Stunden) benötigte Logdaten in einer sqlite Datenbank jeweils auf dem lokalen System vorgehalten, um den Traffic im Netzwerk zu reduzieren. Man kann DbLog Definitionen anlegen, soviele man will, warum sollte das nicht funktionieren? Das einzige was ich mir dabei wünschen würde, wäre eine zusätzliche Spalte "Host" um in der Datenbank direkt erkennen zu können, von welchem System die jeweilige Logzeile stammt.

[chris1284]

bei mir loggen drei fhem Installationen auf ein und dieselbe Datenbank (auf einem 4. System) - völlig ohne Probleme.

Machen sie bei mir 2 Systeme und 2 Devices nun auch. Eine DB mit 2 Tabellen in der einfach jeder host sein Zeug rein wirft ist ja schon möglich gewesen, nur nicht 1 DB unterschiedliche Tabellen um das loggen zu individualisieren / zu strukturieren. Das hat auch den Vorteil das ich für alle Gerät ein configfile für die DB zentral ablegen kann statt eines auf alle hosts zu kopieren.

wäre eine zusätzliche Spalte "Host" um in der Datenbank direkt erkennen zu können, von welchem System die jeweilige Logzeile stammt.

dieses Problem ist bei mir nun nicht mehr existent da jeder Host (und auch 2 Devices) ihre eigenen Tabels haben. Sprich will ich wissen was der PI loggt schau ich in die Tabellen des Pi ( in der gleichen DB  wie auch der Cubie und der Wettermast loggt).

Die Spalte host ist ja auch recht einfach einbaubar denke ich, ist aber eine Fleißaufgabe das neu Feld in jedes statement einzubauen Ein neues Feld in die Tabellen mit einzubauen ist ja auch kein Akt.

[jschmitt]

Hallo allerseits,

ich habe im März die Datei 93_DbLog.pm von chris1284
gerne übernommen.

Leider hatte ich das Problem, daß nach einem REBOOT des
Systems FHEM schneller zu Werke kommt als MySql.

(Den Neustart muß ich machen, verschiedene Gründe).
Mit der Folge von Fehlern, Datenbank noch nicht bereit...
Seitdem wurde das Original- Modul 93_DbLog erweitert/gepatched.
Alldieweil ich aus der Datenbank die Option benötige SVG- Plots,
auch aus anderen Tabellen als "current" oder "history" zu erstellen,
melde ich mich hier nochmal:
Wurde sowas mittlerweile eingebaut?
Meine Tabellen werden nun mal von "außen" befüllt. Ich will die nur per SVG- Plot darstellen.
Oder gibt es da was eleganteres?

Es wäre EXTREM praktisch, auf Tabellen anderen Namens als "current" oder "history" zugreifen zu können.
Solche Tabellen dürfen ja auch die aktuelle Struktur der bereits vorhandenen aufweisen müssen.
Nur trennen sollte man die Datenherkunft in der Lage sein. Alles in einer Tabelle ist Kuddelmuddel
und bei externer Auswertung schwer nachvollziehbar.

@chris1284:
welche Codezeilen in der Datei 93_DbLog sind/ waren der Knackpunkt bzw.
hast Du eine aktualisierte Version dieses Moduls?


Viele Grüße,

Johannes

[chris1284]

die änderungern waren sehr einfach und es lief stabil.

Wurde sowas mittlerweile eingebaut?

nein, aber schön wäre es natürlich weiterhin. ist ja auch nicht viel zu ändern.

@chris1284:
welche Codezeilen in der Datei 93_DbLog sind/ waren der Knackpunkt bzw.
hast Du eine aktualisierte Version dieses Moduls?

im prinzip musst du nur:
- DbLog_Define anpassen, was genau siehst du wenn du meine und dblog vergleichst
- in den sql-statements current und history durch variablen ersetzen und
- in den sub's vor dem ausführen der statements die variablen aus dem hash befüllen

die aktuelle dblog hab ich mir dahingehend noch nicht umgebaut da ich noch meine "alte" verwende.
aber ja, es wäre toll wenn diese kleine änderung produktiv gehen würde