Why Lighting Systems Are Becoming IT Networks

How Modern Control Is Changing The Way Lighting Projects Are Designed, Deployed And Maintained

There was a time when a lighting system could be understood by following a cable.

A console sent DMX down a line. Fixtures were addressed in sequence. If something went wrong, the fault was usually physical: a bad cable, a missing terminator, a wrong address, or one fixture in the chain behaving badly.

That world has not disappeared. DMX is still everywhere, and for good reason. It is simple, robust, widely supported, and perfectly suited to many lighting applications.

But the larger and more ambitious a lighting project becomes, the more it starts to behave like something else entirely.

A modern lighting installation may now involve software, network switches, Art-Net or sACN data, pixel controllers, show playback devices, remote user interfaces, scheduled events, sensors, triggers, and long-distance data distribution. The lights may still be the visible part of the system, but behind the scenes, the job increasingly resembles network design.

Lighting has not stopped being lighting. It has become lighting plus IT.

The point where DMX stops being enough

DMX512 was one of the great standardising forces in entertainment technology. One universe. 512 channels. A clear method of getting control data from one device to another.

For conventional fixtures, that model still makes excellent sense. A dimmer, a PAR, a moving head or a smoke machine can be addressed, patched and controlled reliably within that structure.

Pixel lighting changes the equation. An RGB pixel uses three control channels. RGBW uses four.

Multiply that across strips, dots, panels, tubes, sculptural forms or architectural elements, and a single universe disappears quickly.

That is not a problem in itself. The issue is that large pixel projects do not only require more channels. They require a different way of thinking.

Instead of asking, “What address is this fixture?” designers may need to ask:

• Where does this pixel sit in physical space?
• How does the mapped content travel across the structure?
• Where should data be converted from network to pixel protocol?
• How far can the signal travel?
• How do we keep multiple outputs synchronised?
• How do we update, trigger or monitor the system after installation?

Those are lighting questions, but they are also networking questions.

From fixture layout to system architecture

One of the clearest examples is the growth of large-scale pixel mapping.

In a small rig, the control path might be obvious: software to interface, interface to fixture, fixture to fixture. In a large installation, the control path becomes a system architecture.

At the 2026 Taiwan Lantern Festival in Chiayi, for example, the main lantern installation combined LED pixel tape and neon flex into a large, animated structure. The creative goal was visual storytelling: mist, colour, animation, cultural symbolism and nightly show playback.

Technically, however, the system depended on a layered control approach. Content was created and mapped in ENTTEC LED Mapper, then distributed through a Pixelator Mini and PLink Injectors to reach fixtures positioned across the structure. The PLink layer allowed pixel data to travel long distances before being converted locally near the LEDs. That is a very different model from simply running DMX down a chain.

The creative result is light and motion. The technical reality is data management.

Ethernet as the lighting backbone

This is why Ethernet-based control has become so central to modern lighting.

Protocols such as Art-Net and sACN allow lighting data to move across network infrastructure in a flexible, scalable way. Instead of being tied to one physical DMX run, control data can be routed to different devices, zones or controllers across a venue, building or installation.

That flexibility matters because scale, distribution and integration are now deeply connected. Large projects may involve multiple universes spread across a venue, with processing happening at different points in the system, from playback devices and Ethernet nodes to controllers positioned near the fixtures themselves. At the same time, lighting increasingly needs to interact with scheduling systems, sensors, media servers and custom interfaces.

At that point, the lighting network is no longer just carrying control data. It effectively becomes part of the experience itself.

This is also where products that once seemed like separate categories begin to overlap. A DMX Ethernet node, a pixel controller, a show recorder and a software mapper may all be doing different jobs, but they are often part of the same data ecosystem.

The new role of the lighting technician

None of this means every lighting person needs to become a network engineer, but it does mean that basic networking knowledge is becoming harder to avoid.

A technician working on a modern system may need to understand IP addressing, universe routing, switch behaviour, cable distance, multicast traffic, bandwidth, DHCP, static IPs, and why “it works on my laptop” does not always mean it will work once installed in a venue.

