smarthomeNG
database: Enhancements collection of links and opinions
- https://knx-user-forum.de/forum/supportforen/smarthome-py/1278859-update-von-gleichbleibenden-messwerten-in-die-datenbank
- https://github.com/smarthomeNG/smarthome/issues/165#issuecomment-280458728
- https://knx-user-forum.de/forum/supportforen/smarthome-py/1273010-verbrauch-gas-etc-ungewolltes-item-trigger-bei-neustart
New attributes:
-
database_write: on_updateto 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.180instead of1636243430180
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.
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
@Tom-Bom-badil löst bei Dir ein database: init das Problem mit den Nullwerten?
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