The decision: PoE, conventional, or wireless
Power over Ethernet lighting runs low-voltage power and data to each fixture over the same cable, from a network switch rather than a lighting panel. Every fixture becomes a network device with its own address, sensor and energy reading. That is a strong idea, and in the right building it works well.
It is also a different way of owning lighting. The fixtures depend on switches, the switches depend on IT, and the energy bill now includes network gear that runs all night. So the question is whether PoE fits your building, or whether a conventional or wireless system would serve you better. We treat PoE as advisory and pilot work for that reason: we would rather prove it on one floor than recommend it for every floor.
Where it pays and where it doesn’t
| Building or space | Our view | Why |
|---|---|---|
| Dense open office floor, ceilings open for renovation | Good candidate | Short runs, many fixtures per switch, IT ownership, rich sensor data |
| Historic or hard-to-rewire office building | Worth a pilot | Low-voltage cabling can simplify pathways; confirm local requirements first |
| Healthcare and labs | Case by case | Emergency power, infection control and uptime requirements add complexity |
| High-bay warehouse or plant | Not recommended | Long runs, high fixture wattage and sparse layouts |
| Parking structures, long corridors, exterior | Not recommended | The 100-meter channel limit and environmental exposure |
| Small building without managed IT | Not recommended | Nobody to own the switches |
Standby power is the cost nobody models
A lighting panel sits idle at night. A PoE switch doesn’t. Switches draw power around the clock, so a floor that is dark from 7 p.m. to 7 a.m. and all weekend still consumes energy in the closet. A GSA trial of PoE lighting found lower installation cost but higher standby power, and that matches what we see on the bench.
Our energy model includes measured switch standby, not just fixture watts. In some buildings PoE still comes out ahead. In others, the standby draw erases the controls savings that made it attractive.
IT and facilities have to agree who owns it
PoE puts lighting on the network, which raises questions that conventional controls never did. Who approves a switch firmware update that will reboot a floor’s lights? Who carries spare switches? Who gets the alert when a port fails, and who answers occupants when a zone goes dark? We write a responsibility matrix with both teams before design, and we treat the lighting network as part of your building network security scope.
Emergency lighting questions to settle first
Egress lighting must stay on when normal power fails, and with PoE it also depends on switches and network power. Before design we answer, with your authority having jurisdiction:
- how emergency luminaires are powered: local battery, central inverter or switches on backup power;
- which listings the emergency path relies on, such as UL 924 for emergency lighting equipment;
- what happens to egress lighting during a switch reboot or failure;
- how the emergency path will be tested and documented.
What the Lab tests
The Lytbit Lab keeps PoE switches on the bench alongside drivers, sensors and controllers from several ecosystems. For a pilot we measure port power under load against the IEEE 802.3bt budget, standby draw, behavior during reboot, failover and firmware updates, and whether the lights come back in their last state or at full output. The results become a Bench Note you keep.
DC lighting beyond PoE
PoE is one form of DC lighting. Centralized DC power distribution and low-voltage lighting circuits raise similar questions about ownership, standby losses and listings. We assess them the same way: advisory first, a pilot if the case holds up. See a representative historic office PoE scenario for how a pilot can be structured.
