Creating UDTs with MQTT Devices

Ignition
1

Can someone help me understand how UDTs are used when using the MQTT Modules?

I am looking to use the MQTT modules but I am concerned about how I will utilize UDTs with it. I’ve seen webinars where the tags are auto-created when using these modules and the data comes in using Sparkplug protocol.

I am looking to use a Red Lion HMI which can publish data to an MQTT broker using their Sparkplug MQTT connector. So then the tags should auto-populate under the MQTT Engine tag provider.

If for example, I have 100 pumps that all have the same set of data tags publishing to the MQTT broker using this same HMI, how can I create UDTs if the tags are auto-created with the MQTT Engine Module?
I want to be able to manage Ignition side alarms for those pumps from the Ignition server.

Any suggestions?

1 Like
2

Quick reply for now. Don’t mind the typos
We treat mqtt tag provider like any other (apart from ignition opc-ua} , as a source of data for igntion tags. We create udt definitions and tags in the igntiokn opc-ua that link to the mqtt tags usuijg Reference tags. This way we can manage all the config, alarms, properties, etc. From ignition. The only thing we use mqtt tags for is history for its backfill, by adding history into the mqtt tags.
Otherwise you’re unable to add any supporting tags for ignition not coming from mqtt

This is also how another IA employee would do it I was in touch with at the time

2 Likes
3

AWESOME. Thank you, I’ve been trying to figure that out all day. I was afraid I was going to have to manage them one by one or do some type of scripting or I don’t even know.

1 Like
4

No worries. If it helps, you can use system.tag.configure to configure the history config on the mqtt tags so you don’t have to do this manually

5

But why not do it on the reference tag in the UDT definition?

6

The you won't get backfill data if the comms fails :frowning:

If you care about backfill of course, otherwise just use history on ignition tags. I had no choice as we needed it

7

So your devices are using store and forward then?

8

Yep, I didn’t set up the mqtt side and don’t know the terminology, but store and forward sounds right

9

I don’t use the Red Lion, but instead I use Maple Systems.

The MQTT Protocol allows you to have several layers of tag grouping.

I have "Well Data, Vfd Data, Flowline Data, Tank Data, Etc…

Here’s some you may want to read.
MQTT Sparkplug B

10

Fwiw, we used folder structures in our mqtt tags that mimicked our folder and tag structure we used for our ignition tags. This made it easy to set the tag reference sources. However, I would still always use ignition tags from the OPC UA server as opposed to just looking at the mqtt provider tags, as it gives you flexibility to do whatever you want with them and to add supporting tags around them.

11

Been a while, but does this mean that instead of using MQTT Engine tags in projects, you are essentially creating a copy of the source tag provider that is publishing the Ignition tags over MQTT, changing all of the tags to reference tags, and pointing them at the MQTT engine tags?

i.e. Source provider -> MQTT Engine -> Copy of source provider as reference tags

1 Like
12

Pretty much. MQTT engine uses a managed tag provider, so you have very little control over them

13

Yup, so far that is the only practical way using MQTT tags imo.

14

If all of the nodes that are feeding MQTT data are other Ignition gateways, what's the difference between this approach and using remote tag providers?

15

Good question. It's definitely more 'hyped' to go the MQTT route because of UNS coming up so much.
Imo, if you're not using your MQTT data onsite for anything else and if you don't have any other topics coming in then Ignition data, it's way faster to develop using RTP's.

One claim made by Cirrus Link is that the MQTT approach will scale more. Your main gateway will be able to handle way more tags if they come in over MQTT, because the tags are more lightweight. I do wonder if it's still the case when you need to duplicate them all into reference tags. Amount of tags they spoke of when we last had a chat was 200k tags vs 1million tags.

16

Update: nevermind, backfill is possible with referencetags [FEATURE] Allow reference tags to receive backfill data from sources like MQTT tags - #16 by jhottell had my answer

If I have understood this response and thread correctly, you use reference tags for interacting with the MQTT data, but you set up history directly on the incoming MQTT tags to allow backfill? Isn't it now possible to allow back fill in the reference tags tag group if we choose to set up history with them? Or should we continue to keep history enabled directly on the incoming mqtt tags?

17

I used the same way , but i have a question here and asking for the best approach for that .
I received MqttTag decoded in special format which need to be encoded to be readable .i am able to encode this fromat using scripting in each mqttTag change script and write the value in as a new Tag .

What's the best way to do encode . Add Tag change script on mqtt Tag but this way more static if new tag received in Mqtt Tag Folder. i have to back tod designer and add tagChange script .

18

Consider using a derived tag. You can decode from the custom format to a document type, and in the reverse direction, construct from document to encoded format. (If users will write to individual members of the document, be sure to use "optimistic writes" in the tag group.

19

Does this apply for reading in structures as documents from Siemens opcua as well? Does this let you write values consecutively immediately?

20

Yes.

Within a single writeBlocking, yes. Not for multiple independent writes, IIRC.

1 Like