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
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
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
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
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.
Hab gerade maxValue und minValue getestet. Funktioniert wie erwartet. Well done!
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
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
"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
Das hätte mir natürlich gleich auffallen müssen.
Fix liegt im contrib. Nochmal bitte ...
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
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
Okidoki. Hab eingehend getestet und es sieht - zumindest bei mir - gut aus. Also noch mal: Well done!
Beste Grüße
Carsten
Danke für die Rückinfo Carsten ... ist eingecheckt.