Hallo,
leider habe ich über die SUFU/Google keine Antwort auf meine Frage gefunden.
Trotz Löschung der Datei "EventTypes.txt" (inkl. Clear & Flush), bereinigen meiner MySQL-Datenbank, diverser "DBLogExcludes" und Neustart befinden sich sehr viele, oft gleichartige Einträge in der Event-Auswahlliste zur Erstellung eines Plots (s. Anlage).
Wie kann ich diese Liste bereinigen/aktualisieren?
Vielen Dank für eure Hilfe!
PS: FHEM ist aktuell
PPS: Hier die Definition meiner DbLog:
define dbLog DbLog db.conf .*:.*
attr dbLog room Logs
Die Excludes mache ich im jeweiligen Device.
Das würde mich auch sehr interressieren.. >:(
Die Einträge des Devices, welches dort nicht angezeigt werden soll aus der Datenbank löschen, sollte helfen.
Oder das DbLog-device einfach per Attribut auf "History" konfigurieren.
Leider helfen mir die beiden Antwort nicht weiter. Vielleicht könntet ihr das noch ein wenig präzisieren? Danke!
Zitat von: marvin78 am 01 August 2016, 13:01:33
Die Einträge des Devices, welches dort nicht angezeigt werden soll aus der Datenbank löschen, sollte helfen.
Wie ich geschrieben habe, habe ich alle unnötigen Events in der DB gelöscht.
@betateilchen: Welches Attribut meinst du beim dbLog-Device?
das kenn ich auch *g*
wie schon geschrieben: einfach die "toten" devices in mysql (oder anderer db) löschen.
ich hab mir einfach phpmyadmin installiert, du kannst aber natürlich alles andere auch nehmen, was dir zugriff auf deine db gewährt.
der befehl für z.b. mysql würde dann in etwa so lautenDELETE FROM `current` WHERE DATEDIFF(NOW(), `TIMESTAMP`) >= 5
das würde dann aus deiner tabelle "current" alles seit 4 tagen (>=5) nicht genutzte löschen. die tage kannst natürlich nach deinem eigenen feeling einstellen.
da in current eh nur die aktuellsten daten stehen, kannst dir auch nix an alten daten ruinieren - die stehen in der history.
Zitat von: veeroohre am 22 Juli 2016, 09:48:39Trotz [...] bereinigen meiner MySQL-Datenbank
Die DB ist clean. phpmyadmin ist installiert.
"SELECT device, reading FROM `history` group by device, reading"
liefert 94 Zeilen und die sind ok. Wo kommen die anderen Einträge her?
Noch andere Ideen?
Aus der Current Tabelle, nicht aus der History! Das Thema hatte ich auch schon mal.
Mea culpa, wer lesen kann ist klar im Vorteil!
Hätte ich nicht gedacht, dass sich das Drop-Down-Feld aus der Current die Devices und Readings holt. Finde ich unlogisch, da die Werte später ja aus der History kommen.
Zitat von: betateilchen am 01 August 2016, 13:13:09
Oder das DbLog-device einfach per Attribut auf "History" konfigurieren.
Was war denn damit gemeint? Kann mich jemand aufklären? Ziehen die Drop-Down-Felder danach die Devices und Readings aus der History? Falls ja, fände ich das als Default-Einstellung die bessere Wahl.
Vielen Dank für eure nette Hilfe!
Es ist sogar sehr logisch. Wenn man überlegt, dass in der history Tabelle Millionen von Datensätzen vorkommen und in der current Tabelle nur die aktuellen, kann man sich auch denken, warum current verwendet wird (Performance). Stellt man auf history um, wird in den Drop-Downfeldern natürlich nichts mehr angezeigt bzw. gibt es sie nicht. In der current Tabelle befindet sich ja dann nichts.
Das alles ist im Übrigen auch dokumentiert. Neben der Tatsache, dass es auch in den Beiträgen hier im Thread zu erkennen ist, natürlich....
Das sehe ich aus Newbie-Sicht anders.
Weder habe ich in der DBLog-, der Plot noch einer anderen (ok, ich habe nicht alle nachgesehen) Dokumentation etwas gefunden.
Auch bringt die Sufu bei den Wörtern "dblog drop-down plot" nur sehr wenige Einträge zurück. Diese Wörter schienen aus meiner Sicht, das Minimum, was in einem passenden Thread auftauchen sollten.
In welcher Dokumentation finde ich dazu etwas bzw. welche Suchwörter wären passender gewesen? Vielleicht kann ich dann in Zukunft so offensichtlich unnötige Anfragen im Anfänger-Forum unterlassen.
@veeroohre: das Einzige, wo ich Dir zustimme, ist der Punkt, dass das Attribut DbLogType offenbar vom Modulautor wirklich nicht dokumentiert ist.
Der Rest Deiner Diskussion ist müssig. Warum, hat marvin78 schon schön erklärt.
(Und übrigens, ich finde eine DbLog regexp .*:.* schon nicht sonderlich sinnvoll. Aber das ist ein anderes Thema.)