[Gelöst] Freezes in exaktem Minutenabstand - Bitte um Hilfe bei der Fehlersuche

[frank]

du weisst aber schon, dass die readingsgroups zusätzlich einen haufen events erzeugen können.
und zwar immer dann, wenn sie irgendwo angezeigt werden.

ganz schlecht ist das folgende attribut:

alwaysTrigger
1 -> alwaysTrigger update events. even if not visible.
2 -> trigger events for calculated values.

wie schon weiter oben geschrieben, hast du scheinbar weiterhin ein eventproblem.
ein letztes mal empfehle ich dir "attr event-on-change .*" in möglichst jedem device.

[mumpitzstuff]

ein letztes mal empfehle ich dir "attr event-on-change .*" in möglichst jedem device.

Das sollte meines Erachtens durch FHEM als Standard gesetzt werden und eher abschaltbar sein als anschaltbar... Soll nicht heissen das FHEM das heute so macht, meiner Meinung nach, sollte FHEM das aber so tun und es würde viele Freeze Probleme gar nicht erst auftreten lassen.

[hauwech]

Hallo Frank,
daß readingsGroups events erzeugen war mir bisher nicht wirklich bewußt aufgefallen im Eventmonitor. AlwaysTrigger habe ich aber nirgends gesetzt.
Ich habe im Verlauf dieser Fehlersuche zusätzlich zu denen, wo es schon gesetzt war, auf alle Devices mit einem battery oder batteryLevel reading das event-on-change-reading .* gesetzt, weil da eine readingsGroup existiert, die alle Battery Stati einfängt. Vorher hatte ich vermieden, das auf alle devices zu setzen, weil das viele Plots unschön aussehen läßt.
Da werde ich weiter optimieren, Performance hat höhere Prio als Plots. Ich denke, ich setze bei den betroffenen devices (meist Heizthermostate) ein event-min-interval auf die wichtigen readings. Damit habe ich schon die LaCrosse Temperatursensoren gebändigt, die alle paar Sekunden melden.
Macht es Sinn, event-on-change-reading .* und z.B. event-min-interval measured-temp=600, [humidity=600,] actuator=600 zu setzen? Hat das den Effekt, daß alle readings bei geänderten Werten und measured-temp, humidity und actuator trotzdem alle 10 Minuten ein event werfen? Oder gewinnt event-on-change-reading?

Gruß Roland

[frank]

vom prinzip her sollte es so funktionieren.
kannst du doch auch sehr komfortabel im eventmonitor live verfolgen.

zusätzlich könntest du auch noch mit event-on-update einige readings auf maximale event generierung schalten.

[hauwech]

Update:
Ich habe nun immer wenn ich Zeit hatte, devices und auch komplette rooms mit Verdachtigen gelöscht. Der letzte freeze blieb aber hartnäckig.
Jetzt habe ich mir überlegt, wozu ich das vor langer Zeit angelegte device "telnetPort" eigentlich brauche, was in 99% aller freezes als Verursacher auftaucht. Aktiv genutzt habe ich es eigentlich nur im IOBroker-fhem-Adapter. Den hatte ich auf IOBroker-Seite aber schon abgeschaltet gehabt, ohne daß sich im freeze-Verhalten auf fhem-Seite was ändert.
Jetzt habe ich - nach einem Backup - das telnet-device in fhem gelöscht. Damit ist der letzte freeze auch weg. Ich habe dann mit shutdown restart das device wiederbelebt - der freeze ist wieder da. Das Wunder wie mit den wiederbelebten readingsGroups hat sich leider nicht wiederholt. Nochmal gelöscht - freeze wieder weg. Mit neuem Namen, aber gleichem DEF (7072 global) wieder angelegt - freeze kommt mit dem neuen Namen wieder. Damit dürfte der Verursacher feststehen und freezemon hat Recht gehabt.
Abgesehen von meinem IOBroker-Problem bleibt nun die Frage: Wird telnet doch von fhem oder diversen Modulen gebraucht, wenn es intern mit 60s Intervall aufgerufen wird?
Ich werde das jetzt mal beobachten. Vielleicht kennt aber jemand die Nebenwirkungen, wenn das fhem-telnet-device fehlt.
IOBroker könnte ich notfalls mit MQTT füttern, wenn telnet nicht gebraucht würde. Das ist dank des schlanken MQTT Protokolls wahrscheinlich auch deutlich performanter, als sämtliche fhem devices und sämtliche readings mit dem fhem-Adapter nach IOBroker zu pumpen.
Danke an Frank:
Die Kombination von event-on-change-reading und event-min-interval funktioniert wie erwartet. Die event-Flut ist eingedämmt und die Plots sehen auch wieder ordentlich aus.

