Platform

Each asset must be pre-registered in the RoboFuse platform, and only then the asset can communicate with the platform.

This step can be implemented using the API’s or using the web application – “developer” app.

Pre-Registered refers to the fact that a Asset must be defined in the RoboFuse IoT platform before the platform accepts any communication from that particular Asset.

Self-Activation

Once the Asset is pre-registered it must be activated, this must be done by device using next protocol.

At each reboot, must call the API end point: /assets/activate, from api.robofuse.com (this URL can be different based on deployment strategy, but devices must be re-programed accordingly).

/assets/activate

This endpoint allows easy activation of the Assets that are installed on different locations and provide easy method to “reprogram” an asset.

The frequency of calling the activation can be established by each device; is mandatory to call this function immediately after each reboot – restart – power on.

During the normal functioning the Asset can call the “activate” function at any time.

POST

Asset must call the end point with next payload:

{
 "encryption_key": "string",
  "asset_internal_number": "string",
  "sensors": [
    {
      "asset_internal_number": "string",
      "name": "string"
    }
  ]
}

• encryption_key: optional – if completed the response will be encrypted with this key
• asset_internal_number – asset number used when pre-registered on the Robofuse platform
• sensors – array with the presented sensors only if more than one sensor (himself) is presented (then is gateway)

Expected behavior:

• Client creates a POST Activate Request to the API Server with specific parameter(s).

URL example: https://api.robofuse.com/assets/activate/{internal_asset_number}

• If encryptionKey is missing or empty, then go to error
• If internal_asset_number is defined in api robofuse then get Application UID is found it; if is found in more than 1 Application, then go to error;
• If Application UID has Rabbit MQ active – check if the Device internal_asset_number topic is created, else create the topic
  • If is Gateway – check and create the assets needed for each associated sensor
• Generate configuration response
• Encrypt response – if criteria are meet

API Server respond to the request and return results in JSON format.

Note:

• If is Gateway – check and create the assets needed for each associated sensor; that is simplify the Asset Management,
• For each sensor Gateway (Asset) must generate UUID’s as internal asset numbers, because the sensor asset_internal_number must be unique; otherwise the platform will not enroll the sensor. Once the sensor asset_internal_number, is generated must be kept by Asset “forever”, if a new UUID is generated for same sensor the platform will treat as a new sensor.

Response

If all “things” run well, the response is:

{
  "app_uid": "104_abdd",
  "sensors_reading_frq": 1,
  "log_freq": 5,
  "protocol": "mqtt/wot",
  "device_time_zone": "+3",
  "sever_time": "2018-02-02T10:00:00",
  "location_id": "sibiu",
  "latitude": 45.0703,
  "longitude": 7.6869,
  "mqtt_servers": [
    {
      "URI": "mqtt://mq.robofuse.com:1883",
      "user": "104",
      "pwd": "hereitis"
    },
    {
      "URI": "mqtt://alt.server.com:1883",
      "user": "104",
      "pwd": "hereitis"
    }
  ],
  "wot_servers": [
    {
      "URI": "https://datastore.robofuse.com/api"
    },
    {
      "URI": "https://alt.server.com/api"
    }
  ],
  "sensors": [
    {
      "0": {
        "asset_number": "568hdk",
        "name": "sensor name",
        "description": "sensor descr",
        "streams": {
          "mqtt_stream": "humidity",
          "wot_stream": "humidity_sensors"
        }
      },
      "asset_number": "982oid",
      "name": "sensor name",
      "description": "sensor descr",
      "streams": {
        "mqtt_stream": "temperature",
        "wot_stream": "temperature_sensors"
      }
    }
  ]
}

•   “app_uid”: application UID used to send further data / accessing API or MQTT
•   “sensors_reading_frq”: objective to read sensor data, in seconds
•   “log_freq”: objective to send log data, in seconds – log data means : /api/device/state
•   “protocol”: “mqtt/wot”, – how data to be sent – using MQTT, or API
•   “device_time_zone”: “+3”,
•   “sever_time”: “2018-02-02T10:00:00”,
•   “location_id”: “sibiu”,
•   “latitude”: 45.0703,
•   “longitude”: 7.6869,
• “mqtt_servers”: array that contain the needed data to connect to mqtt
• “sensors” – array that refer for each one where data are expected to be received
• “asset_number”:
• “name”: “sensor name”,
• “description”: “sensor descr”
  • “streams”:
    • “mqtt_stream”: “humidity”, – in case of MQTT Topic
    • “wot_stream”: “humidity_sensors” – end point

Note:

• The sensors stream, is expected to be “hard-coded” in the firmware, but can be designed and implemented a method to compose the paths, this will give us flexibility to deploy the datastore on different URL
• The payload is expected to be 100% “hard-coded” – if this needs to be changed then deployed, devices must be retired and reprogrammed.