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.

Onde este guia se encaixa

TL;DR (Regras de decisão)

  • 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.
  • Regra de aquisição: if the supplier cannot provide a clear “data points + alarms + offline mode + security + SLA” pack, the quote is Não comparável / Alto risco.

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)

  • Exigir um connectivity plan: how devices connect, how they are provisioned, and how outages are handled.
  • Exigir um 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)
  • Planilha de orçamento de energia: include smart module consumption in Wavg/Wh-night assumptions

Use essas páginas para manter o dimensionamento honesto:

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.
  • Disputas de garantia: no logs/traceability → enforce serial mapping + commissioning record + maintenance logs.

Related diagnosis/control pages:

PASS/FAIL procurement rules (smart edition)

Marcar um lance FAIL (não comparável/alto risco) se não tiver nenhum desses itens:

  • Smart Spec Pack (data points + controls + alarms + offline mode + security/data ownership)
  • Planilha de orçamento de energia including smart module impact (Wavg/Wh-night assumptions)
  • Resultados do comissionamento (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)

Deseja uma verificação rápida da sanidade da engenharia?

Compartilhe sua classe de estrada, altura do poste, lux/uniformidade alvo e suposições de PSH do pior mês.

Entre em contato com a Inlux Solar →

Próximas etapas (manter seu projeto pronto para a licitação)

Certifique-se de que seu projeto de iluminação pública solar atenda a todos os padrões de aquisição e engenharia.

Modelos e evidências

Lista restrita de um tipo de sistema

Voltar para Todos os Guias Hub →

PERGUNTAS FREQUENTES

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.