MQTT2_CLIENT Probleme

[rudolfkoenig]

Aber ich würde mir wünschen, dass es sinnvolle Meldungen im Logfile gäbe, wenn eine Verbindung wegen fehlender oder falscher user/password Daten nicht aufgebaut werden kann.

Das war eigentlich meine Absicht, die Implementierung war aber kaputt.
Jetzt werden die "offiziellen" MQTT CONNACK Meldungen ausgegeben, mein mosquitto liefert aber auch beim falschen Passwort "bad id", obwohl ein "bad user name or password" existiert.
MQTT2_SERVER ist noch grober, und terminiert die Verbindung.

Normal Abmelden lösst kein LWT, bin mir da recht sicher.

Mag sein, aber MQTT_CLIENT sendet kein DISCONNECT, insofern wird LWT immer ausgegeben.
Wenn jemand mit sagt, warum DISCONNECT sinnvoll ist, kann ich es gerne einbauen
Da mein Vorschlag mit der notify nur beim reconnect, nicht aber beim FHEM-Start funktioniert, habe ich onConnect spendiert.

[hexenmeister]

Korrektes disconnect ist mir deshalb wichtig, damit ich für alle meine Instanzen immer einen korrekten Status per MQTT verfügbar habe. Also online, herunter gefahren (sauber disconnected) und abnormal beendet (lwt).
Und leider brauche ich für die "normal beendet" einen onDisconnect, da mit notify sich das nicht realisieren lässt. Oder habe ich etwas übersehen?

[betateilchen]

Benutzername/Passwort sollte mit MQTT2_CLIENT funktionieren.
SSL (aka TLS) auch, habe ich aber nie getestet.

SSL habe ich heute getestet, das funktioniert tatsächlich. Für mich der einzige Grund, vielleicht tatsächlich von MQTT auf MQTT2 umzusteigen und die bestehenden Konfigurationen entsprechend anzupassen, wenn ich mal Zeit dafür habe.

[betateilchen]

Das war eigentlich meine Absicht, die Implementierung war aber kaputt.
Jetzt werden die "offiziellen" MQTT CONNACK Meldungen ausgegeben, mein mosquitto liefert aber auch beim falschen Passwort "bad id", obwohl ein "bad user name or password" existiert.

mein mosquitto liefert korrekt:

Code: [Auswählen]

2018.11.11 22:18:55 1: mqtt2_local: Connection refused, bad user name or password


[betateilchen]

Die Sache mit der automatisch aus dem deviceName ermittelten clientId, wenn diese nicht per Attribut gesetzt ist, sollte man dringend nochmal überdenken. Wenn zwei oder mehr FHEM Installationen ohne gesetzte clientId (zufällig oder beabsichtigt) den gleichen Namen für das MQTT2_CLIENT device verwenden, passieren ganz komische Dinge. Hier wäre vielleicht die Verwendung einer UUID (oder zumindest eines Teils davon) in der clientId sinnvoller und eindeutiger.

[rudolfkoenig]

mein mosquitto liefert aber auch beim falschen Passwort "bad id"

Hat sich rausgestellt, dass ich eine alte mosquitto Version hatte, dem auch SSL unbekannt war.
Mit einer aktuelleren mosquitto funktioniert SSL auch bei mir, und bei falschen Benutzername oder Passwort liefert es "Connection refused, not authorized"

Wenn zwei oder mehr FHEM Installationen ohne gesetzte clientId (zufällig oder beabsichtigt) den gleichen Namen für das MQTT2_CLIENT device verwenden, passieren ganz komische Dinge.

Kannst du das bitte konkretisieren?
Sowohl den Setup, wie auch die komischen Dinge.

[betateilchen]

Mit einer aktuelleren mosquitto funktioniert SSL auch bei mir, und bei falschen Benutzername oder Passwort liefert es "Connection refused, not authorized"

Die Meldung "not authorized" bekomme ich nur, wenn ich gar keine Benutzerdaten definiert habe.
Die Meldung "bad user name or password" kommt bei mir, wenn die übergebenen credentials falsch sind.

