93_DbLog - Vermeidung von Plot-Abrissen

[Joachim]

Moin @ all,

Da der Tread "Vorschläge zur Weiterentwicklung" heißt, möchte ich mal eine Idee in die Diskussion werfen, die mir schon länger auf der Zunge liegt. Wenn dafür ein eigener Tread aufgemacht werden soll, dann sagt es.

Mich stört immer wieder bei meinen Plots der Plotabriss, wenn
a) am Anfang des Plots noch keine Daten vorhanden sind
b) am Ende des Plots keine aktuellen Daten vorhanden sind.
Als Beispiel:
Es sind folgende Daten in DBLog vorhanden (ja, ich weiß, diese Daten stammen aus einem Filelog, das sollte aber für das Verständniss nicht stören)

Code Auswählen Erweitern


2013-12-20_23:49:52 TS_Bad temperature: 19.7
2013-12-21_01:14:54 TS_Bad temperature: 19.0
2013-12-21_01:19:52 TS_Bad temperature: 18.9
2013-12-21_05:04:52 TS_Bad temperature: 19.5

es soll ein Plot generiert werden vom 21.12.2013 00:00 Uhr bis 06:00 Uhr.
Im angezeigten Plot würden nur diese Werte genutzt:

Code Auswählen Erweitern


2013-12-21_01:14:54 TS_Bad temperature: 19.0
2013-12-21_01:19:52 TS_Bad temperature: 18.9
2013-12-21_05:04:52 TS_Bad temperature: 19.5

da DBLog nur die Daten ausliefert, die nach 00:00 Uhr und vor 06:00 Uhr liegen. Der Plot fängt also erst um 01:14:54 Uhr an, und endet um 05:04:52 Uhr.
Meine (Schnaps)Idee wäre, stattdessen folgende Daten an SVG auszuliefern:

Code Auswählen Erweitern


2013-12-21_00:00:00 TS_Bad temperature: 19.7
2013-12-21_01:14:54 TS_Bad temperature: 19.0
2013-12-21_01:19:52 TS_Bad temperature: 18.9
2013-12-21_06:00:00 TS_Bad temperature: 19.5

Der Plot würde dann ohne Abriss angezeigt werden. Die 06:00 Uhr Anzeige muss natürlich gegen die aktuelle Uhrzeit getestet werden (also maximal bis zur aktuellen Uhrzeit, wenn die später ist wie die Endzeit des Plots, dann bis zur Endzeit des Plots).
Das ganze verfälscht die Anzeige, wenn ich keinen Denkfehler gemacht habe nicht, da um 00:00 Uhr die Temperatur von 23:49 Uhr immer noch gültig ist, und um 06:00 gilt das gleiche.
Habe ich hier einen Denkfehler, oder könnte man das so implementieren?

Gruß Joachim

[Tobias]

Diesbezüglich habe ich schon seit längerem ein Konzept im Kopf aber bisher nicht die zeit und den Druck dazu.

Gesendet von meinem ALCATEL ONE TOUCH 997D mit Tapatalk

[Joachim]

Danke für die Antwort,
dann war das ja schon mal keine Schnapsidee.
Wenn ich nur besser programmieren könnte. Ich habe den entsprechenden Teil von DBLog allerdings noch nicht wirklich verstanden.

Gruß Joachim

[betateilchen]

Diesbezüglich habe ich schon seit längerem ein Konzept im Kopf

Ich auch. Aber erst, wenn ein paar andere, wichtigere Baustellen in dem Modul beendet sind.

[Joachim]

  Das hört sich gut an.

Gruß Joachim

[betateilchen]

Mich stört immer wieder bei meinen Plots der Plotabriss, wenn
...
da DBLog nur die Daten ausliefert, die nach 00:00 Uhr und vor 06:00 Uhr liegen. Der Plot fängt also erst um 01:14:54 Uhr an, und endet um 05:04:52 Uhr.
Meine (Schnaps)Idee wäre, stattdessen folgende Daten an SVG auszuliefern:
...
Das ganze verfälscht die Anzeige, wenn ich keinen Denkfehler gemacht habe nicht, da um 00:00 Uhr die Temperatur von 23:49 Uhr immer noch gültig ist, und um 06:00 gilt das gleiche.
Habe ich hier einen Denkfehler, oder könnte man das so implementieren?

Was mich an Deiner Schnapsidee stört und was das Hauptproblem bei der Vermeidung des Plotabrisses ist, ist folgende Frage:

Wieso gehst Du so sicher davon aus, dass um 00:00 immer noch der gleiche Wert gültig ist wie um 23:49 Uhr und noch nicht der neue Wert von 01:14 ?

