Hallo,
meine Instalation läuft jetzt schon seit längerem recht stabil (Heizungsanlage, Thermostate, Licht, Rolläden). Hin- und wieder verbessere ich noch was oder bau was an. Nun habe ich seit einigen Tagen unerklärliche Abstürze.
Die Ports der Webinstanzen sind noch offen, fhem reagiert aber nicht mehr.
Der Prozess (./startfhem) läuft zwar noch, lässt sich aber nur mit kill -9 beenden.
Es gibt keine Fehlereintragungen im log. Habe verbose schon mal hoch gesetzt.
Zuerst habe ich meine letzte Änderung im Verdacht gehabt. Hier wird bei Überschreiten einer bestimmten einstellbaren Temperatur im Pufferbehälter der Solaranlage die Umwälzpumpe der Heizung eingeschaltet und das Thermostat im Hobbyraum auf 21 Grad gestellt.
Ich habe im notify der Heizungsanlage das log eingeschaltet, aber die Bedingung wird gar nicht angesprungen, da zum Zeitpunkt des Absturzes nicht erfüllt.
Neu ist noch das Modul 70_stv, welches mir bei einem eingehenden Anruf eine Meldung auf dem TV ausgibt.
Aber auch das hat schon mehrfach funktioniert.
Für mich sieht das so aus, dass fhem irgendwo auf einen System-Call wartet.
Gibt es da eine Möglichkeit herauszufinden, wo fhem bzw. perl gerade steht?
Zum Beispiel die Ausgabe des Prozedurenstacks?
Die Heizungsanlage wird im übrigen mit den ttputils im nonblocking Mode ausgelesen, einmal pro Minute. Läuft ohne jede Probleme.
Gruß
Elektrolurch
Hast du bei dem 70_STV Modul die fork-Option gesetzt?
Was ist der letzte fhem.log Eintrag?
Auf welchen System läuft dein FHEM?
Hallo,
ZitatAuf welchen System läuft dein FHEM?
Es gibt auch FHEM-ler mit Signaturen ::)
Auf einer 7390 betreibt Elektrolurch sein FHEM.
Grüße
Edith. ja ich weiß - es gibt auch FHEM-ler die sich Signaturen nicht durchlesen können weil sie nicht angezeigt werden.
Arghhhh ja das vergesse ich immer :D Nun, es bleiben aber zwei Fragen offen :D
Hallo,
klar bleiben noch 2 Fragen offen.
Du hast dir aber seine Signatur schon angeschaut?
Grüße
Hallo,
ja, FB7390.
Nein, beim stv habe ich derzeit überhaupt keine Attribute gesetzt. Genaugenommen hatte ich es schon vor einem Jahr mal testhalber eingebunden, lief aber nicht, weil ich es in der Definition mit Angabe des Portes 62235 definiert hatte. Im Code des Moduls ist / war aber ein Bug, man darf den Port nicht angeben, wenn man den 62235 haben möchte. Das hatte ich vor ein paar Tagen festgestellt und geändert. Seit dem läuft es, aber ausführlich noch nicht getestet. Konnte alerdings noch nicht feststellen, ob zum Zeitpunkt des Absturzes überhaupt ein Telefonanruf einging und stv genutzt wurde.
Meine unix-Zeiten sind schon lange her, aber es gab da mal was, mit kill und einer Nummer an den Prozess den Prozedurstack ausgeben zu lassen.
Ob das mit perl geht, weiß ich nicht.
Jedenfalls scheint perl auf irgend etwas zu warten, Schleifen habe ich in meinem Code nicht, auch nicht über notifys die ggfs wieder ein notify triggern, dann stände das im log.
Der letzte Eintrag im log sagt nur, dass die HzAnlage (Gasbrenner) - Werte ausgelesen wurden und nach Verarbeitung die "Update-Zeit" (ein reading der Hz, welches ich mir zur Kontrolle anzeigen lasse) aktualisiert wurde. Passiert einmal je Minute.
Darin kann also kein "Absturz" oder "Hängenbleiben" programmiert sein.
Gruß
Elektrolurch
Hm....ja Puschel ich habe gelesen, dass ich keine Farben nutzen soll!
Zurück zum Problem: Ich wüßte jetzt auch nicht, wie man den Perl Stack debuggen kann.
Wie sehen denn die Filesysteme aus, ist vielleicht die Fritzbox voll?
Da ist Platz genug auf der Box, da ich von Zeit zu Zeit auch die alten debugs lösche.
Habe gerade nachgesehen: Zum Zeitpunkt des "Hängenbleibens" ist tatsächlich ein Anruf eingegange, der hatte keinen aufgelösten Namen. In dem stv-Modul werden da ohne Prüfung immer eine feste Anzahl von Parameter (set-befehl) kopiert. Da steht dann wohl ein undef mitten drin und der aufgerufene Socket kommt wohl nicht damit zurecht.
Zumindest könnte dies das Problem erklären....
Gruß
Elektrolurch
Deaktive doch mal das Modul und rufe bei dir zuhause an!
Geht nicht. Das ganze scheint nur dann "hängenzubleiben", wenn der Anrufernamen nicht ermittelt werden kann. Damit scheint das 70_stv ein Problem zu haben, der Code fragt jedenfalls nicht ab, ob da ein "undef" drin steht.
du kannst doch die rufnummer unterdrücken.
gruss
andre
Stimmt. Danke.
Mir gings eigentlich ja auch ums prinzipielle, d.h. einen Aufrufstack zu bekommen. So was gabs in C, wenn man beim Kompilieren die Symbole mit eingebunden hat.
So ein Problem, wie oben geschildert, kann ja immer mal auftreten...
Ich denke, dass es an dem 70_stv Modul liegt. Der Code im set-Befehl kopiert anscheinend eine feste Zahl von Parametern, ohne zu prüfen, ob die undef sind. Und möglicherweise mag dann der Aufruf an den Socket die Daten nicht. Aber das müsste ich mir erst einmal genauer ansehen. Habe erst einmal ein paar Workarrounds eingebaut....
Google spuckt eigentlich schnell was aus, was auf einem FB7390 (gerade getestet) funktioniert:
# cat t.pl
use Carp qw<longmess>;
sub fn3() { print longmess(); }
sub fn2() { fn3(); }
sub fn1() { fn2(); }
fn1();
# perl t.pl
at t.pl line 3
main::fn2() called at t.pl line 4
main::fn1() called at t.pl line 5
Fuer Leute die sich mit Unix besser auskennen (oder viel Zeit haben) kann http://fhem.de/fb7390/strace auch helfen.
Hallo,
leider habe ich immer noch das Problem, das fhem manchmal drei Tage, manchmal nur einige Stunden durchläuft und dann hängen bleibt (s.o.).
Was kann ich derzeit ausschließen:
1. Speicherplatz ist genügend frei auf der Box.
2. longpoll habe ich für die Web-Instanzen deaktiviert.
3. Wenn fhem hängen bleibt, sind keine Verbindungen zum Webserver oder telnet offen.
4. Wenn fhem hängen bleibt, zeigt strace keine Prozeduraufrufe an.
5. Ich habe jetzt fhem mit strace über drei Tage laufen lassen und zwischenzeitlich immer wieder das log wg. Plattenplatz gelöscht, da blieb fhem nicht hängen.
6. Das Modul STV kann ich definitiv ausschließen, da der Hängenbleiber auch bei deaktiviertem device auftritt (s.o. mein Verdacht)
7. Auf der FB verwende ich derzeit OS 6.03, welches schon seit Monaten läuft, genauso wie die fhem-Software. Das unregelmässige Hängenbleiben von fhem tritt aber erst seit ca. 3 Wochen auf. Grundsätzliche Codeergänzungen habe ich aber in den letzten Wochen nicht gemacht.
Über entsprechende Log-File Ausgaben habe ich überprüft, ob sich da ev. doch eine Endlosschleife über notify - setreading oder ähnliches ergeben haben könnte: negativ.
Die Hängenbleiber sind auch mit keinem Event zu korrellieren.
8. Ich habe mal eine Routine geschrieben, die im fehm-Baum die Werte, readings usw. auf undefs überprüft. Dabei ist mir aufgefallen, dass das fht-Modul, durch das Umbenennen des devices wohl etwas Probleme mit den automatisch angelegten logs und plots hat. (logfile -> interne Variable nr wird beim save als undef bemeckert). Daher habe ich mal vorsichtshalber die plots und logs zu den fht-devices gelöscht. Brachte aber auch kein Ergebnis.
Derzeit habe ich einen Workaround gebastelt:
fhem schreibt über ein "at" alle 10 Minuten einen Zeitstempel in eine Datei. Ein kleines Skript prüft den Inhalt dieser Datei alle 10 Minuten. Ist der Zeitstempel älter, wird die pid von fhem ermittelt und der Prozeß gekillt und dann ./startfhem& aufgerufen.
Leider löst das nicht das Problem.
Hat jemand eine Idee, was man noch prüfen könnte? Oder wie man das Problem weiter einkreisen könnte?
Ich habe zwar noch einige Backups von fhem seit dem 2.5.2014 und könnte diese zurückspielen, dann weiß ich aber immer noch nicht, was die Ursache für das Problem sein könnte.
Gruß
Schnief, schnief
Elektrolurch
Ich wuerde FHEM mit "attr global verbose 5" laufen lassen, und falls es wieder haengen bleibt, hier die letzten 50-100 Zeilen aus dem Log posten.
Man muss in dieser Zeit den Plattenplatz ueberwachen, und notfalls logfile wechseln (attr global filelog <neue-dateiname>), damit man die alte Datei loeschen kann.
Hallo Rudi,
werde ich versuchen.
Mir ist aber noch etwas aufgefallen:
Bei manchen "Hängenbleibern" gibt es zusätzlich ein fhem-logfile mit Datum 1.1.1970, leerem Inhalt, kein Änderungs- oder Erstellungsdatum.
1.1.1970 ist ja das Unix-Urdatum. Aus irgendeinem Beitrag habe ich noch in Erinnerung, dass fhem auf einer FB nicht startet, wenn das Datum nicht gesetzt ist.
Könnte es vielleicht sein, das der ntp - Dienst auf der FB gelegentlich Mist zurückliefert und daher fhem dann hängenbleibt?
Wenn fhem ja läuft, so sagt strace, dass es meistens zwischen select und time() "herumkurvt".
Wie gesagt: Die fhem-1970-1-1.log - Datei ist nicht bei jedem Hängenbleiber vorhanden.
So drei oder vier Mal war sie da.
Gruß
Elektrolurch
Klingt merkwuerdig.
NTP setzt nicht die Zeit ohne weiteres, und schon gar nicht aut 1970.
Bist Du sicher, dass das FB nicht ein reboot durchgefuehrt hat (siehe uptime)?
Das mit der 1970er Zeit habe ich auf meiner 7390 auch nachdem die Fritte neustartet und fhem
vor der DSL Synchronisation startet. Sieht so aus, als ob die Fritte einfach im Betrieb abraucht. Vielleicht ein Memory Problem?
Hallo,
leider nicht. Die FB läuft ohne Neustart durch. Habe gerade mal die ganzen Ereignisanzeigen durchgesehen. Der letzte Eintrag, welche was mit Zeit zu tun hat, ist vom 25.6., da stteht, dass die Zeit erfolgreich synchronisiert wurde.
Heute ist fhem um 11:42 Uhr(wurde dann durch meinen watchdog neu gestartet) und dann wieder gegen 14:00 Uhr hängengeblieben. Im Ereignisprotokoll der FB gibt es um die besagten Zeiten keinerlei Ereignisse, rein gar nichts.
Jetzt läuft fhem mit "attr global verbose 5". Habe den Standardlogfilenamen auf "tagesweise" log umgestellt, damit ich dann die unnötigen Infos nach 24 h löschen kann. Mal sehen, wie lange fhem jetzt durch läuft.
Können auch 3 Tage werden, ist nicht vorhersehbar.
Bin für jeden Tipp dankbar.
Gruß
Elektrolurch
Hallo,
da das Hängenbleiben von fhem nur sporadisch passiert, war das Einkreisen einr möglichen Ursache schwierig.
Seit dem ich attr global verbose 5 gesetzt hatte, blieb fhem nur einmal Hängen. So wie das aussieht, (s.u.) liegt es u.U. an dem 10_FBDECT - Modul.
Ich habe eine dect200 im Einsatz, die ist aber zwei Geschoßdecken entfernt und gelegentlich hatte ich so Eintragungen im log wie: ..out of sync.. reseting buffer...
Ich habe die dect200 jetzt mal deaktiviert, mal sehen, ob nun fhem wie gewohnt stabil durchläuft.
Hier das log, vor dem Hängenbleiber. Ich verstehe zwar das Modul nicht so ganz, aber an einer Stelle wird ein String zerlegt, ohne vorher abzufragen, ob der überhaupt vorhanden ist, bzw. die erwartete Länge hat.
2014.07.03 17:44:24 5: FBAHA/RAW: /070300200000001200100000000000100000002300080000000000010000ffff
2014.07.03 17:44:24 5: DECT200 dispatch 070300200000001200100000000000100000002300080000000000010000ffff
2014.07.03 17:44:24 5: FBAHA/RAW: /0703001c00000012001000000000000c0000000f0004000000000000
2014.07.03 17:44:24 5: DECT200 dispatch 0703001c00000012001000000000000c0000000f0004000000000000
2014.07.03 17:44:24 5: FBAHA/RAW: /0703001c00000012001000000000000c000000140004000000000000
2014.07.03 17:44:24 5: DECT200 dispatch 0703001c00000012001000000000000c000000140004000000000000
2014.07.03 17:44:24 5: FBAHA/RAW: /0703001c00000012001000000000000c000000130004000000038844
2014.07.03 17:44:24 5: DECT200 dispatch 0703001c00000012001000000000000c000000130004000000038844
2014.07.03 17:44:24 5: FBAHA/RAW: /0703001c00000012001000000000000c000000120004000000000000
2014.07.03 17:44:24 5: DECT200 dispatch 0703001c00000012001000000000000c000000120004000000000000
2014.07.03 17:44:24 5: FBAHA/RAW: /0703001c00000012001000000000000c000000150004000000003a54
2014.07.03 17:44:24 5: DECT200 dispatch 0703001c00000012001000000000000c000000150004000000003a54
2014.07.03 17:44:24 5: FBAHA/RAW: /0703001c00000012001000000000000c000000160004000000000000
2014.07.03 17:44:24 5: DECT200 dispatch 0703001c00000012001000000000000c000000160004000000000000
2014.07.03 17:44:24 5: FBAHA/RAW: /070300200000001200100000000000100000002300080000000000010000ffff
2014.07.03 17:44:24 5: DECT200 dispatch 070300200000001200100000000000100000002300080000000000010000ffff
2014.07.03 17:44:25 5: FBAHA/RAW: /040301240000001200100200000000090000128054657374737465636b646f73650000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000b74303837363120303032383432390000000000000030332e3230000000000000000000000000000000000000000000000200100000000000840000000f00040000000000000000002300080000000000010000ffff00000025002400000000001000000001000000010000001400000005000001f40000003c0000000f00000000000000120004000000000000000000130004000000038844
2014.07.03 17:44:25 5: FBAHA/RAW: 040301240000001200100200000000090000128054657374737465636b646f73650000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000b74303837363120303032383432390000000000000030332e3230000000000000000000000000000000000000000000000200100000000000840000000f00040000000000000000002300080000000000010000ffff00000025002400000000001000000001000000010000001400000005000001f40000003c0000000f00000000000000120004000000000000000000130004000000038844/0703002000000012001000000000001000000023000800000000ffff00000000
2014.07.03 17:44:26 5: FBAHA/RAW: 040301240000001200100200000000090000128054657374737465636b646f73650000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000b74303837363120303032383432390000000000000030332e3230000000000000000000000000000000000000000000000200100000000000840000000f00040000000000000000002300080000000000010000ffff00000025002400000000001000000001000000010000001400000005000001f40000003c0000000f000000000000001200040000000000000000001300040000000388440703002000000012001000000000001000000023000800000000ffff00000000/0703003c00000012001000000000002c00000025002400000000001000000001000000010000001400000005000001f40000003c0000000f00000000
2014.07.03 17:44:26 5: DECT200 dispatch 040301240000001200100200000000090000128054657374737465636b646f73650000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000b74303837363120303032383432390000000000000030332e3230000000000000000000000000000000000000000000000200100000000000840000000f00040000000000000000002300080000000000010000ffff00000025002400000000001000000001000000010000001400000005000001f40000003c0000000f000000000000001200040000000000000000001300040000000388440703002000000012001000000000001000000023000800000000ffff000000000703003c
Gruß
Elektrolurch
Hallo,
nun war es heute nacht um 01:26 Uhr mal wieder so weit. fhem blieb hängen bis mein watchdog es nach 10 Minuten neu startete. Wieder waren Die letzten Eintragungen kommen von der dect200 (s.u.). Dort scheint der Fehler beim "dispatch" der Daten zu liegen.
Was kann man dagegen tun (außer als die dect200 aus fhem herauszunehmen :-))?
Jetzt sind die Experten gefragt....
Gruß
Elektrolurch
2014.07.06 01:21:55 5: FBAHA/RAW: /070300200000000700100000000000100000002300080000000000010000ffff
2014.07.06 01:21:55 5: DECT200 dispatch 070300200000000700100000000000100000002300080000000000010000ffff
2014.07.06 01:21:55 5: FBAHA/RAW: /0703001c00000007001000000000000c0000000f0004000000000000
2014.07.06 01:21:55 5: DECT200 dispatch 0703001c00000007001000000000000c0000000f0004000000000000
2014.07.06 01:21:55 5: FBAHA/RAW: /0703001c00000007001000000000000c000000140004000000000000
2014.07.06 01:21:55 5: DECT200 dispatch 0703001c00000007001000000000000c000000140004000000000000
2014.07.06 01:21:55 5: Triggering ts (1 changes)
2014.07.06 01:21:55 5: Notify loop for ts power: 0.00 W
2014.07.06 01:21:55 5: Alle_Geraete_im_Haus: not on any display, ignoring notify
2014.07.06 01:21:55 5: ts2: not on any display, ignoring notify
2014.07.06 01:21:55 5: Triggering ts_notify
2014.07.06 01:21:55 4: ts_notify exec {ts_not($NAME,$EVENT);;}
2014.07.06 01:21:55 5: Cmd: >{ts_not($NAME,$EVENT);}<
2014.07.06 01:21:55 5: FBAHA/RAW: /0703001c00000007001000000000000c00000013000400000003829c
2014.07.06 01:21:55 5: DECT200 dispatch 0703001c00000007001000000000000c00000013000400000003829c
2014.07.06 01:21:55 5: FBAHA/RAW: /0703001c00000007001000000000000c000000120004000000000000
2014.07.06 01:21:55 5: DECT200 dispatch 0703001c00000007001000000000000c000000120004000000000000
2014.07.06 01:21:55 5: FBAHA/RAW: /0703001c00000007001000000000000c000000150004000000003a61
2014.07.06 01:21:55 5: DECT200 dispatch 0703001c00000007001000000000000c000000150004000000003a61
2014.07.06 01:21:55 5: FBAHA/RAW: /0703001c00000007001000000000000c000000160004000000000000
2014.07.06 01:21:55 5: DECT200 dispatch 0703001c00000007001000000000000c000000160004000000000000
2014.07.06 01:21:55 5: FBAHA/RAW: /070300200000000700100000000000100000002300080000000000010000ffff
2014.07.06 01:21:55 5: DECT200 dispatch 070300200000000700100000000000100000002300080000000000010000ffff
2014.07.06 01:21:56 5: FBAHA/RAW: /040301240000000700100200000000090000128054657374737465636b646f73650000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000b74303837363120303032383432390000000000000030332e3230000000000000000000000000000000000000000000000200100000000000840000000f00040000000000000000002300080000000000010000ffff00000025002400000000001000000001000000010000001400000005000001f40000003c0000000f0000000000000012000400000000000000000013000400000003829c
2014.07.06 01:21:56 5: FBAHA/RAW: 040301240000000700100200000000090000128054657374737465636b646f73650000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000b74303837363120303032383432390000000000000030332e3230000000000000000000000000000000000000000000000200100000000000840000000f00040000000000000000002300080000000000010000ffff00000025002400000000001000000001000000010000001400000005000001f40000003c0000000f0000000000000012000400000000000000000013000400000003829c/0703002000000007001000000000001000000023000800000000ffff00000000
2014.07.06 01:21:56 5: FBAHA/RAW: 040301240000000700100200000000090000128054657374737465636b646f73650000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000b74303837363120303032383432390000000000000030332e3230000000000000000000000000000000000000000000000200100000000000840000000f00040000000000000000002300080000000000010000ffff00000025002400000000001000000001000000010000001400000005000001f40000003c0000000f0000000000000012000400000000000000000013000400000003829c0703002000000007001000000000001000000023000800000000ffff00000000/0703003c00000007001000000000002c00000025002400000000001000000001000000010000001400000005000001f40000003c0000000f00000000
2014.07.06 01:21:56 5: DECT200 dispatch 040301240000000700100200000000090000128054657374737465636b646f73650000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000b74303837363120303032383432390000000000000030332e3230000000000000000000000000000000000000000000000200100000000000840000000f00040000000000000000002300080000000000010000ffff00000025002400000000001000000001000000010000001400000005000001f40000003c0000000f0000000000000012000400000000000000000013000400000003829c0703002000000007001000000000001000000023000800000000ffff000000000703003c
... und jetzt kommt 10 Minuten später der Neustart
2014.07.06 01:26:20 5: Initializing Type Library:
2014.07.06 01:26:20 1: Including fhem.cfg
Ich habe versucht die letzte Meldung zu analysieren, das kann man auch "trocken" ohne FBAHA mit
{ Dispatch($defs{fbaha}, "040301240000000700100200000000090000128054657374737465636b646f73650000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000b74303837363120303032383432390000000000000030332e3230000000000000000000000000000000000000000000000200100000000000840000000f00040000000000000000002300080000000000010000ffff00000025002400000000001000000001000000010000001400000005000001f40000003c0000000f0000000000000012000400000000000000000013000400000003829c0703002000000007001000000000001000000023000800000000ffff000000000703003c", undef) }
wobei fbaha vorher angelegt werden muss (Typ FBAHA).
Dabei kam raus, dass FHEM ein haufen Perl warnings (Use of uninitialized value) auspuckt, da die Nachricht irgendwie nicht vollstaendig ist, aber ueberlebt. Ich habe FBDECT/FBAHA modifiziert, damit die Probleme bei verbose 4 im Logfile landen.
Weiterhin unklar fuer mich ist wieso die Nachricht zu kurz ist (evtl copy&paste Fehler?), und wieso FHEM sich aufhaengt.
Ich wuerde mich freuen, wenn du diese aktuelle Version verwendest, sie enthaelt zusaetzlich eine relevante Debug-Meldung beim Verlassen der FBDECT_Parse Funktion. Ich habe sie diesmal direkt fuer upload zur Verfuegung gestellt.
Gruss,
Rudi
Hallo Rudi,
update läuft schon. Kopiert habe ich alles, denn die zwei Zeilen vom Neustart waren ja auch dabei.
Danke für die Unterstützung. Ich denke, dass das Problem an dem Funksignal liegt, was sporadisch "kaputt" ankommt.
Da sind ja für type = 4 und 7 in dem dispatch - Teil zwei while - Schleifen, vielleicht bleibt ja fhem da hängen, wenn die Daten nicht stimmen....
Es reicht ja dann, für das dect-Teil verbose auf 4 zu setzen.
Mal sehen... und Danke.
Gruß
Elektrolurch
Hallo,
sowie das aussieht, war es wohl das 10_FBDECT - Modul. Dank der Änderungen von Rudi kommt zwar nun ein log-Eintrag (sowas wie unknown Message 0), aber fhem bleibt nicht mehr hängen.
Wie schon oben gesagt, die Distanz zur FB geht über drei Geschoßdecken und da gehen wohl ab und zu mal dect-Gignale verstümmelt über den Äther.
Danke an Rudi für die Unterstützung.
Gruß
Elektrolurch
10_FBDECT.pm konnte vor den aktuellen Aenderungen in eine Endlosschleife kommen, wenn die Nutzdatenlaenge eines Teilpaketes mit 0 angegeben wurde.
Ich verstehe zwar nicht, wieso solche Pakete zustande kommen koennen (vermutlich ist der AHA-Server auf dem FB auch noch nicht fehlerfrei), aber im aktuellen 10_FBDECT.pm sollte so eine Endlosschleife nicht mehr vorkommen.
Schön, wenn sich wieder mal ein Problem gelöst hat. Vielen Dank.
Ich habe zwar keine Dect200, aber ebenfalls sporadische Abstürze von FHEM. Der Perl Task läuft dann nicht mehr und ein Neustart auf der Telnet Konsole startet FHEM wieder normal an. Das Log gibt mir leider auch keine ordentliche Antwort. Soll ich jetzt auch mal global verbose 5 probieren? Neuer Thread oder hier? Danke!
Sent from my iPhone using Tapatalk
Ja, Ja.