Skip to content
CC2 Device Documentation

duress_appAPI Behavior (MQTT)

The Duress Management duress_appexposes REST endpoints for device assignment, but all actual device communication happens via MQTT. Understanding the exact MQTT commands the duress_apppublishes allows the assistant to reproduce the same behaviour without direct duress_appaccess.

1. Simple Assign (POST /simple-assign)

Section titled “1. Simple Assign (POST /simple-assign)”

Assigns a device to a user and provisions the home screen.

What the duress_appdoes (MQTT):

  1. Publishes three fdld commands sequentially to download allocdata.json, unallocdata.json, and dvs/duresshome.json.
// Command 1 – download allocdata.json
{
  "devwork": {
    "actions": [
      {
        "a": "fdld",
        "p": {
          "file": "allocdata.json",
          "url": "https://api.infrafon.cloud/ife/rest/v1/file/<file_id>/download"
        }
      }
    ]
  }
}
// Command 2 – download unallocdata.json
{
  "devwork": {
    "actions": [
      {
        "a": "fdld",
        "p": {
          "file": "unallocdata.json",
          "url": "https://api.infrafon.cloud/ife/rest/v1/file/<file_id>/download"
        }
      }
    ]
  }
}
// Command 3 – download duresshome DV
{
  "devwork": {
    "actions": [
      {
        "a": "fdld",
        "p": {
          "file": "dvs/duresshome.json",
          "url": "https://api.infrafon.cloud/ife/rest/v1/file/<file_id>/download"
        }
      }
    ]
  }
}
  1. Sends a reboot after all downloads complete.
{ "devwork": { "actions": [{ "a": "reboot" }] } }

The files contain:

  • allocdata.json – sets duresshome as the home DV, includes the assigned user’s name in user.visitor and in the duresshome.json DV.
  • unallocdata.json – fallback configuration for the unallocated state.
  • dvs/duresshome.json – the wearer’s home screen with user_name and user_role set to the assigned user.

2. Full Assignment (POST /device-assignments)

Section titled “2. Full Assignment (POST /device-assignments)”

Same as simple assign, plus additional files (visite.json) and pre‑flight checks (device connectivity, MQTT health, existing assignment).

3. Return / Deactivation (DELETE /device-assignments/<id>)

Section titled “3. Return / Deactivation (DELETE /device-assignments/<id>)”

Deactivates the assignment and returns the device to an unallocated state.

MQTT command sent:

{ "devwork": { "actions": [{ "a": "return_local" }] } }

This triggers the device to load unallocdata.json and return to the unallocated home screen.

4. Update Assignment (PUT /device-assignments/<id>)

Section titled “4. Update Assignment (PUT /device-assignments/<id>)”

Updates the database record only – no MQTT commands are sent.

To update the name on the device itself, a separate app.duress or allocation update would be needed. However, for the notification name (the subj field in duress alerts), the duress_appuses its own database assigned_to field, not the device’s vname. So updating the portal record is sufficient for future alerts.

How the assistant can use this

Section titled “How the assistant can use this”
  • When a user asks to assign a device, the assistant can mimic the simple assign flow by sending the same fdld + reboot commands.
  • For debugging wrong notification names, the assistant can explain that the portal’s assigned_to field (not the device’s own data) controls the subj, and suggest updating it via the duress_appUI.
  • For returning a device, the assistant can send return_local directly.
Section titled “Related”