Autor Thema: MQTT2_CLIENT Probleme  (Gelesen 1085 mal)

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 19320
Antw:MQTT2_CLIENT Probleme
« Antwort #45 am: 10 November 2018, 18:50:24 »
Zitat
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.

Zitat
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.

Offline hexenmeister

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4162
    • tech_LogBuch
Antw:MQTT2_CLIENT Probleme
« Antwort #46 am: 10 November 2018, 22:49:23 »
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?
In Verwendung: HM, EnOcean, 1wire, Firmata, MySensors, ESPEasy, MQTT*, NodeRED, Alexa, Telegram,..
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy
Kaffeekasse: https://www.paypal.me/s6z

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15164
  • s/fhem\.cfg/configDB/g
Antw:MQTT2_CLIENT Probleme
« Antwort #47 am: 11 November 2018, 17:12:37 »
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.
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg-Stammtisch: 14.12.2018 - 18:30 Uhr

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15164
  • s/fhem\.cfg/configDB/g
Antw:MQTT2_CLIENT Probleme
« Antwort #48 am: 11 November 2018, 22:23:25 »
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:

2018.11.11 22:18:55 1: mqtt2_local: Connection refused, bad user name or password
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg-Stammtisch: 14.12.2018 - 18:30 Uhr

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15164
  • s/fhem\.cfg/configDB/g
Antw:MQTT2_CLIENT Probleme
« Antwort #49 am: 11 November 2018, 23:33:00 »
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.
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg-Stammtisch: 14.12.2018 - 18:30 Uhr

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 19320
Antw:MQTT2_CLIENT Probleme
« Antwort #50 am: Gestern um 09:42:31 »
Zitat
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"

Zitat
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.

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15164
  • s/fhem\.cfg/configDB/g
Antw:MQTT2_CLIENT Probleme
« Antwort #51 am: Gestern um 11:22:35 »
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:

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.
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg-Stammtisch: 14.12.2018 - 18:30 Uhr

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 19320
Antw:MQTT2_CLIENT Probleme
« Antwort #52 am: Gestern um 11:30:14 »
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?

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15164
  • s/fhem\.cfg/configDB/g
Antw:MQTT2_CLIENT Probleme
« Antwort #53 am: Gestern um 11:39:38 »
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.

-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg-Stammtisch: 14.12.2018 - 18:30 Uhr

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15164
  • s/fhem\.cfg/configDB/g
Antw:MQTT2_CLIENT Probleme
« Antwort #54 am: Gestern um 11:45:27 »
Wie komme ich der Ursache für den Socket error auf die Spur?

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.

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)
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg-Stammtisch: 14.12.2018 - 18:30 Uhr

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15164
  • s/fhem\.cfg/configDB/g
Antw:MQTT2_CLIENT Probleme
« Antwort #55 am: Gestern um 12:19:50 »
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.

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.

« Letzte Änderung: Gestern um 12:22:38 von betateilchen »
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg-Stammtisch: 14.12.2018 - 18:30 Uhr

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 19320
Antw:MQTT2_CLIENT Probleme
« Antwort #56 am: Gestern um 12:25:29 »
Zitat
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.

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15164
  • s/fhem\.cfg/configDB/g
Antw:MQTT2_CLIENT Probleme
« Antwort #57 am: Gestern um 12:34:52 »
Das Attribut clientId ist gesetzt auf "fhemHome" und der Wert steht auch in $hash->{clientId} korrekt drin.

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 ;)


-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg-Stammtisch: 14.12.2018 - 18:30 Uhr

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15164
  • s/fhem\.cfg/configDB/g
Antw:MQTT2_CLIENT Probleme
« Antwort #58 am: Gestern um 14:53:23 »
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?

-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg-Stammtisch: 14.12.2018 - 18:30 Uhr

 

decade-submarginal