PoE lighting delivers power and data to each luminaire over the same Ethernet cable, making per-fitting control and metering possible while reducing cabling and installation cost. It suits new-build and refit projects that want sensor-rich, individually addressable fixtures, provided you plan within IEEE 802.3bt power limits and the 100-metre Ethernet distance ceiling. Before committing, check the wattage each luminaire draws against your planned switch power budget.
TL;DR:
- Ensuring power budgets account for peak simultaneous load, not just fixture wattage, prevents dropouts and system failures.
- Using Cat6A cabling and proper switch capacity planning supports high-power fixtures and avoids issues with cable heating and insufficient headroom.
- Segmenting lighting onto dedicated VLANs and implementing security controls protect network integrity and facilitate reliable discovery and commissioning.
- A thorough commissioning process—including cable testing, fixture verification, and firmware updates—reduces rework and enhances long-term reliability.
- Coordinating electrical and network design early, especially mains and earthing, ensures compliance and prevents costly late-stage modifications.
Table of Contents
- How PoE lighting works and what makes up the system
- Standards, cabling and distance limits you need to plan around
- Designing the power budget for a lighting network
- Network architecture and security for lighting as an IP service
- Installing and commissioning a PoE lighting rollout
- Weighing the benefits against the real limitations
- UK wiring and earthing rules for PoE switch installations
- Connecting PoE lighting to wider building control systems
- Choosing fixture types and checking compatibility before you specify
- Keeping a PoE lighting network running reliably
- Why a managed approach reduces the risk in PoE lighting projects
- Getting your PoE lighting project off the ground
- Sources
- FAQ
How PoE lighting works and what makes up the system
PoE lighting works by combining electrical power and network data on one Cat cable, run from a switch to a luminaire instead of separate lighting and low-voltage circuits. According to Cisco, this delivers low-voltage DC power and data over a single Ethernet cable, removing the need for an AC-to-DC converter at every fixture and cutting installation complexity.
Three components define the system boundary:
- PSE (power sourcing equipment): a PoE switch or midspan injector that supplies power onto the cable.
- PD (powered device): the luminaire or driver that draws power and reports status back over the same link.
- Managed switch: handles power allocation, VLAN assignment, DHCP scope and telemetry, and usually exposes an API for lighting controller software.
Controller software sits above the switch layer, discovering fixtures, grouping them into zones and applying scenes or schedules. Commissioning tools query each PD for its power class and firmware version before it joins the live network, which is why discovery accuracy matters as much as raw switch capacity.
Standards, cabling and distance limits you need to plan around
The IEEE 802.3 family sets the power ceiling for any PoE lighting design. The earlier 802.3af and 802.3at amendments cap power well below what modern fixtures with embedded sensors need, while 802.3bt (Type 3 and Type 4) uses all four pairs of the cable to raise available power substantially. The IEEE 802.3cv amendment extends this further by standardising four-pair PoE delivery, and 802.3bt Type 4 supports up to roughly 90W per port, though the wattage actually available at the luminaire is somewhat lower once cable losses are accounted for.
Cabling choice determines how much of that power reaches the fixture intact:
- Cat5e is adequate for legacy, low-wattage PoE but leaves no headroom for higher-power fixtures or future upgrades.
- Cat6 improves resistance and heat performance over longer runs at higher currents.
- Cat6A is the practical choice for new PoE lighting installs, and Cisco and Molex design guidance recommends it where loads are high, since it leaves headroom for 10 Gigabit Ethernet and reduces resistance on long cable runs.
Ethernet’s 100 metre distance limit shapes where intermediate distribution frames (IDFs) sit in the building. On larger floorplates, plan additional IDFs or midspan injectors rather than stretching a single run past that ceiling, since a cable exceeding it will fail to deliver reliable power or data.
Designing the power budget for a lighting network
Getting the power budget right is the single most common point of failure in PoE lighting projects. Start with the wattage rating of each luminaire, then work through the switch and mains requirements methodically.
- List luminaire wattage per fixture type, including any sensor or driver overhead stated by the manufacturer.
- Multiply by expected simultaneous draw, not the fixture count alone, since dimming and scheduling mean not every fitting pulls full power at once.
- Add headroom: practitioner guidance referenced by BSI recommends N+1 switch redundancy or 20 to 30% power headroom on top of calculated load, since running a budget to its exact limit causes dropouts when fixtures draw peak current simultaneously.
- Total the switch power budget required per IDF, checking it against the published power budget of the switch model under consideration.
- Plan the mains feed: dedicated circuits sized to the switch’s maximum draw, correctly rated breakers, and rack cooling sufficient for sustained high-wattage PoE operation.
Switches drawing near their maximum PoE budget generate meaningful heat, and rack cooling is frequently underestimated at design stage. Cisco’s Catalyst 9300 guidance also points to features such as Perpetual PoE and redundant power supplies as a way to keep lighting live through a software reload or partial switch failure, which matters more for lighting than for a typical data endpoint.
Pro Tip: Size the switch budget on your peak simultaneous draw plus headroom, never on the sum of every fixture’s nameplate wattage.
For readers specifying switch hardware, our Catalyst overview covers resiliency features relevant to lighting deployments, and the Meraki MS130 series is worth reviewing for smaller access-layer installs.
Network architecture and security for lighting as an IP service
Once lighting runs over Ethernet, it becomes a network service with the same architectural requirements as any other IP device fleet. Segment lighting onto dedicated VLANs and subnets separate from user data and building management traffic, and size those VLANs deliberately: Cisco and Molex smart building guidance suggests keeping roughly 500 devices per VLAN as a practical ceiling, since discovery and multicast traffic can slow or fail at larger scale without splitting the estate.
Commissioning relies on standard protocols working correctly together:
- DHCP assigns addresses to each luminaire as it joins the network.
- LLDP and LLDP-MED, including lighting-specific TLVs, let switches and fixtures exchange power class and location data automatically.
- Vendor discovery tools then map fixtures to switch ports and controller zones during commissioning.
Security controls matter because a lighting fixture is now a network endpoint, not a passive load. The CalNext lab evaluation treats lighting endpoints as first-class IP devices requiring firmware lifecycle management and cybersecurity controls, not an afterthought bolted onto the electrical design. In practice this means DHCP snooping, port security, access control lists restricting lighting VLAN traffic, management plane restrictions on switch access, and a documented firmware update schedule. Our IoT security guide covers the same controls applied more broadly across connected building devices.
Installing and commissioning a PoE lighting rollout
A structured commissioning sequence avoids the rework that follows rushed installs. Before any fixture goes live, confirm cable test results, port and fixture labelling, and IDF power availability against the design budget.
- Configure the DHCP pool for the lighting VLAN, sized to the fixture count plus growth.
- Run discovery, using tools such as MoDiag or CoreSync to map fixtures to ports and confirm power class.
- Verify each fitting individually: correct dimming response, sensor reporting and controller grouping.
- Apply firmware updates to bring every PD to the same baseline before handover.
Ongoing operations then shift to per-luminaire energy metering, scheduled firmware patching in line with a documented cadence, and rack temperature monitoring where switches run near their power ceiling.
Pro Tip: Keep a spreadsheet or CMDB record mapping each luminaire’s MAC address, switch port and firmware version from day one, it turns a future fault-finding job into a five-minute lookup.
Our network infrastructure planning checklist covers rack, IDF and mains provisioning in more detail if you are scoping this stage.
Weighing the benefits against the real limitations
PoE lighting’s biggest returns come from granular control and monitoring rather than the cabling saving alone. IKAN’s analysis reports energy savings commonly ranging from 50% to 75% compared with older fluorescent systems, driven by daylight harvesting, occupancy sensing and per-fixture scheduling that legacy lighting circuits cannot offer.
The limits are real, though:
- Per-port wattage ceilings mean high-output fixtures may need Type 4 ports or midspan injectors, not standard access ports.
- Cable heating under sustained high current narrows the safety margin on long runs, particularly in bundled cable trays.
- Discovery tooling scales imperfectly past a few hundred fixtures per VLAN without segmentation.
The most common pitfalls are organisational rather than technical: under-provisioned power budgets, IT and facilities teams coordinating too late in the design phase, and mains or earthing planning treated as an afterthought once cabling is already installed.
UK wiring and earthing rules for PoE switch installations
PoE lighting removes AC wiring from most of the building, but it concentrates electrical requirements at the switch and IDF instead, and those points remain subject to full electrical regulation. Installation guidance from Elec-Mate confirms that BS 7671 implications apply directly to the mains feed supplying PoE switches: dedicated circuits, correct breaker sizing and proper earthing of network equipment are all required, alongside compliance with the data cabling standards in BS EN 50173 and BS EN 50174.
In practice, this means the electrical contractor and the network installer need to agree on IDF locations early, since each cabinet running high-power PoE now carries a mains supply obligation that a traditional data-only rack never had. Earthing network equipment correctly matters for both safety and signal integrity, particularly where PoE switches sit in a metal rack alongside other building services.
This is also where cable choice and electrical compliance intersect. Cat6A cabling reduces resistive losses on long runs, which lowers heat generation in bundled trays, a factor that features in fire safety assessments for cable containment. None of this replaces a qualified electrician’s sign-off, but it does mean the network design phase cannot be separated from the electrical design phase the way it often is on conventional data cabling projects. Treating the PoE switch cabinet as an electrical installation, not just a comms cabinet, avoids late-stage compliance issues that are expensive to fix once cable is in the ceiling void.

