search

Imroy / pubsubclient

A client library for the ESP8266 that provides support for MQTT
MIT License
433 stars 115 forks source link

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

Open newtovaux opened 6 years ago

newtovaux commented 6 years ago

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 commented 6 years ago

Can you not use pub.retain()?

newtovaux commented 6 years ago

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

Imroy commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

Altair31 commented 6 years ago

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

capedra commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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.