Closed jkoplo closed 3 years ago
@jkoplo Yes, this is definitely a simple addition. I have to admit that I didn't add this node because I thought that developers would use the Control Packets directly if they didn't wish to use a Serializer. This was short-sighted of me.
I'll wrap this section into a "Publish (Raw)" method and expose it on its own as a "Publish (Raw)" public method.
Next release will feature two new methods in the Client palette:
Publish (Control Packet)
Publish (Raw Payload)
Haha - no worries. No API survives contact with the end-user for long!
I'm more than willing to help with some of this and do some PRs, but LabVIEW isn't exactly ideal for merges and it seems like you're in heavy active development.
Open source is a relief valve for me... and I'm at a point where there is some pressure to vent ;-)
Implemented in release 3.1.4
@francois-normandin - would you consider extending your API to have a "Publish Raw Payload" on the MQTT Client class?
For my use case, I'm actually using two values - a header and a data payload to make my packet payload. I then merge them together into a single JSON object and send it. On the other side, they get separated and the header is turned back into a LV dataype, but the data payload is kept as a JSON string until later. In other words the payload datatype isn't known when I receive the MQTT packet on the other end.
I've managed to implement this in your existing library by creating a new Serializer that basically does nothing but check that it's passed a string (as a variant) and then stores/returns this string. This allows me to build my payload outside of the MQTT library and then pass it as a string to the variant input of the MQTT Publish. It's a pretty ugly hack.