How to publish a long array of float with MQTT?

Hi to everybody,
I am new to this forum and I am struggling on an issue that I imagine many of you consider for dummies..
I want to send via MQTT an array of 720 float data, thus needing to convert them into string and then applying the c_str() method for sending them, with the client.publish() command.
The problem is that, when I publish them, I get as serially printed the correct publishment notification, but at Broker side (Raspberry Pi3), when I go to read the received data I don't read anything, the file remains empty as the beginning.
In the following, a part of the code I have employed, using an ESP32:

    while(i < DIM)
    {
      xQueueReceive(queue, &ecg_vect[i], portMAX_DELAY);
      ecg_vect_str += String(ecg_vect[i]);
      ecg_vect_str += ", ";
      i++;
      vTaskDelay(1);
    }

    if((client.publish(ecg_topic, ecg_vect_str.c_str()), strlen(ecg_vect_str.c_str()), true))
    {
    	Serial.print("Data correctly sent, cycle number: ");
        Serial.println(j);
    }
    j++;
    ecg_vect_str = "";

I thought that the problem could be at broker side, but if I changed the sent data from the one represented here and a simple sentece like "end of string" or similars, it works.
Does anybody know where I went wrong?

Thank you for the support"

Instead of converting float to string you can publish floats as byte array.
See the principle:

720 32 bit floats may not properly fit into the payload of MQTT packet.

I found its best to limit the number of 0's past the decimal point that the client sends when sending large arrays of floats as a MQTT payload.

What if I decrease the payload to the half?
Do you think it could work?

Ok, very interesting, I will try this, thank you.
But, I am a bit confused about my code using strings, I would like to understand why it doesn't work even though it seems to.

What is the full length of composed string?

And limiting the number of decimal places sent.

Do you need
0000000000000000000000000000.00000000000000000000000000000 for each 32 bit float you send?

It changes as the numbers I send via MQTT progressively increase.
Indeed, at the moment I only send a counter that is progressively increased by 1 each time.
I did not set a default length of the string for this reason

No you're right!
How could I do?

rounding.

The search box is a useful tool.


For instance, using the words "9v battery" in the search box one could find lots of reasons why this may be a bad idea.

Other search words include "level shifter", "round"

Did you test what the maximum length will be in your code?

I found the issue is more on the RPi MQTT BROKER end when sending "large" array's of float values. Somehow the Broker gives all the proper call and response but does not actually store the float values and can cause the broker to get locked up.

I rounded to the minimum number of decimal places, and decreased the dimension of the array from 720 to 55..a drastic decrease.
What I found out is that by reducing everything I could to the minimum, the Broker receives the first two cycles (counter from 1 to 55 and from 56 to 110) and then it blocks...

This is the screenshot at broker side...I am using Anydesk since the Rasp is in another room, but I hope it is sufficiently clear.
I neither don't know why I read a '?'..since I never send this character, but anyway as you can see after these two cycles the broker stops receiving albeit the publisher continues sending data and notifies that the latter have been successfully sent.

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.