How we choose a protocol
Write the sequence first, then pick the protocol. The right question isn’t “DALI or wireless?” but “what does each space need to do, and what’s the simplest system that does it reliably?” Once the sequence of operations exists, the protocol choice usually becomes obvious.
Our defaults, which we’ll argue with when a building gives us reason to:
- New construction with detailed sequences: wired DALI-2, with D4i drivers where fixture-level energy data matters.
- Occupied retrofits: wireless luminaire-level controls, usually on Bluetooth Mesh NLC profiles, because they need little new wiring and little disruption. See wireless lighting control protocols.
- Keeping existing LED drivers: 0-10V dimming, accepting that no data comes back from the driver. Our guide to 0-10V, DALI-2, and D4i covers the tradeoffs.
- IT-led office renovations: PoE can make sense. We don’t recommend it for warehouses with long cable runs, and we always measure standby power. See PoE lighting: where it pays off.
- Matter: wait. Watch it, bench it, and keep it out of base-building lighting until commercial lighting device types exist. We explain why in Is Matter ready for commercial buildings?
Getting lighting to talk to the BMS
Ask for the gateway’s points list before you sign the purchase order. Integration is often priced per point, and a gateway that exposes 40 points per zone when the BMS needs four makes integration slow and expensive. We specify the exact points the BMS needs, usually occupancy, zone state, and energy, and map only those.
For new BMS work, we prefer BACnet/SC where both sides support it: it carries BACnet over TLS-secured connections with certificate-based authentication and avoids broadcast management devices. Where BACnet/IP is the only option, we keep it inside a segmented network. Our article on BACnet/SC for lighting networks goes deeper, and our lighting and BMS integration service describes the work.
Tagging decides whether data is usable
A point called “AV-1047” is useless to anyone who didn’t create it. Every point we integrate gets a consistent name, a checked unit, and a Brick or Project Haystack tag, so analytics tools, the BMS, and Ledger all agree on what it means. We follow ASHRAE 223P as it matures. See Brick, Haystack, and ASHRAE 223P.
Rules we follow on every integration
- Bench it first. Every new combination is tested in the Lytbit Lab on the firmware you’ll receive.
- Read-only by default. Write access is granted point by point and logged.
- Prefer local interfaces. Vendor cloud APIs change, apply rate limits, and sometimes require a subscription. Read the terms before a building depends on them.
- Document every point. Name, unit, tag, source, and owner go in the points list and the configuration report.
To compare protocols side by side, use the Protocol Explorer. For definitions, see the glossary. For hardware beyond lighting, see IoT hardware integration.
