MQTT Probleme

[stif]

Leider funktioniert die MQTT Kommunikation mit Basecamp nicht so wie sie soll oder ich mache irgendwas falsch..

Wenn ich das FullyFeatured-ESP32 Beispielprogramm von der AsyncMqttClient Bibliothek lade, kann ich problemlos MQTT Messages über den Broker iot.eclipse.org (IP 198.41.30.241) senden und empfangen:

Connecting to MQTT...
Connected to MQTT.
Session present: 0
Subscribing at QoS 2, packetId: 1
Publishing at QoS 0
Publishing at QoS 1, packetId: 2
Publishing at QoS 2, packetId: 3
Subscribe acknowledged.
  packetId: 1
  qos: 2
Publish received.
  topic: test/lol
  payload: myTest 2�
  qos: 1
  dup: 0
  retain: 1
  len: 8
  index: 0
  total: 8
Publish received.
  topic: test/lol
  payload: test 1@�
  qos: 0
  dup: 0
  retain: 0
  len: 6
  index: 0
  total: 6
Publish acknowledged.
  packetId: 2
Publish received.
  topic: test/lol
  payload: test 2P�
  qos: 1
  dup: 0
  retain: 0
  len: 6
  index: 0
  total: 6
Publish acknowledged.
  packetId: 3
Publish received.
  topic: test/lol
  payload: test 3
  qos: 2
  dup: 0
  retain: 0
  len: 6
  index: 0
  total: 6

Wenn ich dasselbe mittels der Basecamp Bibliothek ausprobiere (Gist zum Beispielprogramm), kommen die Messages mit payload myTest 1 und qos 0 sowie payload myTest 2 und qos 1 am broker an. Jedoch wird die Funktion onMqttPublish und onMqttSubscribe nicht aufgerufen, und es kommen weder manuell gesendete Messages an, noch welche wo eigenlich eine subscription auf das Topic besteht:

Connected to MQTT.
Session present: 0
Subscribing at QoS 2, packetId: 1
Publishing at QoS 0
Publishing at QoS 1, packetId: 2
Publishing at QoS 2, packetId: 3
Disconnected from MQTT.
Connected to MQTT.
Session present: 0
Subscribing at QoS 2, packetId: 0
Publishing at QoS 0
Publishing at QoS 1, packetId: 0
Publishing at QoS 2, packetId: 0
Connected to MQTT.
Session present: 0
Subscribing at QoS 2, packetId: 0
Publishing at QoS 0
Publishing at QoS 1, packetId: 0
Publishing at QoS 2, packetId: 0

Die Message myTest 3 mit qos 2 kommt im Gegensatz zu myTest 1 und myTest 2 gar nicht am Broker an.. (habe ich mittles der Chrome WebApp MQTTlens getestet)
Ausserdem wird, aus welchem Grund auch immer, die Verbindung zum MQTT Broker 3x aufgebaut..

[Mutzmann]

Die Probleme mit dem Verbindungsaufbau beschäftigen mich auch. Mein Basecamp Client bekommt keine Verbindung zum Broker, immer dann, wenn er gleichzeitig 3 TCP Verbindungen zum Broker öffnet. Ich habe mir die Kommunikation von Client und Broker mit Wireshark angesehen. Wenn eine MQTT-Verbindung steht, schließt der Broker diese, sobald die nächste MQTT-Verbindung geöffnet wird. Ich habe allerdings keine Idee, warum 3 Verbindungen parallel geöffnet werden. Könnte es an der Verzögerung (in "Ticks") liegen, falls beim Verbindungsaufbau noch keine MQTT-Verbindung steht? Ich habe die Verzögerung mal auf 1000 erhöht und beobachte das Verhalten mal https://github.com/merlinschumacher/Basecamp/blob/0979ef1c234a036afb7bd8a8046dbf5219835384/Basecamp.cpp#L280

Hier meine Mitschnitte:

Client 192.168.1.116 - Broker 192.168.1.119

Nach mehrmaligen Neustarten des ESP klappt es irgendwann - in diesem Fall wurde aber nur eine TCP-Verbindung geöffnet.

[Mutzmann]

Ich habe es mit vTaskDelay(1000) getestet und bisher konnte ich die Verbindungsprobleme nicht reproduzieren. Es scheint also das Problem zu beheben!

[merlinschumacher]

Ich werde mir das mal genauer anschauen. Ich war länger krank und hatte noch keine Zeit mich darum zu kümmern.

[david-m-m]

Ich habe ähnliche Probleme gehabt und habe bei
https://github.com/merlinschumacher/Basecamp/blob/master/Basecamp.cpp#L290
ein
vTaskDelay(1000);
eingefügt. (Der Wert von 100 ist zu klein, s.u.)

Zusatzinfo: Im Debug Log sehe ich, dass mqttHandling oft mehrfach versucht, mit dem MQTT Broker zu verbinden, was am mehrfachen Aufruf des onConnect Callbacks erkennbar ist. Mit dem zusätzlichen Delay besteht eine große Wahrscheinlichkeit, dass nur ein einziger Connect erfolgt. Dann und nur dann ist auch das Publishen und Subscriben von Topics (im onConnect Callback) erfolgreich.

[obrain17]

Der komplette Austausch der Routine für das MQTT Handling bringt sicher Besserung. Die Verbindung wird beim Start nur einmal aufgebaut und der Re-Connect erfolgt nur auf Veranlassung vom Async-MQTT-Client. (KeepAlive Funktionalität).

Siehe Pull Request #64