[SOLVED]MQTT library PubSubClient: why "client.connect" is false so often

EDIT: SOLVED. Put client.connect() in setup and have it called just once instead of every time.

I’m working on a wireless sensor node that sends data to a ethernet connected gateway arduino. This gateway Arduino sends MQTT messages to a MQTT broker (Mosquitto). As I’m monitoring MQTT messages, I’m seeing long delays between when sendMQTT = 1 and when the MQTT messages are actually posted. It’s because on many (most?) of the loop, client.connect() is returning false. So many loops go by before the microcontroller actually sends the MQTT message even though the data arrived as much as 15 seconds ago.

I’m not sure why this is happening. I’m don’t have an understanding of what client.connect() is actually doing though. The ethernet sheild connects to the router via static IP address, as far as I know, there’s not too much traffic on the network to confuse things.

Maybe someone with more knowledge of this library can shed some light on things?

#include <Ethernet.h>
#include <Wire.h>
#include <PubSubClient.h>

void loop() 
  if (haveData)
    sendMQTT = 1;
    haveData = false;
  }  // end if haveData
  if (sendMQTT == 1)
    if (client.connect("arduinoClient"))
      dtostrf (SensorNode.var2_float, 4, 1, buff_message);
      client.publish(buff_topic, buff_message);
      sendMQTT = 0;
  }//end if sendMQTT
  if ((millis() - keepalivetime)>15000)
    keepalivetime = millis();
}  // end of loop

AFAIK "client.connect" is a wrapper for "Ethernet.connect" if you use it with the ethernet shield, and the MQtt library expects to speak to the server through some "client"

you can wrap anything with "client" if it has a connect, disconnect, read and write function. I hope that helps

LocalgHost: AFAIK "client.connect" is a wrapper for "Ethernet.connect" if you use it with the ethernet shield, and the MQtt library expects to speak to the server through some "client"

I see. It gives me something to go by - so it looks like "Ethernet.connect" is returning false for some reason. I can't find a rhyme or reason for why that is. Most of the time things go through just fine, sometimes it doesn't, and it's all because this Ethernet.connect is returning false. The ethernet shield I'm using is that Wiznet 5100.

In case anyone is wondering, I'm using this as part of a wireless sensor setup for home automation. Wireless sensor data is being sent to this Arduino, which then posts the data onto the ethernet network via MQTT to be consumed by a program call OpenHAB running on a Raspberry Pi. It works well for the most part, except for some lost data due to the ethernet Arduino not being able to post the data because of client.connect always failing.

At some point, client.connect must start working again...haven't been able to figure it out.

Just an update. The problem seems to have gotten worst since this weekend. I’m not sure if the ethernet shield is starting to go bad or what. I’ve tried two different ethernet shields and they’re both acting really really bad - both just looping around because client.connect() is returning false almost all the time now.

However, when I power the Arduino down and power it back up, the first client.connect() seems to always work.

SOLVED - need to put the client.connect() call in setup instead of every single time I want to publish a message.

Thank you thank you thank you!

I was getting really random behaviours from my sketch, most of the time messages were being sent reliably but randomly it appeared like the Arduino had crashed (I hadn't gotten around to actually testing whether client.connect was failing as I was ignoring the problem hoping it might go away eventually... actually the complex the sketch became the slower and more seemingly unreliable it became)

Anyway, thanks so much for updating the thread in such a clear manner, really helpful to people like me!


While I'm using the ethernet shield, I had a similar problem when using the PubSubClient with a mosquitto on a Raspberry Pi.

Stdout of mosquitto told me 'Invalid protocol "MQTT" in CONNECT from ...'.

The solution was to change the version in the PubSubClient.h from MQTT_VERSION_3_1_1 to MQTT_VERSION_3_1.

After fixing this, it doesn't matter whether PubSubClient.connect() is called from the setup() or loop() function.

Best regards, Ove