Pixel LED puts thousands of individually controllable RGB or RGBW LEDs on a façade or in a feature installation. Connecting that to a building's lighting control system is where projects get awkward, because the two systems answer different questions.
An architectural system asks which scene a zone should be in. A pixel system asks what colour each LED should be, many times a second. Architectural control deals in intent. Pixel control deals in output.
Integrating them means understanding where one system's job ends and the other's begins, and translating between the two.
The scale difference
A building system might say: office at 70%, lobby on scene 3, façade on its evening scene, emergency override active.
A pixel system needs three channels per RGB pixel and four per RGBW pixel. A façade of 2,000 RGB pixels needs 6,000 channels. One DMX universe holds 512 channels, or 170 RGB pixels, so that façade needs about twelve universes streaming continuously.
When the building system selects "evening", something else has to decide what those 2,000 pixels do. That is the job of a pixel controller or media server, and it should stay there.
How pixel systems are controlled
A typical chain looks like this:
DMX512 sits underneath all of it. Pixel data is organised into 512-channel universes. Running DMX cable for every universe stops being practical at scale, so the universes travel over Ethernet instead.
Art-Net and sACN both do this. They send DMX universes across an IP network, and each pixel controller picks up the ones it needs. Art-Net is common in entertainment lighting and media façades. sACN is also widely supported. Which one you use usually depends on what your controllers support and how the network is built.
The network protocol never reaches the LEDs. The pixel controller converts Art-Net or sACN into a pixel-level signal such as SPI, which is what the LED chips understand.
How architectural systems are controlled
Architectural control works with luminaires, rooms, zones and scenes. You will meet DALI and DALI-2, KNX, 0-10 V, DMX, BACnet and various proprietary systems. They don't all do the same job. Some are lighting protocols, others are building automation layers.
DALI and DALI-2 address individual luminaires or groups, with scenes and status feedback. They suit offices, hotels and retail, where lighting follows occupancy, schedules and daylight. They are not built to stream RGB animation to thousands of pixels.
KNX works one level up, next to blinds, HVAC and room controls. It can say "activate façade evening scene" without knowing the colour of a single LED.
BACnet shows up when lighting reports into a building-management system. Again, it carries status and high-level commands, not pixel data.
Where the two systems meet
Architectural control systems were not built to carry pixel data. The buses behind them are sized for commands and status: a DALI line runs at 1,200 bit/s and supports up to 64 devices, and KNX twisted pair runs at 9,600 bit/s. That is plenty for "recall scene 3" or "report lamp failure". It is nowhere near enough for the 6,000 channels of a 2,000-pixel façade refreshed many times a second.
Pixel systems have the opposite profile. They stream continuous data over Ethernet and have no notion of rooms, zones, schedules or occupancy.
So the two systems exchange different kinds of information. One side speaks in commands and status, the other in streams of channel values. Integration is the work of translating between them. A scene command from the building system becomes a preset recall in the pixel system. The integration layer, usually a gateway or lighting server, sits at that boundary:
Building control, integration layer, pixel controller and pixels, with a façade evening scene mapped to preset 04.
It doesn't translate pixel values. It translates commands into predefined pixel behaviour.
Three levels of integration
How much the building system controls is a design decision. There are three levels.
Level 1: scene triggering. The building system offers a short list of façade states: off, static white, evening, event, dynamic, maintenance. The integration layer starts the matching preset. The pixel programming stays in the pixel environment, and the operator never has to think about DMX universes. This fits most architectural projects.
Level 2: parameter control. The building system also sets selected parameters, for example brightness at 60%, warm white, slow wave at 20% speed. The integration layer converts these into pixel-system commands. Use this when operators need to adjust the output themselves.
Level 3: pixel-level control. A media server or show-control system generates the pixel data in real time and the pixel controllers pass it to the LEDs. The building system only supervises: it enables the façade, selects the operating mode and caps the brightness. This is for media façades and heavily dynamic content.
More resolution doesn't make a better integration. Start at Level 1 and move up only when the project needs it. A Level 1 system is easier to operate and has less to go wrong.
Example: a hotel façade
A hotel runs its interior lighting on DALI-2. The RGBW pixel façade runs on networked pixel controllers receiving sACN. The operator wants four façade modes.
The DALI-2 system never sees a pixel. An integration controller maps each building scene to a stored pixel-controller state:
The operator gets one interface, with two control technologies underneath.
Plan the network early
Once pixel lighting is on Ethernet, part of the job is network engineering. A large installation can have many pixel controllers, dozens of universes, media servers, switches and building-management interfaces. A setup that works on the test bench gets much harder to troubleshoot once it spreads across a building.
- Bandwidth: count the universes and the update rates. Don't assume any Ethernet network will cope.
- Multicast: sACN can use multicast, so switch and VLAN settings need to allow for it.
- Segmentation: keep lighting traffic apart from general building IT traffic. It makes commissioning easier and the system more reliable.
- Redundancy: critical installations may need duplicate controllers, network paths or power supplies.
- Addressing: agree IP addresses, universes, controller outputs and pixel mappings before commissioning starts.
Decide who is in charge, and what happens when it fails
If building automation, architectural control, a media server and a local panel can all send commands, you need to know which one wins. A typical order, highest priority first:
The order will differ per project. Write it down.
Then decide what happens when something drops out. If the media server goes offline, the façade can hold its last state, fall back to static white, switch off or run a local sequence. That is a lighting design decision, not an IT setting, so make it with the client.
What to get right
Most integration problems trace back to a short list:
- Exposing every pixel to the building-control system. Expose scenes and a few parameters instead.
- Treating DMX, Art-Net, sACN, DALI and KNX as interchangeable. Each has its own place in the architecture.
- Letting two systems control the same output. Set the hierarchy first.
- Underestimating the network. Pixel lighting produces far more traffic than conventional lighting.
- Leaving failure behaviour undefined. Decide what each component does when another one fails.
- Skipping the interface document. List what crosses between the systems: scene selection, brightness, colour, effect, speed, status, faults and overrides.
Summary
Integration works when each system has clear responsibilities. The pixel system handles high-resolution output. The architectural system handles scenes, zones, schedules and the building. A defined integration layer turns "façade evening scene" into a sequence across thousands of LEDs, and the operator only ever sees the simple command.