Question about MQTT (partner) module(s)

Ignition
1

As far as I understand it, MQTT isn't natively part of the Ignition system. Optional modules are required to make it work.

Last week I tested extensively with Cirrus Solutions' MQTT Distributor module. Today I noticed this module comes with a pricetag, not even including the MQTT Engine module I'll also need.

I've read a lot of articles and instructions describing what the module does and why it's a great addition. Frequently mentioned as "Strategic Partner" and even having a dedicated tab for these type of modules on the resources page. Yet I only found out I needed to purchase well over $5k worth of licensing when I installed the module and Ignition notified me I now have an unlicensed trial version on my system.

I guess I was a little thrown off by "strategic partner", thinking it wasn't a commercially licensed module. That line of thinking had not been contradicted by any of the extensive instructional material I consumed - but now we're here. Am I correct in my assesment there are practically no MQTT alternatives and my only other option to not pay for additional licenses is to change communication protocol?

2

FWIW, the Distributor module is the only one you may not actually need - there’s plenty of free MQTT brokers out there and you can run your own depending on your system architecture.

Yes, that’s correct, I’m not aware of any other MQTT modules.

This reads like you have already purchased a license? Did someone buy it and drop it in your lap? It seems inconceivable that somebody could make it through the pricing page without realizing the MQTT modules (and any other module) have some cost. It’s very clear and up front.

1 Like
3

Kevin, thanks for the quick response!

FWIW, the Distributor module is the only one you may not actually need - there’s plenty of free MQTT brokers out there and you can run your own depending on your system architecture.

I've entertained that possibility for a very brief moment - sadly the customer we're working with has a very strict IT service and not tying the MQTT broker to the gateway is not just a headache, it'd be a chronic migraine..

This reads like you have already purchased a license? Did someone buy it and drop it in your lap? It seems inconceivable that somebody could make it through the pricing page without realizing the MQTT modules (and any other module) have some cost. It’s very clear and up front.

I (eventually) landed on that page when I was deliberately seeking out pricing. The gateway has been live for well over a year by now, adding in functionality sprint by sprint. Development happens in reverse - we build first and document later. The original license was purchased even further back in time, by a different department.

My search for the MQTT module went in through the backdoor I suppose - I'm the engineer that needs to make this work so I'm looking for modules and instructions. Just wanted to make really, really sure I needed to go have a chat about additional costs.

The only other module I've made use of so far was recommended via the forum, with clear disclaimer it'd be a paid license. I'd discussed this beforehand with the customer (we can spend n hours building this feature, or x amount of dollars to buy a license). This time I'll have to inform them the decision to go with MQTT 3 months ago based on the fact I found some neat plug-and-play modules comes with a steep pricetag we weren't aware of.

I didn't mean to come across as deflecting blame, it just came out of left field for me. I understood modules can come with an additional license, but something about the "Strategic Partner" made me assume these modules were similar to SQL-bridge or Symbol-factory type modules. Ass, u & me or something.

Again, thanks for the quick and definitive response and apologies if my initial post rubbed off wrong.

4

Hmm, yeah, it's tough if you're approaching in "reverse" like this.

Usually a conversation with sales engineering about what you're trying to build can help you figure out what modules you'll need (now, and eventually), but if you don't know what you're building until you build it I guess that can be tricky :slight_smile:

5

If you look close at the pricing pages, you will see that this module also has a price tag, and can be left out to save money. The platform license includes a bunch of drivers, and substantial functionality, but all the rest is customizable for price/features.

6

I don't know what alternative you'd use here besides OPC-UA or gateway network connections, but in order to know what your requirements are so we can make suggestions, we'll need to know what you're trying to do. MQTT is great for low bandwidth communication from hubs to spokes. It provides not only live data, but store and forward capabilities when using Sparkplug B and using an edge device that supports S&F. OPC-UA can also be used for live data, but won't support S&F. Gateway network connections can do both live data and S&F, but require you to use Ignition for the edge nodes.

Personally, I like keeping the MQTT broker independent of the Ignition server. This allows for future expansion of redundant/clustered brokers if needed. I also prefer EMQx as my broker due to both price (free) and extensive capabilities and diagnostics. It's lightweight and runs in Linux.

1 Like
7

OPC UA kind of supports store and forward. On the client side you can configure the Queue Size that Monitored Items get created with via the corresponding Tag Group setting.

When the connection is lost, the server will continue sampling the underlying data sources until the Session times out or Subscription lifetime expires. You'll capture these changes if you have large enough queues, and if the client reconnects before the Session times out then it will transfer the Subscriptions to the new Session and receive all the queued changes.

I think the main issues are:

  1. Subscription lifetimes are relatively short and not configurable
  2. Queues are not persisted to disk, this is really just for short network interruptions
1 Like
8

I didn't realize this, but it sounds like this wouldn't ride through a minute or 2 outage? I'm thinking more like 15 minute+ outages that can lead into hours depending on the cellular connection I'm dealing with.

9

It's probably only ~1 minute right now. I'm looking at making the target Subscription lifetime configurable in 8.3. The Session lifetime is already configurable (on the OPC UA connection settings).

In theory 15 minute or multiple hour outages shouldn't be an issue, it really just depends how often the underlying data is changing and how large the Queue is configured to be.

1 Like
10

but in order to know what your requirements are so we can make suggestions, we'll need to know what you're trying to do.

We have a separate LoRaWAN gateway that received data from mobile equipment in the field. This gateway then needs to present the data to Ignition. We're probably going to move ahead with the MQTT solution because the Engine module dynamically builds the tag-hierarchy based on the MQTT topic-hierarchy, allowing me to script a solution that responds to those dynamically generated tags. Essentially - if a new device is created in the LoRa gateway, everything on the Ignitionside can be automated to update. OPC UA, BACnet, even Modbus are all viable alternatives to get the data across as it's not time critical - but they all require manual configuration on the Ignition-side that's not required using the MQTT module.

Considering we're starting with 100+ devices it's a huge timesaver.

11

Make sure you understand the MQTT modules are heavily biased towards using Sparkplug and that there are some downsides to using generic MQTT, such as only being able to publish to a topic in a custom namespace via scripting.

12

Good thing I only need to listen on the Ignition-side of things :slight_smile:

My setup allows me to disable all namespaces and add a custom "#" subscription - I'm in full control of what gets published and the system is fully dedicated to move only relevant data.

It's quite a .. simple setup really, hence my initial apprehension at the license costs. I realize the modules (and MQTT in general) allow for much more complicated and extensive possibilities, but all it needs to do for us is take data from (a third party, LoRaWAN) gateway A, to gateway B (Ignition).

Thanks for all the input, I'm pretty sure I know what I need to know to make an informed decision.

1 Like
13

You might check out HydraMQTT which looks to still be in development, but depending on your timeline may work for you.

1 Like