-
Notifications
You must be signed in to change notification settings - Fork 114
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
Comments
Can you not use pub.retain()? |
Where is that defined? I can't find it in PubSubClient.h |
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. |
@Imroy |
The publish function returns true and I already tried the following lines but this issue still happens:
Also:
|
A retained topic with empty message means clear this retained topic (if any). |
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) |
No, I use mosquitto with my home-made IOT without problems (and I also use retained messages). |
So you mean that a retained message is stored on the server harddisk and it remains on the hdd indefinitely ? |
It depends on broker's implementation but it seems to be done that way by mosquitto. |
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. |
Yeah, I've been trying with different payloads but, sometimes, the broker does not get the published message from the Wemos D1 Mini Pro. |
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 ? |
You're right. Unfortunately, the persistent data issue persists on 1.4.14. |
So did you ever figure this out? 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. |
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.
The text was updated successfully, but these errors were encountered: