Buderus KM200 Kommunikationsmodul

cortmen · 28 Dezember 2022, 19:14:12

*Update
https://forum.fhem.de/index.php?topic=130588.msg1254046#msg1254046

Tach zusammen, eigentlich arbeite ich schon seit vielen Jahren mit
gplot- SVG Funktionen und einer MySQL Datenbank

Es gab ja vor ein paar Tagen ein "update" vom DbLog, aber eigentlich wurden dier grundsätzlichen Features nicht verändert.
Trotzdem bringt mich dblog und km200 so langsam ans "Ende" mit dem loggen.

Mit dem Filelog ist alles keine AKtion, passt und fertig..
Aber nicht das schreiben mit dblog in die Datenbank.

Ich habe hier fast den gesamten Thread gefiltert auf dem dblog, es gibt wohl nicht viele, die mit dblog in die DB schreiben.

Ich versuche mal das grundsätzliche Problem zu beschreiben.
Wichtig ist das ich in der "def" des DbLog bereits nach Devices und Readings filter.

Code Auswählen

/opt/fhem/db.conf .*:(cpu_temp.*|loadavg|temperature|humidity|measured-temp|desired-temp|actuator|rain|water|generalPurpose).*

Sobald ich in der def ( \/heatSources\/returnTemperature | .... | ....| ).* klappt noch alles im gplot und die Werte werden in die DB geschrieben
Kommt ein weiterer Eintrag in der def hinzu (\/heatSources\/returnTemperature | \/system\/sensors\/temperatures\/hotWater_t2|.....|...| ).*

ob mit Entwertung \/ oder ohne, kein Unterschied

Ist "feierabend", Error im modul dblog:

Code Auswählen

