Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Type
    • The type of History Store with options of In-Memory and Disk-Backed
    • 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.
  • History Max Size
    • The maximum number of megabytes history can use before dropping the data
    • In-Memory History Store will use the Ignition Java Heap memory
    • Default is 500
  • History Max Age
    • Maximum number of minutes to store history before dropping the data.
  • Flush Quantity
    • The maximum number of tags to publish in a single message upon reestablishing re-establishing communication.
    • Default 10,000
  • Flush Period
    • The period to wait in milliseconds between publishes when flushing messages upon reestablishing communication.messages upon re-establishing communication.
    • 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
    • Default 200


How to determine these settings

...

  • Configure a History Store with a large storage time for your tags.
  • Disconnect the Edge for a set time period to cause MQTT Transmission to store data to the History Store using one of the methods detailed below:
    • Disable the network connection
    • Disable the broker
    • Use Primary Host ID in both MQTT Engine and in the MQTT Transmission.
      • Removing the Primary Host ID from MQTT Engine will simulate the primary backend application going offline and cause MQTT Transmission to store data to the History Store.
      • Restoring the Primary Host ID to MQTT Engine will simulate that the primary backend application is online and cause MQTT Transmission to flush the stored data
    • Modify the MQTT Transmission client credentials at the broker preventing the client from connecting
Warning
Do not affect any configuration change on the MQTT Transmission module such as Disable/Enable of the module or modifications to Server settings. This will cause a module restart which will shutdown and restart all transmitters 
  • Monitor the live updates for the count of tag change events and memory used from the Transmission Info History Store metrics.
  • Reconnect and monitor the data flushing to ensure that the flush settings (quantity and period) are able to handle the current tag changes that continue to build.

    Note
    Whilst the history flush is in progress, all new change events are written to the history store until it has been completely flushed. If the tag change rate at the Edge is faster than the MQTT Transmission Flush Period this can cause a build up of data in history store(s) and prevent the publishing of live data.


  • Extrapolate based on the test

...

For ease of control we recommend setting a Primary Host ID in both MQTT Engine and in the MQTT Transmission.

Removing the Primary Host ID from MQTT Engine will simulate the primary backend application going offline and cause MQTT Transmission to store data to the History Store.

...






Excerpt Include
CHAR:FAQ: Chariot MQTT Server
CHAR:FAQ: Chariot MQTT Server
nopaneltrue

...