Local Commands

/settings/commands controls who is allowed to invoke each command on this Edge Server. The commands themselves — what they write, to which device, with what value — are defined in ControlCom Connect. This page is purely a security policy layer on top of them.

What Local Commands Are

A "command" in the ControlCom platform is a server-side action that writes a value to a destination (Modbus register, OPC-UA node, BACnet object, MQTT topic, etc.). Commands are usually invoked in one of two ways:

  • Locally — by an HMI or operator UI that sits on the same network as the Edge Server and POSTs to the public REST API on port 3041.
  • Remotely — by the ControlCom Connect cloud platform, typically as the action half of an alarm, schedule, or trigger.

For every configured command, you decide whether local callers must present a valid JWT and whether remote triggering by the cloud is allowed at all.

The Commands Table

The page lists one row per configured command:

ColumnNotes
NameThe command's friendly name from platform configuration.
TypeCommand kind (action, macro, etc.).
Topic SuffixThe MQTT topic suffix the command publishes on.
Auth RequiredToggle controlling local-caller authentication.
Remote ExecutionToggle controlling whether the cloud may trigger this command.

Rows with unsaved changes are highlighted, and a counter badge in the header tracks how many edits are pending.

Auth Required

When Auth Required is on, local callers (HMIs, scripts, custom UIs on the LAN) must include a valid JWT — typically the same admin token used by the Edge Server's own UI. When off, the command is callable by anything that can reach port 3041.

Use cases

  • Auth Required = on is the safe default for any command that does something physical: opening a valve, starting a pump, writing a setpoint.
  • Auth Required = off is appropriate for read-only or visual commands — for example, blinking an indicator light from a kiosk that has no login flow.

Remote Execution

When Remote Execution is on, the cloud platform may trigger the command (as part of an alarm action, a scheduled job, or a trigger). When off, the cloud cannot invoke it under any circumstance, even if a platform-side rule references the command.

Use cases

  • Remote Execution = on for anything the cloud is supposed to orchestrate — automated responses to alarms, scheduled setpoint changes, remote acknowledgements.
  • Remote Execution = off for commands that must be initiated by a human on-site — emergency stops, manual overrides, commissioning routines. This is a hard interlock: even an attacker who compromised the cloud account cannot push the command.

Bulk Toggles

Two pill-style toggles in the top right apply to all rows at once:

  • Auth Required (all) — flips every command's Auth Required to match.
  • Remote Execution (all) — flips every command's Remote Execution to match.

If the rows are inconsistent (some on, some off), a Mixed indicator is shown on the bulk control. Toggling a bulk control only updates rows that don't already match the target value, so the pending-changes count reflects the real diff.

Saving Changes

Toggles are local until you commit them:

  • Save — writes every pending change to the server in one request. The changes apply immediately.
  • Reset — discards pending changes and reloads the current state.
  • Refresh — pulls the latest state from the server, useful if someone else updated the same settings from another session.

Was this page helpful?