Gruß Roland

[Wernieman]

Dann hast Du irgendeinen Job auf Deinem Rechner/Netz, der jede Minute per telnet an Dein fhem geht. Dann schaue mal ins syslog, ob da irgendetwas auffällt ...

[hauwech]

Ich bin nicht so der große Linux-Guru.

Code Auswählen Erweitern

cat /var/log/syslog|grep telnet bringt null Fundstellen, das log geht bis heute morgen 6:29 Uhr zurück, da gab's die freezes noch.
Ein

Code Auswählen Erweitern

sudo grep -R im Verzeichnis /var/log bringt auch nur

Code Auswählen Erweitern

roland@fhem-nuc:/var/log$ sudo grep -R telnet
Übereinstimmungen in Binärdatei btmp
installer/syslog:Nov 17 17:15:43 in-target:   squashfs-tools ssh-import-id strace tcpd tcpdump tdb-tools telnet time tmux
installer/syslog:Nov 17 17:15:46 in-target: Holen:177 cdrom://Ubuntu-Server 16.04.1 LTS _Xenial Xerus_ - Release amd64 (20160719) xenial/main amd64 telnet amd64 0.17-40 [63,5 kB]
installer/syslog:Nov 17 17:16:15 in-target: Vormals nicht ausgewähltes Paket telnet wird gewählt.^M
installer/syslog:Nov 17 17:16:15 in-target: Vorbereitung zum Entpacken von .../telnet_0.17-40_amd64.deb ...^M
installer/syslog:Nov 17 17:16:15 in-target: Entpacken von telnet (0.17-40) ...^M
installer/syslog:Nov 17 17:17:06 in-target: telnet (0.17-40) wird eingerichtet ...
installer/syslog:Nov 17 17:17:06 in-target: update-alternatives: /usr/bin/telnet.netkit wird verwendet, um /usr/bin/telnet (telnet) im automatischen Modus bereitzustellen^M
auth.log:Jan 29 20:02:58 fhem-nuc sudo:   roland : TTY=pts/0 ; PWD=/var/log ; USER=root ; COMMAND=/bin/grep -R telnet
Alles alter Kram.
Gibt's noch andere logs, wo man fündig werden könnte?

Gruß Roland

[Wuppi68]

schau ma hier ...

https://help.joyent.com/hc/en-us/articles/226687427-Watching-active-IP-connections-Linux

da gibt es ein paar Wege zum Monitoren der aktiven Netzwerkverbindungen ...

oder setzt mal den verbose Level auf 5 vom telnet Device

[hauwech]

Danke, das sind interessante tools, die ich noch nicht kenne.
Ich habe in einer VM ein fhem neu installiert, das kann man als cold standby immer mal gebrauchen.
Im leeren fhem habe ich eine freezemon Instanz und ein telnet device angelegt. Das hält so alleine die Füße still und verursacht wie erwartet keine freezes.
Ich schließe daraus, daß das Kern-fhem selbst keine internen telnet-Aufrufe macht und die Probleme somit aus einem Modul heraus initiiert werden müssen.
Mit dem Löschen des telnet devices bin ich zwar die freezes losgeworden, habe aber die Ursache nicht beseitigt.
Ich habe eben den Tip "telnet device auf verbose 5" verfolgt, und siehe da: Kurz vor dem freeze werden alle devices durchgegangen. Ich habe hier nur einen Teil herausgeschnitten. Das "... returned dont care" interpretiere ich als "macht nix...". Aber die Tatsache, daß zyklisch ALLE devices angefaßt werden, könnte doch zu diesen Verzögerungen führen, oder??? Loglevel 4 heißt ja nur, daß sie mit verbose 5 geloggt werden, ausgeführt werden sie aber immer.

Code Auswählen Erweitern

