[gelöst] seltene minutenlange "Hänger" auf der Fritzbox

[herrmannj]

Hallo zusammen,

ihc möchte mal vorsichtig iin die Runde fragen ob das unten beschriebene Verhalten von auch von anderen Usern beobachtet wird.

Der Hardwarerahmen, FB7390, HM Lan, Cul868, RFXTRX. Was ich bereits in der Vergangenheit beobachtet habe ist folgendes: in seltenen Fällen hängt bei miir fhem auf der FB, durchaus mal viele Minuten. In den meisten Fällen blieb mir das wohl auch unbemerkt, in den Logs tauchen (bis auf HMLAN disconnect) keine besonderen Hinweise auf und fhem läuft anschließend normal weiter.

Aufgefallen ist mir das durchaus früher schon (irgendeine Aktion, zB Schalter drücken, Licht geht deutlich verzögert an. zB 90 sek später). Wie gesagt, das war nie so richtig festzumachen.

Jetzt habe ich mit den learnings der vergangenen Monate fhem komplett neu aufgesetzt und die Programmierung ist noch überschaubar. In dem Zuge habe ich unter anderem einen Timer eingerichtet der Events für Tageslogs jeweils exakt im 10min Abstand "feuert". Da ich zusätzlich gerade debug Einträge für einen Windsensor (14 Sekunden Events) ins Log schreibe kann man hier recht gut sehen DAS etwas schiefgeht, dummerweise nicht was ....

Der 13:10:00 Eintrag in log stammt aus meinem Timer, im Timer wird der nächste Zeitüunkt (nächste volle 10min dynamisch berechnet).
Von 13:10:12 bis 13:19:26 meldet sich der Windsensor mit aktuell gemessener Windrichtung und dem berechneten gleitendem Durchschnitt.

Danach ist bis 13:32:29 - also mehr als 10 min nichts im Log, der Timer hätte um exakt 13:20 und dazu etwa alle 14 Sekunden eine Windmeldung auftauchen müssen.

Um 13:32:29 "lebt" das System wieder, scheinbar zwischengepufferte Windmeldungen werden am Stück bearbeitet, der HMLAN wird als als vermisst gemeldet. Der überfällige 13:20:00 Timer wird um 13:32:29 abgearbeitet (und schaltet sich selber für 13:40:00 erneut scharf).

Deutlich sichtbar ist das die in der Zwischenzeit aufgelaufenen Windmeldungen jetzt am Stück direkt abgearbeitet werden (normal alle 14 Sekunden, manchmal fehlen natürlich auch welche). Um 13:32:39 ist der Spuk vorbei, das nächste Event ist mit > 10 Sekunden der Windmesser.

Leider habe ich keine zusätzlichen Informationen wo es geklemmt hat im Log, dieses auch früher schon gelegentlich beobachtete Verhalten ist hier nur durch Zufall genau zeitlich dokumentiert.

Irgendwelche Exoten Module (sorry, you know ... ) habe ich nicht im Einsatz, erst recht nicht da ich das System gerade neu aufbaue.

Irgenwelche Gedanken / eigene Beobachtungen anderer User dazu ?

Grüße
Jörg

Code Auswählen Erweitern


