We Installed 340 Legrand Devices. The Problem Wasn't the Devices.

What the inspection didn't catch

It was a Tuesday in March 2024 when the facilities manager forwarded the first complaint. We'd commissioned 340 Legrand devices two weeks earlier — radiant and adorne switches, a dozen 0-10V dimmers, four runs of Legrand undercabinet LED, occupancy sensors in the restrooms, and a set of Zigbee Deckenleuchte fixtures we'd spec'd for the corridor ceiling. The walkthrough passed. The client signed off. Then the west wing started behaving like a network with a bad cold.

Pressing a switch took two seconds. Sometimes four. The occupancy sensors in the hallway were triggering lights in a conference room on the other side of the wall. One dimmer would randomly drop to 10% and stay there until someone cycled the breaker. Nothing was broken, exactly. It was just slow. The kind of slow that makes people think the system is cheap.

I've been handling lighting control orders for nine years. I've made — and written down — 14 significant mistakes, roughly $18,000 in wasted budget across those projects. This one was number 13, and it's the one that changed how we scope jobs.

We spent a week blaming the hardware

First instinct: bad devices. We swapped two switches, reflashed the gateway firmware, replaced an occupancy sensor that seemed to be the common thread. The problem followed the network, not the hardware. That's when our commissioning tech pulled the Zigbee traffic logs and found the actual issue: we'd built a mesh that was technically compliant and practically congested.

Here's what I didn't appreciate at the time. Zigbee bandwidth runs on 2.4 GHz, uses 16 channels, and the radio spec tops out around 250 kbps — and that's theoretical throughput before protocol overhead, retries, and mesh routing. It's not a lot of headroom. A small office with 20 devices won't notice. A 340-device deployment where every switch, sensor, and fixture is chatting on the same mesh absolutely will.

Zigbee's data rate is 250 kbps at 2.4 GHz per IEEE 802.15.4. Real-world throughput is lower once you account for protocol overhead and mesh routing. The Connectivity Standards Alliance publishes the spec; the practical capacity planning is on you.

The kicker is that nothing in the Legrand documentation lied to us. The devices were fine. The Zigbee ecosystem did exactly what it was supposed to do — open interoperability, no proprietary lock-in, solid device-level reliability. We just never did the math on what happens when you put 340 nodes on one network and expect instant response during a shift change.

The deeper problem: we treated every lighting question as a control question

Around the same time, a greenhouse operator I'd worked with on a smaller job asked me something that stuck. She wanted to know if she could put her seedling grow lights on a Legrand dimmer channel and asked, almost as an afterthought, "how close should the grow light be to seedlings?"

I started answering with dimmer percentages. She stopped me. The question wasn't about control at all — it was about PPFD at the canopy and whether her fixture height was right for the growth stage. Seedlings generally want something in the 100–300 µmol/m²/s range depending on species and fixture, and the distance from the canopy is what sets that, not the dimmer setting. A dimmer changes power draw; it doesn't fix a light that's hanging 40 cm too high.

That conversation reframed the March project for me. We'd spent weeks tuning Legrand lighting control logic when the actual constraint was physical and network-level. The system was fine. The design wasn't.

I should add that Zigbee 3.0 genuinely does make multi-vendor interoperability easier — that part of the marketing holds up. What it doesn't do is plan your channel usage, your router-to-end-device ratio, or your broadcast traffic during scene recalls.

What it cost

The rework wasn't catastrophic. It was worse than that — it was embarrassing and slow. We ended up re-architecting the mesh: splitting the west wing onto a second Zigbee network with its own gateway, adding six always-powered routers in the corridor, and rewriting the scene logic so a single button press didn't fan out to every fixture in the building. Total: about $2,400 in labor and replacement parts, plus 11 days of scheduling churn.

The client's event date didn't move. We made it, but we made it by eating overtime and pulling two techs off another job. That's the part nobody puts in the proposal. The invoice said $2,400. The real cost was the 11 days we couldn't bill and the follow-up meeting where the facilities manager asked, politely, whether we'd done this before.

I knew I should have run a proper site survey and a device-density calculation before signing off on the bill of materials. But the project was moving fast, the spec looked standard, and I thought "340 devices, it'll be fine." That was the one time it wasn't fine.

Looking back, I should have paid for the extra site walk and the network design review upfront. At the time, it felt like a line item the client wouldn't approve. Given what I knew then — that Legrand's Zigbee devices are reliable and the protocol is designed for exactly this kind of deployment — my confidence was reasonable. It was also wrong.

What we do now, before a single device ships

None of this is exotic. It's just the stuff that gets skipped when a deadline is close.

1. Count nodes, not just fixtures. Every switch, sensor, dimmer, and Zigbee Deckenleuchte is a node. If the plan puts more than roughly 50–60 devices on a single mesh without a clear router strategy, we split the network or add a gateway. That threshold isn't a Zigbee limit — it's our comfort line after getting burned.
2. Map the routers first. Mains-powered devices (switches, dimmers, undercabinet LED drivers) route traffic. Battery sensors don't. If a wing is mostly sensors and end devices, the mesh gets thin fast. We now spec at least one router per room cluster.
3. Cut broadcast traffic at the scene level. Group binding and local scene control beat "gateway tells every device" every time. That's where most of our latency came from.
4. Do a 30-minute channel scan. 2.4 GHz is crowded. Wi-Fi, microwaves, and neighboring Zigbee networks all share the band. We pick a channel after scanning, not before.
5. Separate the control question from the physics question. If someone asks how close a grow light should be to seedlings, the answer isn't a dimmer setting. Same for corridor lighting — if the fixture spacing is wrong, no amount of Legrand lighting control tuning will fix the dark spots.

We've caught 47 potential network issues with this checklist in the past 18 months. Most of them were the kind of thing that wouldn't have shown up until week three.

The part that still bugs me

I went back and forth for two weeks on whether to recommend the cheaper bill of materials or the one with the extra gateway and the site survey. The cheaper option saved the client about $1,100 on paper. The survey and second gateway added roughly $900 and a day of scheduling. I chose cheap because the deadline was tight and the client was price-sensitive.

That was the wrong trade. Not because cheap is always wrong, but because in a deadline-driven project, the thing you're actually buying with the extra $900 is certainty — the knowledge that the system won't need a second commissioning pass while the client is watching. Missing the event date would have cost the client far more than $900. It nearly cost us the account.

This worked for us on a 340-device commercial retrofit. If you're doing a 20-device residential job with a single room of Legrand undercabinet LED, the calculus is different — you probably don't need a second gateway or a formal channel plan. I can only speak to mid-size commercial work where the device count crosses triple digits. Your mileage may vary if you're running a smaller, simpler mesh.

The devices were never the problem. The planning was. And the planning is the part you can't rush, even when — especially when — the deadline says you should.