Receiving messages on subscription as publish packets about arduinomqtt

[rapasal]

Yes! That's just what I needed. Thanks for your help. Great library by the way!

[monstrenyatko]

Hi @rapasal
What broker do you use?
Please provide a full debug log. See #define MQTT_LOG_ENABLED 1

I didn't notice anything very wrong from the first look. Need to debug.
Try to add more logs to void deliverMessage(MQTTString& topic, Message& message) {} method.
It looks like the client can't match the topic value with the value used on subscribe.
You use clean session, so the broker should not send messages until you subscribe and set the handler...
Verify the topic value is sent by the broker

Try to reproduce the same using public MQTT broker like Mosquitto and on x86 platform. See example
It could be easier to debug on PC.

[rapasal]

I reformatted to bring the code listed above out of the MqttWrapper class and it works fine! For some reason wrapping it up introduces this behavior. I will do some experimenting today with some logic wrapped and some just in setup() and loop() to see if I can spot what breaks it. I'll add some extra logs like you suggest too.

[rapasal]

OK, so I have been playing around and found that the problem is when calling mqtt->subscribe(...). In my example above I had a hard coded topic. I got myself in a muddle before posting and was actually calling this with a char array instead of a hard coded string when I got the error.

char subTopic[64];
functionToPopulateSubTopic(subTopic);
mqttWrapper.mqtt->subscribe(subTopic, MqttClient::QOS0, subCallback);

When I hard code as per my initial example it actually works! When I pass the char array in I get the error described. Having the code in a wrapper has no effect. I can confirm that running the ConnectEsp8266WiFiClient example in Arduino IDE also shows the same error when using a char array as the subscription topic.

When I pass a char array to mqtt->publish(...) it works fine. I noticed that the topic argument for both subscribe and publish are converted into a MQTTString differently, and tried to use the implementation from publish in the subscribe method but no luck.

I added the following line to deliverMessage(...) inside the for loop:

MQTT_LOG_PRINTFLN("Incoming topic: %s", (char*)(mMessageHandlers.get()[i].topic));

This threw up something strange... When I hard code the subscription address this prints the correct topic. When I pass the subscription address as a char array it prints the publish topic! I know that the char array I pass definitely contains the subscription topic as I print it right before calling subscribe(...).

I'm not sure what the solution here is. Hard coding isn't really an option as I want to be able to store the topics in arrays so that they can be edited at run time.

[monstrenyatko]

@rapasal
I think your problem with a string allocated on stack.
When you use this library or the original Paho library you have to assume that nothing is copied by default.
You have full memory control. That is good for embedded systems.
The topic is stored by reference in default implementation.
Look at

• MqttClient::MessageHandlersStaticImpl
• MqttClient::MessageHandlersDynamicImpl

I guess this is exactly what you need to avoid hardcoded topics.
If you know the maximum topic length I would suggest using MessageHandlersStaticImpl

I see no problem with the default MessageHandlers implementation if you guaranty the topic pointer is valid until you unsubscribe.
You can organize own topic storage or write custom MessageHandlers implementation if you wish

The library is flexible enough to provide everything externally with no need for library modification.