Kannst du das bitte konkretisieren?
Sowohl den Setup, wie auch die komischen Dinge.

MQTT Broker = mosquitto auf einem externen Server im Internet
FHEM_1 = define mqtt2 MQTT2_CLIENT <host>:<port>
FHEM_2 = define mqtt2 MQTT2_CLIENT <host>:<port>

Dann melden sich beide FHEM Installationen mit der gleichen clientId an und schießen sich gegenseitig die Verbindung ab.


Im Moment versuche ich aber, die Ursache hierfür rauszufinden:

Code: [Auswählen]

2018.11.12 11:14:34 1: host:8883 disconnected, waiting to reappear (mqtt2)
2018.11.12 11:14:35 1: host:8883 reappeared (mqtt2)
2018.11.12 11:15:44 1: host:8883 disconnected, waiting to reappear (mqtt2)
2018.11.12 11:15:44 1: host:8883 reappeared (mqtt2)
2018.11.12 11:15:46 1: host:8883 disconnected, waiting to reappear (mqtt2)
2018.11.12 11:15:46 1: host:8883 reappeared (mqtt2)
2018.11.12 11:16:55 1: host:8883 disconnected, waiting to reappear (mqtt2)
2018.11.12 11:16:55 1: host:8883 reappeared (mqtt2)
2018.11.12 11:18:05 1: host:8883 disconnected, waiting to reappear (mqtt2)
2018.11.12 11:18:05 1: host:8883 reappeared (mqtt2)
2018.11.12 11:19:20 1: host:8883 disconnected, waiting to reappear (mqtt2)
2018.11.12 11:19:20 1: host:8883 reappeared (mqtt2)

Das hatte ich gestern schonmal, ist dann aber wie von Zauberhand verschwunden. Aber seit heute Nacht wird mein Logfile damit geflutet.

[rudolfkoenig]

Wenn beide FHEM Instanzen hinter den gleichen IP (aus Sicht der mosquitto Server) stecken, dann habe ich eine Theorie: mosquitto vermutet ein Tasmota, der eine zweite Verbindung zum gleichen MQTT Server oeffnet. MQTT2_SERVER hat fuer solche Faelle (gleicher clientId vom gleichen IP) auch eine Ausnahme. Was spricht gegen die Umbenennung des MQTT2_CLIENTs?

[betateilchen]

Die beiden FHEM Installationen befinden sich nicht im gleichen Netzwerk bzw. hinter der gleichen IP, denn dann bräuchte ich keinen externen Broker.

Gegen die Umbenennung spricht die Tatsache, dass ich etwas über 40 FHEM Installationen habe, die in der technischen Grundkonfiguration immer identisch sind. D.h. die FHEMWEB Instanz heißt überall "web", und die MQTT2_CLIENT Instanz heißt eben immer "mqtt2". Das reduziert den Verwaltungsaufwand erheblich.

[betateilchen]

Wie komme ich der Ursache für den Socket error auf die Spur?

Code: [Auswählen]

1542018430: New client connected from <meineIp> as mqtt2 (c1, k30, u'udo').
1542018460: Socket error on client mqtt2, disconnecting.
1542018461: New connection from <meineIp> on port 8883.
1542018461: New client connected from <meineIp> as mqtt2 (c1, k30, u'udo').
1542018531: Socket error on client mqtt2, disconnecting.
1542018531: New connection from <meineIp> on port 8883.
1542018531: New client connected from <meineIp> as mqtt2 (c1, k30, u'udo').
1542018602: Socket error on client mqtt2, disconnecting.
1542018602: New connection from <meineIp> on port 8883.
1542018602: New client connected from <meineIp> as mqtt2 (c1, k30, u'udo').
1542018672: Socket error on client mqtt2, disconnecting.
1542018672: New connection from <meineIp> on port 8883.
1542018672: New client connected from <meineIp> as mqtt2 (c1, k30, u'udo').
1542018742: Socket error on client mqtt2, disconnecting.
1542018742: New connection from <meineIp> on port 8883.


Code: [Auswählen]

