When you like to exhange data between Ignition servers (10k - 100k tags)…
Why should one choose ‘MQTT’ over ‘remote tags providers’?
Is this based on how many tags? Or how solid the network is? or???
Everyone that I speak to is really into this MQTT thing.
But since ‘remote tag providers’ are a basic Ignition thing one should think that this should be best.
All input welcome.
If your only requirement is sharing tags between two servers, I would use remote tag providers.
MQTT is fantastic for ingesting data from many different sources, but, because it’s not an Ignition specific technology, doesn’t have all the “bells and whistles” of an Ignition <-> Ignition connection - such as remote tags being seamlessly edited from the local designer.
1 Like
I think this is part of the equation too. MQTT is great for bringing in data from the "Edge", when bandwidth is a concern.
2 Likes
Guess Ignition Edge doesn't support EAM module and cannot serve as a remote tag provider!
Neither of those things are true.
There are Edge licenses that can have the EAM module, and the EAM module in general is not required for GAN connections.
Thanks for the clarification.
Thanks for the info. It is clear now that we should use remote tag providers.
1 Like
Hi,
I know this topic is 2 years old, but we are also evaluating the communication concepts between Edge and Gateway with GAN (Remote Tag?) and MQTT)
The pro for MQTT between Edge and a central gateway is for me the unlimited store&foreward capabilities of MQTT Transmission, while the integration between Edge and a central gateway with GAN is limitied (35 days or 10 Mio rows - for us 10 Mio rows can mean 2 days or less then 2h)
I can't see and cons for MQTT, also I heard that there are some limitations with alarms when using MQTT Transmission.
Are there any pros to use GAN (Remote Tags) instead of MQTT between Edge and a Gateway?
Thank you!
André
I personally don't do alarming using MQTT, but in the latest version, alarms are supposed to synchronize between the server and edge. MQTT may even struggle with that many records. The key with MQTT is there's an extra point of failure, being the MQTT broker/server. Typically, this is a separate server (unless you're using the Distributor module). I like to use EMQx, and you can set up a cluster of MQTT servers or use a cloud service for extra redundancy there. If you're dealing with a lot of tags and have an unmetered network connection you may be better off going with a remote tag provider. If you're on a metered/cellular connection, MQTT will save you some bandwidth over remote tags.
1 Like