Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)

[DS_Starter]

Hallo Andreas,

das ist ein Datenbankmechanismus der recht gut hier erklärt ist: https://karbachinsky.medium.com/deadlock-found-when-trying-to-get-lock-try-restarting-transaction-54a3ed118068

Führe mal bitte im DbRep aus:

Code Auswählen Erweitern

set ... sqlCmd SHOW ENGINE INNODB STATUS;

Es kommt eine größere Ausgabe. Interessant ist dieser Block

------------------------
LATEST DETECTED DEADLOCK
------------------------
2023-12-20 09:14:22 7f9d830cf700
*** (1) TRANSACTION:
TRANSACTION 243789459, ACTIVE 149 sec inserting
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 1184, 2 row lock(s), undo log entries 1
MySQL thread id 7266603, OS thread handle 0x7f9d0a32d700, query id 639594931 fhem.myds.me 192.168.2.46 fhemshort update
REPLACE INTO current (TIMESTAMP, TYPE, EVENT, VALUE, UNIT, DEVICE, READING) VALUES ('2023-12-20 09:11:27','FULLY','','1',NULL,'googlenexus.fully','powerstate')
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 547 page no 8 n bits 240 index `PRIMARY` of table `fhemshort`.`current` trx table locks 1 total table locks 3  trx id 243789459 lock_mode X locks rec but not gap waiting lock hold time 47 wait time before grant 0
*** (2) TRANSACTION:
TRANSACTION 243789414, ACTIVE 168 sec inserting
mysql tables in use 2, locked 2
114855 lock struct(s), heap size 14759464, 21983074 row lock(s), undo log entries 834
MySQL thread id 7270446, OS thread handle 0x7f9d830cf700, query id 639592831 fhem.myds.me 192.168.2.46 fhemshort Sending data
INSERT IGNORE INTO current (TIMESTAMP,DEVICE,READING) SELECT timestamp,device,reading FROM history where 1 group by timestamp,device,reading
*** (2) HOLDS THE LOCK(S)

Vllt. erkennen wir anhand der Statements die beteiligten Prozesse. Könnte auch ein paralleler DbLog Schreibvorgang beteiligt sein.

Grüße,
Heiko

[flummy1978]

Hallo Heiko,

vielen Dank für die Antwort. Ich bin grad erst von der Arbeit rein und hab das mal ausgeführt. (Verbose 5 Log aus der Aufführung ist ebenfalls vorhanden). Leider verstehe ich aber aus der Ausgabe gar nichts. Vielleicht ja Du

(Inhalt als Txt Anhang, weil es zu einem Fehlermeldung der Forumssoftware führt, wenn ich versuche das zu posten )
log.txt

Vllt. erkennen wir anhand der Statements die beteiligten Prozesse. Könnte auch ein paralleler DbLog Schreibvorgang beteiligt sein.

In Anbetracht dessen was ich in dem oben erwähntem Link bisher gelesen habe und Deinem Hinweis mit dem entsprechendem Schreibvorgang, könntest es natürlich sehrwohl genau das Problem sein. Die Betroffenen Devices erhalten sehr sehr viele Infos von der Wetterstation - Dafür eben auch der Vorgang alle 15 Min um die Daten nochmehr zu schrumpfen als anhand von event Beschränkungen innerhabl von Fhem. Beispiel:

Code Auswählen Erweitern