2013.11.01 13:10:00 2: myUtils 10 min timer called
2013.11.01 13:10:12 1: wind 225 212.378880367041
2013.11.01 13:10:26 1: wind 202 212.448997698335
2013.11.01 13:10:40 1: wind 225 212.390947711122
2013.11.01 13:10:54 1: wind 225 212.460998001616
2013.11.01 13:11:08 1: wind 270 212.530659123829
2013.11.01 13:11:22 1: wind 225 212.849933239808
2013.11.01 13:11:36 1: wind 247 212.917433610698
2013.11.01 13:11:50 1: wind 247 213.10678120175
2013.11.01 13:12:04 1: wind 180 213.29507686174
2013.11.01 13:12:18 1: wind 225 213.110104212508
2013.11.01 13:12:32 1: wind 225 213.176159189105
2013.11.01 13:12:46 1: wind 225 213.24184719361
2013.11.01 13:13:00 1: wind 225 213.307170264757
2013.11.01 13:13:14 1: wind 225 213.372130429953
2013.11.01 13:13:28 1: wind 225 213.436729705342
2013.11.01 13:13:42 1: wind 180 213.500970095868
2013.11.01 13:13:56 1: wind 225 213.314853595335
2013.11.01 13:14:10 1: wind 247 213.379771075361
2013.11.01 13:14:24 1: wind 225 213.566550124942
2013.11.01 13:14:38 1: wind 180 213.630069290915
2013.11.01 13:14:52 1: wind 202 213.443235572632
2013.11.01 13:15:06 1: wind 225 213.379662041673
2013.11.01 13:15:20 1: wind 180 213.444219474775
2013.11.01 13:15:34 1: wind 225 213.25841825547
2013.11.01 13:15:48 1: wind 225 213.323649265162
2013.11.01 13:16:02 1: wind 225 213.388517880356
2013.11.01 13:16:16 1: wind 225 213.453026114354
2013.11.01 13:16:30 1: wind 202 213.517175969274
2013.11.01 13:16:44 1: wind 225 213.453191658334
2013.11.01 13:16:58 1: wind 225 213.517340593565
2013.11.01 13:17:12 1: wind 225 213.581133145823
2013.11.01 13:17:26 1: wind 225 213.644571295013
2013.11.01 13:17:40 1: wind 225 213.707657010041
2013.11.01 13:17:54 1: wind 225 213.770392248874
2013.11.01 13:18:08 1: wind 202 213.832778958602
2013.11.01 13:18:22 1: wind 225 213.767041297721
2013.11.01 13:18:36 1: wind 225 213.829446623845
2013.11.01 13:18:50 1: wind 157 213.891505253713
2013.11.01 13:19:04 1: wind 202 213.575441335636
2013.11.01 13:19:18 1: wind 180 213.511133328216
2013.11.01 13:19:32 1: wind 157 213.324960365282
2013.11.01 13:19:46 1: wind 247 213.012043918808

2013.11.01 13:32:27 1: wind 202 213.200865897037
2013.11.01 13:32:27 1: wind 225 209.840606127926
2013.11.01 13:32:27 1: wind 225 209.92482498277
2013.11.01 13:32:27 1: wind 225 210.008575955088
2013.11.01 13:32:28 1: wind 225 210.091861644227
2013.11.01 13:32:28 1: wind 225 210.174684635092
2013.11.01 13:32:28 1: wind 202 210.257047498231
2013.11.01 13:32:28 1: wind 225 210.211175012129
2013.11.01 13:32:28 1: wind 225 210.293335150951
2013.11.01 13:32:28 1: wind 247 210.375038844557
2013.11.01 13:32:29 1: wind 225 210.578510850976

2013.11.01 13:32:29 1: 192.168.178.20:1000 disconnected, waiting to reappear
2013.11.01 13:32:29 2: HMLAN_Parse: HMLAN1 new condition disconnected
2013.11.01 13:32:29 1: 192.168.178.20:1000 reappeared (HMLAN1)
2013.11.01 13:32:29 2: HMLAN_Parse: HMLAN1 new condition init

