Neues Database Plugin

[Msinn]

Es sollte auch reichen database: init statt database: yes zu verwenden. Dann wird beim Start das Item statt mit 0 mit dem letzten Wert aus der Datenbank initialisiert, Ist auch der Doku zu entnehmen.

[aldaris]

Tatsächlich geht es mit den hint von aschwitz. Init und Yes gehen nicht, weil die Intervalle dann nicht passen. Es wird ja ein Wert geschrieben, genau das soll es (z.B. bei Tagessummen) nicht.

[aldaris]

Leider habe ich direkt die nächste Frage an die Datenbank :-(. Diese Nacht ist mir ein Wechselrichter in Störung gegangen und hat falsche Werte geliefert. Die versauen mir jetzt meine Visualisierung. Gibt es eine Möglichkeit, den Werte in der Datenbank manuell zu ändern? Es ist NUR der Wert zu ändern, Zeitpunkt und Zeitintervall sollen unverändert bleiben.

[Morg]

Im WebIf des database-Plugins gibt es jetzt die Möglichkeit, verwaiste Datenreihen aktuellen Items neu zuzuordnen. Bei sehr großen Datenbanken könnte das etwas dauern; da will ich später nochmal ran. Wenn ihr ansonsten noch was findet, was nicht oder nicht gut läuft, lasst es mich wissen.

[Cannon]

Wenn ihr ansonsten noch was findet, was nicht oder nicht gut läuft, lasst es mich wissen.

Gerne doch! :-) Wobei das Plugin wirklich toll ist. Ich weiß gar nicht, was ich ohne dem machen würde. Gehört ja quasi zur Grundfunktionalität von SmartHomeNG.

Mich nervt etwas, dass da 0-Werte reingeschrieben werden, wenn das Item noch nicht initialisiert ist - zumindest vermute ich das. Ich nutze bei "langsamen Items" meist database: init. Das Problem dabei ist dennoch, dass falsche 0-Werte in die DB geschrieben werden. Das hat irgendwas mit dem Neustart von SmartHomeNG zu tun. Ob das daran liegt, dass ich ggf. mehrfach neu gestartet habe und noch nicht initialisiert war, kann ich aber nicht beurteilen. Die Frage ist nur, ob man das irgendwie vermeiden kann. Gerade wenn man min/max-Werte abfragen will ist das besonders störend.

[Morg]

Wenn der Wert normalerweise nicht 0 wird, wäre es ganz einfach mit einem eval. ANsonsten müsstest du mal schauen, welchen Wert das Item nach dem Start von shng hat und woher der Wert kommt (init, database, ...?). Bei database: init sollten keine "falschen" 0-Werte geschrieben werden, da das Item den initialen Wert aus der db bekommt. Irgendwo müsste ja dann eine 0 herkommen. Versuche mal herauszufinden, woher...

[aldaris]

Hilft das bei Dir nicht auch?
https://knx-user-forum.de/forum/supp...28#post1988128

[ooUrmeloo]

