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

Begonnen von frober, 03 April 2019, 11:31:20

Vorheriges Thema - Nächstes Thema

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

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

#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.
Raspi 3b mit Raspbian Buster und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

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
Raspi 3b mit Raspbian Buster und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

DS_Starter

Hallo Bernd,

sorry, deine Anfrage hatte ich übersehen.

ZitatGab 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

ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

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


Raspi 3b mit Raspbian Buster und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

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?
Raspi 3b mit Raspbian Buster und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

DS_Starter

#5
Hallo Bernd,

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

ZitatDie 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:


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.

Zitat
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
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

frober

Hallo Heiko,

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

Mit deiner Abfrage: 
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:
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:
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:
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:
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:
get logdb - ALL 2019-04-04 2019-04-05 KS300:data:::$val=~s/.*\sR..([\d.]*).*/$1/eg

letzte Zeilen aus Popup:
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:
get logdb - ALL 2019-04-06 2019-04-07 Sonoff_Brunnenpumpe:statENERGY_Total_Year::delta-h: Sonoff_Brunnenpumpe:statENERGY_Total_Year::delta-d:

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



Raspi 3b mit Raspbian Buster und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

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:

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.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

frober

Hallo Axel,


ich habe im DbLog valueFn gesetzt
{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).

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.



Raspi 3b mit Raspbian Buster und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

DS_Starter

#9
Alles ?

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

Grüße Heiko ... who is Axel ?  :D
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

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:

{if ($DEVICE eq "KS300" && $READING eq "state" && $EVENT=~/^[avg]/) {$READING="average"} else {$VALUE=(split("state: ",$VALUE,2))[1]}}
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

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):
ZitatIch 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
Raspi 3b mit Raspbian Buster und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

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. :o  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
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

DS_Starter

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

{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
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

frober

Zitat von: DS_Starter am 07 April 2019, 23:03:35
Du könntest noch versuchen die valueFn so abzuändern:

{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:
#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
Raspi 3b mit Raspbian Buster und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...