[gelöst] DbLog: delta-h(d) funktioniert nicht mehr

frober · 02 Oktober 2019, 18:52:03

Hallo Heiko,

ich habe dir die Daten als File angehängt.

Wenn du noch mehr Infos brauchst....

Gruß Bernd

DS_Starter · 02 Oktober 2019, 22:48:38

Hallo Bernd,

das ist ziemlich kompliziert.
Für einen ersten Test habe ich eine Version in mein contrib geleden.

Einfacher Download mit diesem Befehl in der FHEM Kommandozeile. Bitte so komplett mit den Ausführungszeichen am Anfang und Ende eingeben!!!

Code Auswählen

"wget -qO ./FHEM/93_DbLog.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_DbLog.pm"

Danach reload bzw. restart.

Grüße,
Heiko

DS_Starter · 03 Oktober 2019, 11:19:29

Hallo Bernd,

habe es mir heute nochmal vorgenommen und deine Daten bei mir importiert.
Die verbose 5 Ausgaben habe ich etwas erweitert. Nun sieht man deutlich dass die gelieferten Informationen im "preprocessed input" passen.

Zitat
2019.10.03 11:12:56.762 4: DbLog LogDB -> ################################################################
2019.10.03 11:12:56.763 4: DbLog LogDB -> ### new get data for SVG ###
2019.10.03 11:12:56.763 4: DbLog LogDB -> ################################################################
2019.10.03 11:12:56.764 4: DbLog LogDB -> main PID: 26237, secondary PID: 26237
2019.10.03 11:12:56.767 4: LogDB - Processing Statement: SELECT
MAX(DATE_FORMAT(TIMESTAMP, '%Y-%m-%d %H:%i:%s')) AS TIMESTAMP,
MAX(DEVICE) AS DEVICE,
MAX(READING) AS READING,
MAX(VALUE)
FROM fhemtest.history WHERE 1=1 AND DEVICE = 'KS300' AND READING = 'data' AND TIMESTAMP < STR_TO_DATE('2019-09-25 00:00:00', '%Y-%m-%d %H:%i:%s') AND TIMESTAMP > DATE_SUB(STR_TO_DATE('2019-09-25 00:00:00', '%Y-%m-%d %H:%i:%s'),INTERVAL 1 DAY) UNION ALL SELECT
MAX(DATE_FORMAT(TIMESTAMP, '%Y-%m-%d %H:%i:%s')) AS TIMESTAMP,
MAX(DEVICE) AS DEVICE,
MAX(READING) AS READING,
MAX(VALUE)
FROM fhemtest.history WHERE 1=1 AND DEVICE = 'KS300' AND READING = 'data' AND TIMESTAMP >= STR_TO_DATE('2019-09-25 00:00:00', '%Y-%m-%d %H:%i:%s') AND TIMESTAMP <= STR_TO_DATE('2019-09-26 00:00:00', '%Y-%m-%d %H:%i:%s') GROUP BY DATE_FORMAT(TIMESTAMP, '%Y-%m-%d %H') ORDER BY TIMESTAMP
2019.10.03 11:12:56.768 5: LogDB - SQL-result -> TS: 2019-09-24 23:45:11, DEV: KS300, RD: data, VAL: T: 9.9 H: 93 W: 0.0 R: 1664.4 IR: no Wi: 0
2019.10.03 11:12:56.769 5: LogDB - SQL-result -> TS: 2019-09-25 00:58:54, DEV: KS300, RD: data, VAL: T: 14.2 H: 92 W: 0.0 R: 1666.9 IR: no Wi: 0
2019.10.03 11:12:56.770 5: LogDB - SQL-result -> TS: 2019-09-25 01:54:49, DEV: KS300, RD: data, VAL: T: 14.4 H: 92 W: 0.0 R: 1666.9 IR: no Wi: 0
2019.10.03 11:12:56.770 5: LogDB - Output delta-h -> TS: 01, LASTTS: 00, OUTTS: 2019-09-25 00:30:00, OUTVAL: 2.5
2019.10.03 11:12:56.771 5: LogDB - SQL-result -> TS: 2019-09-25 02:53:17, DEV: KS300, RD: data, VAL: T: 14.5 H: 92 W: 0.0 R: 1666.9 IR: no Wi: 0

Die Ausgabe 2.5 ist genau die Differenz zwischen dem ersten Wert am 25.09. und dem letzten Wert des 24.09.

Ich kann da keinen Fehler feststellen. Lade dir bitte die DbLog Version nochmal aus meinem contrib um es mit verbose 5 nachvollziehen zu können.

Grüße,
Heiko

frober · 03 Oktober 2019, 13:21:26

Danke Heiko, ich komme leider erst heute Abend dazu zum testen.
Melde mich dann...

frober · 03 Oktober 2019, 17:11:31

Hallo Heiko,

der erste Test war negativ, auch Fhem aktualisieren hat nichts gebracht.

Dann fiel mir ein, dass ich die Regendaten ja aus früheren Tests noch mit logge.

Gplot auf rain umgestellt und nun funktioniert es. Zuvor hatte ich alles auf data mit regex gematcht:

Code Auswählen

#logProxy DbLog:logdb:KS300:data::delta-h:$val=~s/.*\sR..([\d.]*).*/$1/eg
#logProxy DbLog:logdb:KS300:data::delta-d:$val=~s/.*\sR..([\d.]*).*/$1/eg

nun:

Code Auswählen

#logProxy DbLog:logdb:KS300:rain::delta-h:
#logProxy DbLog:logdb:KS300:rain::delta-d:

und so funktioniert es.

Warum auch immer, der Fehler scheint woanders zu liegen

Wir lassen es so, danke für deine Mühe.

Gruß
Bernd

DS_Starter · 03 Oktober 2019, 17:25:31

Hallo Bernd,

ZitatGplot auf rain umgestellt und nun funktioniert es. Zuvor hatte ich alles auf data mit regex gematcht

Jetzt wo du es schreibst fällt es mir wie Schuppen von den Augen. Es könnte sein, dass deswegen das delta nicht berechnet werden kann weil in diesem Fall das VALUE aus der DB nicht numerisch ist.

Ich würde gern noch etwas probieren und dich bitten nochmal zu testen.

frober · 03 Oktober 2019, 17:31:09

Kein Problem, teste gerne..

DS_Starter · 03 Oktober 2019, 18:09:26

Dann zieh nochmal bitte aus dem contrib.
Mit verbose 5 sieht man nun im Log ob und wie der Regex auf den $val wirkt. Damit kann man kontrollieren ob der Regex den man im SVG-Editor eingetragen hat, so wirkt wie er soll.

