Edge Server Health

The Health section is the operator's window into what the Edge Server is doing right now. Four tabs cover the live data flow, the upstream and downstream connection states, and the host process itself.

All four pages share a common header with an Auto-refresh toggle and a manual Refresh button. They all read from local endpoints, so they work even when the cloud connection is down — which makes Health the right place to start when something looks off.

Auto-Refresh

The header above the tabs has a single auto-refresh toggle that applies to all Health pages at once. When enabled, the UI re-fetches Live Values, Client Diagnostics, MQTT Publisher, and System Metrics on a fixed cadence — choose 30s, 1m, 2m, 5m, or 10m from the interval dropdown.

Click Refresh at any time for an immediate pull. While a fetch is in flight, the refresh icon spins and the button is disabled.

Live Values

/health/live-values shows every variable the Edge Server is currently tracking, sourced from all clients plus internal state variables (ISVs).

Columns

• Name — the variable's topic property path.
• Client — the client that produced the value (name and type), or ISV for internal state variables.
• Value — the current value.
• Timestamp — when the value was last observed locally.
• Last Published At — when the value was last published to the cloud (blank if it has never been sent — usually because the deadband and stale rules haven't fired yet).

Filters and search

• A search box matches across name, client, and value.
• Faceted filters for Client Type and Client Name let you focus on a single protocol or a single device.
• Reset clears all filters in one click.

The table is sortable on every column and paginates at 20, 50, or 100 rows per page.

When to use it

• Confirming a newly added variable is reading.
• Comparing the local value against what the cloud is showing — a divergence usually means deadband filtering, a stale-after timer, or a disconnected MQTT publisher.
• Spotting variables that have a recent Timestamp but a much older Last Published At (deadband holding them back).

Client Diagnostics

/health/client-diagnostics shows one row per configured client (Modbus TCP, Modbus RTU, OPC-UA, BACnet, LoRaWAN, MQTT, HTTP, etc.) with its connection state and protocol-specific counters.

• A green dot marks the client as connected; red marks it disconnected.
• Each row carries protocol-specific diagnostic fields supplied by the server — for example, last successful read time, error counts, or last error message.

When to use it

• Triaging "no data from device X": check whether the client is connected, when it was last seen, and whether the error count is climbing.
• Verifying that a configuration deploy actually picked up — disconnected clients you just added usually mean a typo in host/port or a network reachability issue (use the Ping tool to confirm).

MQTT Publisher

/health/mqtt-publisher is a focused view of the outbound MQTT pipeline that ships data to ControlCom Connect.

Fields

• Connection Status — Connected (green) or Disconnected (red).
• Batches Sent — cumulative number of batch publishes since startup.
• Items Sent — cumulative count of individual variable updates published.
• Bytes Sent — cumulative bytes on the wire, with B/KB/MB formatting.

When to use it

• Confirming cloud connectivity from the device side. If the publisher is Connected and Items Sent is growing, the Edge Server is shipping data successfully.
• Estimating the deadband effectiveness: compare Items Sent with the variable count from Live Values over the same interval.
• Detecting silent failures: a Connected publisher with a flat Items Sent counter usually means deadband and stale rules are filtering everything out, not that the device is broken.

System Metrics

/health/system-metrics shows resource usage for the Edge Server process itself.

Fields

• Working Set — resident memory (what the OS reports as in-use), in MB.
• Private Memory — committed private memory, in MB.
• GC Total Memory — managed heap size after the most recent GC, in MB.
• Uptime — process uptime in seconds.
• Thread Count — current managed thread count.

When to use it

• Verifying the container hasn't restarted recently (Uptime should be growing). Frequent restarts usually point at an OOM kill — check container logs.
• Capacity planning: the minimum recommended memory is 256 MB, but a busy device with many clients and high deadband traffic can grow well beyond that. If Working Set is climbing without bound, raise it with your team.
• Confirming a thread leak suspicion: a slowly increasing Thread Count over hours is a smell.