MQTT2_CLIENT Probleme

Begonnen von rudolfkoenig, 07 November 2018, 21:12:15

Vorheriges Thema - Nächstes Thema

betateilchen

Zitat von: rudolfkoenig am 16 November 2018, 19:18:58
Ich wuerde trotzdem einen Versuch mit keepalive = 60 starten.


1542542358: New connection from <ip> on port 8883.
1542542358: New client connected from <ip> as fhemHome (c1, k60, u'udo').
1542542384: Socket error on client fhemHome, disconnecting.
1542542385: New connection from <ip> on port 8883.
1542542385: New client connected from <ip> as fhemHome (c1, k60, u'udo').
1542542455: Socket error on client fhemHome, disconnecting.
1542542456: New connection from <ip> on port 8883.
1542542456: New client connected from <ip> as fhemHome (c1, k60, u'udo').
1542542526: Socket error on client fhemHome, disconnecting.
1542542527: New connection from <ip> on port 8883.
1542542527: New client connected from <ip> as fhemHome (c1, k60, u'udo').
1542542600: Socket error on client fhemHome, disconnecting.
1542542605: New connection from <ip> on port 8883.
1542542605: New client connected from <ip> as fhemHome (c1, k60, u'udo').
1542542672: Socket error on client fhemHome, disconnecting.
1542542672: New connection from <ip> on port 8883.
1542542672: New client connected from <ip> as fhemHome (c1, k60, u'udo').
1542542742: Socket error on client fhemHome, disconnecting.


BTW: warum ist das keepalive im Code von 00_MQTT2_CLIENTE.pm hart codiert?
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

Zitat von: betateilchen am 18 November 2018, 12:06:10

  • mqtt2_Home verbindet zum externen mosquitto per SSL
  • mqtt2_local verbindet zum mosquitto im lokalen Netzwerk, ohne SSL.

Wenn ich mqtt2_local aus FHEM lösche, ändert das nichts an den Verbindungsabbrüchen bei mqtt2_Home.


1542543580: New connection from ... on port 8883.
1542543580: New client connected from ... as fhemHome (c1, k30, u'udo').
1542543606: Socket error on client fhemHome, disconnecting.
1542543607: New connection from ... on port 8883.
1542543607: New client connected from ... as fhemHome (c1, k30, u'udo').
1542543677: Socket error on client fhemHome, disconnecting.
1542543679: New connection from ... on port 8883.
1542543679: New client connected from ... as fhemHome (c1, k30, u'udo').
1542543750: Socket error on client fhemHome, disconnecting.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

ZitatBTW: warum ist das keepalive im Code von 00_MQTT2_CLIENTE.pm hart codiert?
Weil:
- ich nicht unendlich viel programmieren kann
- ich nicht erwartet habe, dass damit Probleme gibt
- ich auch fuer die Zukunft was lassen wollte.
Ich weiss schon, immer dieses ich,ich,ich :)

rudolfkoenig

ZitatHast Du eigentlich mal getestet, wie sich MQTT2_CLIENT verhält, wenn es in einer FHEM Installation mehrere devices dieses Typs gibt?
Das habe ich gerade zum ersten mal versucht (per SSL zu Mosquitto und ohne SSL zu MQTT2_SERVER): ich sehe keine Besonderheiten. Uebrigens die Disconnect Abstaende sind 27 71 71 78 67, d.h. es hat nichts mit dem keepalive zu tun.


betateilchen

Das ganze MQTT2 Gedöns ist für einen wirklich stabilen Einsatz einfach nicht zu gebrauchen. Die Umstellung ist nun zum zweiten Mal gescheitert. Der erste Versuch war direkt nach der Veröffentlichung der MQTT2-Module.

