Go Down

Topic: [SOLVED]MQTT library PubSubClient: why "client.connect" is false so often (Read 664 times) previous topic - next topic

EricExperiment

May 26, 2014, 02:53 am Last Edit: Jun 20, 2014, 02:27 am by EricExperiment Reason: 1
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?


Code: [Select]


#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)
 {
   client.loop();
   keepalivetime = millis();
 }
}  // end of loop

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"

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

EricExperiment


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.

EricExperiment

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.

EricExperiment

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

hazymat

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!

Go Up