Datenreduktion in Fhem per MySQL

Ist-Zustand

Mit Fhem hatte ich klein angefangen und gemäß der Einsteiger-Anleitung für meine Geräte Filelog's definiert. Fhem läuft seit Beginn auf einem Raspberry Pi I Rev B. Angefangen hatte ich mit 4 Heizungsreglern und 3 Thermostaten von Homematic. Es kamen nach und nach anderen Sensoren und Akteure hinzu. Fhem pfeift inzwischen auf dem letzten Loch. Die Filelogs sind riesig.

Seit einem halben Jahr werkelt der schnellere Banana-Pi als Fileserver in unserem Haus. Er hat eine SATA-Festplatte und externe USB-Festplatte zum Backup. Was liegt näher, als die Daten dorthin auszulagern. Für ein späteres Projekt möchte ich die Daten einfach auswerten können, sprich sie müssen in eine Datenbank. Gut dokumentiert ist die Nutzung von MySQL und Fhem. Es werden aber auch andere Datenbanken unterstützt. Im Nachgang war MySQL nicht die beste Wahl. Aber es funktioniert.

Natürlich ging es nicht ohne Stolpersteine. Gemäß dem Motto "never touch a running system" hatte ich auf Updates verzichtet. Es lief ein Jahr altes System auf dem Raspberry. Die Pakete für meine Version waren online nicht mehr verfügbar. Normal erledigt sich die Installation vom mySQL-Clienten einfach, es ist nur eine Zeile in der Kommandozeile. Aber wenn man anfängt alte Bibliotheken im Internet zu suchen und nachzuinstallieren, kann viel schief gehen. Letztlich habe ich das Handtuch geworfen, alles gesichert, dass neuste Raspbian-Image gezogen und alles neu gemacht :-(.

Die Umstellung von FileLog zu DbLog ist kinderleicht. Es gibt zahlreiche Anleitungen im Internet. Eine Empfehlung ist das Skript zur Migration der alten Daten. Bei mir stürzte der Rechner zufällig während des Script-Durchlaufes ab. Die Hälfte der Daten war nun schon in der Datenbank. Ein erneuter Durchlauf würde also diese Daten duplizieren. So habe ich noch eine Prüfung nachgerüstet, ob der Datensatz bereits migriert wurde. Nach x-Tagen gelegtlichen Durchläufen, war es vollbracht. Die alten Daten in der Datenbank. Per

 use fhem;
 select count(*) from history;

komme ich auf 12 Millionen Werte in der Tabelle "history". Oh mein Gott.

Vorüberlegung

Zukünftig Datenflut einschränken?

Die Sensoren spucken intervallsweise jede Menge Werte aus. Daten kann man die Daten in Fhem durch das Attribut "event-on-change-reading" einschränken. Für Bewegungsesnoren, Lichtmelder habe ich das genutzt eingesetzt und konnte die Daten auf wenige Werte pro Tag einschränken.

# Event nur, wenn sich Pinlevel ändert
attr Pin35 event-on-change-reading Pinlevel

# Logge nur Pinlevel
define DbLog_LichtBad DbLog /etc/fhemdb.conf Pin37:.*Pinlevel.*

Aber bei diskreten Werten hat das gewisse Nachteile

Plotabriss über 0 Uhr Grenze ( http://www.fhemwiki.de/wiki/Plot-Abriss_vermeiden)
Die Kurven würden verfälscht werden. z.B. Temperaturwerte aller 5 Minuten 16°, 20°, 20°, 20°, 18° würden zu 16°, 20°, 18°. Abhilfe wäre die Kurvenform steps, nun die Temperatur springt aber nicht von 16-20 Grad. Steps eignen sich eher für binäre Zustände weniger für diskrete Messwerte. Also bleibe ich doch lieber bei den linearen Kurven. (Splines u.ä. kann Fhem ohnehin nicht)
Ob Readings sinnvoll sind oder nicht entscheiden oft die Werte. z.B. dass der Motor im Ventil "ok" freut mich und sollte immer so sein, aber mich interessiert sobald der Fehler auftritt. Ein vorab-Filter per event-on-change-reading ist somit nicht immer möglich.

Wie auch immer, bei mir ist das Kind ohnehin in den Brunnen gefallen, sprich ich muss mir Gedanken machen, was ich löschen kann.

Unnützes Löschen

Hier lohnt sich ein Blick in die Tabelle, welche Werte möchte man wirklich anzeigen oder anderweitig nutzen. Da ich mit das Taupunkt-Modul arbeite, hat diese ungewollt und redundant das Reading "T" mitgeliefert. Auch Reading 'state' wird auch gerne redundant abgelegt. State soll ja nur den Status des Moduls wiedergeben und ist meist Standard, wie nichtssagend. Oft basteln die Entwickler eigener Module eben aussagekräftige Readings dazu. So hat man eben ein Reading mit der Temperatur, die aber auch im 'state' enthalten ist. Reading 'winOpenReporting' hatte ich nie genutzt. Kann weg.

Bei mir ist das Kind ohnehin schon in den Brunnen gefallen. Nach ca. 10 Monaten mit Daten 4 Heizungsreglern , 3 Thermostaten wollte ich die Daten auswerten. Als Filelog schlecht möglich, daher stellte ich auf DbLog um. Hier ein nettes Script , was wunderbar arbeitet. https://www.snip2code.com/Snippet/120357/FHEM-filelog-to-dblog-mysql-migration Aber weiter im Text... nach erfolgreicher Migration war ich bei ca. 5 Millionen Einträgen. Beim Durchsehen der Daten fällt auf, dass ich viele Daten nicht brauche, gerade ob der "Motor ok" benötige ich nicht. Diese kann man schnell aus der Datenbank löschen. Übrig bleiben die relevanten Messerte.. Oft habe ich lineare Verläufe, mit Stützwerten dazwischen, die man nicht bräuchte. zB. 3.04 Uhr 10 ° | 3.05 Uhr 10 ° | 3.06 Uhr 10 ° | 3.07 Uhr 10 ° 3.08 Uhr 11 ° Die Informationen um 3.05, 3.06 bräuchte man nicht. Fhem würde so oder so zwischen 3.04 und 3.07 Uhr eine Linie bei 10 ° zeichnen. Aufpassen müsste man an den Tagesgrenzen , da Fhem nur die Daten vom aktuellen Tag ranzieht. Die Punkte um 0 bzw. 24 Uhr sollte man also tunlichst nicht löschen. Das sind die Start- und Endpunkte der Linie. Wissenschaftlich ist das natürlich nicht ganz sauber. Würde es um wichtige Daten gehen, würde ich zumindest die alten Daten noch sichern, oder wenigstens vermerken wie viele an den ersten Messwert schreiben, wie viele ich gelöscht habe und auch nur löschen, wenn die Messwerte im Messtakt liegen. Hier nutze ich die Daten Entschuldigt bitte vorab, den kruden SQL - Code. MySQL ist nicht in der Lage temporäre Tabellen mehrfach zu nutzen (join itself geht nicht). Die MySQL ist nach wie vor weit von einer professionellen DB entfernt. Wie es aussieht strotzt MySQL nur so an Bugs und Eigenheiten.