issue with MQTT client: async-mqtt-client vs PubSubClient

Hi all,

In My ESP32, I've implemented the PubSubClient librabry for a Project; it works fine but I've a problem. When I try to publish the following message, the publish() function fails returning "false" value and I don't understand why.

The message is this one: "{"timestamp":"1560296856","temperature":"26.60","humidity":"54.00","moisture":"38.39","gas":"100.00","rain":"100.00"}"

Deleting the rain block it is published without error so it seems that the message is too long. I've also tried to set the following variables but without success.

  • MQTT_MAX_PACKET_SIZE
  • MQTT_MAX_TRANSFER_SIZE

Do you have any idea? How can i debug in order to have more info?

For the above reason I tried to use async-mqtt-client library but I cannot compile the code due to an incopatibility with WiFi.h library. Do you have a guide on how to configure it from scretch in arduino IDE?
Anyway, looking at async-mqtt-client/FullyFeatured-ESP32.ino at master · marvinroger/async-mqtt-client · GitHub example, seems that i have to use FreeRTOS software timers. Is it a mandatory condition?

Thanks,
Max

so it seems that the message is too long.

So, why not shorten it? Do you REALLY need "timestamp"? Wouldn't "time" do as well? "temp"? "hum"?

Do you really think you are measuring the temperature to the nearest 0.01 degrees C?

Do you really think you are measuring relative humidity to 0.01%?

thanks for the feedback. You are right, I could definitely reduce the number of characters to be used but please keep in mind the following considerations:

  • this is just an example, in the future I might not be able to reduce the json payload. What can I do in that scenario?
  • you are assuming that the issue is a lenght limitation, are we 100% sure?
  • how can I have a more detailed error message?
  • consider this issue as the first case of debugging need. is it possible?

Thanks,
Max

this is just an example, in the future I might not be able to reduce the json payload. What can I do in that scenario?

Deal with that when it becomes a problem.

you are assuming that the issue is a lenght limitation, are we 100% sure?

100% sure? No. Is it a reasonable assumption, based on the evidence? Yes. Can it be tested? Yes.

how can I have a more detailed error message?

More detailed than what?

consider this issue as the first case of debugging need. is it possible?

Of course. The "library" you are using are just header and source files that get compiled and linked, just like your ino file. Just like in the ino file, you can add Serial.print() statements to the cpp file(s) that make up the library.

Deal with that when it becomes a problem.

As I said, it is just an example, I will face the problem very soon, as soon as I’ll enrich the json (I already have in mind to do it). I need to sort it out somehow (different library?)

More detailed than what?

than “false” message…it would be good to have a verbose message.

Of course. The “library” you are using are just header and source files that get compiled and linked, just like your ino file. Just like in the ino file, you can add Serial.print() statements to the cpp file(s) that make up the library.

it is a good hint! I did not think about it even if it is very simple solution. I was looking for different solutions like this one: https://devblogs.microsoft.com/iotdev/debug-your-arduino-code-with-visual-studio-code/

What about async-mqtt-client? Have you ever tried it?

Thanks,
Max

than "false" message...it would be good to have a verbose message.

I understand this even less.

Programmers are often terrible at documenting limitations in their code, because they assume that everyone will use it the same way they do, for the same purposes. Any attempt to use it differently is usually not even handled correctly. That sounds an awful like what is happening with this library to you.

So, you have an opportunity to improve the library, documenting, and properly handling the limitations.

Lucky you.

Have you ever tried it?

No. I haven't a use for mosquitoes, in any form. I keep bug repellent handy, if any are expected to be around.