Zitat
2019.10.03 18:04:08.313 4: DbLog LogDB -> ################################################################
2019.10.03 18:04:08.314 4: DbLog LogDB -> ### new get data for SVG ###
2019.10.03 18:04:08.314 4: DbLog LogDB -> ################################################################
2019.10.03 18:04:08.315 4: DbLog LogDB -> main PID: 26237, secondary PID: 26237
2019.10.03 18:04:08.317 4: LogDB - Processing Statement: SELECT
MAX(DATE_FORMAT(TIMESTAMP, '%Y-%m-%d %H:%i:%s')) AS TIMESTAMP,
MAX(DEVICE) AS DEVICE,
MAX(READING) AS READING,
MAX(VALUE)
FROM fhemtest.history WHERE 1=1 AND DEVICE = 'KS300' AND READING = 'data' AND TIMESTAMP < STR_TO_DATE('2019-09-25 00:00:00', '%Y-%m-%d %H:%i:%s') AND TIMESTAMP > DATE_SUB(STR_TO_DATE('2019-09-25 00:00:00', '%Y-%m-%d %H:%i:%s'),INTERVAL 1 DAY) UNION ALL SELECT
MAX(DATE_FORMAT(TIMESTAMP, '%Y-%m-%d %H:%i:%s')) AS TIMESTAMP,
MAX(DEVICE) AS DEVICE,
MAX(READING) AS READING,
MAX(VALUE)
FROM fhemtest.history WHERE 1=1 AND DEVICE = 'KS300' AND READING = 'data' AND TIMESTAMP >= STR_TO_DATE('2019-09-25 00:00:00', '%Y-%m-%d %H:%i:%s') AND TIMESTAMP <= STR_TO_DATE('2019-09-26 00:00:00', '%Y-%m-%d %H:%i:%s') GROUP BY DATE_FORMAT(TIMESTAMP, '%Y-%m-%d %H') ORDER BY TIMESTAMP
2019.10.03 18:04:08.318 5: LogDB - SQL-result -> TS: 2019-09-24 23:45:11, DEV: KS300, RD: data, VAL: T: 9.9 H: 93 W: 0.0 R: 1664.4 IR: no Wi: 0
2019.10.03 18:04:08.319 5: LogDB - Result after Regex -> TS: 2019-09-24 23:45:11, DEV: KS300, RD: data, VAL: 1664.4
2019.10.03 18:04:08.320 5: LogDB - SQL-result -> TS: 2019-09-25 00:58:54, DEV: KS300, RD: data, VAL: T: 14.2 H: 92 W: 0.0 R: 1666.9 IR: no Wi: 0
2019.10.03 18:04:08.321 5: LogDB - Result after Regex -> TS: 2019-09-25 00:58:54, DEV: KS300, RD: data, VAL: 1666.9
2019.10.03 18:04:08.321 5: LogDB - SQL-result -> TS: 2019-09-25 01:54:49, DEV: KS300, RD: data, VAL: T: 14.4 H: 92 W: 0.0 R: 1666.9 IR: no Wi: 0
2019.10.03 18:04:08.322 5: LogDB - Result after Regex -> TS: 2019-09-25 01:54:49, DEV: KS300, RD: data, VAL: 1666.9
2019.10.03 18:04:08.323 5: LogDB - Output delta-h -> TS: 01, LASTTS: 00, OUTTS: 2019-09-25 00:30:00, OUTVAL: 2.5

Probier mal damit. Dann sieht man auch wenn der Regex angepasst werden muss weil er nicht den numerischen Wert extrahiert o. dgl.

Grüße,
Heiko

frober · 03 Oktober 2019, 18:50:27

Mein log sieht genauso aus:

Zitat2019.10.03 18:24:51 4: DbLog logdb -> ################################################################
2019.10.03 18:24:51 4: DbLog logdb -> ### new get data for SVG ###
2019.10.03 18:24:51 4: DbLog logdb -> ################################################################
2019.10.03 18:24:51 4: DbLog logdb -> main PID: 3782, secondary PID: 3782
2019.10.03 18:24:51 4: logdb - Processing Statement: SELECT
MAX(DATE_FORMAT(TIMESTAMP, '%Y-%m-%d %H:%i:%s')) AS TIMESTAMP,
MAX(DEVICE) AS DEVICE,
MAX(READING) AS READING,
MAX(VALUE)
FROM history WHERE 1=1 AND DEVICE = 'KS300' AND READING = 'data' AND TIMESTAMP < STR_TO_DATE('2019-09-25 00:00:00', '%Y-%m-%d %H:%i:%s') AND TIMESTAMP > DATE_SUB(STR_TO_DATE('2019-09-25 00:00:00', '%Y-%m-%d %H:%i:%s'),INTERVAL 1 DAY) UNION ALL SELECT
MAX(DATE_FORMAT(TIMESTAMP, '%Y-%m-%d %H:%i:%s')) AS TIMESTAMP,
MAX(DEVICE) AS DEVICE,
MAX(READING) AS READING,
MAX(VALUE)
FROM history WHERE 1=1 AND DEVICE = 'KS300' AND READING = 'data' AND TIMESTAMP >= STR_TO_DATE('2019-09-25 00:00:00', '%Y-%m-%d %H:%i:%s') AND TIMESTAMP <= STR_TO_DATE('2019-09-26 00:00:00', '%Y-%m-%d %H:%i:%s') GROUP BY DATE_FORMAT(TIMESTAMP, '%Y-%m-%d %H') ORDER BY TIMESTAMP
2019.10.03 18:24:51 5: logdb - SQL-result -> TS: 2019-09-24 23:45:11, DEV: KS300, RD: data, VAL: T: 9.9 H: 93 W: 0.0 R: 1664.4 IR: no Wi: 0
2019.10.03 18:24:51 5: logdb - Result after Regex -> TS: 2019-09-24 23:45:11, DEV: KS300, RD: data, VAL: 1664.4
2019.10.03 18:24:51 5: logdb - SQL-result -> TS: 2019-09-25 00:58:54, DEV: KS300, RD: data, VAL: T: 14.2 H: 92 W: 0.0 R: 1666.9 IR: no Wi: 0
2019.10.03 18:24:51 5: logdb - Result after Regex -> TS: 2019-09-25 00:58:54, DEV: KS300, RD: data, VAL: 1666.9
2019.10.03 18:24:51 5: logdb - SQL-result -> TS: 2019-09-25 01:54:49, DEV: KS300, RD: data, VAL: T: 14.4 H: 92 W: 0.0 R: 1666.9 IR: no Wi: 0
2019.10.03 18:24:51 5: logdb - Result after Regex -> TS: 2019-09-25 01:54:49, DEV: KS300, RD: data, VAL: 1666.9
2019.10.03 18:24:51 5: logdb - Output delta-h -> TS: 01, LASTTS: 00, OUTTS: 2019-09-25 00:30:00, OUTVAL: 2.5

