Edge controller setup
Preparing a private gateway or edge controller: local power, local interface, node registry and the order in which a site is brought up without depending on the uplink.
| Document revision | r0.1-draft |
|---|---|
| Status | draft |
| Applies to | LS-GW-100, LS-GW-300 |
| Regions | global |
| Published | Oct 15, 2026 |
| Review due | Apr 15, 2027 |
| Author | Engineering documentation (owner unassigned) |
| Reviewer | Engineering sign-off pending (reviewer unassigned) |
The gateway is the device the site depends on, so it is configured to be useful before it is ever connected to an uplink. This document describes the setup order and the checks that prove the site is genuinely local-first; it does not reproduce the device's parameter list, which lives on the model page and in the datasheet.
Preconditions
- The gateway's mounting position has been chosen for radio coverage, per Reference topology, and it has a local power source independent of any WAN equipment.
- The intended node list is known, so the registry can be built deliberately rather than discovered.
Setup sequence
1. Power the device locally and confirm local access
Power the gateway from its own local source and confirm it answers on its local interface with the uplink physically disconnected. This is a precondition, not an optimisation: a gateway that only appears once the WAN is present has not been shown to run offline.
2. Set the device identity and time base
Set the device's own identity and confirm its time base before building any schedule. A schedule resolved against a drifting clock will fire at the wrong time and be mistaken for a rule-engine fault.
3. Build the node registry
Add endpoints to the registry in the order they are paired. The registry — not the radio advertisement — is the list the site acts on, so an endpoint that is reachable but not registered behaves unpredictably.
4. Define local policy
Create schedules, scenes and alarms on the device and mark which of them must resolve locally. Anything that must survive an uplink loss has to be resolvable on the edge. See Failover and local policy.
5. Prove the local path with the uplink absent
With the uplink disconnected, run one schedule that includes a real endpoint and confirm it executes and is logged locally. Only after this check should the uplink be enabled.
6. Enable the uplink and optional field protocols
Enable outbound connectivity last. Cloud management is optional and management-only; field protocols on an edge controller are configured after the local path is proven, so a protocol fault cannot be confused with a local-policy fault.
Failure modes
- Time drift: schedules fire late or not at all after a power event; verify the time base before editing rules.
- Registry mismatch: an endpoint paired on the radio but absent from the registry will not appear in scenes or logs.
- Rule resolved remotely: a rule that behaves differently with the uplink up is being evaluated in the cloud; move it to the edge.
- Protocol enabled before the local path is proven: a field-protocol fault masks the local behaviour; keep the order above.
Placeholder — pending engineering sign-off: the gateway's default port assignments, local-interface addressing scheme and the registry capacity are not published yet and are set per SKU generation.
Limitations
LS-GW-100andLS-GW-300differ in their field-protocol and historian behaviour; do not apply a step that assumes an edge controller to the compact gateway. Check the model page for which capabilities exist on your revision.- Capacity is bounded by air-time and by the reporting interval you configure, not by a fixed node number. There is no maximum node count published here.
What this document does not cover: the API and event shapes are documented in API and webhooks, and field-protocol configuration is in MQTT, Modbus and BACnet.