[Solved] No Broker connection about pubsubclient HOT 25 CLOSED

What version of MQTT broker used?
Instead of "original" pubsubclient this code required 3.1.1, not 3.1.
Latest git version work well for me with mosquitto 1.4.2, but I has similar errors on 1.3.x (from ubuntu 10.04 repo)

from pubsubclient.

you are right, i tried using mqttspy whit protocol mqtt3.1.1 and mosquitto do not receive the message.

I think it is important write to the readme that this version use only 3.1.1 protocol and that the user must check if the broker support it.

A question little OT, on mosquitto is there a command for check it version ?
Mosquitto is very common so maybe this command also is good to write in your readme

from pubsubclient.

Oh yeah, sorry about that. I used the MQTT 3.1.1 docs when creating the MQTT::* classes.
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.pdf

In particular, the CONNECT message now sends "MQTT" as the protocol name and protocol level 4, whereas knolleary's code sent "MQIsdp" and protocol level 3. There's no way to know beforehand which to send. Perhaps try the new version and fall back to the old if it gets no response?

BTW, I'm running Mosquitto 1.3.4 on Debian Sid.

from pubsubclient.

@Testato type mosquitto -h and look at mosquitto version. basic 3.1.1 support added in 1.3 but ubuntu uses own version numbering and packets from repo really does not support 3.1.1.

@Imroy custom build/custom repo? I have debian 7 on VPS with 1.4.1

For now I prefer to build mosquitto from scratch because I want to enable built-in websockets server in 1.4

from pubsubclient.

@Imroy
/ # mosquitto -h
mosquitto is an MQTT v3.1 broker.

-h command write only the protocol that mosquitto support, but not the mosquitto version.
It seems that on mosquitto there is no command that check it version ? it is strange.

from pubsubclient.

After some reading, it looks like knolleary had implemented MQTT 3.1:
http://www.hivemq.com/6-facts-why-its-worth-upgrading-to-mqtt-3-1-1/
https://github.com/mqtt/mqtt.github.io/wiki/Differences-between-3.1.0-and-3.1.1

Would a compile-time define selecting for 3.1-only operation be good enough?

from pubsubclient.

@Testato Looking at the Mosquitto source, version 1.3.4 at least accepts a "MQTT"/level 4 connection packet. It may not be fully MQTT 3.1.1 compliant though.

from pubsubclient.

Would a compile-time define selecting for 3.1-only operation be good enough?

It may be helpful for older systems. For newer we have more recent versions and third-party ppa

You should at least document supported version (boldfaced in readme.md for example). AFAIR, NodeMCU mqtt client also uses 3.1.1

from pubsubclient.

Would a compile-time define selecting for 3.1-only operation be good enough?

like av1024 say it is not important, we can install the last mosquitto and resolve the problem.
It is only important write in the readme file that this lib use MQTT 3.1.1, and the command to install the last version of mosquitto to help the user to install the right version.
I'm on Debian, default installation for BBB, and on the repository is there the old version of mosquitto

from pubsubclient.

@Testato Hmmm... As I can see in mosquitto's makefile, the full version appended to help, but it is from git sources. May be your version too old ((

in debian/ubuntu you may invoke apt-cache show mosquitto and search version in output. As an suggestion - description should contain "MQTT version 3.1/3.1.1" not "3.1".

PS: I remember - on VPS I install fresh version from mosquitto's repo, original package has version 0.15-2

from pubsubclient.

wasnt a simple way to to 3.1.1 on Ubuntu 14.04 through apt-get, so i added the official mosquitto dev ppa and upgraded to 1.4.2a. I can now receive fine on the server, but i still get connection refused on the esp8266 when i try to publish back to it. Im using your mqtt_basic example as well.

from pubsubclient.

Okay, notice added to README. What about a list of supported brokers?

from pubsubclient.

@MACscr Try start mosquitto -v -c /etc/mosquitto.conf (remember to stop service before) and check config. I have some issues with old config after upgrade so service don't start

@Imroy What about a list of supported brokers?

It's will be helpful for newbies )) At least simple list of existing brokers (including online services)...

from pubsubclient.

