Closed matthias-bs closed 1 year ago
One thing which is 'special' or at least different in the TTN case: The username has 15 characters and the password has 98 characters. However, connecting seems to work and the buffer size of 512 bytes should be sufficient, right?
Problem solved! After increasing the buffer size (MQTT_PAYLOAD_SIZE
) to 4096, it worked!
I found the hint here: https://www.thethingsnetwork.org/forum/t/ttn-v3-esp32-mqtt-message-dont-arrive/47509/10
The reason is, that not only the payload, but a whole bunch of metadata is sent in the uplink message...
So the problem was not really related to arduino-mqtt. However, I wonder if there were a way to indicate a buffer overrun!?
Hi,
I encounter a very strange behaviour in a sketch based on ESP32DevelopmentBoard.ino.
Actually, I want to receive a topic from the TTN MQTT broker. See https://www.thethingsindustries.com/docs/integrations/mqtt/ for details; it uses MQTT Standard Version 3.1.1 (only QoS 0). I can see with two other MQTT clients (MQTT Explorer on Linux and IoT MQTT Panel Pro on Android) when the messages are sent.
Instead of receiving the messages in the
messageReceived()
callback,connect()
is invoked at the same time the message is expected (according to the other clients).When I change the MQTT broker (to my local Mosquitto) and the according subscription, the
messageReceived()
callback is invoked as expected. (the switching is done with the definesTTN
andFLORA
fromcredentials.h
in the code below)So the code fails with the first MQTT broker/topic setup and works as intended with the second one.
If have tried the following without observing any difference:
v3/flora-lora@ttn/devices/eui-9876b6000011c87b/up
tov3/+/devices/eui-9876b6000011c87b/up
(in case there is an issue with the length or the @-character)#
Any ideas how to track this down?
My setup is
Please find my sketch below:
credentials.h: