(Gelöst)PRESENCE: FHEM hängt sich oft auf, Raspberry PI mit SSH bleibt bedienbar

Begonnen von isy, 31 August 2015, 19:42:49

Vorheriges Thema - Nächstes Thema

isy

Ja, das stimmt. Letzte Zeit jede Nacht. Morgens ist der RasPi  mit reboot (zum Glück, ansonsten ist irgendwann das OS defekt) wieder zu erwecken. FHEM komplett aufgehangen.

Ich habe apptime laufen. Wenn die PRESENCE Fehlermeldungen kommen, dann gehen die WEB basierten Verbindungen (u.a. Solarview, Enigma) alle auf über 2s Responsetime.
PRESENCE aus, alles OK.

Werde mal versuchen. das blocking.pm modul zu debuggen. Muss ich mich einlesen.
attr global stacktrace 1
ist eingetragen.

Die Homematic Fehler mit den Fensterkontakten sind  seit 2 Tagen gelöst, ich habe AES abgeschaltet. Es könnte durchaus sein, dass die "getconfig" Anfragen der nicht richtig gepairten Fensterkontakte zu Timeouts führten.
Morgen früh bin ich schlauer.
Ein Weg wird erst zu einem Weg, wenn man ihn geht

isy

Schon zugeschlagen:

2015.09.03 23:19:06 5: PRESENCE (S4) - ping command returned with output:
PING 192.168.178.25 (192.168.178.25) 56(84) bytes of data.
64 bytes from 192.168.178.25: icmp_req=1 ttl=64 time=357 ms
64 bytes from 192.168.178.25: icmp_req=2 ttl=64 time=225 ms
64 bytes from 192.168.178.25: icmp_req=3 ttl=64 time=140 ms
64 bytes from 192.168.178.25: icmp_req=4 ttl=64 time=64.0 ms

--- 192.168.178.25 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 64.078/196.984/357.816/109.087 ms
2015.09.03 23:19:06 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at FHEM/Blocking.pm line 105.
2015.09.03 23:19:06 3: stacktrace:
2015.09.03 23:19:06 3:     main::__ANON__                      called by FHEM/Blocking.pm (105)
2015.09.03 23:19:06 3:     main::BlockingInformParent          called by FHEM/Blocking.pm (92)
2015.09.03 23:19:06 3:     main::BlockingCall                  called by ./FHEM/73_PRESENCE.pm (535)
2015.09.03 23:19:06 3:     main::PRESENCE_StartLocalScan       called by ./FHEM/98_apptime.pm (104)
2015.09.03 23:19:06 3:     main::apptime_getTiming             called by ./FHEM/98_apptime.pm (45)
2015.09.03 23:19:06 3:     main::HandleTimeout                 called by fhem.pl (583)
2015.09.03 23:19:06 1: CallBlockingFn: Can't connect to localhost:: IO::Socket::INET: Bad hostname 'localhost:'

2015.09.03 23:19:16 5: PRESENCE (Helmut) - ping command returned with output:
PING 192.168.178.30 (192.168.178.30) 56(84) bytes of data.

--- 192.168.178.30 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3010ms

2015.09.03 23:19:16 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at FHEM/Blocking.pm line 105.
2015.09.03 23:19:16 3: stacktrace:
2015.09.03 23:19:16 3:     main::__ANON__                      called by FHEM/Blocking.pm (105)
2015.09.03 23:19:16 3:     main::BlockingInformParent          called by FHEM/Blocking.pm (92)
2015.09.03 23:19:16 3:     main::BlockingCall                  called by ./FHEM/73_PRESENCE.pm (535)
2015.09.03 23:19:16 3:     main::PRESENCE_StartLocalScan       called by ./FHEM/98_apptime.pm (104)
2015.09.03 23:19:16 3:     main::apptime_getTiming             called by ./FHEM/98_apptime.pm (45)
2015.09.03 23:19:16 3:     main::HandleTimeout                 called by fhem.pl (583)
2015.09.03 23:19:16 1: CallBlockingFn: Can't connect to localhost:: IO::Socket::INET: Bad hostname 'localhost:'

Danach hängt das PRESENCE Modul:
presence present
2015-09-03 23:17:49 state present 2015-09-03 23:17:49

Das war der letzte Status, danach keiner mehr.

Danach "shutdown restart" und siehe da:
2015.09.03 23:28:32 5: PRESENCE (Helmut) - ping command returned with output:
PING 192.168.178.30 (192.168.178.30) 56(84) bytes of data.

--- 192.168.178.30 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 2999ms

2015.09.03 23:28:32 4: Connection accepted from telnet:127.0.0.1:49419
2015.09.03 23:28:32 5: Cmd: >{PRESENCE_ProcessLocalScan('Helmut|0|absent')}<
2015.09.03 23:28:32 5: PRESENCE (Helmut) - blocking scan result: Helmut|0|absent
2015.09.03 23:28:32 4: PRESENCE (Helmut) - rescheduling next check in 60 seconds

