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:

Column	Notes
Name	The command's friendly name from platform configuration.
Type	Command kind (action, macro, etc.).
Topic Suffix	The MQTT topic suffix the command publishes on.
Auth Required	Toggle controlling local-caller authentication.
Remote Execution	Toggle 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.