Neues Database Plugin

[Sisamiwe]

wichtiges Update für das Datenbank-Subsystem

Vielen Dank....

Die Fehler, die du beschreibst, haben mich schon immer genervt; und ich dachte, es liegt an meiner DB-Größe.

Sollten die Änderungen auch ins db-addon Plugin eingebaut werden?

[Morg]

Wenn das hier soweit getestet und für gut befunden ist - jein Der wesentliche Unterbau in lib.db sollte eigentlich (TM) durch db_addon jetzt schon genutzt werden, ich habe da aber noch nicht reingeschaut. Ich würde dir Bescheid geben, wenn ich das für "an der Zeit" halte, dann können wir schauen, was ggf. angepasst werden sollte.

[Morg]

Ich hätte mal eine Frage, falls hier genügend Leute mitlesen, die eine Meinung bilden und äußern wollen

Im Moment ist ja das alte database_maxage von "nur löschen" zu "löschen oder aggregieren (sum, max, min, avg, int, last, ...)" geworden. Es wurde der Wunsch geäußert, dies mehrstufig zu ermöglichen, z.B. die ersten 6 Monate täglich, von 6-12 Monaten wöchentlich, und danach zweiwöchentlich.

Da wir ja mittlerweile die Möglichkeit haben (hätten - das müssten Plugins erst noch einbauen), Daten als "nicht verfügbar" zu kennzeichnen, könnten auch kurze oder längere Ausfälle in den Daten in der Datenbank gespeichert werden. Wenn jetzt aggregiert wird - z.B. avg - dann gehen diese Lücken in der Datenbasis verloren.

Gäbe es ein Interesse daran, die Rohdaten von aggregierten Daten "extern" aufzubewahren, um so etwas nachträglich nachvollziehen zu können?

Ich finde diese Option persönlich nicht notwendig - ob meine Heizungsanbindung vor 9 Monaten mal einen Tag offline war oder nicht, ist mir nach so langer Zeit wahrscheinlich egal, aber bevor ich mich endgültig für oder gegen eine entsprechende Implementierung entscheide, wollte ich mal nach Meinungen fragen.

Die mehrstufige Aggregierung zum weiteren Platzsparen auf der Platte baue ich mit ein.

[Morg]

Weil ich umfangreiches Feedback erhalten habe, und in der Hoffnung, dass das hier auch gelesen wird -

Es ist nicht unwahrscheinlich, dass (zumindest anfänglich) viele Warnungen oder sogar Fehler von lib.db oder plugins.database ausgeworfen werden. DAS IST NORMAL!

Warum? Weil diese Fehler in der Vergangenheit einfach geschluckt/verworfen wurden. Jetzt werden sie ausgegeben, und das kann als Anhalt genommen werden, ggf. das Datenbanksystem oder auch die eigene Datenbank zu prüfen (Leistung, Speicher, DB zu groß?).

Dazu kommt, dass nach dem Start z.B. maxage_compaction losläuft. Bei SQLite kann dies dazu führen, dass die Datenbank für längere Zeit (Stunden?!) durch maxage_compaction blockiert wird, wenn viele Daten gelöscht oder aggregiert werden müssen.

Bei MySQL/MariaDB können ein unglücklich provisionierter Datenbankserver oder eine zu große Datenbank zu häufigen Timeout-Fehlern führen. In dem Fall empfehle ich zuerst, den DB-Server zu optimieren (Speicherplatz, Plattenplatz, Swap), und dann die Datenbank zu verkleinern.

Beispiel:

Ich habe mein Swap von 8 GB (= phys. RAM) auf HDD auf 16 GB auf SSD umgestellt. Das allein war schon ein riesiger Performancegewinn.

Meine Datenbank von 19 GB (ca. 190 Mio Zeilen) auf 4 GB (32 Mio Zeilen) zu verkleinern hat dazu geführt, dass der DB-Server effektiv kein Swap mehr benötigt und den verfügbaren Speicher auch nicht mehr auslastet. Seitdem habe ich auch keine Warnungen mehr, vorher ständig Timeouts.

[manhartm]

Ich habe auf einem Raspberry 4B mit dem Rasbian Trixie eine neue Installation mit SmarthomeNG 1.12.2 (master) aufgesetzt.

Die Datenbank (MariaDB) habe ich gemäss Blog-Eintrag aufgesetzt: https://www.smarthomeng.de/database-...-mysql-mariadb

In 'etc/plugin.yaml' ist das Plugin definiert:

database:
    class_name: Database
    class_path: plugins.database
    driver: pymysql
    connect:
    -   host:localhost
    -   user:smarthome
    -   passwd:raspberry
    -   db:smarthome_db
    count_logentries: true
    plugin_enabled: true
​

Direkt nach dem Start erhalte ich eine sehr grosse Zahl von Fehlermeldungen:

2026-08-31  19:20:30 ERROR    lib.db              Can not execute query: INSERT INTO item(name) VALUES(%(name)s); (args OrderedDict({'name': 'env.core.memory'})): (1364, "Field 'id' doesn't have a default value")
2026-08-31  19:20:30 ERROR    plugins.database    Database: Query error: (1364, "Field 'id' doesn't have a default value")
2026-08-31  19:20:30 WARNING  plugins.database    Problem dumping env.core.memory: (1364, "Field 'id' doesn't have a default value")
2026-08-31  19:20:30 ERROR    lib.db              Can not execute query: INSERT INTO item(name) VALUES(%(name)s); (args OrderedDict({'name': 'env.core.threads'})): (1364, "Field 'id' doesn't have a default value")
2026-08-31  19:20:30 ERROR    plugins.database    Database: Query error: (1364, "Field 'id' doesn't have a default value")
2026-08-31  19:20:30 WARNING  plugins.database    Problem dumping env.core.threads: (1364, "Field 'id' doesn't have a default value")
2026-08-31  19:20:30 ERROR    lib.db              Can not execute query: INSERT INTO item(name) VALUES(%(name)s); (args OrderedDict({'name': 'env.core.scheduler.worker_threads'})): (1364, "Field 'id' doesn't have a default value")
2026-08-31  19:20:30 ERROR    plugins.database    Database: Query error: (1364, "Field 'id' doesn't have a default value")
2026-08-31  19:20:30 WARNING  plugins.database    Problem dumping env.core.scheduler.worker_threads: (1364, "Field 'id' doesn't have a default value")

Die genau gleiche Konfiguration läuft auf meinem aktuellen Produktivsystem mit 1.10.0 problemlos und ohne diese Fehlermeldungen.

Was muss ich ändern ?

[Morg]

Entweder core und plugins auf develop (aktuell von heute) aktualisieren, da sind Fixes für alle Fehler drin, die ich bisher gefunden habe, bis zum nächsten Fixup-Release warten (im Prinzip sollte der Code soweit sein, ich möchte den vorher aber 2-4 Wochen öffentlich laufen haben), oder auf eine alte Version zurückwechseln und sich in der Ruhe im Log der Illusion hingeben, es gäbe keine Fehler (siehe mein vorheriger Post).

Ja, die Fehler sind zu viele und zu laut, dazu habe ich gerade noch einen Fix gepusht.

Sorry, bessere Möglichkeiten hast du gerade nicht (und Downgrade ist aus meiner Sicht nicht wirklich eine Möglichkeit...)