Hallo zusammen,
vor kurzem habe ich mir die Netatmo Wetterstation inkl. Regensensor gekauft und in FHEM integriert. Diesbezüglich funktioniert auch alles, wie es soll. Allerdings ist das Webfrontend von FHEM seitdem sehr langsam geworden. Nach einem shutdown restart dauert es z.B. 2-3 Minuten, bis das Webfrontend wieder erreichbar ist. Zwischendurch friert das Frontend auch gerne mal ein und ich bekomme vom Browser eine Timeout Fehlerseite präsentiert. Auch meine iOS App (FHEM APP) funktioniert zeitweise dann nicht mehr. Wenn ich ein Apptime ausführe, ist der Übeltäter auch schnell gefunden:
name function max count total average maxDly
tmr-netatmo_poll HASH(0x373bfe0) 30044 4 75130 18782.50 8 HASH(netatmo.aussen)
tmr-netatmo_poll HASH(0x36c3280) 20029 4 53073 13268.25 17167 HASH(netatmo.regen)
tmr-netatmo_poll HASH(0x373bb30) 10018 4 27039 6759.75 15958 HASH(netatmo.wohnzimmer)
WEB FW_Read 4033 148 61191 413.45 0 HASH(WEB)
hmusb HMLAN_Read 122 135 2020 14.96 0 HASH(hmusb)
tmr-Weather_GetUpdateTimer HASH(0x34117d0) 43 2 65 32.50 5 HASH(WetterMS)
KuSpuelmaschineWattSet notify_Exec 40 9 347 38.56 0 HASH(KuSpuelmaschineWattSet); HASH(Ku.Spuelmaschine_Power)
BZWaschmaschineWattSet notify_Exec 30 10 159 15.90 0 HASH(BZWaschmaschineWattSet); HASH(BZ.Waschmaschine_Power)
FileLog_BZ.Waschmaschine_Power FileLog_Get 25 1 25 25.00 0 HASH(FileLog_BZ.Waschmaschine_Power); FileLog_BZ.Waschmaschine_Power; CURRENT; INT; 2015-07-28_00:00:00; 2015-07-29_00:00:01; 4:RegExp::
tmr-HUEBridge_GetUpdate HASH(0x25a2ac8) 23 4 91 22.75 3602 HASH(WZ.HUEBridge)
tmr-at_Exec HASH(0x1d8b868) 21 23 438 19.04 15033 HASH(fhem_heartbeat)
tmr-HUEDevice_GetUpdate HASH(0x2272370) 19 22 325 14.77 25940 HASH(WZ.HUEBridge_HUEDevice1)
tmr-HUEDevice_GetUpdate HASH(0x26d8950) 19 22 296 13.45 25930 HASH(WZ.HUEBridge_HUEDevice2)
FHEMWEB:192.168.2.102:54637 FW_Read 12 9 21 2.33 0 HASH(FHEMWEB:192.168.2.102:54637)
tmr-FW_closeInactiveClients 5 22 10 0.45 25919
BZ.WaschmaschineWatt dummy_Set 4 35 75 2.14 0 HASH(BZ.WaschmaschineWatt); BZ.WaschmaschineWatt; 0.08
tmr-CUL_HM_ActCheck ActionDetector 3 2 6 3.00 1 ActionDetector
BZWaschmaschineBetriebAn notify_Exec 2 10 11 1.10 0 HASH(BZWaschmaschineBetriebAn); HASH(BZ.Waschmaschine_Power)
BZWaschmaschineHoherVerbrauchAn notify_Exec 2 10 9 0.90 0 HASH(BZWaschmaschineHoherVerbrauchAn); HASH(BZ.Waschmaschine_Power)
BZWaschmaschineHoherVerbrauchAus notify_Exec 2 10 9 0.90 0 HASH(BZWaschmaschineHoherVerbrauchAus); HASH(BZ.Waschmaschine_Power)
Ku.SpuelmaschineWatt dummy_Set 2 81 162 2.00 0 HASH(Ku.SpuelmaschineWatt); Ku.SpuelmaschineWatt; 0
Habt ihre eine Idee, warum das Pollen der Netatmo Daten den FHEM Server so in die Knie zwingt? Was kann ich tun, um den aktuellen Zustand zu verbessern?
Danke für die Hilfe!!
Gruß
Daniel
was hast du als Intervall angegeben? hast du gewartet bis die historischen Werte abgeholt sind?
gruß
andre
Als Intervall habe ich 300 definiert. Das Modul ist seit über einer Woche im Einsatz. Da sollten die historischen Werte mittlerweile da sein, oder muss ich da noch etwas für tun?
Das hängt erfahrungsgemäß mit zwei Sachen zusammen:
- die Netatmo Werte werden schubweise abgeholt. Es kann vorkommen, dass bei kurzen Abfrageintervallen die API oft sperrt und nach deren erneuter Verfügbarkeit die Abfrage dann z.B. Werte von einem halben Tag (oder mehr) in FHEM als Events einliest.
- vor allem beim Einsatz von DBLog zum loggen der Werte wird dies dann problematisch. Schau mal bei dir in der Linux Prozessansicht auf die Auslastung deiner MySQL Datenbank. Die ist bei mir da in der Regel extrem hoch und blockiert dann den FHEM Prozess indirekt.
Ich habe dasselbe Problem. Sehr lange Lsufzeit beim Updaten, was dann in der Zeit FHEM lahmlegt und dafür sorgt, dass HmLan dauernd neu connected werden muss.
Habt Ihr eine Lösung dafür gefunden?
Grüße Matthias