2019.01.30 10:56:28.362 4: Connection accepted from telnetPort_127.0.0.1_38504
2019.01.30 10:56:28.363 4: authorize telnetPort/cmd/jsonlist2: allowedWEBhook returned dont care
2019.01.30 10:56:28.363 4: authorize telnetPort/cmd/jsonlist2: allowed_WEB returned dont care
2019.01.30 10:56:28.364 4: authorize telnetPort/cmd/jsonlist2: allowed_WEBphone returned dont care
2019.01.30 10:56:28.364 4: authorize telnetPort/cmd/jsonlist2: allowed_WEBtablet returned dont care
2019.01.30 10:56:28.393 4: authorize telnetPort/devicename/AV_Receiver: allowedWEBhook returned dont care
2019.01.30 10:56:28.393 4: authorize telnetPort/devicename/AV_Receiver: allowed_WEB returned dont care
2019.01.30 10:56:28.393 4: authorize telnetPort/devicename/AV_Receiver: allowed_WEBphone returned dont care
2019.01.30 10:56:28.393 4: authorize telnetPort/devicename/AV_Receiver: allowed_WEBtablet returned dont care
2019.01.30 10:56:28.394 4: authorize telnetPort/devicename/Activity_chk: allowedWEBhook returned dont care
....
2019.01.30 10:56:28.629 4: authorize telnetPort/devicename/v_armInt_s: allowed_WEB returned dont care
2019.01.30 10:56:28.629 4: authorize telnetPort/devicename/v_armInt_s: allowed_WEBphone returned dont care
2019.01.30 10:56:28.629 4: authorize telnetPort/devicename/v_armInt_s: allowed_WEBtablet returned dont care
2019.01.30 10:56:31.563 1: [Freezemon] myFreezemon: Long running Command detected jsonlist2 TYPE=.*:FILTER=state=..*:FILTER=model!=CCU-FHEM:FILTER=model!=ActionDetector:telnetPort - 3.199874 seconds
2019.01.30 10:56:31.639 1: [Freezemon] myFreezemon: Long function call detected ReadFn:telnetPort_127.0.0.1_38504 - 3.275956 seconds
2019.01.30 10:56:31.641 1: [Freezemon] myFreezemon: possible freeze starting at 10:56:29, delay is 2.639 possibly caused by: cmd-jsonlist2 TYPE=.*:FILTER=state=..*:FILTER=model!=CCU-FHEM:FILTER=model!=ActionDetector(telnetPort) fn-ReadFn(telnetPort_127.0.0.1_38504)
2019.01.30 10:57:28.159 4: Connection accepted from telnetPort_127.0.0.1_38592
2019.01.30 10:57:28.161 4: authorize telnetPort/cmd/jsonlist2: allowedWEBhook returned dont care
2019.01.30 10:57:28.161 4: authorize telnetPort/cmd/jsonlist2: allowed_WEB returned dont care
2019.01.30 10:57:28.162 4: authorize telnetPort/cmd/jsonlist2: allowed_WEBphone returned dont care
2019.01.30 10:57:28.162 4: authorize telnetPort/cmd/jsonlist2: allowed_WEBtablet returned dont care
....
2019.01.30 10:57:28.433 4: authorize telnetPort/devicename/sunMarker: allowedWEBhook returned dont care
2019.01.30 10:57:28.433 4: authorize telnetPort/devicename/sunMarker: allowed_WEB returned dont care
2019.01.30 10:57:28.433 4: authorize telnetPort/devicename/sunMarker: allowed_WEBphone returned dont care
2019.01.30 10:57:28.433 4: authorize telnetPort/devicename/sunMarker: allowed_WEBtablet returned dont care
2019.01.30 10:57:28.433 4: authorize telnetPort/devicename/telnetForBlockingFn_1548771227: allowedWEBhook returned dont care
2019.01.30 10:57:28.433 4: authorize telnetPort/devicename/telnetForBlockingFn_1548771227: allowed_WEB returned dont care
2019.01.30 10:57:28.433 4: authorize telnetPort/devicename/telnetForBlockingFn_1548771227: allowed_WEBphone returned dont care
2019.01.30 10:57:28.433 4: authorize telnetPort/devicename/telnetForBlockingFn_1548771227: allowed_WEBtablet returned dont care
2019.01.30 10:57:28.434 4: authorize telnetPort/devicename/telnetPort: allowedWEBhook returned dont care
2019.01.30 10:57:28.434 4: authorize telnetPort/devicename/telnetPort: allowed_WEB returned dont care
2019.01.30 10:57:28.434 4: authorize telnetPort/devicename/telnetPort: allowed_WEBphone returned dont care
2019.01.30 10:57:28.434 4: authorize telnetPort/devicename/telnetPort: allowed_WEBtablet returned dont care
2019.01.30 10:57:28.434 4: authorize telnetPort/devicename/telnetPort_127.0.0.1_38592: allowedWEBhook returned dont care
2019.01.30 10:57:28.434 4: authorize telnetPort/devicename/telnetPort_127.0.0.1_38592: allowed_WEB returned dont care
2019.01.30 10:57:28.434 4: authorize telnetPort/devicename/telnetPort_127.0.0.1_38592: allowed_WEBphone returned dont care
2019.01.30 10:57:28.434 4: authorize telnetPort/devicename/telnetPort_127.0.0.1_38592: allowed_WEBtablet returned dont care
2019.01.30 10:57:28.435 4: authorize telnetPort/devicename/userCfg: allowedWEBhook returned dont care
2019.01.30 10:57:28.435 4: authorize telnetPort/devicename/userCfg: allowed_WEB returned dont care
....
2019.01.30 10:57:28.436 4: authorize telnetPort/devicename/v_armInt_l: allowed_WEBphone returned dont care
2019.01.30 10:57:28.436 4: authorize telnetPort/devicename/v_armInt_l: allowed_WEBtablet returned dont care
2019.01.30 10:57:28.437 4: authorize telnetPort/devicename/v_armInt_s: allowedWEBhook returned dont care
2019.01.30 10:57:28.437 4: authorize telnetPort/devicename/v_armInt_s: allowed_WEB returned dont care
2019.01.30 10:57:28.437 4: authorize telnetPort/devicename/v_armInt_s: allowed_WEBphone returned dont care
2019.01.30 10:57:28.437 4: authorize telnetPort/devicename/v_armInt_s: allowed_WEBtablet returned dont care
2019.01.30 10:57:31.113 1: [Freezemon] myFreezemon: Long running Command detected jsonlist2 TYPE=.*:FILTER=state=..*:FILTER=model!=CCU-FHEM:FILTER=model!=ActionDetector:telnetPort - 2.951947 seconds
2019.01.30 10:57:31.194 1: [Freezemon] myFreezemon: Long function call detected ReadFn:telnetPort_127.0.0.1_38592 - 3.03339 seconds
2019.01.30 10:57:31.197 1: [Freezemon] myFreezemon: possible freeze starting at 10:57:29, delay is 2.195 possibly caused by: cmd-jsonlist2 TYPE=.*:FILTER=state=..*:FILTER=model!=CCU-FHEM:FILTER=model!=ActionDetector(telnetPort) fn-ReadFn(telnetPort_127.0.0.1_38592) tmr-Unifi_DoUpdate(UnifiController)