Wieso ist um 23:45 die Regengesamtmenge abweichend? Laut Datenbank gibt es keine Unterschied: Nachtrag: der komplette Datensatz stimmt um 23:45 nicht.

Nachtrag2: Der Datensatz stammt von:

Zitat"2019-09-24 06:43:23","KS300","KS300","state: T: 9.9 H: 93 W: 0.0 R: 1664.4 IR: no Wi: 0","data","T: 9.9 H: 93 W: 0.0 R: 1664.4 IR: no Wi: 0",""

Zitat"2019-09-24 23:32:29","KS300","KS300","rain: 1666.9","rain","1666.9","l/m2"
"2019-09-24 23:37:34","KS300","KS300","state: T: 14.1 H: 92 W: 0.0 R: 1666.9 IR: no Wi: 0","data","T: 14.1 H: 92 W: 0.0 R: 1666.9 IR: no Wi: 0",""
"2019-09-24 23:37:34","KS300","KS300","rain: 1666.9","rain","1666.9","l/m2"
"2019-09-24 23:45:11","KS300","KS300","state: T: 14.1 H: 92 W: 0.0 R: 1666.9 IR: no Wi: 0","data","T: 14.1 H: 92 W: 0.0 R: 1666.9 IR: no Wi: 0",""
"2019-09-24 23:45:11","KS300","KS300","rain: 1666.9","rain","1666.9","l/m2"
"2019-09-25 00:08:04","KS300","KS300","avg_day: T: 14.2 H: 87 W: 0.0 R: 2.5","average","avg_day: T: 14.2 H: 87 W: 0.0 R: 2.5",""
"2019-09-25 00:08:04","KS300","KS300","state: T: 14.1 H: 92 W: 0.0 R: 1666.9 IR: no Wi: 0","data","T: 14.1 H: 92 W: 0.0 R: 1666.9 IR: no Wi: 0",""
"2019-09-25 00:08:04","KS300","KS300","rain: 1666.9","rain","1666.9","l/m2"
"2019-09-25 00:10:36","KS300","KS300","state: T: 14.1 H: 92 W: 0.0 R: 1666.9 IR: no Wi: 0","data","T: 14.1 H: 92 W: 0.0 R: 1666.9 IR: no Wi: 0",""
"2019-09-25 00:10:36","KS300","KS300","rain: 1666.9","rain","1666.9","l/m2"
"2019-09-25 00:13:09","KS300","KS300","state: T: 14.1 H: 92 W: 0.0 R: 1666.9 IR: no Wi: 0","data","T: 14.1 H: 92 W: 0.0 R: 1666.9 IR: no Wi: 0",""
"2019-09-25 00:13:09","KS300","KS300","rain: 1666.9","rain","1666.9","l/m2"
"2019-09-25 00:33:29","KS300","KS300","state: T: 14.1 H: 92 W: 0.0 R: 1666.9 IR: no Wi: 0","data","T: 14.1 H: 92 W: 0.0 R: 1666.9 IR: no Wi: 0",""
"2019-09-25 00:33:29","KS300","KS300","rain: 1666.9","rain","1666.9","l/m2"
"2019-09-25 00:36:01","KS300","KS300","state: T: 14.1 H: 92 W: 0.0 R: 1666.9 IR: no Wi: 0","data","T: 14.1 H: 92 W: 0.0 R: 1666.9 IR: no Wi: 0",""
"2019-09-25 00:36:01","KS300","KS300","rain: 1666.9","rain","1666.9","l/m2"
"2019-09-25 00:38:34","KS300","KS300","state: T: 14.1 H: 92 W: 0.0 R: 1666.9 IR: no Wi: 0","data","T: 14.1 H: 92 W: 0.0 R: 1666.9 IR: no Wi: 0",""
"2019-09-25 00:38:34","KS300","KS300","rain: 1666.9","rain","1666.9","l/m2"
"2019-09-25 00:48:44","KS300","KS300","state: T: 14.2 H: 92 W: 0.0 R: 1666.9 IR: no Wi: 0","data","T: 14.2 H: 92 W: 0.0 R: 1666.9 IR: no Wi: 0",""
"2019-09-25 00:48:44","KS300","KS300","rain: 1666.9","rain","1666.9","l/m2"
"2019-09-25 00:51:16","KS300","KS300","state: T: 14.2 H: 92 W: 0.0 R: 1666.9 IR: no Wi: 0","data","T: 14.2 H: 92 W: 0.0 R: 1666.9 IR: no Wi: 0",""
"2019-09-25 00:51:16","KS300","KS300","rain: 1666.9","rain","1666.9","l/m2"
"2019-09-25 00:56:21","KS300","KS300","state: T: 14.2 H: 92 W: 0.0 R: 1666.9 IR: no Wi: 0","data","T: 14.2 H: 92 W: 0.0 R: 1666.9 IR: no Wi: 0",""
"2019-09-25 00:56:21","KS300","KS300","rain: 1666.9","rain","1666.9","l/m2"
"2019-09-25 00:58:54","KS300","KS300","state: T: 14.2 H: 92 W: 0.0 R: 1666.9 IR: no Wi: 0","data","T: 14.2 H: 92 W: 0.0 R: 1666.9 IR: no Wi: 0",""
"2019-09-25 00:58:54","KS300","KS300","rain: 1666.9","rain","1666.9","l/m2"
"2019-09-25 01:01:27","KS300","KS300","state: T: 14.2 H: 92 W: 0.0 R: 1666.9 IR: no Wi: 0","data","T: 14.2 H: 92 W: 0.0 R: 1666.9 IR: no Wi: 0",""
"2019-09-25 01:01:27","KS300","KS300","rain: 1666.9","rain","1666.9","l/m2"