Eigentlich muss man vier Möglichkeiten implementieren:

• nimm den letzten Datenwert, der vor dem Beginn des Plotzeitraums liegt, als Anfangswert
• nimm den ersten Datenwert, der innerhalb des Plotzeitraums liegt, als Anfangswert
• nimm den Mittelwert aus den beiden vorgenannten Werten als Anfangswert
• lass das Verhalten so, wie es bisher ist

Und das gleiche dann auch nochmal für den Endwert.
Das Ganze per Attribut der SVG Definition steuerbar.
Und dann muss man auch noch den Fall berücksichtigen, dass es im Log überhaupt keinen Wert gibt, der vor dem Beginn des Plotzeitraums liegt.

Und genau diese komplexe Fragestellung macht macht richtig viel Arbeit.

[Joachim]

Moin Betateilchen,
Zu Deiner Frage:

Wieso gehst Du so sicher davon aus, dass um 00:00 immer noch der gleiche Wert gültig ist wie um 23:49 Uhr und noch nicht der neue Wert von 01:14 ?

Ich folge der Überlegung, dass ein Wert, der sich ändert, geloggt wird. Wenn bei einer Änderung kein Wert geschrieben wird, wurde dass durch den User explizit gewünscht. Z.B. durch die Wahl des Abfragezeitraums, oder sonstige Feinheiten, die eventuell direkt im Modul definiert wurden. Wenn die normale Funktion laufen würde, dann wäre in meinem Beispiel ja auch der nächste zu plottende Wert der vom 2013-12-21_01:14:54.
Zum Endwert, s.o.

Und dann muss man auch noch den Fall berücksichtigen, dass es im Log überhaupt keinen Wert gibt, der vor dem Beginn des Plotzeitraums liegt.

Durch einen Eintrag in dem Modul welches die Daten liefert,  läßt sich sicherstellen durch
event-min-interall, daß z.B. ein Eintrag alle 24 Stunden geschrieben wird, dann muß um 00:00 maximal 24 Stunden nach hinten gesehen werden, da mindestens ein Wert am Tag geschrieben wird.

nimm den Mittelwert aus den beiden vorgenannten Werten als Anfangswert

war mir zu arbeitsintensiv als Idee, und frisst Ressourcen. Wer feinere Abstufungen haben will, muß das Readings Intervall heraufsetzen was dann ja auch kein Problem ist, da bei gleichen Werten nur einmal alle 24 Std. geloggt wird.

Kann es sein, dass Deine Variante 2 und 4 identisch sind?

Attribut Steuerung ist eine gute Idee.

Ach ja, was noch dazu sagen ist, ich bin schon seit Januar am basteln, wie ich DBLog davon überzeuge, keine doppelten Werte in die Datenbank zu schreiben, hänge aber an einer Stelle, und wollte bisher mangels Zeit auch nicht Fremde Hilfe in Anspruch nehmen.
http://forum.fhem.de/index.php/topic,17468.0.html
Und in Verbindung mit der Änderung ist es halt wichtig, auch die Auslieferung der Werte an SVG anzufassen.

Gruß Joachim

[betateilchen]

Zu Deiner Frage:Ich folge der Überlegung, dass ein Wert, der sich ändert, geloggt wird.

die Grundsatzfrage bleibt aber: WANN wird er geloggt. Nicht jeder zu loggende Wert kommt von einem Sensor, der sich aktiv bei fhem meldet, um einen neuen Wert zu melden.

Ich habe z.B. Wetterwerte, die ich nur einmal pro Stunde von fhem aus aktiv abfragen MUSS.

Variante 2+4 sind nicht identisch. Wir haben nämlich zwei Grenzen.

[Joachim]

Ich habe z.B. Wetterwerte, die ich nur einmal pro Stunde von fhem aus aktiv abfragen MUSS.

wie machst Du es bisher im Plot?

Variante 2+4 sind nicht identisch. Wir haben nämlich zwei Grenzen.

also Variante 2 so,
nimm den ersten Datenwert, der innerhalb des Plotzeitraums liegt, als Anfangswert (verschieben auf "Plotbeginn")
im Gegensatz zu Variante 4,
nimm den ersten Datenwert, der innerhalb des Plotzeitraums liegt, als Anfangswert (nicht verschieben auf "Plotbeginn")

Gruß Joachim

[betateilchen]

Du musst bei Deiner Vorstellung über das Plotten über den Tellerrand eines Temperatursensors hinausschauen. Deshalb ist das Thema sehr viel komplexer und man muss einige Evenutalitäten mehr berücksichtigen, als Du hier darstellst. Deshalb gibt es bisher vermutlich auch noch keine Lösung innerhalb des Moduls.

