News:
May, 2017:
Please check out Colin's implementation of a functional MQTT driver at https://forums.ni.com/t5/Community-Documents/MQTT-Driver-for-LabVIEW/ta-p/3561289. It exceeds the basic proof-of-concept stage of this client API and we recommend it if you would like to build applications using MQTT.
Aug 09, 2016:
After we got mentioned at NI Week (Thanks, Darren from DMC), I took some time to fix outstanding issues: Community member zazbot pointed out some bit parsing issues in "Sub_Read_Fixed_Header" and other VIs. See this helpful KB entry to explain some un-intuitive behavior. Also, I fixed "read published message" which was truncating strings twice.
As always, some bugs may remain. I have limited bandwith to perform more tests. So feedback is always welcome!
Overview
MQTT (Message Queue Telemetry Transport) is a lightweight TCP-based messaging protocol targeting M2M applications, monitoring and distributed IO applications. It allows high latency and/or constrained networks, typically found in such applications.
The goal is to target any embedded RIO device for such applications.
This set of VIs is functional for the MQTT protocol version 3.1.1. Its specification can be found here: http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/csprd01/mqtt-v3.1.1-csprd01.html
Description
The MQTT infrastructure uses a Broker (server) to host "topics". Topics are of a hierarchical nature and can be named in a "URI" fashion: e.g. "SolarPlant1/Sensors/IrradiationSensor1“ to identify a specific data source. Clients can subscribe to topics and will receive updates when topics are updated from other clients (or servers). If they want to publish new data to topics, they can do so. There are different "Quality of Service" levels, allowing lossless or lossy transport, respectively.
From the mqtt web site:
Steps to Implement or Execute Code
Requirements
Software
LabVIEW 2013
Hardware
Any platform you can program with LabVIEW that supports TCP/IP. If you encounter issues on Embedded platforms, please remove the Unicode conversion primitives in the "Build MQTT String" and "Read MQTT String" VIs, respectively.
Current status and what needs to be done
Currently, you should be able to get basic functionality for publishing and subscribing up and running quickly. I have not finished testing all QoS levels yet.
There is no active development for this API. Please refer to https://forums.ni.com/t5/Community-Documents/MQTT-Driver-for-LabVIEW/ta-p/3561289 for an enhanced MQTT driver.
Contribute
The code is back up on Github: https://github.com/DAQIO/LVMQTT - feel free to contribute!
License
The code is licensed under the MIT license. Feel free to include it in your projects.
For cool IIoT solutions, check out our web site at www.daq.io
Peter
Example code from the Example Code Exchange in the NI Community is licensed with the MIT license.
I haven't gotten a chance to actually use this yet, but I've taken a look and its clearly extremely impressive. I was expecting a set of dll-wrapped functions and instead I find that you've written the protocol in labview. Truly amazing. I definitely plan on investigating further. Thanks!
There are a few problems with connecting to the server.
This proclem occurs when I connect two times to the server.
The connection will be refused the second time.
Hi,
Good work with this API, thanks!
I'm using this API to publish data to the recently released IBM IoT Foundation service. While developing I have noticed couple of things in the API:
- MQTT_TCP_Open_Connection.vi needs a mechanism to initialize the connection ID on first call. Otherwise it will throw error on second time the TCP connection is opened as allardm has noticed in his message above.
- Also there is unwired connection ID in MQTT_PubRecRead.vi between Sub_Read_Fixed_Header.vi and MQTT_TCP_Read.vi
- There is also something wrong in the published message. I just haven't figured it out yet. The IBM IoT service doesn't recognize the sent message payload correctly. With Paho MQTT the IBM IoT receives the payload correctly.
Hey Matti,
we appreciate your feedback. We currently do not have any resources to actively drive the project.
That's why I would appreciate if you could contribute any changes or bug fixes to the github repository.
Thanks - and happy holidays!
Peter
I had to make a few changes in addition to the connection thing to get data into IoT Foundation.
1. In Sub_Build_Variable_Connect.vi I had to change the hardcoded "Protocol Name" to MQTT and the "Protocol Version" to 4.
2. In Sub_Build_Connect_Flags_Byte.vi I had to reverse the order of the connect Flags. username and password were bytes 0 and 1 and they needed to 7 and 8.
3. In MQTT_Publish.vi I had to remove the length information from the "message to be published".
I have not fully verified these changes against the spec but this is what I needed to do to connect to IoT and publish data to it.
Hi,
1. I haven't noticed problems with this. For me it works as it is at the moment.
2. I can confirm this, this is why I had to set clean session and reserved to TRUE. I've been wondering that, but didn't pay attention to it as everything seemed to work and I had more important concerns.
3. I can confirm this. I've created a new vi to create MQTT publish message payload using Sub_Build_MQTT_string.vi as template and removed the length bytes.
Thanks everyone for debugging and improving!
I hope to find some time early next year to consolidate the fixes.
Happy holidays to all!
Peter
Hey everyone,
I will be working on making this MQTT library compatible to the OASIS standard MQTT 3.1.1. We will release a free VI package hopefully before NI Week.
-Peter
What is the status of an MQTT 3.1.1 complient library?
It's ready and I will try and publish it soon. It will only support LV 2013, though
I played around a bit and get (sometimes) errors if I connect a second time to the broker. I debuged the code and found that the problem may be caused by the "MQTT TCP_Open_Connection.vi". If I remove the connection to the local port terminal everything works as expected.
I wonder why you have to set the local port for the TCP connection (normally you do not have to)? I looked through the spec and found nothing which indicates that you have to use a fix port instead of a dynamic one. By the way assign a local port number restricts to one connection per host.
thanks stgmbc, you are correct. That's simply a mistake I made. I am sorry I still have not gotten around to post an update. I'm happy to receive feedback for sure!
hi , i wanted to know if the latest version is available anywhere ?
working on it.... to be updated soon
Great job.Well done!
Awesome! Thank you Peter for your hard work on this. We have been extensively using this API and will continue doing so in the future.
Thank you Peter for the update, I am at present working with the Subscribe and publish example and the vi is working fine only every alternate time.e.g First time it stops automatically at a single run and then when i restart the code it works perfect. I believe this has something to do with the connection ID created at the MQTT TCP OPEN Connection vi.
Has anyone else experienced the same or any probable solutions.
Looking forward to hear from all the labview experts.
Ok so i was closing the vi directly from the abort execution button and not from the stop publishing button .So every second time Disconnect message was being passed.
All good now
That's the spirit! Nothing beats personal experience, debugging and fixing problems yourself. I am happy to receive bug reports, though.
Hi,
Just added new pull request to GitHub which should fix issue with the MQTT Publish function. Please, check when possible.
Hello
While working with connect and subscribe vi , I saw that the very first time when you press Run and connection with server is established the Vi stops automatically.the screen below shows the status after the first Run is pressed and after the vi stops.Then when i Re press Run and when connection with server is already present the vi runs properly.
Has anyone observed the same,how to debug this if at all?
thanks
Matti,
could you please store the files for LV 2013 to ensure version consistency? Thanks
Hello,
I found a problem in the "MQTT Connect" VI. The problem is caused by the case structure triggered by the "Sub Conn Status FGV" VI. Because of this case structure, the connection isn't always guaranteed. After removing the structure, you oblige the flow to go through acknowledgment.
After correcting this, i found that the "MQTT Read Published Message" returns "MQIsdp" for a while, and then starts working correctly.
Besides this little fix, the library runs great. Congratulations to the developers!
Arthur
Hi Arthur,
Thanks for the feedback and the suggestions. Are you suggesting to remove the status FGV? I will take a look at the code later.
Peter
Hello Peter,
I'm sending an attachment containing a picture of the VI's block diagram and the VI itself. Before I did those changes, I always got "Connection accepted", even if there was no communication between pairs.
Maybe I was simply using your library the wrong way, but now it works like a charm!
Att.,
Arthur Hauer
I'm seeing the same initial connection issue as described above. I am initializing the Conn Status FGV to 'Connection refused:server unavailable' to get things to work better at start.
Also, I'd suggest making the timeout for the TCP exposed at the top of the API so users can adjust it (especially for the Read Published Message VI). The 25 sec default is quite long.
-Jack
Hi Jack and Arthur,
Feel free to provide your modifications to the github project (LabVIEW 2013). You could also send those files to me, so I can try out the changes and merge with the project.
Thanks
Peter
Hello everyone!
I am facing a couple of problems with the MQTT Addon and I would require some assistance.
I downloaded it and installed the MQTT Addon on my LabVIEW 2013. I am trying to run 2 of the offered examples in the packadge at the same time.
I have set up an MQTT broker on a Raspberry Pi 2B and I am trying to connect to it using the following 2 examples, provided in the MQTT-Addon:
"Connect and Publish" and "Connect and Subscribe".
Unfortunately when I start first of the 2 examples from the packadge, firts it gives the following error:
"TCP Read in MQTT_Functions.lvlib:MQTT_TCP_Read.vi->MQTT_Functions.lvlib:MQTT_PubAck_Read.vi->MQTT_Functions.lvlib:MQTT_Simple_Connect_and_Publish.vi"
But after that it works fine.
Same thing happens when I start the second one.
Bedides this, when I get one of the 2 examples working and I want to start the second one, they both drop out of the MQTT connection and the broker getst the following message:
"1482184764: New connection from 192.168.0.101 on port 1883.
1482184764: New client connected from 192.168.0.101 as LabVIEW_MQTT_Client (c0, k15360).
1482184794: Socket error on client LabVIEW_MQTT_Client, disconnecting.
"
Could somen one give me an idea on what to do?
How to make them run togheter without exiting the MQTT connection?
Hi Peter,
Thanks for the awesome client!
I found a bug concerning QoS 2: The "Sub_Build_Fixed_Header" VI is missing a case for PUBREL and is using the default state instead. This leads to a wrong header (0x60 instead of 0x62) for a PUBREL packet, forcing the broker to close the network connection. Adding another case for PUBREL and building the header according to spec solves this problem.
Hi phil
Could you please send me the latest version of the MQTT_Labview_client?
My email is hong.zhang@agresearch.co.nz
Thanks
Hong
Hi Peter
I got the error66 at MQTT_TCP_Read.vi. How to fix it? Thanks
Hello everyone,
let me, please, ask the following question.
Is it possible to use this library for communication with Azure IoT platform by MQTT protocol? B/c I was trying to do it, but I couldn't connect or send any messages there...
Is there such LabVIEW toolkits what allow to do that, please?
Thanks a lot in advance!
Hi,
about https://github.com/DAQIO/LVMQTT/blob/master/Sub/Sub_Read_MQTT_String.vi
I don't understand what what use that VI is, in my cause it 'kills' only the two first byte (from the array) from a other publisher in python?
I may have given you a hint about this VI here: https://github.com/DAQIO/LVMQTT/issues/8
Hope it helps.
Hi everyone,
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
Hi everyone,
downloaded and evaluated latest github uploaded version (from 7 Jan 2018).
It works immediately exchanging messages between 2 clients, after entering broker IP/port and a unique client name for the connection.
While planning integration into my setup, I found two issues:
1) When using QoS-Level2 (Exactly once), MQTT definition says that "duplicate" flag has to be set for a message which is repeatedly sent. Setting this flag should be done automatically by client / broker. In the test.vi, it is settable individually for each Publish action. Does this mean that the "mqtt-LabVIEW-master" doesn´t support this QoS function natively but has to be parameterized by customer application if necessary?
b) There´s obviously a mistake in name for the controls "mqttUserInformation.ctl" and "mqttWillInformation.ctl", as content and name of both are contradictory. For further use of these controls in my application, it would be helpful if this could be fixed (not worked in in github till now and schedule doesn´t allow to do, to upload fixed version on my own). Is update planned so this could be fixed closely?
Regards,
André
hi all,
when i use this toolkit, i can't Call mqtt subscribe.vi for twice. One vi will stop, do you know what?
thanks
andy