I have what I assume is a fairly typical deployment - a bunch of edge nodes using MQTT Engine and Transmission modules to feed data up to a central Ignition gateway. Each edge node is publishing a bunch of UDT instances (although I am not propagating the UDTs themselves). Ideally, I would define the alarms in the edge node UDTs and respond to them on the Central gateway. This feels harder than it should be, so my hope is I'm missing something simple. I've found through this Chariot document that it appears this used to be supported but is no longer, and now there are 3 possible approaches to handling alarms depending on scenario. MQTT Alarms - MQTT Modules for Ignition 8.x - Confluence
Apply alarm configuration directly to the MQTT Engine tags. This appears to be a naive approach for a number of reasons.
Use reference tags (and presumably a second set of UDTs matching the structure defined at the edge). This feels like the most robust approach, although inefficient and with extra administration effort.
Use Ignition Gateway Network to propagate the alarms between gateways. My understanding from the wording in the article I linked above is the alarm will only be present at the Central gateway but must be managed at the edge. This is not applicable to my use case.
Unless I'm missing something, is option #2 the way to go here?
Yes - Option 2 is the way to go. Though keep in mind that your edge alarm timestamp and the central gateway alarm timestamp won't be identical.
Option 3 is the best case if your edge to central gateway can handle the extra bandwidth of the GAN.
I have setup this exact scenario with duplicated "MQTT" UDTs - created Gateway script to browse the MQTT Engine and build the Tag Database in the default provider. This way management is much easier then creating every datatype instance manually.
Thanks for the response, it's appreciated. On your comment regarding Option 3, is this achieved through adding remote tag providers from each edge node?
Yes - We have another client where we use the gateway network from the edge with remote tag providers, remote alarms and remote history (Query Only). Though the 'edge' was full gateways. I like this option the best - even though the tags will show up in different tag providers at the enterprise level, instead of in one in the MQTT Engine for all your data.
Though with your comment on #3 - If you setup the service security to be to Read,Write,Edit - You can edit and modify the alarms from the central gateway.
One additional consideration is if you want alarm acknowledging to be synced between the edge and central ignitions. In other words, if someone acks an alarm on the edge panel should it also ack the alarm on central ignition? And vice versa, someone acks alarm on central ignition, should the edge panel alarm also receive the ack.
If you want the alarm statuses synced, #3 might be the best option, as the other options would require additional scripting to achieve that functionality.