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)
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:
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:
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
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
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
Zitat von: Tobias am 24 April 2014, 15:06:18
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.
:-* Das hört sich gut an.
Gruß Joachim
Zitat von: Joachim am 24 April 2014, 14:55:29
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.
Moin Betateilchen,
Zu Deiner Frage:
ZitatWieso 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.
ZitatUnd 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.
Zitatnimm 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
Zitat von: Joachim am 25 April 2014, 15:10:15
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.
ZitatIch habe z.B. Wetterwerte, die ich nur einmal pro Stunde von fhem aus aktiv abfragen MUSS.
wie machst Du es bisher im Plot?
ZitatVariante 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
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.
Moin betateilchen,
ZitatDu 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
*Notizblock*
Angenommen, ich möchte den Bereich von 1500 bis 1600 ohne Abriss plotten:
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).
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:
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
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.
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
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.
Moin betateilchen,
nur damit wir nicht aneinander vorbeireden, ich möchte keine Werte in der Datenbank verändern, sondern nur den Anfangswert für SVG manipulieren.
Deine Argumentation ist natürlich grundsätzlich richtig, wenn man sie allerdings zuende verfolgt, bedeutet das, dass man in einem Plot nur Punkte anzeigen darf, da direkt hinter bzw. vor dem Event nicht sicher ist, dass der Wert stimmt.
Wenn man allerdings Linien anzeigt, muss man davon ausgehen, dass Änderungen durch das Device gemeldet werden, und der Bereich zwischen zwei Events dem des ersten Events entspricht, und dann ist es meiner Meinung nach nur eine Vereinfachung, da man sonst SVG anfassen müsste, um dort den Abruf so zu setzen, dass bei einem Plot von 0:00 bis 0:00 der Aufruf wäre: Liefere die Daten vom letzten Wert vor 0:00 bis 0:00 und zeichne der Graphen ab 0:00.
Gruß Joachim
Zitat von: Joachim am 02 Mai 2014, 11:48:34
wenn man sie allerdings zuende verfolgt, bedeutet das, dass man in einem Plot nur Punkte anzeigen darf, da direkt hinter bzw. vor dem Event nicht sicher ist, dass der Wert stimmt.
Du verwechselst dabei "Datenhaltung" mit "Datendarstellung". Eine graphische Darstellung ist immer nur eine optische Interpretation einer tatsächlich vorhandenen Datenbasis.
Im Prinzip hast Du aber mit den Punkten recht. Man muss nur die Punkte der echten Messwerte nahe genug nebeneinander ermitteln, dann kommt man irgendwann in den Bereich, wo das Auge einzelne Punkte nicht mehr unterscheiden kann und nur noch eine Linie sieht.