...

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

Anchor
Settings Settings

Settings

...

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

Anchor
ServerSettingsMain ServerSettingsMain

Server Settings - Main

...

• CA Certification Certificate File
  • CA Certification Certificate file currently in use.
• Client Certification Certificate File
  • Client Certification Certificate file currently in use.
• Client Private Key File
  • Client Private Key file currently in use
• Change Password?
  • Check box to enable changing of the optional password.
• Password
  • Optional password associated with the certificate's private key.
• Hostname Verification
  • Enable TLS Hostname Verification. This is true by default.
• TLS ALPN Extensions
  
  • Optional TLS ALPN Extensions to use with this connection

Anchor
ServerSettingsAdvanced ServerSettingsAdvanced

Server Settings - Advanced

Image RemovedImage Added

• Client ID

  • Optional MQTT client ID to use.  If specified this will be used in the MQTT Transmission connect packet when connecting to the server.  If left blank, a random client ID will be create of the form 'IgnitionTargetMT-xxxxxxxx-xxxx-xxxx'.

    Warning
    Caution: MQTT Clients IDs must be unique and if two clients attempt to connect with the same client ID, one will be forcefully disconnected from the server to allow the other client to connect.

    
    

• Anchor
  Keep Alive Keep Alive

  Keep Alive
  • The maximum interval in seconds (5-65,535) between any two MQTT protocol control packets sent by the client to the server.
  • The minimum Keep Alive for MQTT Transmission is 5.
  • If the client is idle and has no control packets to send, it will send PINGREQ protocol packet and the server is required to respond with a PINGRESP packet. If no response is received from the server within 1.5 times the Keep Alive, the client will close the connection.

  • If the server does not receive, at minimum, a PINGREQ message from a client within 1.5 times the Keep Alive, it will terminate the connection and send the client's LWT if it has been defined.

  • For MQTT Transmission, this is an DEATH message.

• Random Startup Delay
  • The Random Startup Delay in milliseconds of the form 'min-max' where min is the low end and max is the high end of the random range. e.g. '10-1000'. 
• Reconnect Delay
  • The clients reconnect delay in millisecond.
• Auto-reconnect RPC Client
  • Allow the RPC Client to auto connect and reconnect when publishing from Ignition Python scripts.
• Subscribe to Legacy STATE Topic
  
  • Allow the Transmission Client to subscribe to a legacy state topic (eg. STATE/IamHost) for primary host ID notifications (available from release 4.0.16)
  • Review Changes to the STATE messages in the Sparkplug v3.0.0 Specification
• Data Format Type
  • The format of the data to send. Default is Sparkplug_B_v1_0_Protobuf with JSON as an option.

Anchor

...

ServerSettingsRPCClient

...

ServerSettingsRPCClient

...

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

The Certificates tab contains a single Main section.

Image Removed

...

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  

Image Added

• Enable/disable RPC Client
  • Enable or disable the RPC MQTT Client 

  • The RPC MQTT Client is used for MQTT publishing from Transmission using Ignition Python scripts

• Auto-reconnect RPC Client
  • If checked, the RPC client will automatically reconnect to the server.
  • If unchecked, the RPC client will try to connect at publish time
• RPC Client ID
  • A manually configured MQTT Client ID for this RPC connection
  • Do not use this setting unless it is an absolute requirement that a specific Client ID be used for the connection to the MQTT Server. If left blank, one will be auto-generated. 
• Username
  • Optional username for this RPC connection if required by the MQTT Server
• Password
  • Optional password for this RPC connection if required by the MQTT Server
• CA Certification File
  • CA Certificate file currently in use
• Client Certificate File
  • Client certificate file currently in use
• Client Private Key File
  • Client private key file currently in use
• Password
  • Optional password associated with the certificates private key
• Hostname Verification
  • Enable hostname verification. Enabled by default
• TLS ALPN Extensions
  • Optional TLS ALPN Extensions to use with this connection

Anchor
ServerCertificates ServerCertificates