Gruß Bernd

DS_Starter · 03 Oktober 2019, 19:19:51

Das Ergebnis ist entsprechenden Selects den du im Log auch siehst.
Der wird schon immer so verwendet. Du kannst ihn auch im DbRep oder einem SQL-Frontend deiner Wahl ausführen. Es kommt das gleiche Ergebnis.

Hm, ich denke das Statement hat ein Problem. Gute Frage wieso dieser Datensatz so geliefert wird.
Ideen sind willkommen.

frober · 03 Oktober 2019, 20:46:45

Ich habe zwar nicht ganz verstanden was du meinst, aber ich muss widersprechen.

Ich habe nochmal auf 'rain' gematcht:

Zitat2019.10.03 20:21:38 4: DbLog logdb -> ################################################################
2019.10.03 20:21:38 4: DbLog logdb -> ### new get data for SVG ###
2019.10.03 20:21:38 4: DbLog logdb -> ################################################################
2019.10.03 20:21:38 4: DbLog logdb -> main PID: 3782, secondary PID: 3782
2019.10.03 20:21:38 4: logdb - Processing Statement: SELECT
MAX(DATE_FORMAT(TIMESTAMP, '%Y-%m-%d %H:%i:%s')) AS TIMESTAMP,
MAX(DEVICE) AS DEVICE,
MAX(READING) AS READING,
MAX(VALUE)
FROM history WHERE 1=1 AND DEVICE = 'KS300' AND READING = 'rain' AND TIMESTAMP < STR_TO_DATE('2019-09-25 00:00:00', '%Y-%m-%d %H:%i:%s') AND TIMESTAMP > DATE_SUB(STR_TO_DATE('2019-09-25 00:00:00', '%Y-%m-%d %H:%i:%s'),INTERVAL 1 DAY) UNION ALL SELECT
MAX(DATE_FORMAT(TIMESTAMP, '%Y-%m-%d %H:%i:%s')) AS TIMESTAMP,
MAX(DEVICE) AS DEVICE,
MAX(READING) AS READING,
MAX(VALUE)
FROM history WHERE 1=1 AND DEVICE = 'KS300' AND READING = 'rain' AND TIMESTAMP >= STR_TO_DATE('2019-09-25 00:00:00', '%Y-%m-%d %H:%i:%s') AND TIMESTAMP <= STR_TO_DATE('2019-09-26 00:00:00', '%Y-%m-%d %H:%i:%s') GROUP BY DATE_FORMAT(TIMESTAMP, '%Y-%m-%d %H') ORDER BY TIMESTAMP
2019.10.03 20:21:38 5: logdb - SQL-result -> TS: 2019-09-24 23:45:11, DEV: KS300, RD: rain, VAL: 1666.9
2019.10.03 20:21:38 5: logdb - SQL-result -> TS: 2019-09-25 00:58:54, DEV: KS300, RD: rain, VAL: 1666.9
2019.10.03 20:21:38 5: logdb - SQL-result -> TS: 2019-09-25 01:54:49, DEV: KS300, RD: rain, VAL: 1666.9
2019.10.03 20:21:38 5: logdb - Output delta-h -> TS: 01, LASTTS: 00, OUTTS: 2019-09-25 00:30:00, OUTVAL: 0
2019.10.03 20:21:38 5: logdb - SQL-result -> TS: 2019-09-25 02:53:17, DEV: KS300, RD: rain, VAL: 1666.9
2019.10.03 20:21:38 5: logdb - Output delta-h -> TS: 02, LASTTS: 01, OUTTS: 2019-09-25 01:30:00, OUTVAL: 0