Oder habe ich die allowed_Web.* Instanzen falsch konfiguriert?

Code Auswählen Erweitern

Internals:
   FUUID      xxxxxxxxx-f33f-af18-4e61-xxxxxxxxxxxxxxxxxxxx
   NAME       allowed_WEB
   NR         71
   STATE      validFor:WEB
   TYPE       allowed
   validFor   WEB
   READINGS:
     2019-01-29 15:09:19   lastAuthExpires xxxxxxxxxxxx
     2019-01-29 15:09:19   lastAuthExpiresFmt xxx, xx xxx xxxx 14:09:19 GMT
     2019-01-29 15:09:19   lastAuthUser    xxxxxxxx
     2019-01-29 15:08:54   state           validFor:WEB
   helper:
     bm:
       allowed_Authenticate:
         cnt        46
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        30.01. 09:38:32
         max        0.000462055206298828
         tot        0.00591206550598145
         mAr:
           HASH(allowed_WEB)
           HASH(WEB)
           HASH(0x1929928)
       allowed_Authorize:
         cnt        30
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        30.01. 09:40:58
         max        7.60555267333984e-05
         tot        0.000606536865234375
         mAr:
           HASH(allowed_WEB)
           HASH(WEB_88.xxx.xx.xx_51631)
           cmd
           apptime
Attributes:
   basicAuth  xxxxxxxxxxxxxxx
   basicAuthExpiry xx
   validFor   WEB

