MQTT topics

One way to send data to IA is to publish properly formatted MQTT messages to a topic referred to as the default normalizer topic. Publishing to that topic will ensure that:

1. Attribute history is automatically updated

2. Attribute values are checked against rules and events generated if rule criteria are met.

Other MQTT topics of interest

The MQTT topics discussed here can be used for troubleshooting. A developer can use the Messages page in the backend system using the ClearBlade Developer console and subscribe to the listed topics to watch messages flowing.

1. Data published to default normalizer topic is internally forwarded to this MQTT topic known as the assetLocationAndStatus topic:
   _dbupdate/_monitor/_asset/<asset_id>/locStatusHistory
   
   If desired data can be sent directly to the assetLocationAndStatus topic (i.e. bypassing the default normalizer topic) by publishing MQTT messages to that topic with the following payload formats (presented as TypeScript types):
   For creating a new asset:

   CODE

   {
     id: string;
     type: string;
     group_ids: string[];
     last_updated?: string;
     last_location_updated?: string;
     latitude?: number;
     longitude?: number;
     floor_levels?: number[];
     custom_data?: {
       [key: string]: string | number | boolean | null | Record<string, unknown>;
     };
     tags?: string[];
     label?: string;
     attributes_labels?: {
       [key: string]: string;
     };
   };

   
   For updating an existing asset:
   

   CODE

   {
     id: string;
     last_updated?: string;
     last_location_updated?: string;
     latitude?: number;
     longitude?: number;
     floor_levels?: number[];
     custom_data?: {
       [key: string]: string | number | boolean | null | Record<string, unknown>;
     };
     tags?: string[];
     label?: string;
     attributes_labels?: {
       [key: string]: string;
     };
   };

   
   The processing of assetLocationAndStatus messages is configured using the following parameters:

   

   Changing any of these parameter values from their defaults requires changes in the backend system via the ClearBlade Developer console.
   
   NOTE: Changes to backend ClearBlade systems must be made with extreme caution!

   1. Edit the system_info collection.

   2. In the configuration column the existing object needs to be modified to include a new “asset_location_status_options” as follows…
      

      CODE

      {
        ...
        "asset_location_status_options": {
          ...
          "createAssetIfMissing": false,
          "assetHistoryBatching": "TIME_ONLY",
          ...
        },
        ...
      }

      
      

2. _rules/_monitor/<asset_id>
   Messages published to this topic are used to determine whether rule criteria are satisfied and whether events should be generated. This topic is published to by internal IA services and typically NOT by external code (i.e.. normalizers).
   

3. live/monitor/asset/<asset_id>/locationAndStatus
   Publishing to this topic will cause live updates on an Asset in the IA UI. This is useful for users leaving their browsers open to watch an asset change over time. This topic is published to by internal IA services and typically NOT by external code (i.e.. normalizers).
   

4. _dbupdate/_monitor/_asset/<asset_id>/command/<command_uuid>/request
   When an asset’s CONTROLS are interacted with, messages are published to this topic. These messages are referred to as commands since they make the recipient do something.
   
   Each command is accompanied by an automatically generated UUID which could be used for tracing commands from specific executions. Typically a custom code-service needs to be built to subscribe to this topic and perform some functionality when command messages are published.