Sending Data

Sending Data covers the two direct integration paths into ControlCom Connect: publishing to the platform's MQTT broker, or posting to the HTTP API. You use them when your own code holds the readings, whether that is device firmware, a service on a server, or a script. The Edge Server is not involved.

Workflow Stage: Collect

Overview

Both paths deliver values to the Variables of a Generic device in your Organization. The difference is the transport and the credential. MQTT keeps a persistent TLS connection open and authenticates with the device's certificate. HTTP sends one request per batch and authenticates with an API key. The JSON payload is the same shape in both cases, so switching later means changing the transport code, not the data.

Guides

MQTT

Publish to the platform broker over TLS on port 8883 with the device certificate.

Connection details, both payload formats, and client examples.

HTTP API

POST JSON to the data endpoint with API key credentials.

Endpoint, Basic authentication from an API key, payload format, and request examples.

MQTT or HTTP

Pick MQTT when the device stays online and sends often, when it needs to receive commands from the platform, or when it is constrained enough that a persistent lightweight connection beats repeated HTTP handshakes. Pick HTTP when the sender is a web or server application, when data goes out on a schedule rather than continuously, or when the network only allows outbound HTTPS.

	MQTT	HTTP API
Connection	Persistent, over TLS on port 8883	One request per upload, over HTTPS
Credential	Device certificate and private key, issued when the device is created	API key, created under Administration > API Keys
Direction	Publish data and receive commands	Publish data only
Typical sender	Firmware, gateways, always-on services	Web applications, scheduled jobs, scripts
Testing	Any MQTT client that supports TLS client certificates	cURL, Postman, or any HTTP library

Running both is common: MQTT for the equipment on site and HTTP for a third-party system that pushes a daily batch.

The sender addresses a specific device, and each key in the payload lands in the Variable on that device whose Topic Property matches the key. Keys without a matching Variable are ignored, so create the Variables before sending. The Variables page describes the dialog, the data types and the Store Data setting that decides whether history is kept.

The payload is a dataArray of key and value pairs, with either one timestamp for the whole message or one per item. Omit the timestamp and the platform uses the time it received the message.

{
  "timestamp": 1647359121000,
  "dataArray": [
    { "key": "temperature", "value": 24.5 },
    { "key": "isDoorOpen", "value": false }
  ]
}

Getting Started

Create a Generic device under Devices in the ControlCom Connect console, save the certificate bundle and connection details it offers, and add a Variable for each key you plan to send. Bring Your Own Device walks through this once, and Device Administration covers the device types and certificate rotation in detail.

Then follow the guide for your transport. Once the first message arrives, the Variable's current value updates on the device's Variables tab, which is the quickest way to confirm the integration works.

Sending Data over MQTT Sending Data over HTTP

If you would rather not write the MQTT client yourself, Node-RED can publish to the broker using the same certificate bundle. If the equipment speaks an industrial protocol such as Modbus or OPC UA, the Edge Server reads it for you and no integration code is needed at all.

Next Steps

With data arriving, the Store stage keeps history for every Variable that has Store Data enabled. From there, query it in Platform Explorer in the Analyze stage, put it on a dashboard in the Visualize stage, or set an alarm on a threshold. The Platform Overview shows how devices, Variables and assets fit together.