DBD::mysql::st execute failed: Data too long for column 'READING' at row 3 [for Statement "INSERT INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES )

Wenn ich die Readings direkt am Device eintrage werden diese ignoriert, es wird nichts in die DB geschrieben.

Deshalb die Frage, wer hat dblog mit den Filtern in der def des Moduls dblog gesetzt und es läuft?

DS_Starter · 28 Dezember 2022, 19:34:44

Nabend,

in der Meldung steht der Grund drin:

Zitat
...Data too long for column 'READING' at row...

D.h. die Spalte in der DB ist zu klein um die Länge des Readings aufzunehmen. Das ist Datenbanktechnik.
Aber es gibt Abhilfe.

Das einfachste ist das INTERNAL COLUMNS -> Readings anzuschauen. Es sollte Reading: 64 sein. Wenn es kleiner ist, benutzt du noch das ganz alte Datenbankschema.

Zwei Möglichkeiten:

1. die schnelle : setze das Attr colReading auf den angezeigten Wert des Internals
2. die bessere: rufe configCheck auf. In der Rubrik "Result of table 'fhemtest1.history' check" findest du eine Statement zur Anpassung der Spalte wenn der Check die Diskrepanz erkennt.

LG,
Heiko

cortmen · 28 Dezember 2022, 19:38:33

Hier kurz die Werte der Felder

Code Auswählen

Result of table 'history' check

Column width set in DB history: 'DEVICE' = 32, 'TYPE' = 32, 'EVENT' = 64, 'READING' = 32, 'VALUE' = 128, 'UNIT' = 32
Column width used by mydblog: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Recommendation: The relation between column width in table history and the field width used in device mydblog don't meet the requirements. Please make sure that the width of database field definition is equal or larger than the field width used by the module. Compare the given results.
Currently the default values for field width are:

DEVICE: 64
TYPE: 64
EVENT: 512
READING: 64
VALUE: 128
UNIT: 32

You can change the column width in database by a statement like 'alter table history modify VALUE varchar(128);' (example for changing field 'VALUE'). You can do it for example by executing 'sqlCmd' in DbRep or in a SQL-Editor of your choice. (switch mydblog to asynchron mode for non-blocking).
Alternatively the field width used by mydblog can be adjusted by setting attributes 'colEvent', 'colReading', 'colValue'. (pls. refer to commandref)

Result of table 'current' check

Column width set in DB current: 'DEVICE' = 32, 'TYPE' = 32, 'EVENT' = 64, 'READING' = 32, 'VALUE' = 32, 'UNIT' = 32
Column width used by mydblog: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Recommendation: The relation between column width in table current and the field width used in device mydblog don't meet the requirements. Please make sure that the width of database field definition is equal or larger than the field width used by the module. Compare the given results.
Currently the default values for field width are:

DEVICE: 64
TYPE: 64
EVENT: 512
READING: 64
VALUE: 128
UNIT: 32

Code Auswählen

Internals
COLUMNS
field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
CONFIGURATION
/opt/fhem/db.conf
DEF	
/opt/fhem/db.conf .*:(cpu_temp.*|loadavg|temperature|humidity|measured-temp|desired-temp|actuator|rain|water|generalPurpose).*
FD
6
FUUID
5c42f490-f33f-0190-c0a4-728cba991e1b1687
FVERSION
93_DbLog.pm:v5.5.8-s26907/2022-12-27

DS_Starter · 28 Dezember 2022, 19:55:48

Ja, du siehst es hier -> 'READING' = 32 d.h. altes Schema und zu kurz für dein langes Reading.

Entweder anpassen der Spalte mit

Code Auswählen


 alter table history modify READING varchar(64);

für eine "richtige" Lösung oder das Attr benutzen.

Das Statement kannst du im DbRep sqlCmd oder einem SQL-Tool deiner Wahl ausführen.

cortmen · 28 Dezember 2022, 19:56:53

@DS_Starter

thx angepasst

Result of table 'history' check

Column width set in DB history: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Column width used by mydblog: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Recommendation: settings o.k.

thburkhart · 28 Dezember 2022, 20:00:31

@cortmen
auch ich hatte diese Schwierigkeiten, wie man den Beiträgen wenig zuvor entnehmen kann.

Es hat definitiv nichts mit der neuen dbLog-Version 5.5.7, die ich mit testen durfte.
Vielmehr sind die langen Buderus-readings etwas bockig in der DEF

bei meinen Versuchen muss es in der DEF wohl so aussehen:

Code Auswählen

\/buderus:heatSources\/systemPressure|
also noch ein "Buderus" davor

Ich lese in der DBLOG deshalb wieder alles

Code Auswählen

./configDB.conf .*:.*

ungeliebte Readings habe ich dem Rat von egerd folgend auf non polling gesetzt.

dblog include/exclude habe ich noch umsetzt, da dies bei meinen vielen TUYA-Devices in JEDEM Device separat gesetzt werden muss.
Ein dblog include/exclude kann wohl nicht als globales Attribut für alle TUYA oder LaCrosse-Devices gesetzt werden; so zumindest mein Laienkentnisstand.

Die Tuyas sins dabei mit sekündlichen Readings sehr, sehr gesprächig.

Mein Workaround ist ein nächtliches reducelog

Code Auswählen

[code]define DbLog_reduce at *01:40:00 { fhem("set dblog_THB reducelognbl 1 average") }
attr DbLog_reduce alias DbLog_reducelog 1   1:40
attr DbLog_reduce disable 0
attr DbLog_reduce room DBLog,xTimer
#   COMMAND    { fhem("set dblog_THB reducelognbl 1 average") }
#   DEF        *01:40:00 { fhem("set dblog_THB reducelognbl 1 average") }
#   FUUID      5f887572-f33f-21fb-21ea-721ebd4df32ab567
#   NAME       DbLog_reduce
#   NR         1265
#   PERIODIC   yes
#   RELATIVE   no
#   REP        -1
#   STATE      Next: 01:40:00
#   TIMESPEC   01:40:00
#   TRIGGERTIME 1672274400
#   TRIGGERTIME_FMT 2022-12-29 01:40:00
#   TYPE       at
#   READINGS:
#     2022-12-28 08:50:06   state           Next: 01:40:00
#
setstate DbLog_reduce Next: 01:40:00
setstate DbLog_reduce 2022-12-28 08:50:06 state Next: 01:40:00

[/code]

das läuft in der neuen Version deutlich schneller und entfernt ca. 1 Mio redundante Einträge.

Somit liegt die event filterung über das Attribut wie sowas bei meinen LacrosseDevices

Code Auswählen

attr TX29DTH_05 event-on-change-reading battery
attr TX29DTH_05 event-on-update-reading humidity,state,temperature

für meine 60 Tuya-Devices noch vor mir

Vielleicht weiß auch jemand, wie das global geht

DS_Starter · 28 Dezember 2022, 20:02:48

Sehr gut.

Nur so nebenbei ... nach diesem Verfahren kann man sich auch größere Spalten anlegen wenn man es braucht.
Sind sie größer als der Standard, dann muß man auch die Attr benutzen um dem Modul zu sagen es soll breitere Werte
verarbeiten.
Ich habe zum Beispiel eine Spezial-Db mit einer Breite für Value = 2000. Dort speichere ich empfangene Message des 93_Log2Syslog Moduls.

thburkhart · 28 Dezember 2022, 20:04:08

Zitat von: cortmen am 28 Dezember 2022, 19:56:53
@DS_Starter

thx angepasst

Column width set in DB history: 'DEVICE' = 32, 'TYPE' = 32, 'EVENT' = 64, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Column width used by mydblog: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32

DS_Starter war schneller...

@cortmen könntest DU deine dbDEF bezgl. Buderus mal posten?

cortmen · 28 Dezember 2022, 20:04:22

@thburkhart

Danke für diese Tipps, also versuche ich es jetzt mit längeren DB Feldern und Deinen Tipps
gerne noch einmal..

thburkhart · 28 Dezember 2022, 20:11:18

@DS-Starter

du hast sicher einen Tipp bezüglich der DEVICE / TYPE-globalen event.....-Attribute.

denn meine DB ist wieder angeschwollen:

Code Auswählen

[code]define dblog_THB DbLog ./configDB.conf .*:.*
attr dblog_THB DbLogType Current/History
attr dblog_THB alias dblog_THB
attr dblog_THB asyncMode 1
attr dblog_THB bulkInsert 1
attr dblog_THB cacheLimit 5000
attr dblog_THB comment ./configDB.conf .*:(state|temperature|power|humidity|va_temperature|va_humidity|humidity_value|desiredTemperature|valveposition|\\
\/buderus:heatSources\/systemPressure|CHpumpModulation|actualDHWPower|actualCHPower|flameStatus|\\
applianceSupplyTemperature|actualSupplyTemperature|supplyTemperatureSetpoint|outdoor_t1|supply_t1|supply_t1_setpoint|\\
actualTemp|currentSetpoint|charge|chargeDuration|setpoint|singleChargeSetpoint|workingTime|oilfox_metering_liters).*
attr dblog_THB commitMode ac:on_ta:off
attr dblog_THB room DBLog
attr dblog_THB syncInterval 30
attr dblog_THB useCharfilter 1
attr dblog_THB verbose 1
#   COLUMNS    field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32 
#   CONFIGURATION ./configDB.conf
#   DEF        ./configDB.conf .*:.*
#   FD         5
#   FUUID      63a33b3f-f33f-fd5f-7f81-5787629cdd49cde5
#   FVERSION   93_DbLog.pm:v5.5.3-s26750/2022-12-10
#   MODE       asynchronous
#   MODEL      MYSQL
#   NAME       dblog_THB
#   NR         2
#   NTFY_ORDER 50-dblog_THB
#   PID        7703
#   REGEXP     .*:.*
#   SBP_PID    7704
#   SBP_STATE  running
#   STATE      connected
#   TYPE       DbLog
#   UTF8       0
#   dbconn     mysql:database=fhem;host=localhost;port=3306
#   dbuser     fhemuser
#   eventCount 1377
#   HELPER:
#     COLSET     1
#     DEVICECOL  64
#     EVENTCOL   512
#     LONGRUN_PID 1672254837.9287
#     OLDSTATE   connected
#     PACKAGE    main
#     READINGCOL 64
#     TC         current
#     TH         history
#     TYPECOL    64
#     UNITCOL    32
#     VALUECOL   128
#     VERSION    5.5.3
#   Helper:
#     DBLOG:
#       CacheOverflowLastNum:
#         dblog_THB:
#           TIME       1672254837.91322
#           VALUE      0
#       countCurrent:
#         dblog_THB:
#           TIME       1672254813.90109
#           VALUE      7322
#       countHistory:
#         dblog_THB:
#           TIME       1672254813.90109
#           VALUE      3644445
#       state:
#         dblog_THB:
#           TIME       1672254813.90717
#           VALUE      connected
#   OLDREADINGS:
#   READINGS:
#     2022-12-28 20:13:57   CacheOverflowLastNum 0
#     2022-12-27 18:40:35   CacheOverflowLastState normal
#     2022-12-28 20:14:18   CacheUsage      446
#     2022-12-28 20:13:57   NextSync        2022-12-28 20:14:27 or when CacheUsage 5000 is reached
#     2022-12-28 20:13:33   countCurrent    7322
#     2022-12-28 20:13:33   countHistory    3644445
#     2022-12-28 20:13:57   state           connected
#
setstate dblog_THB connected
setstate dblog_THB 2022-12-28 20:13:57 CacheOverflowLastNum 0
setstate dblog_THB 2022-12-27 18:40:35 CacheOverflowLastState normal
setstate dblog_THB 2022-12-28 20:14:18 CacheUsage 446
setstate dblog_THB 2022-12-28 20:13:57 NextSync 2022-12-28 20:14:27 or when CacheUsage 5000 is reached
setstate dblog_THB 2022-12-28 20:13:33 countCurrent 7322
setstate dblog_THB 2022-12-28 20:13:33 countHistory 3644445
setstate dblog_THB 2022-12-28 20:13:57 state connected

[/code]

thburkhart · 28 Dezember 2022, 20:18:08

kann das DBlog reduce auch ein log schreiben?

DS_Starter · 28 Dezember 2022, 21:15:23

Zitat
kann das DBlog reduce auch ein log schreiben?

Ja, mit verbose 3 oder höher.
Ich empfehle aber das reduceLog im DbRep. Hat mehr Möglichkeiten und wird dort auch weiter gepflegt.

Sailor · 29 Dezember 2022, 17:08:22

Hallo zusammen.

Das ist hier das Forum für den km200.

Ich denke Eure Probleme sind im DbLog - Bereich besser aufgehoben.
Am besten die Beiträge verschieben.

Danke

Sailor

zyklop · 04 Januar 2023, 09:14:52

Zitat von: Sailor am 29 Dezember 2022, 17:08:22
Hallo zusammen.

Das ist hier das Forum für den km200.

Ich denke Eure Probleme sind im DbLog - Bereich besser aufgehoben.
Am besten die Beiträge verschieben.

Danke

Sailor

Danke, kann einer einen Shop für das KM200 empfehlen? tu mir schwer was zu finden

thburkhart · 04 Januar 2023, 13:20:45

Zitat von: Sailor am 29 Dezember 2022, 17:08:22
Hallo zusammen.

Das ist hier das Forum für den km200.

Ich denke Eure Probleme sind im DbLog - Bereich besser aufgehoben.
Am besten die Beiträge verschieben.

Danke

Sailor

die Probleme sind wegen der readings schon KM200 spezifisch.
Ich habe nur wegen diese die db auf *.:*. von expliziert Angabe umstellen müssen.

@cortmen Ich wäre dankbar für deine DEF mit expliziten Angabe ; wenn dir das überhaupt gelungen ist

herzlichen Dank

Thomas