Ein Weg wird erst zu einem Weg, wenn man ihn geht

frank

ZitatDas war der letzte Status, danach keiner mehr.
eventuell wird der fehlgeschlagene connect versuch unzureichend abgefangen, sodass presence aussteigt. da müsste markus mal schauen.

versuch doch mal nach dem fehler eine änderung im presence modul auf der detailseite zu machen. zb modify der def, um das modul erneut "anzuschubsen".
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

isy

Heute läuft super. Keine Hänger, alle Werte in apptime < 200ms. PRESENCE auch normal, keine FM im Log.
Werde mal Räucherstäbchen entzünden. Das machen wir in der IT immer so, wenn alles ohne Change dann doch wieder läuft.
Wenn das Thema zuschlägt, melde ich mich wieder.

Euch allen vielen Dank, ich weiß das zu schätzen!
Ein Weg wird erst zu einem Weg, wenn man ihn geht

isy

Habe noch eine Frage:
Nach "shutdown restart" meldet sich sofort neben dem "save config" button ein rotes Ausrufezeichen (2 Änderungen an fhem.cfg zu bestätigen).

Ist das beim aktivierten PRESENCE Modul bei euch auch so?

Ein Weg wird erst zu einem Weg, wenn man ihn geht

isy

Neue Feststellung - kann das jemand bestätigen?

Wenn ich bei aktiviertem PRESENCE Modul im FHEM Editor in der fhem.cfg nur einen Buchstaben ändere, wird fhem neu gestartet und folgendes Log erzeugt:

2015.09.04 23:14:33 1: Including ./log/fhem.save
2015.09.04 23:14:36 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at FHEM/Blocking.pm line 105.
2015.09.04 23:14:36 1: CallBlockingFn: Can't connect to localhost:: IO::Socket::INET: Bad hostname 'localhost:'
2015.09.04 23:14:38 3: Device HM_3545CF added to ActionDetector with 000:10 time
2015.09.04 23:14:38 3: Device HM_388C62 added to ActionDetector with 000:10 time
2015.09.04 23:14:38 3: Device au_Bew_Garage added to ActionDetector with 000:10 time
2015.09.04 23:14:38 3: Device ku_SW_Fenster_r added to ActionDetector with 001:05 time
2015.09.04 23:14:38 3: Device wz_SW_BalkonTuer added to ActionDetector with 001:05 time
2015.09.04 23:14:46 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at FHEM/Blocking.pm line 105.
2015.09.04 23:14:46 1: CallBlockingFn: Can't connect to localhost:: IO::Socket::INET: Bad hostname 'localhost:'


Danach steht PRESENCE (aufgehangen). Wen ich FHEM neu starte (shutdown restart), dann erfolgt ein ordentlicher, fehlerfreier Neustart.

Ein Weg wird erst zu einem Weg, wenn man ihn geht

dev0

Kann es sein, dass du die fhem.cfg schon mal manuell bearbeitest? Ich vermute, dass ein Port bei einer Gerätedefinition fehlt. Schau dir mal die Devices vom Typ FHEMWEB und telnet an. Ggf. auch andere Devices, die einen Port in der Definition benötigen.

isy

Ja, manchmal trage ich Kommentare ein. Über die eigene Web-Oberfläche, aber auch über ext. Editor von meinem Linux System aus.

Ich habe jetzt mal meine alte fhem.cfg gesichert und die fhem_demo umbenannt.
Als erstes das PRESENCE aktiviert. Läuft problemlos, aber in der demo Version ist auch kein SSL Port bem telnet eingetragen.
Weiterhin den gesammten "global" Teil Zeile für Zeile aus meiner gesicherten fhem.cfg rübergenommen.
Läuft.
Die Telnet Einträge habe ich komplett aus der demo übernommen und nur mein SSL Passwort eingetragen.
Läuft auch, jetzt kommt das Ausrufezeichen neben dem "save config" button nach dem shutdown restart
Gibt keinen Ärger mit dem PRESENCE Modul.

Dann noch den Rest der fhem Installation übernommen.
Läuft derzeit auch. Muss ich abwarten.

Evtl. gibt es ein Zeichen in der fhem.cfg, welches unsichtbar am Editor ist, aber intern Ärger verursacht.


Ein Weg wird erst zu einem Weg, wenn man ihn geht

isy

Habe das Problem abgestellt, aber die Ursache bleib unklar.
Also im Telnet Device "ssl" deaktiviert, brauche ich intern nicht. Danach keine Probleme mehr.

Danke noch mal an alle, die mitgeholfen haben!
Ein Weg wird erst zu einem Weg, wenn man ihn geht