Warum schlagen meine automatisierten DALI-Notlicht-Funktionsdauertests mit 'duration test max. delay exceeded' fehl, obwohl manuelle Tests erfolgreich sind?

Was der Kunde gefragt hat

Bei der Inbetriebnahme eines Bürogebäudes mit rund 300 DALI-Notleuchten bemerkte ein Integrator sporadische Testfehler an seiner zentralen Überwachungsstation (Zitate leicht bearbeitet, übersetzt und vollständig anonymisiert):

"Beim Auslösen automatisierter Funktionsdauertests über unser Steuerungssystem melden etwa 40 Leuchten 'duration test max. delay exceeded'. Gehen wir aber die Etage manuell ab und lösen einen manuellen Test aus, leuchten sie die vollen 3 Stunden."

"Wir haben fünf der meldenden Leuchten gegen neue getauscht, aber zwei der Ersatzgeräte warfen beim nächsten automatischen Durchlauf denselben Delay-Fehler."

Warum der Fehler "max delay exceeded" auftritt

Nach Teil 202 des DALI-Standards (autarke Notbeleuchtung) fällt das Betriebsgerät nicht zwangsläufig in der Millisekunde, in der ein Befehl zum Starten eines Dauertests eintrifft, in den Notbetrieb. Stattdessen prüft es zunächst seine interne Bereitschaft. Ist der Akku nicht vollständig geladen, stellt die Leuchte den Test in eine Warteschlange und wartet, bis die Ladung abgeschlossen ist.

Der Zeitplan des Controllers erwartet jedoch, dass der Test innerhalb eines vordefinierten Verzögerungsfensters (häufig 24 bis 48 Stunden) startet. Erreicht der Ladezeitgeber des Akkus vor Ablauf dieses Fensters nicht 100 %, bricht das Betriebsgerät die wartende Anfrage ab und setzt das Fehlerstatusflag "duration test max. delay exceeded".

Manuelle Bezeugungstests umgehen diese Warteschlangenlogik häufig oder finden zu einem Zeitpunkt statt, an dem der Akku endlich voll geladen ist, was den frustrierenden Eindruck eines Softwarefehlers erzeugt.

Ist die Leuchte defekt? Selten.

In über 90 % der Feldanalysen sind Leuchte und Akku einwandfrei. Die Grundursachen sind betrieblicher Natur: 1. Aktuelle Netzunterbrechungen: Bereits ein kurzer Spannungseinbruch während der Endbauphase setzt die Anforderung des 24-Stunden-Ladezyklus zurück. 2. Unmittelbar aufeinanderfolgende Tests: Ein monatlicher Funktionstest am Sonntagabend gefolgt von einem jährlichen Dauertest am Montagabend führt garantiert zum Fehlschlag. Der Funktionstest entlädt den Akku leicht, was einen vollständigen Ladezyklus vor dem Dauertest erzwingt. 3. Bus-Broadcast-Stürme: Wenn 300 Leuchten gleichzeitig versuchen, Testinitiierung und Akkustatus an das Gateway zu melden, können Kollisionsfehler dazu führen, dass der Controller annimmt, eine Leuchte habe ihr Testfenster verpasst.

Wie Sie es diagnostizieren und beheben

1. Bestätigen Sie eine vollständige, ununterbrochene Akkuladung. 2. Staffeln Sie den automatischen Testzeitplan, damit nicht alle Geräte gleichzeitig testen. 3. Isolieren Sie eine betroffene Leuchte auf einer nachweislich einwandfreien Leitung und starten Sie direkt einen Funktionstest, danach einen Dauertest. 4. Überprüfen Sie die Part-202-Statusantworten mit ProbitSite und ersetzen Sie nicht konforme Geräte.

Um zu isolieren, ob es sich um ein Zeitplan- oder ein Hardwareproblem handelt, schließen Sie ProbitSite an die betroffene Leitung an. Lesen Sie die live übertragenen Part-202-Statusbytes einer meldenden Leuchte aus: ProbitSite dekodiert den genauen internen Zustand und zeigt an, ob die Akkuladung aktiv, ausstehend oder durch einen Temperaturfehler blockiert ist.

Zeigt der Status eine gesunde Ladung, senden Sie einen direkten DALI-Befehl "START DURATION TEST" an diese eine Adresse. Startet die Leuchte sofort den Testmodus, ist Ihre Hardware konform, und der automatisierte Zeitplan der Zentrale muss verbreitert und über mehrere Nächte gestaffelt werden.