Must be between 0 for MQClient, between 0 and 1 for MQ_Extra_Clients.  

MQTT Client address list

SSL/TLS 'stunnel' Parameters

(Connect Port=1883)

Accept Connect

Connect To

127.0.0.1

127.0.0.1:1883

address1.mybroker.com:8883

127.0.0.2

127.0.0.2:1883

address2.mybroker.com:8883

127.0.0.3

127.0.0.3:1883

address3.mybroker.com:8883

Must be 0.   

Milliseconds to wait between sending each RBE packet. T

he RBE task periodically checks the RBE flags set for each point in the RTDB to see if data has changed. If so, all changed points are sent to the broker. This parameter defines how often to perform this check. 

Text string which may be inserted into topic strings for RBE messages, to identify the destination MQ-HCP when using multiple HCP's.

The Console_ID text, if configured, is substituted into the 'sys', 'cmd', and 'file' Control Topics in place of the "Console_ID" (see Subscriptions object). If the Console_ID field is left empty, the field is omitted from the subscribe topic string. 

Select the topic publish rule for MQ RBE messages, which are also the rules that will be used by other clients who subscribe to the broker for the RBE data (such as the MQ_HCP).

When publishing RBE messages, the topic always begins with the topic string "RBE", and the Console_ID field configured in this MQ_RBE object. The Console_ID can be used to differentiate different sets of RediGate data into groups within the host/broker topic space.

The topic string can also include the following data specific to this unit configuration (note, each RediGate should be configured with a unique UnitName or UnitAddress to distinguish the topic message space of each gateway):

• "UnitName" or "UnitAddress" (taken from the top level System object in ACE)
• "RTUName" or "RTUAddress" (taken from the Field Unit object)
• and optionally the "ChannelName" or "ChannelNumber" (taken from the Master Channel object). The Channel information can be excluded if all RTUs in this unit have unique names or addresses. 

Select the RBE publish Subscribe Topic Rule from the following options, where HcpId, UnitName, UnitAddress, ChannelName, ChannelNumber, RtuName, and/or RtuAddress in the topic would contain the actual property data in the configuration:

• RBE/HcpId/UnitName/ChannelName/RtuName
• RBE/HcpId/UnitName/RtuName
• RBE/HcpId/UnitAddress/ChannelNumber/RtuAddress
• RBE/HcpId/UnitAddress/RtuAddress

This option is used in systems using redundant MQTT servers. In this case, the MQTT RBE/PR objects in the ACE configuration will use an instance number (0=primary, 1=secondary). 

If only one MQTT connection is used, the MQ_Client/MQ_Rbe_Pr_Handler process may be configured to use the other RBE instance:

Select 'RBE 0 DBM Flag' to use the primary (RBE0) process for MQ_RBE.

Select 'RBE 1 DBM Flag' to use the secondary (RBE1) process for MQ_RBE. In this case, standard HCP RBE/PR connections would be configured to use instance 0. 

If both primary and secondary HCP connections are used in a configuration, the MQ_Extra_Clients/MQ_Extra_Rbe_Pr_Handler process may be configured to use the alternate RBE instances:

Select 'TERTIARY RBE process for DBM' for the third (RBE2) process for MQ_RBE.

Select 'QUATERNARY RBE process for DBM' for 4th (RBE3) process for MQ_RBE. 

This list allows the MQ_RBE process to filter which Channel/Field Unit configurations will report their data using the automatic RBE process. If this table is left blank (or is omitted in older versions of the configuration), then all configured RTDB database fields will report data on all MQTT clients. If one or more rows are entered in the table, then only the configured FieldUnits will be reported through this MQTT Client.

Click the Edit Table button to edit the list of Field Units.

Channel – Enter the channel number (0-16) of the Field Unit to include in RBE reporting.

RTU to Enable – Enter the Field Unit address of the device to include in RBE reporting.

Must be 0.   

Select whether to subscribe to the MQTT 'sys' topic. The 'sys' topic subscription is used to allow a remote host to send system level commands (see MQ_RBE_PR_Handler).

