Street lighting remote management: from luminaire to maintenance
Separate luminaire control, communications and operating procedures before expanding an installation.
What remote management enables
Street lighting remote management allows operators to monitor luminaires and send switching, dimming and scheduling commands remotely. It combines a controller at the lighting point, communications and a management platform. The Lux AITHA lighting solution applies this architecture using Zhaga Book 18, DALI and LoRa or NB-IoT variants, selected for the installation.
Monitoring and control are different activities. Monitoring collects available device information and helps identify incidents; control sends a command whose execution needs verification. A screen displaying a requested dimming level does not necessarily prove that the luminaire applied it. The project should distinguish the request, its confirmation and any observed state rather than displaying them as equivalent evidence.
Information supports maintenance only when it has context. A point without communication may still be illuminating; a communicating luminaire may have a driver or power problem. Associating the device with its location and history avoids treating every missing report as an electrical failure. It also helps the crew prepare the right tools and identify the equipment before travelling.
Energy savings depend on lighting design, schedules, permitted dimming and previous operation. Connecting luminaires alone cannot responsibly be associated with a universal savings percentage. Evaluating the outcome requires a comparable baseline, a measurement period and rules that preserve the lighting requirements of the public space. A useful pilot records those assumptions instead of leaving them implicit.
Luminaire interface and communication network
Zhaga Book 18 and DALI address different parts of the installation. The former describes a connection interface for modules on outdoor luminaires; DALI enables commands and data exchange with compatible equipment. The socket, available power supply and driver capabilities must be checked together. Having the connector does not automatically certify the assembled installation or establish support for every diagnostic function.
Both Lux AITHA variants share the Zhaga Book 18 interface and DALI control. Lux AITHA LoRa uses its own private network at 868 MHz in the EU, not LoRaWAN. Router LoRa is separate from the luminaire and connects that device network to AITHANEX or the system specified for the project. Its location and backhaul are separate installation decisions.
Lux AITHA NB-IoT uses mobile connectivity per point. Before selecting it, confirm compatible coverage and service with the operator at the site. A general coverage map cannot replace testing the actual module, antenna and configuration. The LoRa variant also requires link measurements and suitable infrastructure locations; neither architecture makes local radio conditions irrelevant to a reliable deployment.
Prepare a representative pilot
A pilot should include streets and locations representing real difficulties: distance, obstacles, installation height and access conditions. Selecting only favourable points creates a demonstration, not a sufficient basis for expansion. The inventory should record luminaire model, driver, connection, position and installed device, using identifiers that the maintenance team can recognise and keep consistent with its existing asset records.
Tests start with the basics: switch on, switch off, dim and apply agreed schedules. Then check information reception, incident identification and the response to communication loss. Each test needs an expected result, evidence and a person responsible for acceptance. Otherwise, two teams can interpret the same behaviour differently and approve a pilot without agreeing what successful operation actually means.
Recovery deserves testing alongside normal operation. Review which information is retained, which commands may remain pending and what happens when the connection returns. Document a manual procedure for periods without communication. The safety and continuity of lighting should not depend on improvisation during an incident, especially when a crew must intervene outside the hours of the technical support team.
Decide whether to expand
Expansion should follow observed results: adequate communication for the intended use, verified control, incident traceability and acceptance by maintenance staff. Thresholds belong to the project rather than a generic catalogue promise. Record exceptions and locations that need a different approach before approving the next group of lighting points. Unresolved exceptions should remain visible in the acceptance record.
Operation also requires identifying who changes schedules, who authorises dimming and who receives alerts. A change log helps investigate incidents and distinguish an authorised modification from a fault. Integrating information into the maintenance workflow may provide more value than adding another dashboard that nobody consults during the working day. Ownership of the workflow matters as much as receiving the data.
Published specifications must be checked against the proposed version. The Lux AITHA technical datasheet describes the product variants; Zhaga and the DALI Alliance explain the general interfaces. Declared compatibility, certification and validation of a particular installation are different kinds of evidence and should not be presented as interchangeable guarantees.