Just trying to understand the architecture.
My plan is to test with a maple cMT-G01
So that needs to connect to a broker.
Lets say I use a cloud based broker like CloudMQTT or HiveMQ. A that point the data from the maple should be at the broker.
From this point I would use the Cirruslink Engine Module to get the data into Ignition?
Does this seem right?
The Distributor Module is Cirrus-Link’s broker
The Engine Module subscribes to a broker and exposes the topics as tags in Ignition
The Transmission Module allows Ignition tag changes to be written to the broker
EDIT
Not sure if you need a cloud-based broker, but I wrote a little tutorial on connecting mqtt based sensors to Ignition with Cirrus-Link’s broker. It might be helpful to some degree.
https://community.ncd.io/t/wireless-mqtt-sensors-from-ncd-for-ignition-scada-tutorial/4250
If you are going to use the Cirrus Link MQTT modules you will NOT need to have a separate broker.
Make sure you set your cMT-G01 gateway up with the “Sparkplug B 3.1.1” protocol, this way everything will be a breeze making it work with Ignition.
I’m in the Oil & Gas Industry and I use the Maple Syatem cMT-G01 gateway for all of our remote locations to get data back to our Ignition server.
P.S. If your going to have more then 50 Gayeways you will need to purchase the Pro version of the Cirrus Link Modules(the Pro Version will handle 250 gateways) if you need more then 250 they do have a cloud bases version.
Yeah I dont want to have a limit on gateways so I was looking at different brokers. That is why I was looking at maybe using a cloud based broker or perhaps at some point launching my own broker. I figured for testing it would make sense to use a cloud broker since it would maybe be easier.
so this seems ok maple>cloudbroker>engine module>ignition?
I just checked, and the Engine Module config settings, and it does have a 3rd party option for connecting. This should work as you described.
Cirrus Link does have its own “Chariot” stand-alone broker, suitable for cloud deployment.
Yes I may go that route.
That brings up my next question. Does the broker have to support sparkplug? or does tag creation work as long as the edge gateway supports sparkplug?
You are not required to use sparkplug. You can create a custom namespace, for example I set up one that used a basic JSON string and it will still auto create the Ignition tags.
ok, so as long as you can figure out how the data is cast, you can lay out how you would have the tags broken out?
I don’t know about how Maple is structuring the data, but for a raw JSON, it would be one tag per key I think. You can change the folder structure/hierarchy to a degree with you subscription settings. You will just have to try it and see. The MQTT modules work on the two hour trial.
So I didnt feel like waiting for a maple unit and just setup an ignition gateway with the transmitter module, attached it to cloudmqtt. I then setup another gateway with the engine module. I was able to get tags from the transmitter gateway to carry across cloudmqtt and show up in the engine module gateway. I tried writing to a memory tag but nothing happens. what am I missing?
another thing I have noticed is that if I add a tag on the transmitter gateway, it doesnt show up on the engine gateway unless I do an edit/save in the transmitters tab of the mqtt transmission settings section of the transmitter gateway.
Sorry, I not much understand why you try communicate with this module via MQTT.
look like this device have OPC UA built-in server. all what you need just hook up ignition to this server as client.
yes I am very much aware that I could have used opc-ua, but I wanted to test out mqtt.
Ok, then you need understand how MQTT work.
It will not show any tags (topics) while you not setup(post) some a value on it. tag/topic can’t be empty.
Ignition Cirrus Link can give you option to use ignition MQTT as server and then your device connect and post topics(tags) and you will see it under “All Providers”,
or Ignition can be like a client to any MQTT server and subscribe to all or just a some topics. and you will see this messages under “All Providers”
But my personal opinion, if choice between MQTT and OPC-UA, i will use OPC-UA. on this way you don’t need buy Cirrus Link. and you will have option to work with tag more like “ignition way”.
For a simplistic understanding, think of OPC UA as a point to point communication between a client and server and MQTT as a chat application between multiple clients connected to each other thru a chat (MQTT) server. The chat takes places on different topics that clients want to publish and subscribe to. Chat is initiated by MQTT clients when a tag change is detected in its database. The client initiates a chat on a specific topis when a change is detected and it is received by all clients that subscribe to that topic. OPC UA is based on industry standard API’s and its purpose is to allow interoperability between diverse SCADA systems and third party applications who understand this specification.
So OPC UA and MQTT are complimentary technologies to each other not competing technologies. The first defines address space of a controlled plant with its up-to-date real time status data and the second one allows you to synchronize the address spaces of distributed servers (OPC or non-OPC) on LAN/WAN. MQTT compatible hardware with I/O can as well be an MQTT client which will directly communicate with other MQTT clients to read/write data in their address spaces.
Of course this is too simplistic understanding and there are advanced concepts such as tag change subscription and async method calls, data modelling techniques etc in OPC UA and store and forward and cloud injectors and spark-plug specifications etc in MQTT etc, but I guess the simplistic model is important to have first.
Bad example.
OPC-UA you can use like chat server too. it no limit to clients numbers. Only one option what you will missing if we compare with MQTT, your clients can’t start his own “chats”. And another thing what probably not much to industrial applications, MQTT can be scale on both ways if amount of clients is grow . But it hard to imagine in industrial applications.
Of course you can have many clients connected to an opc ua server but communication is always between a client and the server , never between two clients directly in opc . Whereas in MQTT communication is between client to rest of the clients , thru the server . The purposes of the two are different
Sorry, but probably you miss something. If someday you will find “direct communication between 2 clients” in MQTT, with the out post to server. Let me know, please. 
Of course communication is always routed thru the MQTT server when a client posts a message on a topic , like a chat server , but the server basically keeps track of clients connected dynamically and which client is subscribing to which topic etc . Of course all messages first go to the server and It’s ultimately the server which which routes these messages to appropriate clients but messages ultimately reach to subscribing clients .
No, messages not ultimately reach subscribers. It happen only you send messages with this flag.