• sys/Gateway/# – issue subscription where "Gateway" is replaced by the Unit Name in the top-level System object (default, if Subscriptions object is omitted)
• sys/HCP_ID/Gateway/# – issue subscription where "Gateway" is replaced by the Unit Name, and HCP_ID is taken from the parent MQ_RBE object.
• Disable subscription to 'sys' topic – this option prevents 'sys' topics from being received on this device from a host. Note that this setting also prevents Health Echo commands, so an appropriate (non-Health Echo) option must be chosen for Host Synchronization. 

Select whether to subscribe to the MQTT 'cmd' topic. The 'cmd' topic subscription is used to allow a remote host to set or control data values in the FieldUnits on this device. This could be used in a situation requiring a field device to be monitored but commands must be explicitly prevented.

cmd/Gateway/# – issue subscription where "Gateway" is replaced by the Unit Name in the top-level System object (default, if Subscriptions object is omitted)

cmd/HCP_ID/Gateway/# – issue subscription where "Gateway is replaced by the Unit Name, and HCP_ID is taken from the parent MQ_RBE object.

Disable subscription to 'cmd' topic – this option prevents 'cmd' topics from being received on this device from a host. 

Select whether to subscribe to the MQTT 'file' topic. The 'file' topic subscription is used to allow a remote host to publish a file to this device via MQTT. This could be used with some additional logic to process configurations or other files.

file/Gateway/# – issue subscription where "Gateway" is replaced by the Unit Name in the top-level System object (default, if Subscriptions object is omitted)

file/HCP_ID/Gateway/# – issue subscription where "Gateway is replaced by the Unit Name, and HCP_ID is taken from the parent MQ_RBE object.

Disable subscription to 'file' topic – this option prevents 'file' topics from being received on this device from a host. 

Select how (or whether) to synchronize MQTT communication with a host system. Synchronization is typically used when this device is publishing through multiple MQTT servers, and one or more hosts is also connected to the MQTT servers. This ensures that the device and the host system are communicating with each other through the same MQTT server, so that commands and data are sent and received directly.

Require Health Echo from host – Host must periodically send out a 'sys' command with Health Echo and this device will respond with an echo, ensuring synchronized communication (default, if Subscriptions object is omitted). If the Health Echo is not received within two times the Keep Alive period configured in MQClient, the MQClient will disconnect from the current MQTT server and try the next address.

Subscribe to 'STATE/HostName' – (see Host Name option below) This synchronization method reduces network traffic by not requiring constant application-level Health Echo messages. 

In this case, the host should publish a message (with Retain flag set) with topic of "STATE/HostName" (where "HostName" is configured to identify the host). The payload of the message should be "CONNECTED" (all caps). It should also lodge a Last Will and Testament with the server using the same topic and a payload of "DISCONNECTED."

When a RediGate device connects to the server and subscribes to 'STATE/HostName', the server will deliver the retained message immediately with the payload "CONNECTED", thus informing the device that the host application is currently connect on the same server.

If this STATE message is not received within two times the Keep Alive period, the MQ Client will move to the next server. If the server disconnects from the server, the RediGate will receive the "DISCONNECTED" message and will immediately move on to the next server, attempting to locate a server to which the host is simultaneously connected.

No Host Synchronization – If only a single MQTT server is used, this option can be used. The MQ Client will not look for a Health Echo or STATE message but will remain connected to the server. Synchronization with a host is ensured as long as the host is also connected to the server. 

Select how to publish data on startup or upon reconnection to an MQTT server.

Send Only Non-Zero data registers – Upon connection, publish only non-zero values in RTDB registers (default, if Subscriptions object is omitted). Upon receiving the Birth Certificate from this device, the host must zero its entire database of values, so that non-zero data received from the device will ensure host and device have identical data. This option reduces the amount of published traffic upon connection.

Send All data including Zero/Null registers – Upon connection, all RTDB registers (except those configured as "Non-RBE") will be published even if they contain zeroes. This causes more data traffic on reconnection, but it ensures the host is informed of all available points, values, and identifications (tags or register numbers) at the time of connection. 

