database: Enhancements collection of links and opinions about plugins

[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