Seit gestern Abend flutet mir MQTT2_CLIENT nun auch das Logfile bei nicht-SSL Verbindungen, und das sogar bei einem mqtt-Server im lokalen Netzwerk. Da ich seit gestern 14:30 Uhr dienstlich unterwegs war, kann ich mit Sicherheit sagen, dass ich an der Konfiguration nichts verändert habe, was gestern ab ca. 20 Uhr zu den Verbindungsproblemen innerhalb des lokalen Netzes hätte führen können.

Vermutlich werde ich nochmal zwei Stunden Zeit investieren und meine FHEM Installationen wieder auf mqtt umstellen.

Bin gerade sehr enttäuscht :(
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

#80
ZitatDas ganze MQTT2 Gedöns ist für einen wirklich stabilen Einsatz einfach nicht zu gebrauchen.
Das ist so generisch nicht wahr, bei mir laeuft das ohne Probleme seit August.

ZitatBin gerade sehr enttäuscht
Mag sein, aber mit so einer Art von Beschreibung geht man lieber zum Pfarrer oder Therapeuten.
Ich brauche mehr Details, wenn ich helfen soll.

betateilchen

Zitat von: rudolfkoenig am 19 November 2018, 22:56:27
Das ist so generisch nicht wahr, bei mir laeuft das ohne Probleme seit August.

Das freut mich für Dich. Aber Deine Laborbedingungen müssen ja nicht unbedingt allen real existierenden Einsatzszenarien entsprechen.

Für mich ist meine Aussage nicht nur generisch richtig, sondern auch faktisch. Inzwischen habe schon zweimal eine Menge Zeit investiert, mich mit dem Thema MQTT2 zu befassen. Ein drittes Mal werde ich das vermutlich nicht tun.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

DasQ

Also hier läuft das gedöns eigentlich recht gut und man sollte so ehrlich sein, das mqtt2 noch in den Kinderschuhen steckt. Da sind Fehler aus den man lernt an der Tagesordnung.

Btw. Ich hab mir auch erst vorgestern angetan, von FHEM.cfg auf mariaDB umzustellen. Was mit einer 2 Jahre alten und inzwischen überholten Manuel hier aus dem Forum und einigen veralteten youtubevideos, sich sehr spannend gestaltete.
Nu bin ich auf Datenbank, für log und config umgestiegen und es bleibt weiter spannend, deswegen red ich's jetzt aber nicht gleich schlecht oder mach's madig.

Soll jeder für sich selbst entscheiden was gut ist für ihn.
Fhem on MacMini/Ubuntu.
Absoluter Befürworter der Konsequenten-Kleinschreibung https://de.wikipedia.org/wiki/Kleinschreibung
Infos zu Klimawandel http://www.globalcarbonatlas.org

mark79

Ich habe MQTT2 erstmal auf ein Testsystem ausprobiert, das lief und jetzt habe ich vorerst nur die Zigbee2MQTT Devices über MQTT2 angebunden. Das läuft wie ich finde schon sehr gut und ich bin dankbar dafür! :) Die neuen Module nehmen einen schon ne Menge arbeit ab und für Anfänger ist das auch leichter zu verstehen.

Den Rest wie Tasmota, ESPeasy und OpenMQTTGateway habe ich noch über das alte MQTT am laufen, weil ich noch keine Zeit und Lust hatte alles umzustellen.
Rock64 4GB mit Debian Strech, FHEM im LXC, Sonoff Switches/Touch, HM Thermostate, HMUART/Zigbee2MQTT@MapleCUN, ESP RGBWW Wifi Controller, ESP8266 Door Sensor/Briefkastenwächter, BT CSL Stick, BT iTags, Alexa, FireTV, RPi2 mit Kodi, Xiaomi Vacuum v1/Smarthome Komponenten

HomeAlone

Ich teste den MQTT2_CLIENT seit ein paar Tagen. Vielleicht können meine Beobachtungen ja bei der Fehlersuche helfen.