Leider habe ich direkt die nächste Frage an die Datenbank :-(. Diese Nacht ist mir ein Wechselrichter in Störung gegangen und hat falsche Werte geliefert. Die versauen mir jetzt meine Visualisierung. Gibt es eine Möglichkeit, den Werte in der Datenbank manuell zu ändern? Es ist NUR der Wert zu ändern, Zeitpunkt und Zeitintervall sollen unverändert bleiben.

Du könntest den "DB Browser for SQLite" verwenden.
Siehe auch hier: https://knx-user-forum.de/forum/supp...30#post1961430

Damit habe ich einzelne Einträge ändern können. Ist m.E. aber nichts, was man häufiger manuell machen möchte ...

[knxms]

Hallo!
Mir ist bei der Anpassung von DB-Items aufgefallen, dass das Item env.core.scheduler.active_threads in meiner Datenbank praktisch doppelt so viele Einträge hat, wie die anderen Items aus der Gruppe env.core.scheduler....

grafik.png

Ich kann nachvollziehen, dass die "env_stat"-Logik mit cycle=300 aufgerufen wird. Und, dass die active_threads mit

(Auszug aus core.yaml)

active_threads:
    type: num
    eval: sh...worker_threads() - sh...idle_threads()
    eval_trigger:
       - ..worker_threads
       - ..idle_threads​

berechnet werden. D.h. die Berechnung wird scheinbar 2x getriggert; damit entstehen 2 DB-Einträge.

Ist das so gewollt?

[Msinn]

Ja, da sich die Anzahl worker Threads und die Anzahl idle Threads unabhängig voneinander ändern können und sich dadurch die Anzahl der aktiven Threads in jedem der beiden Fälle ändern kann.

[knxms]

Das verstehe ich.
Ich wurde deshalb stutzig, weil zwei Einträge (…bei meiner Datenbank…) praktisch zeitgleich erfolgen. So wie hier:

image.jpg

[Msinn]

Die „praktisch zeitgleichen“ Einträge erfolgen immer, wenn ein aktiver Thread beendet wird und anschlueßend in die Liste der idle Threads aufgenommen wird.

[fuxl66]

Hi,

Ich habe eine neue VM mit 1.12 + 3.6 unter Trixie erstellt. Bevor ich sie produktiv einsetze spiele ich mit dem Gedanken meine MariaDB, die bereits als Docker läuft (benutzer + pwd), zu verwenden.

Was müßte dafür angepasst werden?
- aktuelle SQL Plugin config

database:
    plugin_name: database
    driver: sqlite3
    count_logentries: true
    connect:
    -   database:/usr/local/smarthome/var/db/smarthomeng.db
    -   check_same_thread:0​

In den items

database: 'init'

mfg
Markus

[Morg]

Ich habe jetzt mal etwas am Database-Plugin gearbeitet.

Wesentliche Änderungen:

• unter der Haube
  • einige Fehler behoben
  • das Locking konsequenter umgesetzt, so dass gleichzeitige Zugriffe (auch aus verschiedenen Threads) so weit ich ich das sehen kann verhindert werden
  • Timeouts und Reconnects verbessert
• in der Items-API:
  • es gibt jetzt bei gesetztem database_maxage (Löschen nach x Tagen) die Möglichkeit, nicht zu löschen, sondern Dinge zu tun:
    
    mit dem Attribut database_maxage_action kann festgelegt werden, was mit alten Daten geschehen soll. Default ist "delete" -> unverändert
    Es gibt weitere Möglichkeiten, wie z.b. "sum", "avg", "max", "min", "integrate", "first", "last" - im Wesentlichen dieselben, die man über die Item-Funktionen auch nutzen kann.
    Dazu gibt es noch "database_maxage_interval", per Default "1d", also ein Tag - damit wird festgelegt, in welchen Intervallen die Daten aggregiert werden.
    Bei "sum" werden alle Werte eines Tage addiert und statt der einzelnen Werte nur noch ein Tageswert geschrieben. Bei "avg" gibt es den Tagedsurchschnitt, "min" und "max" sind klar, "first" und "last" (gehen z.B. auch für str-Items) belassen von allen Werten eines Tages nur den jeweils ersten oder letzten.
    
    Das alles passiert automatisch - und Daten, die noch "alt" vorhanden sind, werden Stück für Stück im Hintergrund automatisch aggregiert.
    
    Wenn die Datenbank wirklich schon zu groß ist, gibt es noch die Möglichkeit festzulegen, wie viele "Intervalle" (hier: Tage) am Stück verarbeitet werden. Mit 1 dauert es entsprechend länger, ist aber mit weniger Rechen- und Zugriffsaufwand verbunden und sollte daher stabiler laufen.

Das Ganze geht auch mit sqlite, ich habe aber keine Erfahrungen, wie es mit sehr großen sqlite-Datenbanken arbeitet. Mit sehr großen MySQL-Datenbanken (19 GB....) geht es langsam, aber kontinuierlich


Vielleicht hlift das dem Einen oder Anderen

[Morg]

So, wichtiges Update für das Datenbank-Subsystem lib/db.py und plugins/database/:

Mit den letzten Updates im database-Plugin sind einige Fehler an die Oberfläche gespült worden, die vorher ignoriert oder still verschluckt wurden (try/except: pass). Teilweise waren Fehler im Code, die notwendige Anweisungen gar nicht erst haben ausführen lassen.

Ich habe daraufhin mehrere Code-Audits durchgeführt und einiges an Änderungen einbauen müssen.

Wichtig - die meisten Änderungen (und alle großen Fixes) beziehen sich nur auf MySQL-Datenbanken, nicht auf SQLite!

Auslöser waren wiederholte Fehler ("packet sequence number wrong", "NoneType object has no attribute", disconnect/hang errors). An mehreren Stellen im Code waren Abfolgen von Locking - Cursor - Anweisung - Commit/Rollback - Lock-Freigabe implementiert, die aber nicht einheitlich und nicht alle vollständig waren. Die unterschiedliche Behandlung von Anweisungen mit explizitem oder ohne Cursor haben sich teilweise überschnitten, und verschiedene SQL-Anweisungen sind durcheinander an die DB gegeben worden ("packet sequence number wrong").

Die hat in der Vergangenheit teilweise zu Datenverlust führen können.

Mit diesem Update werden alle Datenbankzugriffe über einen `with transaction()`-Kontextmanager geroutet. Dieser sorgt in jedem Fall dafür, dass nur ein Anweisungsblock gleichzeitig ausgeführt wird und hinterher sauber aufgeräumt - entweder ein commit() im Erfolgsfall oder ein rollback() im Fehlerfall. Die vorhandenen Logik (z.B. dump() vom buffer) sorgt jetzt schon für eine Wiederholung von fehlgeschlagenen Anweisungen, so dass keine Daten verloren gehen.

Durch den einheitlichen transaction-Manager ist das Verhalten an allen Stellen einheitlich und nachvollziehbarer geworden.

Weitere kleinere Fehler sind quasi nebenher mit behoben worden - auch einige für SQLite.

Für Anwender sind keine Änderungen der Konfiguration oder sonstige Arbeiten erforderlich. Die notwendigen Updates am DB-Schema werden automatisch eingespielt, und damit sollte das Datenbanksystem hoffentlich für eine Weile wieder fehlerfrei laufen.

Damit das funktioniert, müssen core (shng) und plugins beide auf aktuellen develop-Stand gebracht werden. Das aktuelle database-Plugin aus develop wird nicht laufen, wenn nicht auch der Core aktuell ist!

Die Updates vom PR #1052 (database: enable reversible invalidation of values) sind _nicht_ enthalten.

Aufgrund der Schwere der Fehler plane ich noch ein 1.12.3-Release, sobald dieses Update einigermaßen getestet wurde. Bei mir habe ich intensive Tests mit verschiedenen Datenbank-Containern durchgeführt (im Betrieb die DB ausschalten und solche Späße...) und umfangreiche Tests für lib.db und das database-Plugin hinzugefügt. Auf meinem "Produktionsserver" zuhause läuft das jetzt seit ca. einer Woche ohne eine einzige Warnung oder einen Fehler.
)