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

[frober]

Hallo,

ich benutze DbLog mit logproxy und einer KS300-Wetterstation. Seit einiger Zeit funktioniert das delta-h/delta-d im Plot nicht mehr. Fhem ist aktuell.
Das einzige was ich geändert habe, ist von SQLite zu MySQL zu wechseln.
Ich logge das state vom KS300, der regex funktioniert, wenn ich das delta in der gplot-Datei heraus nehme, bekomme ich die Gesamtregenmenge im Plot angezeigt.

list DbLog_KS300

Code Auswählen Erweitern


Internals:
   DEF        logProxy:DbLog_KS300:HISTORY
   FUUID      5c4a0c7e-f33f-ff70-7ffe-d55c4ee8cd85483a
   GPLOTFILE  DbLog_KS300
   LOGDEVICE  logProxy
   LOGFILE    HISTORY
   NAME       DbLog_KS300
   NOTIFYDEV  global
   NR         332
   STATE      initialized
   TYPE       SVG
Attributes:
   label      "KS300 Min $data{min1}, Max $data{max1}, Last $data{currval1},"
   room       Aussen
   sortby     1


Definition in DbLog_KS300.gplot

Code Auswählen Erweitern


#logProxy DbLog:logdb,extend=1200:KS300:data:::$val=~s/^T..([\d.-]*).*/$1/eg
#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
#logProxy DbLog:logdb,extend=1800:TH_Aussen:state:::$val=~s/^T..([\d.-]*).*/$1/eg
#logProxy DbLog:logdb:KS300:data:::$val=~s/.*IR..(yes|no)(\d*).*/$1eq"yes"?1:-2/eg


zu Temp-Aussen: Der Sensor ist zur Zeit defekt, deshalb keine Anzeige.

Hat jemand eine Idee?

Gruß und danke
Bernd

Nachtrag: Betreff angepasst, die KS300 ist nicht das Problem.

[frober]

Keiner eine Idee?

Gab es eine Änderung im DbLog, die ich übersehen habe?
Oder kommt das Problem gar nicht von DbLog?

Die Umstellung von SQLite zu MySQL hat problemlos funktioniert.
Leider kann ich den Zeitpunkt des Problem und der Umstellung der Datenbank nicht mehr nachvollziehen.

Gruß Bernd

[DS_Starter]

Hallo Bernd,

sorry, deine Anfrage hatte ich übersehen.

Gab es eine Änderung im DbLog, die ich übersehen habe?

Nein, in DbLog gab es schon längere Zeit keine inhaltlichen Änderungen, seit Oktober letzten Jahres waren die Änderungen lediglich kosmetischer Natur. Ich fange gerade erst wieder damit an DbLog etwas anzupassen.

Also vermutlich liegt es nicht am DbLog bzw. wenn doch, wäre es ein Problem welches es schon lange in der Konstellation logproxy und MySQL geben müsste und nur keinem aufgefallen ist (eher unwahrscheinlich). Ich selbst benutze auch kein logproxy, insofern müsste ich mich dort erst einlesen.
Vielleicht hat noch jemand eine Idee der logproxy _und_ MySQL nutzt.

Ungeachtet dessen schaue ich auch mal in einem Testsystem wenn ich dazu komme.

Grüße,
Heiko

[frober]

Hallo Heiko,

ich habe Mal eine Kopie vom SVG und gplot-File ohne logproxy erstellt. Genau das gleiche
Die delta-Berechnung kommt doch aus DbLog, oder?

Ich bin mittlerweile bei über 1400l Regenmenge angekommen, da ich Akkus mit Solarzelle beim KS300 benutze.
Normalerweise wird das Reading bei jedem Batteriewechsel genullt. Kann es sein, dass es bei der delta-Berechnung bei solchen Werten Problem gibt?
Ich meine bei >1200l hat es noch funktioniert.

Gruß Bernd

[frober]

Mir ist noch etwas aufgefallen:
Unter "Show preprocessed Input" wird das delta-h stündlich nur von 00:30 - 18:30 angezeigt, sollte doch bis 23:30 sein?

[DS_Starter]

Hallo Bernd,

jetzt habe ich mir das mal etwas genauer angeschaut. Also die gute Nachricht ist ...

Die delta-Berechnung kommt doch aus DbLog, oder?

Ja.

Die schlechte Nachricht ist, dass die Logik der Get-Funktion in DbLog, welche unter anderem die Plotdaten liefert seit mindestens 2,5 Jahren (vermutlich noch länger) nicht verändert wurde. 

Um zu sehen welches Statement an die Datenbank abgesetzt wird und was dann geliefert wird gehe mal bitte wie folgt vor:

1. setzte im DBlog device verbose 4
2. führe dann in der Befehlszeile im FHEMWEB das folgende Statement aus:
    get logdb - ALL 2019-04-05 2019-04-06 KS300:data::delta-h KS300:data::delta-d

Dann kommen Logeinträge, die in meinem Beispiel (Daten eines Energiemessers) so aussehen:

Code Auswählen Erweitern


2019.04.06 22:54:56.277 4: Processing Statement: SELECT
                  MAX(DATE_FORMAT(TIMESTAMP, '%Y-%m-%d %H:%i:%s')) AS TIMESTAMP,
                  MAX(DEVICE) AS DEVICE,
                  MAX(READING) AS READING,
                  MAX(CAST(VALUE AS DECIMAL(20,8)))
                  ,MAX(TYPE) AS TYPE,MAX(EVENT) AS EVENT,MAX(UNIT) AS UNIT FROM history WHERE 1=1 AND DEVICE  = 'SMA_Energymeter' AND READING = 'Saldo_Wirkleistung' AND TIMESTAMP < STR_TO_DATE('2019-04-05 00:00:00', '%Y-%m-%d %H:%i:%s') AND TIMESTAMP > DATE_SUB(STR_TO_DATE('2019-04-05 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(CAST(VALUE AS DECIMAL(20,8)))
                  ,MAX(TYPE) AS TYPE,MAX(EVENT) AS EVENT,MAX(UNIT) AS UNIT FROM history WHERE 1=1 AND DEVICE  = 'SMA_Energymeter' AND READING = 'Saldo_Wirkleistung' AND TIMESTAMP >= STR_TO_DATE('2019-04-05 00:00:00', '%Y-%m-%d %H:%i:%s') AND TIMESTAMP <= STR_TO_DATE('2019-04-06 00:00:00', '%Y-%m-%d %H:%i:%s') GROUP BY DATE_FORMAT(TIMESTAMP, '%Y-%m-%d %H') ORDER BY TIMESTAMP
2019.04.06 22:54:56.408 4: Processing Statement: SELECT
                  MAX(DATE_FORMAT(TIMESTAMP, '%Y-%m-%d %H:%i:%s')) AS TIMESTAMP,
                  MAX(DEVICE) AS DEVICE,
                  MAX(READING) AS READING,
                  MAX(CAST(VALUE AS DECIMAL(20,8)))
                  ,MAX(TYPE) AS TYPE,MAX(EVENT) AS EVENT,MAX(UNIT) AS UNIT FROM history WHERE 1=1 AND DEVICE  = 'SMA_Energymeter' AND READING = 'Saldo_Wirkleistung' AND TIMESTAMP < STR_TO_DATE('2019-04-05 00:00:00', '%Y-%m-%d %H:%i:%s') AND TIMESTAMP > DATE_SUB(STR_TO_DATE('2019-04-05 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(CAST(VALUE AS DECIMAL(20,8)))
                  ,MAX(TYPE) AS TYPE,MAX(EVENT) AS EVENT,MAX(UNIT) AS UNIT FROM history WHERE 1=1 AND DEVICE  = 'SMA_Energymeter' AND READING = 'Saldo_Wirkleistung' AND TIMESTAMP >= STR_TO_DATE('2019-04-05 00:00:00', '%Y-%m-%d %H:%i:%s') AND TIMESTAMP <= STR_TO_DATE('2019-04-06 00:00:00', '%Y-%m-%d %H:%i:%s') GROUP BY DATE_FORMAT(TIMESTAMP, '%Y-%m-%d %H') ORDER BY TIMESTAMP


Die gelieferten Daten siehst du du in einem Popup wie im Anhang. Diese gelieferten Daten sollten plausibel sein.
Du siehst auch dass die Stundendifferenzen bis 23:30 geliefert werden. Wenn das bei dir nicht so ist, dann gibt es vermutlich ab 18:30 keine Deltas mehr.
Man sieht also dass die Werte geliefert werden wie sie sollen.

Normalerweise wird das Reading bei jedem Batteriewechsel genullt. Kann es sein, dass es bei der delta-Berechnung bei solchen Werten Problem gibt?
Ich meine bei >1200l hat es noch funktioniert.

Unwahrscheinlich. Die Differenzen werden durch einfache Mathematik ermittelt wie ich im Code gesehen habe.

Also im Moment kann ich keinen Fehler feststellen, schau mal bei dir.
Vermutlich stimmt der Regex im gplot-Fle nicht weil doch bei den Differenzen lediglich Zahlenwerte kommen und keine Strings. Nimm bei den delta-Einträgen die Einträge "$val=~s/.*\sR..([\d.]*).*/$1/eg" mal raus. Ich vermute hier stark die Ursache des Problems.

Grüße,
Heiko

[frober]

Hallo Heiko,

erst mal danke für deine Mühe und Hilfe.

Mit deiner Abfrage: 

Code Auswählen Erweitern

get logdb - ALL 2019-04-04 2019-04-05 KS300:data::delta-h KS300:data::delta-d

bleibt das Popup leer

im log mit Verbose 4:

Code Auswählen Erweitern

2019.04.07 10:02:48 4: Processing Statement: SELECT
                  MAX(DATE_FORMAT(TIMESTAMP, '%Y-%m-%d %H:%i:%s')) AS TIMESTAMP,
                  MAX(DEVICE) AS DEVICE,
                  MAX(READING) AS READING,
                  MAX(CAST(VALUE AS DECIMAL(20,8)))
                  ,MAX(TYPE) AS TYPE,MAX(EVENT) AS EVENT,MAX(UNIT) AS UNIT FROM history WHERE 1=1 AND DEVICE  = 'KS300' AND READING = 'data' AND TIMESTAMP < STR_TO_DATE('2019-04-04 00:00:00', '%Y-%m-%d %H:%i:%s') AND TIMESTAMP > DATE_SUB(STR_TO_DATE('2019-04-04 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(CAST(VALUE AS DECIMAL(20,8)))
                  ,MAX(TYPE) AS TYPE,MAX(EVENT) AS EVENT,MAX(UNIT) AS UNIT FROM history WHERE 1=1 AND DEVICE  = 'KS300' AND READING = 'data' AND TIMESTAMP >= STR_TO_DATE('2019-04-04 00:00:00', '%Y-%m-%d %H:%i:%s') AND TIMESTAMP <= STR_TO_DATE('2019-04-05 00:00:00', '%Y-%m-%d %H:%i:%s') GROUP BY DATE_FORMAT(TIMESTAMP, '%Y-%m-%d %H') ORDER BY TIMESTAMP
2019.04.07 10:02:48 4: Processing Statement: SELECT
                  MAX(DATE_FORMAT(TIMESTAMP, '%Y-%m-%d %H:%i:%s')) AS TIMESTAMP,
                  MAX(DEVICE) AS DEVICE,
                  MAX(READING) AS READING,
                  MAX(CAST(VALUE AS DECIMAL(20,8)))
                  ,MAX(TYPE) AS TYPE,MAX(EVENT) AS EVENT,MAX(UNIT) AS UNIT FROM history WHERE 1=1 AND DEVICE  = 'KS300' AND READING = 'data' AND TIMESTAMP < STR_TO_DATE('2019-04-04 00:00:00', '%Y-%m-%d %H:%i:%s') AND TIMESTAMP > DATE_SUB(STR_TO_DATE('2019-04-04 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(CAST(VALUE AS DECIMAL(20,8)))
                  ,MAX(TYPE) AS TYPE,MAX(EVENT) AS EVENT,MAX(UNIT) AS UNIT FROM history WHERE 1=1 AND DEVICE  = 'KS300' AND READING = 'data' AND TIMESTAMP >= STR_TO_DATE('2019-04-04 00:00:00', '%Y-%m-%d %H:%i:%s') AND TIMESTAMP <= STR_TO_DATE('2019-04-05 00:00:00', '%Y-%m-%d %H:%i:%s') GROUP BY DATE_FORMAT(TIMESTAMP, '%Y-%m-%d %H') ORDER BY TIMESTAMP


Abrage mit regex:

Code Auswählen Erweitern

get logdb - ALL 2019-04-04 2019-04-05 KS300:data::delta-h:$val=~s/.*\sR..([\d.]*).*/$1/eg KS300:data::delta-d:$val=~s/.*\sR..([\d.]*).*/$1/eg

Popup:

Code Auswählen Erweitern

Timestamp: Device, Type, Event, Reading, Value, Unit
=====================================================
2019-04-04 00:30:00: KS300, KS300, state: T: 4.9  H: 94  W: 0.0  R: 1410.9  IR: no  Wi: 0, data, 0,
2019-04-04 01:30:00: KS300, KS300, state: T: 4.7  H: 94  W: 0.0  R: 1410.9  IR: no  Wi: 0, data, 0,
2019-04-04 02:30:00: KS300, KS300, state: T: 4.5  H: 94  W: 0.0  R: 1410.9  IR: no  Wi: 0, data, 0,
2019-04-04 03:30:00: KS300, KS300, state: T: 4.4  H: 94  W: 0.0  R: 1410.9  IR: no  Wi: 0, data, 0,
2019-04-04 04:30:00: KS300, KS300, state: T: 4.3  H: 95  W: 0.0  R: 1411.2  IR: yes  Wi: 0, data, 0,  xxx
2019-04-04 05:30:00: KS300, KS300, state: T: 4.3  H: 95  W: 0.0  R: 1411.2  IR: no  Wi: 0, data, 0,
2019-04-04 06:30:00: KS300, KS300, state: T: 4.5  H: 95  W: 0.0  R: 1411.7  IR: no  Wi: 0, data, 0,   xxx
2019-04-04 07:30:00: KS300, KS300, state: T: 4.7  H: 95  W: 0.5  R: 1411.9  IR: yes  Wi: 0, data, 0,  xxx
2019-04-04 08:30:00: KS300, KS300, state: T: 4.3  H: 95  W: 0.8  R: 1411.9  IR: no  Wi: 0, data, 0,
2019-04-04 09:30:00: KS300, KS300, state: T: 3.9  H: 94  W: 0.5  R: 1413.2  IR: no  Wi: 0, data, 0,   xxx
2019-04-04 10:30:00: KS300, KS300, state: T: 4.0  H: 92  W: 1.3  R: 1414.0  IR: no  Wi: 1, data, 0,   xxx
2019-04-04 11:30:00: KS300, KS300, state: T: 5.2  H: 92  W: 0.0  R: 1414.2  IR: no  Wi: 0, data, 0,   xxx
2019-04-04 12:30:00: KS300, KS300, state: T: 5.6  H: 92  W: 0.8  R: 1414.7  IR: no  Wi: 0, data, 0,   xxx
2019-04-04 13:30:00: KS300, KS300, state: T: 6.4  H: 90  W: 0.0  R: 1414.7  IR: no  Wi: 0, data, 0,
2019-04-04 14:30:00: KS300, KS300, state: T: 6.4  H: 92  W: 0.0  R: 1415.0  IR: no  Wi: 0, data, 0,   xxx
2019-04-04 15:30:00: KS300, KS300, state: T: 7.1  H: 91  W: 0.0  R: 1415.5  IR: no  Wi: 0, data, 0,   xxx
2019-04-04 16:30:00: KS300, KS300, state: T: 7.2  H: 92  W: 0.0  R: 1416.0  IR: no  Wi: 0, data, 0,   xxx
2019-04-04 17:30:00: KS300, KS300, state: T: 6.8  H: 91  W: 0.0  R: 1416.0  IR: no  Wi: 0, data, 0,
2019-04-04 18:30:00: KS300, KS300, state: T: 6.6  H: 92  W: 0.0  R: 1416.0  IR: no  Wi: 0, data, 0,
2019-04-04 19:30:00: KS300, KS300, state: T: 6.1  H: 93  W: 0.0  R: 1416.0  IR: no  Wi: 0, data, 0,
2019-04-04 20:30:00: KS300, KS300, state: T: 5.8  H: 94  W: 0.0  R: 1416.3  IR: no  Wi: 0, data, 0,   xxx
2019-04-04 21:30:00: KS300, KS300, state: T: 5.5  H: 94  W: 0.0  R: 1416.3  IR: no  Wi: 0, data, 0,
2019-04-04 22:30:00: KS300, KS300, state: T: 5.2  H: 94  W: 0.0  R: 1416.3  IR: no  Wi: 0, data, 0,
2019-04-04 23:30:00: KS300 KS300 state: T: 5.2  H: 94  W: 0.0  R: 1416.3  IR: no  Wi: 0 data 0
#KS300:data::delta-h:$val=~s/.*\sR..([\d.]*).*/$1/eg
Timestamp: Device, Type, Event, Reading, Value, Unit
=====================================================
2019-04-04 12:00:00: KS300 KS300 state: T: 5.2  H: 94  W: 0.0  R: 1416.3  IR: no  Wi: 0 data 0
#KS300:data::delta-d:$val=~s/.*\sR..([\d.]*).*/$1/eg

Ich habe mal bei jedem delta-h xxx angestellt, wo eigentlich keine 0 sein dürfte.

log:

Code Auswählen Erweitern

2019.04.07 18:07:39 4: Processing Statement: SELECT
                  MAX(DATE_FORMAT(TIMESTAMP, '%Y-%m-%d %H:%i:%s')) AS TIMESTAMP,
                  MAX(DEVICE) AS DEVICE,
                  MAX(READING) AS READING,
                  MAX(CAST(VALUE AS DECIMAL(20,8)))
                  ,MAX(TYPE) AS TYPE,MAX(EVENT) AS EVENT,MAX(UNIT) AS UNIT FROM history WHERE 1=1 AND DEVICE  = 'KS300' AND READING = 'data' AND TIMESTAMP < STR_TO_DATE('2019-04-04 00:00:00', '%Y-%m-%d %H:%i:%s') AND TIMESTAMP > DATE_SUB(STR_TO_DATE('2019-04-04 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(CAST(VALUE AS DECIMAL(20,8)))
                  ,MAX(TYPE) AS TYPE,MAX(EVENT) AS EVENT,MAX(UNIT) AS UNIT FROM history WHERE 1=1 AND DEVICE  = 'KS300' AND READING = 'data' AND TIMESTAMP >= STR_TO_DATE('2019-04-04 00:00:00', '%Y-%m-%d %H:%i:%s') AND TIMESTAMP <= STR_TO_DATE('2019-04-05 00:00:00', '%Y-%m-%d %H:%i:%s') GROUP BY DATE_FORMAT(TIMESTAMP, '%Y-%m-%d %H') ORDER BY TIMESTAMP
2019.04.07 18:07:39 4: Processing Statement: SELECT
                  MAX(DATE_FORMAT(TIMESTAMP, '%Y-%m-%d %H:%i:%s')) AS TIMESTAMP,
                  MAX(DEVICE) AS DEVICE,
                  MAX(READING) AS READING,
                  MAX(CAST(VALUE AS DECIMAL(20,8)))
                  ,MAX(TYPE) AS TYPE,MAX(EVENT) AS EVENT,MAX(UNIT) AS UNIT FROM history WHERE 1=1 AND DEVICE  = 'KS300' AND READING = 'data' AND TIMESTAMP < STR_TO_DATE('2019-04-04 00:00:00', '%Y-%m-%d %H:%i:%s') AND TIMESTAMP > DATE_SUB(STR_TO_DATE('2019-04-04 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(CAST(VALUE AS DECIMAL(20,8)))
                  ,MAX(TYPE) AS TYPE,MAX(EVENT) AS EVENT,MAX(UNIT) AS UNIT FROM history WHERE 1=1 AND DEVICE  = 'KS300' AND READING = 'data' AND TIMESTAMP >= STR_TO_DATE('2019-04-04 00:00:00', '%Y-%m-%d %H:%i:%s') AND TIMESTAMP <= STR_TO_DATE('2019-04-05 00:00:00', '%Y-%m-%d %H:%i:%s') GROUP BY DATE_FORMAT(TIMESTAMP, '%Y-%m-%d %H') ORDER BY TIMESTAMP

Abfrage ohne Delta aber mit regex:

Code Auswählen Erweitern

get logdb - ALL 2019-04-04 2019-04-05 KS300:data:::$val=~s/.*\sR..([\d.]*).*/$1/eg

letzte Zeilen aus Popup:

Code Auswählen Erweitern

2019-04-04 23:54:42: KS300, KS300, state: T: 4.9  H: 94  W: 0.0  R: 1416.3  IR: no  Wi: 0, data, 1416.3,
2019-04-04 23:57:15: KS300, KS300, state: T: 5.1  H: 94  W: 0.0  R: 1416.3  IR: no  Wi: 0, data, 1416.3,
2019-04-04 23:59:47: KS300, KS300, state: T: 4.9  H: 94  W: 0.0  R: 1416.3  IR: no  Wi: 0, data, 1416.3,
#KS300:data:::$val=~s/.*\sR..([\d.]*).*/$1/eg


Meines Erachtens funktioniert das regex, die Gesamtregenmenge wird als Zahl!? geliefert, aber es wird kein Delta gebildet.

Grundsätzlich funktioniert delta-h/d auch bei mir:

Code Auswählen Erweitern

get logdb - ALL 2019-04-06 2019-04-07 Sonoff_Brunnenpumpe:statENERGY_Total_Year::delta-h: Sonoff_Brunnenpumpe:statENERGY_Total_Year::delta-d:

Code Auswählen Erweitern

2019-04-06 20:30:00: Sonoff_Brunnenpumpe, MQTT_DEVICE, statENERGY_Total_Year: 0.806, statENERGY_Total_Year, 0.002,
2019-04-06 21:30:00: Sonoff_Brunnenpumpe, MQTT_DEVICE, statENERGY_Total_Year: 0.809, statENERGY_Total_Year, 0.002,
2019-04-06 22:30:00: Sonoff_Brunnenpumpe, MQTT_DEVICE, statENERGY_Total_Year: 0.811, statENERGY_Total_Year, 0.003,
2019-04-06 23:30:00: Sonoff_Brunnenpumpe MQTT_DEVICE statENERGY_Total_Year: 0.811 statENERGY_Total_Year 0.002
#Sonoff_Brunnenpumpe:statENERGY_Total_Year::delta-h:
Timestamp: Device, Type, Event, Reading, Value, Unit
=====================================================
2019-04-06 12:00:00: Sonoff_Brunnenpumpe MQTT_DEVICE statENERGY_Total_Year: 0.811 statENERGY_Total_Year 0.057
#Sonoff_Brunnenpumpe:statENERGY_Total_Year::delta-d:

Liegt es wirklich am regex, oder ist es wieder eine Besonderheit wg. des KS300  state<>data?


Gruß
Bernd

[DS_Starter]

Hi Bernd,

Frage: warum fragst du denn "data" ab ? Die Regenmenge steht doch im Reading "state". Also müsste m.M. nach funktionieren:

Code Auswählen Erweitern

get logdb - ALL 2019-04-04 2019-04-05 KS300:state::delta-h:$val=~s/.*\sR..([\d.]*).*/$1/eg KS300:state::delta-d:$val=~s/.*\sR..([\d.]*).*/$1/eg


Dann sollte auch das Regex passen.

[frober]

Hallo Axel,


ich habe im DbLog valueFn gesetzt

Code Auswählen Erweitern

{if ($DEVICE eq "KS300" && $READING eq "data" && $EVENT=~/^[avg]/) {$READING="average"} else {$VALUE=(split("state: ",$VALUE,2))[1]}}

state funktioniert nicht, habe gerade alles durchprobiert.

Die Daten werden zwar als state geloggt, aber als Reading data abgelegt (Siehe Rohdaten).

Code Auswählen Erweitern


Timestamp: Device, Type, Event, Reading, Value, Unit
=====================================================
2019-04-04 00:01:07: KS300, KS300, state: T: 5.1  H: 94  W: 0.0  R: 1410.7  IR: no  Wi: 0, data, T: 5.1  H: 94  W: 0.0  R: 1410.7  IR: no  Wi: 0,
2019-04-04 00:06:12: KS300, KS300, state: T: 5.1  H: 94  W: 0.0  R: 1410.7  IR: no  Wi: 0, data, T: 5.1  H: 94  W: 0.0  R: 1410.7  IR: no  Wi: 0,
...
2019-04-04 23:57:15: KS300, KS300, state: T: 5.1  H: 94  W: 0.0  R: 1416.3  IR: no  Wi: 0, data, T: 5.1  H: 94  W: 0.0  R: 1416.3  IR: no  Wi: 0,
2019-04-04 23:59:47: KS300, KS300, state: T: 4.9  H: 94  W: 0.0  R: 1416.3  IR: no  Wi: 0, data, T: 4.9  H: 94  W: 0.0  R: 1416.3  IR: no  Wi: 0,
#KS300:data:::


Das hatte einen bestimmten Grund, der mir aktuell nicht mehr einfällt.
Auf jeden Fall, wollte ich das state loggen, um evtl. meine Filelog-Daten migrieren zu können.
Wenn alles nicht hilft, stelle ich alles auf die einzelnen Readings um, dann sollte es auf jeden Fall wieder funktionieren.

[DS_Starter]

Alles ?

Hast du auch mal das Attribut  addStateEvent = "0" bzw. "1" gesetzt ?

Grüße Heiko ... who is Axel ? 

[DS_Starter]

Ich sollte besser lesen 

Die valueFn ist nicht korrekt denke ich. Du willst doch das state Reading loggen bzw. das state Reading anpassen wenn es geloggt wird:

Code Auswählen Erweitern

{if ($DEVICE eq "KS300" && $READING eq "state" && $EVENT=~/^[avg]/) {$READING="average"} else {$VALUE=(split("state: ",$VALUE,2))[1]}}


[frober]

Hallo Heiko,

und sorry für Axel, war nicht bei der Sache schäm

Das valueFn stimmt schon, dabei hast du mir geholfen
siehe https://forum.fhem.de/index.php/topic,83066.msg753286.html#msg753286

Die KS300 bringt kein state, sondern data. Um das zu loggen, habe ich auch bei der KS300 DbLogInclude:data.

Darum habe ich data gelassen (selbst geschrieben am 13.02.18):

Ich habe nun "data" gelassen, weil es mich nicht stört und ich meine, ich hätte in einem älteren Post gelesen, dass in DbLog, die Mittelwertbildung beim KS300 etwas anders berechnet wird als bei anderen Devices (falls dies immer noch so ist?).

addStateEvent ist bei mir nicht gesetzt

Gruß Bernd

[DS_Starter]

Oh je ... schon ein Jahr her 
In dem Thread steht ja auch dass wir schon mal rausbekommen haben welche Sonderbehandlung KS300 vornimmt. Das wußte ich nicht mehr.   Dann passt deine valueFn.

Wenn du magst kannst du mir ja von einem Tag diese DAten exportieren (mit DbRep) und senden. Dann könnte ich sie bei mir importieren und wir kommen vielelicht weiter.

LG,
Heiko

[DS_Starter]

Du könntest noch versuchen die valueFn so abzuändern:

Code Auswählen Erweitern

{if ($DEVICE eq "KS300" && $READING eq "data" && $EVENT=~/^[avg]/) {$READING="average"} else {$VALUE=~s/.*R:\s+(\d+.\d+).*/$1/eg}

Dann würde data nur die Regenwerte als Zahl enthalten. Vielleicht ist das in diesem Fall hilfreich.

Grüße,
Heiko

[frober]

Du könntest noch versuchen die valueFn so abzuändern:

Code Auswählen Erweitern

{if ($DEVICE eq "KS300" && $READING eq "data" && $EVENT=~/^[avg]/) {$READING="average"} else {$VALUE=~s/.*R:\s+(\d+.\d+).*/$1/eg}

Dann würde data nur die Regenwerte als Zahl enthalten. Vielleicht ist das in diesem Fall hilfreich.

Dein Vorschlag in Ehren, es gibt alle Werte als Einzelreadings, die ich loggen kann.
Wie erwähnt wollte ich evtl. die alten Filelog-Daten migrieren.

Was mich wundert, genau meine Definition hat bis vor einigen Wochen problemlos funktioniert.

Anbei der Export meiner KS300-Daten.

Ich habe noch ein kleines Problem, wie matche ich per regex Umlaute auf 0|1?
Letztes Jahr wurden plötzlich vom Luxtronik-Device nicht mehr ae sondern ä geliefert.
Ich habe es mit set utf8, ascii-Code usw. probiert. Aktuell mache ich dies so:

Code Auswählen Erweitern

#logProxy DbLog:logdb,extend=2000:Heizung:opStateHeatPump1:::$val=~s/(W.*rmepumpe|Abtauen).(l.*uft|steht)(\d*).*/$1eq"Abtauen"?0:($2ne"steht"?1:0)/eg
#logProxy DbLog:logdb,extend=2000:Heizung:opStateHeatPump1:::$val=~s/(W.*rmepumpe|Abtauen)(\d*).*/$1eq"Abtauen"?1:0/eg
Funktioniert, bringt aber Meldungen im Log.

Gruß Bernd

[DS_Starter]

Hallo Bernd,

danke für die Daten, schaue ich mir an.

Ich habe noch ein kleines Problem, wie matche ich per regex Umlaute auf 0|1?
Letztes Jahr wurden plötzlich vom Luxtronik-Device nicht mehr ae sondern ä geliefert.
Ich habe es mit set utf8, ascii-Code usw. probiert.

Dafür kannst du das Attribut useCharfilter = 1 benutzen. Damit werden Umlaute in ae, ue usw. umgesetzt und du kannst dein bisheriges Regex nutzen.

Was mich wundert, genau meine Definition hat bis vor einigen Wochen problemlos funktioniert.

Das kann ich auch nicht nachvollziehen.
Du kannst gerne mal die angehängte Version vom November letzten Jahres probieren. Nach dem Download umbenennen und FHEM restarten.

[frober]

Hallo Heiko,

danke, ich werde morgen Mal die alte Version testen.

Schönen Abend noch.

[DS_Starter]

dito !

LG

[frober]

Hallo Heiko,

viele Tests, aber erfolgreich , zumindest was die "Fehlerursache" betrifft.

Deine alte Version hat nichts gebracht
Ich habe mein Testsystem, zum Glück noch mit SQLite benutzt. Die Daten des KS300 migriert und auf neuesten Stand gebracht, wobei Stand 01/18 auch schon funktionierte.

Die Definitionen kopiert und siehe da:

Code Auswählen Erweitern

Timestamp: Device, Type, Event, Reading, Value, Unit
=====================================================
2019-04-09 00:30:00: KS300, KS300, state: T: 7.2  H: 92  W: 0.0  R: 1416.3  IR: no  Wi: 0, data, 0, 
2019-04-09 01:30:00: KS300, KS300, state: T: 7.0  H: 93  W: 0.0  R: 1416.3  IR: no  Wi: 0, data, 0, 
2019-04-09 02:30:00: KS300, KS300, state: T: 6.2  H: 93  W: 0.0  R: 1416.3  IR: no  Wi: 0, data, 0, 
2019-04-09 03:30:00: KS300, KS300, state: T: 6.5  H: 94  W: 0.0  R: 1416.3  IR: no  Wi: 0, data, 0, 
2019-04-09 04:30:00: KS300, KS300, state: T: 6.5  H: 94  W: 0.0  R: 1416.3  IR: no  Wi: 0, data, 0, 
2019-04-09 05:30:00: KS300, KS300, state: T: 6.4  H: 94  W: 0.0  R: 1416.3  IR: no  Wi: 0, data, 0, 
2019-04-09 06:30:00: KS300, KS300, state: T: 7.0  H: 94  W: 0.0  R: 1416.3  IR: no  Wi: 0, data, 0, 
2019-04-09 07:30:00: KS300, KS300, state: T: 9.2  H: 93  W: 0.0  R: 1416.3  IR: no  Wi: 0, data, 0, 
2019-04-09 08:30:00: KS300, KS300, state: T: 9.8  H: 91  W: 0.0  R: 1416.3  IR: no  Wi: 0, data, 0, 
2019-04-09 09:30:00: KS300, KS300, state: T: 12.3  H: 82  W: 0.0  R: 1416.3  IR: no  Wi: 0, data, 0, 
2019-04-09 10:30:00: KS300, KS300, state: T: 13.1  H: 81  W: 0.0  R: 1416.3  IR: no  Wi: 0, data, 0, 
2019-04-09 11:30:00: KS300, KS300, state: T: 14.7  H: 72  W: 0.0  R: 1416.3  IR: no  Wi: 0, data, 0, 
2019-04-09 12:30:00: KS300, KS300, state: T: 15.3  H: 68  W: 1.1  R: 1416.3  IR: no  Wi: 1, data, 0, 
2019-04-09 13:30:00: KS300, KS300, state: T: 16.0  H: 64  W: 0.0  R: 1416.3  IR: no  Wi: 0, data, 0, 
2019-04-09 14:30:00: KS300, KS300, state: T: 16.6  H: 62  W: 0.0  R: 1416.3  IR: no  Wi: 0, data, 0, 
2019-04-09 15:30:00: KS300, KS300, state: T: 16.2  H: 65  W: 0.0  R: 1416.3  IR: no  Wi: 0, data, 0, 
2019-04-09 16:30:00: KS300, KS300, state: T: 12.4  H: 85  W: 0.0  R: 1417.0  IR: yes  Wi: 0, data, 0, 
2019-04-09 17:30:00: KS300, KS300, state: T: 12.8  H: 90  W: 0.0  R: 1417.0  IR: no  Wi: 0, data, 0.7, 
2019-04-09 18:30:00: KS300, KS300, state: T: 12.8  H: 90  W: 0.0  R: 1417.0  IR: no  Wi: 0, data, 0, 
2019-04-09 19:30:00: KS300 KS300 state: T: 12.8  H: 90  W: 0.0  R: 1417.0  IR: no  Wi: 0 data 0 
#KS300:data::delta-h:$val=~s/.*\sR..([\d.]*).*/$1/eg
Timestamp: Device, Type, Event, Reading, Value, Unit
=====================================================
2019-04-09 12:00:00: KS300 KS300 state: T: 12.8  H: 90  W: 0.0  R: 1417.0  IR: no  Wi: 0 data 0.7 
#KS300:data::delta-d:$val=~s/.*\sR..([\d.]*).*/$1/eg


Dann war es doch die Umstellung von SQLite auf MySQL...

Siehst du hier eine Korrekturmöglichkeit, oder muß ich die Einzelreadings loggen?

Gruß Bernd

P.S.  Das Attribut useCharfilter = 1 wandelt es die Daten zum loggen um, oder funktioniert es auch beim Abrufen der alten Daten?

[DS_Starter]

Hallo Bernd,

na das ist ja ein Ding.
Dann muss ich erstmal herausbekommen worin der Unterschied bei der Behandlung durch beide DB-Typen besteht. Denn die get-Funktion ist für alle DB's identisch. Einzig die Generierung der SQLs berücksichtigt DB Spezifika. Dann muss es dieses Problem eigentlich schon immer geben, allerding fällt es wahrscheinlich nur auf wenn man eine solche Konstellation wie du benutzt.
Ich habe ja deine Daten. Vielleicht gelingt es mir damit. Dauert aber etwas, das wird nicht so leicht zu finden sein ...

Das Attribut useCharfilter = 1 wandelt es die Daten zum loggen um, oder funktioniert es auch beim Abrufen der alten Daten?

Nein, es betrifft nur neu geloggte Daten. Altdaten werden nicht beeinflusst.

Güße,
Heiko

[frober]

Hallo Heiko,

schon mal Danke für deine Mühe, falls ich helfen kann....

Meine Daten musst du etwas modifizieren, der Startwert vom Vortag fehlt. Aktuell wird  mit 0 gerechnet.
Kann dir die Daten aber auch nochmal exportieren.

[DS_Starter]

Kann dir die Daten aber auch nochmal exportieren.

Ja, dann mach das mal bitte. Je identischere Daten ich habe, desto besser.

LG

[frober]

So, habe die Daten nochmal exportiert.

[DS_Starter]

Danke, melde mich wenn ich etwas bewegen konnte.

Grüße,
Heiko

[DS_Starter]

Hallo Bernd,

ich konnte das Problem identifizieren und lösen.
Den Download dieser Version mit der Bitte um Test findest du hier:

https://forum.fhem.de/index.php/topic,65860.msg929642.html#msg929642

Grüße
Heiko

[frober]

Hallo Heiko,

das ging ja flott, wow.

Funktioniert, die Deltas werden wieder angezeigt.

Ich stelle diesen Thread auf gelöst.

Gruß und danke
Bernd

[DS_Starter]

Moin Bernd,

prima
Mit dem Einchecken warte ich noch ein bisschen. Ich möchte eventuelle Meldungen anderer User noch abwarten.
Vermutlich gibt es keine unerwünschten Nebenwirkungen, aber es wäre mir lieb es kämen noch ein paar Rückmeldungen.
Ansonsten mache ich das in den nächsten Tagen.
Falls dir noch was auffallen sollte, kannst du gerne in dem anderen Thread antworten.

Schönes WE,
Heiko

[frober]

Mache ich und dito.

[frober]

Hallo Heiko,

zu dem hier gelösten Problem ist mir noch eine Kleinigkeit aufgefallen.

Das Regengesamtmenge (delta-d) wird am nächsten Tag um 0:30 als delta-h ausgewiesen (siehe Screenshots).
Soweit ich es nach vollziehen konnten, ist nur die Regenmenge ab ca. 12 Uhr des Vortages betroffen.

Die Regenmenge des Vortags wird dadurch bei der Regengesamtmenge das aktuellen Tages mit angezeigt.

Vielleicht kannst du das noch korrigieren.

Die Logdaten und mein Gplot-File habe ich mit angehängt.

Gruß und danke Bernd

[DS_Starter]

Hallo Bernd,

bin mir unsicher ob ich da direkt im DbLog etwas machen kann.
Mach mal bitte einen Auszug mit verbose 4 im DbLog wenn du das SVG aufrufst.
Und dazu auch noch ein "Preprocessed Input" aus dem SVG-Editor.

Grüße,
Heiko

[frober]

Hallo Heiko,

ich habe dir die Daten als File angehängt.

Wenn du noch mehr Infos brauchst....

Gruß Bernd

[DS_Starter]

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 Erweitern

"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]

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.

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]

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

[frober]

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 Erweitern

#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 Erweitern

#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]

Hallo Bernd,

Gplot 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]

Kein Problem, teste gerne..

[DS_Starter]

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.

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]

Mein log sieht genauso aus:

2019.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:

"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",""

"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]

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]

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

Ich habe nochmal auf 'rain' gematcht:

2019.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':

2019.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.

"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]

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]

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]

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

[DS_Starter]

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.

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 ...

[frober]

Ok, dann nochmals danke für deine Mühe.

Schönen Abend noch.

[DS_Starter]

Ich habe noch einen Lösungsansatz gefunden.
Falls du DbRep im Einsatz hast und dieses Statement im scqlCmd ausführst:

Code Auswählen Erweitern


SELECT Z.TIMESTAMP, Z.DEVICE, Z.READING, Z.VALUE from
                  (SELECT DATE_FORMAT(TIMESTAMP, '%Y-%m-%d %H:%i:%s') AS TIMESTAMP,
                  DEVICE AS DEVICE,
                  READING AS READING,
                  VALUE AS 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) 
                   
ORDER BY TIMESTAMP DESC LIMIT 1 ) AS Z                   
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


klappt das sowohl für Reading "data" als auch für "rain".
Muss mal schauen ob das in der Form einbaubar ist.
Würde mich freuen wenn du das Statement bei dir mit verschiedenen Readingvariablen testen könntest.

Grüße,
Heiko

[frober]

Hallo Heiko,
natürlich werde ich es testen, kann leider nur sagen, ob es am WE klappt.

Grüsse Bernd

[frober]

Hallo Heiko,

ich habe 'data' und 'rain' getestet und 'data' mit verschiedenen Zeiträumen, in denen der Plot die "Fehlanzeige" hat.
Des weiteren habe ich eine Std. früher angefangen, alles am Vortag um 23:00.

Die Daten sehen TOP aus:

Code Auswählen Erweitern

SELECT Z.TIMESTAMP, Z.DEVICE, Z.READING, Z.VALUE from
                  (SELECT DATE_FORMAT(TIMESTAMP, '%Y-%m-%d %H:%i:%s') AS TIMESTAMP,
                  DEVICE AS DEVICE,
                  READING AS READING,
                  VALUE AS VALUE
                  FROM history WHERE 1=1 AND DEVICE  = 'KS300' AND READING = 'data' AND TIMESTAMP < STR_TO_DATE('2019-09-24 23:00:00', '%Y-%m-%d %H:%i:%s') AND TIMESTAMP > DATE_SUB(STR_TO_DATE('2019-09-24 23:00:00', '%Y-%m-%d %H:%i:%s'),INTERVAL 1 DAY) 
                   
ORDER BY TIMESTAMP DESC LIMIT 1 ) AS Z                   
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-24 23: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


Um 23:45 steht nun die richtige Regengesamtmenge:

SqlResultRow_01

2019-09-24 23:45:11|KS300|data|T: 14.2 H: 92 W: 0.0 R: 1666.9 IR: no Wi: 0

2019-10-06 17:49:40


SqlResultRow_02

2019-09-25 00:58:54|KS300|data|T: 14.2 H: 92 W: 0.0 R: 1666.9 IR: no Wi: 0

2019-10-06 17:49:40


SqlResultRow_03

2019-09-25 01:54:49|KS300|data|T: 14.4 H: 92 W: 0.0 R: 1666.9 IR: no Wi: 0

2019-10-06 17:49:40


SqlResultRow_04

2019-09-25 02:53:17|KS300|data|T: 14.5 H: 92 W: 0.0 R: 1666.9 IR: no Wi: 0

Zum Verständnis für mich, da mir der SQL-Befehlssatz nicht geläufig ist:
Von jeder Std wird der letzte, also höchste, Timestamp und dazu der höchste Wert (String) aus dieser Std. angezeigt.
D.h. Timestamp und value gehören eigentlich nicht zusammen, sind aber aus der gleichen Std.

Wenn das so ist, dann passt alles. 

Danke und Gruß
Bernd

[DS_Starter]

Hallo Bernd,

hört sich gut an. 
Der Subselect in der Klammer am Angang liefert dem eigentlichen Select eine Tabelle "Z" die aus einem Datensatz besteht, nämlich den letzten der Vorperiode (INTERVAL 1 Day = - Tag des vorher angegebenen Datums).
Das wird dann mit dem nächsten Select gemergt (UNION ALL) um die Grundlage für Berechnung der Deltas zu haben.

Nun muss ich das Konstrukt im DbLog einbauen ohne ungewünschte Nebenwirkungen hervorzurufen.
Wenn ich das gemacht habe und der Meinung bin dass es richtig arbeitet, werde ich die neue DbLog-Version in dem
DbLog Optimierungsthread (https://forum.fhem.de/index.php/topic,65860.0.html) veröffentlichen.

Ich bitte dich dann, und natürlich auch alle anderen User, möglichst intensiv die SVG-Erstellung zu testen.
Die Änderung der SQL-Statements hat ja eine fundamentale Auswirkung. 

Danke dir !

LG,
Heiko

[frober]

Auch nochmals danke dir.
Den Thread lese ich eh mit....

Schönen Sonntag noch.

Bernd