Setup:

  • Mosquitto, für den Zugriff über tls auf Port 8883 ohne Benutzername/Passwort konfiguriert.
  • Vergleichsclient (MQTT.fx) der auf Port 8883 ohne Benutzername/Passwort zugreift, auf # subscribed und beliebige Topics versenden kann.
  • MQTT2_CLIENT in fhem, der auf Port 8883 ohne Benutzername/Passwort zugreift. Test Publishing mache ich entsprechend über das publish drop down in der set liste der MQTT2_CLIENT Instanz. Grundlegend habe ich die MQTT_GENERIC_BRIDGE an den MQTT2_CLIENT gebunden.

Habe MQTT2_CLIENT wie folgt definiert:
defmod mosquitto MQTT2_CLIENT reddocker:8883
attr mosquitto SSL 1
attr mosquitto clientId fhemMQTT2CLIENT
attr mosquitto icon mqtt_broker
attr mosquitto room MQTT,Zentralen

und die MQTT_GENERIC_BRIDGE so:
defmod mqttGenericBridge MQTT_GENERIC_BRIDGE mqtt room=ZWave,room=EnOcean,room=HomeMatic
attr mqttGenericBridge IODev mosquitto
attr mqttGenericBridge globalPublish *:topic={"fhempub/$device/$reading"}
attr mqttGenericBridge globalTypeExclude *:power\
*:energy
attr mqttGenericBridge icon mqtt_device
attr mqttGenericBridge room MQTT,Zentralen


Kurz OT: Kann man dem MQTT2_CLIENT auch einen Benutzernamen/Passwort mitgeben?

Was läuft genau nicht?
Vorgestern hatte ich dieselben Probleme wie heute - andauernde DISCONNECTS und CONNECTS, wobei keine Nachrichten versendet werden können. Gestern lief es lustigerweise mit denselben Settings, wenngleich auch ein paar DISCONNECTS und CONNECTS vorkamen.

Da das Verhalten mMn nicht ganz deterministisch ist (oder ich es nicht als solches erkenne ;)) hier zunächst die Logmessages vom Mosquitto, nachdem ich fhem über shutdown restart neu starte:
1542810911: New connection from 192.168.178.72 on port 8883.
1542810912: New client connected from 192.168.178.72 as fhemMQTT2CLIENT (c1, k30).
1542810912: Sending CONNACK to fhemMQTT2CLIENT (0, 0)
1542810912: Received SUBSCRIBE from fhemMQTT2CLIENT
1542810912:     # (QoS 0)
1542810912: fhemMQTT2CLIENT 0 #
1542810912: Sending SUBACK to fhemMQTT2CLIENT
1542810913: Received PINGREQ from MQTT_FX_Client
1542810913: Sending PINGRESP to MQTT_FX_Client
[...]
1542810923: Socket error on client fhemMQTT2CLIENT, disconnecting.
1542810923: New connection from 192.168.178.72 on port 8883.
1542810923: Socket error on client <unknown>, disconnecting.
1542810924: New connection from 192.168.178.72 on port 8883.
1542810924: Socket error on client <unknown>, disconnecting.
1542810924: New connection from 192.168.178.72 on port 8883.

Also zunächst wird der Client als fhemMQTT2CLIENT erkannt, nach dem reconnect bleibt er aber <unknown>.

Im Eventlog von fhem erscheinen folgende Nachrichten:
2018-11-21 15:39:25 MQTT_GENERIC_BRIDGE mqttGenericBridge transmission-state: outgoing publish sent
2018-11-21 15:39:25 MQTT_GENERIC_BRIDGE mqttGenericBridge outgoing-count: 6
2018-11-21 15:39:25 HMCCURPCPROC d_rpcBidCos_RF rpcstate: running
2018-11-21 15:39:25 MQTT_GENERIC_BRIDGE mqttGenericBridge transmission-state: outgoing publish sent
2018-11-21 15:39:25 MQTT_GENERIC_BRIDGE mqttGenericBridge outgoing-count: 7
[...]
2018-11-21 15:39:25 MQTT2_CLIENT mosquitto DISCONNECTED
2018-11-21 15:39:25 MQTT2_CLIENT mosquitto CONNECTED
2018-11-21 15:39:25 MQTT2_CLIENT mosquitto DISCONNECTED
2018-11-21 15:39:25 MQTT2_CLIENT mosquitto CONNECTED
2018-11-21 15:39:55 MQTT2_CLIENT mosquitto DISCONNECTED
2018-11-21 15:39:55 MQTT2_CLIENT mosquitto CONNECTED

