mqtt2_client wird vom System gelöscht [gelöst]

[Nighthawk]

Hallo zusammen,

ich habe seit einiger Zeit ein seltsames Phänomen, der mqtt2_client der bei mir die Brücke zu mosquitto schlägt, wird immer wieder im fhem gelöscht. Das Löschen kann ich an nichts festmachen, es passiert immer willkürlich.
Ich habe auch schon versucht mit verbose 5 zu loggen, leider erzeugt dies eine so hohe Last, dass mein Raspi nach ca. 24h sich komplett aufhängt.
Ich bin momentan etwas ratlos wie ich das Problem einfangen kann, die Tatsache dass der mqtt2_Client gelöscht wird (was einen Komplettausfall der MQTT Kommunikation zur Folge hat) führt zu einem sehr negativen WAF.

[rudolfkoenig]

Ich wuerde versuchen es einzugrenzen mit sowas:

Code Auswählen Erweitern

defmod debugDelete notify global:DELETED.* { Log 1, $EVENT;; stacktrace() }

[Nighthawk]

Hallo Rudi,

danke für die schnelle Rückmeldung, werde ich mal einbauen.

Gruß
Alex

[event horizon]

Hallo zusammen!

Auch bei mir wird der mqtt2 client gelöscht. Ich habe sechs fhem Instanzen im Einsatz.
Der Client ist auf allen im Einsatz.
Gelöscht wird der Client aber nur auf zweien.
Den beiden ist gemeinsam, dass auf diesen Telegram läuft und gelöscht wird der Client, wenn es Störungen beim Internetzugang gibt.

Es wäre toll, wenn es eine Lösung geben würde.

Viele Dank für eure Arbeit!

Ferdi

[event horizon]

P. S. : Ich lege mich auch mit dem  debugDelete notify auf die Lauer...

[Icinger]

Ist bei mir auch schon ein paar mal passiert.
Kein Neustart, kein Update oder so.......Einfach plötzlich weg.
In der fhem.cfg ist das Device aber noch gespeichert, nur im Live-Betrieb plötzlich verschwunden.

PS: Ich werd mich zusätzlich zu dem debugDelete jetzt auch per msg informieren lassen:

Code Auswählen Erweitern

defmod debugDelete notify  global:DELETED.* {my @rr_Stefan;;fhem("msg @rr_Stefan ".$EVENT);; Log 1, $EVENT;; stacktrace() }


[event horizon]

Hi, Folgendes wurde mitgeschnitten :

2019.06.21 12:03:25 1: 10.13.20.40:1883 disconnected, waiting to reappear (my2Broker2Master) 2019.06.21 12:03:25 1: 10.13.20.40:1883 reappeared (my2Broker2Master) 2019.06.21 12:06:03 1: DELETED my2Broker2Master 2019.06.21 12:06:03 1: stacktrace: 2019.06.21 12:06:03 1: (eval) called by fhem.pl (1131) 2019.06.21 12:06:03 1: main::AnalyzePerlCommand called by fhem.pl (1156) 2019.06.21 12:06:03 1: main::AnalyzeCommand called by fhem.pl (1085) 2019.06.21 12:06:03 1: main::AnalyzeCommandChain called by ./FHEM/91_notify.pm (121) 2019.06.21 12:06:03 1: main::notify_Exec called by fhem.pl (3750) 2019.06.21 12:06:03 1: main::CallFn called by fhem.pl (3670) 2019.06.21 12:06:03 1: main::DoTrigger called by fhem.pl (2251) 2019.06.21 12:06:03 1: main::CommandDelete called by fhem.pl (781)

Ferdi

Gesendet von meinem SM-G960F mit Tapatalk

[Nighthawk]

Code Auswählen Erweitern

Folgendes kam bei mir heraus:

2019.06.21 18:09:27 1: sendemail Subject: Tor geschlossen!!
2019.06.21 18:09:27 1: sendemail Text: Das Garagentor wurde geschlossen!
2019.06.21 18:09:27 1: sendemail Anhang:
2019.06.21 18:10:00 1: sendemail returned: Jun 21 18:10:00 raspberrypi sendemail[8231]: Email was sent successfully!
2019.06.21 18:10:01 2: LuftdatenInfo (Luftquali) - error while request: write to http://192.168.111.111:80 timed out
2019.06.21 18:10:04 1: DELETED mqtt2_client
2019.06.21 18:10:04 1: stacktrace:
2019.06.21 18:10:04 1:     (eval)                              called by fhem.pl (1131)
2019.06.21 18:10:04 1:     main::AnalyzePerlCommand            called by fhem.pl (1156)
2019.06.21 18:10:04 1:     main::AnalyzeCommand                called by fhem.pl (1085)
2019.06.21 18:10:04 1:     main::AnalyzeCommandChain           called by ./FHEM/91_notify.pm (121)
2019.06.21 18:10:04 1:     main::notify_Exec                   called by fhem.pl (3750)
2019.06.21 18:10:04 1:     main::CallFn                        called by fhem.pl (3670)
2019.06.21 18:10:04 1:     main::DoTrigger                     called by fhem.pl (2251)
2019.06.21 18:10:04 1:     main::CommandDelete                 called by fhem.pl (781)


[rudolfkoenig]

Ist wohl ein Fehler in der Behandlung von TCP-Schreibfehlern in fhem.pl.
Bisher bin ich davon ausgegangen, dass asynchrone Schreibauftraege nur von Server-Diensten wie telnet, FHEMWEB, MQTT2_SERVER erfolgen, und in solchen Faellen kann man die Verbindung durchs Loeschen der FHEM-Instanz (die die konkrete Verbindung representiert, nicht den Server) beenden.
Ab jetzt (d.h. update ab morgen um 8 Uhr) loescht fhem.pl nur TEMPORARY Eintraege (d.h. die vorher beschriebene Verbindung).

Ob die Loesung keine Nebenwirkungen hat, konnte ich nicht testen.
Die eigentliche Ursache war ein Netzwerkfehler, oder eine Gegenstelle, die keine Daten haben wollte.

[Nighthawk]

Hallo Rudi,

danke für den Fix, werde gleich updaten und prüfe ob ich Nebenwirkungen bemerke.

Gruß
Alex

[event horizon]

Hallo Rudi!

Von mir auch vielen Dank.

Mir sind keine Nebenwirkungen aufgefallen.

Gruß
Ferdi