(fixed)[patch] SVG fixedrange=hour zeigt werte zur vollen Stunde am Anfang nich

[JoeALLb]

Ich betreibe FHEM mit DBLOg und verwende SVG-Plots mit fixedrange=hour.
Wenn ich einen Plot von 10:00 bis 11:00 anzeige, würde ich denken, dass ein Wert in der DB der genau um 10:00:00 gesetzt wurde,
für den aktuellen Plot noch verwendet werden sollte.
Derzeit fürd dieser Wert nur für einen Plot von 09:00 bis 10:00 als endpunkt verwendet.

Fehlt hier eventuell nur ein >= anstatt eines > beim Zusammenstellen des SQL-Befehls?

Ich persönlich finde es schön, wenn ein Eintrag um 10:00 für beides verwendet wird, also als Endpunkt für den Plot  09:00 bis 10:00 und als
Anfangspunkt für den Plot 10:00 bis 11:00. Der MySQL-Between-Befehl würde dies ebenfalls so auswerten.

Ich bin mir auch nicht sicher, ob das ein SVG-Fehler oder ein Fehler in DbLog ist.

Anbei die Ergebnisse meiner Recherchen, vielleicht helfen diese für die Einschätzung des Problems.
Ich hoffe diese werden nicht als zu "unstrukturiert" betrachtet, ich versuchte einfach möglichst genau
herauszufinden, wo das problem besteht und was ich ggf. falsch verstehe...

Folgende Abfrage liefert interessanterweise den Eintrag um 11:00:00 nicht mit!
Im Plot wird er aber angezeigt. Wird hier für das Erhalten der Daten ein anderer Befehl abgesetzt?

Code Auswählen Erweitern

get myDbLogSQL - - 2014-03-14_10:00:00 2014-03-14_11:00:00 ESAx000WZ_466c:wattage
2014-03-14_10:00:10 214.858707293944
2014-03-14_10:03:07 271.496015377575
2014-03-14_10:08:16 465.697541996449
2014-03-14_10:13:32 303.574840402322
2014-03-14_10:26:13 252.344271732609
2014-03-14_10:28:53 299.519264112941
2014-03-14_10:33:30 173.377943238042
2014-03-14_10:36:31 265.098536653033
2014-03-14_10:39:18 288.260381561319
2014-03-14_10:41:51 314.295577059515
2014-03-14_10:52:17 306.735222024372
2014-03-14_10:57:35 150.947570576713

Die Abfrage von 11:00:00 bis 12:00:00 enthält den Logeintrag von 11:00:00 auch nicht.

Code Auswählen Erweitern

get myDbLogSQL - - 2014-03-14_11:00:00 2014-03-14_12:00:00 ESAx000WZ_466c:wattage
2014-03-14_11:23:30 286.536037183417
2014-03-14_11:28:23 164.152744374996
2014-03-14_11:33:20 484.565739878065
2014-03-14_11:40:35 220.880314387094
2014-03-14_11:48:52 289.729313829002
#ESAx000WZ_466c:wattage:::


Erst die Abfrage von 10:59:59 enthält diesen Logeintrag.

Code Auswählen Erweitern

get myDbLogSQL - - 2014-03-14_10:59:59 2014-03-14_12:00:00 ESAx000WZ_466c:wattage
2014-03-14_11:00:00 207.446274488318
2014-03-14_11:23:30 286.536037183417
2014-03-14_11:28:23 164.152744374996
2014-03-14_11:33:20 484.565739878065
2014-03-14_11:40:35 220.880314387094
2014-03-14_11:48:52 289.729313829002
#ESAx000WZ_466c:wattage:::

Ein MySQL-Between-Befehl gibt diesen Datensatz jedoch direkt zurück!

Code Auswählen Erweitern

