Page History

...

• Primary Host ID
  • The primary host ID to use for 'state' checks.  These checks are used to ensure that the primary backend MQTT Engine client remains connected.  If the primary host ID is set, MQTT Engine will publish it's connection state on a topic that contains the Primary Host ID.  In the event that MQTT Engine becomes disconnected from the server, a death certificate will be published on the same topic, setting the state to 'offline'.  Any connecting client that subscribes on the state topic will then be notified of the MQTT Engine state and walk to the next server is MQTT Engine is offline.
• Group ID Filters
  • A comma seperated list of group IDs to ignore.  If no group IDs are to be ignored, this should be left empty
• Chariot Cloud Access Key
  • If using Cirrus Link's Chariot platform, this is the provided Access Key
• Chariot Cloud Secret Key
  • If using Cirrus Link's Chariot platform, this is the provided Secret Key
• Block Node Commands
  • Whether or not to block outgoing commands from MQTT Engine to Edge Nodes. This is true by default and provides a security mechanism for preventing accidental outgoing commands from MQTT Engine.
• Block Device Commands
  
  • Whether or not to block outgoing commands from MQTT Engine to Devices. .  This is true by default and provides a security mechanism for preventing accidental outgoing commands from MQTT Engine.
• File Policy
  
  • The policy for handling Files contained within a Sparkplug payload.
    • Ignore: The default policy. The file will be ignored.
    • Store: The file will be stored to the local file system in the directory specified by the File Location field.  A Tag will be created with a String value representing the file URI.
• File Location
  
  • The directory to store the files when using the Store policy described above.

Image AddedImage Removed

Namespaces

The third tab is used for configuring namespaces.  Each namespace configuration represents a family of devices and/or data that MQTT Engine will support.  A namespace defines the topics that each MQTT Engine client will subscribe on as well as indicates how the payload will be handled.  There are two types of namespaces: Default and Custom.  

...

Custom namespaces are used to provide support for generic MQTT messages with string based payloads.  If a custom namespace is configured MQTT Engine will convert all messages received to tags.  The topic of each message will directly translate into the tag's path.  The payload of the message will be that tag's value.   

Image RemovedImage Added

Each custom namespace has the following properties:

• Required Settings
  • Name
    • A friendly name of the namespace to easily identify it.
  • Subscriptions
    • A comma separated list of subscriptions.
• Optional Settings
  • Root Tag Folder
    • A
    optional
    • name of a folder where all tags will be stored.  If configured, this folder will be the base folder where all tag paths will start.
  • Tag Name
   
  • An optional
    • A tag name to be used for all tags.  If not configured, the last token in the topic will represent the tag.
    • JSON Payload
      
      • A flag to indicate that the content of the string based payload is a JSON object.

  Note: if a Tag Name is not specified, care must be taken so that published messages do not end up overwriting previous tags. 

  Clicking on the 'Create new Custom Namespace...' link will bring up the following form to add a new Custom Namespace.

  Image RemovedImage Added

  Custom Namespace Example  

  Let say we have a publish received on the topic "test/data/point" with value "12345".  If no Tag Value is configured, and a message is received, MQTT Engine will create a two folders "test" and "data" and a tag "point" with the value of "12345".

  Image RemovedImage Added

  

  Alternatively if a Tag Name is configured, lets call it "payload", then MQTT Engine will convert each token in the topic to a folder and create a tag called "payload" with the value "12345"

  Image RemovedImage Added

  

  In most cases it is useful to specify a Tag Name in order to prevent cases when a publish on a topic can overwrite a previously created tag, changing it into a folder.  Consider the case where you have the following two publishes:

  ...

  When the 2nd publish is received it will overwrite the first tag because "two" is now a folder instead of a tag.  This folder/tag name collision can be avoided by specifying the Tag Name to always use for tags. 

   

  Custom Namespace JSON Example

  Let say we have a publish received on the topic "test/data/json" with value '{ "stringTag" : "12345", "folderTag" : { "intTag" : 1, "boolTag" : true } 

   

  }'. MQTT Engine will create a three folders "test", "data" and "point" followed by a tag/folder structure representing the JSON value of the payload. 

  Image Added

  Image Added