2018.11.12 11:32:45 5: mqtt2: keepalive 30
2018.11.12 11:32:45 5: mqtt2: received PINGRESP
2018.11.12 11:33:15 5: mqtt2: keepalive 30
2018.11.12 11:33:15 5: mqtt2: received PINGRESP
2018.11.12 11:33:25 1: <host>:8883 disconnected, waiting to reappear (mqtt2)
2018.11.12 11:33:25 5: HttpUtils url=https:/<host>:8883/
2018.11.12 11:33:25 1: <host>:8883 reappeared (mqtt2)
2018.11.12 11:33:25 5: mqtt2: received CONNACK (0)(0)
2018.11.12 11:33:25 5: mqtt2: received SUBACK (0)(9)(0)


[betateilchen]

Die Verbindungsprobleme mit dem socket error treten scheinbar nur bei SSL auf.
Und interessanterweise nur in einer der beiden momentan umgestellten FHEM Installationen, die ansonsten gleich konfiguriert sind.

Code: [Auswählen]

define mqtt2 MQTT2_CLIENT <host>:8883
attr mqtt2 SSL 1
attr mqtt2 clientId fhemHome
attr mqtt2 username udo

Ausserdem bin ich davon ausgegangen, dass die clientId (fhemHome) für die Verbindung zum mosquitto verwendet wird und nicht der FHEM-eigene deviceName (mqtt2)
Als nächstes werde ich testen, was passiert, wenn ich die devices in den beiden Installationen tatsächlich verschieden benenne - was mir aber nicht gefallen würde.

[rudolfkoenig]

Ausserdem bin ich davon ausgegangen, dass die clientId (fhemHome) für die Verbindung zum mosquitto verwendet wird und nicht der FHEM-eigene deviceName (mqtt2)

Jetzt wo Du es sagst
Es wird $hash->{clientId} verwendet, was aus dem Attribut clientId (oder NAME, falls nicht gesetzt) abgeleitet wird, indem man alles ausser 0-9A-Za-z entfernt.

[betateilchen]

Das Attribut clientId ist gesetzt auf "fhemHome" und der Wert steht auch in $hash->{clientId} korrekt drin.

Code: [Auswählen]

Internals:
   BUF       
   DEF        <host>:8883
   DeviceName <host>:8883
   FD         9
   NAME       mqtt2_Home
   NR         222
   PARTIAL   
   SSL        1
   STATE      opened
   TYPE       MQTT2_CLIENT
   WBCallback
   clientId   fhemHome
   lastMsgTime 1542022425.73912
   nextOpenDelay 5
   Helper:
     DBLOG:
       state:
         fhemDbLog:
           TIME       1542022395.72668
           VALUE      CONNECTED
   READINGS:
     2018-11-12 12:33:15   state           opened
Attributes:
   SSL        1
   clientId   fhemHome
   group      00 System
   icon       mqtt
   room       99 System
   username   udo

Am Name der devices liegt die Ursache für die Verbindungsprobleme offenbar nicht alleine. Die reconnects treten auch mit unterschiedlichen Namen immer noch auf, allerdings seltener als vorher: immer im Abstand von ca. 70 Sekunden.

Ausserdem ist mir aufgefallen, dass MQTT2_CLIENT offenbar keine RenameFn() besitzt

[betateilchen]

Es wird $hash->{clientId} verwendet, was aus dem Attribut clientId (oder NAME, falls nicht gesetzt) abgeleitet wird, indem man alles ausser 0-9A-Za-z entfernt.

Hm... bist Du sicher? An welcher Stelle erfährt DevIo_OpenDev() denn, dass es mit $hash->{clientId} anstatt $hash->{NAME} arbeiten soll?

[rudolfkoenig]

Etwas praeziser:
- DevIo_OpenDev oeffnet nur die TCP-Verbindung, sie interessiert sich nicht um clientId.
- nach dem die Verbindung offen ist, wird $hash->{clientId} gesendet.
- clientId wird in define initialisiert, und in AttrFn modifiziert
- die Verbindung wird neu aufgebaut, wenn FHEM gestartet ist (und damit alle Attribute bekannt sind), oder wenn man ein "relevantes" Attribut (SSL, clientId, etc) gesetzt hat.