2013.11.01 13:32:29 2: myUtils 10 min timer called
2013.11.01 13:32:29 1: wind 225 210.658630235137
2013.11.01 13:32:29 1: wind 157 210.738304511609
2013.11.01 13:32:29 1: wind 202 210.439758375433
2013.11.01 13:32:30 1: wind 225 210.392870828903
2013.11.01 13:32:30 1: wind 225 210.47402154652
2013.11.01 13:32:30 1: wind 247 210.554721426817
2013.11.01 13:32:30 1: wind 202 210.757195196668
2013.11.01 13:32:30 1: wind 225 210.708544112242
2013.11.01 13:32:30 1: wind 225 210.787941089396
2013.11.01 13:32:31 1: wind 202 210.866896972233
2013.11.01 13:32:31 1: wind 247 210.817636433498
2013.11.01 13:32:31 1: wind 247 211.018649564423
2013.11.01 13:32:31 1: wind 225 211.218545955732
2013.11.01 13:32:32 1: wind 225 211.295109589311
2013.11.01 13:32:32 1: wind 202 211.371247869371
2013.11.01 13:32:32 1: wind 202 211.319185381208
2013.11.01 13:32:32 1: wind 225 211.26741212909
2013.11.01 13:32:32 1: wind 225 211.343704283928
2013.11.01 13:32:32 1: wind 202 211.419572593462
2013.11.01 13:32:33 1: wind 180 211.367241634609
2013.11.01 13:32:33 1: wind 225 211.192979181084
2013.11.01 13:32:33 1: wind 225 211.2696848523
2013.11.01 13:32:34 1: wind 225 211.345964380898
2013.11.01 13:32:34 1: wind 225 211.421820134338
2013.11.01 13:32:34 1: wind 225 211.497254466925
2013.11.01 13:32:34 1: wind 225 211.572269719886
2013.11.01 13:32:34 1: wind 225 211.646868221442
2013.11.01 13:32:34 1: wind 202 211.721052286879
2013.11.01 13:32:35 1: wind 157 211.667046440841
2013.11.01 13:32:35 1: wind 202 211.36334062728
2013.11.01 13:32:35 1: wind 225 211.31132206824
2013.11.01 13:32:35 1: wind 225 211.387370278972
2013.11.01 13:32:36 1: wind 225 211.462995999644
2013.11.01 13:32:36 1: wind 225 211.538201577424
2013.11.01 13:32:36 1: wind 202 211.612989346438
2013.11.01 13:32:36 1: wind 202 211.559583850069
2013.11.01 13:32:36 1: wind 225 211.506475050902
2013.11.01 13:32:36 1: wind 225 211.581439078397
2013.11.01 13:32:37 1: wind 225 211.655986639073
2013.11.01 13:32:37 1: wind 247 211.730120046634
2013.11.01 13:32:37 1: wind 180 211.926063824152
2013.11.01 13:32:37 1: wind 225 211.748696802907
2013.11.01 13:32:38 1: wind 225 211.822315154002
2013.11.01 13:32:39 1: wind 225 211.895524514257
2013.11.01 13:32:39 2: HMLAN_Parse: HMLAN1 new condition ok
2013.11.01 13:32:50 1: wind 225 211.968327155845


[daduke]

Hallo,

könnte auch wieder das hier sein: http://forum.fhem.de/index.php/topic,14893.msg102778.html#msg102778

hab's noch nicht lösen können.

Gruß,
-Christian

[herrmannj]

Guter Hinweis,

hatte zwar die Suche bemüht, den fred aber nicht gefunden.

Ich war zu der Zeit als der Hänger war nicht im Haus, bin etwa 20min vorher gegangen - hatte fhem aber vorher im browser offen.

Wäre also möglich ...

Also longpoll deaktivieren ?

Bei mir tritt das jetzt keinesfalls so häufig auf, ich beobachte das höchstens alle Tage mal. Ich könnte einen zweiten Timer aktivieren der alle 30 Sekunden feuert und selbst seine Aufrufzeit überwacht und dann bei Überschreitung einen Logeintrag generiert. Dann wäre zumindest genauer überprüfbar wie oft das tatsächlich Auftritt. Das ich das so genau sehen konnte war ja eher ein Zufall, in den meisten Fällen dürfte der Hänger unbemerkt bleiben.

Grüße
Jörg

[Joachim]

Moin herrmannj,

