Skip to content

Control lock

Radosław Kubera edited this page Oct 16, 2026 · 4 revisions

lock control

Control catalogue · Documentation home

Portal lock control

Minimal field JSON:

{
  "id": "lock",
  "type": "lock",
  "name": "Lock"
}

Full field JSON:

{
  "id": "lock",
  "type": "lock",
  "name": "Lock",
  "default": "LOCKED",
  "controls": [
    {
      "key": "",
      "type": "action",
      "label": "ui_122",
      "command": "",
      "payload": "LOCK"
    },
    {
      "key": "",
      "type": "action",
      "label": "ui_123",
      "command": "",
      "payload": "UNLOCK"
    },
    {
      "key": "",
      "type": "action",
      "label": "ui_117",
      "command": "",
      "payload": "OPEN"
    }
  ],
  "ha": {
    "command_topic": "$command",
    "state_topic": "$state",
    "payload_lock": "LOCK",
    "payload_unlock": "UNLOCK",
    "payload_open": "OPEN"
  }
}

Properties in the full example:

Property Required? Meaning / default
id Required Stable application key; unique across registered pages.
type Required Enabled field type.
name Required title¹ Display title; may be replaced by a nonempty names object.
default Optional Omit to use the built-in initial value.
controls Optional Omit to use the preset controls; supplying an array replaces them.
ha Optional Omit to use automatic HA discovery; supplied properties override defaults.

¹ name can be replaced by names. Other shared optional properties are listed in the catalogue.

The control provides Lock, Unlock and Open buttons. Default reported state is "LOCKED"; action payloads are LOCK, UNLOCK and OPEN on the base topic. Report LOCKED, LOCKING, UNLOCKED, UNLOCKING or OPEN as appropriate. Button matching ignores letter case. The raw state string is hidden in the portal; button highlighting follows reported state, not merely the click.

Integration with Home Assistant

MQTT component: lock. Requires the control’s feature flag, dynamic pages, MQTT and HA support to be enabled. ArdPortal registers MQTT Discovery and routes state/commands; the sketch implements device behavior. Action callbacks acknowledge acceptance, not physical completion.

Supported by ArdPortal: LOCK, UNLOCK and OPEN action callbacks, with separately reported string lock state on the state topic. The preset supplies the corresponding command payloads.

Not provided by the built-in integration / limits: No PIN collection/validation, user-code database, auto-relock timer, actuator driver or door-contact integration. Actions do not automatically prove or change the reported lock state.

Explicit ha properties can override Discovery metadata. They do not create additional hardware behavior, application value properties or command handlers by themselves. See HA integration for the shared setup.

Integration with Zigbee

Native mapping: Door Lock (0x0101). Requires ESP32-C5/C6/H2, ARDPORTAL_ENABLE_ZIGBEE=1, enabled dynamic pages and the control’s feature flag, with the matching End Device/Router board mode. MQTT/HA is not required. Register the initial pages before endpoint startup; later endpoint changes require restart. persist retains its AppConfig meaning.

Supported by ArdPortal: Lock/unlock commands and basic lock-state reports; LOCKED maps to locked, UNLOCKED and OPEN map to unlocked.

Not provided / limits: No distinct OPEN/unlatch command, PIN/user-code management, door-state reporting or automatic relock. OPEN cannot be distinguished from UNLOCKED in the reported Zigbee lock state.

visibleWhen does not dynamically add/remove Zigbee endpoints: they remain registered, and Zigbee commands remain accepted regardless of field visibility. Gateway presentation depends on its support for the mapped clusters. ArdPortal can export a Zigbee2MQTT converter or ZHA quirk; see the validation scope.

See Zigbee integration for pairing, endpoint lifecycle, gateway limitations and OTA requirements.

Read and update values from C++

These examples use the field ID from the JSON above and an existing ArdPortal portal. Run them after page registration has finished and portal.portalAndAppConfigReady() is true. Call portal.loop() frequently. Register callbacks once in setup(); do not repeat setters on every loop iteration.

Set the value with automatic ArdFS persistence

Set "persist": true on this field in its page JSON. It is optional for editable fields whose preset already persists settings, but required to override a RAM-only preset such as a sensor. Calling setAppConfigValue() sets the control value and ArdPortal automatically saves AppConfig through its integrated ArdFS storage. Do not create an ArdFS object or call a separate write/flush method. The automatic save is coalesced and advanced by subsequent portal.loop() calls.

// Use this path when the value is a setting that should survive restart.
ArdJSON::JSONVar next = "LOCKED";
if (!next.isValid() || !portal.setAppConfigValue("lock", next)) {
  Serial.println("Setting rejected or storage temporarily unavailable");
}

true from the setter means acceptance, not a completed flash write. Configure this callback once to observe the result:

portal.onPortalAndAppConfigSaved([](bool ok, const String& error) {
  if (!ok) Serial.println(error);
});

Update only RAM

// Use this alternative for live readings/status; never writes ArdFS.
ArdJSON::JSONVar next = "LOCKED";
if (!next.isValid() || !portal.setAppConfigStateValue("lock", next, false)) {
  Serial.println("Runtime value rejected");
}

The third argument false avoids queuing an immediate MQTT publication. Use true or omit it to queue changed state. RAM updates work regardless of persist. Alternatively, with "persist": false, setAppConfigValue() also follows the RAM-only path.

Read the current value

const ArdJSON::JSONVar current = portal.getAppConfigValue("lock");
if (!current.isUndefined() && current.isValid()) {
  Serial.println(ArdJSON::JSON.stringify(current));
}

The getter returns the effective field value: RAM override first, then saved AppConfig, then the definition default. A RAM-only update is lost on restart; the saved value/default becomes effective again. Choose the persistent or RAM path for a given value. A RAM override can mask a later persistent change for the same ID; there is no API to clear just that override. Prefer separate setting and telemetry IDs when both are needed.

Back to control catalogue

Clone this wiki locally