NEMA vs Zhaga for smart street lighting

Last updated: 14 May 2026 / 9 min read

When designing smart street lighting systems, the question of which socket to use for linking the control unit (controller) to the luminaire — NEMA or Zhaga — inevitably arises.
This is not merely a matter of mechanical interface. The socket determines how the controller integrates with the luminaire: whether it operates as a standalone device with its own measurements and logic (as with NEMA), or as part of a system dependent on the driver and its capabilities (as with Zhaga).

In practice, this decision is directly tied to the control architecture: the drivers used, the protocols, and the method of data collection.

This is why sockets and protocols cannot be considered in isolation — the choice between NEMA and Zhaga effectively defines the architecture of the entire lighting management system.

This article examines how the choice between NEMA and Zhaga affects:

• available control protocols (0–10V, DALI-1, DALI-2, DALI D4i);
• the location of "intelligence" (in the driver or in the controller);
• the composition and quality of collected data;
• overall project costs.

How control protocols affect NEMA and Zhaga architecture

Before comparing NEMA and Zhaga sockets, it is necessary to understand the control protocols.
The protocol determines:

• what data can be retrieved from the luminaire,
• how control is implemented,
• and where the system "intelligence" resides — in the driver or in the controller.

The socket, in this chain, is simply the means of implementing the chosen architecture.
The correct choice therefore begins not with the socket, but with an understanding of what each protocol can and cannot do.

0–10V: The baseline — Brightness control only

The 0–10V analog signal is the simplest method of lighting control. The voltage on the control wire determines the dimming level: 

• 10V corresponds to maximum brightness,
• 0V to minimum (typically not a full switch-off).

This type of system does not support addressing: all luminaires connected to a single channel behave identically. There is no feedback — the system receives no confirmation that a command has been executed and has no visibility into equipment status.
The main advantage is low cost and simplicity of implementation. Functionally, however, this solution is limited to basic dimming tasks.

DALI-1: Individual addressing with basic diagnostics

DALI-1 (Digital Addressable Lighting Interface) introduces a digital control bus and enables individual devices within a single line to be addressed.
This makes it possible to:

• control luminaires individually or in groups,
• retrieve basic information about equipment status.

Typical feedback signals include:

• lamp or light source failure,
• driver fault,
• loss of power,
• dimming errors.

Compared to 0–10V, the system becomes controllable and partially observable, but diagnostic depth remains limited.
One more characteristic of DALI-1 was limited standardization of behavior across devices from different manufacturers. In practice, this meant that the same dimming command could produce different results. 

For example, when a brightness level of 50% was set, one 100W luminaire might draw approximately 40W, while another drew approximately 60W. Both devices formally received the same command, but actual behavior depended on the driver implementation of the specific manufacturer. This made it difficult to build predictable and uniform lighting systems, particularly in large projects with mixed equipment.

DALI-2: Standardization of behavior and sensor support

DALI-2 addresses the key limitation of the first generation — inconsistent behavior across devices from different manufacturers.
In this version:

• both commands and device responses are standardized,
• predictable dimming levels are guaranteed,
• standards for sensors are introduced (discrete and analog),
• diagnostics are expanded.

The system is now capable not only of detecting a fault, but of identifying its cause — for example, overheating, a short circuit, or an open load.
This makes DALI-2 better suited for large-scale projects and installations with mixed equipment.

DALI-2 + D4i: Telemetry and per-luminaire data

D4i is an extension of DALI-2 that moves operational data collection to the driver level.
In this configuration, the luminaire becomes a source of telemetry, including:

• power (W),
• energy consumption (kWh),
• voltage and current,
• temperature,
• operating hours,
• number of switch-on cycles.

This architecture enables:

• accurate energy auditing,
• predictive maintenance,
• integration of lighting into broader asset management systems.

However, this comes at the cost of a higher driver price — on average approximately 30% more than DALI-1 and DALI-2 drivers.

The differences between protocols lie not only in the method of control, but also in the level of available data and diagnostics.

This directly affects system architecture:

• when using D4i, consumption data is generated at the driver level,
• when using 0–10V and basic DALI-1, consumption data is handled at the controller level.

This is why the choice of protocol is directly linked to the choice of socket — which will be examined in the following section.

Comparison of 0–10V, DALI-1, DALI-2 and D4i protocols

How control protocols influence NEMA and Zhaga architecture

The previous section established that the control protocol determines where data is generated and where system logic resides — in the driver or in the controller.
This leads directly to the question of socket selection.
The socket is not simply a physical interface — it is the point at which the controller integrates into the system architecture. Depending on the chosen solution:

• either the controller remains an autonomous device with its own measurements and logic,
• or it becomes part of a system dependent on the driver and its capabilities.

These two approaches are what the NEMA and Zhaga standards represent.

NEMA vs Zhaga: The fundamental difference

The NEMA (ANSI C136.41) and Zhaga (Book 18) sockets serve the same purpose — connecting the control unit to the luminaire.

The key difference lies in the power architecture and distribution of functions:
NEMA

