Solar Lighting
Control System
Programmable dimming, sensor logic, and remote monitoring matched to your battery and LED load before the container ships.
JXSOL supplies solar street light controllers and remote management systems for project contractors, OEM integrators, and distributors building smart solar lighting programs. Every controller is firmware-configured, function-tested, and communication-verified before shipment.
Solar Lighting Control System for
Project-Level Lighting Management
A solar lighting control system is the controller, firmware, communication module, and remote-management layer that determines how a solar outdoor light actually behaves in the field. It manages battery charge and discharge, LED output levels, dusk-to-dawn switching, dimming schedules, sensor override logic, and — for IoT-enabled deployments — remote monitoring and fault reporting.
The solar panel and battery determine how much energy is available. The solar street light controller determines how that energy is used, when the light turns on, how bright it runs at each hour, and whether a fault gets reported before a site visit is triggered.
Most field failures in solar lighting projects don't originate in the battery or the LED module. They originate in a controller that was shipped with a generic firmware profile and never matched to the actual load, battery voltage, or operating schedule of the installation. We configure every controller before shipment — charge parameters set to the battery chemistry and capacity, dimming schedule programmed to your specified profile, sensor sensitivity adjusted for the installation environment.
That pre-shipment configuration is what separates a system that runs consistently for three years from one that generates warranty calls in the first winter.
This page is for buyers sourcing controllers for project integration, OEM solar street light programs, or smart solar lighting deployments where the control layer needs to be specified and configured, not just selected from a catalog.
Request a solar lighting control system quote with your load and battery parameters
What the Controller Actually Manages
Before the Light Ships
The solar street light controller is doing several things simultaneously, and the interactions between those functions are where most configuration errors occur. Understanding what the controller manages — and how we configure each function before shipment — is the fastest way to evaluate whether a controller is correctly specified for your project.
Charge & Discharge Control
MPPT circuit · Chemistry-matched parameters · Over-discharge protection
The controller's MPPT (Maximum Power Point Tracking) charge circuit extracts maximum available power from the solar panel and delivers it to the battery at the correct charge voltage for the battery chemistry. LiFePO4 and lithium-ion batteries have different charge voltage profiles; a controller configured for one chemistry will undercharge or overcharge the other.
We set the charge parameters to match the battery pack in the order — not to a generic default. Over-voltage protection, over-discharge protection, and short-circuit protection are all active functions, not just listed features.
The over-discharge cutoff is set to preserve battery cycle life: cutting off at 20% state of charge rather than running the battery to zero adds hundreds of cycles to the pack's effective life.
LED Output Control & Dimming
Constant-current output · PWM dimming · 10–100% range · Schedule-programmed
The controller drives the LED module through a constant-current output circuit. Dimming is achieved by adjusting the output current — typically via PWM — across the programmed schedule. The dimming range on standard controllers runs from 10% to 100% output.
We program the dimming schedule before shipment: full output for the first hours after dusk, mid-night reduction to 30–50%, motion-triggered return to full brightness, then off or minimal output before dawn. The exact schedule is set to your specification.
Common field failure: Buyers receive controllers with a factory default schedule that runs 100% all night — fine for the first few months, but it depletes the battery faster than the panel can recover in winter, and the system starts shutting off early by November.
Sensor Input Processing
PIR & microwave inputs · Hold time · Sensitivity threshold · Motion override
When a motion sensor is integrated, the controller processes the sensor signal and overrides the current dimming level — typically jumping to 100% output for a configurable hold time before returning to the scheduled level. PIR sensors detect body heat; microwave sensors detect movement through radar. Each has different false-trigger characteristics.
We configure the sensitivity threshold and hold time before shipment. A hold time that's too short (under 15 seconds) causes the light to cycle visibly as a pedestrian walks through the detection zone. A hold time that's too long wastes battery on empty streets.
For projects with high pedestrian traffic, we typically set hold time to 30–45 seconds and sensitivity to mid-range to reduce false triggers from wind-blown vegetation.
Dusk-to-Dawn Timing
Light sensor trigger · Astronomical timer · On/off threshold · Seasonal adjustment
The controller determines when to switch the light on and off using either a light-dependent resistor (LDR) sensor, an internal astronomical timer, or both. The LDR measures ambient light level and triggers the output when the panel voltage drops below the on-threshold at dusk.
Astronomical timers use GPS-derived latitude and longitude to calculate local sunrise and sunset times without relying on a sensor that can be affected by shadows, nearby artificial light, or sensor degradation over time. For projects where consistent timing matters — municipal roads, security perimeters — we recommend the astronomical timer as the primary trigger.
We set the on/off thresholds and, where applicable, the latitude/longitude coordinates before shipment so the light operates correctly from day one without field adjustment.
System Protection & Fault Management
Thermal cutoff · Reverse polarity · Panel reverse current · Fault logging
The controller monitors internal temperature and battery voltage continuously. If the battery temperature exceeds the safe operating range — common in enclosures in tropical climates — the controller reduces charge current or suspends charging to prevent thermal damage.
Reverse polarity protection prevents damage if the battery is connected incorrectly during installation. Panel reverse-current blocking prevents the battery from discharging back through the solar panel at night — a function handled by the MPPT circuit's blocking diode or by software in more advanced controllers.
On controllers with data logging, fault events are recorded with timestamps. This is useful for warranty claims and for diagnosing intermittent failures that don't present during a site visit.
Controller Specification Sheet Buyers Can Use for Screening
The table below covers typical parameters for JXSOL solar street light controllers. Values marked "typical" reflect the most common configurations; model-specific datasheets are available on request. Confirm exact specifications before ordering.
| Parameter | Typical Value / Options |
|---|---|
| Battery Voltage | 12V, 24V, 36V, 48V (model-dependent) |
| Battery Chemistry | LiFePO4 (standard), Li-ion (available) |
| Charge Mode | MPPT (standard), PWM (available on lower-cost models) |
| Max Charge Current | 10A – 30A (model-dependent) |
| LED Load Current | 1A – 20A (matched to LED module power) |
| LED Dimming Output | PWM constant-current, 10%–100% range |
| Dimming Modes | Time-based schedule, motion-triggered override, manual/remote override |
| Sensor Input | PIR (standard), microwave (available), dual-sensor (available) |
| Communication Options | Standalone (no communication), RF/IR remote, 4G LTE, NB-IoT, Zigbee, LoRa |
| Remote Monitoring | Cloud dashboard (4G/NB-IoT models), local gateway (Zigbee/LoRa models) |
| Over-voltage Protection | Active, threshold set to battery chemistry |
| Over-discharge Protection | Active, cutoff at configurable SOC threshold (typically 20%) |
| Short-circuit Protection | Active |
| Temperature Protection | High-temp charge derating, low-temp charge inhibit |
| Operating Temperature | -20°C to +60°C (typical) |
| Ingress Protection | IP65 (standard controller enclosure), IP67 (available) |
| Certifications | CE, RoHS (confirmed); IEC 62124 (system-level, available on request) |
| Firmware Configuration | Pre-shipment programming to buyer's schedule and load parameters |
| OEM Firmware Lock | Available — prevents field modification of schedule and parameters |
Specifications shown are typical values for this product type. Actual specifications vary by model and configuration. Contact us with your LED power, battery voltage, panel wattage, and operating schedule for exact model matching and a detailed datasheet.
Dimming, Sensor, and Solar Lighting Remote Control Logic
The "smart" in a smart solar lighting system is almost entirely in the controller's dimming and sensor logic — and in how much of that logic can be adjusted after the light is installed. Getting this right before shipment reduces after-sales support cost significantly. Getting it wrong means site visits, firmware updates, or controller replacements.
Time-Based Dimming Schedules
A time-based dimming schedule runs the LED at different output levels across the night, triggered by the controller's internal clock and dusk/dawn detection. A typical municipal road schedule: 100% output from dusk to 23:00, 50% from 23:00 to 05:00, 100% from 05:00 to dawn.
The schedule is programmed into the controller before shipment. For repeat orders, we store the approved schedule and apply it to every unit in the batch — no variation between units, no field adjustment required.
Motion-Triggered Override
When the PIR or microwave sensor detects motion, the controller overrides the current dimming level and returns the LED to full output for a configured hold time. After the hold period expires with no further motion, the controller returns to the scheduled dimming level.
Hold time calibration matters: A hold time that's too short creates a flickering effect as the light dims and re-triggers; a hold time that's too long defeats the energy-saving purpose of the dimming schedule. We configure this based on your installation environment.
Dawn/Dusk Detection
The controller uses a light sensor or an internal astronomical clock to detect dusk and dawn. Astronomical clock mode is more reliable in environments where ambient light from nearby buildings or streetlights can confuse a photocell sensor.
We configure the detection mode based on the installation environment described in the order.
Solar Lighting Remote Control Levels
Remote control capability varies by communication module. Standalone controllers with no communication module can only be adjusted by physical access to the controller — a handheld programmer or direct firmware update. RF/IR remote controllers allow group or individual adjustment from a handheld remote within line-of-sight range, which is practical for small installations and distributor SKUs where the buyer wants a simple post-installation adjustment option without IoT infrastructure cost.
IoT-Enabled Controllers: The After-Sales Service Difference
IoT-enabled controllers — 4G, NB-IoT, Zigbee, LoRa — allow remote schedule changes, output level adjustments, and fault monitoring from a cloud dashboard or local gateway.
The commercial value is direct: a project contractor managing 500 lights across a municipality can push a schedule change to all units from a laptop rather than dispatching a crew. A distributor supporting a customer's installation can diagnose a fault remotely before deciding whether a site visit is necessary.
Standalone vs. IoT: The Key Distinction for Buyers
Standalone controllers have fixed post-shipment behavior unless physically accessed. IoT-enabled controllers can be updated remotely, which changes the after-sales service model entirely.
For large projects or programs where the buyer is responsible for ongoing maintenance, the IoT option reduces service cost enough to justify the higher unit cost.
Standalone Controller
Best for distributor SKUs where the buyer's customer manages their own installation. Pre-programmed schedule, no IoT infrastructure cost.
IoT-Enabled Controller
Best for large projects or programs where the buyer is responsible for ongoing maintenance. Remote updates reduce service cost at scale.
Choosing 4G, NB-IoT, LoRa, Zigbee, or Standalone Control
Communication protocol selection affects landed cost, service model, and project acceptance — it's not a spec detail to leave until after the order is placed. The decision depends on the installation environment, the buyer's monitoring requirements, and the network infrastructure available at the project site.
Standalone or RF/IR Remote
No SIM · No Network DependencyNo SIM card, no network dependency, no ongoing data cost. The controller runs its programmed schedule and responds to a handheld remote for local adjustments. The right choice for distributor SKUs targeting small commercial or residential projects where the end customer doesn't need centralized monitoring and the buyer doesn't want to manage SIM cards or data plans. Also the right choice for markets where cellular or IoT network coverage is unreliable.
Limitation: Post-installation schedule changes require physical access to the controller.
4G LTE
Most Widely Deployed · Global CoverageThe most widely deployed option for IoT solar lighting. 4G coverage is available in most urban, suburban, and peri-urban markets globally, and the data cost for lighting telemetry — status reports, fault codes, schedule updates — is low (typically under $1/month per unit on a bulk SIM plan). The standard choice for municipal road projects, large commercial installations, and any deployment where the buyer or their customer needs remote monitoring and fault reporting. The controller connects to a cloud dashboard; monitor battery state, LED output, fault history, and operating hours for every unit from a single interface.
Best for: Municipal road projects, large commercial installations, remote monitoring requirements.
NB-IoT
Narrowband IoT · Dense Urban DeploymentsDesigned for dense deployments in urban environments where many devices share the same network infrastructure. Uses less bandwidth than 4G and has better building penetration — matters for controllers installed in enclosed battery compartments or underground cable runs. The preferred choice for smart-city projects in markets where the network operator has deployed NB-IoT infrastructure, primarily China, parts of Europe, and some Middle East markets. Data cost is lower than 4G.
Limitation: Not available everywhere. Buyers must confirm network availability at the project site before specifying.
Zigbee Mesh
Campus & Industrial · Local GatewayUsed for campus, industrial park, and controlled-site installations where a local gateway is available. Each controller communicates with the gateway rather than directly with a cellular network — the gateway aggregates data from all units and forwards it to a cloud platform or local server. This architecture reduces per-unit communication cost significantly for large installations and works in areas without reliable cellular coverage.
Trade-off: A gateway must be installed and maintained at the site. Best where the buyer's customer has existing network infrastructure.
LoRa Mesh
Long Range · Low Power · Gateway-BasedLike Zigbee, LoRa is used for campus and controlled-site installations with a local gateway. LoRa offers longer range per node than Zigbee, making it suitable for larger sites or installations where nodes are more spread out. The gateway aggregates data from all units and forwards it to a cloud platform or local server, reducing per-unit communication cost for large installations.
Trade-off: For remote or distributed installations without a local gateway, 4G is more practical.
Protocol selection determines your service model, ongoing data cost, and what monitoring capabilities you can offer your customer.
Protocol Selection and Project Acceptance
In municipal and institutional tenders, the communication protocol is often specified in the tender document — the buyer doesn't choose, they match. For projects where the buyer has flexibility, the decision comes down to three questions:
-
Does the project site have reliable cellular coverage?
-
Does the buyer's customer have an existing monitoring platform with a preferred protocol?
-
Is there a local gateway infrastructure that makes mesh networking practical?
Quick Selection Reference
We can configure any of these options. The choice is yours based on your project context. For a full overview of how communication integrates with the complete smart solar lighting system, see smart solar lighting systems.
Not sure which protocol fits your project?
Tell us your project's network environment and monitoring requirements — we'll recommend the right protocol.
Market Segments Where Control Systems Protect Margin
A solar lighting control system is what separates a premium solar street light from a commodity one. The control layer is where the margin lives — and where the warranty risk concentrates if it's configured incorrectly. The segments below are where our buyers are building profitable programs around control-system differentiation.
Municipal Road and Street Upgrades
Municipal procurement increasingly specifies IoT solar lighting with remote monitoring and fault reporting. A control system that reports faults before a resident complaint triggers a work order reduces maintenance dispatch cost for the municipality. For buyers supplying municipal contractors, this means the solar street light controller is a specification requirement, not an optional upgrade.
Tenders in this segment typically require CE certification, IEC 62124 compliance, and documentation that the control system meets the specified communication protocol.
Campus and Institutional Projects
Universities, hospitals, and corporate campuses specify smart solar lighting with group control capability for phased deployment. A campus project often starts with a pilot of 100–200 units on a single pathway or parking area, then expands to additional zones as the facilities team confirms performance.
The control system needs to support group scheduling — different dimming profiles for different zones — and ideally integrate with the campus's existing building management system. OEM firmware configuration that locks the schedule and prevents unauthorized adjustment is common in this segment.
Industrial Parks and Logistics Yards
Large-area installations — perimeter roads, loading docks, internal circulation routes — benefit from dimming and sensor logic that reduces battery stress across the full installation. A logistics yard running 200 lights at 100% output all night is oversizing the battery and panel requirement significantly.
A dimming schedule that drops to 30% during low-traffic hours reduces the energy budget and allows a smaller, lower-cost battery configuration. The solar street light controller is what makes that optimization possible. Buyers supplying industrial park developers can position the control system as a cost-reduction tool, not just a smart feature.
OEM Solar Street Light Programs
OEM buyers integrating JXSOL controllers into their own product line need firmware that's locked to their specified schedule and behavior — consistent across every unit in the batch, not adjustable by the end installer. This protects the OEM's product reputation: if the end customer can modify the controller settings, the OEM loses control of how the product performs in the field.
- Firmware locked to any schedule the OEM specifies
- Communication module configured to report to the OEM's own monitoring platform
- Meaningful differentiation for OEM buyers building a branded smart solar lighting line
Distributor Upgrade SKUs
A distributor carrying standard solar street lights can add a control-system SKU — a higher-margin product that targets buyers who need more than basic on/off operation. The control system creates a product tier: standard solar light at one price point, smart solar light with programmable dimming and remote control at a higher price point.
Product Tier Structure
Standard Solar Street Light
Basic on/off operation — entry price point
Smart Solar Light with Control System
Programmable dimming, remote control — defensible higher margin
The margin difference is defensible because the control capability is visible and demonstrable. For distributors in markets where smart-city programs are driving buyer awareness of IoT lighting, this tier is increasingly what buyers ask for first.
The Control System Is Where Margin Is Defended
Across all five segments — municipal, campus, industrial, OEM, and distributor — the control system is the differentiator that justifies a higher price point and protects against commodity competition. Buyers who specify the controller as a requirement, not an option, are building programs that are harder to displace on price alone.
OEM/ODM Control Configuration Before Mass Production
OEM configuration goes deeper than firmware. The controller hardware, communication module, protection parameters, and reporting interface all need to match your product specification and target market. Here's what we configure for OEM orders, and where the practical limits are.
Firmware Schedule and Behavior
Locked after programming
We program the dimming schedule, sensor hold time, sensor sensitivity, dusk/dawn detection mode, and over-discharge cutoff to your specification before mass production.
Locked firmware for OEM buyers: The end installer cannot modify the schedule or parameters without a firmware update tool that only the OEM controls. This prevents field modifications that create inconsistent behavior across the installation and generate support calls.
Communication Protocol and Reporting Interface
Configured to your platform
The communication module is configured to your specified protocol — 4G, NB-IoT, Zigbee, or LoRa — and initialized to report to your monitoring platform or dashboard. Reporting interval, data fields, and alert thresholds are all configurable.
- Existing IoT platform with defined API — we configure the module to match the API format
- No existing platform — white-label dashboard available under your brand
Hardware Matching — Voltage, Load Current, Battery Chemistry
Confirmed before production starts
The controller hardware must match the battery voltage, LED load current, and battery chemistry in the fixture. We confirm these parameters during the engineering review before mass production — not after the first batch ships.
Required inputs for controller model confirmation
- LED module forward voltage and current draw
- Battery pack voltage and chemistry
- Solar panel open-circuit voltage
Private-Label Packaging and Documentation
Produced under your brand
Controller packaging, user manuals, and compliance documentation are produced under your brand for OEM programs. CE declarations and RoHS certificates can be prepared under your product specifications.
Import documentation: For buyers supplying markets with specific import documentation requirements, we prepare the documentation package as part of the OEM order — not as a separate request after shipment.
Confirm NB-IoT Coverage Before Locking the Protocol
If your target market uses NB-IoT, verify network coverage at the project sites before locking the protocol. We've had buyers specify NB-IoT for a market where coverage was patchy, and the controllers had to be retrofitted with 4G modules after installation. That's an avoidable cost — confirm coverage early.
MOQ and Engineering Review
Standard Catalog Controllers
100 units
Minimum order quantity
OEM/ODM — Custom Firmware, Locked Schedules, Non-Standard Communication
300–500 units
Depending on scope of changes
What to Send for Engineering Review
Engineering review is included. Send us your fixture's electrical parameters, your target schedule, your communication requirement, and your monitoring platform details — we'll confirm the configuration before production starts.
- Fixture electrical parameters (LED voltage, current, battery chemistry, panel Voc)
- Target dimming schedule and sensor behavior
- Communication protocol and monitoring platform details
- Target market and import documentation requirements
Controller Board Manufacturing and QC Checks
A solar street light controller is an outdoor electronics product that runs continuously for years in temperature extremes, humidity, and vibration. The manufacturing process for the controller board determines whether it survives those conditions or fails after the first summer. Here's how we build and test ours.
SMT Assembly and Solder Quality
Controller boards are assembled on automated SMT lines — the same lines that handle our LED driver and sensor circuit boards. Automated placement and reflow soldering produces consistent solder joint geometry across the full batch. The failure mode we're preventing is cold solder joints and tombstoned components, which pass visual inspection but develop intermittent connections after thermal cycling.
Manual SMT introduces variation in solder volume and joint profile that shows up as field failures 6–18 months after installation; we moved all controller board assembly to automated SMT lines years ago specifically because of this failure pattern.
After reflow, every board goes through automated optical inspection (AOI) — a camera-based system that checks component placement, solder joint geometry, and polarity against the approved board layout. Boards that fail AOI are pulled before they reach the function test station.
Function Testing Before Firmware Load
Before firmware is loaded, each controller board is tested for basic electrical function: power supply rails, charge circuit output, LED driver output, sensor input response, and communication module initialization. A board that has a component failure or a trace defect will fail this test.
Firmware is loaded only onto boards that pass electrical function testing — this prevents the situation where a firmware-loaded board fails in the field due to a hardware defect that was present before programming.
Firmware Load and Verification
Firmware is loaded via a programming fixture that connects to the board's programming interface. After loading, the firmware version is verified against the approved build for the order. For OEM orders with locked firmware, the lock is applied at this stage and verified before the board moves to final assembly.
Dimming schedule, sensor parameters, communication configuration, and protection thresholds are all confirmed against the order specification.
Communication Handshake Testing
For IoT-enabled controllers, the communication module is tested for network registration and data transmission before the board is assembled into the housing. A controller that ships without a verified communication handshake will appear functional on the bench but fail to register on the monitoring platform after installation — a failure mode that's difficult to diagnose remotely and requires a site visit to resolve.
We test every IoT controller for network registration and data transmission as a separate QC step.
Charge/Discharge and Dimming Response Testing
Assembled controllers are tested on a bench fixture that simulates the battery, solar panel, and LED load. The test verifies charge current at the programmed MPPT setpoint, LED output at each dimming level, sensor trigger response, and over-discharge cutoff at the programmed threshold.
This is a functional test of the complete controller behavior, not just the individual circuit blocks.
100% Outgoing Inspection
Every controller unit — board, housing, communication module, and accessories — is inspected before packing. For IP65/IP67 enclosures, the housing is pressure-tested after final assembly. Labeling, firmware version, and accessory completeness are checked against the packing list. For OEM orders, private-label labeling is verified against approved artwork.
Our JXSOL solar lighting manufacturing capabilities cover the full production and QC process across all product categories — the controller board process described here is part of the same quality system that covers LED modules, battery packs, and complete fixture assembly.
Related Smart Solar Lighting Options If You Need More Than the Controller
The solar lighting control system is the right product if you're sourcing the control and communication layer for an existing fixture design, integrating a controller into an OEM product, or adding remote monitoring capability to a project. If your requirement is broader, the products below may be a better fit.
Complete Smart Solar Lighting System
An integrated solar lighting unit — solar panel, LiFePO4 battery, LED module, PIR or microwave sensor, and programmable controller — in a single product. The right starting point for most road, pathway, parking, and campus lighting projects where you need a complete fixture, not just the control layer. Available in all-in-one and split configurations from 100 units.
View product
Smart Solar Poles
A pole-integrated smart solar lighting system where the solar panel, battery compartment, LED fixture, controller, and optional IoT communication module are built into a single pole structure. Specified for urban streetscape projects, campus infrastructure, and smart-city installations where the visual integration of the system matters alongside the lighting performance.
View product
Solar Street Light With Camera
A solar street light with an integrated IP67-rated surveillance camera — one pole, one power source, one installation. The power budget accounts for both the LED and camera loads. The right product for security-driven projects: perimeter lighting, parking surveillance, road monitoring, and remote site security.
View productFor a full overview of the smart solar lighting category and system configuration guidance, see smart solar lighting systems.
Quote Inputs for a Usable Control-System Recommendation
A generic quote for a solar street light controller is not useful — the controller model, firmware configuration, and communication module depend entirely on the electrical parameters of the fixture it's going into and the operating requirements of the project. Send us the following and we'll come back with a specific model recommendation, a configuration spec, and a detailed quote.
Electrical Parameters
Required for model matching
- LED module power (watts) and forward current (amps)
- Battery voltage (12V / 24V / 36V / 48V) and chemistry (LiFePO4 / Li-ion)
- Solar panel wattage and open-circuit voltage
Operating Requirements
For firmware configuration
- Operating hours per night and target dimming schedule
- Sensor type (PIR / microwave / none) and hold time preference
- Required autonomy nights (consecutive cloudy days the system must sustain)
Communication & Monitoring
For module selection
- Communication protocol (standalone / RF remote / 4G / NB-IoT / Zigbee / LoRa)
- Monitoring platform or dashboard requirement (existing platform API, white-label dashboard, or none)
- Reporting interval and alert requirements
Order & Program Details
For pricing and OEM scope
- Order quantity (for standard or OEM/ODM pricing)
- OEM requirements: firmware lock, private-label packaging, compliance documentation under your brand
- Target market and certification requirements (CE for Europe, or other market-specific)
Why These Inputs Matter Before Quoting
Providing these inputs upfront prevents the most common sourcing problem: a controller that's electrically compatible but firmware-mismatched for the project, which only surfaces after installation. A quote built on complete parameters returns a specific model recommendation, a configuration spec, and a price — not a range that requires another round of clarification.
Solar Lighting Control System FAQ
Answers to the specification and configuration questions buyers ask most often before placing an order or submitting a quote request.
What information is needed to match a solar street light controller to a solar light?
The minimum inputs are: battery voltage and chemistry, LED module power and forward current, solar panel open-circuit voltage, and the operating schedule (hours per night, dimming profile, sensor type). From these we confirm the correct controller model — charge current rating, load current rating, and MPPT input voltage range — and program the firmware to the specified schedule.
Minimum matching inputs
- Battery voltage and chemistry
- LED module power and forward current
- Solar panel open-circuit voltage
- Operating schedule: hours per night, dimming profile, sensor type
If you're integrating our controller into an existing fixture design, send us the fixture's electrical schematic or the LED driver's input spec — that's usually faster than building the parameter list from scratch.
Can a solar lighting remote control change dimming schedules after installation?
It depends on the communication module. The capability varies significantly across controller types:
Standalone
No communication module. Any schedule change requires physical access — a handheld programmer connected to the controller's programming port.
RF / IR Remote
Allows output level adjustments from a handheld remote within line-of-sight range, but cannot change the underlying time-based schedule.
IoT-Enabled
4G, NB-IoT, Zigbee, LoRa — full remote schedule changes, parameter updates, and firmware updates from a cloud dashboard or local gateway.
OEM firmware lock: For OEM buyers who have locked the firmware, remote schedule changes require an authenticated update from the OEM's programming tool. This is intentional — it prevents unauthorized modification of the product configuration.
Should a project use 4G, LoRa, Zigbee, NB-IoT, or standalone control?
The decision comes down to three factors: network infrastructure at the project site, monitoring requirements, and per-unit cost tolerance.
Default for most projects. Broad coverage, low data cost, no local infrastructure required.
Preferred for dense urban deployments in markets where NB-IoT networks are deployed. Confirm coverage before specifying.
Cost-effective for campus or industrial park installations where a local gateway is available and the buyer wants to avoid per-unit SIM costs.
The right choice for distributor SKUs and small projects where the end customer doesn't need remote monitoring and the buyer doesn't want to manage network subscriptions.
Tender document rule: If the tender document specifies a protocol, match it — don't substitute without confirming with the project owner.
What causes solar lighting controllers to fail in outdoor projects?
Four failure modes account for most field failures. Understanding each one helps buyers evaluate controller quality before specifying.
A controller configured for Li-ion chemistry used with a LiFePO4 battery will chronically undercharge the pack, reducing effective capacity over time.
A controller without active over-discharge cutoff, or with the cutoff set too low, runs the battery to near-zero state of charge repeatedly, which accelerates cell degradation.
A controller housing with inadequate IP protection allows condensation to reach the communication module, causing intermittent connectivity that's difficult to diagnose remotely.
A manufacturing defect that passes initial testing but develops intermittent connections after thermal cycling in outdoor temperature swings.
Our automated SMT assembly and AOI inspection process is specifically designed to prevent cold solder joint failures (failure mode 4). Charge parameter mismatch, over-discharge, and moisture ingress are addressed through correct factory configuration and IP-rated housing — both verified before shipment.
Can JXSOL supply controllers for OEM solar street light products?
Yes. We supply controllers for OEM integration with custom firmware schedules, locked configuration, private-label packaging, and compliance documentation under the buyer's brand. The engineering review before production confirms that the controller model matches the fixture's electrical parameters — battery voltage, LED load current, panel open-circuit voltage — before mass production starts. Communication modules are configured to the buyer's specified protocol and, for IoT-enabled systems, initialized to report to the buyer's monitoring platform. OEM orders typically start at 300–500 units depending on the scope of firmware and communication customization.
What MOQ applies to standard and custom solar lighting control systems?
Standard catalog controllers with pre-programmed schedules: 100 units minimum. OEM/ODM orders with custom firmware, locked schedules, non-standard communication configuration, or private-label packaging: typically 300–500 units, depending on the scope of changes.
Engineering review is included in the OEM process — we don't charge separately for configuration work on orders that proceed to production. For buyers who need to test a controller configuration before committing to a full OEM program, we can produce a small sample batch (typically 5–10 units) for field validation before the production order is placed.
Ready to Specify?
Get a Control-System Recommendation
Share your project parameters and we'll confirm the right controller model, firmware configuration, and MOQ before you commit.
Explore More
Related Smart Solar Lighting Products
Smart Solar Lighting System
Integrated smart solar lighting systems with built-in control, communication, and energy management for complete project deployment.
View ProductSmart Solar Poles
Multi-function smart poles combining solar lighting with surveillance, environmental sensing, and connectivity infrastructure.
View ProductSolar Street Light With Camera
Solar street lights with integrated camera modules for combined illumination and surveillance in a single pole-mounted unit.
View Product