Remote Control for Solar Street Lights
-- How It Works
Remote Control for Solar Street Lights: How It Works
Short answer: remote control on a solar street light is two data flows, not one. Telemetry flows up from the fixture — battery state, panel output, faults. Commands flow down from the platform — dimming schedules, threshold changes, firmware updates. Everything else, including any camera on the pole, is a payload riding on top of those two flows.
What the fixture reports
The controller samples the health of the system on a fixed cycle and reports:
- Battery status: voltage, current, state of charge, and temperature
- Panel performance: charging current and daily generation totals
- LED fixture operation: drawn power, dimming level, runtime hours
- Ambient light conditions, used to confirm dusk/dawn switching
- System temperature inside the housing
- Motion detection, where the fixture runs adaptive lighting
In our controllers, these readings are what the platform graphs. A site manager who sees one fixture's state of charge drifting below its neighbors is looking at a shading or battery problem, not a lighting problem.
Choosing the communication link
Two options cover almost every project, and the choice is about data volume and coverage, not fashion:
| Need | 4G/5G cellular (SIM) | LoRaWAN |
|---|---|---|
| Telemetry (kilobytes/day) | Works, oversized | Designed for it |
| Video or firmware pushes | Required | Not practical |
| Coverage | Carrier dependent | Private gateway, site-owned |
| Recurring cost per fixture | SIM data plan | Gateway amortized, near-zero per node |
| Typical use in our projects | Cameras, connected sites | Municipal dimming and monitoring fleets |
Our default for municipal fleets is LoRaWAN for telemetry and dimming commands, with a 4G uplink only where a camera or frequent firmware update is in scope. The comms mistake we see most often is paying a per-fixture SIM plan to move a few hundred bytes a day.
The command path, end to end
A remote command travels: user terminal (phone or desktop) → cloud platform → communication network → fixture controller → execution → status feedback back up the same chain. The fixture acknowledges, and the platform shows the new state.
Set expectations honestly: this is a seconds-scale loop, not a millisecond one. A cellular module that is awake on a schedule, or a LoRaWAN duty-cycle limit, both add latency by design. Nobody should be selling "instant" control on a battery-powered pole.
Security minimums we build in
We treat the controller as an embedded device on a hostile network:
- Telemetry and commands are encrypted in transit; nothing travels as plaintext.
- Device authentication is per-fixture, with credentials provisioned at commissioning.
- The controller does not listen on the public internet. Platform access goes through the cloud endpoint, with account-level access control and logging.
- Firmware updates are signed, so a stolen module cannot be reflashed into the fleet.
For sites that carry cameras, the video pipeline is separate: the image sensor feeds an encoding chip, the stream goes over the SIM's 4G/5G link to the cloud for storage and transcoding, and the same encryption and access rules apply. That payload is why those sites need cellular.
What this page does not cover
This page covers telemetry and control for the lighting fixtures themselves. It does not cover the camera product line, grid SCADA integration, or cybersecurity certification regimes for critical infrastructure. To see how the dimming commands are applied once the sun is down, read power consumption control. To size the controller and battery behind the link, use the controller sizing calculator, or compare complete units in our all-in-one solar street lights line.