Die MQTT2_CLIENT Nachrichten erscheinen ca. alle 30 Sekunden, die MQTT_GENERIC_BRIDGE messages alle 10 Minuten.

Das fhem Logfile liefert:
2018.11.21 15:39:13 3: mosquitto device opened
2018.11.21 15:39:24 1: reddocker:8883 disconnected, waiting to reappear (mosquitto)
2018.11.21 15:39:25 1: reddocker:8883 reappeared (mosquitto)
2018.11.21 15:39:25 1: reddocker:8883 disconnected, waiting to reappear (mosquitto)
2018.11.21 15:39:25 1: reddocker:8883 reappeared (mosquitto)
2018.11.21 15:39:25 1: reddocker:8883 disconnected, waiting to reappear (mosquitto)
2018.11.21 15:39:25 1: reddocker:8883 reappeared (mosquitto)
2018.11.21 15:39:55 1: reddocker:8883 disconnected, waiting to reappear (mosquitto)
2018.11.21 15:39:55 1: reddocker:8883 reappeared (mosquitto)
2018.11.21 15:40:25 1: reddocker:8883 disconnected, waiting to reappear (mosquitto)
2018.11.21 15:40:25 1: reddocker:8883 reappeared (mosquitto)


Ein Test-Publish vom MQTT2_CLIENT set mosquitto publish fhempub/TOPICVONHAND liefert:
2018-11-21 15:54:25 MQTT2_CLIENT mosquitto publish fhempub/TOPICVONHAND
2018-11-21 15:54:25 MQTT2_CLIENT mosquitto DISCONNECTED
2018-11-21 15:54:25 MQTT2_CLIENT mosquitto CONNECTED
2018-11-21 15:54:25 MQTT2_CLIENT mosquitto DISCONNECTED
2018-11-21 15:54:25 MQTT2_CLIENT mosquitto CONNECTED
2018-11-21 15:54:55 MQTT2_CLIENT mosquitto DISCONNECTED
2018-11-21 15:54:55 MQTT2_CLIENT mosquitto CONNECTED


und im Mosquitto Log:
1542812065: Socket error on client <unknown>, disconnecting.

Das gleiche Topic über den MQTT.fx Client klappt einwandfrei.
Zunächst der Connect des MQTT.fx Clients (Mosquitto log):
1542817031: New connection from 192.168.178.102 on port 8883.
1542817031: New client connected from 192.168.178.102 as MQTT_FX_Client (c1, k60).
1542817031: Sending CONNACK to MQTT_FX_Client (0, 0)


Und das das Logfile beim Versenden eines Test Topics (Mosquitto):
1542812378: Received PUBLISH from MQTT_FX_Client (d0, q0, r0, m0, 'test/blub', ... (0 bytes))
1542812378: Sending PUBLISH to mqtt_a3e42221.393db (d0, q0, r0, m0, 'test/blub', ... (0 bytes))
1542812378: Sending PUBLISH to MQTT_FX_Client (d0, q0, r0, m0, 'test/blub', ... (0 bytes))
1542812385: Received PINGREQ from WZ_Sonoff_4FachLeiste1_2


Hilft das weiter? Wenn nicht, kann ich irgendwie anders helfen?

Viele Grüße
Sascha

Beta-User

Zu OT: MQTT2_CLIENT sollte mit allowed zusammenarbeiten (das ist - neben der Unterstützung von MQTT2_DEVICE der wesentliche Vorteil gg. der alten MQTT-Implementierung).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rudolfkoenig

