Dynamic Space Partitioning splits a single ballroom into eight independently lit rooms and merges them back again as the operable walls open and close. I designed the model behind it: the walls, the sub-areas, and the devices in each one, set up in a single configuration any installer can run.


A partitioned area holds a set of sub-areas and the walls between them. Every wall has an IR sensor (IRTR) wired to a contact-closure input, so the lighting follows the wall. Open it and the sub-areas merge into one zone; close it and they split back apart. Nobody has to touch a control panel.
Partitioning divides a large room into smaller ones for as long as you need them. The same venue can hold a 400-person gala in the morning and five breakout sessions running at once in the afternoon.
The dividers go by several names: operable walls, operable partitions, movable partitions. Whatever the venue calls them, the lighting has to keep up. Each room lit on its own while the wall is closed, and lit as one room when it opens.
The shipped configuration flow, playable. You run the same five steps an installer runs in the WaveLinx app: create the area, define its shape, name the sub-areas, tell each wall what it joins, and wire each wall's sensor to a contact input. Then the walls are yours to test. The plan below is the standard training layout: four sub-areas, five operable walls.
HARDWARE TRUTHS · one IRTR sensor per wall, transmitter facing receiver across the wall pocket (≤ 8 ft) · each IRTR is powered (EXPS-15V) and lands on a contact-closure input: one CCI module carries up to four walls, within 32 ft · an Area Controller holds up to two partitioned spaces of 10 sub-areas and 10 walls each. Flow mirrors the WaveLinx application note (v16, 2025).
Lighting platforms assume a fixed floor plan. Partitioning breaks that assumption. The walls move, so the relationship between rooms, zones, and devices keeps changing. The interface had to make that moving system simple enough to configure once and then leave alone.
A wall is a relationship between two rooms, not a device. Nothing in the platform modeled "these two sub-areas merge when this wall opens."
When a wall opens mid-event the lighting has to join up straight away, then separate again when the wall closes, without a staff member recalling scenes by hand.
Sub-areas, walls, joins, devices and contact inputs are a lot to set up. One wrong mapping and a wall lights the wrong rooms. The flow had to be guided and hard to get wrong.
"The wall moves. The lights should just know. I don't want to go find a laptop and open a program, I'm holding a phone."
I led the partitioning experience end to end. I defined the concept model, pitched it at the User Advisory Group, took the information architecture through three major versions, and delivered the configuration flow on mobile, tablet, and desktop.
Model the space the way the people running it think about it. Rooms first, walls as the relationships between them, rather than the way the hardware happens to be wired.
Get that mental model right and the contact-closure plumbing disappears behind a floor plan anyone can read.
Step through it. The shipped desktop wizard takes a room from "Partitioned" to fully wall-aware.
{{ verBody }}
The Area screen is where all of it lands: four zones and 54 devices under one partitioned Rose Ballroom. Sub-areas A through H each hold their own zones, devices and occupancy sets, and the screen reminds you that device assignment happens at the sub-area level. Edit Walls and Edit Sub Areas sit right there, so the whole model stays one tap from a change.

An installer configures partitions on a phone at the panel; a venue manager runs the room from a wall-mounted wallstation. The same three-step model, sub-areas → walls → devices, scales to each screen.
Once the controller knows the state of a wall, the behavior follows from it. With the walls closed, each wallstation operates only its own sub-area. When a wall opens, the wallstations in the rooms it joins command that whole joined space.
Partitioning taught me how to model a moving physical system in software. It came down to a modeling decision rather than a piece of interface: rooms became the primary object instead of walls, and the wall hardware fell in behind a floor plan anyone can read.
Getting there took three honest iterations and a willingness to throw out a V1 that was technically correct but that users could not reason about. The consolidated flow now reads the same on every surface, and the patterns it produced carry into the rest of the WaveLinx platform: relationship objects, guided wizards, and live state read from contact inputs.