Du bist nicht allein.
Ich habe (hatte) das Problem auch, allerdings mit OWServer, HM-LAn und MAX.
Ich bin noch dabei, das Problem einzugrenzen, dazu habe ich ein seperates physikalisch getrenntes Subnetz geschaffen, in dem 2 FHEM installationen laufen. Diese laufen jetzt seit 2 Wochen ohne sporadische Ausfälle. Beide FHEM Installationen haben gemeinsam, dass sie auf das Netzwerk zugreifen. Entweder localhost für OWServer oder HMLan und MAX-Cube. Sowie diese beiden FHEM-Instanzen wieder in meinem normalen Netzwerk spielen gibt es wieder Aussetzer. Eine dritte FHEM-Installation läuft ganz normal im Hauptnetzwerk, und ohne Aussetzer, allerdings laufen hier auch nur Module, die nicht auf das Netzwerk zugreifen (RS232).
Bau mal folgende Zeilen in deine fhem.cfg ein

Code Auswählen Erweitern

#######################################################################################################################
##  Alive
#######################################################################################################################

define alive dummy
attr alive room Alive
attr alive setList 0 1
define at_alive at +*00:01:00 {if ("$value{alive}" == 0) {fhem("set alive 1")} else {fhem("set alive 0")}}
attr at_alive room Alive
define FileLog_alive FileLog ./log/alive-%Y-%m-%d.log alive.*
attr FileLog_alive room Alive
define SVG_FileLog_alive_1 SVG FileLog_alive:SVG_FileLog_alive_1:CURRENT
attr SVG_FileLog_alive_1 plotsize 1200,350
attr SVG_FileLog_alive_1 room Alive
dann findest du Aussetzer schneller.

Gruß Joachim

[herrmannj]

Moin Joachim,

na denn weiß ich jetzt wenigstens das ich kein Einzelfall bin

Sporadische nicht eindeutig auftretende Fehler sind natürlich die schönsten ...

Jaydee und Rudi hatten ja in dem von daduke verlinkten fred die Theorie aufgestellt das es am longpoll liegt. Den habe ich erst einmal deaktiviert und seitdem sehe ich auch keine Indizien für die Aufhänger mehr im log. Allerdings ist das auch nur wenige Stunden her und daduke war ja auch im fred und er schreibt das er es für sich noch nicht gelöst hat. Da ich mal unterstelle das er longpoll ebenfalls deaktiviert hat spricht das gegen den longpoll als (alleinige???) Ursache. Hast Du longpoll auf off ?

Wenn ich mir Dein Setup anschaue sind hast Du wahrscheinlich auch nicht ausschließlich Fritzboxen am Start ? Jaydee hat in seiner Sig auch einen Raspi angegeben. Wenn das so stimmt kann man die Fb als Verursacher  wohl ebenfalls ausschließen.

viele Grüße
Jörg

Edith:
in diesem fred http://forum.fhem.de/index.php/topic,14719.0.html hat Andyclimb den freeze auch auf ca 10min eingegrenzt. Nach dem deaktivieren des longpolls scheints zu gehen.

[Joachim]

Moin Jörg,

longpoll ist bei mir an, und mit meinem Testaufbau trotzdem keine Aussetzer, solange FHEM mit Devices, die Netzwerk brauchen in einem seperaten Subnetz hängen.
Und richtig, 2x Fritzbox (7570,7390) und eimal raspberry.

Gruß Joachim

[herrmannj]

hier: http://forum.fhem.de/index.php/topic,14719.msg95070.html#msg95070 schreibt andyclimb das er mit ausgeschaltetem longpoll "nur" noch 2min freeze sieht. (manchmal...)

Nun ist es natürlich möglich das longpoll nicht die Ursache ist sondern die Symptome einfach verschlimmert. Vielleicht aufgrund der größeren Anzahl von Verbindungen zu fhem ? Wie das jetzt mit dem setup bei Dir wo longpoll ja in einem isolierten Netz funktioniert zusammenpasst verstehe ich noch nicht.

