Update von gleichbleibenden Messwerten in die Datenbank

[bmx]

Ich wäre dann dafür, das man im in der plugin.yaml die grundlegende Strategie festlegen können sollte:

database_strategy: change --> Werte übernehmen, wenn sich tatsächlich etwas ändert
oder
database_strategy: update--> Werte übernehmen, wenn ein neuer Wert gesetzt wird, egal ob der bereits vorliegt oder nicht

Und zusätzlich dann bei einem Item:

database_write: on_change
database_write: on_update

die würden dann die "globale" plugin Strategie überschreiben nur für ein Item. Darin könnte auch die Multiinstanzfähigkeit realisiert werden.
So wie in meinem Beispiel weiter oben war das eher als Machbarkeitsstudie gedacht, ein enforce_updates sollte idealerweise nicht angefasst werden.

[smai]

Ich möchte noch einen Idee zwischen on_change und on_update einbringen:
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

Ein Praxisbeispiel bei mir ist die Leistungsmessung der Legionellenschaltung. Diese ist nur einmal in der Woche für vielleicht 30 Minuten aktiv.
Zumindest bei meinem ABB-Aktor muss ich aber periodisches senden aktivieren, weil sonst der Wert nie auf 0 fällt sondern beim letzten Wert kleiner der Sendegrenze stehen bleibt.
Mit on_update hätte ich in der Woche 2016 Einträge, mit dieser Methode nur etwa 10.

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

[Msinn]

Die Idee ist nicht schlecht, was mich nur etwas stört ist dass im Moment eine Reihe von Themen die die Daten Speicheruung in sqlite/database betreffen an den Items diskutiert werden. Da die Plugins unabhängig vom Core sind (und evtl. auch noch andere Plugins mit anderen Bedarfen auftreten könnten), wäre es nach meiner Meinung besser das an Plugin-spezifischen Attributen zu diskutieren und zu implementieren und nicht an der Core Funktionalität zu schrauben um den Bedarf in einem Plugin zu lösen.

smai Das bezieht sich jetzt weniger auf Deinen Beitrag, musste aber mal raus.

[smai]

Ich sehe das wie Msinn, das muss ja im Plugin implementiert werden also sollte es auch ein pluginspezifisches Attribut sein.

Den letzten Vorschlag von bmx finde ich ganz gut, mit einer kleinen Abweichung:
Den Plugin-Parameter würde ich anstatt database_strategy: change gleich nennen wie das Item-Attribut, also database_write: on_update.

Zusätzlich natürlich noch mit meiner Idee ergänzt z.B. als last_update oder sowas.

[bmx]

Ja, gute Idee, d'accord. Wie Du allerdings das dazwischen meinst, da habe ich ein Brett vor dem Kopf oder es ist schon einfach wieder zu spät.

[smai]

Um das verständlicher zu erklären, muss ich etwas ausholen:

Aktuell wird ja immer nur on change gespeichert. Bei folgender Datenreihe ergibt das unten stehenden Plot:

Zeit	Wert
01.00	0
01.05	0
01.10	0
01.15	0
01.20	30
01.25	30
01.30	50
01.35	50
01.40	50
01.45	0

chart1.png
Dieser ist falsch, weil ja z.B. um 01:15 noch der Wert 0 empfangen wurde.

Der Vorschlag war nun, jeden empfangenen Datenpunkt zu speichern, was diesen Plot ergibt:
chart2a.png

Bei meiner Idee würde nun von unveränderten Wertreihen immer nur der erste und der letzte Punkt gespeichert, diejenigen dazwischen werden weggelassen.
Das ergibt denselben Plot (bis auf die Punkte natürlich, welche aber in der smartVISU nicht zu sehen sind):
chart2b.png

Bei lange gleichbleibenden Werten - und nur bei solchen ist das Ursprungsproblem überhaupt erkennbar - lassen sich damit massiv Datenpunkte sparen.

[walldi]

