When lighting data disappears, the LED load may remain on, fade, change to a preset or follow another documented response. Include that retained or fallback state in the electrical acceptance record. Turning off a console is not the same event as removing power from the receiver or the DC source.
This guide is for OEMs integrating a constant-voltage source with a separate lighting controller and compatible modules. The WEHO WL-400-12 photo identifies the source example; it does not make the supply a DMX receiver, an emergency-lighting device or a qualified match for a particular controller.
Separate data, controller power and source power
Draw three distinct paths: the data origin, the controller’s own power and the power delivered to the lighting modules. Record which remain energized when an operator turns one item off. A lost network stream can leave the controller and lamps fully powered. A controller restart can occur while the source remains stable.
ENTTEC’s CVC4 support guidance documents a particular controller that retains the last frame when its data source stops while the controller remains powered. ETC’s explanation of lights staying on after console shutdown gives other product-specific data-loss behaviours. These examples show why behaviour must be checked; they are not a claim that an unidentified controller behaves the same way.
Define the required lighting response for each event
Name the event, initial scene, maximum duration, desired response and restoration action. Include signal loss without power loss, controller-only reboot, source restoration and any applicable local override. Record firmware and configuration because a default or a changed preset can alter the load without changing the supply model.
Do not label every fallback as “off” in the documentation. If the actual permitted response is to retain a bright state, treat it as a possible sustained demand. If a fade is required, the delay, duration and final state belong to the controller requirement, with the source remaining within its own documented operating conditions throughout.
Calculate energy and current for the actual state
For a hypothetical steady 12 V lighting assembly, assume the normal scene draws 8 A and a documented permitted retained scene draws 18 A. The corresponding output powers are 96 W and 216 W. If the retained state lasts 15 minutes, its delivered load energy is 216 × 0.25 = 54 Wh, compared with 24 Wh for the 8 A scene over the same period.
| Hypothetical state | Kasalukuyan | DC load power | Energy in 15 min |
|---|---|---|---|
| Normal scene | 8 A | 96 W | 24 Wh |
| Permitted retained scene | 18 A | 216 W | 54 Wh |
These are invented load examples. They do not establish WL-400 capability, AC input power, conversion efficiency, a thermal limit or a controller rating. Compare the actual worst permitted demand with the confirmed source, controller channels, common paths and installation conditions. Check transitions separately rather than using the steady arithmetic as a transient guarantee.
Observe the transition and the stable destination
Prepare a controlled integration test using approved access to the data and control interfaces. Record the initial scene, precise event and time reference. Observe the light output, controller status and electrical demand during the event, after it settles and when the data returns. Keep enough time history to distinguish a short transition from an indefinitely retained state.
The last successful bright scene may produce a different result from the normal demonstration sequence. Test the relevant initial conditions rather than assuming one data-loss trial covers all memories and presets. When required behaviour is uncertain, keep that configuration out of the released build until the controller documentation and test record establish it.
Keep control response separate from protective isolation
A scene going dark does not establish that hazardous energy has been isolated. A DC supply remaining within its voltage range does not prove that the controller’s data-loss response meets the application requirement. Document each evidence owner separately, and use the equipment’s approved isolation procedure for service.
This article does not turn an ordinary lighting combination into emergency lighting or a safety function. If continued illumination or a particular fail response is required by the project’s applicable rules, it needs the appropriate system specification and evidence. A configurable preset alone does not supply that evidence.
Hand over a configuration and state matrix
Include the controller identity, firmware, saved configuration, default scene and restoration behaviour with the supply and module BOM. The commissioning record should name the actual tested transitions and state the results against the agreed criteria. Identify which updates, substitutions or configuration resets require another review.
The WL-400-12 photo reads 12 V, 33.3 A, while the public page table lists 27 A for its 12 V column and contains unrelated model text. This disagreement is unresolved; neither number is adopted as an installed capacity for this example. Request the applicable ordered-revision specification before source approval. The useful outcome is a complete load-state record that remains valid when normal control is interrupted, rather than a demonstration that works only while one console is sending a familiar scene.
Send the controller’s documented loss-of-data response, recovery sequence, permitted retained scenes, current/duration record and enclosure conditions for your WL-400-12 application. Request the offered revision’s confirmed input/output limits and evaluate every required sustained state before approving the assembly.
Lighting interruption and restoration state matrix
| Initial scene | Data / power event | Required destination | Observed current and timing | Restoration result | Disposition |
|---|---|---|---|---|---|
Blank project worksheet. Enter verified project data; example calculations above are not measurements.