Wie hast Du das Netz den isoliert ? Einfach den gateway weg ? Läuft dhcp oder sind die ip's statisch ?

Bei mir ist longpoll jetzt ja aus und nachdem ich weiß worauf ich achten muss schaue ich mal ob noch Aussetzer auftreten.

Ansonsten würde ich mir Deine Idee ausleihen und sie in ein kurzes Modul mit höherer Zeitauflösung klöppeln, damit könnten freeze direkt ins log geschrieben werden. Vielleicht erkennt dann ein Modulautor den Timeout wieder, muss ja irgendwas in Richtung I/O sein.

vg
Jörg

[Joachim]

Moin Jörg,

Wie hast Du das Netz den isoliert ? Einfach den gateway weg ? Läuft dhcp oder sind die ip's statisch ?

2. Fritzbox zwischengeklemmt siehe Anhang, und damit ein neues Subnetz aufgebaut, alles dahinter denkt, das WWW fängt in meinem Hauptnetz an.
Zum finden der freezes einfach den oben vorgeschlagenen alive Dummy nehmen, man erkennt im Plot sofort Unregelmäßgkeiten, und kann dann gezielt im Log suchen.
Meine Probleme kannst du in folgenden Tread nachlesen
http://forum.fhem.de/index.php/topic,14397.0.html

Nach allem, was ich bisher gefunden und gelesen habe, tendiere ich dazu, dass der Fehler irgendwo in der DevIO.pm liegen muss, aber um da anzusetzen, muss ich den Fehler ersteinmal reproduzieren und vorallem provozieren können.

Gruß Joachim

[herrmannj]

OK, damit der Fehler besser qualifiziert werden kann:

im Anhang ist ein kleines Watchdog Modul, einfach ins Modulverzeichnis kopieren und "shutdown restart". Das Modul startet und überwacht einen Timer. Wird der Timer mit mehr als 1 Sekunde Verspätung ausgeführt taucht im fhem log ein Eintrag in der Form auf:

Code Auswählen Erweitern

2013.11.01 23:59:10 1: possible freeze: timer should 22:59:09, delay is 1.70749402046204

Die Stunde Versatz ist die Zeitzone, der delay ist sec,msec ..

Mit einer Sekunde ist er bewusst "scharf" eingestellt, wird also unter Umständen auch von einem plot ausgelöst.

Damit werden eventuelle freeze mit Zeitpunkt und Dauer im log festgehalten und unter Umständen lassen sich daraus Rückschlüsse ziehen.  Irgendwo muss man ja ansetzen.

vg
Jörg

[herrmannj]

kurzer Zwischenstand:

mit abgeschaltetem longpoll keine Probleme über die Nacht.

Ich denke der Fehler lässt sich recht sicher reproduzieren: im Webinterface den Event Monitor wählen, kurz warten bis die ersten Events eintreffen und NB Deckel zu

09:25 Event Monitor an, Notebook aus:

2013.11.02 09:41:03 1: 192.168.178.20:1000 disconnected, waiting to reappear
2013.11.02 09:41:03 2: HMLAN_Parse: HMLAN1 new condition disconnected
2013.11.02 09:41:03 1: 192.168.178.20:1000 reappeared (HMLAN1)
2013.11.02 09:41:03 2: HMLAN_Parse: HMLAN1 new condition init
2013.11.02 09:41:03 1: possible freeze: timer should 08:30:35, delay is 627.290109872818

09:53 Event Monitor an, Notebook aus:

2013.11.02 10:09:45 1: 192.168.178.20:1000 disconnected, waiting to reappear
2013.11.02 10:09:45 2: HMLAN_Parse: HMLAN1 new condition disconnected
2013.11.02 10:09:45 1: 192.168.178.20:1000 reappeared (HMLAN1)
2013.11.02 10:09:45 2: HMLAN_Parse: HMLAN1 new condition init
2013.11.02 10:09:45 1: possible freeze: timer should 09:00:54, delay is 530.607181787491


