sACN Universe Priority: Define Takeover Before Adding a Backup Source

Set sACN priority from an agreed ownership policy, not from whichever source was commissioned last. Decide which system controls each universe during normal operation, takeover and recovery. Keep universe priority separate from per-address extensions, and verify how the actual receiver handles equal priorities and multiple sources.

A backup source that sends valid data can still fail operationally if the architectural controller wins unexpectedly, the receiver reaches its source limit or a restored primary creates an unwanted output change.

Start with source ownership

ETC's priority explanation describes the standard universe priority range of 0 through 200, with 100 as the default, and distinguishes per-universe from per-address behavior. A higher priority can select a lower level, so priority is not the same as brightness or highest-value merging.

Choose actual values within the supported range after deciding these relationships. Do not copy a priority table from another venue without its ownership assumptions.

Treat per-address priority as a separate capability

Per-address priority can allow more selective ownership, but both sender and receiver behavior matters. ETC's documentation explains that products differ in support and that some receivers have limits on concurrent sources. Verify the relevant model and firmware rather than assuming every sACN-labelled device supports every extension.

ETC's network terminology reference also distinguishes per-address handling and network transport concepts. A correct multicast subscription does not establish correct priority arbitration. Keep packet delivery and source selection as separate checks.

For installations with simple receivers, a clearly separated universe design may be easier to commission than a complex per-address takeover scheme. Make that choice from actual requirements, not from the availability of a checkbox.

Diagnose the winning source

Use the receiver's diagnostics or a suitable packet viewer to identify source name, identity, universe and advertised priority. A console's UI setting is useful, but the received packet is better evidence of what was transmitted.

If lights stay on while the intended console sends zero, inspect other sources before assuming that zero packets were lost. A different source can legitimately own the universe. If output changes only after another source disappears, investigate equal-priority merging or source-capacity limits.

Do not increase priority repeatedly until the symptom vanishes. That can break architectural or maintenance control elsewhere. Update the ownership worksheet and retest every affected operating condition when priority changes.

Commission takeover and return

Run the normal source, introduce the backup and guest systems in the planned order, then remove and restore each one. Observe actual output and record the winning source. Include the maximum intended source count rather than testing only a convenient two-source subset.

Test receiver restart while several sources are present. Save packet evidence and configuration so another technician can reproduce the result. Label any behavior that depends on a manufacturer's merge implementation.

Give visiting operators a source-ownership sheet with permitted universes, priority relationships and the takeover procedure. Verify transmitted settings together before connecting the complete rig. Remove temporary sources after testing. Several old show laptops can change source arbitration even when each individual system looks healthy. Include a receiver restart with those approved sources present, because the order in which sources appear can reveal implementation limits that a quiet two-source bench test missed.

See the Art-Net and sACN comparison for protocol selection context. Review the ownership policy with an integration partner before promising seamless backup; seamless behavior must be demonstrated on the installed equipment.