These are not abstract IT concerns. They affect whether the lights respond correctly. A wrong IP range can make a controller effectively disappear from the system, while poor network topology may create unnecessary traffic or unstable behaviour. Even something as simple as a cheap switch or badly managed long-distance pixel run can introduce flicker, dropouts or strange colour shifts.

In other words: networking mistakes now look like lighting faults. That is why good lighting design increasingly begins before the fixtures are mounted. It starts with signal flow.

Software is now part of the rig

The other major change is that lighting systems are no longer defined only by hardware. Software has become part of the rig. A project might be designed in a visual pixel mapper, tested on a laptop, recorded into a show controller, edited in a desktop programmer, deployed to hardware, then scheduled to run automatically for months or years.

ENTTEC’s S-PLAY ecosystem is a good example of that shift. The S-PLAY itself is a standalone show controller, but the workflow around it now extends into browser-based programming and the newer S-PLAY Programmer desktop application.

That matters because many real-world projects are not programmed once, perfectly, on site. They evolve.

In practice, different people often interact with the same system in very different ways: a designer building cues in the studio, an integrator testing playback before installation, or a venue operator updating schedules months later.

This is where lighting starts to feel less like a fixed electrical installation and more like a managed digital system. The hardware may play the show, but the software increasingly defines how that show is created, edited, deployed and maintained.

Automation changes expectations

Once lighting is networked and software-driven, it becomes much easier to automate. This is one reason why show controllers have become important far beyond traditional entertainment venues.

A bridge may run different looks on public holidays, while museums, façades, playgrounds and public artworks increasingly rely on automated lighting behaviours that respond to schedules, visitors or time of day.

Guangzhou’s Central Axis Park is a useful example. Its illuminated sculptural forms combine architectural lighting, mist and laser effects, with an S-PLAY controller managing scheduled playback and coordinated show elements. The system is not just turning lights on and off. It is controlling an experience over time.

That is the key distinction. A networked lighting system is not merely a bigger lighting rig. It can become part of the operational life of a place.

When lighting becomes infrastructure

The larger the project, the more important that operational thinking becomes.

Arena Milano’s media façade for the Milano Cortina 2026 Winter Olympic and Paralympic Games is an extreme example. The façade required precise control over a vast architectural LED system, with content mapped and distributed across thousands of universes.

At that scale, the lighting system is no longer a decorative layer applied to a building. It becomes part of the venue’s communication infrastructure. It carries branding, ceremony, wayfinding, atmosphere and public identity. It needs to be reliable, repeatable and manageable. It needs to work during major events, not just during commissioning.

This is where the convergence between lighting, AV and IT becomes obvious.

The same project may involve architectural designers, lighting programmers, network specialists, content creators, control system integrators, venue operators and client stakeholders. Each group sees the system slightly differently, and the successful installation is the one where all those layers work together.

Keeping complexity usable

Of course, there is a danger in all of this. As systems become more powerful, they can also become more intimidating. A beautifully designed lighting network is not much use if only one person understands how to operate it. That is why interface design matters.

For a touring programmer, the ideal interface may be detailed and technical. For a venue manager, it may be a tablet page with three buttons: open, event mode, close. For a public artwork, the best interface may be no interface at all: just a schedule that runs quietly in the background.

The aim is not to make every user think like a programmer, it is to put the right level of control in the right hands. This is one of the more interesting shifts in modern lighting. The back end may be more complex than ever, but the front end often needs to be simpler than ever.

The future is connected, not complicated

Lighting professionals have always combined art and engineering. All that has changed is the kind of engineering involved.

The next generation of lighting systems will not only depend on good fixture choice, careful patching and strong creative programming. They will also depend on network planning, software workflows, remote management, data distribution and long-term maintainability.

For some, this may sound daunting, but it also creates enormous creative opportunity.

When lighting becomes networked, it becomes easier to scale and distribute. When it becomes software-driven, it becomes easier to evolve over time, adapting to new spaces, audiences and experiences.

The challenge is not to turn lighting designers into IT departments, it is to give lighting professionals enough network literacy to keep control of increasingly connected systems, because the future of lighting will still be about colour, movement, timing, atmosphere and emotion. It will just travel through a lot more Ethernet cable on the way there.