Using The MQTT Transmission Module to Publish Data
Implementing MQTT in Ignition:Video 75 min video / 6 minute read
< Previous Video | Next Video >
Travis Cox takes a deeper dive into the MQTT Transmission Module, covering the different ways you can publish data to a single MQTT server or to multiple MQTT servers in parallel. Travis also goes into how to configure service sets and transmitters inside a transmission to accomplish different tasks.
Travis: In this session, we're going to talk about the different ways you can publish data to MQTT servers using the MQTT Transmission Module. The Transmission Module can publish data to a single MQTT server or multiple MQTT servers in parallel. It can work with the single set of tags or multiple sets of tags inside of Ignition. We can also send data to a set of MQTT servers that are set up for high availability, where we only send it to the first ones available. And of course, if that goes down, we could send to the next ones available.
There are a lot of different options here. So we're going to dive into detail how to configure server sets and transmitters inside of Transmission to accomplish these different tasks. First, we need to get Transmission communicating to one or more MQTT servers and we do that in the settings area under the Servers tab. As you can see here, I'm connected to three different MQTT servers, one on my local machine and two that happen to be in the cloud. In my particular case, I'd like to send tag data both to my local MQTT server and to the cloud. But in the case of the cloud, I have two servers and I only want to send to the first ones available. I have two of them for redundancy for high availability and so really, it becomes important to create a logical grouping or sets of MQTT servers that we want to send data to, and for that we go to the Sets tab. Here, I have two sets that I've defined, one that's called Default for my local one and then one that's called Cloud for my cloud servers.
If I go back to servers, you'll see that my local one is set to the default server set and my two cloud servers are set to the cloud server set. So basically, if I have more than one MQTT server within a set and I specify a transmitter to publish it to that set, it's going to publish it to the first ones available within that set. I can also set up multiple transmitters to publish data to multiple different server sets. And so if we go to the Transmitters tab, that's where we can set up all these different transmitters and specify which tags that we want to send and to where we want to send them. So in this case, I've got an example transmitter that is set up to send all the tags that are inside of an MQTT tags folder in my default provider to my default server set, which means it's going to send to my local MQTT server because that's the only one that's in that default set.
The next one is called Tags that is sending the entire tag provider called Tags to my local default MQTT server set as well. You see that I'm using the exact same one for the cloud, I'm using the same tag provider and the same configuration to the cloud server set. So in this particular case, these tags are actually being sent to both places at the exact same time with the exact same Sparkplug identifiers.
So the server sets allow us to really specify where we want them to go, and we can actually see back on our server's tab how things are working and where it's being sent right now. Because I have two different transmitters sending to my local one, you could see I've got two of two that are connected on my local MQTT server. Now, on my clouds, I've got two of them. The first one has one of one, so I've got one transmitter going to the cloud and currently is sending it to this particular server. Now, if that's supposed to go down, then it's going to send to the second set that's right here. To simulate that, we're going to actually disable the MQTT server, the primary one that's in the cloud. So I'm going to go ahead and do that, and you can see that went to 0, and then now this one here went to 1. So, that transmitter is now publishing to the second set. So, again, having the high availability, redundancy, gives us that real flexibility.
Now going back to our transmitters, there's a lot of options here with transmitters that we can work with. So if we were to create a new one, again, we can have as many of these as we like, we can specify for every transmitter, you can give it a unique name, we can specify what tag provider we want to get tags from and within that provider, we can specify what folder we like to start at. If I leave it empty, it's going to start at the root, which means every single tag in that provider is going to be sent up. We can then identify what servers that we want to send it to. So if you have the same set you want to send to multiple places, you gotta make sure you create multiple transmitters where we can use the same configuration up here, but different server sets that we're working with. We also have settings here for the UDTs as we talked about in the previous session. If you have UDTs and you want to publish those up versus having them be converted to normal tags, you gotta uncheck this particular box here.
And at the very bottom are the Sparkplug specification settings. This is where we identify for Sparkplug the three levels of hierarchy that uniquely identify one edge gateway from another. And so, we give it a group ID, we give it an edge node ID, and a device ID. Now, you'll notice that all of these are optional because I'm either specifying here on the transmitter or depending on the tag that I have set up here, I can have the folders actually identified in my tag provider for those top three that we will just use those. So it's typically recommended that you come down here and set them in the provider, so you're going to guarantee what those are going to be so that every single tag within that provider will be underneath that top level. We're going to see this in action when we look at the MQTT Engine Module where we're subscribing to those particular tags.