Diagnosis checklist

Diagnosis is an ordered narrowing, not a list of guesses. The order below starts at the load and the power and works outward to the rule, because most reported faults are decided before the radio is involved at all. Each step ends in a yes/no fact, and moving on before establishing it is what turns one fault into three.

Preconditions

• The affected endpoint's identity in the registry and the physical circuit it controls are both known.
• The site's revision record is available: document revision, installed firmware revision, and the model page's stated limits.

Isolation order

1. Is the load itself healthy?

Confirm the circuit has power and the load is intact independently of the control system. A control fault and a supply fault look identical from a switch that will not respond.

2. Can the endpoint act locally?

Operate the endpoint at the device — a wall button, a manual override, a dry-contact input. If it acts locally, the endpoint and the load are healthy and the fault is upstream; if not, the fault is at the device.

3. Is the endpoint in the registry?

Confirm the endpoint is present in the committed registry with the identity the rules expect, per Pairing and addressing. Reachable-but-unregistered is the most common "device works but rules ignore it".

4. Does the gateway resolve the rule locally?

Disconnect the uplink and repeat the failing action, per Failover and local policy. If behaviour changes with the uplink removed, the fault is in where the rule resolves, not in the radio.

5. Does the link close now?

Re-measure the link at the endpoint's installed position, with its enclosure and antenna in place. If the link stopped closing after a change to the building or the mounting, the fault is the link and the remedy is placement, not power. See Coverage and site survey.

6. Is the interface the consumer uses mapping the right point?

If a building system reports a wrong or stale value, confirm the mapping against the authoritative definitions in contracts/openapi.yaml, not against a remembered register offset. See MQTT, Modbus and BACnet.

7. Did the fault begin after a change?

Compare the revision record against the time the fault started. A fault that began at an update is a revision question first (Firmware update) and a hardware question second.

Failure modes

• Two faults confused as one: a link fault and a registry fault are frequently present together; isolate them one step at a time.
• Intermittent link treated as a rule fault: retries can make an intermittent link look like a rule that "sometimes runs late".
• Stale value treated as a mapping fault: confirm whether the point is published on change before editing the map.

Limitations

• The steps above describe the order of isolation, not a parameter set. Where a numeric threshold would help, it is not published here, because an unreviewed threshold is worse than no threshold.
• The checklist covers a single-gateway site. A multi-gateway hand-off fault needs the addressing decision from the topology documents, which this page does not make.

What this document does not cover: the security causes of unexpected behaviour, such as an exposed local interface or a sharing rule, are in Hardening and access, and the lawful band and electrical constraints that can also explain an intermittent site are in Radio and electrical routes.