Wenn der Event Monitor keine Daten mehr an den Browser los wird dauert es etwa 5 - 10 min, dann steht fhem sicher rund reproduzierbar für etwa 10 Minuten.

Ich habe mal in die fhemweb, httputils und httpserv reingeschaut - ich muss gestehen ich verstehe es nicht.

Vielleicht nimmt sich ja jemand der Sache an der die logik in den Modulen versteht. Bzw, wenn mir jemand ein kurzes Intro gibt wo ich suchen muss bin ich dabei.

Zweite Frage wäre dann ob evtl auch andere Module anfällig für dafür sind, soweit ich das verstehe geht es ja darum das ein Puffer vollgeschriebn wird für den ein Client keine Daten mehr abnimmt und wenn der Puffer voll ist dann steht fhem.

vg
Jörg

[cwagner]

Meine Erfahrung hatte ich leider nicht so systematisch wie Ihr hinterfragt: Die These, dass das "Nicht-Loswerden" von ins Web-Interface zu schreibenden Events das Problem jedenfalls befördert, habe ich auch. Und ich kann den Verdacht hinzufügen, dass nicht nur der Eventmonitor, sondern auch Module wie readingsgroups dazu beitragen, dass FHEM sekunden oder Minutenlang hängt.

Und noch eine weitere bisher nicht wirklich hinterfragte Beobachtung: Im Room Everything finde ich nach längerem Betrieb mit zahlreichen Aufrufen von FHEMWEB von Tablet (legt sich natürlich oft schlafen) und Rechner(n) eine durchaus mal 5 und mehr Positionen lange Liste á la:
FHEMWEB:XXX.XXX.XXX.XX7:53789 Connected

Die hier geXte IP-Adresse ist dann identisch, die Ports sind unterschiedlich. Nach einem Neustart gibt es mit der ersten Abfrage genau eine Zeile und die Reaktion von FHEMWeb ist "zackig".

Herzliche Grüße
Christian

[justme1968]

dir FHEMWEB zeilen gibt es für jedes browser fenster das eine verbindung zu fhem offen hat. also z.b. auch für jeden offenen tab.

readingsGroup benutz den longpoll mechanismus um sich ändernde readings zu aktualisieren. wenn longpoll in bestimmten konstellationen probleme macht wird readingsGroup diese genau so zeigen wie z.b. eine device  detail ansicht oder der der event monitor. eventuell trigger readinsGroup das problem früher als eine detail anscht einfach weil mehr readings gleichzeitig sichtbar sind aber auch nicht häufiger als der event monitor. dort ist ja alles zu sehen. readingsGroup sendet nur updates an den browser wenn wirklich ein event aufgetreten ist das zu einem reading passt das auch wierklich angezeigt wird.

man kann für readingsGroup mit 'disable 1' den update mechanismus deaktivieren. dann wird nur noch ein mal beim seitenaufbau die html ansicht erzeugt und es gibt keine updates mehr per longpoll. aktualisierte werte gibt es dann nur noch durch neu laden.

gruss
  andre

[herrmannj]

Hallo Christian,

installiere Dir doch einfach das Modul 4 Posts weiter oben. Das ist auch wirklich ganz einfach, ich habe bewusst den 99_xxUtils Mechanismus genommen damit das bequem über das Webinterface geht.

Lade den Anhang runter und öffne ihn in einem Texteditor. Geh dann in fhem einfach auf "Edit files", öffne die "99_Utils.pm", kopiere den Inhalt des Moduls rein und speichere unter "99_wdUtils.pm". (Hier bitte aufpassen damit Du die "99_Utils.pm" nicht überschreibst !).

Danach findest Du jeden Hänger im fhem log mit dem Vorteil das man nicht über "gefühlte" Hänger sprechen muss sondern klare Daten dazu hat. Immer wenn fhem länger als eine Sekunde nicht reagiert wird ein Eintrag erzeugt.


