Hallo zusammen
ich habe seit einigen tagen festgestellt, das mein Fhem immer wieder "hängt"
im Log finde ich dann diese Zeile
2017.04.01 21:00:05 3: FritzBox7490: read from http://192.xxx.xxx.xxx:80 timed out
ich habe dies auch nur bei diesem Fhem server - alle anderen funktionieren
rufe ich die FB im Webbrauser auf, ist sie sofort da und es lässt sich auch einloggen, dagegen ist an den FHEM server per webbrauser kein arbeiten mehr möglich - bzw es muss erst neu rebootet werden - über den script startet fhem nicht neu
2017.04.01 21:07:10 2: HarmonyHubWZ: disconnect
2017.04.01 21:07:10 2: HarmonyHubFE1: disconnect
2017.04.01 21:07:33 3: HarmonyHubWZ: connected
2017.04.01 21:07:33 3: HarmonyHubFE1: connected
2017.04.01 21:07:56 2: HarmonyHubFE: disconnect
2017.04.01 21:08:40 3: HarmonyHubFE: connected
2017.04.01 21:09:14 2: HarmonyHubFE1: disconnect
2017.04.01 21:09:30 3: FBDECT set FBDECT_FritzBox7490_08761_0254471 off
2017.04.01 21:09:30 2: HarmonyHubWZ: disconnect
2017.04.01 21:09:31 3: FritzBox7490: write to http://192.168.1.10:80 timed out
2017.04.01 21:09:32 3: HarmonyHubFE1: connected
2017.04.01 21:10:19 3: HarmonyHubWZ: connected
2017.04.01 21:10:20 3: FritzBox7490: write to http://192.168.1.10:80 timed out
2017.04.01 21:11:15 2: HarmonyHubFE: disconnect
2017.04.01 21:12:06 3: TempSZ: IF: expected ELSE: (set Rolladen pct 100)
2017.04.01 21:12:07 3: HarmonyHubFE: connected
2017.04.01 21:12:10 2: HarmonyHubFE1: disconnect
2017.04.01 21:12:27 2: HarmonyHubWZ: disconnect
2017.04.01 21:13:03 3: HarmonyHubFE1: connected
2017.04.01 21:13:03 3: HarmonyHubWZ: connected
kann mir bitte jemand einen Rat geben, woran das liegt? das was ich im Forum gefunden habe, mit dem Update - hat bei mir nicht geholfen
gruss tagedieb
Hi,
das mit den Disconnects bei den HarmonyHubs sieht ja auch nicht so toll aus.
Kann es sein, dass Du irgendwelche Blockierer auf Deinem System hast? Hast Du schonmal nachgeschaut, was bei apptime rauskommt?
Gruß,
Thorsten
Guten Morgen Thorsten
danke das du dir Zeit für mein Problem nimmst
die HarmonyHubs habe ich ersteinmal deaktiviert, so funktioniert es schon einiges besser , doch beim Neustarten erscheint die Fehlermeldung(ich weiss aber nicht, ob das mit dem Start von Fhem zu tun hat)
- daher apptime ohne Harmony name function max count total average maxDly
HMLAN1 HMLAN_Read 593 3 1254 418.00 0 HASH(HMLAN1)
HMLAN2 HMLAN_Read 132 2 146 73.00 0 HASH(HMLAN2)
HMLAN3 HMLAN_Read 131 2 137 68.50 0 HASH(HMLAN3)
tmr-BlockingKill HASH(0x3130198) 88 1 88 88.00 822 HASH(0x3130198)
tmr-MilightBridge_DoPingStart HASH(0x471b618) 61 2 116 58.00 108 HASH(milight)
tmr-FRITZBOX_Readout_Start Fritzbox.Readout 58 1 58 58.00 1046 Fritzbox.Readout
tmr-PRESENCE_StartLocalScan HASH(0x486a7a0) 58 1 58 58.00 268 HASH(NAS_Lenovo)
tmr-PRESENCE_StartLocalScan HASH(0x4b7f140) 52 1 52 52.00 835 HASH(Firmenpc)
tmr-BlockingKill HASH(0x6e8b998) 40 1 40 40.00 1498 HASH(0x6e8b998)
tmr-BlockingKill HASH(0x33515d8) 37 1 37 37.00 795 HASH(0x33515d8)
tmr-BlockingKill HASH(0x3822e20) 36 1 36 36.00 1860 HASH(0x3822e20)
tmr-BlockingKill HASH(0x5510f28) 35 1 35 35.00 139 HASH(0x5510f28)
tmr-BlockingKill HASH(0x6644aa8) 35 1 35 35.00 1590 HASH(0x6644aa8)
tmr-BlockingKill HASH(0x6e8b9e0) 35 1 35 35.00 1646 HASH(0x6e8b9e0)
tmr-BlockingKill HASH(0x6ea1820) 35 1 35 35.00 1778 HASH(0x6ea1820)
tmr-BlockingKill HASH(0x3405e78) 32 1 32 32.00 440 HASH(0x3405e78)
tmr-BlockingKill HASH(0x4d6e868) 32 1 32 32.00 1017 HASH(0x4d6e868)
tmr-BlockingKill HASH(0x6649bf0) 32 1 32 32.00 367 HASH(0x6649bf0)
tmr-BlockingKill HASH(0x4859a68) 31 1 31 31.00 928 HASH(0x4859a68)
tmr-BlockingKill HASH(0x4d6e370) 31 1 31 31.00 209 HASH(0x4d6e370)
tmr-BlockingKill HASH(0x4d6ee50) 31 1 31 31.00 293 HASH(0x4d6ee50)
gruss Annette
Hi,
mmm, da sind zumindest mal keine richtigen Blockierer dabei.
Ist denn das Problem aufgetreten, während apptime aktiv war? D.h. apptime eingeschaltet, dann das Problem beobachtet, dann apptime angezeigt?
Auf was für einer Hardware läuft das denn? RasPi oder was "größeres"?
Gruß,
Thorsten
Hallo Thorsten
Fhem läuft auf einem Cubitruck - es sind hier auch nur Anwendungen installiert, welche ich für Fhem benötige, der Alexa- und Apacheserver laufen auf einem anderen Cubitruck
als ich apptime aufgerufen habe lief er "schnell" genau wie nach einem Neustart oder einem reboot der FB , nach einer bestimmetn Zeit hängt es wieder - so wie gerade eben
name function max count total average maxDly
tmr-INDEGO_GetStatus HASH(0x4fc7150) 36897 958 68511 71.51 88564 HASH(Schaf)
HMLAN1 HMLAN_Read 23722 785 1287144 1639.67 0 HASH(HMLAN1)
HMLAN3 HMLAN_Read 23498 710 1243785 1751.81 0 HASH(HMLAN3)
HMLAN2 HMLAN_Read 23193 795 1248187 1570.05 0 HASH(HMLAN2)
tmr-harmony_connect HASH(0x5cba070) 10151 540 15361 28.45 64396 HASH(DVD)
tmr-harmony_connect HASH(0x5cb9d88) 10019 541 14218 26.28 66327 HASH(Fernseher)
tmr-harmony_connect HASH(0x5cba240) 10014 541 14014 25.90 76341 HASH(LGSoundbar)
tmr-CUL_HM_ActCheck ActionDetector 2385 14 7240 517.14 61336 ActionDetector
tmr-JSONREADINGS_GetStatus HASH(0x496f470) 1965 14 16741 1195.79 61499 HASH(wu_conditions)
tmr-CustomReadings_read HASH(0x4590e58) 1854 140 105924 756.60 81704 HASH(myCubie)
tmr-at_Exec HASH(0x3b9abe8) 1675 10 7296 729.60 62566 HASH(at_FHEM.save)
HMLAN3 HMLAN_Ready 1582 8 2875 359.38 0 HASH(HMLAN3)
tmr-HMCCU_ReadRPCQueue HASH(0x5546558) 1573 9487 86479 9.12 92376 HASH(CCU2)
AMADCommBridge_192.168.1.121_47172 AMAD_CommBridge_Read 1517 1 1517 1517.00 0 HASH(AMADCommBridge_192.168.1.121_47172)
tmr-HttpUtils_Err HASH(0x7419068) 1418 1 1418 1418.00 3206 HASH(0x7419068)
Haustuer_open notify_Exec 1394 8 5253 656.62 0 HASH(Haustuer_open); HASH(Sensor_Haustuer)
tmr-SYSMON_Update HASH(0x49d2ac0) 1342 139 33042 237.71 81755 HASH(sysmon)
Haustuer_closed notify_Exec 1328 8 5085 635.62 0 HASH(Haustuer_closed); HASH(Sensor_Haustuer)
CUL_HM_HM_LC_SW1_FM_21B07F CUL_HM_Set 1322 122 4422 36.25 0 HASH(CUL_HM_HM_LC_SW1_FM_21B07F); CUL_HM_HM_LC_SW1_FM_21B07F; off
tmr-AMAD_checkDeviceState HASH(0x5428a28) 1282 87 9194 105.68 72504 HASH(Samsung_Duos)
tmr-HttpUtils_Err HASH(0x6d85b88) 1274 1 1274 1274.00 29975 HASH(0x6d85b88)
das ist die log dazu
2017.04.02 11:24:44 3: CUL_HM set CUL_HM_HM_LC_SW1_FM_21B07F off
[Sun Apr 2 11:25:12 2017] fhem.pl: Argument "off" isn't numeric in numeric lt (<) at (eval 62422) line 1.
2017.04.02 11:25:42 3: FritzBox7490: read from http://192.168.1.10:80 timed out
[Sun Apr 2 11:26:22 2017] fhem.pl: Argument "off" isn't numeric in numeric lt (<) at (eval 63311) line 1.
[Sun Apr 2 11:26:30 2017] fhem.pl: Argument "off" isn't numeric in numeric lt (<) at (eval 63335) line 1.
2017.04.02 11:26:35 3: Nmap (Netzsearch) - starting network scan
[Sun Apr 2 11:26:37 2017] fhem.pl: Argument "off" isn't numeric in numeric lt (<) at (eval 63357) line 1.
[Sun Apr 2 11:26:42 2017] fhem.pl: Argument "off" isn't numeric in numeric lt (<) at (eval 63370) line 1.
[Sun Apr 2 11:26:48 2017] fhem.pl: Argument "off" isn't numeric in numeric lt (<) at (eval 63418) line 1.
[Sun Apr 2 11:26:54 2017] fhem.pl: Argument "off" isn't numeric in numeric lt (<) at (eval 63465) line 1.
[Sun Apr 2 11:26:59 2017] fhem.pl: Argument "off" isn't numeric in numeric lt (<) at (eval 63514) line 1.
2017.04.02 11:27:06 1: 192.168.1.91:1000 disconnected, waiting to reappear (HMLAN3)
2017.04.02 11:27:06 1: HMLAN_Parse: HMLAN3 new condition disconnected
2017.04.02 11:27:07 1: devStateIcon Taster_Garage: Undefined subroutine &main::Taster_Garage_devStateIcon called at (eval 63559) line 1.
2017.04.02 11:27:08 1: 192.168.1.95:1000 disconnected, waiting to reappear (HMLAN1)
2017.04.02 11:27:09 1: HMLAN_Parse: HMLAN1 new condition disconnected
2017.04.02 11:27:13 1: HMLAN_Parse: HMLAN1 new condition init
2017.04.02 11:27:13 1: 192.168.1.95:1000 reappeared (HMLAN1)
2017.04.02 11:27:13 1: HMLAN_Parse: HMLAN3 new condition init
2017.04.02 11:27:14 1: 192.168.1.91:1000 reappeared (HMLAN3)
jedoch die Fehler von netzsearch kamen jetzt das erste mal (sicherlich durch das timeout)
die dauernden Verbindungsabbrüche der HMLANs sind erst nach dem gestrigen Update
gruss annette
Hi,
also auf den ersten Blick sieht das ziemlich übel aus. Bist Du sicher, dass das letzte update sauber durchgelaufen ist? Was sagt "update check"?
Ich würde an Deiner Stelle ansonsten mal versuchen, diese apptime-Einträge von oben abzuarbeiten. Das ganze ist in Millisekunden. D.h. z.B. dass die erste Zeile (tmr-INDEGO_GetStatus) fast 37 Sekunden blockiert hat. So etwas darf nicht passieren. Da müsstest Du Dich wahrscheinlich durch die verschiedenen Module arbeiten und das dann ggf. in den entsprechenden Unterforen posten.
...oder das sind z.T. "at"s, in denen Du irgend etwas "schlimmes" machst.
Gruß,
Thorsten
Hallo Thorsten
ich bin mir sicher das das letzte update NICHT sauber gelaufen ist - denn danach hatte ich bei den HMLANs nur disconnect
nach einem backup und einem erneuten update hatte ich dann diese Phänomene
der Rasenmäher hat ein ellenlanges Doif abzuarbeiten - das kommt einigermassen hin, doch die dauernden Hmlan abbrüche setzten das sytem quasi lahm - Rolläden gehen teilweise 4 Min später in Position
Update zeigt mir eine Datei an - die ich jedesmal rausschmeisse, da sie mir Geräte löscht - die ältere Version arbeitet wunderbar, hier habe ich mir schon detailierte Notizen gemacht, doch ich wollte vorher prüfen, ob das an meinen Fehlern liegt, denn ich habe es immer noch nicht "geschafft" alte Schreibweisen in die neuen umzuwandel :-[
so sieht ein apptime nach einem restart aus
name function max count total average maxDly
HMLAN1 HMLAN_Read 1385 1 1385 1385.00 0 HASH(HMLAN1)
tmr-PRESENCE_StartLocalScan HASH(0x3a64970) 58 1 58 58.00 7 HASH(Foscam)
tmr-MilightBridge_DoPingStart HASH(0x4cf0fb0) 56 1 56 56.00 497 HASH(milight)
tmr-BlockingKill HASH(0x75aa6f0) 36 1 36 36.00 597 HASH(0x75aa6f0)
tmr-INDEGO_GetStatus HASH(0x57cc258) 15 1 15 15.00 11 HASH(Schaf)
HMLAN3 HMLAN_Read 8 1 8 8.00 0 HASH(HMLAN3)
WEBALEXA_192.168.1.86_39453 FW_Notify 7 1 7 7.00 0 HASH(WEBALEXA_192.168.1.86_39453); HASH(BMAussen)
tmr-harmony_connect HASH(0x628faa0) 7 1 7 7.00 6 HASH(DVD)
tmr-HMCCU_ReadRPCQueue HASH(0x5b1d588) 6 18 71 3.94 1067 HASH(CCU2)
tmr-harmony_connect HASH(0x628f7b8) 6 1 6 6.00 7 HASH(Fernseher)
tmr-harmony_connect HASH(0x628fc50) 6 1 6 6.00 26 HASH(LGSoundbar)
Power62_auto DOIF_Notify 4 1 4 4.00 0 HASH(Power62_auto); HASH(BMAussen)
Shutter_up DOIF_Notify 4 1 4 4.00 0 HASH(Shutter_up); HASH(BMAussen)
WEB_192.168.1.131_49593 FW_Notify 4 1 4 4.00 0 HASH(WEB_192.168.1.131_49593); HASH(BMAussen)
WEBphone_192.168.1.138_50468 FW_Notify 4 1 4 4.00 0 HASH(WEBphone_192.168.1.138_50468); HASH(BMAussen)
WEBphone_192.168.1.138_50469 FW_Notify 4 1 4 4.00 0 HASH(WEBphone_192.168.1.138_50469); HASH(BMAussen)
di_battery DOIF_Notify 4 1 4 4.00 0 HASH(di_battery); HASH(BMAussen)
tmr-ENIGMA2_GetStatus HASH(0x516c788) 4 1 4 4.00 7 HASH(SATReceiver)
tmr-ENIGMA2_GetStatus HASH(0x516dc18) 4 1 4 4.00 1 HASH(VUSE)
BMAussen CUL_HM_Set 3 4 9 2.25 0 HASH(BMAussen); BMAussen; ?
2ETor_auf notify_Exec 1 1 1 1.00 0 HASH(2ETor_auf); HASH(BMAussen)
wenn noch alles flüssig läuft
ich bin sehr froh, das du mir schon einige Ansatzpunkte zur beseitung zeigen konntes
gruss annette
Zitat von: tagedieb am 02 April 2017, 12:07:29der Rasenmäher hat ein ellenlanges Doif abzuarbeiten - das kommt einigermassen hin,
Ach, deswegen "Schaf" :)
Das Problem ist folgendes: Wenn Du da tatsächlich etwas hast, das 36 Sekunden dauert, dann disconnecten alle HMLANs zwangsläufig. Die Dinger bekommen alle 25 Sekunden ein "KeepAlive" geschickt, brauchen das aber mindestens alle 30 Sekunden. Wenn Du also 36 Sekunden blockierst, dann sagen alle HMLANs tschüss. Möglicherweise haben die Harmonys ein ähnliches Problem.
Du solltest Dir überlegen, wie Du das ganze geeignet zerlegst, so dass die einzelnen Teile am besten weniger als eine Sekunde brauchen. ...im Worst Case!
ZitatUpdate zeigt mir eine Datei an - die ich jedesmal rausschmeisse, da sie mir Geräte löscht
Welche Datei?
Gruß,
Thorsten
Hallo Thorsten
danke für deine Erklärungen - es hilft mir stets mehr, als fertig präsentierte Lösungen
mehr als 36 sekunden dauert laut Event Monitor gar nichts, selbst die 12 FBDECT, welche auf einmal abgefragt werden, dauern 5 Sekunden :-[
die besagte Datei: 88_HMCCU.pm nach dem update hat sie nur noch 176 kib und es wurden 4 geräte gelöscht - gebe ich sie ein, fliegen anschliessend andere raus
meine vorherige 88_HMCCU.pm hat 178 kib und funktioniert bestens (wird aber zeitlich später im Fhem gestartet)
das DOIF ist aber zur zeit deaktiviert, da ich alles neue erst einmal wieder aus der Fehlersuche ausschliessen wollte
ich habe gerade meine logs durchgesehen - diese timed out Problem besteht schon seit Dezember - ist wohl nur nicht aufgefallen :(
wo kann ich denn hier die entsprechenden Fehler abarbeiten?
[Sun Apr 2 16:26:23 2017] fhem.pl: Argument "off" isn't numeric in numeric lt (<) at (eval 109327) line 1.
[Sun Apr 2 16:26:29 2017] fhem.pl: Argument "off" isn't numeric in numeric lt (<) at (eval 109353) line 1.
vielleicht hilft das weiter bei meinem eigentlichen Problem
Gruss annette
Zitat von: tagedieb am 02 April 2017, 16:52:48danke für deine Erklärungen - es hilft mir stets mehr, als fertig präsentierte Lösungen
Bitteschön, aber in dem Fall hätte ich auch gar keine fertige Lösung anzubieten.
Zitat
mehr als 36 sekunden dauert laut Event Monitor gar nichts, selbst die 12 FBDECT, welche auf einmal abgefragt werden, dauern 5 Sekunden :-[
Also laut apptime hat da sehr wohl etwas mehr als 36 Sekunden gedauert. Wie kannst Du im Event Monitor sehen, wie lange etwas dauert? Hast Du alle 5 Sekunden irgendwelche Events?
Zitat
die besagte Datei: 88_HMCCU.pm nach dem update hat sie nur noch 176 kib und es wurden 4 geräte gelöscht - gebe ich sie ein, fliegen anschliessend andere raus
meine vorherige 88_HMCCU.pm hat 178 kib und funktioniert bestens (wird aber zeitlich später im Fhem gestartet)
Dass die Datei nach dem Update kleiner ist kann ja sein. Ich werfe in meinem Kram auch immer wieder überflüssiges Zeug raus. Geräte werden an sich nur gelöscht (bzw. beim Starten nicht angelegt), wenn sonst noch irgendwas faul ist. Da müsstest Du mal etwas mehr Informationen liefern.
Zitat
wo kann ich denn hier die entsprechenden Fehler abarbeiten?
[Sun Apr 2 16:26:23 2017] fhem.pl: Argument "off" isn't numeric in numeric lt (<) at (eval 109327) line 1.
[Sun Apr 2 16:26:29 2017] fhem.pl: Argument "off" isn't numeric in numeric lt (<) at (eval 109353) line 1.
Das sieht danach aus, dass Du wie schon gesagt irgendwo ein at, notify oder so etwas hast, in dem ein Reading, in dem on oder off steht, mit einer Zahl verglichen wird. Da müsstest Du selbst mal nachsehen, was da so alles bei Dir definiert ist.
Zitat
vielleicht hilft das weiter bei meinem eigentlichen Problem
Glaube ich eher nicht, aber es ist trotzdem besser, es zu verbessern.
Gruß,
Thorsten
Hallo Thorsten
ich glaube den grossen Fehler gefunden zu haben, denn seit einer Stunde habe ich keine "Eiszeiten" mehr und auch im Log erschien die Meldung nur einmal beim Start
(es war mein WOL - auch dieses hatte noch die alte Schreibweise (incl Fehlereintrag im Log) - und bremste somit wahrscheinlich alles aus)
ZitatAlso laut apptime hat da sehr wohl etwas mehr als 36 Sekunden gedauert. Wie kannst Du im Event Monitor sehen, wie lange etwas dauert? Hast Du alle 5 Sekunden irgendwelche Events?
Ja laut apptime waren die zeiten wesentlich anders - im eventmonitor hat der mir im Sekundentakt die Seiten gefüllt und die FBDECT ging von xx.xx.52 (Uhr und 52 sekunden) - bis x Uhr und 57 Sekunden :-\
ZitatDass die Datei nach dem Update kleiner ist kann ja sein. Ich werfe in meinem Kram auch immer wieder überflüssiges Zeug raus. Geräte werden an sich nur gelöscht (bzw. beim Starten nicht angelegt), wenn sonst noch irgendwas faul ist. Da müsstest Du mal etwas mehr Informationen liefern.
ich habe dir mal eine Datei angehangen, mit den logeintägen der alten pm und den der neuen pm
die datei habe ich für mich gesammelt um "später" ::) mal auf Fehlersuche zu gehen - jedoch im Moment war diese Variante die bequemste ;)
ZitatDas sieht danach aus, dass Du wie schon gesagt irgendwo ein at, notify oder so etwas hast, in dem ein Reading, in dem on oder off steht, mit einer Zahl verglichen wird. Da müsstest Du selbst mal nachsehen, was da so alles bei Dir definiert ist.
und wie ändere ich das richtig?
ich nehme an das sind die Rolladen notifys - da ist on =0 und off=100 -
RolloDF:0 set RODFSchalter_auf on-for-timer 1nochmals vielen dank für deine Zeit und Hilfe
gruss annette
Vielleicht kann ich die 36s erklären. Sorry Annette. War heute Nachmittag zu faul zum Schreiben. Dachte ihr seht es noch. In der gesamt Zeit hat dieser Prozess in der Tat 36s gedauert, in dieser Zeit wurde er aber auch 956 Mal aufgerufen. Macht pro Aufruf 71,5ms wo er blockiert. Wie lange lief da apptime schon?
Aha 36897 / 958 = 71 ??? Naja...
Du verwechselst da "max" mit "total".
Gruß,
Thorsten
Möglich. Ist ja schon spät und ich immer noch faul.
Grüße
Hallo zusammen
@CoolTux
warum sorry? es ist Sonntag und jeder macht das hier freiwillig in seiner Freizeit - ich freu mich über jede Hilfe hier, denn es ist nicht selbstverständlich, das ich hier Hilfe "bekommen zu habe"
fhem lief ca 10 min nach einem neustart und ca 6 min war fhem nicht erreichbar - und was bedeutet ?
tmr-BlockingKill HASH(0x75aa6f0) 36 1 36 36.00 597 HASH(0x75aa6f0) kann das das wol gewesen sein? denn jetzt finde ich diesen Eintrag nicht mehr
gruss tagedieb
Zitat von: CoolTux am 02 April 2017, 22:13:46
Möglich. Ist ja schon spät und ich immer noch faul.
Du hast ja auch heute Morgen die Mama noch ein bisschen schlafen lassen, oder? War früh für Sonntag...
Zitat von: tagedieb am 02 April 2017, 22:20:52fhem lief ca 10 min nach einem neustart und ca 6 min war fhem nicht erreichbar - und was bedeutet ?
tmr-BlockingKill HASH(0x75aa6f0) 36 1 36 36.00 597 HASH(0x75aa6f0) kann das das wol gewesen sein? denn jetzt finde ich diesen Eintrag nicht mehr
Naja, der Aufruf selbst hat nur 36ms gebraucht. Allerdings könnte das tatsächlich ein Hinweis darauf sein, dass irgendein Modul BlockingCall verwendet und der Call ging in den Timeout.
Gruß,
Thorsten