Cart

Network basics for lighting over Ethernet#

Last updated · 6 min read

You don't need a complicated network to run an Art-Net or sACN rig. You need an Ethernet switch, a way to give every device an IP address, and a few habits that stop the network from quietly eating your packets. This page is the product-agnostic version — for the specifics of any one expanseElectronics device, see its own quick-start.

What lighting-over-Ethernet actually needs#

A lighting LAN is a small, deterministic broadcast / multicast network. It needs:

  • Layer-2 connectivity between every console, node, and computer — i.e. they're all on the same switch (or chain of switches), not split across a router.
  • Enough bandwidth that nothing has to queue. A single Art-Net universe is around 100 kbit/s with packet rates capped at ~44 Hz; even a hundred universes barely scratches a 100 Mbit/s link. Bandwidth is rarely the bottleneck.
  • Predictable latency. This is what actually matters. Packets that arrive 30 ms late aren't delivered — they cause a fixture to twitch. A clean, lightly-loaded LAN delivers them in sub-millisecond times.

It does not need internet access, port forwarding, VPNs, or any other WAN-era tricks. If your console can ping the node, you're 90% of the way there.

Pick a switch — and pick the right one#

For most rigs, any unmanaged gigabit switch is fine. The mistakes worth knowing:

  • Avoid the cheapest "smart" 100 Mbit/s switches. Half of them re-broadcast frames they shouldn't, and most of the rest have no buffer to speak of, so a 50-fixture pixel rig drops packets the moment something else uses the LAN.
  • Watch for "green Ethernet" / EEE. Energy Efficient Ethernet on consumer switches can put a port to sleep between packets, then take 1–2 ms to wake it up. That latency hits every frame on a quiet universe. Disable EEE if your switch lets you, or buy a switch that doesn't have it on by default.
  • Managed switches help when you outgrow the basics. Useful features: per-port VLANs (separate the lighting LAN from the venue's office LAN), IGMP snooping (multicast pruning, important for sACN with lots of universes), port mirroring (debugging — see what's actually on the wire).
  • PoE switches: if you're powering nodes by PoE, check the switch's total PoE budget and the per-port class. expanseElectronics PoE units are 802.3af, ~9 W draw — but a 4-port PoE switch with a 30 W total budget runs out of headroom quickly when you stack other PoE devices on it.

Addressing — DHCP or static?#

Both work. The decision is about predictability, not protocol.

DHCP (the default on most nodes) means a router or other DHCP server hands out addresses automatically. Pros: zero configuration on the node side, devices "just work" when you plug them in. Cons: the address can change, which matters if you've patched the universe by IP somewhere or if a node uses a UI you reach by typing the IP.

Static IP means you set the address by hand. Pros: predictable across power-cycles and across years; easier to document a rig. Cons: collisions are silent and miserable to debug; you have to keep a record.

Reasonable defaults:

  • Touring rig that gets plugged into a different LAN every week — DHCP. Let the venue's network give you addresses; access nodes by hostname or via a discovery tool.
  • Permanent install — static, in a documented range, with the gateway pointing somewhere consistent. 2.0.0.0/8 and 10.0.0.0/8 are the conventional Art-Net ranges. Document who got which address.
  • A workbench / single-node test — direct cable between the computer and the node, both on static addresses in the same subnet (e.g. 10.0.0.2 on the computer, the node on its DHCP-fallback address). No switch needed.

Subnets and the /8 Art-Net convention#

Art-Net's IP-allocation guidance suggests every node lives somewhere in 2.0.0.0/8 or 10.0.0.0/8. The /8 mask matters: it means a node statically configured for 10.5.0.1 and another at 2.100.0.50 can both reach each other without a router, as long as their subnet masks are 255.0.0.0. If you set the mask to 255.255.255.0 (a /24), they suddenly can't.

You don't have to follow this convention — sACN doesn't care, and Art-Net only cares for ArtPoll discovery, not for actual DMX delivery. But every console, every other node, and most diagnostic tools assume it. Match the convention unless you have a reason not to.

Broadcast, multicast, and why your switch matters#

Art-Net uses broadcast UDP. Every Art-Net packet on the LAN is delivered to every device on the LAN, lighting or not. Your laptop's network stack sees them and discards them — but on a busy network with hundreds of universes, that's noticeable CPU.

sACN uses multicast UDP, with one multicast group per universe. A device subscribes to only the universes it cares about. On a switch with IGMP snooping enabled, only the subscribed ports actually receive traffic for a given universe. On a switch without snooping, multicast falls back to broadcast and you've lost the main benefit.

In practice: small rigs (< 8 nodes), pick whichever protocol your console prefers and don't worry. Bigger rigs (16+ universes), sACN on a managed switch with IGMP snooping is meaningfully easier on the network.

Common pitfalls#

A short list of things that have eaten an evening for one of us at some point:

  • Wireless on the lighting LAN. Don't. Even "good" Wi-Fi has 50 ms latency spikes that look exactly like the node failing. Lighting traffic is wired-only.
  • A second DHCP server appearing. Two DHCP servers on the same broadcast domain hand out conflicting addresses; some nodes take the first reply, some take the last, and you spend an hour debugging "intermittent" connections. Don't enable a fallback DHCP server (e.g. on a masterETH) on a network that already has one.
  • Spanning Tree Protocol blocking ports. Some managed switches default to STP "on" with a 30-second forwarding delay. That's why your node sometimes takes 30 seconds to come online after a reboot. Set those ports to "edge" / "portfast" / "rapid".
  • PoE injectors that aren't. A passive 48 V "injector" without 802.3af negotiation will not power an active-PoE node, and may damage equipment that doesn't expect 48 V on the spare pairs. Use only standards-compliant active PoE.
  • Mismatched subnet masks. A node on 10.0.0.5/24 and a console on 10.50.0.5/24 can't see each other. Either widen both masks to /8 or move them onto the same /24.

Where to go next#