Zu OT: MQTT2_CLIENT ist (im Gegensatz zu MQTT2_SERVER) nicht per allowed zu berechtigen, sondern per "attr mosquitto username XXX" und "set mosquitto password YYY". Hintergrund: allowed ist fuer die Server-Seite gedacht, wo man Benutzername/Passwort prueft. allowed speichert nur den Hashwert fuer das Passwort (nicht den Klartext), und man kann mehrere allowed Instanzen einem Server zuweisen, um unterschiedliche Berechtigungen (ausfuehrbare Befehle) zu realisieren, jenachdem, wer sich angemeldet hat.

Zu den Logs: vielen Dank, reicht aber noch nicht, vulgo ich habe keine Idee. Was auffaellt: mosquitto meldet Socket error 11 Sekunden nach dem Connect, da sollte keepalive noch keine Rolle spielen. Insb. macht MQTT2_CLIENT selbst die Verbindung nur beim Attribut aendern oder Shutdown/etc zu, aber dann mit einer MQTT-DISCONNECT Meldung.

Koenntest du ein Problemfall in FHEM mit "attr mosquitto verbose 5" dokumentieren? Ich wuesste gerne, ob FHEM vorher noch was senden will.
Wie sind die beiden Partner (FHEM und mosquitto) verbunden? Gibt es Firewalls, Proxy, etc dazwischen? Ich vermute z.Zt. dass irgendsowas die Verbindung zuklappt.
Gibt es auch ohne SSL Probleme?

betateilchen

Was bin ich doch froh, dass ich nicht der einzige mit dem Verbindungsproblem bin...
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

HomeAlone

Zitat von: rudolfkoenig am 22 November 2018, 11:48:35
Zu den Logs: vielen Dank, reicht aber noch nicht, vulgo ich habe keine Idee. Was auffaellt: mosquitto meldet Socket error 11 Sekunden nach dem Connect, da sollte keepalive noch keine Rolle spielen. Insb. macht MQTT2_CLIENT selbst die Verbindung nur beim Attribut aendern oder Shutdown/etc zu, aber dann mit einer MQTT-DISCONNECT Meldung.

Koenntest du ein Problemfall in FHEM mit "attr mosquitto verbose 5" dokumentieren? Ich wuesste gerne, ob FHEM vorher noch was senden will.
Wie sind die beiden Partner (FHEM und mosquitto) verbunden? Gibt es Firewalls, Proxy, etc dazwischen? Ich vermute z.Zt. dass irgendsowas die Verbindung zuklappt.
Gibt es auch ohne SSL Probleme?

Hallo Rudi,
Firewall und Proxy gibt es zwischen den beiden hosts nicht. Um es sauber zu dokumentieren, habe ich jetzt einmal alles MQTT-mäßige in fhem entfernt und starte eine neue Versuchsreihe, um dem Fehler (hoffentlich) systematisch auf die Spur zu kommen.

Hier die geplante Versuchsreihe (schaffe ich aber sicherlich nicht alles heute und morgen):

