The history configuration for MQTT Engine tags can be setup as needed for your specific requirements as described in Ignition's Configuring Tag History and How the Tag Historian System Works documents.

There are however some caveats regarding tag history configuration persistence and handling of historical event data that are detailed in this document.

History Configuration Persistence  

Currently history configuration for MQTT Engine tags is not persistent and it may be required to delete MQTT Engine tags in certain cases. Reference Understanding how tag changes at the Edge affect MQTT Engine for more details.

The recommended way of configuring history for MQTT Engine tags is to use reference tags to indirectly reference MQTT Engine tags. This allows the history configuration to be persisted on the reference tag when the underlying MQTT Engine tags are deleted. 

The reference tag must be a Reference tag only.  Derived, Expression and OPC tags (expose MQTT Engine tag provider through OPCUA server) will not properly store history when MQTT Engine tags are updated with historical data at a high rate of speed. This is a limitation within the Ignition platform and may be addressed in a future release.

Alternatively you can use scripting to reapply the history configuration directly to MQTT Engine tags on demand


MQTT Engine Historical Event Processing

MQTT Engine has two ways to process historical events and insert the historical data into Ignition's Tag Historian module:

Writing historical events directly to tag is required if there are:

  • Tag Events scripts that fire when applicable
  • Alarms that are triggered when applicable
  • Reference tags used to indirectly reference MQTT Engine tags



Writing historical events directly to the database, via the Historian, bypassing the tag

The configuration parameters required to write historical events directly to the database, via the Historian, bypassing the Tag are shown below.

MQTT Engine

Under the MQTT Engine Settings General Tab, navigate to the Miscellaneous Settings and ensure Store Historical events is selected

Tag History Configuration

History must be enabled on the MQTT Engine tag but the only property used from the tag history configuration is the Storage Provider.

All historic data will be written to the configured Storage Provider, via the Historian, using the timestamp associated with the historical data.

All other properties such as Sample Mode, Max Time Between Samples, Deadband etc are ignored when writing historic data

Edge Client

The Edge side client should publish historic data asynchronously.

If you are using MQTT Transmission as the Edge side client, under the MQTT Transmission Settings for your transmitter, navigate to the History Settings to disable the In-Order History configuration parameter. 



Writing historical events directly to tags

The configuration parameters required to write historical events to the tag instead of directly to the Historian are detailed below. 

MQTT Engine

Under the MQTT Engine Settings General Tab, navigate to the Miscellaneous Settings and ensure Store Historical events is de-selected

Tag History Configuration

History must be enabled on the tag (either directly on the MQTT Engine tag and/or reference tag) with these three settings required:

  • Deadband Style set to Discrete
  • Sample Mode set to On Change
  • Min Time Between Samples set to 0

All historic data will be written to the tag using the timestamp associated with the historical data.

Deadband Style must be set to Discrete for all tag datatypes. This ensures that a change is registered any time the value moves +/- the specified amount from the last stored value.

If left at the default Auto setting, Ignition will determine the deadband style based on the tag datatype. See this Ignition Configuring Tag History Deadband and Analog Compression for details on how the Analog and Discrete Deadband Styles differ. 


When Max Time Between Samples is greater than 0, inserts at this sample time are not honored during historical data flushes because the tag updates for historical data occur too quickly.

For example the Max Time Between Samples is 5 Seconds. Whilst the edge node is offline, the edge node tag has updates every 10 seconds. On reconnect, all these historical change events are published and written to the MQTT Engine tag within milliseconds. As a result the Max Time Between Samples does not trigger.

Edge Client 

If you are not using reference tags, the Edge side client must publish historic data in-order (synchronously) before live data resumes. This is because Ignition will ignore writes to the tag if the timestamp on the tag change is older that the current value.

If you are using reference tags and have the Ignition Allow Back-fill Data disabled on the tag provider that will contain the reference tags, the Edge side client must publish historic data in-order (synchronously) before live data resumes. This is because Ignition will ignore writes to the tag if the timestamp on the tag change is older that the current value.

If you are using reference tags and have the Ignition Allow Back-fill Data enabled on the tag provider that will contain the reference tags, the Edge side client can publish historic data either synchronously or asynchronously. Using each of these different flush methods has the following implications:

  • In-order history from the Edge Node
    • Historical data will be stored for the reference tag
    • If history is enabled on MQTT Engine tags, historical data will be stored the MQTT Engine tag
  • Asynchronous history from the Edge Node
    • Historical data will be stored for the reference tag
    • Even if history is enabled on MQTT Engine tags, historical data will not be stored the MQTT Engine tag. New values will only be stored in the historical database if it is a non-historical value.

If you are using MQTT Transmission as the Edge side client, under the MQTT Transmission Settings for your transmitter, navigate to the History Settings to select or deselect the In-Order History configuration parameter.

As shown below, when the MQTT Transmission client comes back online and flushes history, it will flush the oldest historical events first (in order) before sending live Tag changes events to Engine. 


History Configuration Examples

Sample Mode = On Change, Min Time Between Samples = 0, Max Time Between Samples = 0

  • Suitable for writing historical events directly to the database or writing historical events directly to the tag
  • Real-time data is written to the storage provider on each tag change event whilst the tag quality is Good
  • Historical data is written to the storage provider or tag using the timestamp associated with the historical data 
    • Handles historical metrics flushed from the Edge that have very high resolution; e.g., the historical metrics have timestamps 1 ms apart for a single tag

Sample Mode = On Change, Min Time Between Samples = 0, Max Time Between Samples = 5

  • Suitable for writing historical events directly to the database or writing historical events directly to the tag
  • Real-time data is written to the storage provider on each tag change event whilst the tag quality is Good
  • Real-time data is written to the storage provider on the Max Time Between Samples interval if no tag change events whilst the tag quality is Good
  • Historical data is written to the storage provider or tag using the timestamp associated with the historical data 
    • When the Max Time Between Samples > 0, there will be no inserts during a history flush as the tag updates occur too quickly
    • Handles historical metrics flushed from the Edge that have very high resolution; e.g., the historical metrics have timestamps 1 ms apart for a single tag

Sample Mode = Periodic, Max Time Between Samples = 0, Sample Rate = 5

  • Suitable only for writing historical events directly to the database
  • Real-time data is written to the storage provider on the Sample Rate whilst the tag quality is Good
  • Historical data is written to the storage provider using the timestamp associated with the historical data





Ignition Allow Back-fill Data

Starting in Ignition 8.1.4 Ignition supports a feature to 'back-fill' historical data for tag providers.

Normally if a tag is updated with a value that is older than the current value, Ignition simply throws it away. In doing so, no tag change event will ever fire and the tag will not be updated. The back-fill option allows the value to be stored to the historical database if history is enabled on that tag. However even with this option enabled, it is important to note that no tag change event will fire. So, tag change event scripts, transaction groups, and any other subsystem that relies on tag change events will not be notified of the event if it is older than the current tag value (i.e. is historical).

To enable this option, browse to the Ignition Gateway Web UI → Config → Tag Providers → Realtime. Select 'edit' for the Tag Provider that will contain Reference Tags that will point to MQTT Engine tags. Scroll to the bottom and click the 'Show advanced properties' checkbox. This will show the 'Allow Back-fill Data' option. Set it to true as shown below and then click 'Save Changes'.




  • No labels

New to MQTT? Start Here!