Hallo,
seit längerm läd FHEM extrem langsam. Vor allem, wenn ich die Temperaturwerte anzeigen lassen bzw. Räume mit Temperatursensoren.
im Logfile zeigt Freezemon folgende Meldungen an (habe vom 21.07. mal ein paar Meldungen herauskopiert; wiederholen sich anscheinend immer wieder):
2019.07.21 01:11:02 1: [Freezemon] myFreezemon: possible freeze starting at 01:11:00, delay is 2.52 possibly caused by: no bad guy found :-(
2019.07.21 01:14:44 1: [Freezemon] myFreezemon: possible freeze starting at 01:14:43, delay is 1.51 possibly caused by: no bad guy found :-(
2019.07.21 01:14:48 1: [Freezemon] myFreezemon: possible freeze starting at 01:14:47, delay is 1.826 possibly caused by: no bad guy found :-(
2019.07.21 01:15:49 1: [Freezemon] myFreezemon: possible freeze starting at 01:15:47, delay is 2.212 possibly caused by: no bad guy found :-(
2019.07.21 01:24:18 1: [Freezemon] myFreezemon: possible freeze starting at 01:24:17, delay is 1.801 possibly caused by: tmr-at_Exec(at_KIND_virt_Temperatur_Sensor1) tmr-at_Exec(at_KIND_virt_Temperatur_Sensor2) tmr-at_Exec(at_WOH_virt_Temperatur) tmr-at_Exec(at_WOH_virt_Temperatur_2) tmr-at_Exec(at_WOH_virt_Temperatur_3)
2019.07.21 02:24:18 1: [Freezemon] myFreezemon: possible freeze starting at 02:24:17, delay is 1.792 possibly caused by: tmr-at_Exec(at_KIND_virt_Temperatur_Sensor1) tmr-at_Exec(at_KIND_virt_Temperatur_Sensor2) tmr-at_Exec(at_WOH_virt_Temperatur) tmr-at_Exec(at_WOH_virt_Temperatur_2) tmr-at_Exec(at_WOH_virt_Temperatur_3)
2019.07.21 03:24:18 1: [Freezemon] myFreezemon: possible freeze starting at 03:24:17, delay is 1.875 possibly caused by: tmr-HMUARTLGW_CheckCredits(HmUART) tmr-at_Exec(at_KIND_virt_Temperatur_Sensor1) tmr-at_Exec(at_KIND_virt_Temperatur_Sensor2) tmr-at_Exec(at_WOH_virt_Temperatur) tmr-at_Exec(at_WOH_virt_Temperatur_2) tmr-at_Exec(at_WOH_virt_Temperatur_3)
2019.07.21 04:14:09 1: [Freezemon] myFreezemon: possible freeze starting at 04:14:08, delay is 1.834 possibly caused by: tmr-CUL_HM_valvePosUpdt(96517501)
2019.07.21 04:24:18 1: [Freezemon] myFreezemon: possible freeze starting at 04:24:17, delay is 1.802 possibly caused by: tmr-at_Exec(at_KIND_virt_Temperatur_Sensor1) tmr-at_Exec(at_KIND_virt_Temperatur_Sensor2) tmr-at_Exec(at_WOH_virt_Temperatur) tmr-at_Exec(at_WOH_virt_Temperatur_2) tmr-at_Exec(at_WOH_virt_Temperatur_3)
2019.07.21 05:24:18 1: [Freezemon] myFreezemon: possible freeze starting at 05:24:17, delay is 1.755 possibly caused by: tmr-at_Exec(at_KIND_virt_Temperatur_Sensor1) tmr-at_Exec(at_KIND_virt_Temperatur_Sensor2) tmr-at_Exec(at_WOH_virt_Temperatur) tmr-at_Exec(at_WOH_virt_Temperatur_2) tmr-at_Exec(at_WOH_virt_Temperatur_3)
2019.07.21 06:24:19 1: [Freezemon] myFreezemon: possible freeze starting at 06:24:17, delay is 2.078 possibly caused by: tmr-at_Exec(at_KIND_virt_Temperatur_Sensor1) tmr-at_Exec(at_KIND_virt_Temperatur_Sensor2) tmr-at_Exec(at_WOH_virt_Temperatur) tmr-at_Exec(at_WOH_virt_Temperatur_2) tmr-at_Exec(at_WOH_virt_Temperatur_3) tmr-HttpUtils_Err(N/A)
2019.07.21 07:24:18 1: [Freezemon] myFreezemon: possible freeze starting at 07:24:17, delay is 1.764 possibly caused by: tmr-at_Exec(at_KIND_virt_Temperatur_Sensor1) tmr-at_Exec(at_KIND_virt_Temperatur_Sensor2) tmr-at_Exec(at_WOH_virt_Temperatur) tmr-at_Exec(at_WOH_virt_Temperatur_2) tmr-at_Exec(at_WOH_virt_Temperatur_3)
2019.07.21 09:24:18 1: [Freezemon] myFreezemon: possible freeze starting at 09:24:17, delay is 1.885 possibly caused by: tmr-at_Exec(at_KIND_virt_Temperatur_Sensor1) tmr-at_Exec(at_KIND_virt_Temperatur_Sensor2) tmr-at_Exec(at_WOH_virt_Temperatur) tmr-at_Exec(at_WOH_virt_Temperatur_2) tmr-at_Exec(at_WOH_virt_Temperatur_3)
2019.07.21 10:24:18 1: [Freezemon] myFreezemon: possible freeze starting at 10:24:17, delay is 1.913 possibly caused by: tmr-HMUARTLGW_CheckCredits(HmUART) tmr-at_Exec(at_KIND_virt_Temperatur_Sensor1) tmr-at_Exec(at_KIND_virt_Temperatur_Sensor2) tmr-at_Exec(at_WOH_virt_Temperatur) tmr-at_Exec(at_WOH_virt_Temperatur_2) tmr-at_Exec(at_WOH_virt_Temperatur_3)
2019.07.21 11:24:18 1: [Freezemon] myFreezemon: possible freeze starting at 11:24:17, delay is 1.738 possibly caused by: tmr-CUL_HM_valvePosUpdt(85764302) tmr-at_Exec(at_KIND_virt_Temperatur_Sensor1) tmr-at_Exec(at_KIND_virt_Temperatur_Sensor2) tmr-at_Exec(at_WOH_virt_Temperatur) tmr-at_Exec(at_WOH_virt_Temperatur_2) tmr-at_Exec(at_WOH_virt_Temperatur_3)
2019.07.21 12:24:18 1: [Freezemon] myFreezemon: possible freeze starting at 12:24:17, delay is 1.739 possibly caused by: tmr-at_Exec(at_KIND_virt_Temperatur_Sensor1) tmr-at_Exec(at_KIND_virt_Temperatur_Sensor2) tmr-at_Exec(at_WOH_virt_Temperatur) tmr-at_Exec(at_WOH_virt_Temperatur_2) tmr-at_Exec(at_WOH_virt_Temperatur_3)
Hier ein list vom KIND_virt_Temperatur_Sensor1, an dem es ansch. mit liegt (die anderen Devices kann ich gerne auch noch einstellen, falls benötigt):
Internals:
DEF 85764301
FUUID 5c65c66f-f33f-194f-a8ed-cae43cd59de3bfbb
NAME KIND_virt_Temperatur_Sensor1
NOTIFYDEV global
NR 131
NTFY_ORDER 50-KIND_virt_Temperatur_Sensor1
STATE set_virtTemp 27.12
TYPE CUL_HM
chanNo 01
device KIND_virt_Temperatur
peerList KIND_HEIZUNG_1_Weather,
Helper:
DBLOG:
state:
DbLog:
TIME 1563982884.17976
VALUE set_virtTemp 27.12
temperature:
DbLog:
TIME 1563982884.15539
VALUE 27.12
READINGS:
2019-07-24 14:41:25 peerList KIND_HEIZUNG_1_Weather,
2019-07-24 17:41:24 state set_virtTemp 27.12
2019-07-24 17:41:24 temperature 27.12
helper:
fkt virtThSens
peerFriend peerSD,peerSens,peerAct
peerOpt -:virtual
regLst
virtTC 00
expert:
def 1
det 0
raw 1
tpl 0
role:
chn 1
vrt 1
tmpl:
vd:
cmd 8470857643000000
idh 2369086
idl 17152
msgCnt 81
msgRed 0
next 1563985135.11012
nextM 1563985135.11012
typ 2
val 010F
vin 27.12
Attributes:
model VIRTUAL
peerIDs 62FB6A01,
webCmd press short:press long
Vielen Dank
Ruggy
Leider bin ich noch nicht weitergekommen.
Jetzt ist es leider nur so, dass ich nahezu keine Temperatur/Feuchtewerte mehr auslesen kann.
Es hängt anscheinend auch irgendwie mit den Sensoren (Xiaomi) und deren Logs zusammen. Oder mit den zusammenhängenden virtuellen Sensoren (für die Steuerung der Heizkörperthermostate; Homematic).
Die Räume in denen sich diese Sensoren befinden kann ich nicht mehr laden. Es läd und läd und läd...
Der Rest wie Türsensor, Lichtschalter, Steckdosenschalter funktionieren noch normal.
Die Räume in denen sich keine Temperatursensoren befinden werden relativ schnell angezeigt.
Wahrscheinlich bleibt mir nichts anderes übrig, FHEM komplett neu zu instalieren.
Ich hätte nur dabei den Fehler nicht erneut gemacht.
Falls noch andere Lists benötigt werden kann ich das gerne machen.
Danke
Grüße Ruggy
Folgendes wird durch den Befehl apptime max angezeigt.
active-timers: 19; max-active timers: 21; max-timer-load: 7 min-tmrHandlingTm: 0.0ms; max-tmrHandlingTm: 671.2ms; totAvgDly: 1590.1ms
name function max count total average maxDly avgDly TS Max call param Max call
DbLog DbLog_Get 60982 2 71830.94 35915.47 0.00 0.00 06.10. 10:12:30 HASH(DbLog); DbLog; HISTORY; INT; 2019-10-06_00:00:00; 2019-10-06_23:59:59; KIND_LUFTFEUCHTE:temperature; KIND_LUFTFEUCHTE:humidity
HmUART HMUARTLGW_Read 573 330 3644.49 11.04 0.00 0.00 06.10. 10:12:42 HASH(HmUART)
tmr-CUL_HM_valvePosUpdt valvePos 411 38 3257.40 85.72 50281.69 2254.59 06.10. 10:12:41 valvePos:96517501
presence.karsten PRESENCE_Notify 255 35 1335.04 38.14 0.00 0.00 06.10. 10:09:31 HASH(presence.karsten); HASH(Unifi_AP_Abstellkammer)
DbLog DbLog_Log 252 364 9197.34 25.27 0.00 0.00 06.10. 10:09:31 HASH(DbLog); HASH(presence.karsten)
MQTT MQTT::Read 242 23 375.63 16.33 0.00 0.00 06.10. 10:12:43 HASH(MQTT)
presence.susi PRESENCE_Notify 229 35 1259.16 35.98 0.00 0.00 06.10. 10:12:45 HASH(presence.susi); HASH(Unifi_AP_Abstellkammer)
deCONZ HUEBridge_Read 182 21 570.21 27.15 0.00 0.00 06.10. 10:27:41 HASH(deCONZ)
tmr-at_Exec HASH(0x3b54ab8) 84 1 84.18 84.18 85.14 85.14 06.10. 10:19:59 HASH(at_WOH_virt_Temperatur)
tmr-at_Exec HASH(0x3b55150) 67 1 67.22 67.22 167.93 167.93 06.10. 10:19:59 HASH(at_WOH_virt_Temperatur_2)
tmr-at_Exec HASH(0x3b27228) 65 1 65.04 65.04 1.93 1.93 06.10. 10:19:58 HASH(at_KIND_virt_Temperatur_Sensor1)
tmr-at_Exec HASH(0x2b14f60) 64 1 64.04 64.04 233.69 233.69 06.10. 10:19:59 HASH(at_WOH_virt_Temperatur_3)
tmr-at_Exec HASH(0x3b40060) 57 1 57.62 57.62 65.55 65.55 06.10. 10:19:58 HASH(at_KIND_virt_Temperatur_Sensor2)
WOH_virt_Temperatur_Sensor1 CUL_HM_Set 54 1 54.91 54.91 0.00 0.00 06.10. 10:19:59 HASH(WOH_virt_Temperatur_Sensor1); WOH_virt_Temperatur_Sensor1; virtTemp; 21.16
WOH_virt_Temperatur_2_Sensor1 CUL_HM_Set 46 1 46.64 46.64 0.00 0.00 06.10. 10:19:59 HASH(WOH_virt_Temperatur_2_Sensor1); WOH_virt_Temperatur_2_Sensor1; virtTemp; 21.16
nanoCUL CUL_Read 39 9 241.55 26.84 0.00 0.00 06.10. 10:25:25 HASH(nanoCUL)
KIND_virt_Temperatur_Sensor2 CUL_HM_Set 37 2 47.66 23.83 0.00 0.00 06.10. 10:19:58 HASH(KIND_virt_Temperatur_Sensor2); KIND_virt_Temperatur_Sensor2; virtTemp; 19.23
WOH_virt_Temperatur_3_Sensor1 CUL_HM_Set 37 1 37.26 37.26 0.00 0.00 06.10. 10:19:59 HASH(WOH_virt_Temperatur_3_Sensor1); WOH_virt_Temperatur_3_Sensor1; virtTemp; 21.16
KIND_virt_Temperatur_Sensor1 CUL_HM_Set 36 1 36.65 36.65 0.00 0.00 06.10. 10:19:58 HASH(KIND_virt_Temperatur_Sensor1); KIND_virt_Temperatur_Sensor1; virtTemp; 19.23
KIND_LUFTDRUCK HUEDevice_Set 20 1 20.97 20.97 0.00 0.00 06.10. 10:11:29 HASH(KIND_LUFTDRUCK); KIND_LUFTDRUCK; ?
MQTT MQTT::Ready 18 2 18.97 9.48 0.00 0.00 06.10. 10:12:42 HASH(MQTT)
KIND_HEIZUNG_1 CUL_HM_Set 7 1 7.78 7.78 0.00 0.00 06.10. 10:11:29 HASH(KIND_HEIZUNG_1); KIND_HEIZUNG_1; ?
KIND_HEIZUNG_2 CUL_HM_Set 7 1 7.75 7.75 0.00 0.00 06.10. 10:11:29 HASH(KIND_HEIZUNG_2); KIND_HEIZUNG_2; ?
FileLog_WOH_HEIZUNG_2 FileLog_Log 7 7 17.34 2.48 0.00 0.00 06.10. 10:22:18 HASH(FileLog_WOH_HEIZUNG_2); HASH(WOH_HEIZUNG_2)
Push_FLUR_BEWEG_1_notify notify_Exec 7 6 23.57 3.93 0.00 0.00 06.10. 10:21:29 HASH(Push_FLUR_BEWEG_1_notify); HASH(FLUR_BEWEG_1)
FileLog_WOH_HEIZUNG_1 FileLog_Log 6 8 10.97 1.37 0.00 0.00 06.10. 10:12:41 HASH(FileLog_WOH_HEIZUNG_1); HASH(WOH_HEIZUNG_1)
FileLog_KIND_HEIZUNG_2 FileLog_Log 6 7 10.01 1.43 0.00 0.00 06.10. 10:13:25 HASH(FileLog_KIND_HEIZUNG_2); HASH(KIND_HEIZUNG_2)
FileLog_KIND_HEIZUNG_1 FileLog_Log 6 8 10.68 1.33 0.00 0.00 06.10. 10:13:31 HASH(FileLog_KIND_HEIZUNG_1); HASH(KIND_HEIZUNG_1)
FileLog_WOH_HEIZUNG_3 FileLog_Log 6 7 10.62 1.52 0.00 0.00 06.10. 10:13:39 HASH(FileLog_WOH_HEIZUNG_3); HASH(WOH_HEIZUNG_3)
BALKON_TEMPERATUR_FileLog_1 FileLog_Log 6 2 7.09 3.55 0.00 0.00 06.10. 10:26:54 HASH(BALKON_TEMPERATUR_FileLog_1); HASH(BALKON_TEMPERATUR)
tmr-CUL_HM_ActCheck ActionDetector 3 2 5.96 2.98 135.07 69.07 06.10. 10:20:01 ActionDetector
FileLog_CUL_TX_78 FileLog_Log 3 1 3.72 3.72 0.00 0.00 06.10. 10:23:03 HASH(FileLog_CUL_TX_78); HASH(CUL_TX_78)
tmr-Unifi_DoUpdate HASH(0x3b57418) 3 35 70.44 2.01 60073.70 1718.97 06.10. 10:20:27 HASH(Unifi_AP_Abstellkammer)
tmr-HMUARTLGW_CheckCredits HMUARTLGW_CheckCredits 3 76 170.24 2.24 71652.90 949.66 06.10. 10:17:41 HMUARTLGW_CheckCredits:HmUART
tmr-HUEBridge_GetUpdate HASH(0x2995b00) 3 20 46.63 2.33 38662.47 1946.92 06.10. 10:17:41 HASH(deCONZ)
FileLog_FLUR_BEWEG_1 FileLog_Log 3 6 6.36 1.06 0.00 0.00 06.10. 10:21:29 HASH(FileLog_FLUR_BEWEG_1); HASH(FLUR_BEWEG_1)
dewpointToAllDeviceReadings dewpoint_Notify 3 364 169.58 0.47 0.00 0.00 06.10. 10:14:25 HASH(dewpointToAllDeviceReadings); HASH(Unifi_AP_Abstellkammer)
tmr-HMUARTLGW_CheckCmdResp HASH(0x296bb48) 2 1 2.69 2.69 45.29 45.29 06.10. 10:12:42 HASH(HmUART)
tmr-MQTT::Timer HASH(0x3c221e8) 2 20 38.45 1.92 38670.69 1940.00 06.10. 10:17:42 HASH(MQTT)
FileLog_HM_544B10 FileLog_Log 2 364 165.31 0.45 0.00 0.00 06.10. 10:14:25 HASH(FileLog_HM_544B10); HASH(Unifi_AP_Abstellkammer)
FileLog_HM_62FAC4 FileLog_Log 2 364 126.23 0.35 0.00 0.00 06.10. 10:23:16 HASH(FileLog_HM_62FAC4); HASH(Unifi_AP_Abstellkammer)
Ein List von DbLog
Internals:
COLUMNS field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
CONFIGURATION ./db.conf
DEF ./db.conf .*:(temperature|humidity|dewpoint|absFeuchte|pressure|state|open|closed|on|off|water|ValvePosition).*
FUUID 5c65c66f-f33f-194f-58b0-1caee314a069d7a7
MODE synchronous
MODEL SQLITE
NAME DbLog
NR 85
NTFY_ORDER 50-DbLog
PID 32618
REGEXP .*:(temperature|humidity|dewpoint|absFeuchte|pressure|state|open|closed|on|off|water|ValvePosition).*
STATE connected
TYPE DbLog
VERSION 3.13.1
dbconn SQLite:dbname=/opt/fhem/fhem.db
dbuser
HELPER:
COLSET 1
DEVICECOL 64
EVENTCOL 512
OLDSTATE connected
READINGCOL 64
TYPECOL 64
UNITCOL 32
VALUECOL 128
Helper:
DBLOG:
state:
DbLog:
TIME 1570342802.67589
VALUE connected
READINGS:
2019-10-06 10:29:37 state connected
cache:
index 0
helper:
bm:
DbLog_Get:
cnt 2
dmx -1000
dtot 0
dtotcnt 0
mTS 06.10. 10:12:30
max 60.9821169376373
tot 71.8309409618378
mAr:
HASH(DbLog)
DbLog
HISTORY
INT
2019-10-06_00:00:00
2019-10-06_23:59:59
KIND_LUFTFEUCHTE:temperature
KIND_LUFTFEUCHTE:humidity
DbLog_Log:
cnt 387
dmx -1000
dtot 0
dtotcnt 0
mTS 06.10. 10:09:31
max 0.252151966094971
tot 9.59991788864136
mAr:
HASH(DbLog)
HASH(presence.karsten)
DbLog_regexpFn:
cnt 2
dmx -1000
dtot 0
dtotcnt 0
mTS 06.10. 10:12:41
max 7.48634338378906e-05
tot 0.000139713287353516
mAr:
DbLog
KIND_LUFTFEUCHTE:absFeuchte KIND_LUFTFEUCHTE:dewpoint
Attributes:
DbLogType Current/History
Hast du auf den Seiten mit den Temp-Sensoren auch irgendwelche Plots!?
Wie häufig loggst du denn Temp-Werte?
Wie sehen die Log-Devices aus, also wie groß ist die Datenmenge?
(Wenn du FileLog hättest, wüsste ich wie man das sieht, also wie häufig wird eine neue Logdatei angelegt: 1x pro Jahr, 1x pro Monat, 1x pro ... / bei DBLog weiß ich leider nicht wie man das feststellt)
Hast du event-on-change-reading etc. "im Einsatz"!?
(solltest du dir mal anschauen, wenn noch nicht)
Weil ansonsten sind die Detailansichten (egal von was) unabhängig von den Werten eines Devices im Log...
...wird ja nicht (bzw. halt max. in Plots) angezeigt...
Wenn das Problem an diesen Dingen liegt: zu viele Daten im Log und (zu) viele Plots auf den Seiten, dann wird ein neu aufsetzen nicht wirklich helfen (außer wirklich NEU OHNE die "alten" Logs / und das dann nur, bis die neu aufgesetzten Logs wieder "groß" sind)...
Gruß, Joachim
Auf den Seiten bzw. Räumen mit den Sensoren habe ich Plots aus den DbLogs.
So sieht z.B. das List vom Sensor im Kinderzimmer. Aus diesen lese ich Temperatur, Luftfeuchtigkeit, abs. Luftfeuchtigkeit, Taupunkt.
Internals:
DEF sensor 10 IODev=deCONZ
FUUID 5c65c66e-f33f-194f-7c57-c84105a208a13e31
ID S10
INTERVAL
IODev deCONZ
NAME KIND_LUFTFEUCHTE
NR 61
STATE Initialized
TYPE HUEDevice
lastupdated 2019-10-06 11:17:33
lastupdated_local 2019-10-06 12:17:33
manufacturername LUMI
modelid lumi.weather
name Multi_Kinderzimmer
on 1
reachable 1
swversion 20161129
type ZHAHumidity
uniqueid 00:15:8d:00:02:78:9d:dc-01-0405
Helper:
DBLOG:
absFeuchte:
DbLog:
TIME 1570360653.20201
VALUE 9.9
dewpoint:
DbLog:
TIME 1570360653.20201
VALUE 11.3
humidity:
DbLog:
TIME 1570360653.20201
VALUE 57.27
temperature:
DbLog:
TIME 1570360653.20201
VALUE 20.04
READINGS:
2019-10-06 13:17:33 absFeuchte 9.9
2019-10-06 13:17:33 battery 100
2019-10-06 13:17:33 dewpoint 11.3
2019-10-06 12:17:33 humidity 57.27
2019-10-06 13:17:33 reachable 1
2019-10-06 13:17:33 temperature 20.04
helper:
devtype S
reachable 0
update_timeout 1
bm:
HUEDevice_Get:
cnt 1
dmx -1000
dtot 0
dtotcnt 0
mTS 06.10. 13:31:48
max 6.103515625e-05
tot 6.103515625e-05
mAr:
HASH(0x32654f0)
KIND_LUFTFEUCHTE
?
HUEDevice_Set:
cnt 3
dmx -1000
dtot 0
dtotcnt 0
mTS 06.10. 13:31:48
max 0.00120687484741211
tot 0.00283002853393555
mAr:
HASH(0x32654f0)
KIND_LUFTFEUCHTE
?
setList:
Attributes:
IODev deCONZ
room Kinderzimmer
userReadings temperature {ReadingsVal("KIND_TEMPERATUR","temperature",0)}
So sieht der virt Temperatursensor vom Kinderzimmer aus.
Internals:
COMMAND { my $T=(ReadingsVal("KIND_LUFTFEUCHTE","temperature",20.0)); fhem "set KIND_virt_Temperatur_Sensor1 virtTemp $T" }
DEF +*01:00 { my $T=(ReadingsVal("KIND_LUFTFEUCHTE","temperature",20.0)); fhem "set KIND_virt_Temperatur_Sensor1 virtTemp $T" }
FUUID 5c65c66f-f33f-194f-50a5-0d83b901c7b79372
NAME at_KIND_virt_Temperatur_Sensor1
NR 133
NTM 14:19:58
PERIODIC yes
RELATIVE yes
REP -1
STATE Next: 14:19:58
TIMESPEC 01:00
TRIGGERTIME 1570364398.84665
TRIGGERTIME_FMT 2019-10-06 14:19:58
TYPE at
Helper:
DBLOG:
state:
DbLog:
TIME 1570360799.10468
VALUE Next
READINGS:
2019-10-06 13:19:59 state Next: 14:19:58
helper:
bm:
at_Set:
cnt 1
dmx -1000
dtot 0
dtotcnt 0
mTS 06.10. 13:31:40
max 0.000165939331054688
tot 0.000165939331054688
mAr:
HASH(0x3b27228)
at_KIND_virt_Temperatur_Sensor1
?
Attributes:
Hier das Verzeichnis log unter fhem.
(Ganz schön viel; kenne mich leider zu wenig aus; wusste nicht, was hier alles geloggt wird. Von Hoermann habe ich eigentlich keine Geräte.)
total 430120
-rw-r--r-- 1 fhem dialout 3347 Dec 19 2018 BALKON_LUFTFEUCHTE_FileLog_1.log
-rw-r--r-- 1 fhem dialout 2827690 Oct 6 13:04 BALKON_TEMPERATUR_FileLog_1.log
-rw-r--r-- 1 fhem dialout 0 May 15 14:30 CUL_FHTTK_0cc0c0-2019.log
-rw-r--r-- 1 fhem dialout 0 Mar 18 2019 CUL_FHTTK_634178-2019.log
-rw-r--r-- 1 fhem dialout 0 Mar 9 2019 CUL_HOERMANN_0010020050-2019.log
-rw-r--r-- 1 fhem dialout 0 Apr 28 15:51 CUL_HOERMANN_02310410A0-2019.log
-rw-r--r-- 1 fhem dialout 0 Apr 27 08:53 CUL_HOERMANN_026425D080-2019.log
-rw-r--r-- 1 fhem dialout 0 Aug 16 08:33 CUL_HOERMANN_0400110000-2019.log
-rw-r--r-- 1 fhem dialout 0 Mar 15 2019 CUL_HOERMANN_312C601840-2019.log
-rw-r--r-- 1 fhem dialout 0 May 4 05:15 CUL_HOERMANN_3900800880-2019.log
-rw-r--r-- 1 fhem dialout 0 Aug 21 19:51 CUL_HOERMANN_4040132010-2019.log
-rw-r--r-- 1 fhem dialout 0 Apr 8 22:51 CUL_HOERMANN_4572881800-2019.log
-rw-r--r-- 1 fhem dialout 0 Mar 13 2019 CUL_HOERMANN_45C0480380-2019.log
-rw-r--r-- 1 fhem dialout 0 Sep 25 19:05 CUL_HOERMANN_503188F000-2019.log
-rw-r--r-- 1 fhem dialout 0 Mar 9 2019 CUL_HOERMANN_6B7EFFF5E0-2019.log
-rw-r--r-- 1 fhem dialout 0 Apr 6 2019 CUL_HOERMANN_7E808C1000-2019.log
-rw-r--r-- 1 fhem dialout 0 Apr 24 14:19 CUL_HOERMANN_8000000000-2019.log
-rw-r--r-- 1 fhem dialout 0 Mar 11 2019 CUL_HOERMANN_8060A61090-2019.log
-rw-r--r-- 1 fhem dialout 0 Aug 6 21:14 CUL_HOERMANN_8EF4708BA0-2019.log
-rw-r--r-- 1 fhem dialout 0 Mar 7 2019 CUL_HOERMANN_A000000000-2019.log
-rw-r--r-- 1 fhem dialout 0 Sep 10 21:20 CUL_HOERMANN_AC01C5E080-2019.log
-rw-r--r-- 1 fhem dialout 0 Apr 18 02:50 CUL_HOERMANN_B0228105C0-2019.log
-rw-r--r-- 1 fhem dialout 0 Mar 12 2019 CUL_HOERMANN_B0C8109120-2019.log
-rw-r--r-- 1 fhem dialout 0 Mar 24 2019 CUL_HOERMANN_B440050C00-2019.log
-rw-r--r-- 1 fhem dialout 0 Mar 12 2019 CUL_HOERMANN_D1CD000800-2019.log
-rw-r--r-- 1 fhem dialout 0 Apr 21 23:25 CUL_HOERMANN_E0F093A080-2019.log
-rw-r--r-- 1 fhem dialout 0 May 13 23:26 CUL_HOERMANN_F8401C0000-2019.log
-rw-r--r-- 1 fhem dialout 6384 Apr 1 2019 CUL_TX_2-2019.log
-rw-r--r-- 1 fhem dialout 1220744 Oct 6 13:26 CUL_TX_78-2019.log
-rw-r--r-- 1 fhem dialout 0 Feb 18 2019 CUL_WS_1-2019.log
-rw-r--r-- 1 fhem dialout 0 Jan 17 2019 CUL_WS_6-2019.log
-rw-r--r-- 1 fhem dialout 0 Nov 28 2018 CUL_WS_8-2018.log
-rw-r--r-- 1 fhem dialout 142 Aug 10 07:21 CUL_WS_8-2019.log
-rw-r--r-- 1 fhem dialout 79420 Oct 6 08:19 eventTypes.txt
-rw-r--r-- 1 fhem dialout 412104 Nov 30 2018 fhem-2018-11.log
-rw-r--r-- 1 fhem dialout 1455459 Dec 31 2018 fhem-2018-12.log
-rw-r--r-- 1 fhem dialout 2137397 Jan 31 2019 fhem-2019-01.log
-rw-r--r-- 1 fhem dialout 2996429 Feb 28 2019 fhem-2019-02.log
-rw-r--r-- 1 fhem dialout 149175323 Mar 31 2019 fhem-2019-03.log
-rw-r--r-- 1 fhem dialout 1600629 Apr 30 23:57 fhem-2019-04.log
-rw-r--r-- 1 fhem dialout 1828748 May 31 23:57 fhem-2019-05.log
-rw-r--r-- 1 fhem dialout 1872166 Jun 30 23:55 fhem-2019-06.log
-rw-r--r-- 1 fhem dialout 1883825 Jul 31 23:59 fhem-2019-07.log
-rw-r--r-- 1 fhem dialout 1732436 Aug 31 23:57 fhem-2019-08.log
-rw-r--r-- 1 fhem dialout 1781431 Sep 30 23:58 fhem-2019-09.log
-rw-r--r-- 1 fhem dialout 347098 Oct 6 13:34 fhem-2019-10.log
-rw-r--r-- 1 fhem dialout 93869 Oct 6 08:19 fhem.save
-rw-r--r-- 1 fhem dialout 151045 Dec 31 2018 FLUR_BEWEG_1-2018.log
-rw-r--r-- 1 fhem dialout 1376125 Oct 6 13:28 FLUR_BEWEG_1-2019.log
-rw-r--r-- 1 fhem dialout 0 Jul 6 09:01 FS20_114a7f-2019.log
-rw-r--r-- 1 fhem dialout 0 Jul 20 04:27 FS20_8e4f46-2019.log
-rw-r--r-- 1 fhem dialout 0 Mar 7 2019 FS20_bbe139-2019.log
-rw-r--r-- 1 fhem dialout 3168 Oct 6 08:20 GONG_FLUR-2019.log
-rw-r--r-- 1 fhem dialout 280 Jul 24 21:48 HM_544B10-2019.log
-rw-r--r-- 1 fhem dialout 1428 Jan 13 2019 HM_62FAC4-2019.log
-rw-r--r-- 1 fhem dialout 0 Mar 29 2019 HMS_0725-2019.log
-rw-r--r-- 1 fhem dialout 1026 Sep 25 16:02 HMS100TF_0000-2019.log
-rw-r--r-- 1 fhem dialout 0 Dec 13 2018 IT_00000000-2018.log
-rw-r--r-- 1 fhem dialout 0 Jan 1 2019 IT_00000000-2019.log
-rw-r--r-- 1 fhem dialout 38 Dec 16 2018 IT_000F000F0F-2018.log
-rw-r--r-- 1 fhem dialout 526 Aug 2 23:10 IT_000F000F0F-2019.log
-rw-r--r-- 1 fhem dialout 851 Jul 15 16:08 IT_1527x0a7f0-2019.log
-rw-r--r-- 1 fhem dialout 446 Dec 27 2018 IT_1527x6a17d-2018.log
-rw-r--r-- 1 fhem dialout 4701 Oct 6 12:31 IT_1527x6a17d-2019.log
-rw-r--r-- 1 fhem dialout 4157 Dec 28 2018 IT_V3_33177ac0-2018.log
-rw-r--r-- 1 fhem dialout 5048 Feb 25 2019 IT_V3_33177ac0-2019.log
-rw-r--r-- 1 fhem dialout 6589278 Dec 31 2018 KIND_HEIZUNG_1-2018.log
-rw-r--r-- 1 fhem dialout 47298915 Oct 6 13:36 KIND_HEIZUNG_1-2019.log
-rw-r--r-- 1 fhem dialout 6580802 Dec 31 2018 KIND_HEIZUNG_2-2018.log
-rw-r--r-- 1 fhem dialout 47181262 Oct 6 13:35 KIND_HEIZUNG_2-2019.log
-rw-r--r-- 1 fhem dialout 54981 Oct 6 08:20 Steckdose_PC-2019.log
-rw-r--r-- 1 fhem dialout 6469692 Dec 31 2018 WOH_HEIZUNG_1-2018.log
-rw-r--r-- 1 fhem dialout 46831287 Oct 6 13:34 WOH_HEIZUNG_1-2019.log
-rw-r--r-- 1 fhem dialout 6466019 Dec 31 2018 WOH_HEIZUNG_2-2018.log
-rw-r--r-- 1 fhem dialout 46448566 Oct 6 13:36 WOH_HEIZUNG_2-2019.log
-rw-r--r-- 1 fhem dialout 6458541 Dec 31 2018 WOH_HEIZUNG_3-2018.log
-rw-r--r-- 1 fhem dialout 46466661 Oct 6 13:35 WOH_HEIZUNG_3-2019.log
-rw-r--r-- 1 fhem dialout 0 Dec 19 2018 WOH_HEIZUNG_3_Clima_FileLog_1.log
-rw-r--r-- 1 fhem dialout 172969 Oct 6 00:46 WOH_SCHALTER_1-2019.log
-rw-r--r-- 1 fhem dialout 211048 Oct 6 12:24 WOH_TUERSENSOR_FileLog_1.log
Wie kann ich sehe bzw. beeinflussen, wie bzw. wann immer aufgezeichnet wird?
Habe gerade gelesen, dass man bei DbLog Indizes erstellt werden können, welche einfluß auf die Performance der Datenbank haben. Evlt. sollte ich das mal versuchen. Habe aber noch keine Ahnung wir, ob es einen Nachteil hat und ob es nur auf alte Werte einfluss habe oder auch neu hinzukommende.
Wieviele Plots hast du denn auf den Seiten die "langsam" gehen?
Schaue doch mal im Eventmonitor (mit Filter auf eines der "betroffenen" Geräte) was da so los ist.
Hast du nun event-on-change-reading in Verwendung?
EDIT4: zumindest bei den geposteten nicht...
Wie geschrieben weiß ich nicht wie man bei LogDB rausbekommt wieviel geloggt wird bzw. wie groß die Datenmenge ist.
Aber auch dort gilt (wohl) jeder Event der vom Device kommt (und in die Regex [wenn es sowas bei LogDB gibt] passt) wird wohl in die Datenbank geschrieben.
Wenn viele Werte drin sind, evtl. sogar welche die gar nicht "interessieren" (weil diese nicht genutzt werden z.B. nicht in Plots auftauchen etc.) dann dauert es nat. lange diese zu lesen, auszuwerten (evtl. unnötige Daten zu verwerfen) und darzustellen...
Wie geschrieben: wenn alles eigentlich gut/schnell/flüssig geht und "nur" Seiten mit (vielen) Plots langsam sind, dann eben mal die "Datensammlung" optimieren...
Was ich so vom Lesen kenne: LogExclude/LogInclude etc. und halt event-on-change-reading etc.
Wenn fhem generell langsam ist, dann auch im Eventmonitor mal schauen was dort so an Events durch das System "huscht" und prüfen, ob du die wirklich alle brauchst.
Wenn du Events weder Loggen willst, noch mit Notify/DOIF/... darauf reagieren willst, um etwas zu tun/auszulösen, dann: "weg damit"! ;)
(event-on-change-reading und "Derivate")
EDIT: die Anzahl der Logs ist (vermutlich) erst mal nicht das Problem. Sondern eher: wieviele Daten stehen jeweils drin und von wievielen Daten machst du (gleichzeitig/auf einer Seite) Plots und wieviele Daten in den Logs sind "nutzlos" (weil nie jemals verwendet für Plots etc.). Wenn du Logs gar nicht willst: Log-Device löschen ODER deaktivieren (attr disable). Aber ich dachte gesehen zu haben, dass du LogDB verwendest? Oder beides (und weißt es gar nicht so genau)?
EDIT2: es gibt auch bzgl. Darstellung/Aufbau von Plots einige Einstellungen. Plotfork (glaube ich heißt das) und "Derivate". Vielleicht auch da mal nachlesen...
EDIT3: wozu schreibst du eigentlich die Temperatur noch mal (alle Minute!?) in einen virtuellen Sensor? Welche Daten nimmst du nun für den Plot? Den des virtuellen Sensors? Das können dann ganz schön (unnötig) viele Daten sein... Evtl. mal drauf achten was du alles in welchen Zeitabständen wohin schreibst. Nutze doch mal event-on-change-reading (evtl. mit min-interval, damit die Plots nicht so "eckig" werden) und warum schreibst du die Daten mittels "at" und nicht mittels "notify" (also nur, wenn sich auch etwas geändert hat)... Das sind lauter Dinge, die nat. das System (unnötig) belasten, weil es muss ja bearbeitet werden und wenn du Seiten mit Plots anzeigst eben auch die gesammelten Daten bearbeitet werden...
Gruß, Joachim
Vielen Dank erstmal für die ausführlichen Antworten.
Und vor allem auch Umfangreiche; da muss ich mich jetzt erst mal durcharbeiten und vorher noch ein paar Mal lesen.
Kann mir aber jetzt vorstellen, dass bei mir viel zu viel aufgezeichnet wird, was man gar nicht braucht.
Beim bereits gezeigten Raum "Kinderzimmer" sind z.B. zwei verschiedene logs. Einer mit Temperatur und Feuchtigkeit und der andere mit absoluter Luftfeuchtigkeit und Taupunkt.
Evlt. würde ich mich aber nochmal melden.
Danke und schönen Sonntag noch.
Klar, kein Thema...
Lieber nachlesen und prüfen und in Ruhe machen, nicht dass dann am Ende wichtige Daten fehlen... ;)
Viel Erfolg, Joachim
Hallo zusammen,
ich habe gesehen, dass du DbLog im synchronen Modus betriebst. In diesem Modus wirkt sich jede Performanceschwäche der Datenbank direkt auf dein FHEM aus.
Am Besten DbLog zunächst auf asynchron (asyncMode=1) umstellen, dann die Attribute showNotifyTime und showproctime im DbLog setzen um die Reaktionszeiten der DB zu sehen und ein "set ... configCheck" im DbLog ausführen.
Dann sieht man eventuelle grundlegende Schwächen.
Mit listCache siehst du wieviele Events sich im Cache ansammeln um in die DB geschrieben zu werden. Indexe kannst du recht komfortabel mit einem DbRep-Device erstellen und noch mehr.
Grüße,
Heiko
Ich denke hier liegt einiges im argen.
Habe mir jetzt die DbLog Datenbank mit ssh angesehen.
Hier werden tatsächlich auch die Daten aus dem virtuellen Sensoren mit geloggt. Und noch einiges "unnützes" mehr.
Aber wie kann ich das verhindern. habe mit folgenden Befehl die Daten eingrenzen wollen. Leider kommen diese readings auch in anderen Devices vor; wie z.B. auch im virtuellen Sensor. Wie mache ich es, dass nur bestimmte Geräte geloggt werden?
Vor allem nicht die virtuellen.
define DbLog DbLog ./db.conf .*:(temperature|humidity|dewpoint|absFeuchte|pressure|state|open|closed|on|off|water|ValvePosition).*
Ist das richtig, dass unter dem Device DbLog bei
Probably associated with
SVG_DbLog_1
SVG_DbLog_2
usw. (bis SVG_DbLog_15)
angezeigt wird?
Dachte es wird alles in der einen Datenbank fhem.db gespeichert und ist somit die einzige?
@DS_Starter
habe die Einstellungen gemacht.
Folgendes wird mit set ... configCheck angezeigt:
Result of DbLog version check
Used DbLog version: 3.13.1
Recommendation: Your running version may be the current one. Please check for updates of DbLog periodically.
Result of configuration read check
Connection parameter store type: file
Connection parameter: Connection -> SQLite:dbname=/opt/fhem/fhem.db, User -> , Password -> read o.k.
Result of connection check
Connection to database /opt/fhem/fhem.db successfully done.
Recommendation: settings o.k.
Result of encoding check
Encoding used by DB /opt/fhem/fhem.db: UTF-8
Recommendation: This is only an information about text encoding used by the main database.
Result of logmode check
Logmode of DbLog-device DbLog is: asynchronous
Recommendation: settings o.k.
Result of shutdown sequence preparation check
Attribute "shutdownWait" is set to:
Recommendation: Please set this attribute at least to 2 seconds to avoid data loss when system shutdown is initiated.
Result of plot generation method check
WARNING - at least one of your FHEMWEB devices have attribute "plotfork = 1" not set. This may cause blocking situations when creating plots.
WEB: plotfork=0
Recommendation: You should set attribute "plotfork = 1" in relevant devices
Result of table 'history' check
Column width set in DB /opt/fhem/fhem.db.history: 'DEVICE' = 32, 'TYPE' = 32, 'EVENT' = 512, 'READING' = 32, 'VALUE' = 64, 'UNIT' = 32
Column width used by DbLog: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Recommendation: WARNING - The relation between column width in table history and the field width used by device DbLog should be equal but it differs.The field width used by DbLog can be adjusted by setting attributes 'colEvent', 'colReading', 'colValue'. (pls. refer to commandref)Because you use SQLite this is only a warning. Normally the database can handle these differences.
Result of table 'current' check
Column width set in DB /opt/fhem/fhem.db.current: 'DEVICE' = 32, 'TYPE' = 32, 'EVENT' = 512, 'READING' = 32, 'VALUE' = 64, 'UNIT' = 32
Column width used by DbLog: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Recommendation: WARNING - The relation between column width in table current and the field width used by device DbLog should be equal but it differs. The field width used by DbLog can be adjusted by setting attributes 'colEvent', 'colReading', 'colValue'. (pls. refer to commandref)Because you use SQLite this is only a warning. Normally the database can handle these differences.
Result of check 'Search_Idx' availability
The index 'Search_Idx' is missing.
Recommendation: You can create the index by executing statement 'CREATE INDEX Search_Idx ON `history` (DEVICE, READING, TIMESTAMP)'
Depending on your database size this command may running a long time.
Please make sure the device 'DbLog' is operating in asynchronous mode to avoid FHEM from blocking when creating the index.
Note: If you have just created another index which covers the same fields and order as suggested (e.g. a primary key) you don't need to create the 'Search_Idx' as well !
Result of check 'Report_Idx' availability for DbRep-devices
No DbRep-device assigned to DbLog is used. Hence an index for DbRep isn't needed.
Recommendation: settings o.k.
Das zeigt listCache:
49 => 2019-10-06 22:30:07|WOH_HEIZUNG_3_Clima|CUL_HM|ValvePosition: 0|ValvePosition|0|
50 => 2019-10-06 22:30:07|WOH_HEIZUNG_3_Clima|CUL_HM|state: T: 21.4 desired: 21.0 valve: 0|state|T: 21.4 desired: 21.0 valve: 0|
51 => 2019-10-06 22:30:07|WOH_HEIZUNG_3_Weather|CUL_HM|state: 21.4|state|21.4|
52 => 2019-10-06 22:30:08|presence.karsten|PRESENCE|state: present|state|present|
53 => 2019-10-06 22:30:08|presence.susi|PRESENCE|state: present|state|present|
54 => 2019-10-06 22:30:09|KIND_HEIZUNG_1_Clima|CUL_HM|ValvePosition: 0|ValvePosition|0|
55 => 2019-10-06 22:30:09|KIND_HEIZUNG_1_Clima|CUL_HM|state: T: 20.5 desired: 20.0 valve: 0|state|T: 20.5 desired: 20.0 valve: 0|
56 => 2019-10-06 22:30:09|KIND_HEIZUNG_1_Weather|CUL_HM|state: 20.5|state|20.5|
57 => 2019-10-06 22:30:18|WOH_HEIZUNG_2_Clima|CUL_HM|ValvePosition: 0|ValvePosition|0|
58 => 2019-10-06 22:30:18|WOH_HEIZUNG_2_Clima|CUL_HM|state: T: 21.4 desired: 21.0 valve: 0|state|T: 21.4 desired: 21.0 valve: 0|
59 => 2019-10-06 22:30:18|WOH_HEIZUNG_2_Weather|CUL_HM|state: 21.4|state|21.4|
Da ist ein bisschen was zu richten, aber heute nicht mehr.
Wir können morgen weiter optimieren. Vllt. hat MadMax-FHEM noch etwas Zeit ...
ZitatProbably associated with ...
Dort taucht jedes Device auf welches FHEM meint mit dem DbLog-Device evtl. assoziiert zu sein.
Ist für die Funktion unwesentlich.
Grüße,
Heiko
Aber mach ein Update, DbLog ist zu alt.
Zitat von: DS_Starter am 06 Oktober 2019, 22:52:26
Da ist ein bisschen was zu richten, aber heute nicht mehr.
Wir können morgen weiter optimieren. Vllt. hat MadMax-FHEM noch etwas Zeit ...
Leider heute nicht mehr...
...und auch die restl. Woche weiß ich noch nicht, bin dienstl. unterwegs...
Aber das meiste was ich so beitragen kann hab ich erst mal genannt...
Klar bei gezielten Fragen gibt's Hilfe (wenn ich Zeit hab)...
Bzgl. DB kann ich eh nichts beitragen, ich nutze FileLog...
Gruß, Joachim
Danke schon mal euch beiden für die Hilfe.
Evlt. ist ja morgen etwas Zeit dafür, oder die nächsten Tage.
Also kann man hier noch etwas retten ohne neu zu installieren?
Läuft ja nichts davon, so langsam wie es ist ;)
Gruß
Ruggy
Bzgl. der Dinge: reduzieren von Events (und [damit] Logeinträgen) und evtl. optimieren beim Plotanzeigen kann das jederzeit (und immer wieder) getan/verbessert werden...
Ich mache das auch hin und wieder: Eventmonitor öffnen und schauen was da so durchläuft und prüfen, ob ich die Events alle brauche (Logeinträge, Reaktion mittels notif/DOIF etc. wenn nicht versuche ich das abzustellen/einzuschränken)...
Viel Erfolg, Joachim
Die Logeinträge zu reduzieren hört sich vernünftig an. Habe aber leider noch nichts gefunden, wie ich einzelne devices ausschließen kann oder nur bestimmte Devices loggen kann.
Evlt. weiß hierzu DS_Starter morgen etwas.
Weiß jetzt auch nicht mehr sicher aus welchem Grund bzw. für was ich "state" und "ValvePosition" loggen will.
Das letzte wird vom Thermostat sein. Aber eigenlich bräuchte ich wahrscheinlich das nicht.
Benötigt man DbLog eigentlich noch für etwas anderes oder "nur" um Plots grafisch anzeigen zu können?
ZitatHabe aber leider noch nichts gefunden, wie ich einzelne devices ausschließen kann oder nur bestimmte Devices loggen kann.
Es gibt verschiedene Möglichkeiten. Die Beschränkung im DEF wie bei Filelog, aber auch über die Attribute DbLogInclude oder
DbLogExclude in den Quelldevices. Dazu unbedingt das Attribut DbLogSelectionMode im DbLog beachten.
Ich empfehle dringend die commadref zu DbLog durchzulesen um zu verstehen wie was arbeitet.
Für den Anfang ist vermutlich am einfachsten direkt im DEF (Regex) die Einschränkung vorzunehmen. z.B.:
define DbLog DbLog ./db.conf (<device>:temperature|<device>:humidity|<device>:dewpoint|<device>:absFeuchte|<device>:pressure|<device>:open|<device>:closed|<device>:ValvePosition)ZitatBenötigt man DbLog eigentlich noch für etwas anderes oder "nur" um Plots grafisch anzeigen zu können?
Um einfach nur Plots anzuzeigen kann man FileLog und DbLog gleichermaßen verwenden. Wenn man viele Daten auch über längere Zeit speichern will, bietet sich DbLog an. Ebenfalls für weitere Auswertungen (siehe DbRep) und das relative einfache Datenmanagement, wie das (selektive) Löschen von Daten die man nicht mehr braucht oder das Ausdünnen um nur Wichtiges zu behalten oder,oder ...
DbLog hat viele Vorteile, aber auch Nachteile. So sollte man sich ein bisschen mit Datenbanken beschäftigen, speziell sich auch um ein Backupkonzept Gedanken machen.
Und meistens braucht eine DB auch entsprechend leistungsfähige Hardware, wobei SQLite dabei sehr genügsam ist gegenüber "richtigen" DB-Systemen wie MySQL und PostgreSQL.
Jetzt zu deinem System. Hast du ein Update gemacht ? Wenn noch nicht, bitte machen.
WEB: plotfork=0
Recommendation: You should set attribute "plotfork = 1" in relevant devices
Für die Schreibperformance ist das Attr asyncMode wichtig. Für die Erstellung der SVGs ist plotfork = 1 im deinem WEB Device wichtig. Wenn plotfork = 1 gesetzt ist, werden die SVG-Daten aus der DB in einem Nebenprozess gelesen was die Performance unabhängig von der DB-Schnelligkeit macht.
Dazu auch das Attr plotEmbed im WEB beachten !
Column width set in DB /opt/fhem/fhem.db.history: 'DEVICE' = 32, 'TYPE' = 32, 'EVENT' = 512, 'READING' = 32, 'VALUE' = 64, 'UNIT' = 32
Column width used by DbLog: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Recommendation: WARNING - The relation between column width in table history and the field width used by device DbLog should be equal but it differs.The field width used by DbLog can be adjusted by setting attributes 'colEvent', 'colReading', 'colValue'. (pls. refer to commandref)Because you use SQLite this is only a warning. Normally the database can handle these differences.
Das ist im Umfeld SQLite eher eine Warnung. Hast vermutlich nicht das aktuellste Script zur Erstellung der DB verwendet. Der Link zum aktuellen Script ist in der Commandref zu DbLog angegeben. Wenn es sich anbietet, löscht du DB nochmal und erstellst sie neu. Ist aber ein "kann".
The index 'Search_Idx' is missing.
Recommendation: You can create the index by executing statement 'CREATE INDEX Search_Idx ON `history` (DEVICE, READING, TIMESTAMP)'
Das ist ganz bitter. Ohne Index wird deine DB nicht vernünftig laufen !
Du kannst den Index über die Befehlszeile anlegen oder benutzt ein angelegtes DbRep-Device dazu:
set <dbrep> index recreate_Search_IdxWenn du das alles gemacht hast, nochmal ein configCheck ausführen.
Unnütze DB-Einträge von Devices oder Readings wirst du mit den entsprechnden Befehlen in einem DbRep-Device einfach wieder los.
Grüße,
Heiko
Update habe ich gestern noch gemacht.
Hat aber keine spürbare Verbesserung gebracht.
Eine Einschränkung für jedes device wird evlt. unübersichtlich aber ist wahrscheinlich die sicherste Methode. Müsste also bei define für jeden Sensor alle benötigten Werte einzeln zum loggen befehlen?
Habe den Hinweis von MadMax-FHEM bzgl. event-on-change-reading gestern irgendwie ein paar Mal überlesen. Ist bestimmt auch sinnvoll. Muss ich dies bei jedem Sensor setzen?
Habe jetzt gerade plotfork = 1 gesetzt und den index erstellt.
;D-> ist der Wahnsinn wie schnell es jetzt ist. So schnell war es glaube ich noch nie ;D
Das gefällt mir schon mal sehr gut. Danke ;D ;D
Bedeutet dies, dass die "bremse" meine schlechte Datenbank war?
Wird der Index ab jetzt immer automatisch erstellt oder muss ich diesen hin und wieder manuell erstellen?
Die anderen vorgeschlagenen Dinge habe ich noch nicht gemacht, weil ich manches noch nicht verstehe wie ich es machen muss.
Werde mich darüber machen.
Das DbRep-Device muss ich erst mal Verstehen. Muss man anscheinend erst erstellen bzw. anlegen?
Das sagt configCheck
Result of version check
Used Perl version: 5.24.1
Used DBI (Database independent interface) version: 1.636
Used DBD (Database driver) version SQLite: 1.54
Used DbLog version: 4.7.4.
Your local DbLog module is up to date.
Recommendation: No update of DbLog is needed.
Result of configuration read check
Connection parameter store type: file
Connection parameter: Connection -> SQLite:dbname=/opt/fhem/fhem.db, User -> , Password -> read o.k.
Result of connection check
Connection to database /opt/fhem/fhem.db successfully done.
Recommendation: settings o.k.
Result of encoding check
Encoding used by DB /opt/fhem/fhem.db: UTF-8
Recommendation: This is only an information about text encoding used by the main database.
Result of logmode check
Logmode of DbLog-device DbLog is: asynchronous
Recommendation: settings o.k.
Result of plot generation method check
WEB: plotfork=1
Recommendation: settings o.k.
Result of table 'history' check
Column width set in DB history: 'DEVICE' = 32, 'TYPE' = 32, 'EVENT' = 512, 'READING' = 32, 'VALUE' = 64, 'UNIT' = 32
Column width used by DbLog: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Recommendation: WARNING - The relation between column width in table history and the field width used by device DbLog should be equal but it differs.The field width used by DbLog can be adjusted by setting attributes 'colEvent', 'colReading', 'colValue'. (pls. refer to commandref)Because you use SQLite this is only a warning. Normally the database can handle these differences.
Result of table 'current' check
Column width set in DB current: 'DEVICE' = 32, 'TYPE' = 32, 'EVENT' = 512, 'READING' = 32, 'VALUE' = 64, 'UNIT' = 32
Column width used by DbLog: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Recommendation: WARNING - The relation between column width in table current and the field width used by device DbLog should be equal but it differs. The field width used by DbLog can be adjusted by setting attributes 'colEvent', 'colReading', 'colValue'. (pls. refer to commandref)Because you use SQLite this is only a warning. Normally the database can handle these differences.
Result of check 'Search_Idx' availability
The index 'Search_Idx' is missing.
Recommendation: You can create the index by executing statement 'CREATE INDEX Search_Idx ON `history` (DEVICE, READING, TIMESTAMP)'
Depending on your database size this command may running a long time.
Please make sure the device 'DbLog' is operating in asynchronous mode to avoid FHEM from blocking when creating the index.
Note: If you have just created another index which covers the same fields and order as suggested (e.g. a primary key) you don't need to create the 'Search_Idx' as well !
Result of check 'Report_Idx' availability for DbRep-devices
No DbRep-device assigned to DbLog is used. Hence an index for DbRep isn't needed.
Recommendation: settings o.k.
event-on-change-reading (und "Derivate") dämmen generell die "Flut" von Events ein...
D.h. das System muss generell weniger tun und ja: bei jedem Sensor (im Prinzip / allerdings reicht es [erst mal] bei den "Geschwätzigsten" -> Eventmonitor / es gibt auch die Möglichkeit sich durch DOIF-Tools Events pro Device "zählen" zu lassen)
Wichtig ist halt die Einschränkung so zu machen, dass nur unnötige Events wegfallen...
Und wie bereits geschrieben: da kann man immer wieder mal ran und optimieren...
Wichtig ist dabei: genau lesen!
Bzw. immer mal einen Blick in den Eventmonitor um zu sehen, ob "wichtige" Events noch kommen (oder plötzlich "weg" sind)...
Gruß, Joachim
ZitatUpdate habe ich gestern noch gemacht.
Hat aber keine spürbare Verbesserung gebracht.
Das ist klar. Es sollte nur aktuell sein. (auch wegen configCheck) ;)
ZitatHabe den Hinweis von MadMax-FHEM bzgl. event-on-change-reading gestern irgendwie ein paar Mal überlesen. Ist bestimmt auch sinnvoll. Muss ich dies bei jedem Sensor setzen?
Ist sinnvoll, wie Joachim schon schrieb. Musst du in jedem Device bzw. Reading setzen wo du es haben willst.
Aber hier nochmal der Hinweis, es gibt den "DbLogSelectionMode = Include" -Modus ! In dem Modus wird überhaupt nichts geloggt außer das was man explizit über DbLogInclude in den Quelldevices freigibt.
Ich kann verstehen, dass du erstmal heiß auf Ergebnisse bist, aber unbedingt commandref lesen !! :)
ZitatHabe jetzt gerade plotfork = 1 gesetzt und den index erstellt.
;D-> ist der Wahnsinn wie schnell es jetzt ist. So schnell war es glaube ich noch nie ;D
Das gefällt mir schon mal sehr gut. Danke ;D ;D
Bedeutet dies, dass die "bremse" meine schlechte Datenbank war?
Sehr gut. :D ... Und ja, an der richtigen Einstellung der DB bzw. dem Gesamtwerk lag es. Eine DB ist nicht nur ein File. Und eine DB ist für "Massendaten" gemacht, will damit sagen dass es normalerweise nicht auf ein paar tausend Datensätze mehr oder weniger ankommt. Dafür ist diese Technik gemacht. Den "configCheck" kann man immer mal wiederholen.
ZitatWird der Index ab jetzt immer automatisch erstellt oder muss ich diesen hin und wieder manuell erstellen?
Im Normalfall braucht man den Index in useren Fällen nicht nochmal erstellen. Aber selbst das geht mit einem DbRep-Befehl sehr einfach.
Zitat
Das sagt configCheck:
....
The index 'Search_Idx' is missing.
.....
Das wundert mich allerdings. War die Indexerstellung noch nicht durch oder hast du den check vorher gemacht ?
Zitat
Das DbRep-Device muss ich erst mal Verstehen. Muss man anscheinend erst erstellen bzw. anlegen?
Ja, musst du einfach definieren. Im Wiki findest du auch jede Menge Infos und Hilfe: https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten
Denke auch an ein Backup deiner DB ! Auch dafür gibts Befehle im DbRep.
bzgl. The index 'Search_Idx' is missing habe ich wie im wiki-fhem zu DbLog und dort bei "Erstellung von Indizes" beschrieben folgenden Befehl (in der fhem.db) ausgeführt:
create index idx_device_reading_timestamp on history (device, reading, timestamp);
War das nicht richtig?
Folgender Befehl zeigte bei mir keine Reaktion.
set <dbrep> index recreate_Search_Idx
ein aktuelles config Check zeigt immer noch "The index 'Search_Idx' is missing" an.
ZitatWar das nicht richtig?
Nicht direkt. Der Name ist falsch und wird nicht gefunden.
ZitatFolgender Befehl zeigte bei mir keine Reaktion.
Der Befehl läuft eine Weile je nach Größe der DB.
Schreibt in status und Logfile.
Was schreibt DbRep denn aus mit:
set .... index list_all?
Müßte etwa so aussehen:
background_processing_time
0.0094
2019-10-07 23:19:14
index_state
Index found in database:
========================
Table: history, Idx: Search_Idx, Col: DEVICE, READING, TIMESTAMP
2019-10-07 23:19:14
sql_processing_time
0.0043
2019-10-07 23:19:14
state
done
2019-10-07 23:19:14
EDIT: Hinweis, bei DbRep immer mal die Browserseite refreshen.