Hallo,
es geht doch weniger um das Speichern der Werte, als um die Interpolation bei Abfrage von Werten zwischen gespeicherten Auszeichnugen.
Ich meine, die Datenspeicherung sollte möglichst konsistent zum vorgesehenen Verhalten des Systems erfolgen: d.h. wenn ein Ereignis / neuer Datensatz ignoriert wird, weil der Wert unverändert ist (default Verhalten), soll auch nicht in die DB geschrieben werden. Wenn ein unveränderter Wert nicht ignoriert wird (enforce_update Verhalten) sollte gespreichert werden.
Die Interpretation von Werten zwischen den gespeicherten Ereignissen ist natürlich mehrdeutig und vom abgebildetetn physikalischen System abhängig. Ich meine, hier sollte für jede Datenreihe definiertbar sein, welche Werte interpoliert werden. Das kann ein Sprungverhalten sein oder ein stetiger Übergang (linearer oder evtl. höhere Interpolation). Diese Definition sollte nicht beim Speichern und auch nicht erst bei der Darstellung getroffen werden, sondern bei der Datenabfrage.

[bmx]

smai Danke für die Erklärung, jetzt habe ich das auch verstanden

[smai]

es geht doch weniger um das Speichern der Werte, als um die Interpolation bei Abfrage von Werten zwischen gespeicherten Auszeichnugen.

Obwohl ich das gemäss meinem ersten Beitrag auch so interpretiert hatte, geht es in diesem Thread tatsächlich um das Speichern.
Im gegebenen Fall weiss man nämlich, dass der Wert zu einem bestimmten Zeitpunkt noch 0 war. Diese Information wird aber nicht gespeichert und lässt sich auch per Interpolation nicht wieder herstellen.
Sache der Interpolation ist es dann, wie die Kurve in der Minute zwischen dem letzten bekannten 0 und dem ersten grösseren Wert verläuft.

Ich meine, die Datenspeicherung sollte möglichst konsistent zum vorgesehenen Verhalten des Systems erfolgen: d.h. wenn ein Ereignis / neuer Datensatz ignoriert wird, weil der Wert unverändert ist (default Verhalten), soll auch nicht in die DB geschrieben werden. Wenn ein unveränderter Wert nicht ignoriert wird (enforce_update Verhalten) sollte gespreichert werden.

Das war auch mein erster Gedanke. Allerdings sehe ich durchaus Anwendungsfälle, in denen unmittelbare Reaktion und historische Auswertung nicht übereinstimmen müssen.
Dazu kommt, dass sich meine Idee des Datensparens ohne Informationsverlust damit nicht umsetzen liesse.

Die Interpretation von Werten zwischen den gespeicherten Ereignissen ist natürlich mehrdeutig und vom abgebildetetn physikalischen System abhängig. Ich meine, hier sollte für jede Datenreihe definiertbar sein, welche Werte interpoliert werden. Das kann ein Sprungverhalten sein oder ein stetiger Übergang (linearer oder evtl. höhere Interpolation).

Das ist bereits so, in der smartVISU kann man zwischen line (linear), spline (kubisch) oder stair (Sprung) wählen.

Diese Definition sollte nicht beim Speichern und auch nicht erst bei der Darstellung getroffen werden, sondern bei der Datenabfrage.

Die Interpolation selbst geschieht aber in der Praxis erst bei der Darstellung. Andernfalls müsste die Abfrage extrem viele interpolierte Werte liefern um eine einigermassen glatte Kurve hinzukriegen.
Man könnte höchstens den Parameter auf dem SHNG-Item definieren und mit den Daten mitliefern anstatt ihn bei der Visu-Entwicklung setzen zu müssen. Wäre vielleicht sinnvoll, hat für mich aber keine Priorität, weil es für den Anwender nur einen minimalen Unterschied macht..

[Tom Bombadil]

Die von Stefan generierten Plots erinnern mich unweigerlich an ein anderes Thema, das hiermit eng verbunden ist und auch bis heute nicht gelöst wurde: Darstellung von 'offline' Zeiten (Sensor liefert NaN, shNG war aus, was auch immer --> nach dem heutigen Konzept steht da nichtmal NaN oder NIL im Textfeld der Datenbankzeile drin, sondern es wird beim Hochfahren einfach eine 0 reingeschrieben). Dies führt ebenfalls zu sehr unschönen Plots, die denen da oben sehr ähnlich sehen ...
/tom

