Das Thema #Datenbank-Logging mit #FHEM ist jetzt auf der Zielgeraden.
Folgende Erkenntnisse (aus diversen Webseiten zusammen gesammelt):

1. Man kommt nicht umhin, in jedes Gerät einmal zu schauen. Dort das Attribut #DbLogExclude auf .* setzen. Wenn man Punkt 2 befolgt, ist das für neue Geräte dann nicht mehr notwendig.
2. Neue Geräte sollten erst einmal gar nichts loggen. Das Loggen wird explizit für ganz bestimmte Readings dieser Geräte freigeschaltet: define defaultAusschluss notify global:DEFINED.* attr $EVTPART1 DbLogExclude .*
3. Im Datenbankdevice muss das #DbLogSelectionMode Attribut auf Exclude/Include gesetzt sein.
4. Im Datenbankdevice muss das #DbLogType Attribut auf Current/History gesetzt sein.
5. Es sollte nur gelogged werden, wenn sich das Reading geändert hat (#event-on-change-reading wird auf .* gesetzt. Hier muss man natürlich aufpassen, zu pauschal darf man das nicht sehen, bei kummulierenden Readings können auch unveränderte Readings notwendig sein.
5. zu loggende Readings definiert man am besten direkt in jedem Gerät. bei einer klassischen #TASMOTA Steckdose hab ich z.B. das #DbLogInclude Attribut auf ENERGY_Current,ENERGY_Power,ENERGY_Today,ENERGY_Voltage,ENERGY_Yesterday gesetzt.

Wenn man das alles berücksichtigt, bleibt die Datenbank überschaubar.

Also: Explizit auswählen, was man loggen will und nur loggen, wenn es Änderungen gibt.
Abschliessend die Datenbank säubern, sprich alle überflüssigen Einträge löschen (über Abfragen, ich hab mir dazu ein paar MS-Access Abfragen definiert). Die current-Datenbank sollte man vielleicht einmal komplett leeren, die füllt sich ja grundsätzlich wieder von selbst.

Nächste Woche kommt der zusätzliche Arbeitsspeicher, mit dem Lala (also mein Server) aufgerüstet wird. Dann werden noch diverse MariaDB-Optimierungen gestzt, um Abfragen und generell das Handling der Datenbank etwas flutschiger zu machen.

Wenn das alles geschafft ist, können die Programmroutinen angepasst werden, die heute noch auf die Geräte direkt zugreifen. Mit der Current-Datenbank ist es ja vergleichsweise leicht, auf die Gerätewerte zuzugreifen. Und dann sinkt hoffentlich der Duty-Cycle wieder. Zur Erinnerung: Das war der ursprüngliche Grund für die ganzen Orgien der letzten Tage.

3. Akt der #FHEM-MIgration
#Filelog auf #DBlog umstellen.

Also das war kein Akt, das war ein Trauerspiel, eine furchtbare Kombination von Unwissenheit und Unverständlichkeit.

Zuerst die positiven Dinge: #MariaDB zu installieren war einfach, den FHEMUSER als Datenbankbenutzer anzulegen war einfach, aber vermutlich begannen da schon die Probleme. Die Tabellen anzulegen war trivial. Und das Umstellen in FHEM ein Klacks. Das Ergebnis war: FHEM sagte: verbunden. Gut. Dann kam ich auf die Idee in FHEM einen #configCheck zu machen. Und der meldete: nicht verbunden.

Versteh ich nicht.

Der state sagte connected und das Ergebnis meinte das Gegenteil.

Und wenn ich die kryptischen Aussagen auf der Kommandoebene von MariaDB richtig deutete, wurden auch keine Daten gespeichert.

Ich hab dann mal auf #asyncMode gestellt. Und dann ist der Cache explodiert.

Also das System will loggen, aber der Datenbankzugriff geht nicht.

Das hatte ich mir schon bei der Anlage des FHEMUsers gedacht.

Ich musste etwas komfortabler in das Datenbanksystem schauen. Auf Lala, dem Server, war #phpMyAdmin installiert. Aber der kann nur auf den Rechner schauen, auf dem er installiert ist. Abver da ich mit dem klarkomme, kam ich auf die Idee, das Tool auch auf Shinobu zu installieren (dem FHEM-Rechner).

Und das Drama begann.

phpMyAdmin wollte unbedingt den Apache-Webserver. Nunja, von mir aus. Im Zuge der Installation explodierte die Zahl der Datenbankbenutzer von zwei (root und FHEMuser) auf 5 oder 6. Keine Ahnung warum das so sein muss. Irgendwann ging es ans Editieren der Config-Dateien. Und spätestens hier war ich praktisch im Blindflug. Ich hatte keine Ahnung was ich da tat.

Aber es war erst einmal soweit erfolgreich, dass ich über Shinobu tatsächlich über phpMyAdmin auf die Tabellen zugreifen konnte.

Ein Teil meiner Konfiguration schien zwar kaputt gewesen zu sein, zwei dort angelegte User und deren Tabellen waren offensichtlich falsch.

Und dann traf ich die folgenschwere Entscheidung: Ich brauche zwei User: root und FHEM. Der Rest muss weg. Alle markiert und Entfernen geklickt. Dann wurde ich noch gefragt, ob auch deren Tabellen weg sollen, das bejahte ich. Und dann war plötzlich alles weg. Ich konnte in phpMyAdmin nichts mehr tun.

Also die allwissende Müllhalde, Google, befragt. Dort wurde mir nur bestätigt, was ich schon wusste, die mysql.db war weg. Und ich solle die wieder anlegen. Ging nicht, ich glaube ich habe in den nächsten Stunden alle möglichen Fehlermeldungen die das System erzeugen kann persönlich begrüßt.

Nicht einmal Deinstallieren und Neuinstallieren haben geholfen. Nur neue Fehlermeldungen suchten meine Bekanntschaft.
Irgendwann fand ich ein Posting das zumindest die Dauermeldung, irgendwas mit Socket, korrigierte und ich meinem root wieder Zugriff geben konnte.

Aber ich war jetzt so genervt, ich hab alles eliminiert: phpMyAdmin, Apache, MariaDB. Und ich habe die FHEM konfiguration auf Lala umgebogen. Denn da lief die Datenbank. Und das war ja der Ausgangspunkt: Mit dem RASPI3 (Chihiro) war das so langsam, dass FHEM nicht mehr bedienbar war. Naja, mit nur 1 GB war Chihiro aber auch wirklich sehr leichtgewichtig. Shinobu mit ihren 8 GB RAM war es egal. Man merkte nicht mal, dass auf einen anderen Server geloggt wurde.

Fazit: Die Investition in Shinobu, 149,-, war erfolgreich. Ich habe das Logging auf Datenbank umgestellt und es lief zufriedenstellend. Allerdings loggt er viel zu viel Müll.

Die erste Aktion ist also, den Umfang der zu loggenden Geräte/Readings zu reduzieren.

Blöd scheint nur zu sein, dass man keine kompletten Geräte bzw. Gerätegruppen ausschliessen kann, nur Readings. Ein #DbLogExclude mit ECHO_* geht also nicht. Aber in jedem Echo ein DbLogExclude mit *.*, welches alles Readings des Gerätes ausschliesst, geht. Nunja, ist ein Anfang.

Jetzt werden erst einmal die Plots umgestellt. Dann die Logs eingeschränkt und zum Schluss, der eigentliche Grund für die ganze Orgie, die Programmierungen, die dann nicht mehr auf die Geräte zugreifen soll, sondern auf die Log-Daten. Und das nur, um den Duty-Cycle der #CCU3 (ja, die hat keinen eigenen Namen) auf unter 20 zu drücken.
Bis dahin muss ich mir noch anschauen, wie ich mit #Perl auf Datenbanken zugreife.
Also langweilig wird mir so schnell nicht...

Die Einträge in den Logs sind über Nacht auf eine halbe Million angestiegen.

Lala merkt man das an. Sie reagiert deutlich langsamer als sonst. Das #NAS hat nur 2 GB Speicher. Sie nutzt swapping sehr exzessiv. Aber man soll sie ja auf 16 GB erweitern können...

*klickerdieklackerdieklick*

...bestellt...