Technology

Open where it matters: the driver, the field bus, your systems.

A platform you cannot leave is not a platform. iLCS uses standard interfaces towards the luminaire, takes in third-party devices over the usual field protocols, and hands your data to your own systems in formats you already read.

Gateway antennas mounted on a wall with the cabling

Site gateway — installed site

Three directions

Downwards, sideways and upwards.

Interoperability is not one property. It matters in three different places, and a system can be open in one and closed in the others — so we list them separately.

01 · Towards the luminaire

Standard sockets, standard drivers

Zhaga Book 18 and NEMA ANSI C136.41 sockets DALI-2 / D4i (IEC 62386), including driver data from parts 251, 252 and 253 0–10 V, PWM and relay for older or simpler gear Any certified D4i luminaire, from any manufacturer

This is the level where a closed system traps you into one catalogue of luminaires. Ours does not.

02 · Towards field devices

The protocols a site already speaks

Modbus RTU and TCP — meters, analysers, inverters, plant equipment M-Bus and pulse inputs — water, gas and heat meters OPC-UA towards industrial systems LoRaWAN — third-party sensors through our gateway or your network server Digital and analogue I/O for anything that only offers a contact OCPP or Modbus TCP for charging points

The cabinet controller is the site integrator: what it can read, the platform can store, chart and alarm.

03 · Towards your systems

Your data, in your tools

REST API with authenticated access MQTT / MQTTS and Kafka for real-time streams ODBC / JDBC, SFTP for scheduled exchanges Export in CSV, XLSX, PDF and KML — the device map included SAML 2.0 / OIDC single sign-on and MFA towards your identity provider Logs towards a SIEM

Including the export you would use on the day you decide to leave. That is the point of it.

How an integration is built

A connector, not a custom project each time.

Each source is wrapped in a connector that extracts, converts units and loads into one data model. Periodically, on an event, or on request.

01 · Read

The gateway or the cabinet controller talks to the device in its own protocol, on site.

02 · Normalise

Units, scales and timestamps are converted so a reading means the same thing wherever it came from.

03 · Store

Everything lands in one history with a place, a time and a unit — which is what makes cross-service reports possible.

04 · Serve

Out through the API, the stream or the export — and onto the same map as the lighting.

One thing to be clear about

The nodes run on our mesh, and that is the point.

Our luminaire nodes speak standard interfaces towards the luminaire, so any D4i driver from any manufacturer works. On the radio side they run our own mesh, and they do not share it with another vendor's controllers.

Because the network has to be fast

Reaching every device in real time, deciding a lighting class at the roadside and applying it across a group in milliseconds needs the radio, the routing and the firmware designed together. A generic control network cannot do it, which is why nobody does adaptive lighting on one.

What actually protects you

Not interchangeable radios — a standard socket, a D4i driver, an open API and an export in standard formats. Those keep your luminaires, your data and your next tender free, which is what a lock-in clause is really about.

And everything above it is open

The field network is ours; the interfaces around it are not. Modbus, M-Bus, OPC-UA, LoRaWAN and OCPP come in; REST, MQTT, Kafka, ODBC, SFTP and standard exports go out.

Name the system you need to talk to.

A GIS, a BMS, an ERP, a city platform, a meter you already own. We will tell you which interface fits, and whether it is configuration or development.

Talk to an engineer