Smart Solar Street Lights (LoRa / NB-IoT) — Monitoring, Control & Procurement Rules

“Smart solar street light” is only valuable if it reduces operational cost and failure time-to-repair. The real deliverable is not the radio label (LoRa or NB-IoT) — it’s an auditable O&M system: what data you get, how alarms work, who owns the network/data, what happens when connectivity fails, and how warranty claims are proven. This guide gives a tender-ready spec, PASS/FAIL rules, and copy/paste RFQ clauses.

Where This Guide Fits

TL;DR (Decision rules)

  • Buy outcomes, not buzzwords: define O&M goals (downtime reduction, battery health visibility, theft alerts, dimming control).
  • Network choice is a business decision: LoRa often implies private/managed network options; NB-IoT often implies carrier-managed connectivity. Choose by ownership, coverage, and long-term operating cost.
  • Smart features change the energy budget: reporting interval and radio uptime must be included in Wavg/Wh-night assumptions.
  • Procurement rule: if the supplier cannot provide a clear “data points + alarms + offline mode + security + SLA” pack, the quote is Not Comparable / High Risk.

Key internal references (for reliability and evidence):

What “smart” should deliver (define your use cases first)

Pick the functions you will actually use. Otherwise you pay for a dashboard you never operationalize.

Core use cases (most projects)

  • Health monitoring: battery voltage/SOC indicator, charging status, controller status, fault flags
  • Energy visibility: basic daily charge/discharge signals to catch undersizing early
  • Remote dimming control: time schedule updates and audit trail of changes
  • Alarm workflow: outage / early shutoff / abnormal behavior notifications

High-value use cases (specific sites)

  • Theft/tamper alerts: where theft risk is real and response is feasible
  • Asset inventory: serial-to-location mapping and lifecycle management
  • Maintenance evidence: logs that support warranty claims and vendor accountability

Related pages to standardize evidence and operations:

LoRa vs NB-IoT — how to choose (procurement lens)

Don’t argue radio tech in a vacuum. Decide using ownership, coverage, operating cost, and deployment complexity.

Choose based on these decision questions

  • Who owns the network? (your team / integrator / carrier)
  • What happens if coverage is weak? (site survey method and acceptance criteria)
  • What is the recurring cost model? (connectivity fees, platform fees, user seats)
  • How will you support it for years? (SLA, firmware updates, device provisioning)

Procurement rule (practical)

  • Require a connectivity plan: how devices connect, how they are provisioned, and how outages are handled.
  • Require a site acceptance method: how you verify coverage/connectivity during commissioning.

Smart features must be included in the energy model

Smart devices consume energy. If you ignore this in the energy budget, rainy-season performance can degrade.

What to force suppliers to disclose

  • Reporting interval: how often data is sent (and if it changes by mode/season)
  • Radio behavior: sleep/wake strategy (high level disclosure is enough)
  • Energy budget sheet: include smart module consumption in Wavg/Wh-night assumptions

Use these pages to keep sizing honest:

Minimum “Smart Spec Pack” (what every bidder must submit)

If a supplier cannot submit this pack clearly, you cannot operate or enforce warranty later.

A) Data points (what you can see)

  • Device ID and serial number mapping support
  • Lighting status and basic fault flags
  • Battery status indicators (at minimum: voltage/SOC indicator) and charging status
  • Controller status indicators

B) Control functions (what you can change)

  • Time dimming schedule update (and confirmation of applied settings)
  • Mode configuration disclosure (time/PIR/hybrid if applicable)
  • Audit trail: who changed what, when (minimum requirement for accountability)

C) Alarm rules and workflow (how you act)

  • Outage/early shutoff alerts (what triggers an alert)
  • Connectivity loss handling (how it is reported and escalated)
  • Alarm delivery method disclosure (email/app/etc.) and acknowledgement workflow

D) Offline mode (non-negotiable)

Connectivity will fail sometimes. The light must remain safe and predictable.

  • Declare the offline lighting behavior (fallback schedule) when comms are lost
  • Declare how long local settings persist and how they are restored