Zur ersten Frage: Ich plotte nur Werte, die ich auch wirklich habe.

[Joachim]

Moin betateilchen,

Du musst bei Deiner Vorstellung über das Plotten über den Tellerrand eines Temperatursensors hinausschauen.

wenn ich Dich richtig verstehe, gibt es in Deinen Augen verschiedene Reading Arten, die ggf. unterschiedlich betrachtet werden müssen.
Dann fangen wir doch mal an, zu sammeln.
a) Readings, die nur feste, unterschiedliche Werte annehmen können, und automatisch durch ein Device geliefert werden. Bei diesen Readings ist der letzte Wert, egal wie lange er zurückliegt, der aktuelle Wert (es sei denn es ist ein nicht erwünschter Fehler, z.B. Absturz von FHEM o.ä., aufgetreten. Hierzu gehören z.B. Fensterkontakte (open, closed, tilted), Schalter (on, off) u.ä
b) Readings, mit Festkommazahlen, die automatisch durch ein Device geliefert werden, Auch hier sollte gelten, dass der letzte gelieferte Wert aktuell ist. Hierzu gehören z. B. Temperaturen, Drücke, Feuchte, Füllhöhen u.ä.
c) Readings, die manuell abgerufen werden, und bei denen ein Zwischenstand nicht aus dem alten und neuen Wert interpoliert werden kann. Hierzu gehören z.B. stündlich manuell abgerufenen Wetterwerte, die sich zwischendurch mehrfach geändert haben können.

Fallen Dir noch weitere ein?
Ich würde die Liste dann ergänzen.

Wie müssen die unterschiedlichen Readings behandelt werden:
Fall a) nimm den letzten Datenwert, der vor dem Beginn des Plotzeitraums liegt, als Anfangswert und den letzten Datenwert,der vor Ende des Plottzeitraums (aktuelle Uhrzeit) liegt als Endwert.

Fall b) nimm den Mittelwert aus den beiden vorgenannten Werten als Anfangswert und den letzten Datenwert,der vor Ende des Plottzeitraums (aktuelle Uhrzeit) liegt als Endwert.

Fall c) lass das Verhalten so, wie es bisher ist.

Kommentare erwünscht.

Gruß Joachim

[betateilchen]

*Notizblock*

Angenommen, ich möchte den Bereich von 1500 bis 1600 ohne Abriss plotten:

Code Auswählen Erweitern


select * from history where device='$device' and reading = '$reading' and timestamp < '2014-04-27 15:00:00' order by timestamp desc limit 1;


Damit finde ich schonmal den letzten geloggten Wert vor dem angegebenen Timestamp (in dem der _ durch ein Leerzeichen ersetzt werden muss).

Code Auswählen Erweitern


2014-04-27 14:58:15|out_Balkon|CUL_HM|temperature: 17.4|temperature|17.4|°C


Und so finde ich den ersten Wert, der heute nach 16 Uhr geloggt wurde:

Code Auswählen Erweitern


sqlite> select * from history where device='out_Balkon' and reading = 'temperature' and timestamp > '2014-04-27 16:00:00' order by timestamp limit 1;

2014-04-27 16:01:05|out_Balkon|CUL_HM|temperature: 18.5|temperature|18.5|°C


[betateilchen]

Wäre denn der einfachste denkbare Lösungsansatz nicht einfach der, mittels eines exakten Timers zu jeder vollen Stunde xx:00:00 den kompletten Inhalt von CURRENT nach HISTORY zu schreiben?

Beim Get für einen Stundenbereich wird ja ohnehin jetzt schon der Bereich 15:00:00 - 16:00:01 angefordert. Und innerhalb einer Sekunde lassen sich eine Menge Datensätze schreiben.

Ich werde das testweise bei mir mal einbauen.

[Joachim]

Moin betateilchen,
das wäre ein Ansatz, dabei ergeben sich aber neue Probleme, z.B. wenn endPlot now gesetzt ist, außerdem werden unnötige Zzusatzeinträge generiert.
In Verbindung mit der in diesem Tread angedachten Änderung
http://forum.fhem.de/index.php/topic,17468.0.html Antwort 22 (da mache ich die Tage weiter)
würde ich es als kontraproduktiv ansehen, wenn dann jede volle Stunde zusätzlich geloggt werden würde.

Gruß Joachim

[betateilchen]

Ich halte grundsätzlich nichts davon, die Timestamps von geloggten Daten zu verändern.
Das ist Betrug am Anwender, da ihm dabei Daten präsentiert werden, die schlichtweg falsch sind.