--- title: Edge Server Management description: Manage a ControlCom Gateway\ source: https://documentation.controlcomtech.com/platform/devices/edge-server --- # Edge Server Management Every ControlCom Gateway runs the ControlCom Edge Server, the on-device runtime that connects to your equipment, collects readings and publishes them to the platform. This page covers managing that runtime from the cloud: the gateway's detail page in Device Administration lets you send it lifecycle commands, edit its full configuration, read its logs, and see exactly which Variables and Commands it handles. > **Workflow Stage: Collect** One naming note up front, because both terms appear in the product: the Edge Server runtime is also called the **SDK**. The tab on the gateway's detail page is labeled **Edge Server**, while the editor it opens is titled **SDK Configuration** and the lifecycle commands are SDK commands. They are the same thing. This page uses Edge Server for the software and SDK where the interface does. Everything here assumes the gateway is already registered and its Edge Server is onboarded. [Device Administration](https://documentation.controlcomtech.com/platform/devices/administration) covers registration and certificates, and the [Edge Server getting started guide](https://documentation.controlcomtech.com/build/edge-server/getting-started) covers deploying the runtime on your hardware. For the web interface served by the gateway itself, see the [Edge Server web interface](https://documentation.controlcomtech.com/build/edge-server/web-interface/overview) documentation; this page is about the cloud side. ## SDK Commands The **Details** tab of a ControlCom Gateway carries a **Send command** panel for controlling the Edge Server runtime remotely. Commands are delivered over the device's MQTT session, so the gateway must be connected for them to arrive. ![The Details tab of a ControlCom Gateway showing the Send command panel and the Connection card](https://documentation.controlcomtech.com/images/edge-server-admin/01-gateway-details.png) *The Details tab. The Send command panel on the right controls the Edge Server runtime remotely* | Command | What it does | | ------- | ----------------------------------------------------------------------------------------------------------- | | Restart | Reboots the Edge Server runtime. The configuration is kept; the runtime stops, starts again and reconnects. | | Stop | Halts the runtime loop. Data collection stops until a Start or Restart is sent. | | Start | Resumes a stopped runtime loop. | Restart is the command you will use most: the Edge Server picks up a newly saved configuration when it restarts, so the usual sequence is save on the Edge Server tab, then Restart from Details. A fourth action, **Request data**, appears in the panel but is marked as coming soon. The panel footer counts queued and pending commands and links to the Commands tab, where the gateway's own device Commands live. Those are separate from SDK commands: device Commands write values to your equipment, SDK commands control the Edge Server itself. See [Commands](https://documentation.controlcomtech.com/platform/commands) for the device side. ## Connection Details Next to the command panel, the **Connection** card shows everything the Edge Server uses to reach the platform: the broker endpoint (MQTT over TLS on port 8883), the topic the gateway publishes to, and its client ID. Only one client may hold the MQTT session at a time; a second connection with the same client ID disconnects the first, which is worth knowing when a gateway appears to drop offline as a duplicate connects. The card also holds the **device shared secret**, masked with a reveal toggle and a copy button. The shared secret authorizes access to the gateway's local Edge Server web page and pairs [Edge HMI](https://documentation.controlcomtech.com/platform/devices/edge-hmi) panels with the Edge Server. It complements the device certificates, which authenticate the MQTT connection itself and are managed on the Certificates tab; [Device Administration](https://documentation.controlcomtech.com/platform/devices/administration#certificates-and-credentials) covers certificate rotation. The hero strip and health tiles above these cards fill in once the gateway has connected and reported telemetry. A freshly registered gateway shows its connection as awaiting the first handshake until the Edge Server comes online. ## The Configuration Editor The **Edge Server** tab opens the SDK Configuration editor, the cloud-side editor for everything the runtime does. The configuration lives on the platform: the gateway fetches it, and applies changes on its next restart. ![The SDK Configuration editor on the Edge Server tab, showing the Clients tab with a Modbus TCP client](https://documentation.controlcomtech.com/images/edge-server-admin/02-sdk-clients.png) *The SDK Configuration editor. Six tabs cover clients, edge processing, rules and publisher settings* The editor is split into six tabs: | Tab | Configures | | ----------------- | --------------------------------------------------------------------------- | | Clients | Protocol connections to your equipment: Modbus, OPC UA, BACnet, EtherNet/IP | | Internal State | Values held in the Edge Server's memory for other processors to use | | Virtual Variables | Values computed on the edge from other readings | | Triggers | Automatic command writes when a condition becomes true | | Rules | Inbound listeners, currently the SparkplugB listener | | Settings | How the Edge Server publishes data to the platform | Items in every tab follow the same pattern: an add card creates one, clicking an item opens its editor in a panel on the right, and the item's menu duplicates or removes it. Removal asks for confirmation. The header offers **Export** and **Import** for moving a configuration as JSON, useful for backing one up or copying it between gateways. Import validates the pasted or uploaded JSON and preserves the current gateway's broker URL, topic and client ID, so an imported configuration never points a gateway at another device's identity. **Save Configuration** applies your edits; saving is covered below under [Validation and Saving](#validation-and-saving). ## Protocol Clients Clients are the connections the Edge Server opens to your equipment. **Add Client** offers six protocol types: Modbus TCP, Modbus RTU, OPC UA, BACnet IP, BACnet MSTP and Ethernet/IP. ![The Add New Client dialog listing Modbus TCP, Modbus RTU, OPC UA, BACnet IP, BACnet MSTP and Ethernet/IP](https://documentation.controlcomtech.com/images/edge-server-admin/03-add-client-dialog.png) *The Add New Client dialog. Each client type connects the Edge Server to equipment over a different protocol* A client holds the connection settings for one endpoint (an IP address and port, or a serial port and baud rate) and a list of items, the individual registers, objects or tags to read. Each item maps a protocol address to a platform Variable by its topic property path, with scaling, byte order and deadband options where the protocol calls for them. Items that should accept writes name a **Write Command**, which links them to one of the device's Commands. ![The Modbus TCP client editor panel with connection settings and mapped items](https://documentation.controlcomtech.com/images/edge-server-admin/04-modbus-client-editor.png) *A Modbus TCP client. Connection settings at the top, and one item per register underneath* The per-protocol details, register addressing, OPC UA node IDs, BACnet object types, EtherNet/IP tag paths, are documented in the client guides: [Modbus](https://documentation.controlcomtech.com/build/edge-server/clients/modbus), [OPC UA](https://documentation.controlcomtech.com/build/edge-server/clients/opc-ua), [BACnet](https://documentation.controlcomtech.com/build/edge-server/clients/bacnet) and [EtherNet/IP](https://documentation.controlcomtech.com/build/edge-server/clients/ethernet-ip). ## Internal State, Virtual Variables and Triggers Three tabs configure processing that runs on the gateway itself, between reading a value and publishing it. **Internal State** variables live in the Edge Server's memory. They hold values that other edge processors need, an operator setpoint for example, without creating traffic to the platform. An internal state variable has a type, an optional initial value, and an optional write command so it can be set remotely. **Virtual Variables** compute new values from other readings using an expression, and run on the edge so the result exists even if the gateway is temporarily offline. The output goes either to a platform Variable (by topic property path) or into an internal state variable. These are distinct from the platform's own Virtual Variables, which are computed in the cloud; the edge variant is the right choice when the computed value feeds a Trigger or an Edge HMI locally. ![The Virtual Variables tab of the SDK Configuration editor with a computed delta T variable](https://documentation.controlcomtech.com/images/edge-server-admin/05-virtual-variables.png) *An edge Virtual Variable. The expression is evaluated on the gateway, not in the cloud* **Triggers** watch a boolean expression and write a value to a Command when the expression turns true. The write fires on the transition from false to true, and an optional re-execute interval repeats it while the condition holds. Value on true and an optional value on false define what gets written. Because Triggers evaluate on the gateway, they keep working without a connection to the platform, which makes them suitable for local protective actions such as energizing an alarm relay. The **Rules** tab configures inbound listeners. One rule type exists today, the SparkplugB listener, which maps metrics from SparkplugB devices on your network into platform Variables; it has its own guide at [SparkplugB Listener](https://documentation.controlcomtech.com/build/edge-server/rules/sparkplugb-listener). Expressions, value transforms and the wider edge processing model are covered in [Data Processors](https://documentation.controlcomtech.com/build/edge-server/data-processors). ## Publisher Settings The **Settings** tab controls how the Edge Server publishes to the platform. Its one adjustable value is the **Publish Batch Interval**: how long the runtime batches readings before sending them, from 500 milliseconds to 10 seconds. ![The Settings tab of the SDK Configuration editor with the Publish Batch Interval slider](https://documentation.controlcomtech.com/images/edge-server-admin/06-publisher-settings.png) *Publisher Settings. The batch interval trades network chatter against real-time visibility* The default of 500 ms suits most installations. Raising it reduces the number of MQTT messages, but the editor shows a caution when you do: longer batching uses more memory on the gateway, a large batch can exceed the broker's message size limit and be rejected, and dashboards see values later. Treat a longer interval as a deliberate choice for constrained links, not a default. ## Validation and Saving **Save Configuration** checks your configuration against the device's platform Variables before applying it. A clean configuration asks for a simple confirmation. If problems are found, a dialog titled **Invalid SDK Configuration Detected** lists each one with the variable, the target and the issue, and offers **Save Anyway** alongside Cancel, because sometimes the fix is on the other side (a Variable you are about to create, for example). The checks catch out-of-range Modbus addressing (unit IDs beyond 0 to 255, addresses beyond 0 to 65535, bits beyond 0 to 15), items that reference a platform Variable that does not exist, and two items writing to the same Variable. The same validation runs whenever you open the gateway: if the stored configuration has problems, a banner reading **Improper Configurations Detected on SDK** appears above the tabs on every page of the device, with a **View Details** dialog listing the issues. The banner clears once the configuration is fixed and saved. Saving stores the configuration on the platform and keeps a history server-side. The gateway applies it on its next restart, so follow a save with a Restart from the Details tab when you want the change live immediately. ## Edge Logs The **Edge Logs** tab shows the Edge Server's own log output, shipped from the gateway to the platform, one stream per day. ![The Edge Logs tab listing one Edge Server log stream per day](https://documentation.controlcomtech.com/images/edge-server-admin/07-edge-logs-streams.png) *Edge Server log streams. Each entry is one day of runtime logs* Selecting a stream opens the log viewer for that day. The viewer shows each entry with its timestamp, severity badge, source context and message, and offers a search box plus quick time range presets from the last 24 hours down to the last minute. **Refresh** re-reads the stream. ![The Edge Logs viewer showing timestamped Edge Server log entries with severity badges](https://documentation.controlcomtech.com/images/edge-server-admin/08-edge-logs-viewer.png) *The log viewer. Connection events, polling activity and warnings from the runtime, without SSH access to the gateway* The logs here are the same ones visible on the gateway's local web interface under [Live Logs](https://documentation.controlcomtech.com/build/edge-server/web-interface/tools/logs), with one difference in reach: this tab works from anywhere, which makes it the first stop when a remote gateway misbehaves. Look for the connection lines after a restart, and for client warnings such as read timeouts against a PLC. ## Edge Server Flags The gateway's **Variables** and **Commands** tabs know what the Edge Server configuration references, and mark it. On the Variables tab, a variable written by the Edge Server carries an **ES** flag. Hovering it lists the writers: the client item, edge Virtual Variable or rule mapping that produces the value. If the writer is currently disabled in the configuration, the flag says so, which is a quick way to spot why a variable stopped updating. An **Edge Server** filter narrows the list to variables written by the Edge Server, or to those that are not. ![The Variables tab of a ControlCom Gateway with ES flags marking variables written by the Edge Server](https://documentation.controlcomtech.com/images/edge-server-admin/09-variables-edge-flags.png) *ES flags on the Variables tab. Each flag traces back to the configuration entry that writes the variable* The Commands tab does the same for writes in the other direction: a Command whose topic suffix matches a write command in the configuration carries the **ES** flag, and its tooltip names the handler, whether that is a client item, an internal state variable, a trigger or a rule mapping. A Command without the flag is not wired to anything on the edge, which usually means the write command name in the configuration does not match the Command's topic suffix. ![The Commands tab of a ControlCom Gateway with ES flags marking commands handled by the Edge Server](https://documentation.controlcomtech.com/images/edge-server-admin/10-commands-edge-flags.png) *ES flags on the Commands tab, with the Edge Server handler for each command* Access to this area is governed by the Edge Server permissions in the Devices feature group (reading and changing the configuration, and reading Edge Logs), assignable per role under [Team & Roles](https://documentation.controlcomtech.com/platform/team). ## Where This Fits Configuring the Edge Server is the heart of the Collect stage: the gateway was registered in the Connect stage through [Device Administration](https://documentation.controlcomtech.com/platform/devices/administration), and the clients, processors and publisher settings on this page determine what data flows from your equipment into the platform. Once the configuration is saved and the runtime restarted, readings are Stored and appear under the device's Variables, ready for the Analyze stage in [Platform Explorer](https://documentation.controlcomtech.com/platform/explorer) and the Visualize stage in [Dashboards](https://documentation.controlcomtech.com/platform/dashboards/overview) and [Diagrams](https://documentation.controlcomtech.com/platform/diagrams-detail/overview). The [Edge Server getting started guide](https://documentation.controlcomtech.com/build/edge-server/getting-started) covers the deployment side, and the per-protocol client guides cover addressing details for [Modbus](https://documentation.controlcomtech.com/build/edge-server/clients/modbus), [OPC UA](https://documentation.controlcomtech.com/build/edge-server/clients/opc-ua), [BACnet](https://documentation.controlcomtech.com/build/edge-server/clients/bacnet) and [EtherNet/IP](https://documentation.controlcomtech.com/build/edge-server/clients/ethernet-ip).