This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Mqtt subscriber error

I am experiencing an error that I can't figure it out why it is happening and where to go and try to fix it.

I am using the subscriber implementation on my nRF51, Raspberry Pi as router and broker.

To test it i'm using a python program on Raspberry to publish the "led/state" topic. I set the publisher to send a publish message every 0.5 seconds inside a loop to send 1200 packets, than it closes the connection.

I saw in wireshark that the broker send the publish message to the subscriber than the subscriber send Acknowledgement to the broker and the broker send an Acknowledgement to the subscriber.

So, around 1887 packets sent in this 3 way handshake, the subscriber stops executing and the broker disconnects it because of the timeout. But to get subscriber running again I have to restart and connect it again to the Rpi.

I ran this test publishing in many other ways and the subscriber halts every time around 1885 to 1890 packets.

Is there something on the mqtt code that I can change to not have this issue?

Parents
  • Hello Gustavo,

    There is no good reason in MQTT to stop exchanging packets after a while. I am however suspicious at the BLE level. Is it possible for you to capture BLE logs and notice if the Raspberry Pi is initiating a disconnection?

    Thank you!

  • Gustavo, at this point I am not able to nail down if the issue you report has a direct correlation with the time or the number of packets. I say time because there are timers needed for TCP connection to be kept alive. In order to rule the time factor out, is it possible that you change the KEEPALIVE time of MQTT client on the kit to either a very high value, and change the rate of publishing as well, may be one packet every second or so. After this change, please observe if the unexpected behavior occurs after about the same number of packets. If yes, then we ruled at any correlation with time. And then the problem is purely a function of number of packets.

Reply
  • Gustavo, at this point I am not able to nail down if the issue you report has a direct correlation with the time or the number of packets. I say time because there are timers needed for TCP connection to be kept alive. In order to rule the time factor out, is it possible that you change the KEEPALIVE time of MQTT client on the kit to either a very high value, and change the rate of publishing as well, may be one packet every second or so. After this change, please observe if the unexpected behavior occurs after about the same number of packets. If yes, then we ruled at any correlation with time. And then the problem is purely a function of number of packets.

Children
No Data
Related