Update von gleichbleibenden Messwerten in die Datenbank

[smai]

Ich habe eben noch etwas zu enforce_updates festgestellt:
Ohne enforce_updates wird update_item des Plugins naheliegenderweise gar nicht aufgerufen. enforce_updates muss also für wiederholtes Schreiben zwingend aktiviert sein.
Damit erübrigt sich IMHO die Diskussion von oben, man kann (und muss) es über enforce_updates steuern.

Bleibt noch die Frage, ob es reicht, meinen Vorschlag zu implementieren oder ob jemand auf einen Modus besteht, bei dem alle Updates gespeichert werden.
Zweiteres hat ja bmx oben bereits implementiert.

[Onkelandy]

Hat sich hier eigentlich noch was ergeben?

[lexxmm]

*ping* will auch noch mal nachfragen?

[Morg]

Ich wärme hier nochmal auf.

Mir fallen mehrere Punkte ein, die man anpassen könnte -

1. der Item-Klasse eine Möglichkeit geben, Items auf "None" zu setzen. Da das nicht per sh.item(None) geht (soll nonbreaking sein), wäre z.B. sh.item(novalue=True) eine Möglichkeit. Es müssten die cast-Methoden angepasst werden, und es könnte zu Nebenwirkungen kommen, wenn core- oder Plugin-Routinen z.B. Zahl oder str erwarten, aber None erhalten. Das müsste man prüfen und ggf. eine Lösung finden.

2. im Database-Plugin die von smai vorgeschlagene Lösung, jede Änderung zu schreiben und bei einer Änderung (mit enforce_updates) auf denselben Wert den letzten identischen Wert wieder zu löschen. Damit wäre bei langen konstanten Intervallen die Dauer in der DB gesichert, so dass eine Interpolation bestenfalls sehr viel kleinere Fehler liefert (siehe Bilder weiter oben).

3. im Database-Plugin die Berechnung von Interpolation beim Abruf von Daten anpassen, dass sie mit 1. und 2. umgehen kann.

Nachdem, was wvhn mir erklärt hat, können die Plotroutinen von Highcharts mit None-Werten umgehen, so dass wir auf der Seite nichts ändern müssen.

Ich habe schonmal in das DB-Plugin reingeschaut, aber mir fehlen noch an ein oder zwei Stellen Details, um zu verstehen, warum dort etwas getan wird. Falls jemand da gute Einsichten hat, wäre ich für etwas Starthilfe dankbar.

[Morg]

So vielleicht nochmal ein paar Punkte zum aktuellen Stand und zu dem, was mir an Anpassungen vorschwebt...

Für mich sieht es so aus: Da gibt es diese Funktion im Item mit "enforce_update(s)", bei der in der SmarthomeNG-Anleitung beschriebene Funktion immer aufgerufen wird, auch wenn sich der Wert nicht ändert. Folglich (für mich) auch im Database-Plugin. Offensichtlich bildet das nun die Ausnahme der Regel.

Wenn ich das jetzt also richtig sehe gibt es dazu generell keine Möglichkeit, regelmäßig mit gleiche Werten in die DB zuschreiben?

Doch, gibt es, mit Bordmitteln.

Wenn man "enforce_change: true" setzt, wird JEDER gesendete Wert in die Datenbank geschrieben. Fertig. Speicherplatz wird dabei natürlich zusätzlich belegt, aber das dürfte dann eben der Preis sein.

Aber: wenn dieser Wert für Stunden oder Tage gültig ist, das Plugin den Wert aber nicht aktualisiert, sondern nur einmal sendet, wird er auch nur einmal geschrieben. (Das könnte man durch "cycle: xx" in Verbindung mit "enforce_change: true" übersteuern, indem der letzte Wert alle xx Sekunden (oder 5m oder 12h oder was auch immer) erneut gesetzt wird. Das ist dann zwar nicht 100% die Datenlage des Plugins, aber es sorgt für regelmäßige (duplizierte) Werte in der DB).

Hinweis: wenn an dem Item weitere Methoden/Trigger hängen (eval, on_change, Logik, Userfunction...), dann werden die alle jedesmal getriggert.

Die Lösung von @bmxp, im database-Plugin auf enforce_updates zu reagieren, wäre eine mögliche Überlegung. Einen Instanzbezug finde ich an der Stelle nicht notwendig; wer ein Item an zwei Datenbank-Instanzen hängt, sollte sowieso wissen, was er/sie tut...

Solange beim Item enforce_updates nicht gesetzt ist, wird das database-Plugin nicht getriggert und update_item kann im Dreieck springen, aber es wird nicht aufgerufen.

Daher ist die Vorbedingung immer enforce_updates=true (oder enforce_change=true), und dann könnte man überlegen, ob das database-Plugin eine Option bekommt, Updates zu ignorieren oder zu schreiben (global oder per Item).

Aber das Wesentliche ist (zuerst) enforce_updates, sonst geht es alles nicht.

--------------------

Ich fände es schön, wenn es eine Option gäbe, im db Plugin auch das Update zu erzwingen. z.B. mit enforce_updates: database ?

Wenn das database-Plugin enforce_updates berücksichtigt, passiert das doch automatisch. Und wenn enforce_updates "nur" für database gelten sollte, schlägt es fehl, weil das Item keine Updates pusht und das Plugin das gar nicht mitbekommt.
Oder wolltest du bei enforce_updates=true nur das Item und "erst" bei enforce_updates=database zusätzlich das database-Plugin triggern?


------------------

Wenn mit Bordmitteln oder einem db-Update wiederholte (gleiche) Werte geschrieben werden, dann würde ich vorschlagen, auch die Idee von smai zu berücksichtigen, dass nur der erste Wert (mit verlängerter duration) und der letzte Wert [einer identischen Serie] in der Datenbank landet. Das wäre eine weitere Änderung, die aber (außer denen, die jetzt schon enforce_change benutzen, niemandes Werte vernachlässigt.)

Wenn mehrmals derselbe Wert kommt,
reicht es eigentlich, wenn man den letzten Zeitpunkt vor der nächsten Änderung in die DB schreibt.
Also von folgender Datenreihe müssten nur die ersten und die letzten beiden geschrieben werden, die Nullen dazwischen braucht es nicht.

00:00	1
00:05	0
00:10	0
00:15	0
00:20	0
00:25	1

Umzusetzen wäre dies, indem man immer erst bei einer Wertänderung den neuen wie auch rückwirkend den vom vorhergehenden Update speichert.

Das halte ich für unproblematisch implementierbar, denn derzeit werden mehrfache Werte nur geschrieben, wenn enforce_change aktiv ist. Mit einer Änderungen, dass auch Updates geschrieben werden, könnte man somit problemlos einführen, dass nur das letzte Update "mitgeschleppt" wird und alle früheren Updates kumuliert werden.

Wie smai auch oben schon geschrieben hat, sehe ich keine Notwendigkeit, das alte Verhalten (alle gleichen Werte bei enforce_change behalten) zu behalten. Außer zur Kontrolle, ob tatsächlich alle x Minuten ein Wert geschrieben wurde, bringt es keinen Mehrwert. (Wenn der notwendig sein sollte, ließe sich das pro databse-Instanz oder pro Item auch wählbar machen, aber dafür bräuchte ich jemanden, der es will )

--------------------

Da sind alles Änderungen nur am database-Plugin, die ich zuerst angehen würde. Die Offline-Detektion ist nochmal eine ganz andere Nummer und nicht ohne Anpassungen am Core (oder Implementierung durch den Nutzer, z.B. Hilfsitems @tom-bombadil) umsetzbar. Das wäre für mich dann erst den zweite Schritt.

[Onkelandy]

Oder wolltest du bei enforce_updates=true nur das Item und "erst" bei enforce_updates=database zusätzlich das database-Plugin triggern?

Ist schon ne Weile her, aber ich denke, genau das war meine Idee.