Servers - Certificates

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

The Certificates

Image Removed

• Certificate File Upload
  • Browse to the certificate file or private key to upload.
• Friendly Name
  • The friendly name of the certificate file or private key.
• File Description
  • The description of the certificate file or private key.

...

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.Image Removed

The Sets tab contains a single Main section.

Image Added

Anchor

...

ServerCertificatesMain

...

ServerCertificatesMain

...

Server Certificates - Main

...

• This is the friendly name of the set used to easily identify it.

...

• This is a friendly description of the set.
  

...

• The primary host ID to use for 'state' notifications.
• If configured, MQTT Transmission will subscribe on 'state' notification topics. If MQTT Transmission is notified that the primary backend application has gone 'offline', it will close it's client connection with the MQTT server and walk to the next MQTT server defined in the set.  If the primary host ID is not set, MQTT Transmission will not subscribe on the notification topics and not receive any 'state' notifications.
• This must contain only letters, numbers, or any of the following special characters: . $ % @ ! - _ ^ *

Image Added

• Certificate File Upload
  • Browse to the certificate file or private key to upload.
• Friendly Name
  • The friendly name of the certificate file or private key.
• File Description
  • The description of the certificate file or private key.

Anchor
Sets Sets

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.Image Added

The Sets tab contains a single Main section.

Anchor
SetsMain SetsMain

Sets - MainImage Added

• Name
  • This is the friendly name of the set used to easily identify it.
• Description
  • This is a friendly description of the set.
    

• Anchor
  PrimaryHost PrimaryHost

  Primary Host ID
  
  • The primary host ID to use for 'state' notifications.
  • If configured, MQTT Transmission will subscribe on 'state' notification topics. If MQTT Transmission is notified that the primary backend application has gone 'offline', it will close it's client connection with the MQTT server and walk to the next MQTT server defined in the set.  If the primary host ID is not set, MQTT Transmission will not subscribe on the notification topics and not receive any 'state' notifications.
  • This must contain only letters, numbers, or any of the following special characters: . $ % @ ! - _ ^ *

Anchor
Transmitters Transmitters

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>

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

The configuration sections available are Tag Settings, Command Settings, History Settings, Alarm

...

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>

If your tag folder hierarchy does not conform to this structure, you can explicitly define these required elements under theSparkPlug Settings section and the elements will be prepended to your tag string.Image RemovedThe configuration sections available are Tag Settings, Command Settings, History Settings, Sparkplug Settings and Advanced Settings.

...

• History Store
  • The MQTT Transmission History Store to use with the Default Transmitter.
• Enable History Storage by Default
  • Checkbox to enable/disable store and forward for all tags. Selected by default. 
  • Store and forward controls whether or not a tag is stored in the configured History Store when Transmission is offline. To override the global setting,individual tags will require a custom tag property 'StoreAndForward' (type: boolean) to be created and set to the reverse state of the global setting.
• In-Order History
  • Checkbox to enable/disable the flush history in-order (synchronously) before live data resumes. Not selected by default.

Anchor

...

TransmittersAlarmSettings

...

TransmittersAlarmSettings

Transmitters -

...

Alarm Settings

Image Added

• Alarm Event Enable

  • When enabled and alarms are enabled on tags, the contents of the triggered alarms will be transmitted via Sparkplug to MQTT Engine and will be inserted into the Ignition Alarm Journal on the server where MQTT Engine is installed.

    Note
    This is not full alarm support as the ability to clear or ack an alarm from MQTT Engine is not currently supported

    
    

Anchor
TransmittersSparkplugSettings TransmittersSparkplugSettings

Transmitters - Sparkplug Settings

Image Added

• Group ID
  • An ID representing a logical grouping of

Image Removed

• Group ID
  • An ID representing a logical grouping of MQTT Edge Of Network (EoN) Nodes and Devices into the infrastructure.
• Edge Node ID
  • An ID that uniquely identifies the MQTT Edge Of Network (EoN) Node within  Nodes and Devices into the infrastructure.