• Supply voltage: 110–230V AC,
• Controller is an autonomous device,
• Includes metering, relay, and control logic.

Zhaga (Book 18)

• Supply voltage: 12–24V DC (from the driver),
• Controller is dependent on the driver,
• Architecture oriented toward DALI-2 D4i integration.

The difference between NEMA and Zhaga is therefore not just a matter of socket — it is a fundamental difference in how the entire control system is built.

Zhaga architecture: technical advantages and constraints

Zhaga is often positioned as the more modern solution. From a conceptual standpoint, this is valid:

• low-voltage interface,
• compact form factor,
• standardized integration,
• oriented toward D4i.

However, these advantages are only realized within the appropriate architecture and come with a number of limitations.

Advantages of Zhaga

1. Separation of power switching and control
   The controller does not switch the power circuit — the load is handled entirely by the driver, regardless of luminaire wattage.
   In practice, this rarely presents a limitation for NEMA:
   - most NEMA controllers support up to ~1kW,
   - typical street luminaires are 70–250W,
   - luminaires above 800W generally use an additional external driver.

2.  Simpler controller design

• no AC/DC converter,
• no built-in metering modules.

This simplifies the controller hardware and can reduce device cost.
In practice, however, the cost of NEMA and Zhaga controllers varies significantly by manufacturer. In some cases, devices of the same class are comparably priced.
That said:
→ savings on the controller are offset by the higher cost of D4i-compliant drivers (~+30%)

3.  Low-voltage supply (12–24V DC)
Reduces interface isolation requirements and simplifies integration.

NEMA architecture: driver independence and system-level control

1. Support for multiple protocols and drivers. 
NEMA controllers can operate with:

• 0–10V,
• DALI-1,
• DALI-2,
• D4i.

The key point: part of the system functionality — metering and logic — is implemented in the controller itself. This allows:

• use of lower-cost drivers,
• independence from D4i,
• flexible system design.

Given that the majority of drivers on the market do not support D4i, this has significant practical implications.

2. Full power disconnection (via relay)
0–10V and DALI protocols do not allow the luminaire to be fully de-energized — a residual standby consumption of approximately 0.3–1W remains.
At city scale, this becomes a meaningful factor.
Example:

• 75,000 luminaires,
• 1W each → 75kW of continuous load
  → ~€6,750 per month
  → ~12.4 tonnes of CO₂

The relay in a NEMA controller eliminates this consumption entirely.

A comparable approach can be used in Zhaga-based systems — by cutting the line at the cabinet level via a segment controller. However, when power is fully removed, all devices on the line lose communication with the system, which limits monitoring and remote control capability during the disconnection period.

3. Fault tolerance and diagnostics

• NEMA: the controller is powered independently → remains accessible when the driver fails → can report the fault.
• Zhaga: the controller is powered by the driver → loses power if the driver fails → becomes unreachable. 
  In practice, this is typically registered as a loss-of-communication or device-unavailable event, which indicates that a fault exists at that point. 
  However, the level of diagnostics and the ease of remotely identifying the root cause are generally lower than with independently powered solutions.

This directly affects maintenance operations and monitoring capability.

4. PLC support
NEMA controllers can use PLC (power line communication).
This enables:

• system control without radio infrastructure,
• use of existing power networks.

Zhaga solutions are generally oriented toward:

• RF / mesh,
• GSM / NB-IoT.

The reason lies in the interface architecture: Zhaga Book 18 typically uses low-voltage DC power supplied by the driver, along with control and data interfaces between the driver and controller, rather than a direct connection to the mains power line. As a result, the controller does not have the same native access to the power network through which PLC is conventionally implemented.

NEMA vs Zhaga: Technical differences and system architecture

How to choose between NEMA and Zhaga

The choice between NEMA and Zhaga is determined by the project architecture and system requirements. If the priorities are:

• flexibility and component independence,
• support for different driver types,
• reduced total system cost,
• straightforward maintenance and diagnostics,

then NEMA will be the appropriate choice in most cases.

If the project is oriented toward:

• collection of detailed additional driver-level data per luminaire — beyond energy consumption — specifically temperature, driver diagnostics, and power supply for sensors (where Zhaga-mounted sensors are a mandatory requirement),
• use of DALI-2 + D4i,
• a compact node form factor for architectural reasons,

then a Zhaga-based architecture becomes the logical choice.

In engineering practice, this is not a question of "better or worse" — it is a choice between two distinct approaches:

• NEMA — an architecture with distributed intelligence at the controller level,
• Zhaga + D4i — an architecture with data at the driver level.

This choice determines not only the structure of the system, but also its cost, scalability, and behavior in operation.

Ditra Solutions: NEMA and Zhaga controllers for any infrastructure

Ditra Solutions offers a wide range of both NEMA and Zhaga controllers. The product line covers all major communication types — GSM/LTE, NB-IoT, LoRa, and PLC — allowing you to select the right solution based on your network infrastructure rather than adapting your infrastructure to the controller.
Explore one of our controllers:

DITRA NEMA Street Light Controller (Cellular)
DITRA Zhaga-type Street Light Controller (Cellular)