Connecting PoE lighting to wider building control systems
PoE lighting rarely operates in isolation once a building has other smart systems in place. Two integration paths come up repeatedly in commercial deployments: DALI over PoE, which lets existing DALI-based dimming and addressing logic run over the Ethernet backbone instead of a dedicated DALI bus, and BACnet integration, which allows the lighting controller to exchange occupancy, scheduling and energy data with the building management system.
Both integrations depend on the same architectural discipline covered earlier: VLAN segmentation, and stable discovery of every fixture as an addressable device. A BACnet gateway sitting on the lighting VLAN needs the same access control list restrictions as any other building system device, since it becomes a bridge between two previously separate networks.
The practical benefit is centralised control. Facilities teams can manage HVAC-linked occupancy sensing, lighting schedules and energy reporting from one interface rather than juggling separate DALI panels and a standalone BMS. That said, integration adds a dependency: if the network segment carrying lighting traffic goes down, so does the building’s ability to dim, schedule or report on it, which is another reason the switch redundancy and headroom planning covered earlier matters more for lighting than for a conventional data VLAN.
Choosing fixture types and checking compatibility before you specify
PoE luminaires broadly fall into a few categories: standard PoE-native fixtures with an integrated driver accepting power directly from the Ethernet cable, PoE-to-DALI adapters that let conventional DALI fixtures join a PoE network without replacement, and sensor-integrated fixtures combining occupancy, daylight and temperature sensing in the same housing as the light source.

