Emergency lighting is not optional: in commercial and public buildings, it is a legal requirement. But integrating DALI emergency lighting status into a KNX installation is a challenge that catches many installers off guard. The two protocols are fundamentally different in how they communicate, and bridging them cleanly requires a solid understanding of both worlds. This article walks through the key steps and considerations for getting DALI and KNX to work together reliably.
For KNX system integrators working on larger building automation projects, this integration is becoming increasingly common. Building owners want a single interface to monitor everything, including whether emergency luminaires are functional, charged, and compliant. Getting that data into KNX group addresses, and ultimately into a central controller, is where the real work begins.
Why DALI and KNX speak different languages
DALI (Digital Addressable Lighting Interface) and KNX are both well-established protocols in building automation, but they were designed with different goals in mind. DALI is a dedicated lighting control protocol: it excels at granular control of individual luminaires, including dimming levels, lamp failure detection, and emergency lighting test results. KNX, on the other hand, is a general-purpose building automation bus that handles everything from heating and blinds to access control and energy management.
The practical difference is significant. DALI communicates on a two-wire bus with its own addressing scheme (up to 64 individual addresses per segment), while KNX uses group addresses and telegrams to exchange data across a broader installation. Neither protocol natively understands the other. Emergency lighting adds another layer of complexity: DALI emergency devices follow the EN 62386 Part 202 standard, which defines specific commands for function tests, duration tests, and status queries. These commands have no direct equivalent in the KNX data model, which means translation is always required.
The role of a DALI gateway in KNX installations
A DALI gateway is the hardware that bridges these two worlds. It sits on both the DALI bus and the KNX bus simultaneously, translating commands and status information between the two protocols. For emergency lighting specifically, the gateway does more than just pass on switch commands: it actively polls the DALI emergency devices, retrieves test results and fault states, and makes that information available as KNX data points.
When selecting a gateway for emergency lighting integration, it is important to choose one that explicitly supports DALI Part 202 (emergency lighting). Not all DALI gateways handle this: some only support standard DALI lighting control (Part 2). A Part 202-capable gateway can read emergency mode status, battery charge level, lamp failure flags, and the results of automatic function and duration tests. These values are then mapped to KNX group addresses, making them accessible to the rest of the xxter KNX building automation platform.
Mapping emergency lighting status to KNX group addresses
Once the gateway is in place, the next step is defining which DALI status values map to which KNX group addresses. This is where careful planning pays off. Each DALI emergency device can report multiple status bits (lamp failure, battery failure, test in progress, duration test result, and more), and each of these needs its own group address if it is to be monitored individually.
A practical approach is to organize group addresses by luminaire and by status type. For example, all lamp failure flags for a given zone might share a logical group, while battery status flags are grouped separately. This makes it easier to build visualizations and alerts later. Keep in mind:
- Use binary data point types (DPT 1.x) for on/off status flags such as lamp failure or emergency mode active
- Use 8-bit or 16-bit data point types for numeric values like battery charge percentage or test duration results
- Document every group address mapping in the ETS project from the start; retrofitting this later is time-consuming
- Verify that the gateway’s ETS plugin generates the correct DPTs automatically, or adjust them manually
Thorough group address planning at this stage prevents confusion during commissioning and makes future maintenance significantly easier.
Monitoring and triggering alerts through the xxter controller
With emergency lighting status available as KNX group addresses, it becomes possible to build meaningful monitoring and alerting logic. The xxter Pairot KNX controller reads these group addresses in real time and can trigger automated responses based on the values it receives. If a luminaire reports a lamp failure, a trigger can immediately send a push notification to the building manager’s smartphone. If a duration test fails, the event can be logged with a timestamp for compliance documentation.
This kind of active monitoring transforms emergency lighting from a passive safety system into a managed asset. Rather than waiting for a manual inspection to discover a faulty unit, the installation proactively reports problems as they occur. The xxter app makes this accessible on any device (tablet, smartphone, or desktop) without requiring a separate emergency lighting management system. For integrators, this means fewer tools to manage and a cleaner handover to the end client.
Common integration pitfalls and how to avoid them
Even with the right hardware and a clear plan, DALI-KNX integration for emergency lighting has a few recurring issues worth knowing about in advance. The most common is assuming that any DALI gateway will handle emergency lighting; as mentioned earlier, Part 202 support is not universal, and discovering this after installation is costly.
Another frequent issue is bus load. DALI emergency devices respond to test commands and status queries with relatively verbose data. If a gateway is polling a large number of devices at short intervals, it can create congestion on the KNX bus. Setting appropriate polling intervals (typically no shorter than every few minutes for status updates) keeps the bus load manageable without sacrificing responsiveness. A third pitfall is neglecting the physical DALI segment limits: a single DALI segment supports a maximum of 64 devices and has strict cable length and current limitations. Larger installations need multiple segments, each with its own gateway.
How xxter supports professionals with DALI-KNX integration
xxter provides KNX system integrators with the tools to bring DALI emergency lighting status into a unified building automation environment. The xxter controller acts as the central hub where all KNX data (including emergency lighting status received via a DALI gateway) comes together in one place. Through the xxter platform, integrators can:
- Configure triggers that send instant alerts when a luminaire reports a fault or test failure
- Build custom visualizations that display emergency lighting status across an entire building floor plan
- Log status changes with timestamps to support compliance and maintenance records
- Give building managers remote access to live emergency lighting data through the xxter app for building management
xxter works without subscription fees or license costs, which makes it a practical choice for both small and large installations. The platform supports scripts and triggers that can be tailored precisely to the monitoring logic a specific building requires. If you are working on a project that involves DALI emergency lighting and want to know how xxter fits into your integration architecture, get in touch with the xxter team to discuss the specifics of your installation.
Preguntas frecuentes
Do I need a separate DALI gateway for each floor or zone, or can one gateway cover the whole building?
It depends on the number of DALI emergency devices in your installation. A single DALI segment supports a maximum of 64 device addresses, so if your building exceeds that number, you will need multiple gateways — one per segment. Each gateway then connects independently to the KNX bus, and all their group addresses feed into the same KNX installation. For large multi-floor buildings, it is common to plan one DALI segment (and gateway) per floor or fire compartment, which also aligns neatly with how emergency lighting zones are typically structured for compliance purposes.
How do I verify that a DALI gateway actually supports Part 202 before purchasing it?
Always check the manufacturer’s datasheet and ETS product database entry specifically for ‘DALI Part 202’ or ‘EN 62386-202 emergency lighting’ support — marketing terms like ‘DALI compatible’ or ‘full DALI support’ do not guarantee this. Look for explicit mentions of emergency mode status, function test and duration test command support, and battery charge level reporting in the technical specifications. If in doubt, contact the manufacturer directly and ask whether the gateway can poll DALI emergency devices for test results and expose those results as KNX data points. Requesting a demo ETS plugin or a test report from a reference installation is also a reasonable step for larger projects.
What polling interval should I configure for emergency lighting status updates, and what happens if I set it too low?
A polling interval of two to five minutes is generally appropriate for emergency lighting status monitoring — it provides timely fault detection without generating excessive KNX bus traffic. Setting the interval too low (for example, every few seconds) can cause bus congestion, especially when multiple gateways are polling simultaneously across a large installation, which may lead to delayed telegram delivery for other KNX functions like lighting control or HVAC. For critical fault flags such as lamp failure or emergency mode active, some gateways support event-driven reporting, meaning they push an update to KNX immediately when a status changes rather than waiting for the next poll cycle — this is worth enabling where available.
Can automatic DALI function tests and duration tests be triggered from within KNX or xxter, or do they have to be initiated from the DALI side?
Many Part 202-capable DALI gateways expose KNX group addresses that can be used to initiate function tests and duration tests remotely, meaning you can trigger them from a KNX logic controller or directly through xxter. This allows you to schedule tests outside of occupied hours using xxter’s trigger and scripting functionality, rather than relying on the DALI devices’ own internal test schedules. Always confirm this capability with your specific gateway’s documentation, as the implementation varies between manufacturers. When tests are triggered this way, the results are written back to their respective KNX group addresses and can be logged automatically by xxter for compliance records.
What is the most common mistake integrators make when setting up KNX group addresses for DALI emergency status, and how can it be avoided?
The most common mistake is under-planning the group address structure — typically by assigning only a single group address per luminaire to represent a generic ‘fault’ state, rather than mapping individual status bits like lamp failure, battery failure, and test result separately. This makes it impossible to distinguish between fault types in visualizations or alerts, which reduces the practical value of the monitoring system and can complicate compliance reporting. The fix is straightforward: plan your group address structure in ETS before commissioning begins, allocate dedicated addresses for each status data point per device or zone, and document everything in a group address list that is shared with the building manager from day one.
Does integrating DALI emergency lighting into KNX satisfy the legal requirement for emergency lighting testing and record-keeping?
The integration itself does not replace the legal obligation — it supports meeting it more efficiently. Regulations such as EN 50172 require that function tests and duration tests are performed at defined intervals and that results are recorded. By routing test results through a DALI gateway into KNX and logging them via xxter with timestamps, you create an automated, auditable record of every test outcome without manual logbooks. However, you should always verify with the relevant authority or compliance consultant in your region that the logging format and retention period meet local requirements, as these can vary between countries and building types.
Can xxter display emergency lighting status on a building floor plan, and how complex is that to set up?
Yes, xxter supports custom visualizations that can overlay emergency lighting status indicators directly onto a building floor plan image. The setup involves uploading a floor plan graphic, placing interactive elements linked to the relevant KNX group addresses (such as lamp failure flags or test result values) at the correct positions, and configuring how each element changes appearance based on the received value — for example, turning red when a fault is detected. This does not require programming skills and can be done entirely within the xxter configuration interface. The result is a live, at-a-glance overview that building managers can access from any device through the xxter app.