• Device Edge Node ID
  • An optional ID that uniquely identifies the MQTT Edge Of Network (EoN) Node within the infrastructure.
• Device ID
  • An optional ID that uniquely identifies a Device within the infrastructure.

...

Anchor
TransmittersAdvancedSettings TransmittersAdvancedSettings

Transmitters - Advanced SettingsImage RemovedImage Added

• Filtered Properties
  • A semicolon delimited list of Tag properties to filter/block from being published

  • By default the filtered properties list contains: 

    Code Block

    accessRights;clampMode;deadband;deadbandMode;formatString;historicalDeadband;historicalDeadbandMode;historicalDeadbandStyle;historyEnabled;historyMaxAge;historyMaxAgeUnits;historyProvider;historySampleRate;historySampleRateUnits;historyTagGroup;historyTimeDeadband;historyTimeDeadbandUnits;opcItemPath;opcServer;permissionModel;rawHigh;rawLow;sampleMode;scaleFactor;scaleMode;scaledHigh;scaledLow;tagGroup;valueSource;expression;expressionType;ConfiguredTagPath;eventScripts;readPermissions;writePermissions;eventScripts;parentEnabled;sourceTagPath

    
    

  • Tag properties are only published if different from the default Ignition tag property settings and are only published in BIRTH messages.
• Rebirth Debounce Delay
  • The amount of time, in milliseconds, to delay before processing Rebirth NCMD requests after one has been processed. Default of 5000 milliseconds.
• Include Sparkplug DataTypes
  • Whether or not to include Sparkplug DataTypes for Metrics in Sparkplug DATA payloads
  • Enabled by default

Anchor
Records Records

Records

...

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

Anchor
RecordsTagSettings RecordsTagSettings

Records - Tag Settings

...

• Group ID
  • The Group ID that matches an existing Sparkplug Edge Node.
• Edge Node ID
  • The Edge Node ID that matches an existing Sparkplug Edge Node.
• Device ID
  • The Device ID that matches an existing Sparkplug Edge Node. (Optional)

Anchor

...

RecordsRecordsSignature

...

RecordsRecordsSignature

Records -

...

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.Image Removed

• Override Publish Tag
  • When unchecked, the tag used to control the record publish will be created within the record defined folder path and named "Publish"
  • When checked, the tag used to control the record publish will be created using the Publish Tag Path property
• Publish Tag Path
  • Defines the tag path for the boolean tag used to control the record publish
  • This can be used to create a tag in the record defined file folder with an alternate name to "Publish" or to have the tag located in a separate folder
  • The full tag path, including the tag provider, needs to be used for example: [default]Edge Nodes/G1/E1/RecordControl/PublishEvents or [default]Edge Nodes/G1/E1/D1/Alarm/PublishAlarms

...

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. 

Image Removed

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

...

Records Signature

Image Added

• Enable Signature
  • Checkbox to enable a digital signature field on all Records. Default is de-selected
• Algorithm
  • The hashing algorithm to use when generating the digital signature
  • Options are SHA_1,SHA_224,SHA_256,SHA_384 and SHA_512
• Password
  
  • The password used to generate the PBE secret key for encrypting the digital signature 

Anchor
RecordsAdvancedSettings RecordsAdvancedSettings

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.Image Added

• Override Publish Tag
  • When unchecked, the tag used to control the record publish will be created within the record defined folder path and named "Publish"
  • When checked, the tag used to control the record publish will be created using the Publish Tag Path property
• Publish Tag Path
  • Defines the tag path for the boolean tag used to control the record publish
  • This can be used to create a tag in the record defined file folder with an alternate name to "Publish" or to have the tag located in a separate folder
  • The full tag path, including the tag provider, needs to be used for example: [default]Edge Nodes/G1/E1/RecordControl/PublishEvents or [default]Edge Nodes/G1/E1/D1/Alarm/PublishAlarms

Anchor
Files Files

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. 

Image Added

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

