Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to ascertain if received message is 'retained'. #84

Open
newtovaux opened this issue Oct 15, 2017 · 15 comments
Open

Unable to ascertain if received message is 'retained'. #84

newtovaux opened this issue Oct 15, 2017 · 15 comments

Comments

@newtovaux
Copy link

In the callback function definition, there is no provision to know whether a received message was 'retained' (only topic, payload and length).

The data should be available in the retain flag of the message.

A subscribing client can identify if a received message was a retained message or not, because the broker sends out retained messages with the retained flag still set to true. A client can then decide on how to process the message.

@Imroy
Copy link
Owner

Imroy commented Oct 15, 2017

Can you not use pub.retain()?

@newtovaux
Copy link
Author

Where is that defined? I can't find it in PubSubClient.h

@Imroy
Copy link
Owner

Imroy commented Oct 15, 2017

It'll be in MQTT.h, in the 'Message' base class. As I explain in the README, I added a set of classes for the MQTT messages and PubSubClient is mostly just a wrapper.

@capedra
Copy link

capedra commented Oct 27, 2017

@Imroy
I've been having a 'retain' struggle on ESP8266-OTA implementation. The messages aren't getting retained on my own broker. Sometimes it retains but sometimes it doesn't. I've already changed qos to 1 and 2 but this issue persists. Maybe because the body of the message is empty? I'm still trying to find out the reason why.

@capedra
Copy link

capedra commented Oct 27, 2017

The publish function returns true and I already tried the following lines but this issue still happens:

if (mqtt_client.publish(pub.topic(), (uint8_t*) "", 0, true))
   Serial.println("Published!");

Also:

if (mqtt_client.publish(MQTT::Publish(pub.topic(), "").set_retain().set_qos(1)))
   Serial.println("Published!");

@Altair31
Copy link

Altair31 commented Oct 27, 2017

Maybe because the body of the message is empty?

A retained topic with empty message means clear this retained topic (if any).
Can you try to set a payload to your message?

@Testato
Copy link

Testato commented Oct 27, 2017

Is the retained message stored in Ram ? If I reboot the broker I will loose the message ?

Sorry for the semi-ot, but on my mosquitto broker the retained message work, but after some days/weeks the retained messages is lost (I do not know what happens, i see only all the clients without message)

@Altair31
Copy link

No, I use mosquitto with my home-made IOT without problems (and I also use retained messages).
Can you check with another software like paho?

@Testato
Copy link

Testato commented Oct 28, 2017

So you mean that a retained message is stored on the server harddisk and it remains on the hdd indefinitely ?

@Altair31
Copy link

It depends on broker's implementation but it seems to be done that way by mosquitto.

@capedra
Copy link

capedra commented Oct 29, 2017

Is the retained message stored in Ram ? If I reboot the broker I will loose the message ?

According to the MQTT protocol, servers can, theoretically, keep retained messages forever, although sometimes there's a limit set by the broker's configuration. Consider, for example, RabbitMQ, which has a 24 hours retention limit by default, even though you can customize this configuration at anytime on it.
I've been using Mosquitto on DO (DigitalOcean), and I even tried to reboot the server but the retention is maintained intact after it.

@capedra
Copy link

capedra commented Oct 29, 2017

Can you try to set a payload to your message?

Yeah, I've been trying with different payloads but, sometimes, the broker does not get the published message from the Wemos D1 Mini Pro.
UPDATE: current version of mosquitto's broker: 1.4.8.
I will be doing some tests on the version 1.4.14 which fixes some issues related to persistent data.

@Testato
Copy link

Testato commented Oct 29, 2017

But 1.4.14 fix a regression on .13 version, so your .8 version should be non affected.

Some of you have retained message that do not change for very long time ? For example have some of you a retained message stored 6 months ago or 1 year ago ?

@capedra
Copy link

capedra commented Oct 29, 2017

But 1.4.14 fix a regression on .13 version, so your .8 version should be non affected.

You're right. Unfortunately, the persistent data issue persists on 1.4.14.
UPDATE: I think I know what's going on, but, just to make sure, I will do a zillion tests more before posting the results here.

@Booli
Copy link

Booli commented Apr 30, 2018

So did you ever figure this out?
I have a problem with the OTA sketch example where the message to clear the update is not send (so from the ESP8266), making the ESP8266 either go into a loop or just hang on it's face after reboot.
I put an if() around the publish and indeed sometimes it just does not publish the message.

Tried QoS 1 and 2, but both to no avail. I suspect it just fails to send it in a first try and then straight after the example sketch just disconnects the client.

I would like to reliably use this to update multiple ESP8266 in the field by MQTT, but I'm stuck on this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants