The MQTT application presents detailed status information about the internal state of the application via Modbus registers.
See the Applications and Modbus tab for some background information on SCADASuite and Modbus. You can always export the Modbus register map for the application to see an up to date list of what status information is available, which registers the information is in, and descriptions of the meaning of the information.
The application's Diagnostic Log also contains important information about the status and internal state of the application.
All Status Parameters are shown in the screen grab below. Some additional explanations are provided via the callouts.
Status Parameters
Application execution information
All SCADASuite applications provide this basic information. The MQTT application is configured to execute once per second. In this example, you can see one very long execution time, as the TLS connection was negotiated. TLS negotiation is very bandwidth and computationally intensive.
You can also see that the Cycle Avg Time is 0, which means that the application executes very quickly except when the TLS connection is being negotiated.
These values are also written to the Diagnostic Log periodically.
This value lets you know at a glance whether the MQTT server is connected. MQTT works best with a persistent connection to the server, especially if high speed data publishing is desired. If the application cannot connect to the server then no data can be published. If this value isn't stable, and normally 1, you might see data loss. Use the Datalogs application to monitor this value without any dependency on communications.
This counter is incremented when a publish acknowledgment is not received in response to a publish request. This counter should be incremented infrequently.
SSL (TLS) connections still require an underlying TCP connection. When SSL is used, both TCP and SSL success counters should be incrementing. If the TCP counters are showing good TCP connection attempts, but an SSL connection cannot be created, then the problem is likely somewhere in the SSL implementation. The MQTT application supports TLS v1.0 to v1.2. It does not support older SSL versions, and it does not support STARTTLS.
These counters track the status of subscription requests. A subscribe requests is only sent when connecting to an MQTT server, so these values should chnage infrequently.
These values track subscription messages, where the host requests that a value is written. A write request can be rejected for various reasons, such as Enable Monitoring isn't selected for the value, Enable Subscribe isn't selected for the value, or Publish on Change isn't selected for the value.