Anchor
FilesTagSettings FilesTagSettings

Files - Tag Settings

Image Added

• Tag Name
  • A friendly name for File Records which must be unique. Name is prepopulated 
• Tag Provider

...

Image Removed

• Tag Name
  • A friendly name for File Records which must be unique. Name is prepopulated 
• Tag Provider
  • Free form field for the path to the name of the tag provider where the file control and information tags will be created
• Tag Folder Path
  • Free form field for the path to the tag folder under name of the specified tag provider where the file control and information tags will be created
• Tag Folder Path
  • Free form field for the path to the tag folder under the specified tag provider where the file control and information tags will be created
  • Do not include the Do not include the provider name. For a tag path of [default]MyFiles, enter MyFiles

...

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

When a Transmitter loses its connection with the MQTT Server and is unable to reconnect, a History Store (if enabled) will store all messages corresponding to change events on the monitored tags.  Once 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 reestablished 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. Image Removed

The History tab contains a single Main section.

...

Image Removed

...

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.

Image Added

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

Anchor
HistoryMain HistoryMain

History - Main

Image Added

If using a large tag capacity it is highly recommended to test the system under load in a non-production environment on similar hardware and software that will be used in production. During testing is also important to get the system into a state where the store and forward cache becomes full before beginning to flush. This will ensure that the system is sized appropriately when deployed into a production environment. There are a number of factors involved in determining how large the tag capacity can be including but not limited to system resources such as CPU, RAM (especially when using 'In-Memory'), Disk IOPS (if using 'Disk-Backed'), the nominal tag change rate (e.g. number of tags changing per second in the system), the flush rate, bandwidth availability, whether flushing in order vs asynchronously, etc. Because of the complex interactions of these variables it is highly recommended to test in a controlled environment. Generally any capacity over 2,000,000 is considered large and should be tested before deploying to production.

...

• Name
  • The name of the History Store.
• Enabled
  
  • Checkbox to enable/disable the History Store. Not selected by default.
• Type
  • The type of History Store.
  • Data stored in an In-Memory History Store will not be persisted across a module configuration change, module disable/enable, module restart or power loss. 
  • Data stored in a Disk-Backed History Store will persist across a module configuration change, module disable/enable, module restart or power loss.
• Edge Node Tag CapacityHistory Max Age
  
  • Maximum number of Edge Node level tag change events minutes to store per Edge Nodehistory before dropping oldest historical Edge Node tag change events. This value is independent of the 'Device Tag Capacity' and only applies to how many 'Edge Node level' tag change events are stored per Edge Node.
  • A tag change event is triggered by either a change in value or quality and results in the tag's Qualified Value (which has three attributes of value, quality and timestamp) being stored. 
• Device Tag Capacity
  
  • Maximum number of Device tag change events to store per Device before dropping oldest historical Device tag change events. This value is independent of the 'Edge Node Tag Capacity' and only applies to how many 'Device level' tag change events are stored per Device.
  • A tag change event is triggered by either a change in value or quality and results in the tag's Qualified Value (which has three attributes of value, quality and timestamp) being stored.
• Flush Quantity
  • The maximum number of tags to publish in a single message upon reestablishing communication.
• • the data.
• Flush Quantity
  • The maximum number of tags to publish in a single message upon reestablishing communication.
• Flush Period
  • The period to wait in milliseconds between publishes when flushing messages upon reestablishing communication

Anchor
HistoryAdvanced HistoryAdvanced

History - Advanced

Image Added

• Enable Rolling History Buffer
  • Enable/disable storing data in a rolling buffer to cover data loss in Keep Alive timeout scenario
• Rolling History Prune Interval
  • The interval, in seconds at which to attempt to prune the rolling history buffer
• Rolling History Max Age
  • The maximum age allowed of data, in seconds, in the rolling history buffer
  • This should be at least 2 x the Keep Alive timeout
  Flush Period
  • The period to wait in milliseconds between publishes when flushing messages upon reestablishing communication