mysql> SELECT timestamp, value FROM history h where device='ESAx000WZ_466c' and reading='wattage' and timestamp between '2014-03-14_11:00:00' and '2014-03-14_12:00:00';
+---------------------+------------------+
| timestamp           | value            |
+---------------------+------------------+
| 2014-03-14 11:00:00 | 207.446274488318 |
| 2014-03-14 11:23:30 | 286.536037183417 |
| 2014-03-14 11:28:23 | 164.152744374996 |
| 2014-03-14 11:33:20 | 484.565739878065 |
| 2014-03-14 11:40:35 | 220.880314387094 |
| 2014-03-14 11:48:52 | 289.729313829002 |
+---------------------+------------------+
6 rows in set (0.02 sec)

Dann habe ich versucht, herauszufinden,w elcher SQL_Befehl tatsächlich abgesetzt wird:
Anbei das Ergebnis:
Hier wird eine Sekunde zu der EndTimestamp hinzugefügt.

Code Auswählen Erweitern

SELECT
              DATE_FORMAT(TIMESTAMP, '%Y-%m-%d %H:%i:%s'),
              DEVICE,
              READING,
              VALUE
               FROM history WHERE 1=1 AND DEVICE  = 'ESAx000WZ_466c' AND READING = 'wattage' AND TIMESTAMP > STR_TO_DATE('2014-03-14 11:00:00', '%Y-%m-%d %H:%i:%s')
             AND TIMESTAMP < STR_TO_DATE('2014-03-14 12:00:01', '%Y-%m-%d %H:%i:%s')
             ORDER BY TIMESTAMP


Zusammenfassend wäre mein Wunsch,
dass auch Werte von "11:00:00" in einem Plot der von 11:00 bis 12:00 geht, angezeigt werden.

Anbei noch ein Screenshot des entsprechenden Plots zur Info.

[rudolfkoenig]

Das FileLog sucht die Strings mit gt und lt als Operator auf dem kompletten String (nicht nur Datums-Abschnitt). Aus diesem Grund muss beim Aufruf fuer die untere Grenze nichts angegeben werden, aber die obere Grenze muss um eine Zeit-Einheit erhoeht werden.

[JoeALLb]

Danke Rudi für die Antwort.

Aber ist das richtig? Ich denke, auch das untere Datum muss verändert werden, denn ein
Logeintrag von 11:00:00 sollte doch in einem Plott der von 11:00 bis 12:00 geht, auch angezeigt werden!
Wie auf meinem Screenshot zu sehen ist, kann dadurch eine schöne Lücke entstehen, die für mich per Definition nicht korrekt aussieht.

[rudolfkoenig]

Aber ist das richtig?

Ja.
FileLog zeigt 10:00-11:00 inklusive an.
Ich vermute DbLog muss leicht angepasst werden.

[JoeALLb]

Ich vermute DbLog muss leicht angepasst werden.

Ok, anbei mein Korrekturvorschlag,
um das Verhalten an FileLog anzugleichen.

Code Auswählen Erweitern

--- 93_DbLog.pm 2014-03-14 14:02:49.847548192 +0100
+++ 93_DbLog.pm.sv      2014-03-14 14:04:59.594064750 +0100
@@ -824,7 +824,7 @@
     $stm .= "AND READING = '".$readings[$i]->[1]."' "    if ($readings[$i]->[1] !~ m(\%));
     $stm .= "AND READING LIKE '".$readings[$i]->[1]."' " if(($readings[$i]->[1] !~ m(^%$)) && ($readings[$i]->[1] =~ m(\%)));

-    $stm .= "AND TIMESTAMP >= $sqlspec{from_timestamp}
+    $stm .= "AND TIMESTAMP > $sqlspec{from_timestamp}
              AND TIMESTAMP < $sqlspec{to_timestamp}
              ORDER BY TIMESTAMP";


[Niko]

Hallo,

den Wunsch möchte ich mich anschließen!

Auch ich habe die Probleme mir DbLog. Ich behelfe mir derzeit in der Form ,dass ich hin und wieder den timestamp in der Datenbank auf "volle Stunde + 1 Sekunde setze".

Daher auch von mir die Bitte um Anpassung von DbLog.

Vielen Dank im voraus und viele Grüße
Niko

[Tobias]

erledigt... wird heute eingecheckt

[Niko]

Abermals DANKE

Niko

[JoeALLb]

Danke. Habe den Titel um "(fixed)" ergänzt.