Zum Vergleich 'data':

Zitat2019.10.03 18:24:51 4: DbLog logdb -> ################################################################
2019.10.03 18:24:51 4: DbLog logdb -> ### new get data for SVG ###
2019.10.03 18:24:51 4: DbLog logdb -> ################################################################
2019.10.03 18:24:51 4: DbLog logdb -> main PID: 3782, secondary PID: 3782
2019.10.03 18:24:51 4: logdb - Processing Statement: SELECT
MAX(DATE_FORMAT(TIMESTAMP, '%Y-%m-%d %H:%i:%s')) AS TIMESTAMP,
MAX(DEVICE) AS DEVICE,
MAX(READING) AS READING,
MAX(VALUE)
FROM history WHERE 1=1 AND DEVICE = 'KS300' AND READING = 'data' AND TIMESTAMP < STR_TO_DATE('2019-09-25 00:00:00', '%Y-%m-%d %H:%i:%s') AND TIMESTAMP > DATE_SUB(STR_TO_DATE('2019-09-25 00:00:00', '%Y-%m-%d %H:%i:%s'),INTERVAL 1 DAY) UNION ALL SELECT
MAX(DATE_FORMAT(TIMESTAMP, '%Y-%m-%d %H:%i:%s')) AS TIMESTAMP,
MAX(DEVICE) AS DEVICE,
MAX(READING) AS READING,
MAX(VALUE)
FROM history WHERE 1=1 AND DEVICE = 'KS300' AND READING = 'data' AND TIMESTAMP >= STR_TO_DATE('2019-09-25 00:00:00', '%Y-%m-%d %H:%i:%s') AND TIMESTAMP <= STR_TO_DATE('2019-09-26 00:00:00', '%Y-%m-%d %H:%i:%s') GROUP BY DATE_FORMAT(TIMESTAMP, '%Y-%m-%d %H') ORDER BY TIMESTAMP
2019.10.03 18:24:51 5: logdb - SQL-result -> TS: 2019-09-24 23:45:11, DEV: KS300, RD: data, VAL: T: 9.9 H: 93 W: 0.0 R: 1664.4 IR: no Wi: 0
2019.10.03 18:24:51 5: logdb - Result after Regex -> TS: 2019-09-24 23:45:11, DEV: KS300, RD: data, VAL: 1664.4
2019.10.03 18:24:51 5: logdb - SQL-result -> TS: 2019-09-25 00:58:54, DEV: KS300, RD: data, VAL: T: 14.2 H: 92 W: 0.0 R: 1666.9 IR: no Wi: 0
2019.10.03 18:24:51 5: logdb - Result after Regex -> TS: 2019-09-25 00:58:54, DEV: KS300, RD: data, VAL: 1666.9
2019.10.03 18:24:51 5: logdb - SQL-result -> TS: 2019-09-25 01:54:49, DEV: KS300, RD: data, VAL: T: 14.4 H: 92 W: 0.0 R: 1666.9 IR: no Wi: 0
2019.10.03 18:24:51 5: logdb - Result after Regex -> TS: 2019-09-25 01:54:49, DEV: KS300, RD: data, VAL: 1666.9
2019.10.03 18:24:51 5: logdb - Output delta-h -> TS: 01, LASTTS: 00, OUTTS: 2019-09-25 00:30:00, OUTVAL: 2.5