[smai]

Bevor das Thema hier vergessen geht, möchte ich es nochmal aufwärmen.

Nachdem ich nochmal darüber geschlafen habe (und das waren ja jetzt einige Nächte ), habe ich mich gefragt, ob es diese database_write Konfiguration überhaupt braucht.
Spricht etwas dagegen, fix die von mir vorgeschlagene Lösung zu implementieren (also jeweils der letzte Wert vor der Änderung)?
Von der Datenmenge her dürfte es keine grosse Rolle spielen. Es betrifft ja nur Fälle, in denen zyklisch ein gleichbleibender Wert gesendet wird. Das sind ja eher wenige Items und der zusätzliche Datensatz entsteht ja dann nur bei einer Änderung.
Mehr Konfiguration bedeutet halt auch immer grossere Komplexität für die Benutzer und auch im Code.

Ich würde behaupten, dass es keine Fälle gibt, wo man trotz zyklischem Senden das bisherige Verhalten möchte.
Stellt sich noch die Frage, ob es Szenarien gibt, in welchen man wirklich jeden empfangenen Wert speichern möchte (also on_update). Mir fällt keines ein, habt ihr eines?


Tom Bombadil das von dir beschriebene Problem sieht zwar tatsächlich verwandt aus, die Ursache ist aber eine (bzw. zwei) andere.
Zwei deshalb, weil "Sensor liefert NaN" und "shNG war aus" wiederum verschieden sind.

"shNG war aus" ist bereits jetzt in der Datenbank erkennbar.
Wenn SHNG sauber heruntergefahren (genauer: das Database Plugin gestoppt wird), dann wird die Duration des letzen Datensatzes gesetzt.
Wird das Plugin nicht sauber gestoppt, bleibt die Duration des letzen Datensatzes NULL.
Bei einem Unterbruch liegt also zwischen time+duration des alten Wertes und time des neuen Wertes eine Lücke.
Bei der Abfrage wird dieser Umstand dann aber ignoriert, was zu dem von dir beschriebenen Effekt führt.
Dies müsste also bei der Abfrage gelöst werden.

Die Ursache für "Sensor liefert NaN" liegt tief im Core.
Dies kann das Database-Plugin gar nicht mitkriegen, weil ein ungültiger Wert (also im Beispiel String "NaN" anstelle einer Zahl) nicht verarbeitet wird. Im Log steht dann "value NaN does not match type num".
Eine Lösung könnte sein, dass das Item in diesem Fall auf None gesetzt wird (entweder durch den Core selbst oder explizit durch das setzende Plugin).
Dies geht aber aktuell nicht, weil ein Aufruf von sh.item(None) nicht den Wert setzt sondern wie sh.item() angesehen wird und den aktuellen Wert zurückliefert.

sondern es wird beim Hochfahren einfach eine 0 reingeschrieben

Dies ist auch irgendwie verwandt, aber nochmal ein anderes Thema. Dieses wurde kürzlich diskutiert in https://knx-user-forum.de/forum/supp...r-bei-neustart. So richtig zufriedenstellend finde ich das Ergebnis dort aber auch noch nicht.

[schuma]

Spricht etwas dagegen, fix die von mir vorgeschlagene Lösung zu implementieren (also jeweils der letzte Wert vor der Änderung)?
Von der Datenmenge her dürfte es keine grosse Rolle spielen. Es betrifft ja nur Fälle, in denen zyklisch ein gleichbleibender Wert gesendet wird. Das sind ja eher wenige Items und der zusätzliche Datensatz entsteht ja dann nur bei einer Änderung.
Mehr Konfiguration bedeutet halt auch immer grossere Komplexität für die Benutzer und auch im Code.

Das würde ich genau so sehen und begrüßen

[psilo]

die datenmenge ist mangels komprimierung derzeit sowieso so oder so mehr als früher.. (aus meiner sicht auch unkritischerweise..)

frage ist ob es noch andere gründe gibt oder wer das testweise mal umsetzen will?

[smai]

Umsetzen würde ich es schon.

[Onkelandy]

#metoo bzw testen