Three layers, and none of them depends on the other being awake.
The street decides, the network carries, the cloud remembers. If the link drops, the first two keep working — which is the only reason a lighting system can be trusted at three in the morning.
Decides on the street
Nodes on the luminaires and controllers in the cabinets run their own logic: dimming classes, schedules, alarms and safety fallbacks, with signed firmware and hardware security.
How iLCS works →
A mesh you own
IEEE 802.15.4 at 2.4 GHz: every device is a node and a repeater, a few gateways carry the data out, and there is no SIM card or subscription per lamp.
The mesh network →
Your data, exportable
Map, history, reports and alarms — hosted in your country or on your own servers, with open interfaces and export in standard formats.
iLCS Cloud →
What this buys you, in practice.
Three consequences that show up in the budget and in the service, not in a datasheet.
Instead of a thousand SIM cards and a thousand subscriptions to renew.
Configuration changes reach a group in seconds and every device is refreshed at least once a minute. Networks designed for battery meters speak a few times a day; adaptive lighting cannot work that way.
The dimming decision is taken on the network itself: a lost internet link does not stop the lighting.
One network, or one system per service.
The usual way to digitise infrastructure is a platform for the lights, SIM cards for the sensors and something else for the cabinets. Here is what changes when they share one network.
| The usual approach | iLCS | |
|---|---|---|
| The network | One per service — a system for the lights, SIMs for the sensors, another for the cabinets | One wireless network in the field, every service on it |
| How often a device speaks | A few times a day — networks designed for battery meters | Real time — commands in seconds, every device refreshed at least once a minute |
| Where decisions are taken | In the cloud: no link, no control | At the edge — the site keeps working offline |
| Adding a service | A new system, a new contract, a new portal | A sensor on a node that already has power and coverage |
| The electrical cabinet | Out of scope, or a black box | Measured, alarmed and switched — specifications published |
| The data | One portal per service, export on request | One data model, one map, open interfaces, your hosting |
Go deeper
How iLCS works →
From the sensor on the pole to the report in the platform.
TechnologyMesh network →
Why a network of our own, and what the alternatives cost.
TechnologyIntegrations & APIs →
Modbus, LoRaWAN, third-party sensors and your own systems.
TechnologySecurity →
Encryption, signed firmware, TPM 2.x, hosting and access.