Hast du meine Nachtrag in letzten Post gesehen?
Die Daten von 23:45 bei 'data' stammen eigentlich von 6:43.

Zitat"2019-09-24 06:43:23","KS300","KS300","state: T: 9.9 H: 93 W: 0.0 R: 1664.4 IR: no Wi: 0","data","T: 9.9 H: 93 W: 0.0 R: 1664.4 IR: no Wi: 0",""

D.h. Delta-h wird um 0:30 über ca. 18 Std gebildet.

DS_Starter · 03 Oktober 2019, 21:02:51

Zitat
Hast du meine Nachtrag in letzten Post gesehen?
Die Daten von 23:45 bei 'data' stammen eigentlich von 6:43.

Ja ich weiß und bin auf der Suche nach einer Erklärung.

Der Unterschied bei Benutzung von "data" und "rain" ist, dass "rain" ein numerischer Wert ist und "data" durch seine Struktur in VALUE ein String. In beiden Fällen wird aber das SQL-Statement mit MAX() gebildet. Meiner Kenntnis nach werden bei Anwendung von MAX() auf Strings die Datensätze nach alphabetischer Hierarchie bewertet.
Wahrscheinlich liegt darin die Ursache für das unterschiedliche Ergebnis bei Anwendung der identischen SQL-Abfrage.

Ich sehe momentan keine Lösung, außer eben rain zu nutzen.

frober · 03 Oktober 2019, 21:16:13

Soweit hatte ich das verstanden.

Was ich nicht verstehe, wieso wird bei 'data' um 23:45 die Daten von 6:43 angezeigt. Das hat doch nichts mit numerisch, bzw. string zu tun.

Ursprünglich wurde bei 'data' kein delta ausgewertet wg. des Strings. Was du ja gefixt hast. Könnte es sein, dass hier noch ein Tippfehler o.ä. vorhanden ist?

frober · 03 Oktober 2019, 21:17:49

P.S. rain ist kein Problem, möchte dir keine unnötige Arbeit aufdrängen.

DS_Starter · 03 Oktober 2019, 21:25:55

ZitatWas ich nicht verstehe, wieso wird bei 'data' um 23:45 die Daten von 6:43 angezeigt. Das hat doch nichts mit numerisch, bzw. string zu tun.

Ich auch nicht. Aber du kannst das Statement aus dem Log nehmen und exakt so in einem x-beliebigen Datenbank-Frontend ausführen. Das Ergebnis ist das gleiche. Hat also nichts mit DbLog zu tun.

Tippfehler ... nein, das schließe ich aus.
Arbeit ist nicht das Problem wenn ich wüßte wie anzusetzen wäre.

Sehe ich aber gerade nicht, vllt. kommt mir noch eine Idee, oder jemanden ...