/ # apt-cache show mosquitto
Package: mosquitto
Version: 0.15-2
Description: MQTT version 3.1 compatible message broker

Architecture: armhf
maybe on the ARM mosquitto is not maintained animore ?

from pubsubclient.

@av1024 the broker is is receiving fine, it just cant send anything back to the esp.

root@openhab:~# mosquitto_pub -d -t "inTopic" -h 192.168.1.154 -m "howdy esp"
Error: Connection refused

from pubsubclient.

@Testato this version of mosquitto is 3.1. I was build custom for my cubietruck (2 or 4 libs should be installed as described in build.md and build pre- last (1.3?) libwebsockets if use it)

@MACscr look at server (mosquitto) output. Looks like mosquitto server not running or uses non-default port...

from pubsubclient.

@av1024 Nevermind, i got it fully working. Guess i was a bit to new to mqtt. Thanks!

from pubsubclient.

I installed the ppa from ubuntu repository and now i have the 1.4.2 mosquitto that work on 3.1.1
thanks to @MACscr for the tips ;-)

~ # mosquitto -h
mosquitto version 1.4.2 (build date Mon, 18 May 2015 15:25:19 +0100)

from pubsubclient.

so now the real problem, it work but not always
i publish every seconds :-)

void loop()
{
    delay(1000);

    client.loop();

    if (client.connect("Esp8266_Client")) {
        client.publish("home/temperature", "22");
        Serial.println("Published !");
    }
    else
    {
        Serial.println("No Broker connection !");
    }
}

RESULT

No Broker connection !
Published !
No Broker connection !
No Broker connection !
No Broker connection !
No Broker connection !

Is there a way for debug this problem ?

from pubsubclient.

There is zero reason to publis every second. Most sensors wont even give it to you every second. Change it to something like every 5 seconds or even 15 to be realistic.

from pubsubclient.

You should not call connect every time. Only in setup() and/or after networking reset. Just like following (sample)

UPD: You sholud also call client.loop() more frequently (e.g. every 10-100ms)

void setup() {
// ...
client.connect();
}

bool flag = false;

void loop() {
  if (WiFi.status() == WL_CONNECTED) {
    if (!flag || !client.connected()) {
      flag = client.connect();
    }
    if (flag && client.connected()) {
       client.loop();
       if (some_flag_for_publish) {
         client.publish(...);
       }
    } else {
      // client disconnected
      flag = false;
    }
  } else {
    // wifi fail
    flag = false;
  }
}

from pubsubclient.

As an option I also use Will messages for auto-notify aboud device off-line:

• init client with WILL topic and faulty message (e.g. "offline")
• after connect immediately publish "online" to will topic and QoS == 1
• if device goes offline, the will topic automatically changes to "offline"

from pubsubclient.

o yes, thanks a lot @av1024.
do you know a link on a document that explain this basic question ? like that the connect is needed only one time ?
I have the full specification pdf for mqtt3.1.1, but for start it is better have less information

from pubsubclient.

No ((
Previously I use knolleary version listed on esp2866/Arduino (it was replaced by this one now) and read examples.

Generally logic is:

• class have loop() so it should be (safe?) called every loop or with minimal delay. /btw, My first sketch also use 1-5sec delay and does not provide accurate answers/
• there is keep-alive word in class/proto description - class should be connected once and then keep connection - so do not call connect every time. Default keep-alive in knolleary was 15sec - so if your code does not call loop() more than 15sec the broker set WILL property to WILL_MESSAGE (offline)
• network is not stable channel - you must check connection state of all items every time and reconnect when neeed. Also you should reconnect all underlaing services after top service was reconnected

In my code (https://bitbucket.org/esp8266/sensor-v2) I use extended protection:

• every operation (connect, subscribe, publish) repeated [N] times on failures
• before publish sensor values I publish 'ping' and receive it by ESP - on LuaNode I had silent "send-to-void" )) situations - send with success but not appear on broker (especially if connection broken in the middle of loop)
  You may look at mqtt.h file in my repo but it is not so easy to understand now )))

from pubsubclient.

thanks @av1024 for the explanation

from pubsubclient.