Hallo Comunity,
ich habe festgestellt dass, wenn der FHEM-Server einige Tage läuft die Belastung des Arbeitsspeichers vom FHEM-Host ansteigt.
Nach einigen Tagen Laufzeit habe ich aktuell 54% Arbeitsspeicher nutzung durch FHEM.
Das Host System ist eine Synology DS716+ii mit ActivePerl 5.24 und aktuell noch 2GB RAM
Gibt es eine möglichkeit mit Bordmitteln herauszufinden wie lange FHEM schon läuft?
Gibt es eine möglichkeit zu sehen welche Informationen der FHEM-Server in den Arbeitsspeicher legt?
Sooo groß ist FHEM noch nicht - aber vielleicht wird es schwierig weil module im Einsatz sind die nicht so weit verbreitet sind (ModbusTCP von ChrisD)
Spontan würde ich sagen das es kein großes Problem ist, ich könnte ja FHEM ja einmal wöchentlich neustarten z.b. ich würde aber lieber der sache auf den Grund gehen.
Hat jemand eine Idee was ich tun kann?
Danke schonmal....
System Info
ConfigType: configFile
SVN rev: 15292
OS: linux
Perl: 5.24.2
uniqueId: b6f...
Modules Model Count
DOIF 3
FHEM2FHEM 1
FHEMWEB 3
FileLog 1
ModbusCoil 35
ModbusRegister 26
ModbusTCPServer 1
PRESENCE
event 2
RESIDENTS 1
ROOMMATE 3
TelegramBot 1
Unifi 1
cloneDummy 3
dummy 1
harmony 8
notify 2
readingsGroup 1
telnet 1
ZitatGibt es eine möglichkeit mit Bordmitteln herauszufinden wie lange FHEM schon läuft?
der fhem befehl "uptime".
das problem verstehe ich noch nicht wirklich.
belegt fhem 50 prozent von 2gb, also 1gb?
oder ist allgemein der arbeitsspeicher zu 50 prozent belegt?
warum stört es dich, wenn der arbeitsspeicher benutzt wird?
htop zeigt das der fhem Prozess nach einigen Tagen etwa 50% in der Spalte MEM% erreicht.
Es stört mich nicht wirklich, es gibt auch kein problem mit FHEM es läuft alles sehr stabil, zuverlässig und angenehm performant...
Mir fällt einfach nur auf - das über einige Tage die auslagerung von FHEM in den Arbeitsspeicher größer wird. Ich möchte einfach vermeiden das FHEM nach ein paar Wochen laufzeit stehen bleibt, weil kein RAM mehr zur verfügung steht.
uptime kannte ich noch nicht - wenn man help eingibt bekommt man diesen befehl auch nicht angezeigt. fheminfo fehlt aber auch in dieser liste.
Die Diskstation hat soeben ein upgrade auf 8GB Speicher bekommen - mal schauen wie es sich damit verhält...
Warum definierst Du nicht ein Gerät mit SYSMON?
Hier lasse ich mir alle Systemwerte anzeigen.
Viele Grüße
Jürgen
Das würde ja auch nichts ändern - nur das ich nebenher per Terminal schauen müsste... Die Speicherauslastung wäre aber ja die gleiche....
Mich wundert nur das FHEM nach einer Woche laufzeit etwa 1GB Daten gesammelt hat.
Hi,
ich habe bisher einen ganz brauchbaren Debugger (perldebug) und Performance Profiler (nytprof) gefunden, aber Speicheranalyse ist wohl etwas schwieriger. Ich kann mir schon vorstellen, dass manche Module nach langer Laufzeit Probleme bekommen, insbesondere da der Garbage-Collector in Perl anscheinend ein einfaches Reference-Counting macht und daher keine Zyklen auflösen kann.
...auf jeden Fall ist das ein interessantes Thema.
Gruß,
Thorsten
Hallo,
Du kannst versuchen den Befehl 'fhemdebug memusage' zu benutzen. Dieser zeigt den Speicherverbrauch der internen Strukturen an. Am Besten ist es FHEM neu zu starten, kurz nach dem Start den Befehl einzugeben, die ausgegebenen Daten zu kopieren und abzuwarten bis der Speicherverbrauch merklich gestiegen ist. Anschließend den Befehl erneut eingeben und schauen bei welchen Zeilen es größere Unterschiede gibt.
Grüße,
ChrisD
Das fhem 1gb Speicher beim system anmeldet ist per se problemlos.
Generell arbeitet de facto alle Programme in etwa so: wenn ein prozess, auch vorübergehen, speicher benötigt dann fragt er beim system (os) an.
Das os gibt dem prozess den speicher, der macht was damit. Wenn der dann nicht mehr benötigt wird behält der prozess den speicher aber (er gibt ihn nicht an das os zurück) und merkt sich, intern, das er den speicher, intern, vergeben kann. Falls benötigt.
Das führt nach einer gewissen Laufzeit dazu das vermeintlich viel speicher "gebraucht" wird. Wenn Du irgendwann mal einen grossen logfile anschaust braucht fhem (- perl) dafür viel speicher. Den behält fhem (- perl) dann "für sich" - auch wenn der logfile schon lange "fertig" ist.
Man muss also untersuchen ob der Speicher immer weiter anwächst, dann passiert was Du sagst. Irgendwann ist er alle. Oder ob 1gb (plus minus) bleibt -> alles ok.
garbage collector: korrekt! Dies (Vereinfacht!!!):
$hash_a->{'chiild'} = $hash_b;
$hash_b->{'parent'} = $hash_a;
return;
gibt eine Leiche. Wenn $hash_b aus dem scope ist kommt man nicht ran. Da jedoch $hash_a auf $hash_b zeigt (und $hash_b auf $hash_a) leben die auf ewig weiter. Wenn das zb bei (häufigen) IO Operationen passiert kann sich das ganz schön summieren. Das Beispiel vereinfacht! Mit "weaken" kann man die auflösen, man muss aber beim programmieren darauf achten.
vg
joerg
Zitat von: herrmannj am 29 Oktober 2017, 00:40:55
Irgendwann ist er alle. Oder ob 1gb (plus minus) bleibt -> alles ok.
es ist auch ok wenn fhem (oder programm x) den ganzen Speicher für sich anmeldet solange das os selbst oder anderen Prozessen davon wieder was abzwacken könnebn wenn diese Speicher benötigen.
Konkret habe ich der DS716+ii ja gestern ein Speicherupgrade verpasst, der FHEM-Host verfügt also jetzt über 8GB Speicher.
Ich hätte auch kein problem damit FHEM einen großen Teil dieses Speichers zuzuweisen - grundsätzlich würde ich fhem eh gerne von den Festplatten fernhalten sodass die DiskStation auch mal die Festplatten herunterfahren kann. Vielleicht auf dem Weg DBLog Daten nur alle 12 Std. oder so wegzuschreiben. Logging ist aber noch nicht aktiv, ich scheitere zur Zeit beim einrichten der SQLite verbindung.
FHEM läuft nun seit dem Speicherupgrade:
Zitat1 day, 03:47:51
Zitat
0 [| 0.7%] Tasks: 81, 93 thr, 109 kthr; 1 running
1 [| 0.7%] Load average: 1.02 1.10 1.08
2 [| 1.3%] Uptime: 1 day, 03:50:25
3 [||||||| 7.9%]
Mem[|||||||||||||||||||| 724M/7.72G]
Swp[ 0K/6.63G]
PID PPID TGID NLWP USER PRI NI IO VIRT RES SHR S CPU CPU% MEM% DISK READ DISK WRITE TIME+ Command
11706 1 11706 1 fhem 20 0 B4 455M 400M 4888 S 0 8.5 5.1 0.00 B/s 0.00 B/s 2h47:05 /opt/ActivePerl-5.24/bin/perl /usr/local/fhem/opt/fhem.pl /
22863 22840 22863 1 root 20 0 B4 26804 2328 1372 R 2 2.0 0.0 0.00 B/s 0.00 B/s 0:07.75 htop
8362 1 8362 1 root 20 0 B4 220M 15892 10100 S 1 0.7 0.2 0.00 B/s 0.00 B/s 2:36.66 /usr/bin/snmpd -fLn -c /etc/snmp/snmpd.conf -p /var/run/snm
4083 1 4083 11 system 20 0 B4 944M 7512 4128 S 1 0.7 0.1 0.00 B
Ich habe herausgefunden das es einen großen einfluss auf die Prozesslast hat wenn ich den poll des WagoControllers verändere - der Poll ist nun so eingestellt das FHEM um 10% (+- 5%) pendelt
Bei der MEM% anzeige hat FHEM vom Neustart an 0.7%.
Gefühlt wächst dieser Wert stündlich um 0.1
Einmal habe ich zu 2GB zeiten die Speicherauslastung bis auf 80% hochlaufen lassen, hatte dann aber Energieversorger seitig einen Stromausfall.
@ChrisD: ich habe den befehl ausprobiert und bekomme eine Perl Meldung das ich das fehlende Modul Devel::Size brauche...
ZitatCan't locate Devel/Size.pm in @INC (you may need to install the Devel::Size module) (@INC contains: . /opt/ActivePerl-5.24/site/lib /opt/ActivePerl-5.24/lib ./FHEM) at (eval 55174) line 2.
BEGIN failed--compilation aborted at (eval 55174) line 2.
Werde mich mal bei ppm umschauen welche Module unter ActivePerl nun installiert werden müssen.
Ausserdem werde ich sysmon mal aktivieren um Plots zur CPU und RAM zur verfügung zu haben.
@herrmannj
zur Zeit ist FHEM hier noch nicht voll am werkeln - die komponenten werden nach und nach hinzugefügt, Logging und Plots laufen leider noch nicht - FHEM hat also aus dieser sicht nicht wirklich viel zu tun - manchmal lasse ich jedoch einen eventMonitor BrowserTab über 4-6 Std. laufen. Ich hoffe nun bald den Zustannd zu erreichen das FHEM mehr als 1GB Ram benötigt.
garbage collector sagt mir mal noch nix, aber das Forum spukt dazu was aus, ich schaue es mir mal an.
FHEM darf gerne VIEL Speicher benutzen, ich brauche hier ja nicht sparsam zu sein...
Eine gute Performance erwarte ich, deswegen habe ich ja auch etwas stärkere Hardware gewählt.
ZitatVielleicht auf dem Weg DBLog Daten nur alle 12 Std. oder so wegzuschreiben
Wenn du sicherstellen kannst dass zb kein Stromausfall die Daten löscht innerhalb der 12h. Der Speicher wird sicher nicht Batteriebuffered sein.
Generell wäre sicher auch keine 8gb nötig gewesen solange das von Synology hin gebogene OS sauber werkelt.
Etwas OT: Ich würde mir aber noch mal überlegen ob ich mit (FHEM-)Server seitig mit einer (in meinen Augen überteuerten NAS Lösung) künstlich beschränken will (Stichwort OS, Perl, Pakete, Treiber usw usw). Für die 400€(?) kann man sich locker einen Server (der auch als Nas fungiert) mit mehr bums bauen der im Stromverbrauch gleichwertig ist und man selber die Wahl des OS und der Software hat
Zur Synology kann ich nur sagen, das ich begeistert bin - DSM das Syno betriebssystem arbeitet sauber, letztendlich hat mich Andre bei der entscheidung Hardware zu kaufen ein bisschen unterstüzt.
Ich habe natürlich auch darüber nachgedacht einen Nuc oder ähnliches einzusetzen, mich aber dann für Synology entschieden um eben auch unsere Datenhaltung und Sicherung zu erneuern. Das ich bzgl. Linux und Perl ein wenig eingeschränkt bin auf der Syno stimmt natürlich - sollte unser FHEM-Haus wenn es mal vollständig integriert ist die grenzen der Syno sprengen können wir immer noch auf ein zweit System (Nuc) ausweichen...
Unsere TimeCapsulle hat halt mittlerweile knapp 8 Jahre auf dem Buckel, es wurde Zeit hier mal auf nummer sicherer zu gehen. Die entscheidung zur Syno hat also nicht nur mit FHEM zu tun.
Hi,
meiner Meinung nach war die einzige echte Antwort bisher diese:
Zitat von: ChrisD am 28 Oktober 2017, 23:44:43
Du kannst versuchen den Befehl 'fhemdebug memusage' zu benutzen.
Anscheinend hast Du (der-Lolo) aber recht schnell aufgegeben:
Zitat von: der-Lolo am 29 Oktober 2017, 14:20:31
@ChrisD: ich habe den befehl ausprobiert und bekomme eine Perl Meldung das ich das fehlende Modul Devel::Size brauche...
Das ist meiner Meinung nach das einzige, das Du brauchst. Einfach mal installieren und nochmal probieren. Ich denke, dass das zumindest mal einen Anhaltspunkt geben könnte, welches Modul das ist.
...außer wenn es hier um zyklische Referenzen geht, die der Garbage collector nicht auflösen kann, aber das muss ja nicht so sein.
Gruß,
Thorsten
naja, aufgegeben habe ich noch nicht - wie schon gesagt, auf der Syno Plattform läuft ActivePerl hier installiert man per ppm am besten Module nach. Ich habe noch nicht herausgefunden welches Paket ich nachinstallieren sollte sodass die abhängigkeit zu Devel::Size sich auflöst.
https://forum.fhem.de/index.php/topic,78678.0.html (https://forum.fhem.de/index.php/topic,78678.0.html)
Leider noch keine antwort - und auch mit Google bis jetzt keinen erfolg gehabt.
Ich arbeite daran und werde euch hier auf dem laufendem halten.
Die 1GB marke bei der RAM auslastung wurde soeben gerissen - hinter dem link ein Plot der RAM auslastung...
https://www.dropbox.com/s/yvfdz8o061d7xl6/Screenshot%202017-10-30%2014.49.41.png?dl=0 (https://www.dropbox.com/s/yvfdz8o061d7xl6/Screenshot%202017-10-30%2014.49.41.png?dl=0)
Ich habe nun endlich Devel-Size per ppm nachinstalliert, das absetzen des befehls fhemdebug memusage führt allerdings dazu das sich der FHEM Prozess sofort beendet. Nun kann ich natürlich nicht sagen ob es an der ActivePerl installation liegt oder an FHEM
Das logfile zeigt nichts an, das web interface ist sofort verschwunden und nicht mehr erreichbar. In htop verschwindet der Prozess - die RAM auslastung war auf >13% angewachsen - stetig über den Tag. Wie auf dem Plot zu sehen... Ich habe nach Neustart der Disk-Station nochmal versucht den Befehl abzusetzen, leider das gleiche Ergebnis...
naja, 20h sind keine repräsentative Zeit.
Sieht aber nach Speicherleck aus. Lass mal länger laufen, wenn möglich keine plots abrufen (oder andere Aktionen welche intensiv Speicher brauchen).
Um der Frage zuvor zu kommen. Sollte der der plot auch über einen längeren Zeitraum so aussehen (Speicher leck) kannst Du selbst wenig machen. Beginne dann ein Modul nach dem anderen zu deaktivieren und wiederhole den Test um den "Übeltäter" (ein oder mehrere module) ausfindig zu machen.
Ich hab leider keine genaue FHEM uptime - müsste aber so 72 Std gewesen sein, die steigung der Ram auslastung ist scheinbar konstant...
Ich schaue mal wie ich zumindest bis zum Zeitraum des kompletten logs zurück plotten kann.
Leider gehts um mein produktiv System, ich könnte einzelne Module vielleicht Stundenweise abschalten und schaen ob die steigung gleich bleibt...
Du kannst meine ich auf der Syno den Virtual Machine Manager installieren (auch wenn er evtl. noch nicht für die DS716+II freigegeben ist kann man einfach das spk laden und installieren) und so dein Prod-Fhem theoretisch klonen und mal in der VM schauen wie es sich dort verhält (Module die evtl Hardware exklusiv nutzen mal außen vor). Evtl. verhält es sich ja in einer VM mit einem debian schon anderst als mit dem dsm
Wenn ich Dich richtig verstehe soll ich mal versuchen FHEM virtuell laufen zu lassen - für die Virtuelle umgebung könnte ich ja z.b. 4GB Ram fest vergeben...
Ja, wäre interessant zu wissen was passiert wenn kein Speicher mehr zur verfügung steht.
Würdest Du eher auf diesen Virtual Machine Manager setzen - oder auf Docker..?
Eine VM für FHEM habe ich zwar nicht aufgesetzt, bin aber jetzt in der Lage den befehl fhemdebug memusage abzusetzen.
Meist habe ich den richtigen moment verpasst - oder es schlicht vergessen wenn fhem viel Arbeitspeicher benutzt...
Jetzt habe ich eine ausgabe von fhemdebug memusage
1. defs 1503475
2. defs::UnifiController 588861
3. modules 332919
4. defs::UnifiController::clients 225457
5. defs::UnifiController::READINGS 194729
6. defs::UnifiController::accespoints 146222
7. FW_RET 124623
8. attr 116581
9. defs::HarmonyHub 64839
10. defs::DS716 63343
11. POSIX:: 60441
12. defs::HarmonyHub::helper 51609
13. defs::HarmonyHub::helper::PARTIAL 50768
14. defs::UnifiController::accespoints::59e0af43e4b049f27ef569f5 44432
15. defs::UnifiController::accespoints::59a2e0fe744eb4c6a4951705 44021
16. defs::DS716::READINGS 41994
17. B:: 36394
18. defs::VEmodeSwitchOG 35095
19. modules::ModbusCoil 34409
20. modules::ModbusCoil::defptr 32608
21. defs::WPmodeSwitch 30057
22. Socket:: 26936
23. defs::UnifiController::accespoints::59a2e0d1744eb4c6a4951703 26847
24. defs::UnifiController::accespoints::59e0af43e4b049f27ef569f5::stat 20811
25. defs::UnifiController::accespoints::59a2e0fe744eb4c6a4951705::stat 20649
26. defs::UnifiController::accespoints::59a2b199744e2cbfda8ae0e8 19391
27. defs::LueftungBadEG 18456
28. defs::LueftungBadOG 18455
29. defs::DS716::helper 18411
30. defs::GAstateView 17078
31. defs::WM6YH891 16785
32. defs::WPstateView 16647
33. defs::VEmodeSwitchEG 15981
34. defs::DS716::helper::cur_readings_map 15257
35. defs::WM6YH891::READINGS 14107
36. Fcntl:: 13689
37. defs::HarmonyHub_DOIF_1 13139
38. modules::ModbusRegister 13037
39. Errno:: 12887
40. defs::VEmodeSwitchOG::READINGS 12846
41. INC 12519
42. defs::UnifiController::accespoints::59a2e0d1744eb4c6a4951703::stat 12057
43. modules::ModbusRegister::defptr 11008
44. defs::UnifiController::accespoints::5af9c583e4b00587d565974a 10852
45. defs::WagoController 10115
46. defs::WPmodeSwitch::READINGS 9844
47. oldvalue 9066
48. defs::UnifiController::wlans 8916
49. defs::UnifiController::clients::59ee0204e4b049f27ef5ae84 8851
50. defs::mF_WMZ 8496
Ich habe auch noch einen Screenshot von htop gemacht - nach 17 Tagen FHEM laufzeit habe ich also eine Arbeitsspeicher belegung von Aktuell: 4210.61
Mir ist es auch schon passiert das ich fhem nicht mehr updaten konnte weil kein Speicherplatz mehr verfügbar war, bei wieviel Arbeitsspeicher belegung das der Fall ist habe ich aber nicht herausgefunden.
Vielleicht kann ja jemand mit diesen Informationen was anfangen.
hier gibt es einen Thread zu dem Thema mit konkreten Erkenntnissen:
https://forum.fhem.de/index.php/topic,84372.msg814846.html#msg814846
Ich nutze auf der Synology DiskStation ja ActivePerl für FHEM -
beim Fhem start bekomme ich im Log folgendes:
Server started with 113 defined entities (fhem.pl:16866/2018-06-14 perl:5.024002 os:linux user:fhem pid:10626)
Im von Damian verlinkten thread geht es doch um ein leak in 5.24, oder? upgrade oder downgrade sollte helfen ist hier die aussage.
Ich setze aber doch gar nicht 5.24 ein...
Komisch das ganze - ich schaue trotzdem mal ob ich das ActivePerl updaten kann.
Ich versuch meine Frage mal hier zu platzieren. Ich habe mein Raspian mit Buster und Perl (v5.28.1) komplett neu aufgesetzt. Allerdings nach einigen Tagen läuft der RAM voll bzw. gibt ihn nicht frei.
apptime bracht mir... und ich vermute es liegt an den Kalendern. Hab mal gelesen dass average nicht größer als 1000 sein soll.
active-timers: 188; max-active timers: 201; max-timer-load: 19 min-tmrHandlingTm: 0.0ms; max-tmrHandlingTm: 10812.4ms; totAvgDly: 26.6ms
name function max count total average maxDly avgDly TS Max call param Max call
tmr-GetUpdate update 10811 779 44327.62 56.90 20915.26 164.23 11.11. 18:13:05 update:TankstelleJET
tmr-Calendar_PollChild HASH(0x4e80a80) 3603 1 3603.30 3603.30 2.26 2.26 12.11. 03:39:46 HASH(Abfall_cal)
tmr-Calendar_PollChild HASH(0x4b7dde0) 3396 14 45393.12 3242.37 852.29 97.08 12.11. 03:33:03 HASH(Abfallkalender)
tmr-CustomReadings_OnTimer HASH(0x395b248) 1593 14 14379.11 1027.08 2.26 1.26 12.11. 00:32:54 HASH(Update.Counter)
tmr-Calendar_PollChild HASH(0x4f23e98) 1053 2 2072.10 1036.05 0.95 0.85 12.11. 04:33:00 HASH(Familienkalender)
Abfall_CalView ABFALL_Notify 786 7 1275.24 182.18 0.00 0.00 12.11. 03:39:46 HASH(Abfall_CalView); HASH(Abfall_cal)
list
Internals:
CFGFN ./FHEM/fhem_calendar.cfg
DEF ical url https://calendar.google.com/calendar/ical/rpq47g2nprdtaagorftdvhkobo%40group.calendar.google.com/private-2925360a6e849ba519582f5e798d0854/basic.ics
FUUID 5ccbe86d-f33f-e9d9-e19f-6927d47fa255a5ac
NAME Abfallkalender
NOTIFYDEV global
NR 663
NTFY_ORDER 50-Abfallkalender
STATE triggered
TYPE Calendar
READINGS:
2020-11-12 06:33:02 calname Abfallkalender
2020-11-12 06:33:02 lastUpdate 2020-11-12 06:32:58
2019-01-02 22:30:48 modeAlarm
2020-11-12 00:00:00 modeAlarmOrStart GELB202023oberhausende
2019-01-02 22:30:48 modeAlarmed
2020-11-12 00:33:02 modeChanged
2020-11-12 06:33:02 modeEnd BIO202021oberhausende;BIO202010oberhausende;BIO20209oberhausende;HMRD202012oberhausende;HMRD202015oberhausende;BIO201926oberhausende;HMRD201924oberhausende;HMRD202020oberhausende;HMRD20207oberhausende;WEIHNACHTSBAUM20201oberhausende;BIO20201oberhausende;GELB20196oberhausende;HMRD20205oberhausende;GELB202014oberhausende;GELB202021oberhausende;BIO20205oberhausende;BIO202012oberhausende;BIO201923oberhausende;PAPIER20203oberhausende;GELB20202oberhausende;HMRD202016oberhausende;HMRD20204oberhausende;GELB20193oberhausende;BIO20206oberhausende;HMRD201921oberhausende;BIO20207oberhausende;HMRD202010oberhausende;HMRD20209oberhausende;GELB20195oberhausende;HMRD20206oberhausende;HMRD202022oberhausende;GELB202019oberhausende;BIO202022oberhausende;HMRD20208oberhausende;BIO201925oberhausende;GELB202011oberhausende;PAPIER20205oberhausende;PAPIER202010oberhausende;BIO20204oberhausende;HMRD20203oberhausende;HMRD201923oberhausende;GELB202017oberhausende;GELB20194oberhausende;BIO202011oberhausende;BIO202020oberhausende;BIO201924oberhausende;PAPIER202011oberhausende;GELB202013oberhausende;BIO20202oberhausende;GELB20201oberhausende;GELB202018oberhausende;PAPIER20207oberhausende;PAPIER20204oberhausende;BIO202016oberhausende;HMRD202011oberhausende;BIO202019oberhausende;PAPIER20209oberhausende;BIO202018oberhausende;PAPIER20202oberhausende;GELB20206oberhausende;GELB202010oberhausende;GELB20209oberhausende;GELB20208oberhausende;GELB202022oberhausende;HMRD202019oberhausende;BIO202013oberhausende;HMRD202013oberhausende;PAPIER201912oberhausende;BIO201922oberhausende;HMRD20201oberhausende;HMRD202018oberhausende;HMRD202017oberhausende;PAPIER20201oberhausende;GELB20203oberhausende;GELB20192oberhausende;HMRD201922oberhausende;GELB20207oberhausende;HMRD202014oberhausende;GELB20205oberhausende;BIO20208oberhausende;HMRD202021oberhausende;HMRD201925oberhausende;GELB202012oberhausende;BIO202017oberhausende;GELB202015oberhausende;PAPIER201913oberhausende;BIO202015oberhausende;PAPIER20206oberhausende;GELB202020oberhausende;HMRD20202oberhausende;BIO201921oberhausende;PAPIER201911oberhausende;GELB202016oberhausende;GELB20204oberhausende;PAPIER20208oberhausende;BIO20203oberhausende;GELB20191oberhausende;BIO202014oberhausende;HMRD201926oberhausende
2020-11-03 00:35:36 modeEnded
2020-11-12 00:00:00 modeStart GELB202023oberhausende
2020-11-12 00:33:02 modeStarted
2020-11-12 06:33:02 modeUpcoming PAPIER202012oberhausende;HMRD202025oberhausende;PAPIER202013oberhausende;GELB202024oberhausende;HMRD202026oberhausende;HMRD202024oberhausende;GELB202025oberhausende;BIO202024oberhausende;GELB202026oberhausende;BIO202025oberhausende;BIO202023oberhausende;BIO202026oberhausende;HMRD202023oberhausende
2020-11-12 06:33:02 nextUpdate 2020-11-12 07:32:58
2020-11-12 06:33:03 nextWakeup 2020-11-12 07:32:58
2020-11-12 06:33:02 state triggered
helper:
bm:
Calendar_Get:
cnt 546
dmx -1000
dtot 0
dtotcnt 0
mTS 11.11. 20:33:02
max 0.0121660232543945
tot 5.70522165298462
mAr:
HASH(Abfallkalender)
-
events
format:custom="$S"
filter:uid=="PAPIER202012oberhausende"
Calendar_Notify:
cnt 745
dmx -1000
dtot 0
dtotcnt 0
mTS 11.11. 21:20:36
max 0.000165939331054688
tot 0.0354771614074707
mAr:
HASH(Abfallkalender)
HASH(global)
Attributes:
DbLogExclude .*
alias Abfallkalender
event-on-change-reading .*
group Abfallentsorgung
hideLaterThan 14d
hideOlderThan 1d
room Terminkalender