No gateway. No connection. Still under control.
Some places will never have a backhaul, and some sites are not allowed one. The nodes keep their own clock, their own profiles and their own rules, and a panel on site puts a person in charge of them.
Solar pole with local control — installed site
Where it is the right answer.
Not a downgrade of the connected system — a different problem, with a different economics.
Isolated stretches
Cycle paths, country roads and lots where a gateway would cost more than the lighting it serves.
Solar poles
Standalone by definition: the node manages the profile against the charge available, not against a schedule someone forgot.
Sports fields and venues
Lit only when used, switched by whoever is on site, with scenes instead of a panel of breakers.
Sites with no external link
Where the requirement is written as a constraint: nothing connects out, and the lighting still has to behave.
The rules live in the node.
Each node carries a real-time clock, a photocell input and a position from GNSS. That is enough to switch correctly for years without anything above it.
Astronomical switching
Sunrise and sunset computed from the node's own position, with the time kept by GNSS — no drift, no seasonal reprogramming, no photocell to clean.
Local dimming profiles
Levels by hour and by calendar, stored in the node and applied whether or not anything else is listening.
Light that comes up
A radar on the stretch raises a whole group as someone approaches, then lets it fall back — the useful part of "light on demand", without a sensor on every pole.
A panel on the wall, not a login somewhere.
A 10.1″ industrial touch panel drives the nodes over the mesh from inside the site: groups, scenes, manual override and schedules, with no cloud behind it. Where a connection exists it can be used as well — but nothing depends on it.
Pitch, stands, car park, perimeter — each as a button rather than a row of breakers.
Whoever is on site wins: the panel takes priority over the schedule, and puts it back afterwards.
Where cameras or third-party sensors can publish events over MQTTS, they can trigger a lighting behaviour locally — an integration configured per site.
iLCS-HMI2020-Touch — the panel that drives the nodes over the mesh
One site's screen — areas, groups, current state, next booking
The screen is the site, not the wiring.
Areas and groups are named the way the people on site talk about them, and each one shows what it is doing now and what is scheduled next. The status line in this screenshot reads gateway offline: the panel is commanding the luminaires over the mesh, with nothing above it.
The touch panel in full →What you give up without a gateway.
We would rather write it here than let you discover it after the installation.
| Standalone | With a gateway | |
|---|---|---|
| Astronomical switching and profiles | Yes | Yes |
| Presence reaction on the stretch | Yes | Yes |
| Remote command and monitoring | On site only | Yes |
| Faults and energy in the platform | No — read on site | Yes, per luminaire and per hour |
| Firmware updated over the air | Locally | Over the network |
| Adaptive operation to a lighting class | No — it needs measured traffic and luminance | Yes |
A standalone site can be connected later: the nodes are the same, and adding a gateway turns the installation into a monitored one without touching the poles.
Describe the site and the constraint.
How many luminaires, whether there is mains power, and whether anything is allowed to connect out. That decides between a standalone site, a panel on the wall and a gateway.