-
Notifications
You must be signed in to change notification settings - Fork 103
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
database: Enhancements collection of links and opinions #373
Comments
Erledigt:
has been implemented in SmartHomeNG v1.7.2 -> new item Attribute enforce_change
Issue has been closed on July, 9th 2017
Offen:
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
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 |
Nein, die Items stehen bereits auf 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 |
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? |
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 |
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. |
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. 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)). |
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 |
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_changedatabase_maxage: <days>
maximum age of entries within a database for an item -> has alreedy been implementedNew feature wishes:
--> provide a fixed database id for items
Webinterface:
like
2021:11:07 12:15:12.180
instead of1636243430180
The text was updated successfully, but these errors were encountered: