Problem/Fehler DBRep maxValue deleteOther mit Postgres

Begonnen von casoe, 04 Juli 2023, 23:16:07

Vorheriges Thema - Nächstes Thema

casoe

Hallo zusammen,

ich probiere schon den ganzen Abend herum und komme nicht weiter. Ich habe seit ein paar Tagen ein Balkonkraftwerk, dass über einen Shelly in FHEM eingebunden ist. Das funktioniert soweit ganz gut.

Jetzt möchte ich die Datenlast in der Postgres-Datenbank reduzieren und mit DBRep nicht benötigte Einträge löschen.

Es geht um folgendes DBRep-Device:

Internals:
   DATABASE   fhem
   DEF        dblog
   FUUID      64a466d9-f33f-b657-5779-1043bb79c96170fd
   FVERSION   93_DbRep.pm:v8.52.8-s27720/2023-07-02
   LASTCMD    maxValue display
   MODEL      Client
   NAME       dbrep_bkw
   NOTIFYDEV  global,dbrep_bkw
   NR         70
   NTFY_ORDER 50-dbrep_bkw
   ROLE       Client
   STATE      done
   TYPE       DbRep
   UTF8       1
   eventCount 52
   HELPER:
     DBLOGDEVICE dblog
     IDRETRIES  2
     MINTS      2017-05-19 21:25:59
     PACKAGE    main
     VERSION    8.52.8
     CV:
       aggregation day
       aggsec     86400
       destr      2023-07-03
       dsstr      2023-06-30
       epoch_seconds_end 1688421599
       mestr      07
       msstr      06
       testr      23:59:59
       tsstr      00:00:00
       wdadd      259200
       yestr      2023
       ysstr      2023
     DBREPCOL:
       COLSET     1
       DEVICE     64
       EVENT      512
       READING    64
       TYPE       64
       UNIT       32
       VALUE      128
   OLDREADINGS:
   READINGS:
     2023-07-04 22:59:23   2023-06-30_23-59-03__MQTT2_DVES_9BFAF4__statTotal_kwh_genDay__MAX__2023-06-30 0.2400
     2023-07-04 22:59:23   2023-07-01_23-59-02__MQTT2_DVES_9BFAF4__statTotal_kwh_genDay__MAX__2023-07-01 3.1866
     2023-07-04 22:59:23   2023-07-02_23-59-01__MQTT2_DVES_9BFAF4__statTotal_kwh_genDay__MAX__2023-07-02 3.8868
     2023-07-04 22:59:23   2023-07-03_23-58-59__MQTT2_DVES_9BFAF4__statTotal_kwh_genDay__MAX__2023-07-03 3.8686
     2023-07-04 22:59:23   state           done
Attributes:
   aggregation day
   allowDeletion 1
   device     MQTT2_DVES_9BFAF4
   reading    statTotal_kwh_genDay
   timestamp_begin 2023-06-30 00:00:00
   timestamp_end previous_day_end

Das Auslösen von maxValue deleteOther führt zu folgender Fehlermeldung:

DBD::Pg::st execute failed: ERROR:  column "2023-06-30 23:59:03" does not exist
LINE 1: ...IMESTAMP < '2023-07-01' AND (TIMESTAMP,VALUE) != ("2023-06-3...
                                                             ^ at ./FHEM/93_DbRep.pm line 11630.

Ich kürze an der Stelle mal ab, weil ich nach dem Stellen auf verbose 5 das resultierende SQL-Statement sehe:

delete FROM history where ( DEVICE = 'MQTT2_DVES_9BFAF4' ) AND ( READING = 'statTotal_kwh_genDay' ) AND TIMESTAMP >= '2023-06-30 00:00:00' AND TIMESTAMP < '2023-07-01' AND (TIMESTAMP,VALUE) != ("2023-06-30 23:59:03","0.240039045752022");
Für Postgres muss das aus meiner Sicht das folgende Statement sein:
delete FROM history where ( DEVICE = 'MQTT2_DVES_9BFAF4' ) AND ( READING = 'statTotal_kwh_genDay' ) AND TIMESTAMP >= '2023-06-30 00:00:00' AND TIMESTAMP < '2023-07-01' AND (TIMESTAMP,VALUE) != ('2023-06-30 23:59:03','0.240039045752022');
Also einfaches Anführungszeichen statt des doppelten. Damit klappt es dann auch direkt auf der Datenbank.

Ich kann nur vermuten, dass das ein Fehler in DBRep für Postgres ist. Stimmt das? Kann das jemand korrigieren?

Beste Grüße
Carsten

DS_Starter

Hallo Carsten,

das schaue ich mir morgen mal an. Postgres ist nicht unbedingt meine Domäne. Da kann es durchaus sein dass sich ein SQL-Fehler eingeschlichen hat.

Grüße,
Heiko
ESXi 6.5 @NUC6i5SYH+FHEM auf Debian, DbLog/DbRep MariaDB
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 habe das Problem gefixt und eingecheckt. Die neue V wird morgen früh im Update enthalten sein.
Wenn du heute schon vorab testen möchtest, kannst du dir diese Version gerne auch aus meinem contrib (siehe Fußtext) laden und FHEM restarten.

Grüße,
Heiko
ESXi 6.5 @NUC6i5SYH+FHEM auf Debian, DbLog/DbRep MariaDB
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

casoe

Cool, ich teste das mal heute Abend. Bei minValue war meiner Erinnerung nach das gleiche Problem. Bin mir nicht sicher, wie generisch das ist.

Danke dir!

Beste Grüße
Carsten

casoe

Ich hab grad kurz in den Code geschaut und das scheint für beide genutzt zu werden. Ich teste auf jeden Fall maxValue und minValue.

casoe

Hab gerade maxValue und minValue getestet. Funktioniert wie erwartet. Well done!

casoe

Ich glaube, ich hab das nächste Problem gefunden. Wenn ich "aggregation hour" setze, kommt ebenfalls eine Fehlermeldung. Das Device sieht so aus:

defmod dbrep_zahler_maxValueGasHour DbRep dblog
attr dbrep_zahler_maxValueGasHour aggregation hour
attr dbrep_zahler_maxValueGasHour allowDeletion 1
attr dbrep_zahler_maxValueGasHour device MQTT2_gasmeter
attr dbrep_zahler_maxValueGasHour reading value
attr dbrep_zahler_maxValueGasHour room System->Postgres
attr dbrep_zahler_maxValueGasHour timestamp_begin 2022-11-09 00:00:00
attr dbrep_zahler_maxValueGasHour timestamp_end previous_day_end
attr dbrep_zahler_maxValueGasHour verbose 5

Schon beim Auslösen der Anzeige kommt eine Fehlermeldung:
2023.07.09 13:44:03.516 5: DbRep dbrep_zahler_maxValueGasHour - Devices for operation -
included (1): MQTT2_gasmeter
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.07.09 13:44:03.516 5: DbRep dbrep_zahler_maxValueGasHour - Readings for operation -
included (1): value
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.07.09 13:44:03.516 4: DbRep dbrep_zahler_maxValueGasHour - SQL execute: SELECT VALUE,TIMESTAMP FROM history where ( DEVICE = 'MQTT2_gasmeter' ) AND ( READING = 'value' ) AND TIMESTAMP >= '2022-11-09 00:00:00' AND TIMESTAMP < '2022-11-09 01' ORDER BY TIMESTAMP;
2023.07.09 13:44:03.517 2: DbRep dbrep_zahler_maxValueGasHour - ERROR - DBD::Pg::st execute failed: ERROR:  invalid input syntax for type timestamp: "2022-11-09 01"
LINE 1: ...IMESTAMP >= '2022-11-09 00:00:00' AND TIMESTAMP < '2022-11-0...
                                                             ^ at ./FHEM/93_DbRep.pm line 11631.

2023.07.09 13:44:03.518 1: PERL WARNING: Use of uninitialized value in subroutine entry at ./FHEM/93_DbRep.pm line 4214.
2023.07.09 13:44:03.518 3: eval: {DbRep_maxvalDone('dbrep_zahler_maxValueGasHour|REJEOjpQZzo6c3QgZXhlY3V0ZSBmYWlsZWQ6IEVSUk9SOiAgaW52YWxpZCBpbnB1dCBzeW50YXggZm9yIHR5cGUgdGltZXN0YW1wOiAiMjAyMi0xMS0wOSAwMSIKTElORSAxOiAuLi5JTUVTVEFNUCA+PSAnMjAyMi0xMS0wOSAwMDowMDowMCcgQU5EIFRJTUVTVEFNUCA8ICcyMDIyLTExLTAuLi4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIF4gYXQgLi9GSEVNLzkzX0RiUmVwLnBtIGxpbmUgMTE2MzEuCg==')}
2023.07.09 13:44:03.518 1: PERL WARNING: Use of uninitialized value in subroutine entry at ./FHEM/93_DbRep.pm line 4215.
2023.07.09 13:44:03.518 3: eval: {DbRep_maxvalDone('dbrep_zahler_maxValueGasHour|REJEOjpQZzo6c3QgZXhlY3V0ZSBmYWlsZWQ6IEVSUk9SOiAgaW52YWxpZCBpbnB1dCBzeW50YXggZm9yIHR5cGUgdGltZXN0YW1wOiAiMjAyMi0xMS0wOSAwMSIKTElORSAxOiAuLi5JTUVTVEFNUCA+PSAnMjAyMi0xMS0wOSAwMDowMDowMCcgQU5EIFRJTUVTVEFNUCA8ICcyMDIyLTExLTAuLi4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIF4gYXQgLi9GSEVNLzkzX0RiUmVwLnBtIGxpbmUgMTE2MzEuCg==')}
2023.07.09 13:44:03.518 5: DbRep dbrep_zahler_maxValueGasHour - BlockingCall PID "11478" finished

Anscheinend wird der Zeitstempel nicht richtig gebaut. Das gleiche DbRep-Device mit "aggregation day" klappt ohne Probleme.

Kannst du dir das noch mal ansehen?

Beste Grüße
Carsten

DS_Starter

Hallo Carsten,

der String zur Abgrenzung des Timestamp war so gewollt und funktioniert auch für MySQL, SQLite.
Postgre mag es offensichtlich nicht und ich habe die Syntax für Postgre angepasst.

Die gefixte V liegt in meinem contrib für dich zum Test bereit.

Grüße.
Heiko
ESXi 6.5 @NUC6i5SYH+FHEM auf Debian, DbLog/DbRep MariaDB
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

casoe

"set maxValue display" klappt jetzt. Allerdings kommt bei "set maxValue deleteOther" immer noch eine Fehlermeldung.

Die sieht so aus:

2023.07.09 21:16:32.967 5: DbRep dbrep_zahler_minValueGasHour - Devices for operation -
included (1): MQTT2_gasmeter
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.07.09 21:16:32.967 5: DbRep dbrep_zahler_minValueGasHour - Readings for operation -
included (1): value
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.07.09 21:16:32.968 4: DbRep dbrep_zahler_minValueGasHour - SQL execute: delete FROM history where ( DEVICE = 'MQTT2_gasmeter' ) AND ( READING = 'value' ) AND TIMESTAMP >= '2022-11-17 20:00:00' AND TIMESTAMP < '2022-11-17 21' AND (TIMESTAMP,VALUE) != ('2022-11-17 20:57:55','16985.44');
2023.07.09 21:16:32.968 2: DbRep dbrep_zahler_minValueGasHour - ERROR - DBD::Pg::st execute failed: ERROR:  invalid input syntax for type timestamp: "2022-11-17 21"
LINE 1: ...IMESTAMP >= '2022-11-17 20:00:00' AND TIMESTAMP < '2022-11-1...
                                                             ^ at ./FHEM/93_DbRep.pm line 11640.

2023.07.09 21:16:32.975 5: DbRep dbrep_zahler_minValueGasHour - BlockingCall PID "13493" finished

Bei minValue passiert das Gleiche.

Beste Grüße
Carsten

DS_Starter

Das hätte mir natürlich gleich auffallen müssen.
Fix liegt im contrib. Nochmal bitte ...
ESXi 6.5 @NUC6i5SYH+FHEM auf Debian, DbLog/DbRep MariaDB
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

casoe

Hab es gestern Abend schon mal angetestet und es scheint schon gut zu sein. Würde heute Abend noch mal einen strukturierten Test machen wollen.

Beste Grüße
Carsten

DS_Starter

Hallo Carsten,

habe festgestellt einen Fehler eingebaut zu haben, der an anderer Stelle einen SQL-Fehler verursacht.
Das habe ich nochmal reviewed und den Fix in mein contrib geladen.

Grüße,
Heiko
ESXi 6.5 @NUC6i5SYH+FHEM auf Debian, DbLog/DbRep MariaDB
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

casoe

Okidoki. Hab eingehend getestet und es sieht - zumindest bei mir - gut aus. Also noch mal: Well done!

Beste Grüße
Carsten

DS_Starter

Danke für die Rückinfo Carsten ... ist eingecheckt.
ESXi 6.5 @NUC6i5SYH+FHEM auf Debian, DbLog/DbRep MariaDB
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