Code Auswählen Erweitern

Internals:
   FUUID      xxxxxxxxxxxx-f33f-af18-dea2-xxxxxxxxxxxxxxxxx
   NAME       allowedWEBhook
   NR         725
   STATE      validFor:WEBhook
   TYPE       allowed
   allowedCommands ,
   allowedDevices ,
   validFor   WEBhook
   READINGS:
     2019-01-29 15:08:58   state           validFor:WEBhook
   helper:
     bm:
       allowed_Authenticate:
         cnt        46
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        30.01. 09:39:30
         max        0.000255823135375977
         tot        0.00468230247497559
         mAr:
           HASH(allowedWEBhook)
           HASH(WEB)
           HASH(0xa150008)
       allowed_Authorize:
         cnt        30
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        30.01. 09:39:55
         max        0.000185012817382812
         tot        0.00183892250061035
         mAr:
           HASH(allowedWEBhook)
           HASH(telnetForBlockingFn_1548771227_127.0.0.1_36040)
           cmd
           perl
Attributes:
   allowedCommands ,
   allowedDevices ,
   basicAuth  { "$user:$password" eq "xxxxxx:xxxxxxxxxx" }
   validFor   WEBhook

Code Auswählen Erweitern

Internals:
   FUUID      xxxxxxxxx-f33f-af18-1c9c-xxxxxxxxxxxxxxxxxxx
   NAME       allowed_WEBphone
   NR         78
   STATE      validFor:WEBphone
   TYPE       allowed
   validFor   WEBphone
   READINGS:
     2019-01-29 15:08:54   state           validFor:WEBphone
   helper:
     bm:
       allowed_Authenticate:
         cnt        35
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        30.01. 09:38:32
         max        0.000112056732177734
         tot        0.00136947631835938
         mAr:
           HASH(allowed_WEBphone)
           HASH(WEB)
           HASH(0x1929928)
       allowed_Authorize:
         cnt        30
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        30.01. 09:40:58
         max        4.00543212890625e-05
         tot        0.000430822372436523
         mAr:
           HASH(allowed_WEBphone)
           HASH(WEB_88.xxx.xx.xx_51631)
           cmd
           apptime
Attributes:
   basicAuth  xxxxxxxxxxxxxxx
   validFor   WEBphone

Code Auswählen Erweitern

Internals:
   FUUID      xxxxxxxxxx-f33f-af18-5354-xxxxxxxxxxxxxx
   NAME       allowed_WEBtablet
   NR         83
   STATE      validFor:WEBtablet
   TYPE       allowed
   validFor   WEBtablet
   READINGS:
     2019-01-29 15:08:54   state           validFor:WEBtablet
   helper:
     bm:
       allowed_Authenticate:
         cnt        35
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        30.01. 09:38:32
         max        0.000107049942016602
         tot        0.00133299827575684
         mAr:
           HASH(allowed_WEBtablet)
           HASH(WEB)
           HASH(0x1929928)
       allowed_Authorize:
         cnt        30
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        30.01. 09:40:58
         max        7.89165496826172e-05
         tot        0.000463962554931641
         mAr:
           HASH(allowed_WEBtablet)
           HASH(WEB_88.xxx.xx.xx_51631)
           cmd
           apptime
Attributes:
   basicAuth  xxxxxxxxxxxxxxxxxx
   validFor   WEBtablet

Gruß Roland

[hauwech]

Ich bin gerade auf eine möglicherweise heiße Spur gestoßen:
Pro:
- die fhem-devices in Check_MK stehen seit gestern auf "stale"
- das Check_MK Plugin für fhem macht lokales telnet
- in der Datei  /usr/lib/check_mk_agent/plugins/mk_fhem steht:

Code Auswählen Erweitern

my $fhem_outpout = `/opt/fhem/fhem.pl 7072 "jsonlist2 TYPE=.*:FILTER=state=..*:FILTER=model!=CCU-FHEM:FILTER=model!=ActionDetector"`;

- das paßt exakt zu:

Code Auswählen Erweitern

2019.01.18 09:34:07.580 1: [Freezemon] myFreezemon: Long running Command detected jsonlist2 TYPE=.*:FILTER=state=..*:FILTER=model!=CCU-FHEM:FILTER=model!=ActionDetector:telnetPort - 3.30997 seconds
Contra:
- mein Kollege hat das so auch im Einsatz, aber ohne freezes.

