At a smart lighting tender review, the first questions are rarely about the energy-saving rate. They are sharper: Can the system integrate third-party devices? Can it merge with the city's existing management, utility and sanitation platforms? Can it connect to the operator's own system?

These three questions point to the same concern — can the digital assets a city has already built survive the upgrade? The market has moved on from "whether to become intelligent" to "whether the new system can coexist with what is already in place."

This bar is higher than any energy-saving target. For IOTCOMM, the answer needs no claim of being first — only a frank account of what systems we have integrated, how, and what we learned the hard way.

From "whether to deploy" to "whether it coexists": the requirement has changed

In the past, a lighting system was judged on luminaires, communications and energy savings. Today, more and more owners shift the focus upstream to the system boundary — who owns the data, who controls the interfaces, and who decides how far the system can be extended.

The reason is simple. Urban lighting is only one professional slice of the city's operations: above it sit the city operations platform and the IoT perception centre; beside it run parallel systems for urban management, pipe networks, sanitation and traffic; beneath it lie years of phased, multi-vendor legacy devices. Any lighting system that cannot be integrated becomes a new silo. However well it performs on its own, it never enters the city's incident-handling chain.

When lighting data cannot flow into the city's operational metrics, lighting rate and fault-response time cease to be accountable governance indicators — and the premium paid for intelligence is never realised.

This is why IOTCOMM treats platform openness as an architectural premise, not a delivery-phase option.

Policy, regulation and procurement: openness is now the entry ticket

Three threads are turning system integration from a technical option into a compliance requirement.

Policy: The Action Plan for Deepening Smart City Development and Advancing City-wide Digital Transformation (NDRC & NDA Document [2025] No. 1306) requires interconnection of urban operations, comprehensive governance, traffic management and emergency management systems.

Regulation: Wuhan's Interim Measures for City-wide Unified Management ("Yiwangtongguan"), in effect since 1 September 2026, makes "all data that should be aggregated, aggregated" a statutory duty; lighting rate and energy savings are elevated to city governance indicators.

Procurement: Public tenders now carry clauses such as "provide data and control interfaces free of charge and unconditionally" and "open the protocol ports; do not restrict access by terminals of other brands," with classified protection filing required.

Openness is no longer a differentiator — it is the entry ticket.

What systems has IOTCOMM integrated?

Policy sets openness as a hard threshold, but "can connect" and "connects reliably" are two different things. What the Hotu IoT platform has been repeatedly tested on over the years is the latter.

Upward — governed by the city-level platform.

In Chengdu's "Smart Rongcheng" system, IOTCOMM was the core technology partner for the urban lighting IoT perception module: about 180,000 streetlights, 210,000+ control nodes and 3,000+ streets are connected. The point is not the dashboard — it is that data gets out. Through standardised interfaces the platform links directly to the 12345 hotline, so that requests, fault alarms and work orders flow on one chain. Monthly lighting rate reaches 99.38% with around 50% overall energy saving.

Lateral — linked to the production system.

At Xiamen Haitian Terminal, the Hotu platform was deeply integrated with the Terminal Operating System (ITOS) across 70 high-mast lights, parsing operational commands to drive lighting strategy: 100% on when a work zone is active, "8-on-4-off" cyclic dimming when idle, and one third closed 30 minutes after operations end. Overall energy saving exceeds 35% — lighting shifts from "time-clock switching" to "event-driven by production."

Outward — merged with the overseas municipal platform.

In Bangkok, Thailand, 30,000 LTE Cat.1 controllers were deployed and merged into the Bangkok Metropolitan Administration (BMA) existing platform, sparing the owner from maintaining a parallel system.

Downward — legacy heterogeneous devices onboarded.

The platform is compatible with PLC, RF, LoRaWAN, NB-IoT, LTE Cat.1, Wi-SUN, Zigbee and RS485, and can bring other vendors' controllers under unified management via protocol or API.

