MQTT for labview

[bsvingen]

Hello

I am looking for a functional MQTT server client implementation for Labview. I have been doing some search, and found something, but they all seem to be unsupported. Does anyone have any pointers to a fully functional one? Is NI developing any stuff on this?

Thanks

Edited for correct content

Edited September 15, 2018 by bsvingen

[smithd]

You would not build a broker/server implementation in labview, you would use an off the shelf solution like mosquitto. I'm assuming you mean a client implementation.

For clients, the protocol is deliberately pretty simple, for low power devices, so I wouldn't feel uncomfortable using one of the labview implementations out there after testing it a little. If you don't feel comfortable, the real answer is to use one of mature C libraries. The ones I'm aware of are Paho and Mosqitto.

I believe both have synchronous APIs (eg call connect + block, call send + block, etc) which is usually OK for a simple application. For example, Paho's header (https://github.com/nivertech/paho.mqtt.c/blob/master/src/MQTTClient.h) has "MQTTClient_receive", a synchronous receive function, and "MQTTClient_messageArrived", a callback. 4 years ago I made a labview wrapper for the then-current async version of paho, but its obviously so out of date now I'm not even going to post it. The api is relatively easy to wrap -- for example, here is publish:

DLLExport int MQTTClient_publish(MQTTClient[void*] handle, char* topicName, int payloadlen, void* payload, int qos, int retained, MQTTClient_deliveryToken* dt);

Everything is either an opaque pointer or an int, making it easy to consume in any language you like. From the client header above, there is a full example and it looks like the hardest part would be constructing some of the options structures (eg replicating "MQTTClient_connectOptions_initializer", a macro, in labview).

Edited September 14, 2018 by smithd

[bsvingen]

Thanks. Yes, client implementation only is what I'm looking for (post edited). We are using RabbitMQ broker/server in a dedicated embedded PC. A pure Labview implementation is highly preferred (although not completely necessary in the long run). Got a pointer elsewhere for LVMQTT on github. Will look into that first. If that doesn't do the trick, then a wrapper is probably needed (if something else doesn't pop up).

[Sylphe]

This API turned out to work for most basic features, tried with RabbitMQ and Mosquito in previous projects. However it really has to be reworked to be fully reusable and to address multiple topics or servers in one application instance.

[_Mike_]

I have worked extensively with LabVIEW and MQTT.  Indeed LabVIEW does not have any really good libratry for that. I have worked a bit with @cowen71 to put together some good functionality.  We wanted to make it more "reusable" and release it to broader public, but when it reached the amount of features that served our private purposes - the momentum stopped. 

Here is a library https://github.com/mradziwo/mqtt-LabVIEW/ which is not perfect as I say, but allows for asynchronous calls to MQTT, and some event-based callbacks. 

If you would be willing to join the team to bring it to "publication" state, we would be more than happy to collaborate on that. 

 

[viSci]

Just curious, what is the advantage of the MQTT implementation over off the shelf RTI-DDS now built into LabVIEW for windows and RT Linux

[_Mike_]

The sole advantage in my opinion is ability to connect LabVIEW application with systems that use MQTT. I see no point in using MQTT for connecting between two LV applications.

[smithd]

9 hours ago, viSci said:

Just curious, what is the advantage of the MQTT implementation over off the shelf RTI-DDS now built into LabVIEW for windows and RT Linux

You could ask that about MQTT in general. It seems to be a protocol that just sort of slid into its current position as 'the iot protocol' almost by accident.

Specifically vs DDS, MQTT is a lot simpler and easier for a normal person to understand ("ok now send a structure with a command name and a payload string" should sound familiar to everyone, I think), and it works over TCP, making it potentially more network-friendly than the UDP-based DDS.

For me personally, I feel like some of the marketing is hard to believe -- when people start making claims about 'deterministic' performance networking in a magical software package with a bunch of features, without laying out any numbers or proof or anything it makes me concerned, as one example. It seems highly geared towards marketing towards executives vs marketing towards engineers, to put it another way. I'm also not the biggest fan of how it was pushed by NI

Edited October 1, 2018 by smithd