Was habe ich daraufhin gemacht:
- das check_mk Plugin aus /usr/lib/check_mk_agent/plugins entfernt
- define telnetPort telnet 7072 global
- tail -f /opt/fhem/log/fhem-2019-01.log -n 100

..... Trommelwirbel ..........

KEIN FREEZE 
Heureka!

Ich hoffe, das war's jetzt, die Geschichte hat mich doch ganz schön gewurmt.
Dankeschön an alle Mitwirkenden!

Erleichterter Gruß
Roland

[Wernieman]

Sorry aber was ist "Check_MK"?

Übrigens hatte ich Dir am Anfang (glaub ich) geschrieben, das telnet von einem externen Device stammen könnte ....
Aber gut, das es jetzt funzt!

[erdo_king]

Sorry aber was ist "Check_MK"?

Übrigens hatte ich Dir am Anfang (glaub ich) geschrieben, das telnet von einem externen Device stammen könnte ....
Aber gut, das es jetzt funzt!

Check_MK ist ein Monitoring-System, ich habe hierzu ein FHEM-Plugin geschrieben.
Siehe https://forum.fhem.de/index.php/topic,63723.0.html

Das Freezes dadurch entstehen ist mir stand jetzt aber nicht bekannt.


Edit:
Zu Abfrage wird der befehl benutzt:
/opt/fhem/fhem.pl 7072 "jsonlist2 TYPE=.*:FILTER=state=..*:FILTER=model!=CCU-FHEM:FILTER=model!=ActionDetector

[erdo_king]

@hauwech:
ich seh grad das du noch einen alten Agent benutzt.
teste doch bitte mal den Neuen! Ich habe hier mehr Sachen ausgefiltert ...

https://github.com/erdoking/mk_fhem/blob/master/local/share/check_mk/agents/mk_fhem

interessant wäre auch die Laufzeit der beiden Abfragen - einmal aus dem Kopf...

Alt:
time /opt/fhem/fhem.pl 7072 "jsonlist2 TYPE=.*:FILTER=state=..*:FILTER=model!=CCU-FHEM:FILTER=model!=ActionDetector
Neu:
time /opt/fhem/fhem.pl 7072 "jsonlist2 TYPE=.*:FILTER=state=..*:FILTER=model!=CCU-FHEM:FILTER=TYPE!=CCU-FHEM|ActionDetector|at|notify|statistics|DOIF"

[herrmannj]

jsonlist2 ist bekannt dafür längere Laufzeiten zu haben - eben weil viele Module "angefasst" werden. Ich würde nach Alternativen suchen.

Generell bauen Architekturen die jsonlist benutzen auch darauf auf fhem zu pollen, oft zyklisch. Eine andere Möglichkeit besteht darin events bei der Entstehung abgreifen und an externe Systeme pushen, quasi nur das was von Interesse ist zu übertragen.

[hauwech]

Übrigens hatte ich Dir am Anfang (glaub ich) geschrieben, das telnet von einem externen Device stammen könnte ....
Aber gut, das es jetzt funzt!

Ja, hast Du 
"extern" hatte ich nach allen Versuchen mit IObroker, alexa, SSCam & Co. soweit ausgeschlossen, weil der Aufruf lt. freezemon auf TelnetPort_127.0.0.1... ging, das mußte nach meinem Ermessen etwas Lokales sein.
Ich hatte aber auch meine String-Suche in den files auf /opt/fhem begrenzt. Das Check-mk Plugin liegt aber unter /usr/lib/....

@erdo:
Die Ausführungszeiten unterscheiden sich leider nur marginal:

Code Auswählen Erweitern

time /opt/fhem/fhem.pl 7072 "jsonlist2 TYPE=.*:FILTER=state=..*:FILTER=model!=CCU-FHEM:FILTER=model!=ActionDetector"
real    0m4.662s
user    0m0.228s
sys     0m0.200s

time /opt/fhem/fhem.pl 7072 "jsonlist2 TYPE=.*:FILTER=state=..*:FILTER=model!=CCU-FHEM:FILTER=TYPE!=CCU-FHEM|ActionDetector|at|notify|statistics|DOIF"
real    0m4.657s
user    0m0.240s
sys     0m0.188s

Gruß Roland