MQTT Transmission provides a configuration section to the Ignition Gateway and this can be seen in the left side menu bar of the Ignition Gateway web UI.

There are two configuration pages "History" and "Settings".                                   

Settings

The configuration options for each of the six tabs - General, Servers, Sets, Transmitters, UNS Transmitters, Records and Files - are detailed below. 

General

The General Settings tab contains a single Main section.

General - Main

Servers

The Servers tab has two parts - Settings and Certificates

Servers - Settings

This tab provides a list of the MQTT Servers that MQTT Transmission should connect to. By default, MQTT Transmission is configured to connect to the local MQTT Distributor based MQTT Server and is set up to connect to localhost, port 1883, using the default username/password.

Additional or alternative MQTT Servers can be configured in MQTT Transmission - often times more than one will be configured to handle fail-over in redundant or geographically distributed systems. Clicking on the 'Create new MQTT Server' link will bring up a form for adding a new MQTT Server setting. 

The 'Connected' column will show either:

The configuration sections available are Main, TLS, Advanced and RPC Client Connection

Server Settings - Main

Server Settings - TLS

See this document for TLS configuration: Configuring Secure MQTT Communication

Server Settings - Advanced


If both the Random Startup Delay and the Reconnect Delay are configured, the startup delay for any one client will be the aggregate of the two configured values. For example, with the Random Startup Delay = 10-1000ms and the Reconnect Delay = 1000ms, the startup delay for any one client will be between 1010 and 2000ms


Server Settings - RPC Client Connection

This section was added in release 4.0.18 - previously configuration for the Auto-reconnect RPC Client property was under the Advanced section 

This section was updated in 4.0.23 to move the Enable/disable RPC Client and Auto-reconnect RPC Client to the Sets RPC Client configuration

Servers - Certificates

This tab provides a list of the certificate or private key files if loaded and available for TLS configuration.

All certificate or private keys must be in PEM format. If using modules pre 4.0.9, any private key must also be in RSA PKCS1 format. If using modules 4.0.9 or greater, any private key must also be in either RSA PKCS1 or PKCS8 format. 

The Certificates tab contains a single Main section.

Server Certificates - Main

Sets

The Sets tab contains a list of server sets.  Each set represents a logical grouping of MQTT servers.  When a set is referenced by a Transmitter configuration, a single connection to one of the servers in the set will be maintained. The other servers will act as failover in the case that a connection with the first is lost.  Server sets cannot have common elements meaning that a single MQTT server cannot be in more than one set.

The Sets tab contains Main and RPC Client sections.

Sets - Main

Sets - RPC Client

Transmitters

Transmitters are the agents within MQTT Transmission that monitor tags, convert them to Sparkplug Messages, and publish them to an MQTT Server. Each transmitter is configured with a server Set and will attempt to maintain an MQTT client connection with one server in that Set at all times.

Transmitters will monitor tags from a specific Tag Provider and, optionally, a specific Tag Path. If the tag folder hierarchy has been constructed as Group ID, Edge Node ID, and Device ID, then these will automatically be used when building up the MQTT message payload that will represent the Tags as follows:

[TagProvider]<TagPath>/<GroupID>/<EdgeNodeID>/<DeviceID>

Review the MQTT Transmitters and Tag Trees describing how Transmitter configurations interact with Ignition tag trees 

If your tag folder hierarchy does not conform to this structure, you can explicitly define these required elements under the SparkPlug Settings section and the elements will be prepended to your tag string.

The configuration sections available are Tag Settings, Command Settings, History Settings, Alarm Settings, Sparkplug Settings and Advanced Settings.

Transmitters - Tag Settings

Transmitters - Command Settings

Transmitters - History Settings

Note: Store and Forward does not guarantee all data is stored and forwarded. There are some edge cases that are not currently handled with regard to data loss in the event of connection failures related to MQTT keep alive timeouts. This window of potential missed data can be reduced by decreasing MQTT Transmission and MQTT Engine configurable keep alive timeouts.

Transmitters - Alarm Settings

MQTT Transmission 4.0.16 through 4.0.22 support the propagation of alarm events from the Edge to MQTT Engine on the Central Gateway to be inserted in the Ignition Alarm Journal but do not support the remote acknowledgment of those alarms

MQTT Transmission 4.0.23 and newer support the propagation of alarm events from the Edge to MQTT Engine on the Central Gateway to be inserted in the Ignition Alarm Journal along with acknowledgements from the Central Gateway back to the Edge

Review the Alarm Event Propagation document for system configuration details including the changes needed to the data/ignition.conf file and MQTT Engine

Transmitters - Sparkplug Settings

Note that if a 'Device ID' is not specified, any folder within the folder specified by the Tag Path will be considered a device folder and any Tags within it will be published as device Tags. 

Transmitters - Advanced Settings

UNS Transmitters

The UNS Transmitter is an agent the monitors tags and publishes them as MQTT Messages with a JSON payload to an MQTT Server.

The UNS Transmitter can be configured to read tags from the UNS structure created by MQTT Engine and publish tag changes over MQTT to any Enterprise consuming clients.

Review our Using MQTT Modules in a UNS Architecture document for more details on using the UNS Transmitter.

Each transmitter is configured with a server Set and will attempt to maintain an MQTT client connection with one server in that Set at all times.

