dblog: reopen mit leerem Cache

[sfancy]

Hallo,

ich verwende in meinem Backup-Script die Befehle:

Code Auswählen Erweitern

set LogDBenergy commitCache ; set LogDBenergy reopen 7200
und nach dem Backup:

Code Auswählen Erweitern

set LogDBenergy reopen
Mir ist aufgefallen, dass ein reopen nach dem Backup nicht funktioniert, wenn der Cache leer ist weil in der Zwischenzeit kein zu loggendes Event kam. Erst wenn Cache>=1 ist geht das reopen. Ist das so gewollt oder ein Fehler?

Hier noch das Logfile mit verbose=5:

Code Auswählen Erweitern

2026.01.16 18:06:13 2: LogDBenergy - Connection closed until 20:06:13 (7200 seconds).

2025.01.16 18:06:32 3: LogDBenergy - Reopen requested

2025.01.16 18:08:02 4: LogDBenergy - ################################################################
2025.01.16 18:08:02 4: LogDBenergy - ###              start of new Logcycle                       ###
2025.01.16 18:08:02 4: LogDBenergy - ################################################################
2025.01.16 18:08:02 4: LogDBenergy - number of events received: 1 of device: Sonoff_PV
2025.01.16 18:08:02 4: LogDBenergy - check Device: Sonoff_PV , Event: ENERGY_Yesterday: 0.2111
2025.01.16 18:08:02 5: LogDBenergy - parsed Event: Sonoff_PV , Event: ENERGY_Yesterday: 0.2111
2025.01.16 18:08:02 4: LogDBenergy - added event - Timestamp: 2025-01-16 18:08:02, Device: Sonoff_PV, Type: MQTT2_DEVICE, Event: ENERGY_Yesterday: 0.2111, Reading: ENERGY_Yesterday, Value: 0.2111, Unit: kWh
2025.01.16 18:08:42 3: LogDBenergy - Reopen requested
2025.01.16 18:08:42 4: LogDBenergy - ################################################################
2025.01.16 18:08:42 4: LogDBenergy - ###      New database processing cycle - SBP asynchronous    ###
2025.01.16 18:08:42 4: LogDBenergy - ################################################################
2025.01.16 18:08:42 4: LogDBenergy - MemCache contains 1 entries to process
2025.01.16 18:08:42 4: LogDBenergy - DbLogType is: Current/History
2025.01.16 18:08:42 5: LogDBenergy - MemCache contains:  5806 -> 2025-01-16 18:08:02|Sonoff_PV|MQTT2_DEVICE|ENERGY_Yesterday: 0.2111|ENERGY_Yesterday|0.2111|kWh
2025.01.16 18:08:42 4: LogDBenergy - simple do statement: PRAGMA temp_store=MEMORY
2025.01.16 18:08:42 4: LogDBenergy - simple do statement: PRAGMA synchronous=FULL
2025.01.16 18:08:42 4: LogDBenergy - simple do statement: PRAGMA journal_mode=WAL
2025.01.16 18:08:42 4: LogDBenergy - simple do statement: PRAGMA cache_size=4000
2025.01.16 18:08:42 3: LogDBenergy - SubProcess connected to /opt/fhem/log/energy.db
2025.01.16 18:08:42 4: LogDBenergy - Operation: log_asynch
2025.01.16 18:08:42 4: LogDBenergy - Primary Key used in history: none
2025.01.16 18:08:42 4: LogDBenergy - Primary Key used in current: none
2025.01.16 18:08:42 5: LogDBenergy - DbLogType: Current/History
2025.01.16 18:08:42 4: LogDBenergy - AutoCommit: ON, Transaction: ON
2025.01.16 18:08:42 4: LogDBenergy - Insert mode: Array
2025.01.16 18:08:42 5: LogDBenergy - processing 5806 -> TS: 2025-01-16 18:08:02, Dev: Sonoff_PV, Type: MQTT2_DEVICE, Event: ENERGY_Yesterday: 0.2111, Reading: ENERGY_Yesterday, Val: 0.2111, Unit: kWh
2025.01.16 18:08:42 4: LogDBenergy - begin Transaction
2025.01.16 18:08:42 4: LogDBenergy - 1 of 1 events inserted into table history
2025.01.16 18:08:42 4: LogDBenergy - commit inserted data table >history<
2025.01.16 18:08:42 4: LogDBenergy - begin Transaction
2025.01.16 18:08:42 4: LogDBenergy - 1 of 1 events updated in table current
2025.01.16 18:08:42 4: LogDBenergy - commit inserted data table >current<


[DS_Starter]

Das ist kein Fehler.
Du hast den asynchronen Modus gewählt. Erst wenn der Cache zu verarbeitende Daten enthält, wird der Request an die DB weitergeleitet (und der Status geht auf connected bei Erfolg), vorher ist es nicht nötig.

[sfancy]

Danke für die schnelle Antwort. Ich war nur zu ungeduldig und habe mich vom weiterhin anstehenden STATE 'Database disconnected by request.' verwirren lassen. Ich habe nach dem reopen ein STATE 'waiting for connection' erwartet.