Select whether to publish tag names associated with RTDB register locations. Publishing registers with tag names requires the configuration of the optional Tag Names object under each RTDB (see 4-Other Client Services#Tag Names).

Don't Publish Tag Names – Upon connection, publish only RTDB registers by number (default, if Subscriptions object is omitted). Upon receiving the Birth Certificate from this device, the host must zero its entire database of values, so that non-zero data received from the device will ensure host and device are in synch.

Publish Tag Names on MQTT Connect – Upon connection, publish a list of the configured Tag Names associated with RTDB register addresses for the Field Unit. Subsequently, all data will be published using the RTDB register addresses, but the host system can use the initial list to correlate addresses with names for display purposes.

Publish GZIP'd Tag Names on MQTT Connect – Same option as previous, but the initial publication of Tag Names and register addresses is sent in the MQTT payload in zipped format using 'gzip' compression. This reduces the bandwidth and packet size when publishing a large database of tag names. 

NOTE: If any RTDB is configured to report by exception using Sparkplug-B but has no tag names configured, then all data for all RTDBs will be published, using their tag name (if available) or RTDB address. To prevent non-tagged registers from being published, make sure that all RBE RTDBs have at least one tag name configured.

Enter the Host Name to use in the 'STATE/HostName' subscription, if using that option for Host Synchronization

Host Name must be a maximum of 80 characters. If using the State/HostName option and this field is left blank, the Host Name in the subscription will default to the HCP_ID in the MQ_RBE object.

Must be 0.

Select which of four RBE flags to use for checking changed data (make sure not to use the same as any other process that might use the same RBE flag, such as MQTT, HCP, DNP).

The STATE topic is used to ensure an active end-to-end connection to Host, or switch to next MQTT server. In applications where the SCADA server and RediGate connect sequentially to more than one redundant MQTT broker, the SCADA server should publish the STATE topic to ensure the RediGate is in active communication using the same broker at the same time, to ensure RBE messages are received end to end. The RediGate will subscribe to the STATE topic, and if it doesn't receive 

To disable the use of the STATE topic, enter a string between 1 and 5 characters in length. Regardless of configuration, the STATE topic is ignored if the RediGate is only configured for a single MQTT server in the URL_List table.

The STATE topic is presently supported on the RediGate using the "legacy" format prior to the Sparkplug-B protocol version 3.0.0, where the payload is expected to be simple text as "ONLINE" or "OFFLINE". The STATE topic should be in the form "STATE/Host1", where "Host1" is the Primary Host ID in the Ignition MQTT Engine or equivalent in a different SCADA system (in MQTT Engine release 4.0.14 or later, also configure the Legacy Host ID - see STATE message in Sparkplug v3.0.0).

Must be 0.

Enter one or more IP address of the NTP servers to which to connect.

NTP uses algorithms to average the errors between different time servers, and to detect servers which are not reliable. If any server address is set to 0.0.0.0, all subsequent addresses in the list are ignored.

A couple of publically available NTP servers you can try are 129.6.15.28 and 129.6.15.29

Use a unique Instance number for each Terminal Client object. 
The Terminal Client object must have at least one child Host Connection object defined. 

From the dropdown list, select the serial port which should be used for connection to this Terminal Client TCP network port. Select the Serial Port from among standard serial ports (COMx) or one instance of a pair of Virtual Port pair (VirCOM xxa or xxb) if connecting this Terminal Client port to another process using Virtual Serial Ports. Make sure the Async port is defined under Networks. 

Select the connection mode of the Terminal Server.

Always – Select this option to connect automatically upon system restart or upon the IP socket connection being terminated.  If using the "Always" mode of connection, there must be only one child Host Connection object with its Dial String set to an empty field. The Terminal Client will use the IP address of that Host Connection object to automatically connect to the end device. 

Any Data – Select this option to connect the Terminal Client to the remote server only when data is received on the serial port. If using the "Any Data" mode of connection, there must be only one child Host Connection object with its Dial String set to an empty field. The Terminal Client will use the IP address of that Host Connection object to connect when data is received on the serial port.

ATDT – Select this option to connect the Terminal Client only if an "ATDT###" message is received on the serial port, where ### is some alphanumeric string. When using the “ATDT” option, there may be many child Host Connection objects defined under this Terminal Client object.  The Host Connection entries should have their Dial String configurations set to unique ATDT### values. The “ATDT” option causes the Terminal Client to act as a modem emulator.  The connected serial device acts as if it were connecting using a dial-up modem, where each ATDT dial sequence tells the Terminal Client to connect to a destination IP server, rather than dialing over a PSTN telephone network.

DCD – Select this option to connect the Terminal Client only when the DCD signal on the RS-232 serial port is raised to a positive voltage.  This option allows a physical voltage input on the serial port to trigger the network socket connection. If using the “DCD” mode of connection, there should be only one child Host Connection object with its Dial String set to an empty field.  The Terminal Client will use the IP address of that Host Connection object to connect when the DCD control signal is received.

ATDT or DCD – Select this option to connect the Terminal Client in one of two modes described above (the “ATDT” or “DCD” modes). When choosing this option, it is required that one or more Host Connection objects be defined with a configured Dial String, and there should also be only one Host Connection object defined with its Dial String set to an empty field. If an “ATDT###” message is received on the serial port, the matching Host Connection object is used, and the Terminal Client connects to that IP address. If an active DCD signal is present, the Terminal Client connects to the IP address defined in the first Host Connection object containing an empty Dial String field.

Number of seconds to close socket after inactivity (0 disables TTL)

After 2019, serial buffer is flushed upon TCP connect if TTL > 5.

Use a unique Instance number for each Host Connection object. 

Enter the Dial String, if applicable, in the form “ATDT###”, where ### is some unique alphanumeric string (up to 30 characters).  This field may be left blank.

If using the Terminal Client in “ATDT” or “ATDT or DCD” connection modes, enter the ATDT#### string that is used to make a connection.  Each ATDT string should be configured should be unique among all Host Connection objects under a given Terminal Client.

The Dial String has an alternate function when using the Terminal Client to connect to a named server (URL, FQDN). If the Connection Table IP address is set to 0.0.0.0 and Interface set to "DNS", then you can enter a URL in the Dial String field.

If using any other connection mode, leave this field blank.  In those cases, the IP address(es) defined in the Connection Table become the default IP address used by the Terminal Client to which connection is made.

Select from the dropdown menu the conditions under which the Terminal Client should disconnect from the IP network server:

Never – Never terminate the Terminal Client from the remote server (remote side can drop the connection at any time).

+++ - Disconnect Terminal Client connection from the remote server if the string "+++" is received on the serial port. This must be exactly three pluses in a row. This function emulates the modem attention string often used prior to hanging up a PSTN dial connection.

DCD Drop – Disconnect the Terminal Client from the remote server when the DCD input on the RS-232 serial port goes to a low (inactive) state. This can be used in conjunction with the DCD connect option in the Terminal Client, to allow the DCD signal to both connect and disconnect; however, the two configuration options are independent and don't have to be used together.

+++ or DCD Drop – Disconnect the Terminal Client from the remote server either upon receiving the string "+++" on the serial port, or when an inactive DCD signal is detected on the serial port. 

Select whether to echo all commands. The options are:

No – Do not echo characters typed from the serial port. To Async – Echo characters to serial port only. To Async & IP – Echo characters received on the serial port to both the serial port and the remote connected IP server. 

Click the Edit Table button to define the IP address(es) and network interface for the Host Connection object.

Destination Address – IP address for the Terminal Client to connect to. Configuring a list of more than one IP address provides a fail-over connection in case one connection is unable to connect.

Interface – Device interface, which must match the Domain Name in the ACE network configuration objects, such as Ethernet, PPP, etc. (case-sensitive). This tells which interface to use for the connection.

To use a named server as the destination (URL or FQDN up to 30 characters) in the Terminal Client instead of an IP address, the following things must be configured:

• Destination Address must be 0.0.0.0
• Interface must be DNS
• Dial String must be the URL address of the connection

The DNS feature currently only supports a single URL destination (not multiple failover addresses). Also make sure under Networks to configure the "DNS Servers" object or enable the "Use Peer DNS" option in the CellModem object.

Must be 0.

Click the Edit Table button to define the variables and corresponding values that will be usable in other areas of the configuration

Search Name: Variable name for string replacement. This value will be accessible within an MQTT Client object by typing the name ${Search Name}

Replacement Text: Up to 512 chars to replace the original ${Search Name}

Returns the System → Unit Name of the current configuration