The UNS Transmitter will use the namespace unsAv1.0 and will prefix this to all publishes from MQTT Transmission

The UNS namespace may be disabled via script using the "UseTopicPrefixToken" parameter 


The UNS Transmitter MQTT Client has no subscriptions and so will not receive commands from Enterprise consuming clients



The configuration sections available are Tag Settings, Publish Settings, History Settings and Advanced Settings.

UNS Transmitters - Tag Settings

UNS Transmitters - Publish Settings


UNS Transmitters - History Settings

UNS Transmitters - Advanced Settings

Records

Within MQTT Transmission, a record is a collection of tags under an Ignition folder which are treated as a single entity and published on demand. They are usually used for, but not restricted to, sending flow computer records such as events, alarms and history data.

Each record will have an associated boolean tag that will trigger the record publish. The location of this boolean tag is defined in the Record - Advanced Settings section.

Records are published via an MQTT client using a Sparkplug-like format such as spBv1.0/Group/NRECORD/Edge or spBv1.0/Group/DRECORD/Edge/Device  

The configuration sections available are Tag Settings, Sparkplug Settings, Records Signature and Advanced Settings.

Records - Tag Settings

Records - Sparkplug Settings

To publish records, MQTT Transmission uses a configured Transmitter. The properties entered into the Sparkplug settings for Group ID, Edge ID and Device ID (optional) must match an existing Sparkplug Edge Node based on a Transmitter and tag tree configuration.

.

Records - Records Signature

From version 4.0.19 added support for digital signatures/hashing of Records that are generated by MQTT Transmission so that they can be verified in the MQTT Recorder database.

Records - Advanced Settings

Each record will have an associated boolean tag that is used to trigger the on demand publish of the record. The Advanced settings manage the location and naming of this boolean tag.

Files

The 'Files' tab allows for the configuration to publish files which are transferred using Sparkplug over MQTT.

The configuration for file record creates a set of control tags (which specify where to locate the file to publish and a manual trigger option) along with information tags publish status and history. 

The configuration sections available are Tag Settings, File Settings, Sparkplug Settings and Advanced Settings.

Files - Tag Settings

Files - Control and Information Tags

The control and information tags created in the tag folder are:

NameTypeDescription
Last Published FileStringName of last published file
Last Published Sequence NumberIntegerSequence number of last published file since last reset of metrics
Percent CompletedBytePublish completion percent for file being published
Publish FileBooleanManual trigger to publish file
Publish File CountLongNumber of files published since last reset of metrics
Publish File in TransitStringName of current file being published
Publish File PathStringFull path to the target file to publish over MQTT. Created if 'Enabled Auto-Publish' is disabled 
Publish Files FolderStringFull path to the target file folder to publish over MQTT. Created if 'Enabled Auto-Publish' is enabled
Publish Operation StatusStringStatus description of current publish operation
Publish Operation Status CodeIntegerStatus code for current publish operation
Remaining RetriesIntegerNumber of remaining retries for current publish operation
ResetBooleanTrigger to reset publish metrics


Files - File Settings

Files - Sparkplug Settings

To publish files, MQTT Transmission uses a configured Transmitter. The properties entered into the Sparkplug settings for Group ID, Edge ID and Device ID (optional) must match an existing Sparkplug Edge Node based on a Transmitter and tag tree configuration.

Files - Advanced Settings



History

The "History" page allows for the configuration of MQTT Transmission History Stores.

When a Transmitter is configured to use an MQTT Transmission History Store, data is written to the History Store once MQTT Transmission has determined that there is a connection failure. Once a connection with an MQTT server is re-established the History Store will publish the stored messages with a flag set to indicate that the messages are "historical" to prevent confusion with live data values. Determination of a connection failure can be up to 1.5 times the configured keep alive. and, as such, any data published during this time can be lost.

From release 4.0.17, in order to cover data loss during a keep alive timeout scenario, the MQTT Transmission History Store includes a Rolling History Buffer that can be configured in the Advanced Properties configuration section. When the Rolling History Buffer is enabled, all tag changes will be written to the History Store regardless of connection status.


From release 4.0.19, major improvements have been made to the disk-backed History Store. Details on configuring pre 4.0.19 modules can be found here


Prior to release 4.0.22, Disk-Backed History stores are located here ~yourIgnitionInstance\user-lib\cls\data\h2

From release 4.0.22, Disk-Backed History store are located here ~yourIgnitionInstance\data\modules\com.cirrus-link\com.cirruslink.mqtt.transmission.gateway\h2

From release 4.0.25, the base path for the database location of the Disk-Backed History store is configurable.

  • The default base path for Linux is ~yourIgnitionInstance\data\modules and the database will be included in the Ignition GWBK
  • The default location for Windows Linux is ~yourIgnitionInstance\user-lib\modules and the database will not be included in the Ignition GWBK
  • The database file will be created in this directory under the base path com.cirrus-link\com.cirruslink.mqtt.transmission.gateway\h2

The History tab contains a Main section and an Advanced section.

History - Main

History - Advanced

Rolling History Settings

Advanced Settings

If using multiple Disk-Back History Stores, the TCP Database Port must be unique for each one.

This requirement applies to all Disk-Backed History Stores (MQTT Transmission and all Injectors), MQTT Engine Alarm Stores and Chariot MQTT Server (uses TCP Port 9092) if co-located on the same platform