If your solar street lights run fine in dry season but start dimming early or shutting down during rainy weeks, it’s usually not “bad batteries”.
It’s almost always autonomy sizing done with the wrong assumptions.
Rainy-season autonomy sizing is the #1 hidden reason solar street lighting projects start failing after 2–4 cloudy days. It’s rarely “bad luck.” In most cases, it’s an energy balance mistake: sizing against annual-average sun hours, ignoring derating losses, or claiming “autonomy days” from battery Ah without proving worst-month survival + recovery.
If you’re bidding EPC/government tenders, autonomy is not a marketing line. It must be auditable.
Quick Answer (60 seconds)
Projects fail after 2–4 cloudy days when daily energy demand (Wh/night) is higher than worst-month energy supply (Wh/day) after losses. The battery SOC drops during cloudy days—and then never fully recovers when sun returns. Eventually, the controller triggers protection (aggressive dimming / early-off / shutdown).
To prevent this, size with:
1) Worst-month PSH (not annual average)
2) A documented derating chain (PV → controller → battery → LED)
3) A recovery margin (SOC rebound after cloudy streaks)
4) A traceable tender evidence pack (BOQ → model → IES/LDT → DIALux/Relux → sizing sheet)
1) The “2–4 Cloudy Days” Failure Pattern (what actually happens)
Most failures follow a predictable timeline:
- Day 1–2 cloudy: SOC drops, but lights still run normally.
- Day 3–4 cloudy: SOC crosses protection threshold → dimming increases or lights shut off earlier.
- After clouds: Sun returns, but the system doesn’t recover because PV energy barely covers nightly load + losses → SOC “ratchets down” over time.
So the root cause is not “how many cloudy days.” It’s whether your system can recover.
2) The 3 Most Common Sizing Mistakes (and why they pass paper checks)
Mistake A — Using annual average sun hours
Average PSH makes spreadsheets look good, but rainy season is not average.
If worst month is 2.5–3.2 PSH and you sized at 5.0 PSH, your energy budget collapses.
Rule: Use worst-month PSH for autonomy survival. Use average PSH only for annual estimates.
Tender-proof note (don’t skip this): record your PSH source + coordinates + month inside the sizing sheet. Typical accepted sources include PVGIS / NASA POWER / Meteonorm, or the tender’s specified dataset.
Mistake B — The “Battery Ah trap”
People quote battery Ah and “convert to days,” but autonomy depends on usable Wh, not nameplate.
Usable energy is reduced by:
- BMS cutoff + voltage curve
- controller SOC protection window (you may not use 0–100%)
- temperature derating
- aging reserve
Mistake C — Ignoring the derating chain
PV nameplate is not delivered energy. Typical losses include:
- PV temperature + dust + mismatch
- MPPT/controller efficiency
- battery charge/discharge losses
- wiring losses
- LED driver efficiency
- maintained performance strategy over years
If you skip losses, you are designing “day-one marketing performance,” not tender-grade reliability.
3) The Tender-Ready Method: Build an Auditable Energy Balance
Step 1 — Define nightly energy demand (Wh/night)
Use the real operating profile, not “rated wattage”.
Nightly Load (Wh/night) = Σ (Power_i × Hours_i)
Example (typical dimming profile):
- 100% for 2 hours
- 70% for 6 hours
- 40% for 4 hours
If lamp rated 50W at 100%:
- 50W × 2h = 100Wh
- 35W × 6h = 210Wh
- 20W × 4h = 80Wh
Total = 390Wh/night
Tender tip: Put this load table in the submission. It removes disputes.
Step 2 — Estimate worst-month PV energy supply (Wh/day)
PV Supply (Wh/day) = PV_Wp × PSH_worst_month × System_Efficiency
PSH must be auditable: state the month and data source (PVGIS / NASA POWER / Meteonorm / tender dataset), plus the project coordinates. If you can’t trace it, reviewers will treat it like a guess.
Instead of using one “magic efficiency,” show a simple derating chain that can be justified:
| Derating item (PV → LED) | Typical factor (example) | What it represents | How to justify in tender |
|---|---|---|---|
| PV temperature + soiling + mismatch | 0.80–0.90 | heat losses + dust/salt film + mismatch | site exposure + O&M cleaning assumption |
| Controller / MPPT efficiency | 0.94–0.98 | conversion + tracking | controller datasheet |
| Battery charge/discharge efficiency | 0.88–0.95 | coulombic + conversion losses | chemistry + conservative typical |
| Wiring + driver efficiency | 0.90–0.97 | cable + driver losses | driver spec + wiring design |
Example total efficiency (conservative): 0.85 × 0.95 × 0.90 × 0.93 ≈ 0.68
Now if PV = 150Wp, worst month PSH = 3.0:
PV supply ≈ 150 × 3.0 × 0.68 = 306Wh/day
If nightly load is 390Wh, you already see the problem: even when sun returns, the system can’t recover.
Step 3 — Autonomy is not just “days”; it’s survival + recovery
You need two checks:
A) Survival check (cloudy streak)
Battery_usable (Wh) ≥ Load_Wh/night × Autonomy_nights
Define “usable” explicitly:
- SOC window allowed by controller (e.g., 90%→20%)
- temperature + aging reserve
- BMS cutoffs
B) Recovery check (the part most bids miss)
After the cloudy streak, system must recover SOC within a reasonable period.
Recovery headroom = PV_supply – Daily_load
If PV_supply is only equal to the load, SOC never climbs, and failures repeat.
Practical tender rule:
If you claim 3 nights autonomy, also prove SOC rebound within ~2–5 “normal sun” days after the event.
4) How to Define “Battery Usable Wh” (so your autonomy claim survives audit)
Autonomy is based on usable energy, not nameplate.
A simple tender-friendly example:
- Battery nominal energy: 12.8V × 30Ah = 384Wh
- Usable SOC window (example): 90% → 20% = 70% usable
- Temperature factor (example note): 0.90
- Aging reserve (example): 0.85
Usable energy (example)
= 384Wh × 0.70 × 0.90 × 0.85
≈ 206Wh usable
Tender note: clearly state what defines the SOC window (controller protection strategy vs BMS cutoff). If you don’t state it, reviewers will assume it’s optimistic.
5) Tender Appendix: Standards & Evidence Mapping (Copy-Ready)
Purpose: Turn “claims” into an audit trail (BOQ → model → files → simulation → sizing).
A) Standards → Evidence Files → Where to show it
| Topic / What it proves | Commonly referenced standards (examples) | Evidence file(s) to attach | Where to show it (audit trail) | Reviewer notes |
|---|---|---|---|---|
| Road lighting targets (Avg/Min/Uniformity/Glare) | EN 13201 / CIE 115 / IES RP-8 | DIALux/Relux report (PDF) | DIALux “Requirements” + “Results Summary” | State road class + pass/fail table |
| Traceable photometrics | (Tender requirement) | IES/LDT files + matching datasheet | DIALux luminaire list + IES filenames + BOQ mapping | Files must match quoted model/optics |
| Luminaire performance is test-based | IES LM-79 | LM-79 report | Evidence pack “Photometric Tests” | Avoid “spec-sheet only” |
| Lifetime / lumen maintenance method | IES LM-80 + TM-21 | LM-80 report + TM-21 projection summary | Evidence pack “Reliability” | Mention maintained-performance assumptions |
| Luminaire safety | IEC 60598 | IEC 60598 / CB report (if available) | Evidence pack “Safety” | Useful for strict tenders |
| Battery safety | IEC 62133-2 | IEC 62133 report | Evidence pack “Battery compliance” | Reduces safety concerns |
| Battery transport | UN 38.3 | UN38.3 summary + MSDS | Evidence pack “Shipping compliance” | Often requested for clearance |
| PV module qualification | IEC 61215 / IEC 61730 | PV certificate + datasheet | Evidence pack “PV compliance” | Useful if PV is part of system |
| Pole / structure reference | EN 40 (when required) | Pole spec + wind load note (if asked) | Evidence pack “Structure” | Project-specific |
| Galvanizing/corrosion | ISO 1461 | Galvanizing statement + inspection | Evidence pack “Corrosion protection” | Often decisive in coastal regions |
| Corrosion test reference | ISO 9227 (if required) | Salt spray report (if available) | Evidence pack “Coating verification” | Don’t over-promise if not asked |
| Energy sizing method (autonomy is energy balance) | Engineering method statement | Autonomy sizing sheet (load, PSH, derating, usable window, recovery) | Sizing appendix + referenced in narrative | Core proof for rainy-season risk |
| Evidence mapping (BOQ → model → files) | Tender audit requirement | BOQ mapping sheet | BOQ mapping appendix | Prevents mismatch rejection |
B) File naming convention (10-second traceability)
IES/LDT
DIALux/Relux report
BOQ mapping
Autonomy sizing
- ProjectName-AutonomySizing-WorstMonthPSH-Derating-Recovery.xlsx
C) Copy-ready tender narrative sentences
Lighting compliance statement:
“This design targets the project-defined road lighting criteria (e.g., EN 13201 / CIE 115 / IES RP-8 as applicable). Calculation outputs are provided in the attached DIALux/Relux report, with luminaires referenced by traceable IES/LDT filenames.”
Autonomy compliance statement:
“Rainy-season autonomy is verified using a worst-month energy balance method. The sizing appendix documents: (1) load profile (Wh/night), (2) worst-month PSH (source + month + coordinates), (3) derating chain, (4) battery usable energy window, and (5) recovery margin check after cloudy streak events.”
6) Real-World Cases (Anonymized): why the math failed after 2–4 cloudy days
Case 1 — Coastal West Africa: “3-night autonomy” failed on the 4th cloudy day
Config: 8 m pole, 50 W, claimed 3 nights autonomy
Symptom: Works in dry season; rainy weeks trigger dimming/shutdown after ~3–4 cloudy days.
Common field details that quietly destroy autonomy (but rarely appear in bids):
- PV surface dulling from salt air + dust film after 2–4 weeks
- partial shading from trees/walls that only becomes obvious in wet season work conditions
Bad assumptions: annual average PSH used; no derating chain shown.
Reality (worst month):
- PSH worst month: 3.0
- PV: 150Wp
- Efficiency: 0.68
- PV supply ≈ 306Wh/day
- Nightly load (real profile): ~390Wh/night
Why it fails: PV supply < daily load ⇒ no recovery headroom ⇒ SOC keeps drifting down.
Fix applied: PV margin increased (e.g., 200Wp) + documented derating + added recovery check + energy-aware dimming for cloudy streaks.
Case 2 — Dust season: autonomy “looked OK” but recovery never happened
Cause: PV soiling reduced effective PV output beyond the spreadsheet assumption, making PV_supply ≈ daily_load.
Fix: add a soiling factor + cleaning/O&M assumption + restore PV headroom.
Lesson: survival without recovery margin causes repeat failures.
Case 3 — Cold nights: battery “capacity exists” but usable energy collapses
Cause: temperature derating + SOC protection window reduced usable Wh, triggering earlier cutoff.
Fix: conservative usable window + temperature note + verify controller cutoffs.
Lesson: autonomy is based on usable Wh, not rated Ah.
7) A Practical Sizing Checklist (one-page appendix you should attach)
Include these 6 items in your bid:
1) Project inputs (location, road type, pole height, spacing, qty)
2) Load profile table (Wh/night)
3) Worst-month PSH value + source + month + coordinates
4) Derating chain table (each factor + justification)
5) Battery usable energy assumption (SOC window, reserve, temperature, aging)
6) Recovery check statement (SOC rebound within X days)
8) Field symptoms that point to sizing (not hardware)
If you see these, suspect sizing first:
- stable in dry season, repeat failures in rainy season
- failure appears after a few cloudy days and repeats in cycles
- aggressive dimming even when components test “OK”
- SOC never reaches high levels after rain
Troubleshooting matters—but if the math is wrong, you’re treating symptoms.
FAQ (SEO + tender queries)
What is autonomy in solar street lighting?
Autonomy is the number of nights the system can meet its operating profile without sufficient charging, based on usable battery energy and documented assumptions.
Why do solar street lights fail after 2–4 cloudy days?
Because the system was sized using average PSH or incomplete losses; after cloudy streaks, PV supply cannot cover load + losses, so the battery doesn’t recover and protection triggers dim/off.
Should I size using average sun hours or worst-month PSH?
For rainy-season reliability and tender compliance, use worst-month PSH. Average PSH is only for annual estimation.
How do I prove autonomy in a government tender?
Provide an evidence pack: load profile, worst-month PSH (source + month + coordinates), derating chain, battery usable window, recovery margin check, plus BOQ → model → IES/LDT → DIALux/Relux mapping.
Next Step (High-Conversion CTA)
Rainy-season failures are not “weather problems.” They’re math + assumptions + traceability problems.
If you want a bid that survives review—and survives the rainy season—request an audit-ready engineering pack (24H):
- Worst-month sizing + derating chain
- Recovery margin (SOC rebound)
- Energy-aware dimming profile
- BOQ → IES/LDT → DIALux/Relux → quantity mapping
Request Engineering Pack (24H) →
Reviewed by: Solar Street Lighting Engineering Team, Sunlurio
We support EPC/government tenders with audit-ready deliverables: sizing sheets, BOQ mapping, IES/LDT photometrics, and DIALux/Relux reports.
