MQTT brokers are becoming increasingly popular for various hardware suppliers and of course, the home automation market. In very simple terms, an MQTT broker is a message dispatcher. One or more Clients can Publish topics and values to the broker and additionally, One or more clients can Subscribe to be notified when someone writes values to these topics.
If you are searching for an MQTT driver, then I assume you know what this is. If not, mqtt.org can provide all of the additional information you could possibly need.
Additionally, the MQTT specification can be found here: MQTT-v3.1.1-os Specification
Firstly I have to give Kudos to Peter at daq.io. With constant reference to the MQTT specification, and referring to Peters implementation saved me a lot of time. Thus I had something working quite quickly.
MQTT-Client-API-in-native (Peter - daq.io)
So why did I (re)develop an MQTT Driver? Simply put, I had a few issues that I found easier to solve by reworking the implementation.
Implementation
Several API calls exist for the various MQTT functions. All can be tested using the aptly named 'test.vi'.
An MQTT comms server VI must run in parallel to the event loop. The comms server VI sends and receives data to the broker and dispatches data to the relevant callers.
Published data from the Broker are received by the comms server VI and then distributed within my application via a User Event. Thus it is possible for multiple VI's to register to the user event and thus, be updated when data is received from the broker.
Note:
The broker configuration is via clusters in the 'test.vi' block diagram.
The driver has been tested with mosquitto MQTT broker and also io.adafruit.
What is missing?
LabVIEW 2013+
Note that I also used an independent MQTT client to subscribe to the broker and verify my LabVIEW MQTT events were really working. In my case, I used mqttfx
Huge thanks to Peter at daq.io. Peters driver was referred to often during this implementation. Peter is aware of my development.
Source code is now available in GitHub: https://github.com/cowen71/mqtt-LabVIEW
Very nice API indeed.
There's an error in VI "\class\mqtt\mqttCmd\mqttCmdPublish\mqttCmdBuildPayload.vi": The payload for a publish command can be anything, so changing the data string to UTF-8 is incorrect. I noticed that when publishing a JSON-String (that already had been converted to UTF-8). That did not work to well.
Wishful improvements (IMHO):
Jens
Thanks a lot for your sharement,
However, in "INIT. VI", I couldn't configure my USERNAME and PASSWORD, so, the result is "Connection refused: bad username or password"
Could you please tell me how to configure username and password?
Thanks a lot
Hi,
The MQTT object includes the fields for the username and password and so the following actions are needed:
.Greetings.
OK, time seems to be my biggest problem currently.
I have uploaded a newer version of the driver but with only very minor modification unfortunately.
I really do welcome input from other developers to improve the driver further. There are several comments/requests above that make good sense to mebut I do not have the opportunity to implement them.
Thanks Cowen for a nice expansion of peter's work.
As I work a lot with MQTT-LV applications I'd love to share my findings and contribute to your project. Have you considered publishing it on github or similar platform to make collaboration easier and more efficient?
Hi,
My first experience of using GitHub to share my code - of course used it to access code previously.
It is here:
https://github.com/cowen71/mqtt-LabVIEW
If I have something incorrect, please shout.
Hello cowen71,
Thanks for your MQTT Driver implementation for LabVIEW. I was waiting for something like this for a long time.
I am getting error "OpenSSL Error: error:140760FC: SSL routines: SSL23_GET_CLIENT_HELLO:unknown protocol" when connecting to CloudMQTT Server.
The local instance when connecting to broker on my PC is working fine. Can we connect to MQTT Server without SSL Port, as error seems something related to SSL?
regards
Regarding my above Post the problem was solved after Selecting User Name and Password Flags in Connection Info.
I think, what i found error in your code.
For example, client recieved connection refused (error 66 from TCP write) from broker (i don`t know why):
TCP connection in this time remain open. Next subVI set connection ID in 0.
In next iteration, you run MQTT open again, but TCP connection from client is opened. In this case, connection ID use old (what was refused by server). Error loop.
I place connection ID away from case:
Then, subVI "MQTT close" get connection ID, clouse it. In next iteration connection is established.
Hello, good afternoon.
We are trying to connect a publisher and subscriber in a NI MyRIO, but the connection is not done correctly, how I could have several clients in the same computer?
Hi,
Very nice job!
I would like to test this library but unfortunately, I have Labview 2011. Is it possible to convert the code for Labview 2011 or older and share it on this page? thank you.
Cedric
Hello, i know this is too much to ask, but, can anybody can share this AWESOME Driver but for LabView 2011, will be vey nice if anybody can do,
thanks in advance!!!! and for what i can see, awesome job!
Hi
I am slightly new to MQTT protocol. I am using the code provided by Cowen71, thanks by the way for sharing the code, it really helpful. I can send the data to my local computer using local mosquito broker (MQTT.fx) as described in the overview of MQTT at the top of this page. The problem is that I cannot send data to the Azure Internet of Things (IoT) hub using this code as the data is not secured. I am using share access signature (SAS) to access the hub. I am not sure how to secure the data sent by the code provided by Cowen71 (e.g. to include CA cerfificate) in the code. Any help is greatly appreciated. Many thanks in advance.
Hi,
Thanks a ton for providing such a useful MQTT library. I want ot develop a MQTT subscriber with TLS ( a CA certificate enabled option). How could I do it? As I donot have have option of identifying the certificate files and key files which is what is needed for a typical subscriber application in Certificate mode.
Any pointers on how implement it also would be very helpful.
Looking forward to prompt responses.
Best regards
+1 to the post above. Any advise on using the mqtts/tls protocol? Thank you.
With TLS now natively supported in LabVIEW 2020 extending the MQTT client with TLS support might be relatively simple. I'll upgrade to 2020 soon and have a look...Perhaps someone is already working on it though?
Check out this thread for an MQTT client that works for secure connections:
https://lavag.org/topic/21615-azure-iot-mqtt/?tab=comments#comment-132669
Or download it directly here:
https://github.com/LabVIEW-Open-Source/LV-MQTT-Broker/releases/tag/1.0.2
@cowen71 wrote:
Note that I also used an independent MQTT client to subscribe to the broker and verify my LabVIEW MQTT events were really working. In my case, I used mqttfx
nice, I used the open-source http://mqtt-explorer.com/ to validate
@cowen71 wrote:
1. when i subscribe message, the time over 60 mins , the message will stop. i update the subTimeout, it sames no Response?
This API is well written and very useful. I have modified it slightly to work with my solution, but one feature I cannot figure out is how to unsubscribe to a broker. I don't want to disconnect and reconnect with a new subscription. I see support for "subscribe", but nothing for "unsubscribe". Does anyone have insight as how to accomplish that?
How does this model handle running multiple publisher/subscriber groups under the same implementation?
Can it be used to manage multiple instances of servers?
A bit of a rooke, but I am already connected and using the Mosquito MQTT? Sorry for the semi-newbie questions on this 🙂