Compatibility checks matter before procurement, not after. Confirm the fixture’s power class against the switch port’s available wattage, since a Type 4 fixture on a Type 3 port simply will not power up correctly. Confirm also whether the fixture supports the LLDP-MED lighting TLVs your discovery tooling expects, since a fixture that reports incorrectly can appear on the network but fail commissioning verification.
Mixed-vendor estates are common in refit projects, where existing DALI fixtures sit alongside new PoE-native luminaires. This is workable, but it means the controller software needs to support both protocols simultaneously, and the commissioning checklist needs a compatibility pass for each fixture type rather than a single blanket test.
Keeping a PoE lighting network running reliably
Most faults in an operating PoE lighting network trace back to one of three causes: a power budget issue, a discovery or addressing problem, or a firmware mismatch. A fixture that fails to power on is usually either exceeding the port’s available wattage or sitting on a cable run degraded past a usable distance, both of which show up quickly in switch port diagnostics.
Fixtures that power on but fail to respond to control commands are more often a discovery or VLAN issue: check the DHCP lease, confirm LLDP is exchanging correctly, and verify the fixture sits on the expected VLAN. Firmware mismatches across a mixed-age fixture estate are a slower-burning problem, since a fixture running old firmware may report incorrectly to the controller even while functioning normally as a light source.
Routine maintenance should include scheduled firmware patching in line with the CalNext lab evaluation’s recommendation to treat lighting endpoints as IP devices requiring lifecycle management, rack temperature checks where switches run close to their power ceiling, and periodic review of the per-luminaire metering data for fixtures drawing outside their expected range, which is often the earliest sign of a failing driver.
Why a managed approach reduces the risk in PoE lighting projects
PoE lighting projects tend to fail for the same reasons other network projects fail: power budgets calculated too late, and IT and facilities teams coordinating after design decisions are already locked in. A network audit or wireless survey before specification catches both issues early, and managed services or NaaS engagements then carry the firmware and monitoring workload that lighting endpoints require indefinitely, not just at handover.
When evaluating any provider for this work, ask for power-budget verification against your fixture schedule, a documented commissioning toolkit, and a firmware and patching SLA covering the lighting fleet specifically.
— Jacob
Getting your PoE lighting project off the ground
Whichever stage you are at, there is a service that matches it. A network audit suits teams still scoping feasibility and power budgets, a wireless survey helps where lighting will share infrastructure with other wireless systems, and Network As A Service suits organisations that want predictable ongoing costs for switch provisioning and monitoring rather than a one-off capital project. For readers who want design and delivery support directly, our professional services team can help scope a PoE lighting rollout from power budget through to commissioning.
- Scoping stage: request a network audit to verify power budgets and cabling readiness.
- Design stage: a wireless survey identifies conflicts where lighting shares infrastructure with other systems.
- Operations stage: NaaS or managed services cover switch provisioning, firmware patching and monitoring.
Sources
For deeper technical detail, consult the IEEE 802.3cv amendment for four-pair PoE standards, Cisco and Molex’s design guidance for cabling and deployment, and the CalNext lab evaluation for power and cybersecurity findings. For compact PSE hardware suited to smaller deployments, this 8-port metal-case switch is worth reviewing.
- What is PoE Lighting? – Cisco
- IEEE 802.3cv amendment (PoE over 4 pairs) – IEEE Standards
- Power over Ethernet lighting install guide – Elec‑Mate
- PoE microgrid lab evaluation and cybersecurity considerations – CalNext
FAQ
What is PoE in lighting?
PoE in lighting means a luminaire receives both its electrical power and its control data over a single Ethernet cable instead of separate mains wiring and control wiring. This is possible because PoE lighting delivers low-voltage DC power alongside data, removing the need for an AC-to-DC converter at each fixture.
What is PoE networking?
PoE networking is the general standard, defined by IEEE 802.3 and its amendments, for delivering electrical power over the same Ethernet cable that carries network data. It covers any powered device, from IP phones and cameras to lighting fixtures, that draws power from a compatible switch or midspan injector rather than a separate electrical supply.
What are the drawbacks of using PoE for lighting?
The main drawbacks are the per-port wattage ceiling set by the IEEE 802.3bt standard, cable heating on long high-current runs, and discovery tooling that scales imperfectly beyond a few hundred fixtures per VLAN without segmentation. Coordinating power budgets and mains provisioning between IT and facilities teams early in the project avoids most of these issues.
How do I set up a PoE lighting network?
Setting up a PoE lighting network starts with calculating your power budget from luminaire wattage and expected simultaneous draw, then adding headroom before selecting switch hardware. Commissioning then follows a standard sequence: configure DHCP, run discovery tools such as MoDiag or CoreSync, verify each fixture individually, and apply firmware updates before handover.
Recommended
- DfE Wireless Standards & Cisco Meraki
- Network Infrastructure Planning Simplified
- DfE Switching Standards & Cisco Meraki
- The role of IoT in smart buildings: a 2026 guide