Mit den gewonnen Erkenntnissen (longpoll + svg+longpoll deaktivieren, Eventmonitor sauber beenden) auf meiner Seite jetzt seid 48h keine Hänger. Letztendlich sehe ich jetzt auch genau ob und wie lange Plots das System aufhalten. Für die Umweltdaten (Wind, Temp, Sonne, Regen etc) hatte ich sowieso radikal auf loggen nur alle 10min umgestellt, damit werden auch 48h Plots in 1-2 Sekunden von der FB geliefert.

Interessant finde ich dabei das ich früher eigentlich viele dieser 10min Freeze gehabt haben muss - die in den meisten Fällen unbemerkt geblieben sind. Du kannst Deine Vermutungen auf alle Fälle prima damit überprüfen.

Die Aussage von Andre bzgl Readingsgroup finde ich konsistent und auch Rudi scheint ja eine sehr klare Vorstellung davon zu haben woran es liegt. In einem anderen threat hat bereits gesagt das er die Sache auf der to-do Liste hat. Vermutlich werden ihm die so gewonnen Daten helfen das umzusetzen.

vg
Jörg

[cwagner]

... FHEMWEB zeilen gibt es für jedes browser fenster das eine verbindung zu fhem offen hat. also z.b. auch für jeden offenen tab.

readingsGroup benutz den longpoll mechanismus um sich ändernde readings zu aktualisieren. wenn longpoll in bestimmten konstellationen probleme macht wird readingsGroup diese genau so zeigen wie z.b. eine device  detail ansicht oder der der event monitor. eventuell trigger readinsGroup das problem früher als eine detail anscht einfach weil mehr readings gleichzeitig sichtbar sind aber auch nicht häufiger als der event monitor. dort ist ja alles zu sehen. readingsGroup sendet nur updates an den browser wenn wirklich ein event aufgetreten ist das zu einem reading passt das auch wierklich angezeigt wird.

man kann für readingsGroup mit 'disable 1' den update mechanismus deaktivieren. dann wird nur noch ein mal beim seitenaufbau die html ansicht erzeugt und es gibt keine updates mehr per longpoll. aktualisierte werte gibt es dann nur noch durch neu laden.

Vielen Dank, Andre, für die Informationen - tatsächlich habe ich in jüngerer Zeit eigentlich immer nur noch ein TAB in einem Browser zur Zeit offen - mein Hinweis auf readingsGroup war auch nicht als Kritik am von mir sehr geschätzten Modul gemeint, sondern als ein Gedanke, der vielleicht hilft, das Thema weiter einzukreisen.


Christian

[cwagner]

installiere Dir doch einfach das Modul 4 Posts weiter oben. Das ist auch wirklich ganz einfach, ich habe bewusst den 99_xxUtils Mechanismus genommen damit das bequem über das Webinterface geht.

Lade den Anhang runter und öffne ihn in einem Texteditor. Geh dann in fhem einfach auf "Edit files", öffne die "99_Utils.pm", kopiere den Inhalt des Moduls rein und speichere unter "99_wdUtils.pm". (Hier bitte aufpassen damit Du die "99_Utils.pm" nicht überschreibst !).

Das habe ich auch gleich beim Erscheinen des Posts gemacht und auch bei mir eine ganze reihe von (selbst verursachten) Gründen gefunden. Da ich soviele "Verzögerungen" hatte, scanne ich aktuell erst einmal auf alle Ereignisse, die länger als 10 Sec dauern. Und da sind tauchen die hier schon beschriebenen Anlässe auf.

Ich muss jetzt erst einmal rauskriegen, wie man ein FHEMWeb-Browserfenster so beendet, dass es nicht als Connected stehen bleibt (die längste Liste war bei mir schon mal 6 oder 8 Zeilen lang) und wie man wie von Dir beschrieben Logs ausdünnt - denn richtig: In vielen Fällen müssen die Datenpunkte gar nicht in dieser Dichte aufgezeichnet werden.

Christian