database: Enhancements collection of links and opinions

[bmxp]

• https://knx-user-forum.de/forum/supportforen/smarthome-py/1278859-update-von-gleichbleibenden-messwerten-in-die-datenbank
• New database plugin: misc issues smarthome#165 (comment)
• https://knx-user-forum.de/forum/supportforen/smarthome-py/1273010-verbrauch-gas-etc-ungewolltes-item-trigger-bei-neustart

New attributes:

• database_write: on_update to enable writing of a recurrent value without a change -> behaviour has been implemented in v1.7.2 through the standard attribute enforce_change
• database_maxage: <days> maximum age of entries within a database for an item -> has alreedy been implemented

New feature wishes:

• compacting data --> discuss several strategies
• display orphaned items in database and offer to merge them into another item log
• When changing item names there will be a new id which is often not really wanted.
  --> provide a fixed database id for items

Webinterface:

• select a datetime range for csv export
• optionally select local time or UTC for csv export
• format datetime as such instead of time since epoch in milliseconds
  like 2021:11:07 12:15:12.180 instead of 1636243430180

[msinn]

Erledigt:

Update von gleichbleibenden Messwerten in die Datenbank

has been implemented in SmartHomeNG v1.7.2 -> new item Attribute enforce_change

smarthomeNG/smarthome#165 (comment)

Issue has been closed on July, 9th 2017

New attributes

database_write: on_update Das ist über das neue Standard-Attribut enforce_chane abgedeckt
database_maxageIst implementiert

Offen:

https://knx-user-forum.de/forum/supportforen/smarthome-py/1273010-verbrauch-gas-etc-ungewolltes-item-trigger-bei-neustart
https://knx-user-forum.de/forum/supportforen/smarthome-py/1668877-database-wert-nach-neustart
https://knx-user-forum.de/forum/supportforen/smarthome-py/1428215-database-plugin-und-sh-py-neustart

Ist ein Thema, aber vielleicht keines für das database Plugin. Das triggern betrifft ja nicht nur das Schreiben in die Datenbank, sondern auch die Neuberechnung anderer Items und das Triggern von Logiken

New feature wishes:

• compacting data
  discuss several strategies

Das Verdichten der Daten ist problematisch, da bisher jeder mit dem ich darüber diskutierte andere Wünsche hatte und diese Wünsche sich häufig gegenseitis ausschlossen.

[Tom-Bom-badil]

Für mich ist in diesem Zusammenhang immer noch das uralte Thema "kaputte Visu-Linien" offen, siehe hier. Von mir aus auch gern optional pro Item einstellbar.

Meines Wissens kann das Database-Modul immer noch keine kompletten Zeitverläufe inkl. Ausfälle / shNG Restarts abbilden.

Als Workaround schleppe ich mittlerweile für alle wichtigen (numerischen/boolschen) Items ein 'alive'-Item (0/1) mit, mit dem ich den Item-Wert multipliziere. Dadurch erhalte ich den Effekt, dass ich bei Ausfall eines Gerätes oder Sensors die gewünschte "0" in der Datenbank zu stehen habe, und kann auch 'sonderbare' Werte beim Initialisieren von shNG unterdrücken, und sehe sogar, wann das Gerät ausfiel und wieder 'hochkam' (z.B. ESP-Reboot nach WLAN-Verbindungsfehler).

Das hab ich damals schon ergebnislos mit Markus und einigen anderen diskutiert. Markus' Ansicht war damals, "0" könnte ja auch ein gültiger Meßwert sein und dürfe deshalb auf keinen Fall verwendet werden (nach dem Motto: Wenn nichts gemessen wird, darf auch nichts in der Datenbank stehen). Das mag streng logisch richtig sein, hilft aber nicht, vernünftige Plots zu erzeugen.

Außerdem möchte ich gern selbst festlegen können, wie sich ein Item bzw. der zugehörige Plot bei Ausfall verhalten soll.

/tom

[bmxp]

@Tom-Bom-badil löst bei Dir ein database: init das Problem mit den Nullwerten?

[Tom-Bom-badil]

Nein, die Items stehen bereits auf database: init - für den Plot im oben konkret verlinkten Beispiel siehe hier.

