Collect: Data Collection Overview
ControlCom Connect collects data over three paths: the Edge Server, a container you deploy on site that reads industrial protocols and publishes for you; direct MQTT, where your own code publishes to the platform broker; and the HTTP API, where an application posts batches. All three end up in the same place, the Variables of a device in your Organization. The choice is who writes the code that talks to the equipment.
Overview
The Collect stage sits between Connect, where devices are registered in the platform, and Store, where values are kept in the time-series database. The Edge Server is the no-code path: run a Docker container on your network, onboard it as a ControlCom Gateway, and configure clients in the web interface that poll your equipment. The Edge Server handles the protocol, the secure connection to the platform, buffering during outages and reconnection. MQTT and HTTP are the developer paths: your code holds the readings and delivers them itself.
Guides
Edge Server
A container you run on site. Reads Modbus, OPC UA, BACnet, EtherNet/IP and LoRaWAN; no code to write.
Deploy with Docker, onboard it as a gateway, then map registers and tags to Variables in the web interface.
MQTT
Your code publishes to the platform broker over TLS with the device certificate.
Persistent connection, both payload formats, and the path commands take back to the device.
HTTP API
Your application posts JSON batches with an API key.
One request per upload. Suits scheduled jobs, web services and networks that only allow outbound HTTPS.
Choosing a Path
Start with the equipment. If it speaks an industrial protocol and you cannot or do not want to change its firmware, use the Edge Server. This covers most PLCs, meters, building controllers and drives, and it is the path for sites with many devices, since one Edge Server serves them all and keeps working through internet outages.
If you control the code on the device or in the application that holds the readings, use a direct path. MQTT suits firmware and always-on services that send often or need to receive commands. HTTP suits applications and scripts that send on a schedule, or networks where only outbound HTTPS is allowed. Sending Data compares the two in more detail.
Mixing paths is normal. A typical site runs an Edge Server for the equipment on the floor and uses the HTTP API for a third-party system that pushes a daily batch.
Getting Started
Whichever path you take, the platform side is the same: a device record in your Organization and a Variable for each value you want to collect. The two first-steps guides walk through this end to end, one per path.
Once data arrives, the Variable's current value updates on the device's Variables tab in the console. For the Edge Server, its own web interface also has a Health section with live values and per-client connection state.
Next Steps
Collected values are kept in the Store stage for every Variable with Store Data enabled. From there you can query them in Platform Explorer (Analyze), put them on dashboards and diagrams (Visualize), generate reports (Report), or pass them on through the API (Integrate). The Platform Overview shows how devices, Variables and assets relate.