Retain option for published messages

[bruniii]

First of all, thank you for your collection of MQTT Packages.

I'm trying to understand if there is a way to set the "retain" option when the client publishes a message using Client.lvclass:Publish.vi; if I look to the block diagram of Client.lvclass:Publish (Raw Payload).vi (called by Publish.vi) I see the option RETAIN for the vi MQTT_Control_Packets.lvlib:PUBLISH.lvclass:Create PUBLISH Packet (Client).vi but I cannot change his value.

Is it possibile to add to Client.lvclass:Publish.vi a new input parameter RETAIN and than use the desired value for Create PUBLISH Packet (Client).vi?

Maybe the option is already available; if so I failed to find it, sorry.

Again, thank you for your work.
Marco.

[francois-normandin]

@bruniii thanks for that report.
This Retain functionality is not exposed indeed.
It has not yet been added as a supported feature on the server, so I didn't notice it should have been exposed for the client API to be used with other servers!

Now that I think a bit about the public API, it does not make sense to expose the duplicate flag (DUP) as this should be handled by the session engine... I think the DUP flag should never have been placed there, and the Retain flag should have been there all along.
Since it would be a change that potentially breaks the API for some folks out there (although the DUP flag is probably not something that would be used very much), I'll add it on the ConPane here:

And wire all the way to the base packet publish method:

If you would like to wire it in your own local instance until I publish this change, it should upgrade seamlessly later on.

Note that you can already set the retain flag by using the Publish Control Packet" and assembling the Publish packet yourself.

[bruniii]

Thank you, the proposed change would be perfect! In the mean time, I'll create a small wrapper VI with the VIs in the red box of the last figure.

Best,
Marco.

[francois-normandin]

Excellent. Be sure to use the same Serializer class as your server...

[francois-normandin]

This is fixed in 3.1.6 to be released soon on VIPM Community.
Thanks @bruniii