العربية
Español
Pусский
lingua italiana
Français
Deutsch
Portugues
Understand how DALI D4i, Zhaga Book 18 and TALQ connect in 2026, what each standard covers, and what buyers should verify in a smart LED street-lighting tender.
A practical guide for municipal buyers, consultants, contractors and lighting distributors specifying connected LED street-lighting systems.
Buying a “smart LED street light” used to mean comparing a control-ready driver, a socket and a vendor platform as separate decisions. That is no longer enough. Municipal owners and engineering teams increasingly need a chain of evidence showing that physical interfaces, device data and management software can work together throughout a long asset life. The 2026 collaboration among the DALI Alliance, TALQ Consortium and Zhaga Consortium gives buyers a clearer framework for specifying that chain.[1]
Why This Topic Matters in 2026
The three organizations began technical work in 2024 to unify data streams for smart street lighting. In 2026, their specifications introduced two named TALQ profiles: “DALI D4i Luminaire TALQ Zhaga” and “DALI D4i Sensors TALQ Zhaga.” The profiles map attributes from multiple DALI Parts into the TALQ environment so that selected data can be available in central management software.
For procurement teams, this is more than a new acronym set. It creates a more precise way to ask who is responsible for each layer, which products are certified and which data points must be visible after commissioning. It also helps separate a genuinely interoperable system from a luminaire that is merely described as smart-ready.
What DALI D4i, Zhaga and TALQ Each Do
DALI D4i: structured data at the luminaire
DALI D4i works closest to the luminaire. The DALI Alliance describes D4i as an extension of DALI-2 for intelligent, IoT-ready luminaires. Mandatory driver data specifications cover luminaire data (Part 251), energy data (Part 252) and diagnostics data (Part 253); D4i also defines integrated bus-power requirements and luminaire-mounted control devices. In practical terms, this is the structured information layer that can support asset records, energy monitoring and maintenance decisions.
Zhaga Book 18: the outdoor module interface
Zhaga Book 18 focuses on the interface between an outdoor luminaire and a sensor or communication module. Its value is mechanical and electrical standardization: a project can specify a recognized receptacle ecosystem instead of a permanently embedded proprietary node. Zhaga’s tender guidance emphasizes that the interoperability promise depends on certified products on both sides of the interface.
TALQ: interoperability at the management layer
TALQ operates higher in the system architecture. Its Smart City Protocol is an application-level interface between Central Management Software (CMS) and Outdoor Device Networks (ODN). The purpose is to let systems from different suppliers exchange a common set of information, helping cities avoid dependence on a single proprietary management interface. TALQ does not replace the field network; it standardizes how that network is represented and managed at the software layer.
| Layer | What it standardizes | Buyer-facing value | Tender evidence to request |
|---|---|---|---|
| DALI D4i | Driver, luminaire, energy, diagnostics and sensor data inside or at the luminaire | Structured data for commissioning, energy reporting and maintenance | Exact certified driver and control-device models, database listings and supported DALI Parts |
| Zhaga Book 18 / Zhaga-D4i | Mechanical and electrical interface between outdoor luminaires and sensor or communication modules | Replaceable or upgradeable nodes and a multi-supplier component ecosystem | Receptacle count and orientation, plus luminaire and node certification records |
| Outdoor device network | Project-specific transport between field nodes and the gateway | Carries field data and commands across the deployment | Network architecture, coverage, cybersecurity, commissioning and ownership plan |
| TALQ Smart City Protocol | Application-level exchange between an Outdoor Device Network and Central Management Software | Interoperability at the management platform and reduced dependence on a proprietary API | TALQ-certified solution and required profiles, including the 2026 DALI D4i Luminaire/Sensors TALQ Zhaga profiles |
Source: compiled from DALI Alliance, TALQ Consortium and Zhaga procurement materials.
How the 2026 Profiles Close the Data Gap
Before the joint mapping, a project could have standards-compliant components yet still face uncertainty about which driver or sensor fields would appear in the CMS. The new profiles define required and optional functions for two operational scenarios: D4i luminaires and sensors attached to Zhaga-D4i luminaires. The joint leaflet lists control-gear identification and configuration, luminaire asset data, energy measurements, diagnostic and maintenance information, and standardized sensor data among the mapped scopes.
That creates a traceable path from the driver and sensor to the operator screen. It does not guarantee that every installation will expose every possible data point. Buyers must identify the required attributes, select compatible certified products and confirm that the chosen TALQ-certified solution supports the relevant profile. Certification records and an acceptance test remain essential.
How the smart-lighting standards stack connects
Simplified procurement view based on the 2026 DALI-TALQ-Zhaga joint profiles
DALI D4i
- At the luminaire
- Asset and product data
- Energy and diagnostics
- Sensor data
Zhaga Book 18
- Outdoor module interface
- Sensor or communication node
- Replaceable component path
- Certified ecosystem
Outdoor Network
- Node-to-gateway transport
- Wired or wireless network
- Gateway or ODN integration
- Project architecture
TALQ + CMS
- Standardized data profiles
- Central management view
- Control and monitoring
- Multi-vendor operation
The 2026 joint profiles map DALI attributes into TALQ for use in the CMS. Certification remains specific to the offered product and system configuration.[1]
A Practical Smart Street-Lighting Tender Checklist
Start with outcomes and data, not brand labels. State which points must be controlled, which alarms must be reported, what asset fields must be stored and which energy values must appear in the CMS. Then assign a standard and certification requirement to each layer.
- Define the luminaire evidence. Request the exact driver model, supported DALI Parts and any D4i certification record.
- Specify the physical interface. Define the number and orientation of Zhaga Book 18 receptacles and verify the proposed luminaire and node in the relevant certification databases.
- Name the management profile. Request evidence that the offered CMS/ODN solution is TALQ-certified and supports the required 2026 profile. Zhaga publishes model tender language, while TALQ provides a tender template.
- Test the completed chain. Verify dimming commands, device identification, operating hours, energy readings, fault reporting, sensor values and component replacement during factory and site acceptance.
- Plan for supplier changes. Document what happens if the communication node, gateway or CMS supplier changes during the contract period.
Connecting the Standards to Alite Street-Lighting Products
Zhejiang Alite Lighting Co., Ltd. presents an outdoor-lighting portfolio that includes project street lights, flood lights, high-bay lights, garden lights, solar lights and stadium lights. Its website also emphasizes in-house R&D, product customization, quality inspection and project support. For a standards-led smart street-lighting inquiry, the most relevant public product pages are the ASL30 and ASL31 series.
| Published product data | ASL30 | ASL31 | Procurement interpretation |
|---|---|---|---|
| Series wattage shown in tables | 10-200 W | 10-200 W | Select the size only after photometric design; do not substitute wattage for illuminance and uniformity criteria. |
| Published efficacy | 190 lm/W | 200 lm/W | Verify the exact ordered configuration, test basis and tolerances in the project submittal. |
| Optics and CCT | Type I, II and III; 2400-6500 K | Type I, II and III; 2200-6500 K | Match distribution and CCT to the road class, local policy, glare limits and environmental goals. |
| Ingress and impact options | IP65-IP67; IK08-IK10 | IP65-IP66; IK08-IK10 | Request the exact rating for the quoted SKU and supporting test documentation. |
| Published smart-related feature | Built-in light-sensor option | Marketed for smart-city road projects | Neither reviewed page states D4i, Zhaga-D4i or TALQ certification. Treat those as project options to confirm, not assumed features. |
Source: Alite ASL30 and ASL31 website product pages, accessed 28 August 2026.Published options may vary by configuration; confirm the final specification in the quotation and submittal.
Important configuration note
The ASL30 page lists a light-sensor option, selectable Type I, II and III distributions, easy driver-side access and published efficacy of 190 lm/W. The ASL31 series table lists up to 200 lm/W, Type I to III distributions and multiple IP/IK options. The reviewed pages do not state D4i, Zhaga-D4i or TALQ certification. Send Alite the intended control architecture and request written confirmation of the precise driver, receptacle, node and certification package available for the proposed SKU.
This specification-first approach gives Alite’s R&D and customization team a clearer target. It also protects the buyer: photometry, environmental ratings, control readiness and data interoperability can be evaluated as separate, documented requirements instead of being compressed into the word “smart.”
Frequently Asked Questions
Is a Zhaga socket the same as D4i certification?
No. Zhaga Book 18 defines the interface, while D4i defines power and data functions for intelligent luminaires and control devices. Zhaga states that its interoperability promise relies on certification on both sides of the Zhaga-D4i interface.[3]
Does TALQ connect directly to every street-light driver?
Not typically. TALQ standardizes communication between the CMS and the Outdoor Device Network. The field node, network and gateway remain part of the project architecture; the 2026 profiles help map relevant DALI data into the TALQ-managed environment.[1][4]
Can a smart-ready luminaire be treated as interoperable?
Only after the proposed configuration is verified. The tender should identify the driver, receptacle, sensor or communication node, network, gateway, CMS, profiles and certification status. A marketing label is not a substitute for that evidence.
What should buyers send Alite with an RFQ?
Provide the road geometry and photometric targets, electrical conditions, CCT and environmental requirements, control concept, required data points, preferred interface, certification requirements and acceptance-test plan. Alite can then match the request to a street-light series and confirm which configured options are available.
Conclusion
The 2026 DALI D4i-TALQ-Zhaga profiles make the smart street-lighting standards stack easier to specify from the luminaire to the central platform. The strongest tender will still do three things: define the data required, verify certification at each relevant layer and test the complete offered configuration. For buyers evaluating Alite street lights, ASL30 and ASL31 provide documented road-lighting platforms to discuss, while smart-interface and protocol requirements should be confirmed against the exact project configuration before award.
