Skip to content

Glossary

This glossary defines terms and acronyms used across the CC2 documentation. If you encounter an unfamiliar term while reading, refer back to this page.


A UDP-based protocol used to send location and status data from the device to a remote server. Configured via the wifialp device. Used for real-time positioning and alerting in enterprise environments.

See: WiFi, Scan, ALP & CCX Config

A device state (A) where the device is assigned to a specific user. In this state, allocdata.json becomes active, and user-specific applications and configurations are loaded.

See: Device States

The configuration file loaded when the device enters the Allocated state. Contains user-specific data, application definitions, and network overrides. Usually delivered from the IES during the allocation process.

See: allocdata.json


A wireless personal area network technology used by the CC2 for proximity detection, iBeacon advertising, GATT services, and peripheral communication. Can be configured as type: "ble" (nRF53) or type: "bleperi" (nRF52).

See: Network Configuration


The hardware device documented throughout this site. An advanced IoT unit supporting WiFi, BLE, and LoRa communications.


A full-screen interface that opens when a user interacts with an editable widget. Used for editing multi-line messages, toggling boolean values, selecting from lists, or viewing message details. gotoWidget opens a widget’s DED.

See: Editable Widgets & DEDs

The top-level MQTT envelope key used for persistent configuration of the device. Settings sent under devcfg change the device’s long-term behavior (e.g., WiFi settings, LED patterns, audio configuration). Distinct from devwork (one-shot actions) and devdata (reported state).

See: Device Config

The top-level MQTT envelope key used for dynamic state reporting from the device. Contains sensor readings, current state, battery level, and other runtime values. Appears in uplink messages. Also used in downlink to request specific data.

See: Device Data (Uplink)

The top-level MQTT envelope key used for one-shot actions. Commands under devwork trigger fire-and-forget operations like rebooting, scanning, or file operations. Distinct from devcfg (persistent config) and devdata (state reporting).

See: Device Work

The process of updating the device’s firmware. Can be performed over USB (copying app_update.bin to the USB drive), OTA (over-the-air via MQTT/HTTPS), or via BLE. The device enters the D state during DFU.

See: Firmware & Provisioning Config

A JSON file that defines a screen layout on the device. DVs contain infopages with widgets (buttons, text, graphics, message lists). DVs can be loaded from the IES (src: "inline") or from local storage (src: "local").

See: Device Views (DVs)


See: IES


A compact binary format for scan results (wifiscan, blescan). Enabled by setting "fbin": true. Returns results as base64-encoded binary instead of JSON, reducing payload size — useful for low-bandwidth networks like LoRa.

See: WiFi, Scan, ALP & CCX Config


The baseline configuration file loaded at every boot. Defines core device behavior, network definitions, MQTT broker, and IES endpoints. Other config files (allocdata.json, unallocdata.json) override or extend it.

See: global.json


The backend server that manages device allocation state, user associations, and configuration delivery. When a device is allocated or returned, the IES updates its state and provides the appropriate allocdata.json. The device communicates with the IES via the entityMgrServer defined in global.json.

See: Allocation & Return

A DV source type where the DV JSON is included directly in the allocdata.json or unallocdata.json payload from the IES. The device does not need to read a local file.

See: Allocation & Return


A DV source type where the device loads the DV JSON from the local filesystem at /dvs/<app_name>.json. DVs must be present on the USB drive.

See: Allocation & Return

A low-power wide-area network technology used by the CC2 for long-range communication. Configured as type: "loraperi".

See: Network Configuration


MQTT (Message Queuing Telemetry Transport)

Section titled “MQTT (Message Queuing Telemetry Transport)”

The primary communication protocol used between the CC2 and the backend. Messages are sent as JSON on dedicated topics: msgs-down (to device) and msgs-up (from device).

See: MQTT Commands

A widget type that displays a list of messages (alerts, notifications). Supports folders, read/unread status, and full-page DED views for individual messages.

See: Msglist Protocol (Downlink)


A device state (P) where the device is being configured for first-time use or recovery. During provisioning, the device downloads configuration files (including allocdata.json and unallocdata.json). The state times out after 180 seconds of inactivity.

See: Device States


A binary encoding format where each data element is encoded as:

  • Type (identifies the field)
  • Length (number of bytes of data)
  • Value (the actual data)

Used in BLE GATT communication and some downlink messages to reduce payload size. Defined in tlv_down.json and tlv_up.json files.

See: Msglist Protocol (Downlink)


A device state (U) where the device is not assigned to a specific user. In this state, unallocdata.json becomes active. The device displays a minimal home screen and waits for allocation.

See: Device States

The configuration file loaded when the device is in the Unallocated state. Contains the basic device personality, network order, and minimal app definitions. Usually stored locally on the device.

See: unallocdata.json


The primary network interface used by the CC2 for MQTT communication, configuration downloads, and backend connectivity. Supports WPA2-PSK, WPA3-SAE, and EAP-TLS (enterprise).

See: Network Configuration