E) Security & data ownership (must be explicit)

  • Who owns operational data?
  • Who can access devices and dashboards?
  • How credentials are managed (at least “role-based access” disclosure)
  • Firmware update responsibility and policy (who pushes updates, when)

Commissioning & acceptance (make smart features auditable)

Minimum commissioning deliverables

  • Serial-to-location mapping (device ID + pole ID + GPS or address reference)
  • Connectivity verification record (pass/fail method)
  • Dimming profile settings record (mode + schedule/PIR settings)
  • Alarm test: demonstrate at least one alert path and acknowledgement

Use these pages to standardize handover evidence:

Common failure patterns in “smart” projects (and how to prevent them)

  • “Smart drains the battery”: reporting is too frequent or energy model ignores comms consumption → enforce Wavg disclosure.
  • Dashboard exists but no action: alarms are not defined and nobody owns the workflow → enforce alarm rules + SLA.
  • Connectivity surprises: no acceptance test method → enforce commissioning connectivity test.
  • Warranty disputes: no logs/traceability → enforce serial mapping + commissioning record + maintenance logs.

Related diagnosis/control pages:

PASS/FAIL procurement rules (smart edition)

Mark a bid FAIL (Not Comparable / High Risk) if it lacks any of these:

  • Smart Spec Pack (data points + controls + alarms + offline mode + security/data ownership)
  • Energy budget sheet including smart module impact (Wavg/Wh-night assumptions)
  • Commissioning deliverables (serial-to-location mapping + dimming settings record + connectivity test)
  • Warranty SLA and a clear support boundary (who supports device/network/platform)

Copy/Paste RFQ Clauses (Smart Solar Street Lights)

Clause 1 — Smart Spec Pack (mandatory)

Supplier shall submit a Smart Spec Pack including: (1) data points available, (2) control functions, (3) alarm rules and delivery workflow, (4) offline fallback behavior, and (5) security and data ownership statement. Quotes without this pack are not comparable.

Clause 2 — Energy model includes smart consumption

Supplier shall provide an energy budget sheet (Wavg, runtime hours, Wh/night) that includes smart module reporting assumptions (reporting interval and operational behavior). Autonomy and rainy-season sizing shall be consistent with these assumptions.

Clause 3 — Commissioning and acceptance evidence

Supplier/contractor shall deliver commissioning evidence including serial-to-location mapping, connectivity verification record, dimming settings record, and alarm test demonstration. These deliverables are required for acceptance and warranty enforceability.

Clause 4 — Support boundary and SLA

Supplier shall define support boundaries (device, network, platform) and provide an SLA for response and diagnosis. Supplier shall clarify responsibility for firmware updates and platform availability.

Clause 5 — Data ownership and access control

Supplier shall state who owns operational data and provide an access control statement (roles/users). Credentials and admin access responsibilities must be defined.

Request Smart Lighting RFQ & Acceptance Toolkit

Get the editable toolkit to standardize smart requirements and prevent “dashboard-only” projects:

  • Smart Spec Pack template (data/control/alarms/offline/security)
  • Connectivity acceptance checklist (commissioning pass/fail)
  • Alarm workflow template (ownership + escalation + SLA)
  • Energy budget add-on sheet (smart reporting assumptions)
  • Warranty evidence checklist (serial mapping + logs)

Want a quick engineering sanity check?

Share your road class, pole height, target lux/uniformity, and worst-month PSH assumptions.

Contact Inlux Solar →

Next Steps (Keep Your Project Tender-Ready)

Ensure your solar street light project meets all procurement and engineering standards.

Templates & Evidence

Shortlist a System Type

Back to All Guides Hub →

FAQ

LoRa or NB-IoT — which is better?

Neither is “always better.” Choose based on network ownership, coverage verification method, operating cost model, and long-term support. Procurement should require a clear connectivity plan and acceptance test.

Do smart features reduce battery life?

They can if reporting is too frequent or smart module consumption is ignored in the energy model. Require disclosure of reporting assumptions and include it in Wavg/Wh-night sizing.

What is the minimum acceptance evidence for a smart project?

Serial-to-location mapping, connectivity verification record, dimming settings record, and at least one tested alarm path with acknowledgement workflow.