Art-Net Unicast vs Broadcast: Send Lighting Data to the Intended Nodes

Use Art-Net delivery settings that match the protocol revision, node subscriptions and network design. Unicast targets specific receivers; broadcast reaches the relevant broadcast domain. Do not use broad broadcast as a permanent workaround for an unknown node address or an incorrect universe patch.

The engineering goal is predictable delivery with a documented scope. That includes node replacement and recovery, not merely a successful lighting test with one console and one gateway on a desk.

Separate discovery from level delivery

The Art-Net specification defines discovery and data packets, including destination behavior. Check the revision and the particular packet rules rather than applying one delivery rule to all Art-Net traffic. Discovery visibility and successful delivery of lighting levels are separate acceptance tests.

The table is a design comparison, not a substitute for Art-Net's packet-specific requirements.

Build a universe-to-node worksheet

Record controller output universe, Art-Net port addressing, node identity, node IP address and physical output. Be explicit about numbering conventions: a user interface's first displayed universe can be represented differently by another manufacturer's configuration tool.

Choose addressed bench tests first. Confirm that the expected node receives the intended universe and that a different node does not act accidentally. If discovery populates destinations automatically, save evidence of which nodes advertised the relevant ports.

ETC's network definitions explain foundational network concepts such as broadcast and multicast scope. Those concepts help when discussing the design with network staff, but multicast group configuration for another lighting protocol does not automatically configure Art-Net broadcast behavior.

Diagnose missing output by layer

If discovery works but levels do not, inspect actual data destinations, port addresses and node output patch. If one node works and another does not, compare subscription or universe configuration before changing the whole controller to broadcast.

Check whether a management address change left stale unicast destinations behind. A console may keep sending valid packets to the old address while the new node appears healthy in its own browser interface.

Avoid confusing a switch's traffic controls with application patching. Capture at the sender and near the receiver where practical. That identifies whether packets were never sent, were sent to an unintended destination or arrived but did not match the node's configured output.

Test the operating lifecycle

Acceptance should include all intended universes, representative full output traffic and every required node. Restart a node, replace it using the approved procedure and verify that the controller discovers or targets it correctly again.

Disconnect one receiver and confirm unrelated outputs remain stable. Reconnect after a quiet period and check both network delivery and actual fixture behavior. Save the patch worksheet and node firmware with the show configuration.

Preserve receiver identity, advertised ports and intended physical outputs in the acceptance inventory. This makes an address change diagnosable without reconstructing the patch. Document temporary test controllers and remove them afterwards. An overlooked second sender can create conflicts that resemble delivery-mode trouble even when all packets arrive. Recheck destinations after restoring a configuration backup, since the saved file may predate a node replacement while retaining otherwise familiar universe labels.

Do not claim performance or supported universe counts without checking the actual controller, gateway and switch specifications. The Art-Net versus sACN article explains the wider choice. Bring the delivery worksheet to a partner review before standardizing a venue's lighting network settings.