define DBrep_Wetter_humidity DbRep DBLogging
attr DBrep_Wetter_humidity DbLogExclude .*
attr DBrep_Wetter_humidity alias 04 Schnitt Luftfeuchte errechnen
attr DBrep_Wetter_humidity allowDeletion 1
attr DBrep_Wetter_humidity device Wetterstation
attr DBrep_Wetter_humidity event-on-change-reading .*
attr DBrep_Wetter_humidity executeAfterProc set DBrep_Wetter_temperature averageValue writeToDBInTime
attr DBrep_Wetter_humidity group Automatische DB Bereinigung
attr DBrep_Wetter_humidity icon own-log@darkgrey
attr DBrep_Wetter_humidity reading humidity
attr DBrep_Wetter_humidity room System->Datenbank
attr DBrep_Wetter_humidity sortby 14
attr DBrep_Wetter_humidity timeDiffToNow m:15
attr DBrep_Wetter_humidity timeOlderThan m:0
attr DBrep_Wetter_humidity verbose 2
#   DATABASE   fhem_DB_LIVE
#   DEF        DBLogging
#   FUUID      649cad56-f33f-6adc-6608-1d3b22cbba8a36f0
#   FVERSION   93_DbRep.pm:v8.53.0-s28370/2024-01-10
#   LASTCMD    averageValue writeToDBInTime
#   MODEL      Client
#   NAME       DBrep_Wetter_humidity
#   NOTIFYDEV  global,DBrep_Wetter_humidity
#   NR         327
#   NTFY_ORDER 50-DBrep_Wetter_humidity
#   ROLE       Client
#   STATE      done
#   TYPE       DbRep
#   UTF8       1
#   eventCount 1817
#   HELPER:
#     DBLOGDEVICE DBLogging
#     GRANTS     SHOW DATABASES,SELECT,EXECUTE,CREATE ROUTINE,PROCESS,ALTER ROUTINE,DELETE,CREATE,EVENT,UPDATE,REPLICATION SLAVE,SHUTDOWN,TRIGGER,INSERT,CREATE USER,SHOW VIEW,CREATE VIEW,DROP,RELOAD,INDEX,CREATE TEMPORARY TABLES,REPLICATION CLIENT,REFERENCES,LOCK TABLES,FILE,ALTER
#     IDRETRIES  2
#     MINTS      2022-07-01 00:00:22
#     PACKAGE    main
#     VERSION    8.53.0
#     CV:
#       aggregation no
#       aggsec     1
#       destr      2024-01-25
#       dsstr      2024-01-25
#       epoch_seconds_end 1706219705.23661
#       mestr      01
#       msstr      01
#       testr      22:55:05
#       tsstr      22:40:05
#       wdadd      345600
#       yestr      2024
#       ysstr      2024
#     DBREPCOL:
#       COLSET     1
#       DEVICE     64
#       EVENT      512
#       READING    64
#       TYPE       64
#       UNIT       32
#       VALUE      128
#   OLDREADINGS:
#   READINGS:
#     2024-01-25 22:55:06   2024-01-25__Wetterstation__humidity__AVGAM__no_aggregation -
#     2024-01-25 22:55:06   db_lines_processed 0
#     2024-01-25 22:55:06   state           done
#
setstate DBrep_Wetter_humidity done
setstate DBrep_Wetter_humidity 2024-01-23 22:31:21 .associatedWith Wetterstation
setstate DBrep_Wetter_humidity 2024-01-25 22:55:06 2024-01-25__Wetterstation__humidity__AVGAM__no_aggregation -
setstate DBrep_Wetter_humidity 2024-01-25 22:55:06 db_lines_processed 0
setstate DBrep_Wetter_humidity 2024-01-25 22:55:06 state done


Dieses Device reduziert bsw. die Einträge von humidity - genau wie die anderen Einträge ist es aber auf 0:15 Min beschränkt:
timeDiffToNow  m:15
timeOlderThan m:0

Kann es sein, dass eben genau diese 0 BIS 15 Min zu meinem Problem führen könnte? Was auf dieser Grafik verdeutlicht wurde:
https://miro.medium.com/v2/resize:fit:4800/format:webp/1*fSJWI00jPKHdmj7XqG-m1A.png
 

