Overview

This page collects real-world Configuration Schema patterns. Each use case pairs the JSON Schema you set on the model with the device-side set-config payload that drives it, so you can adapt a working example instead of building from scratch.

Hiding fields until the device reports a capability

Some models ship with optional or removable hardware — for example a Wi‑Fi card that a technician can pull out. When that hardware isn't present, its configuration fields (Wi‑Fi MAC, SSID, etc.) should disappear from the UI instead of showing empty or misleading values.

The device itself knows whether the hardware is installed, so let the device drive visibility. It reports a boolean capability flag via set-config, and the schema reveals the related fields only when that flag is true.

How it works

• A conditional (if / then) block is keyed on a boolean flag the device reports — here wifi_installed.
• The flag is kept invisible at all times by giving it no title and listing it under required inside the if. Because it is only referenced (never declared as a titled property in the visible tree), it never renders as an input — it exists purely as schema logic.
• Xyte's config editor requires every property to be wrapped in an object. Wrapping the conditional in an object property (wifi) with an empty "title": "" satisfies that rule while keeping the wrapper header hidden — this also clears the validation error you get when pasting a bare conditional into the model's Config Schema.
• When the Wi‑Fi card is removed, the device reports wifi_installed: false (or omits it) and the Wi‑Fi settings vanish. When the card is back in, it reports true plus the values, and the settings reappear. Nothing is toggled manually in the UI.

📘

Why not a hidden flag?

JSON Schema has no standard hidden keyword, so a property marked "hidden": true still renders. Referencing the boolean only inside if + required is what keeps it out of the UI while still available for logic.

Config Schema

{
  "type": "object",
  "properties": {
    "network": {
      "$id": "#/properties/network",
      "type": "object",
      "title": "Network",
      "properties": {
        "eth_mac": {
          "$id": "#/properties/network/properties/eth_mac",
          "type": ["string", "null"],
          "title": "LAN MAC Address",
          "readOnly": true
        },
        "wifi": {
          "type": "object",
          "title": "",
          "properties": {},
          "if": {
            "properties": {
              "wifi_installed": {
                "const": true
              }
            },
            "required": ["wifi_installed"]
          },
          "then": {
            "properties": {
              "wifi_mac": {
                "$id": "#/properties/network/properties/wifi_mac",
                "type": "string",
                "title": "WiFi MAC Address",
                "readOnly": true
              }
            }
          }
        }
      }
    }
  }
}

What the device reports

The device sets its configuration through the Set Config endpoint. The payload mirrors the schema's structure, so wifi_installed and the Wi‑Fi fields live inside the network.wifi object.

{
  "network": {
    "eth_mac": "11:22:33:44:55:66",
    "wifi": {
      "wifi_installed": true,
      "wifi_mac": "AA:BB:CC:11:22:33"
    }
  }
}

{
  "network": {
    "eth_mac": "11:22:33:44:55:66",
    "wifi": {
      "wifi_installed": false
    }
  }
}

With the card present the WiFi MAC Address field shows in the model's config UI; once the device reports wifi_installed: false, the field is hidden automatically.