thanks for the ammended API reference now covering the MQTT client.
Can you please comment on the correct use of the retained flag with your (fabulous) MQTT-broker?
Target:
In order to receive default settings from the broker when my (Arduino) system reboots, I publish() all messages with retained=true.
With this, I was hoping to receive the lastest stored values as soon as I subscribe() again to the variables.
Observation:
In a running program I my reply-message is something like: topic [length] - payload = /v1.6/devices/MQTT_Test/state [91] - {“timestamp”: 1467703753479, “context”: {}, “value”: 1.0, “id”: “577b61c97625427396688cf5”}
Thats’s perfect, however directly after subscribe() the reply message is shortened like e.g.:
/v1.6/devices/MQTT_Test/test [20] - {“State”: 137.00000}
It also seems to be static i.e. is not renewed by new publish() with retained=true;
value and topic do not match: May be this was currupted by my early trials, but in topic /v1.6/devices/MQTT_Test/test there is NOT supposed to be a “state”-variable like {“State”: 137.00000}
With PubSubClient-library under Arduino, this default-message shows signs of corruption in the payload:
/v1.6/devices/MQTT_Test/test [20] - {“State”: 137.00000}wyqsIpiXpC2ABO5gAEAnhT
Since I tested this with two libraries (Paho-MQTT and PubSubClient) on an Arduino MKR1000, I think it is related to the API.
What do you think?
Hi Jürgen we did some tests with the retain option for our broker but we found that, since the publish topics and payloads are slightly different than the subscribe topics and payloads, we won’t be supporting the retain option for now. In theory we could activate it -yes-, but it would be just an echo of the published values and not the actual stored values in Ubidots.
I understand, that a retained=true seems not to make too much sense for a (single) running system continously or very often publishing variables. Because if I had subscribed to a variable, I get updates often enough.So as a standard for most variables I do not use retained=true anyway.
However I think a retained=true makes sense for variables, which:
are posted NOT that often, like WLAN connect status or last GPS position or
when IoT-nodes are joining and leaving a cluster and what to know the status of the other devices. Without the others IoT-nodes having to continously having post/upadate all the time.
are used basically as “user preferences” on system startup or restart or reconnect. So I want to know the old value of a variable (being savely stored at Ubidots) on purpose.
I need Item #3 quite often for the following use case:
I use Ubidots control and button widgets to control my Arduino or to change limits e.g. T_min for heater to switch on or T_max to switch off. Using the Ubidot the use can easily change them.
However, when the Arduino restarts the user looses his changes to the hard coded settings, unless on the initial subscribe() the last stored value would be posted.
Unfortunatelly my Arduinos restart about every second day on average (mostly resetted by a watchdog), so it would be great if this wouldn’t be transparent to the user.
Thats why I think it would be a good idea to have retained working and could be nicely implemented by publish() with retained=true. Wouldn’t it?
Sorry, for being that stubborn. But I do not see a different solution using MQTT. Or is there?
All the best
Juergen
P.S.: I understand, that a publish() with retained=true is not easily available in some Client-Libraries, but I think it is worthwhile offering it from the API-side to the customers, who want/need to use it.
As for the payload of an retained message - as of the specificsation ofMQTT 3.1.1 - I do not see, why there needs to be a difference for the user.
Since you nicely include the timestamp anyway, everyone can decide on that, if he thinks that the value expired its shelf life.
P.P.S.: Same applies by the way for Will(), which is the next item I would like to test
I’m facing the exact same problem. I need to retrieve the last value sent through a description when a node comes up.
Is there a way to perform this with MQTT?
Alternatively, could a node publish a “helloworld” that triggers an subscription update from Ubidots?