In case it is helpful to anyone, I have been developing a free MQTT client module based on the HiveMQ client libraries. It is relatively early development, but already it is able to connect to a TLS secured username/password authenticated MQTT broker and reproduce the namespace as packets arrive. I intend to keep working on this, add more features/authentication options in order to extend the free options for edge driven datasources.
5 Likes
So, question about adding some features to this:
Currently the module does Subscribe only to a topic. Based on the fact that MQTT is designed as a report by exception system and really only reports changes to specific topics, I am inclined to implement the Publish function as a scripting function only.
My thoughts on this are based on the way that modules are set up to do tag writes: Get a notification that some tags in the provider have changed, then scan through all the tags to find out what has changed, then send that over the chosen driver/protocol.
Given that tag writes are normally triggered by an Ignition event, and you call system.tag.writeBlocking() to change the tag, why not just call something like mqqtClient.publish(), as there may not even be an existing tag where you publish the data?
Does this make sense?
I have now made a version of this for 8.3, with a functional gateway webpage to set the settings for the client. This builds fully on Maven, so it is also a demo of the full React webpack experience running on Maven, not Gradle which is the option on the sdk examples.
1 Like
Yes. A publish() function allows the most flexibility for generic payload implementation, in my opinion.
I admit that I was very interested in this when you first posted but decided I needed some time to ponder.
Some time ago, I received a request to publish a generic MQTT payload from Ignition. My first attempt at solving the problem was to implement Node-RED & set-up a dynamic tag listener to receive & queue live values of an entire folder in Node-RED, then format & publish the generic MQTT payload from there.
Fast forward, the requirement was added to more gateways, including some Edge gateways...with intermittent connectivity...new solution required.
I spent time pursuing the MQTT transmission module (included in Edge license) & its built-in RPC client. With that, I was able to use their system.cirruslink.transmission.publish function to publish a generic MQTT payload, which I do through a tag change script calling a custom myScript.buildAndPublish() function (which calls the transmission.publish() function) asynchronously.
In both options, having ability to dynamically format the payload & customize qos, topic, etc. at time-of-publish has proven very useful.
I would consider your module as a replacement for full gateway installations after upgrade to 8.3 (sometime this year 
).
So I had some time today and I have neatened a bunch of things up, still a few to go, but progress.
There is now a system.mqtt.publish(topic,payload,qos) scripting function available.
This does need two strings and an int, so no sneaky binary payloads right now....
This is kinda the reason I made the Event Streams MQTT module, it streamlines the workflow for either consuming or generating scalable amounts of data with MQTT.
Tag Event 
Encoder (String) No Filter No Transform Buffer MQTT Handler (Publish)
Using this you can then easily add monitoring, parallel event actions, and its all queue based with an error handler you can configure. Live data rates inside Designer also doesn't hurt.
1 Like
@David_Stone, would this also work for EMQX instead of HiveMQ? Or is there something in particular that makes it dedicated to one Broker?
The reference to HiveMQ is not the broker it supports, it is a reference to the module using the HiveMQ Java Library for the MQTT framewark instead of the Cirrus Link designed Library.
All my testing has been with the HiveMQ public broker and also a local version of Mosquitto running on a local server.
You should have no issues connecting to any normal broker.