Smart Street Lights: Same RFQ, 10 Suppliers — Very Different Answers

I recently ran a simple test.
 I sent the same RFQ to 10 different street lighting suppliers. The requirement was straightforward: smart street lighting for urban roads, with remote management and future IoT scalability.

I intentionally kept the definition broad — just “Smart Street Light.”

The responses were unexpectedly inconsistent.

1. “Smart” has no industry consensus

Across the 10 replies, the meaning of “smart” varied significantly:

● Some suppliers defined a photocell switch as “smart.”

● Others added a timer and called it intelligent control.

● A few offered app-based control, but with closed systems that cannot integrate with external platforms.

● Only a small number provided true system-level capability: individual lamp control, cloud-based management, and open communication protocols.

This is not an isolated case.
 According to industry data, only about 35% of global street lights currently support individual lamp-level control (Persistence Market Research, 2025, L3, medium confidence).

This suggests that most products marketed as “smart street lights” are still far from true system-level intelligence.

2. Supplier capability segmentation

Based on the responses, the 10 suppliers can be broadly grouped into three categories:

Category 1: Basic Automation (~40%)
 Limited to photocell or timer-based switching. No communication module, no remote control. Essentially traditional lighting with basic automation logic — not a smart system.

Category 2: Semi-Smart Systems (~30%)
 Equipped with GPRS or 4G modules, with basic app control and remote switching. However, systems are closed, cannot connect to city-level platforms, and lack third-party integration. Functional, but not scalable.

Category 3: System-Level Smart Lighting (~30%)
 Support individual lamp control (each luminaire has a unique address), cloud-based platforms, and open communication protocols (such as MQTT, CoAP). These are the only suppliers with real project deployment capability.

3. The real gap is not hardware, but system architecture

Across suppliers, LED chips, IP ratings, and power specifications are relatively similar.
 The real differentiation lies in system architecture, mainly in three aspects:

Control granularity
 Low-end solutions operate at circuit or feeder level. Advanced systems support individual lamp control, enabling independent dimming and fault detection.

Communication architecture
 Low-end systems have no communication, or rely on basic SMS modules. Advanced systems support NB-IoT, 4G, or LoRa, allowing flexible deployment depending on local network conditions.
 MQTT, designed for IoT environments, enables stable data transmission under low bandwidth and low power conditions (MDPI/PMC, 2025, L3, high confidence), which is critical in emerging markets.

Platform capability
 Basic solutions lack a platform or rely on local software. Advanced systems provide cloud platforms, data visualization, remote O&M, and multi-user access control.

4. A widely underestimated risk: long-term maintenance

In multiple infrastructure projects across emerging markets, a recurring issue appears:
 the system works initially, but becomes unmanageable within two years.

Typical reasons:

● The original supplier cannot provide long-term support

● The system uses closed protocols, preventing third-party takeover

The outcome is predictable: rising maintenance costs, gradual system degradation, and accelerated asset value loss.

Therefore, when evaluating a smart lighting solution, protocol openness matters more than the “smart” label itself.
 A closed system may reduce upfront cost, but it creates long-term dependency and operational risk.

5. Standard RFQ checklist (for Chile market practice)

Based on this test, I developed a technical checklist for supplier evaluation.
 It is recommended to send these questions directly during procurement and require written responses:

Control & Management

● Does the system support individual lamp control? (Yes / No)

● Does it support remote switching and dimming?

● Does it provide real-time fault alerts?

Communication Capability

● Which communication technologies are supported? (NB-IoT / 4G / LoRa)

● Is local data buffering available during network outages?

Platform Capability

● Is a cloud-based management platform provided?

● Are APIs available for integration?

● Is multi-user role and permission management supported?

Protocol Openness

● Which communication protocols are used? Are they standard (e.g., MQTT)?

● Is third-party system integration supported?

Operation & Maintenance

● Does the system support OTA (remote firmware updates)?

● Is long-term maintenance service provided? What is the service duration?

6. Conclusion

“Smart street lighting” is currently more of a marketing label than a standardized product category.

Among the 10 suppliers tested, fewer than 30% demonstrated true system-level capability.

From a procurement perspective, the focus should not be on whether a product is labeled “smart,” but on:

● Is control granular down to each individual lamp?

● Is the system scalable?

● Are protocols open?

● Who will maintain the system in five years?

Smart street lighting is not a product — it is a system.
 And most suppliers are not there yet.