Configuring the Litmus Production Record Tag Message Conversion Flow

To allow the flow to create the right message payload so that the data can be successfully ingested by Litmus Production Record Database using a Litmus Integration, there are two mandatory configurations the user has to make.

The purpose of the flow, is to ingest tag data collected by Litmus Edge as DeviceHub tags and modify the message payload to meet the requirements of Litmus Production Record Database for tag data. The flow has to therefore subscribe to the topics of the tags which are to be send to Litmus Production Record Database.

The user provides these topics through the use of the Litmus pallet node Datahub Subscribe.

By default the flow has one such node added, but customers can add more nodes as needed.



To provide a topic, users edit the datahub subscribe node and replace the placeholder "Please enter topic"

with the topic of a tag to be used by the event configuration and press the Done button.

As typically more than one tag is required, users have several options for providing all the tags they require.

The flow comes with a single Datahub Subscribe node in the section

But users are able to add more nodes as they need and wire them all into the output.

The example shows how a user added more node by creating copies of the original node.

This option works well if a single DeviceHub device is to be monitored, but can become challenging to support if the flow is used to monitor multiple devices.

Litmus Edge allows users to make use of wildcards when providing a topic, so that one datahub subscribe node can be used to read more than one tag.

The flow is able to handle the use of wildcards.

This option has to be chosen carefully, as if several thousand tags are read, the flow can experience a slowdown.

Example for a wildcard on a Device Level

This option is very well suited if multiple devices are to be monitored. But care has to be taken to the amount of tags the flow may subscribe too.

To make sure, that ideally only these tags configured in Litmus Production Record Database are read, the best approach is to combine both options.

This makes use of the ability of Litmus Edge, that different DeviceHub devices can have the same tag name for the same information. For example the tag Temperature or Downtime can exist on several devices.

This means that the wildcards are used to read the same tag from all devices which have it.

But as each tag needs a data hub subscribe node, the user would add additional nodes accordingly.

For the modification of the message payload, the flow requires the TagItem to be provided which the value of the original payload represents.

More to the concept of TagItems for tags can be reviewed in the chapter Core Concept behind recording process and meta data for process tags.

By default the flow will use as TagItem "Value" and as WriteTopic "Litmus.ProRec". But users are able to modify these.

To modify the TagItem and/or WriteTopic, the user has to edit the sub flow.



This allows to set the desired values for these two settings and press the Done button.

To start the processing, deploy the flow.

As it is possible to have more than one TagItem per DeviceHub tag or have different TagItems for different tags, users can add additional subflows

After all configurations have been done and are deployed, it is recommended to setup a Litmus Integration using the DB - Microsoft SQL Server connector.

How to setup an integration can be read up on using our Litmus Edge Documentation.

After the integration is established, the user needs to subscribe to the topic which has been setup in the sub flow.

How a subscription for an integration is added, can be found in the Litmus Edge Documentation.

Add as Local Data Topic the value used in your event configuration.

Now, every time the flow publishes a new message on this topic, the integration will send it to Litmus Production Record Database.