Mein Ansatz wäre als erstes mal die Devices auf
timeDiffToNow  m:30
timeOlderThan m:15
zu ändern und die Daten erst später zu löschen -könnte das vielleicht schon helfen? (Ich würd gern Deine Meinung dazu hören, bevor ich die ganzen notifys / Devices etc ändere     

VG
Andreas

[DS_Starter]

Moin,

soweit ich sehen kann, hält wahrscheinlich DbLog einen Lock (INSERT IGNORE INTO history...):

Code Auswählen Erweitern

*** (2) TRANSACTION: TRANSACTION 15412754, ACTIVE 1 sec inserting mysql tables in use 1, locked 1 729 lock struct(s),
heap size 90232, 121823 row lock(s), undo log entries 2 MySQL thread id 10195,
OS thread handle 139778776536832, query id 390546 192.168.0.24 fhempi_user
Update INSERT IGNORE INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES ('2024-01-25 18:10:07','Hauptzaehler','ELECTRICITYCALCULATOR','calculated','avgam_no_wemos_current_lang','13.7727',NULL)
*** (2) HOLDS THE LOCK(S):

Die Attribute

Code Auswählen Erweitern

timeDiffToNow  m:30
timeOlderThan m:15

sind vermutlich tatsächlich besser.
Unterstützend kannst du im DbRep das DbLog Device temporär von der DB trennen:

Code Auswählen Erweitern

attr ... executeBeforeProc set DBLogging reopen 60
Die Zeit (60 Sekunden) sollten halt länger sein wie DbRep für seine Aktion benötigt.
DbLog speichert die Event-Daten zwischen und vergisst nichts.

[flummy1978]

Moinsen,

vielen herzlichen Dank für deinen schnellen Lösungsvorschlag. Hab allerdings noch ein paar kleine Fragen dazu:

soweit ich sehen kann, hält wahrscheinlich DbLog einen Lock (INSERT IGNORE INTO history...):

1. Zeiten anpassen: Ich habs befürchtet, aber dann weiss ich was ich jetzt zu tun hab  Hat es einen Grund warum diese Zeiten dann noch besser sind oder einfach wie mein "einfacher" Gedanke war um damit außerhalb der aktuellen Zeit und Tabellenbereich zu sein?

2. Unterstützend...: Ich habe einige devices, die eine solche Aufgabe erfüllen, wenn ich das im ersten Ausführe, und sobald die Zeit für die nachfolgendenn Ausführungen reich, wird es auch ausgeführt?

3. Ergänzend dazu noch: Ich habe wie gesagt mehrere solche Devices. Es ist natürlich ultraclever alle zur gleichen Zeit ausführen zu lassen. Da ich aber an sowas nicht gedacht hab und die Sachen nach und nach gewachsen sind..... Lange Rede kurzer Sinn:

Code Auswählen Erweitern

at_DBrep_3DDrucker_POWER_15Min              Next: 12:25:03
at_DBrep_Wetter_wind_lumi_15Min             Next: 12:25:01
at_DBrep_dev_GH_solar_15Min                 Next: 12:25:06
at_DBrep_zaehler_wemos_current_lang_15Min   Next: 12:25:08

+*00:15 set DBrep_3Ddrucker_ENERGY_Power averageValue writeToDBInTime
Das sind die at-devices die jeweils die Bearbeitung auslösen. Alle nach dem Muster definiert. Gibt es einen Trick / Möglichkeit sie verzögert ausführen zu lassen, oder werden sie es eh automatisch (die Zeiten unterscheiden sich ja bereits um je 1-2 sek)

Alternativ bliebe mir lediglich das Ganze so umzubauen, dass es nur noch ein Einziges at device gibt, das dann das erste auslöst und alle anderen werden mit "executeafterproc" eingebunden. Das wollte ich gern vermeiden, weil ich jetzt "Gruppen" habe. Am oberen Beispiel (3D Drucker):

at löst aus -> 50 Schnitt 3D Drucker ENERGY_Power -> executeAfterProc -> 51 Schnitt 3D Drucker ENERGY_Current -> executeAfterProc -> 52 Schnitt 3D Drucker Power5min -> executeAfterProc ->  53 Schnitt 3D Drucker alte Werte löschen -> done.
Würde diese Ordnung "ungern" verlieren - Gibt es Performance die dagegen sprechen, dann natürlich sofort.

VG
Andreas

[DS_Starter]

Hat es einen Grund warum diese Zeiten dann noch besser sind oder einfach wie mein "einfacher" Gedanke war um damit außerhalb der aktuellen Zeit und Tabellenbereich zu sein?

Bei diesen Zeitabgrenzungen werden die aktuellsten Datensätze nicht berüchsichtigt und können mit DbLog nicht in Konflikt geraten, so die Überlegung.

2. Unterstützend...: Ich habe einige devices, die eine solche Aufgabe erfüllen, wenn ich das im ersten Ausführe, und sobald die Zeit für die nachfolgendenn Ausführungen reich, wird es auch ausgeführt?

Es reicht die DbLog "Sperre" im ersten Device zu veranlassen. Das reopen passiert dann nach Ablauf der angegebenen Sekunden.

Das sind die at-devices die jeweils die Bearbeitung auslösen. Alle nach dem Muster definiert. Gibt es einen Trick / Möglichkeit sie verzögert ausführen zu lassen, oder werden sie es eh automatisch (die Zeiten unterscheiden sich ja bereits um je 1-2 sek)

Der Zeitversatz ist damit schon gegeben.
Bei so wenig Zeitversatz kann aber schon passieren dass einige Dinge parallel laufen, auch im Hinblick auf BlockingCall. Ich würde das mehr auseinanderziehen. Vllt. gefällt dir auch das neue Kommando "multiCmd". Schau es dir mal an.

at löst aus -> 50 Schnitt 3D Drucker ENERGY_Power -> executeAfterProc -> 51 Schnitt 3D Drucker ENERGY_Current -> executeAfterProc -> 52 Schnitt 3D Drucker Power5min -> executeAfterProc ->  53 Schnitt 3D Drucker alte Werte löschen -> done.
Würde diese Ordnung "ungern" verlieren - Gibt es Performance die dagegen sprechen, dann natürlich sofort.

Auch unter diesem Gesichtspunkt ist "multiCmd" wahrscheinlich hilfreich.

Alles in Allem muß meine Analyse nicht in jedem Falle zutreffen. Bevor du große Umbauten vornimmst, gehe langsam voran, starte z.B. mit dem executeBeforeProc und beobachte den Erfolg.
Danach Stück für Stück wie beschrieben.

[flummy1978]

Auch unter diesem Gesichtspunkt ist "multiCmd" wahrscheinlich hilfreich.
Alles in Allem muß meine Analyse nicht in jedem Falle zutreffen. Bevor du große Umbauten vornimmst, gehe langsam voran, starte z.B. mit dem executeBeforeProc und beobachte den Erfolg.
Danach Stück für Stück wie beschrieben.

Perfekt - ich danke Dir vielmals für die Aufklärung. Ich stell mal in das set DBLogging reopen 60 in das erste Device und schau mal wie sich die Log Einträge verändern. In der Zwischenzeit werde ich mir das multiCmd mal anschauen - auch mit der Beführchtung es nicht zu verstehen  
Edit muss mal nachwerfen: So schwer scheint es gar nicht zu verstehen zu sein Ich glaube das ist ein sehr sehr mächtiger Befehl - gerade für solche / meine Zwecke

Ich werde in jedem Fall berichten, was wo zu welchem Erfolg geführt hat (dauert aber ggf ein paar Tage) falls ich mehr umbauen muss, oder die "Analyse" länger dauert.

Vielen Dank nochmal
und VG
Andreas

[jnewton957]

Hallo,
ich habe eine Frage zum Anhängen von Datenbankwerten an eine bestehende Datenbank (sqlite3 gem. wiki)

Nach unendlicher Arbeit ist es mir gelungen eine defekte fhem.db quasi wieder zum Leben zu erwecken. Zwischenzeitlich habe ich mit Start 11/2022 eine neue fhem.db.

ich habe mit DB Browser nun verschiedene sql per device erstellt bzw. könnte sicherlich auch eine sql exportieren.

Wie kann ich nun disjunkte historische Werte 2019-2022 in diese DB für einzelne devices nachtragen. Insbesondere Stromstatistikwerte wären für mich interessant.

Da ich nicht (erneut) Fehler mit der fhem.db machen möchte (eigenes try & error), bitte ich um Hilfe für dieses todo

Danke

[DS_Starter]

Das Wichtigste bei allen Manipulationen ist immer! ein vorhandenes gültiges Backup der Datenbank!
Für SQLite hat Dbrep dafür den Befehl:

Code Auswählen Erweitern

set <DbRep> dumpSQLite

Man kann natürlich auch FHEM stoppen und das File fhem.db mit Betriebssystem Werkzeugen sichern.
Weiterhin ist es ratsam DbLog für die Zeit des Importes zu pausieren. Dafür hat DbLog den Befehl:

Code Auswählen Erweitern

set <DbLog> reopen xxxxxx

Du könntest also so vorgehen:

1. set <DbLog> reopen xxxxxx um die DB für die Zeit xxxxx zu isolieren
2. erstelle ein Backup mit set <DbRep> dumpSQLite
3. importiere deine Daten (mit DbRep oder separaten SQL's)

Wenn alles funktioniert hat, öffne DbLog wieder mit einem simplen "set <DbLog> reopen".
Bei Problemen restore die DB wieder mit "set <DbRep> restoreSQLite" und öffne danach DbLog wieder.

Mit dieser Prozedur solltest du auf der sicheren Seite sein.

[rolizer]

Hallo,
ich hab eine Frage zum Fehlerhandling von multiCmd. Erstmal vielen Dank Heiko für den immensen Aufwand und Zeit die du in das Tool steckst. Unglaublich, was mittlerweile alles möglich ist.

Ich hab ein multiCmd zum testen auf einer neuen FHEM gebaut, um nicht wieder mit einer 7GB großen Datenbank voller Datenschrott zu enden. Dabei fällt mir auf, wenn ein Step im cmdHash zum Fehler führt, werden die nächsten nicht weiter ausgeführt. Ist das gewollt?

Code Auswählen Erweitern

{\
my $cmdhash = "{\
      1  => { cmd            => 'sqlCmd select count(*) from history'\
            },\
      2  => { timeOlderThan  => 'd:5',\
                timeDiffToNow  => 'd:7',\
                cmd              => 'reduceLog average'\
            },\
      3  => { timeOlderThan  => 'd:90',\
                timeDiffToNow  => 'd:91',\
                cmd              => 'reduceLog average=day'\
            },\
      4  => { timeOlderThan  => 'd:360',\
              device          => 'sysmon%,global',\
              cmd            => 'delEntries'\
            },\
      5  => { cmd            => 'sqlCmd select count(*) from history'\
            },\
    }";;\
fhem ("set DBRep.multiCmd.reduceLog multiCmd $cmdhash");;\
}führt zu (letzte 3 Zeilen):

Code Auswählen Erweitern

2024.03.01 01:00:00 3: DbRep DBRep.multiCmd.reduceLog - get initial structure information of database "fhem", remaining attempts: 3
2024.03.01 01:00:00 3: DbRep DBRep.multiCmd.reduceLog - Connectiontest to database mysql:database=fhem;host=localhost;port=3308 with user fhemuser
2024.03.01 01:00:00 3: DbRep DBRep.multiCmd.reduceLog - Index Report_Idx exists. Check ok
2024.03.01 01:00:00 3: DbRep DBRep.multiCmd.reduceLog - Initial data information retrieved - total time used: 0.0186 seconds
2024.03.01 01:00:00 3: DbRep DBRep.multiCmd.reduceLog - Connectiontest to db mysql:database=fhem;host=localhost;port=3308 successful
2024.03.01 01:00:00 3: DbRep DBRep.multiCmd.reduceLog - execute command before sqlCmd: 'set LogDB reopen 3600'
2024.03.01 01:00:00 2: LogDB - Connection closed until 02:00:00 (3600 seconds).
2024.03.01 01:00:00 3: DbRep DBRep.multiCmd.reduceLog - execute command after sqlCmd: 'set LogDB reopen'
2024.03.01 01:00:00 3: LogDB - Reopen requested
2024.03.01 01:00:00 2: DbRep DBRep.multiCmd.reduceLog - command message after sqlCmd: >Reopen executed.<
2024.03.01 01:00:00 3: DbRep DBRep.multiCmd.reduceLog - ################################################################
2024.03.01 01:00:00 3: DbRep DBRep.multiCmd.reduceLog - ###                    new reduceLog run                    ###
2024.03.01 01:00:00 3: DbRep DBRep.multiCmd.reduceLog - ################################################################
2024.03.01 01:00:00 3: DbRep DBRep.multiCmd.reduceLog - execute command before reduceLog: 'set LogDB reopen 3600'
2024.03.01 01:00:00 2: LogDB - Connection closed until 02:00:00 (3600 seconds).
2024.03.01 01:00:00 3: LogDB - Database disconnected by request.
2024.03.01 01:00:00 3: LogDB - Database disconnected by request.
2024.03.01 01:00:00 3: LogDB - SubProcess connected to fhem
2024.03.01 01:00:00 3: DbRep DBRep.multiCmd.reduceLog - reduce data older than: 2024-02-25 00:59:59, newer than: 2024-02-23 00:59:59
2024.03.01 01:00:00 3: DbRep DBRep.multiCmd.reduceLog - reduceLog requested with options:
average
INCLUDE -> Devs: % Readings: %
2024.03.01 01:00:00 3: LogDB - Database disconnected by request.
2024.03.01 01:00:00 3: DbRep DBRep.multiCmd.reduceLog - reduceLog deleting 5606 records of day: 2024-02-24
2024.03.01 01:00:01 3: DbRep DBRep.multiCmd.reduceLog - reduceLog deletion progress of day: 2024-02-24 is: 1000
2024.03.01 01:00:02 3: DbRep DBRep.multiCmd.reduceLog - reduceLog deletion progress of day: 2024-02-24 is: 2000
2024.03.01 01:00:03 3: DbRep DBRep.multiCmd.reduceLog - reduceLog deletion progress of day: 2024-02-24 is: 3000
2024.03.01 01:00:03 3: DbRep DBRep.multiCmd.reduceLog - reduceLog deletion progress of day: 2024-02-24 is: 4000
2024.03.01 01:00:04 3: DbRep DBRep.multiCmd.reduceLog - reduceLog deletion progress of day: 2024-02-24 is: 5000
2024.03.01 01:00:05 3: DbRep DBRep.multiCmd.reduceLog - reduceLog (hourly-average) updating 131 records of day: 2024-02-24
2024.03.01 01:00:05 3: DbRep DBRep.multiCmd.reduceLog - reduceLog (hourly-average) updating progress of day: 2024-02-24 is: 100
2024.03.01 01:00:05 3: DbRep DBRep.multiCmd.reduceLog - reduceLog deleting 244 records of day: 2024-02-25
2024.03.01 01:00:05 3: DbRep DBRep.multiCmd.reduceLog - reduceLog deletion progress of day: 2024-02-25 is: 100
2024.03.01 01:00:05 3: DbRep DBRep.multiCmd.reduceLog - reduceLog deletion progress of day: 2024-02-25 is: 200
2024.03.01 01:00:05 3: DbRep DBRep.multiCmd.reduceLog - reduceLog (hourly-average) updating 5 records of day: 2024-02-25
2024.03.01 01:00:05 3: DbRep DBRep.multiCmd.reduceLog - reduceLog finished. Rows processed: 6264, deleted: 5850, updated: 136
2024.03.01 01:00:05 3: DbRep DBRep.multiCmd.reduceLog - execute command after reduceLog: 'set LogDB reopen'
2024.03.01 01:00:05 3: LogDB - Reopen requested
2024.03.01 01:00:05 2: DbRep DBRep.multiCmd.reduceLog - command message after reduceLog: >Reopen executed.<
2024.03.01 01:00:05 3: DbRep DBRep.multiCmd.reduceLog - ################################################################
2024.03.01 01:00:05 3: DbRep DBRep.multiCmd.reduceLog - ###                    new reduceLog run                    ###
2024.03.01 01:00:05 3: DbRep DBRep.multiCmd.reduceLog - ################################################################
2024.03.01 01:00:05 2: DbRep DBRep.multiCmd.reduceLog - ERROR - The Timestamp of the oldest dataset (1706029700) is newer than specified end time (1701471599)
2024.03.01 01:00:06 3: LogDB - Database disconnected by request.
2024.03.01 01:00:06 3: LogDB - SubProcess connected to fhem
Step 4 bricht ab, weil er keine älteren Daten findet, aber der Step 5 wird nicht mehr ausgeführt.
Vielen Dank
Oli

[DS_Starter]

Hallo Oli,

also explizit gewollt/eingebaut ist das nicht. Möglicherweise habe ich einen Rücksprung bei Abbruch übersehen.
Ich schaue mir das vllt. am WE schonmal an und melde mich wieder.

Grüße,
Heiko

[DS_Starter]

Hallo Oli,

ich habe das Problem gefunden und gefixt.
Die version liegt zunächst in meinem contrib (siehe Fußtext). Du kannst die Version herunterladen, dein FHEM restarten und die Funktion testen.

LG,
Heiko

[flummy1978]

Hey Heiko,

ich hab mir die Funktion multicmd auch angeschaut und finde sie total cool (hat mir viele einzelne Devices entfernt).

Allerdings bekomme ich seit der Umstellung gelegentlich mal diese Meldung:

Code Auswählen Erweitern

2024.03.02 03:23:37.596 2: DbRep SQL_DBrep_Device - ERROR - DBD::mysql::st execute failed: Lock wait timeout exceeded; try restarting transaction at ./FHEM/93_DbRep.pm line 11966
oder
2024.03.02 13:41:00.129 1: DbRep SQL_DBrep_Device -> BlockingCall DbRep_averval pid:171276 Timeout: process terminated

Zeitlich würde ich dafür dieses Device vermuten ohne bisher weiter ins Detail zu gehen. (Verbose hatte ich zur Fehlersuche erhöht, es aber biser nicht provizieren können)

Code Auswählen Erweitern

Internals:
   COMMAND    set SQL_DBrep_Device multiCmd {
        {
          1  => { timeDiffToNow  => 'm:15',
                  device          => 'Wetterstation',
                  reading         => 'wind_gust',
                  cmd             => 'averageValue writeToDBInTime'
                },
        2  =>  { timeDiffToNow  => 'm:15',
                  device          => 'Wetterstation',
                  reading         => 'luminosity',
                  cmd             => 'averageValue writeToDBInTime'
                },
          3  =>  { timeDiffToNow  => 'm:15',
                  device          => 'Wetterstation',
                  reading         => 'wind_speed',
                  cmd             => 'averageValue writeToDBInTime'
                },
          4  =>  { timeDiffToNow  => 'm:15',
                  device          => 'Wetterstation',
                  reading         => 'humidity',
                  cmd             => 'averageValue writeToDBInTime'
                },
          5  =>  { timeDiffToNow  => 'm:15',
                  device          => 'Wetterstation',
                  reading         => 'temperature',
                  cmd             => 'averageValue writeToDBInTime'
                },
          6  =>  { timeDiffToNow  => 'd:3',
                  timeOlderThan   => 'd:2',
                  device          => 'Wetterstation',
                  reading         => 'luminosity,wind_gust,wind_speed,humidity,temperature',
                  cmd             => 'delEntries'
                },
          7  =>  { timeDiffToNow  => 'm:15',
                  device          => '     dev_EG_WZ_innen_temperatur',
                  reading         => 'humidity',
                  cmd             => 'averageValue writeToDBInTime'
                },
          8  =>  { timeDiffToNow  => 'm:15',
                  device          => '     dev_EG_WZ_innen_temperatur',
                  reading         => 'temperature',
                  cmd             => 'averageValue writeToDBInTime'
                },
          9  =>  { timeDiffToNow  => 'm:15',
                  device          => 'dev_EG_WZ_LUX_innen',
                  reading         => 'illuminance',
                  cmd             => 'averageValue writeToDBInTime'
                },
          10  =>  { timeDiffToNow  => 'd:4',
                  timeOlderThan   => 'd:2',
                  device          => 'dev_EG_WZ_LUX_innen',
                  reading         => 'illuminance',
                  cmd             => 'delEntries'
                },
          11  =>  { timeDiffToNow  => 'd:4',
                  timeOlderThan   => 'd:2',
                  device          => 'dev_EG_WZ_innen_temperatur',
                  reading         => 'humidity,temperature',
                  cmd             => 'delEntries'
                },

}
}
   DEF        +*00:15  set SQL_DBrep_Device multiCmd {
        {
          1  => { timeDiffToNow  => 'm:15',
                  device          => 'Wetterstation',
                  reading         => 'wind_gust',
                  cmd             => 'averageValue writeToDBInTime'
                },
        2  =>  { timeDiffToNow  => 'm:15',
                  device          => 'Wetterstation',
                  reading         => 'luminosity',
                  cmd             => 'averageValue writeToDBInTime'
                },
          3  =>  { timeDiffToNow  => 'm:15',
                  device          => 'Wetterstation',
                  reading         => 'wind_speed',
                  cmd             => 'averageValue writeToDBInTime'
                },
          4  =>  { timeDiffToNow  => 'm:15',
                  device          => 'Wetterstation',
                  reading         => 'humidity',
                  cmd             => 'averageValue writeToDBInTime'
                },
          5  =>  { timeDiffToNow  => 'm:15',
                  device          => 'Wetterstation',
                  reading         => 'temperature',
                  cmd             => 'averageValue writeToDBInTime'
                },
          6  =>  { timeDiffToNow  => 'd:3',
                  timeOlderThan   => 'd:2',
                  device          => 'Wetterstation',
                  reading         => 'luminosity,wind_gust,wind_speed,humidity,temperature',
                  cmd             => 'delEntries'
                },
          7  =>  { timeDiffToNow  => 'm:15',
                  device          => '     dev_EG_WZ_innen_temperatur',
                  reading         => 'humidity',
                  cmd             => 'averageValue writeToDBInTime'
                },
          8  =>  { timeDiffToNow  => 'm:15',
                  device          => '     dev_EG_WZ_innen_temperatur',
                  reading         => 'temperature',
                  cmd             => 'averageValue writeToDBInTime'
                },
          9  =>  { timeDiffToNow  => 'm:15',
                  device          => 'dev_EG_WZ_LUX_innen',
                  reading         => 'illuminance',
                  cmd             => 'averageValue writeToDBInTime'
                },
          10  =>  { timeDiffToNow  => 'd:4',
                  timeOlderThan   => 'd:2',
                  device          => 'dev_EG_WZ_LUX_innen',
                  reading         => 'illuminance',
                  cmd             => 'delEntries'
                },
          11  =>  { timeDiffToNow  => 'd:4',
                  timeOlderThan   => 'd:2',
                  device          => 'dev_EG_WZ_innen_temperatur',
                  reading         => 'humidity,temperature',
                  cmd             => 'delEntries'
                },

}
}
   FUUID      5e80a069-f33f-8d79-a867-e1060514c503b7ec
   FVERSION   90_at.pm:0.284400/2024-01-28
   NAME       at_DBrep_15Min_Werte
   NR         151
   NTM        16:37:30
   PERIODIC   yes
   RELATIVE   yes
   REP        -1
   STATE      Next: 16:37:30
   TIMESPEC   00:15
   TRIGGERTIME 1709480250
   TRIGGERTIME_FMT 2024-03-03 16:37:30
   TYPE       at
   eventCount 181
   READINGS:
     2024-03-03 16:22:30   state           Next: 16:37:30
Attributes:
   DbLogExclude .*
   alignTime  01:07:30
   group      Auslösungen < 1x Tag
   room       System->Datenbank
   verbose    5

Kann es der gleiche Bug sein, der oben gefixt wurde?

VG
Andreas

[DS_Starter]

Hallo Andreas,

Kann es der gleiche Bug sein, der oben gefixt wurde?

Nein. Da hatte ich aus einer Fehlerbehandlung einfach einen Rücksprung vergessen.

In deinem Fall vermute ich eher einen "Konflikt" mit DbLog. Für bestimmt Operationen muß die Anwendung die Tabelle sperren (Lock Table). Wenn du eine lange Kommandokette hast, kommt DbLog nicht zum Zug und wartet auf eine Gelegenheit reinzuspringen. Wenn es mal gelingt, und es sind viele Daten im Cache aufgelaufen, krallt sich DbLog die DB. DbRep muß nun warten um seinerseits die history zu sperren. Wenn das zu lange dauert, kommt mit "Lock wait timeout exceeded" der Timeout. Soweit meine Theorie.

Du kannst es überprüfen indem du vor dem Start von multiCmd im DbLog ein "set ... reopen 3600" ausführst.
Das sperrt DbLog für eine Stunde und DbRep hat die DB für sich. Wenn multiCmd durch ist, öffnest du DbLog wieder mit "set ... reopen".

Grüße,
Heiko

[rolizer]

sorry for confusion - hatte die falsche Datei geladen.

[DS_Starter]

Code Auswählen Erweitern

"wget -qO ./FHEM/93_DbRep.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_DbRep.pm

Oder du brauchst eigentlich nur auf den Link im Fußtext gehen und das Modul auswählen und mit dem Downloadbutton im Originalformat speichern (Windows Client).