Configuring

Transmission Settings

The MQTT Transmision Edge side client can publish historic data either in-order (synchronously) or asynchronously however, enabling the In-Order History for MQTT Transmission is unnecessary and will result in a waste of resources. 

When configured for In-Order History, MQTT Transmission will ensure that after the client reconnects, all historical data will be flushed before live data updates are resumed. Until the historical data is completely flushed, any new updates will continue to be written to the history store to ensure the in-order delivery of data. 

Under the MQTT Transmission Settings for your transmitter, navigate to the History Settings to disable the In-Order History configuration parameter.

History Store Settings

MQTT Transmission History Store supports both In-Memory and Disk-Backed types. There are advantages/disadvantages to each:

  • 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 whereas the data will be persisted in a Disk-Backed History Store
  • It will take longer to query data from a Disk-Back History Store that from an In-Memory Store

The flush rate for a history store type is controlled using the Flush Quantity and Flush Period parameters 

  • Flush Quantity
    • The maximum number of tags to publish in a single message upon re-establishing communication.
    • Default 10,000
  • Flush Period
    • The period to wait in milliseconds between acquiring data from the memory store and publishing when flushing messages upon re-establishing communication.
    • Default 200

The Flush Period is a the delay between acquisition and publishing of the historical data. MQTT Transmission queries the history store and builds up a publish, and publishes it, and then delays by the Flush Period. 

The actual message publish frequency is not deterministic as the time to gather the publish from the history store can vary depending on the frequency tag change events occurring, disk speed, CPU availability, etc.

For example, if it takes 5s to gather up and publish that payload, the actual message publish frequency will be it will be 5s + the flush period

History Store Tags

In the MQTT Transmitter provider, under each of the History Store folders for each Transmitter, a tag tree will be created with the tag path of GroupID > EdgeID  and/or > DeviceID.

The tags are updated every 30 seconds

  • Metrics Stored
    • Number of Edge Node or Device level tag change events stored. 
  • Records Stored
    • Number of Edge Node or Device level records stored.


Validating

You can use the steps detailed in the How to verify the history store data published by MQTT Transmission to validate that all the historic data is being flushed as expected

Missing data at the historian

If data is missing data at the Historian, then the next trouble-shooting steps are to adjust the MQTT Transmission Flush Quantity and Flush Period until you have a stable system when the messages published by MQTT Transmission are reliably consumed by your historian.

Start by decreasing the Flush Quantity to say 1000 and increasing the Flush Period to 1000. This will result in a slower flush with smaller message sizes.

Increment the Flush Quantity in small steps to see if there is a message size which is problematic for the historian.

Once a max message size has been identified, start to lower the Flush Period in small steps. This will help to identify if there is a message volume that is problematic for the historian.




Additional Resources










  • No labels

New to MQTT? Start Here!