Page History

...

Once in the configuration section there are three tabs: Servers, Advanced, and Namespaces.  Each of these tabs is described in detail in the following sections.

Servers

The first tab is a list of MQTT Servers that MQTT Engine should connect to.  By default, MQTT Engine is configured to connect to the local MQTT Distributor based MQTT Server.  It is set up to connect to localhost, port 1883, using the default username/password pair of admin/changeme.  Out of the box MQTT Engine will work with MQTT Distributor and its default configuration.  The connection status of each server can be seen in the 'Status' column.  Clicking on the 'Create new MQTT Server' link will bring up the following form for adding a new MQTT Server setting.

...

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

Advanced

The second tab contains advanced settings which allows one to configure Application ID Filters and Cirrus Link Chariot Access Settings.  The Chariot access settings settings are used in conjunction with a Cirrus Link Chariot deployment and will be provided when purchasing Chariot Cloud services.

...

• 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.

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.  

Default Namespaces

Default namespaces are provided out of the box and can simply be enabled or disabled.  When MQTT Engine is first installed, all default namespaces are enabled.  Each default namespace has the following properties:

...

If a namespace is enabled, MQTT Engine will subscribe to the topics necessary to provide support for devices and data associated with that namespace.  If a namespace is disabled, MQTT Engine will unsubscribe from those topics and no longer support the devices and data associated with that namespace.

Image ModifiedCustom Namespaces

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.   

...