|Control 'sys' topic|
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).
|Control 'cmd' topic|
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.
|Control 'file' topic|
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.
|RBE Data at Restart|
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.
|Publish Tag Names|
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 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.
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.
The Sparkplug B object provides a connection to an MQTT broker that expects data to be published in the Sparkplug B format, and open source MQTT payload developed and maintained by Cirrus-Link Solutions. More information about the Sparkplug B payload can be found here: http://www.cirrus-link.com/oem-device-data-integration/.
|Parent(s)||System → Clients|
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).
|RBE Pacing||Enter the number of milliseconds to wait between RBE messages|
|Accept NODE Cmd Topics||Select whether to subscribe for NODE (Gateway) command topics.|
|Accept DEVICE Cmd Topics||Select whether to subscribe for DEVICE command topics (output commands to protocol)|
|Accept File Topics||Select whether to subscribe for file topics|
|Group Name||GroupName is Appended to 'spBv1.0' namespace topics (unless property is left blank), used to filter published data in groups.|
|STATE Topic||The STATE topic is used to ensure an active end-to-end connection to Host, or switch to next MQTT server|
|RBE Processing||Only process RBE RTDB Registers with TagNames?|
|Account||Account name for MQTT Access Control List (255 chars)|
|Password||Password for MQTT Access Control List (255 chars)|
|MQTT Port||MQTT Broker Connection Port (default is 1883 for unencrypted, or 8883 for TLS)|
|MQTT Keep Alive||Enter the interval (in Seconds) to send MQTT keep alive. Expect response within 1.5 times Keep Alive, or disconnect and try the next server.|
|MQTT Connect Delay||Enter the time (in Seconds) to delay after loss of connection before reconnect.|
|Enable RBE List||Enter list of channel/unit to publish. If table is empty, publish ALL RTUs with RBE data enabled.|
|URL_List||Enter a list of URLs or FQDN for MQTT server failover.|
Store and Forward
|Object Type||Store and Forward|
|Parent(s)||System → Clients|
Must be 0.
Select when to store RTDB values as historical records.
|Process to Monitor|
Select which Process (or a TCP Port) should be monitored to determine the "Link Failure" condition. If the Operation Mode is set to store changes only on Link Failure, values will be stored as Unpublished data when the link is broken. This property also determines when to deliver data automatically after the link is restored – when the link is restored, the unpublished historical values will be sent using the Delivery Technique, below.
The following options apply to Process to Monitor:
|Port to Monitor||TCP Port to monitor – this option only applies if using the Monitor a TCP Port link status option above.|
Select which of four RBE flags (0 to 3) to use for checking changed data.
Important: make sure not to use the same RBE Flag used by any other process for RBE processing, such as MQTT, HCP, or DNP3.
Minimum interval delay between checking the RBE Flag for changed data in order to store values to the archive.
Only process RBE RTDB Registers with TagNames?
Use which external Memory to store historical data (currently only supports SD card).
Values are stored to CSV files in /tmp/sdcard1/SNFaa_bbbbb/, where aa is the Channel number instance, and bbbbb is the RTU address.
Files are named CHANaa~RTU-b~yyyymmdd.csv, where aa is the Channel number instance, b is the RTU address, and yyyymmdd is the year/month/day of the date when the values were stored.
Such as: /tmp/sdcard1/SNF05_00009/CHAN05~RTU-9~20180731.csv
See the RediGate Diagnostics Manual for a menu option to view the contents of Store & Forward CSV files.
|Files to Retain|
Number of recent daily files to retain stored historical data before purging.
Data is stored in one CSV file per day for each device.
Select how to deliver historical data from the CSV files when link is restored. When publishing individual historical values, only data marked Unpublished are sent.
BASH Script or command line to run after reconnection – this option only applies if using the Delivery Technique of "Run Reconnect Script After Link Reconnect."
This option might be used, for example, if a script is included which performs an FTP operation to upload the latest .csv files somewhere and then deletes the current files.
|QOS||Quality of Service for delivery of historical data (applies to JSON or Sparkplug delivery technique). Currently, the only option is QOS-0.|
|Send Data Format||Unused option – reserved for future use.|
|Enable RTU List||Enter list of Master Channel/Field Unit RTDBs to use with Store & Forward. If table is empty, store and publish ALL Field Units with RBE data enabled.|
Store & Forward Payload Definitions
Elecsys created the JSON-RBE payload specification for easy integration into 3rd party applications. Historical data is plublished in a text-based JSON object that can be easily parsed. More information about the historical JSON-RBE payload can be found here: JSON-RBE MQTT Payload Format#RBEMQTTPayloadFormat-HistoricalDataPayload.
The Sparkplug B specification is an efficient, binary MQTT payload definition created by Cirrus-Link solutions and supported by SCADA applications such as Ignition Automation's Ignition platform. See the section on Sparkplug B configuration. Information about the Sparkplug B specification and the historical payload can be found on Cirrus-Link's website: http://www.cirrus-link.com/oem-device-data-integration/.
See the section Automated Processing for documentation on this feature.
Terminal Client (TermClient)
The Terminal Client process connects to a TCP/IP server on a network, and bridges that network connection with a local serial port. This is distinguished from the Terminal Server by the fact that the RediGate initiates the connection to the TCP/IP server, as opposed to an external network client making the network socket connection to the RediGate. The Terminal Client process is similar to the "Reverse Telnet" option available in many routers.
The Terminal Client IP connection may be initiated always at startup of the system or upon receiving any data from a device on the serial port, and it also provides an option as a "modem emulator" whereby the connected serial device can use AT commands to direct which IP address should be connected to.
|Parent(s)||System → Clients|
Use a unique Instance number for each Terminal Client object.
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.
|Serial Buff Size||Maximum number of bytes which will be put into an IP packet to be sent to the network server. Once receiving this quantity of bytes on the serial port, a TCP packet will be sent immediately. The actual amount of data bytes may be less than the Serial Buff Size, if the Demark Timer (below) times out before the Serial Buffer is full.|
|Demark Timer||Maximum time (in milliseconds) to wait before creating and sending a packet regardless of how many data bytes were received on the serial port. This indicates the assumed "demarcation" time between serial packets. If a serial device is periodically sending messages at a defined interval, setting this Demark Timer too high could cause multiple serial packets to be clumped together in one TCP packet, which may not be desirable. Setting this value too low might cause half of a packet to be sent prematurely if there is a momentary glitch or pause in the serial data stream.|
|Client Reconnect Delay||Enter the time (in seconds) that the Terminal Client will wait after a failure to connect, before attempting to reestablish connection with the Server. This only applies when the connection is unable to be established. If the connection is made and then lost, reconnection will be attempted immediately.|
|Ok AT Commands||Select whether to echo an "OK" to AT commands entered at the Terminal Client serial port. The OK is similar to communicating with a modem over its serial port.|
|DTR Indicates Online||Select whether DTR indicates IP connection state. If set to 'Yes', the serial port's DTR signal will be asserted to a positive voltage when the IP connection is established with a remote server, and will be de-asserted when the IP connection is lost. This emulates the Data Terminal Ready functionality of a dial-up modem, giving a physical indication that an active connection is present.|
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.
|Time to Live||Number of seconds to close socket after inactivity (0 disables TTL)|
Terminal Client Host Connection (HostCon)
The Host Connection objects are used in conjunction with the Terminal Client to configure one or more IP addresses to which the Terminal Client will connect, and to allow the Terminal Client to be used as a modem emulator.