Jump to content
News about the LabVIEW Wiki! Read more... ×

Recommended Posts

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 by bsvingen

Share this post


Link to post
Share on other sites

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 by smithd

Share this post


Link to post
Share on other sites

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).

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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. 

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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 by smithd

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×

Important Information

By using this site, you agree to our Terms of Use.