From the outset, Hotu was architected not as a closed system that "only manages its own lamps," but as an open node that can be governed from above, called by neighbouring systems, absorbed across borders, and backward-compatible with legacy devices. The scale of Chengdu, the industrial precision of Haitian, the cross-border variance of Bangkok and the mixed standards of legacy fleets are all validated on one platform — not by the luck of individual projects, but because integration is treated as a product capability, not a patch applied at delivery.

Five pitfalls we learned: a working interface is not a closed loop

These five pitfalls are common across the industry. The difference: most vendors trip over them on every project, whereas IOTCOMM has turned them into standard actions — field-alignment tables, NTP time sync, indicator definitions, compliance scheduling and closed-loop ownership — now hard steps planned before every integration begins. The pitfalls were not wasted; they became the margin that later projects no longer relearn.

1Complete contract, missing field semantics. The other side provides an API doc, but fault enums, status definitions and coordinate systems don't match reality. Our response: produce a field-level alignment table signed by both parties, with the coordinate baseline (GCJ-02 / WGS-84) fixed first.

2Unsynchronised time bases. Cross-system clock drift corrupts work-order sequencing and interval metering. Our response: unified NTP time sync, plus time-sanity checks before alarms are stored.

3Undefined indicator definitions. Online rate and lighting rate are calculated differently by different departments; denominators, offline thresholds and periods are never defined, so data never reconciles at acceptance. Our response: issue an indicator definition document before integration, written into the contract appendix.

4Security compliance left to the end. Government-network isolation, gatekeeper relays, classified-protection filing and localisation adaptation are not materials patched before acceptance — they are critical-path items that blow the schedule. Our response: architecture supports private deployment and data-on-premise, with compliance scheduled into the project plan.

5Interface connected ≠ business closed. The interface works, yet the two systems still run in parallel and events are still moved by hand. Our response: the incident loop must land on one chain — received, alarmed, dispatched, fed back, end to end.

Turn openness into verifiable terms: six questions to ask

If openness cannot be verified, it is only an adjective. We suggest requiring suppliers to answer these six in writing at tender or selection stage:

1. Which types of upstream platforms and production systems have you integrated? Can you name the object, interface form and data flow?

2. Are the interfaces bidirectional? Which channels carry downstream control commands and upstream status alarms?

3. Can the owner's existing devices (including third-party brands) be onboarded? Is there extra charging?

4. Can data stay on-premise? Do you support private deployment? Can you complete classified-protection filing?

5. Who defines the operational metrics? Are the calculations for online rate and lighting rate confirmed in writing?

6. After a platform upgrade, who owns interface compatibility?

Any supplier with real integration capability should be able to answer these. Those who cannot will likely pay tuition during delivery.

Technologies converge; interfaces do not. That is why, over sixteen years, IOTCOMM has treated integration not as one-off delivery but as a reusable, verifiable product capability — a lighting system's long-term value lies less in how smart it is than in who can call it, whose data it feeds, and whether it can live inside systems a city has already built.

Frequently asked questions

Q: Can a smart lighting control platform integrate third-party devices?
A: Yes. The Hotu IoT platform is compatible with eight communication standards and can bring other vendors' controllers under unified management via protocol or API.

Q: How does smart street lighting connect to the city's unified management platform?
A: Through standardised data interfaces that feed lighting data into the city operations platform. In Chengdu, the platform links directly to the 12345 hotline so requests, alarms and work orders flow on one chain.

Q: What integration questions should I ask a vendor?
A: Six — which upstream platforms and production systems they have integrated, whether interfaces are bidirectional, whether legacy and third-party devices can be onboarded, whether data can stay on-premise, who defines the metrics, and who owns compatibility after upgrades.

Let's talk

If you're looking to reduce energy costs, improve grid stability, or modernise urban operations, our team is here to help. Contact us to discuss your smart lighting project.

Tel: +86 592 252 0936　｜　Email: oversea_sales@iotcomm.com　｜　Web: www.iotcomm.com