init ist aber auch nicht die Lösung für das genannte Problem - denn das Ziel ist es, Ausfallzeiten zu visualisieren. Und nicht, den Plot einfach vom letzten bekannten Zustand des Messwertes beim nächsten shNG-Reboot bzw. dem nächsten Wiedereinschalten der Gerätes als gerade Linie weiterzuziehen. Das suggeriert dem Anwender, alles wäre in Ordnung gewesen, was ja nicht stimmt.

/tom

[Morg42]

Ich verstehe das Problem nicht ganz. Wenn das Gerät offline ist, woher kommen dann die geloggten Werte?

Sollte da nicht eher das jeweilige Plugin nicht updaten bzw. None liefern? Oder hast du einen anderen konkreten Fall?

[Tom-Bom-badil]

Nein, da dann alle Plugins angepasst werden müssten, statt einer einzigen Anpassung im database Plugin. Es ist ein grundsätzliches Problem.

Soweit ich am Rande mitbekommen habe, wurden ohnehin Teile dieser mehr als 10 Jahre alten Diskussion mittlerweile umgesetzt (es gibt dazu hier und drüben im KNXUF mehrere Threads, nicht nur diesen über 3 Jahre alten).

Ist aber auch egal - das System, in das ich gerade migriere, kennt die Stati 'unknown' und 'unavailable', kann diese in die Datenbank schreiben und lässt in Plots entsprechende Lücken. In meinen Augen eine sehr gute Umsetzung - statt zwischen dem letzten bekannten/gültigen Wert und dem ersten ersten neuen Wert einfach eine Linie quer über den Plot zu ziehen, ist dort einfach korrekterweise eine Lücke im Plot; auch bei kumulierten Daten, Durchschnittswerten usw wird das berücksichtigt.

Hier mal ein Bild, das beschreibt, was ich meine: ESP-Ausfall am 3. Dezember bei ca 7 Grad Celsius, repariert am 7. Dezember bei ca 10 Grad Celsius. Die lange schräge (gelbe) Linie zwischen diesen beiden Werten dürfte es gar nicht geben, genausowenig wie die hellbraune Hintergrundfläche in diesem Zeitraum; denn da wurde gar nicht gemessen und somit das Temperatur-Item auch nicht aktualisiert. Cycle-Intervall der Datenquelle, last_update des Items usw waren die ganze Zeit während des Ausfalls bekannt - man könnte das also gut auswerten (wenn man denn wollte).

Aber wie schon geschrieben - egal ...

/tom

[Morg42]

Okay, danke für die Erklärung.

Das wäre aus meiner Sicht eine sinnvolle, aber wahrscheinlich erhebliche Änderung am database-Plugin... aber eine Überlegung wert.

[Morg42]

Der Vollständigkeit halber -

die Datenbank speichert zu einem Wert die Dauer der Gültigkeit. Solange zwei Stunden lang jede Minute eine 1 kommt, wird nur die Dauer der 1 verlängert, aber keine zweite 1 gespeichert.
Wenn dann eine Weile keine 1 kommt, wird auch kein Wert gespeichert und keine Dauer verlängert, da kein Item-Update das Db-Update triggert.

Insofern wären die in der Db vorhandenen Daten korrekt abbildbar, wenn beim Auslesen die Dauer "irgendwie" reproduziert wird (festes Intervall, - derzeit nicht - gespeicherte Updatezeiten, mindestens nochmal derselbe Wert am Ende der Gültigkeit (da wurde ja geschrieben, also gab es da noch ein Update)).
Das passiert derzeit nicht, insofern sind die "exportierten" Daten nicht so genau, wie sie sein könnten. Bei mir sind es derzeit z.B. PV-Produktion oder Batterieentnahme über Nacht, sobald die Batterie leer ist.

[Tom-Bom-badil]

Ich mag mich da jetzt nicht mehr reindenken, da ich im Moment jede Menge andere Baustellen habe. Es wurden aber schon Lösungsansätze recht detailliert diskutiert, u.a. hier.

Ist aber alles im Sande verlaufen, weil der Anwender, diese große Wundertüte, sich über ein zusätzliches Item wundern könnte (wenn ich das richtig in Erinnerung habe) ...

/tom