Why Monitoring Changes a Solar Street Light Project
A grid-connected street light fails loudly. A solar street light fails quietly: nothing is reported, the road simply goes dark, and the first signal is often a resident's complaint. Remote monitoring closes the gap between failure and discovery, and it gives you evidence when a warranty question arises.
The trend is not hypothetical. Los Angeles maintains more than 220,000 streetlights and approved a $65 million programme in 2026 to convert eligible units to solar, with copper-wire theft named as a leading cause of outages on the existing network. Wherever cable and battery theft, remote sites or thin maintenance budgets are in play, monitoring moves up the specification. The practical question is not whether to monitor, but what to write into the tender, because the clauses you omit are the ones you cannot buy later.
The Data Layer: What a Monitoring System Should Report
Monitoring is a set of measurements plus a way to act on them. For each luminaire, ask for battery state of charge, charge and discharge current, voltage and temperature, photovoltaic current and voltage, load power, the dimming level in force, and device online status.
Each of those values answers a different question in the maintenance queue. Photovoltaic current and voltage tell you whether the panel is producing, shaded or dirty, and a sudden drop to zero during daylight hours is the classic signature of a cut cable or a removed panel. Load power and the actual dimming level in force confirm the luminaire is doing what the profile says. LED driver status and controller status separate a dead light from an empty battery, which is the single most useful distinction when a technician is deciding what to load in the van.
Separate polling from alarms, because they cost different amounts of engineering. Polling is the history you read when something is wrong. Alarms are the events that must reach a person within minutes or hours, and they are the part with a contractual consequence: PV loss, battery undervoltage, load failure, charge failure and controller offline. A system that logs data but cannot route an alarm to a named phone is a reporting tool, not a monitoring system. Note too that a light going offline is the primary theft and tamper signal on an unattended off-grid asset, so the offline alarm deserves a defined response time before you ever need it.
Three Connectivity Architectures and the SIM Math
There are three ways to connect a solar street light: a cellular module in every luminaire, a low-power wide-area cluster such as LoRa or NB-IoT behind a gateway, or local-only Bluetooth and Wi-Fi access. They differ far more in running cost than in hardware cost.
The first option, a cellular module in every luminaire, is typically an LTE Cat-1 or Cat-M unit with its own SIM. Every light is an independent node, coverage depends only on the mobile network, no gateway is needed, and commissioning happens per unit. The second option, an LPWAN cluster, puts a radio node in each luminaire and a concentrator or gateway at the end of the group; one SIM serves the whole cluster, but radio range, node capacity and local topology now matter, and a gateway failure is a network event rather than a single-lamp event. The third option, local Bluetooth or Wi-Fi access, is used for commissioning and read-out without any recurring data cost.
| Architecture | Hardware per pole | Recurring data cost | Main risk | Fits |
|---|---|---|---|---|
| Cellular per luminaire (LTE Cat-1 / Cat-M) | Controller plus modem and SIM in each unit | One data plan per light | Recurring SIM cost grows with fleet size; coverage depends on local networks | Distributed sites, scattered poles, no line of sight between lights |
| LPWAN cluster (LoRa / NB-IoT) with gateway | Radio node per light plus one gateway per cluster | One data plan per gateway | Gateway placement, node capacity and radio obstruction must be engineered | Dense corridors, industrial estates, long linear roads |
| Local access only (Bluetooth / Wi-Fi) | Local radio in each unit | None | No remote alarm; someone must visit to read the data | Small installations, commissioning, one-year pilots |
Do the SIM arithmetic before you choose, because it usually decides the architecture. Multiply the monthly data plan by the number of lights and by the service life you are asking the client to fund, then compare that figure with the cost of gateways, the extra network engineering, and the electrical load of a radio on every pole. Ask for the average monthly data volume per node in writing, and for the gateway node capacity in a real deployment rather than in a laboratory. Our inverter and grid-hybrid guide covers the related question of what changes when a solar luminaire is tied into a wider electrical system instead of standing alone.
Interfaces: What the Controller and the Luminaire Must Expose
Connectivity only works if the hardware has somewhere to plug in. Mains-powered roadway luminaires use locking receptacles: ANSI C136.41 defines three power contacts plus four dimming and signal contacts, and Zhaga Book 18 defines a standardised receptacle for a plug-in sensing or communication module.
Those two interfaces are what allow a city to add a controller to a luminaire that shipped without one. ANSI C136.41 is the standard behind the familiar locking photocell socket, and its four signal contacts support either 0-10 V or DALI dimming. Zhaga Book 18 is the newer route, aligned with D4i-ready luminaires, and it is designed for sensors and network modules rather than for mains switching. If your project is a public tender, naming the interface you expect is what keeps the network layer replaceable in ten years.
Integrated solar street lights are a different case, because the photovoltaic panel, battery, controller and driver sit inside a single housing, as our all-in-one versus split-type guide explains. There is usually no exterior control socket at all, and the monitoring node is the solar charge controller itself plus an optional communication module. Two consequences follow for the specification. First, ask whether the communication module is factory-integrated or an accessory, because a factory-fitted module has a defined sealing and warranty position while a field-fitted one may not. Second, ask what dimming interface the controller publishes to the network, in terms a controls engineer can read: a proprietary app is not an interface, and it will not connect to a municipal control platform. Vibration is the other structural detail that matters at height, because a module mounted on a mast has to survive the same wind and fatigue environment as the luminaire.
What to Write Into the Specification
Vague requirements produce vague systems. The table below lists eight clauses a controls supplier can be held to, from the telemetry set and reporting interval to data ownership, SIM responsibility, gateway capacity and the spare module policy, so none of them is left to interpretation.
| Requirement | Why it matters | What to state in the clause |
|---|---|---|
| Telemetry set and interval | Defines whether faults are detectable at all | Battery state of charge, PV current and voltage, load power, dimming level in force, device online status; interval stated in minutes |
| Alarm classes and routing | An alarm nobody receives is a log entry | Named classes (PV loss, battery undervoltage, load failure, offline) with a recipient and a response time per class |
| Offline detection window | This is your theft and tamper signal | Time from last successful report to offline alarm, in hours, stated as a number |
| Device identity scheme | Telemetry is useless if a node cannot be mapped to a pole | Unique device ID tied to the client's pole or asset number, exported as a list at handover |
| Data ownership and export | Prevents lock-in and survives a platform change | Who owns the data, API or scheduled export in a readable format, retention period in months |
| SIM and hosting responsibility | Recurring cost lines decide five-year cost | Who contracts the SIM, who hosts the platform, who pays after year one |
| Gateway capacity and coverage | Network design is not a hardware purchase | Nodes per gateway and expected radio range, with the survey assumptions recorded |
| Spare and replacement policy | Modules fail and models change | Module spare ratio, replacement lead time, notice period before a model is discontinued |
Keep the clause set short enough to be tendered. Eight lines that a supplier must answer numerically are more useful than two pages of adjectives, and they give you a defensible comparison between bids. Our warranty and spare parts guide applies the same technique to the post-installation side, where the response time is the clause that actually gets used.
Data Ownership, Hosting and Platform Lock-In
Civil works outlive software. A lighting fleet may run for twenty years while the platform managing it is sold, renamed or retired. Settle three things in the contract: where the data is hosted, whether the full history can be exported, and whether an open interface lets another supplier take over.
On hosting, ask whether the platform can sit in the client's own country when data sovereignty rules require it. On export, require the whole history rather than a dashboard screenshot, in a format a spreadsheet can open, with a stated retention period. On interfaces, ask whether the control platform talks to the lighting network through an open specification of the kind the TALQ consortium publishes, so that a second supplier can be brought in without replacing every node. If the answer is a proprietary cloud that only the original supplier can read, price that risk into the decision instead of discovering it at year five. The same logic applies to a gateway-based network: if the concentrator is the single point of integration, document its replacement path in the handover pack.
Turning Alarms Into a Maintenance Workflow
Monitoring pays back when it removes site visits, and that only happens if every alarm has a defined first action. Triage by class: an offline unit as a suspected theft or tamper event, PV loss as a field check, battery undervoltage as a sizing question, load failure as an LED fault.
A workable default is to write that triage into the operations plan with a named owner per row. An offline alarm on a single accessible pole is a site check within days, and on a remote pole it is a suspected theft or tamper event. A PV loss alarm during daylight is field-verifiable in minutes with a clamp meter, and it usually resolves to a loose connector, a shaded pole or a genuinely missing panel. Battery undervoltage alarms that trip across several units in the same week point at the sizing or the charge profile rather than at individual batteries, which is a conversation with the supplier rather than a parts order. A load failure on a healthy battery is an LED or driver problem, and it should never be logged as a battery fault.
Connect the triage table to the two other documents that decide cost: the spare parts holding, and the defect reporting route to the factory. A fleet with telemetry and no triage table generates more tickets than a fleet with neither, because everyone can now see every fault and nobody knows which ones matter. Our fault-finding guide walks through the symptom-to-subsystem logic that turns a telemetry alarm into a test, and its maintenance schedule is designed to sit next to a monitoring dashboard rather than replace it.
Off-Grid Reality: The Energy Cost of Monitoring
On a grid-connected luminaire a monitoring node is a small parasitic load on an effectively unlimited supply. On a solar street light that load comes out of the same battery that has to carry the light through the rainy season, so it belongs in the autonomy calculation.
Ask for the module's average daily consumption in watt-hours or milliamp-hours and add it to the night-time load before you check the autonomy margin, instead of assuming it is negligible. The same discipline applies to remote commands. A well-meant experiment with permanent 100 percent brightness overrides the dimming profile and can flatten a system that was correctly sized for its lighting class. Ask whether remote dimming changes are logged with a timestamp and a user, and whether the controller falls back to its local default if the network drops, so that the site keeps working when the platform does not.
Every one of our published integrated models is documented with a factory dimming and control profile, from 100 percent presence and 50 percent standby on the smaller units to 60 percent after the fourth hour on the largest, and autonomy is designed around those numbers. Changing them from a dashboard after commissioning is exactly the kind of decision that belongs in the site record. The motion and dimming specification guide explains how those profiles are written and verified.
Commissioning and the First Thirty Days
Monitoring is accepted, not installed. Before sign-off, register every node and confirm the device ID list matches the pole numbers, force each alarm class on one unit of each type, and verify telemetry against a clamp meter reading taken beside the pole.
Then baseline the first thirty days: charge and discharge behaviour, the hour the light reaches full output, and the lowest state of charge recorded. Disconnect a panel during the day to test the PV loss alarm, and temporarily block the radio path or remove the SIM to test the offline alarm, because those two alarms carry the theft response and are the ones most often configured on paper only. Confirm that alarms reach a named person rather than a shared inbox. That baseline is what makes a future warranty conversation evidence-based instead of a dispute, and it is the document a funder will ask for at the end of year one.
Cost, Payback and When Not to Monitor
Model monitoring as avoided visits rather than as a feature. Compare the annual cost of nodes, data plans and the platform against the fault-finding visits the client avoids each year, plus earlier fault discovery and fewer unplanned parts orders per year.
Do not accept a generic payback figure from a supplier, because the answer genuinely depends on distance, crew cost and fleet size. Two situations where the honest answer is to skip remote monitoring are fleets small enough that one person walks them monthly, and sites with no usable cellular coverage where an LPWAN design has not yet been surveyed. In both cases, local Bluetooth read-out at commissioning plus a documented manual inspection round is the right spend, and the specification can say so.
What VOLTIC Publishes Today
Precision here saves time on both sides. Our ZHENYE SERIES integrated lights are documented with an MPPT controller covering light control, timer control and human presence detection, and the 150W model is documented with the same controller offered with a Wi-Fi and Bluetooth option.
Our energy storage range is documented with RS485, CAN, Wi-Fi and GPRS communication for monitoring and management, which is where fleet-level monitoring experience sits in our product line today. Network-level monitoring of a solar lighting fleet, meaning cellular or LPWAN nodes reporting into a control platform, is a project-level option: whether it is available for your configuration, with which radio and which platform, has to be confirmed model by model before it is written into a contract. Our standard documented claims are the ones published on our pages: CE, RoHS and ISO 9001 quality system, third-party LM-79 photometric reports, and a five-year product warranty with a twenty-five-year panel power output warranty. Give your engineering contact the alarm classes, the radio preference and the platform requirements, and you will get an answer against your actual configuration instead of a catalogue average.
Frequently Asked Questions
Does every solar street light need remote monitoring?
No. Monitoring earns its cost where a fault is expensive to discover, which usually means remote sites, large fleets, theft risk, or a funder who wants performance evidence. A small walkable site with an existing maintenance round is better served by scheduled inspection.
What is the difference between a NEMA 7-pin connection and Zhaga Book 18?
A NEMA-style locking receptacle, standardised for dimming controls as ANSI C136.41, carries power contacts plus dimming and signal contacts and replaces the photocell on top of a roadway luminaire. Zhaga Book 18 defines a smaller receptacle for a plug-in sensor or communication module.
Which is cheaper, one SIM per light or a LoRa gateway?
For a small scattered fleet the cellular route is usually simpler and cheaper to engineer, because there is no radio planning. For a long dense corridor or an estate with hundreds of poles, gateway-based radio normally wins on recurring data cost.
Can monitoring be added to solar street lights I already own?
Sometimes, and the answer depends on what the existing controller exposes. If the charge controller has a communication port and the luminaire has a spare gland position, an external module can be retrofitted. A sealed controller with a proprietary interface may need replacing.
Does a monitoring module drain the battery enough to matter?
It can, on a system with a thin autonomy margin. The average consumption in watt-hours per day is a value you should request, and it belongs in the autonomy calculation alongside the night-time load. A badly configured reporting interval removes more energy than the module.
What happens to my data if the monitoring platform is discontinued?
That risk is managed in the contract, not in the hardware. Require scheduled export of the full history in a readable format, a documented API where possible, and written notice before a platform is retired. Client-hosted data is worth pricing.
Next Step: Send the Monitoring Requirement, Not Just the Wattage
Most quotations are compared on wattage and price, which is exactly why monitoring requirements go unmet. Write down the alarm classes you need, the connectivity you prefer, the platform and data-ownership rules, and the site conditions, then send that list with the pole drawing.
If you have not chosen a luminaire yet, start from the integrated solar street light range to see the wattage ladder and the published control profiles, check the pole and foundation data in the solar street light pole range before the civil works are priced, and read the selection guide for the six specifications that decide everything else. When your requirement list is ready, send it to our engineering team and we will answer it against the exact model rather than against the catalogue average.