Grundkonfiguration

  • verbose 5 in MQTT2_CLIENT
  • log_level all in Mosquitto
  • Vergleichsclient: MQTT.fx (mit Subscription auf #)

Testreihe
Ver host hostname usr pwd tls
1 local localhost no no no
2 local smartgulp2 - - -
3 local smartgulp2 yes yes no
4 local smartgulp2 yes yes yes


Ver = Version, host = der host, auf dem Mosquitto läuft, hostname = der Name mit dem ich den host in der Config zu MQTT2_CLIENT anspreche, usr = Benutzername wird verwendet, pwd = Passwort wird verwendet, tls = Attribut SSL auf 1

Die einzelnen Versuchsrehien folgen als eigenständiges Posting, sonst verliere ich selbst den Überblick. Die erste habe ich gerade durchgeführt, kommt also sofort. Kann danach erst heute Abend weitermachen.

HomeAlone

#89
Versuch V1

  • Mosquitto lokal installiert
  • als localhost in der Definition angegeben
  • kein Benutzer für die Verbindung
  • kein Passwort für die Verbindung
  • keine TLS-Verschlüsselung

Config
defmod mosquittolocal MQTT2_CLIENT localhost:1883
attr mosquittolocal room MQTT,Zentralen
attr mosquittolocal verbose 5


Verbindungsaufbau
Verbindungsaufbau fhem (logfile Mosquitto):
1543048260: New connection from 127.0.0.1 on port 1883.
1543048260: New client connected from 127.0.0.1 as mosquittolocal (c1, k30).
1543048260: Sending CONNACK to mosquittolocal (0, 0)
1543048260: Received SUBSCRIBE from mosquittolocal
1543048260:     # (QoS 0)
1543048260: mosquittolocal 0 #
1543048260: Sending SUBACK to mosquittolocal
1543048290: Received PINGREQ from mosquittolocal


Verbindungsaufbau fhem (logfile fhem):
2018.11.24 09:30:54 5: HttpUtils url=http://localhost:1883/
2018.11.24 09:31:00 5: HttpUtils url=http://localhost:1883/
2018.11.24 09:31:00 1: localhost:1883 reappeared (mosquittolocal)
2018.11.24 09:31:00 5: mosquittolocal: received CONNACK (0)(0)
2018.11.24 09:31:00 5: mosquittolocal: received SUBACK (0)(4)(0)
2018.11.24 09:31:30 5: mosquittolocal: keepalive 30
2018.11.24 09:31:30 5: mosquittolocal: received PINGRESP
2018.11.24 09:32:00 5: mosquittolocal: keepalive 30


Verbindungsaufbau MQTT.fx (logfile Mosquitto):
1543048489: New connection from 192.168.178.102 on port 1883.
1543048489: New client connected from 192.168.178.102 as MQTT_FX_Client (c1, k60).
1543048489: Sending CONNACK to MQTT_FX_Client (0, 0)
1543048500: Received PINGREQ from mosquittolocal
1543048500: Sending PINGRESP to mosquittolocal
1543048530: Received PINGREQ from mosquittolocal
1543048530: Sending PINGRESP to mosquittolocal
1543048549: Received PINGREQ from MQTT_FX_Client
1543048549: Sending PINGRESP to MQTT_FX_Client
1543048560: Received PINGREQ from mosquittolocal


Subscribe von MQTT.fx (logfile Mosquitto):
1543048682: Received SUBSCRIBE from MQTT_FX_Client
1543048682:     # (QoS 0)
1543048682: MQTT_FX_Client 0 #
1543048682: Sending SUBACK to MQTT_FX_Client


Topic publishen
publish von MQTT2_CLIENT (Logfile Mosquitto):
1543048922: Received PUBLISH from mosquittolocal (d0, q0, r0, m0, 'fhem/test', ... (0 bytes))
1543048922: Sending PUBLISH to mosquittolocal (d0, q0, r0, m0, 'fhem/test', ... (0 bytes))
1543048922: Sending PUBLISH to MQTT_FX_Client (d0, q0, r0, m0, 'fhem/test', ... (0 bytes))


publish von MQTT2_CLIENT (Logfile fhem):
2018.11.24 09:42:02 5: mosquittolocal: sending PUBLISH fhem/test
2018.11.24 09:42:02 1: PERL WARNING: Use of uninitialized value $a[0] in string eq at ./FHEM/00_MQTT2_CLIENT.pm line 238.
2018.11.24 09:42:02 5: mosquittolocal: received PUBLISH (0)(9)fhem/test
2018.11.24 09:42:02 5: mosquittolocal: dispatch mosquittolocal:fhem/test:
2018.11.24 09:42:30 5: mosquittolocal: keepalive 30


Vielleicht hilft hier das PERL WARNING ja schon weiter?

Wie gesagt, weitere Versuche erst heute Abend.

Viele Grüße
Sascha