DALI+ over Thread - System Design and Considerations

DALI+ over Thread — Commercial Wireless Design Guide (AU, 2025)

Professional guidance for openthread-based, DALI+ (wireless DALI over Thread) lighting systems in commercial buildings. 

1. Scope & audience

This document sets design, installation and commissioning guidance for DALI+ over Thread networks used for:

• General lighting (devices clustered relatively close together)
• Standalone emergency lighting (devices further apart)

It aims to help designers produce defensible designs that meet typical requirements and reduce liability. The guide assumes compliance with DALI-2 functional constraints (e.g., device counts, groups, scenes) and AS/NZS 2293 for emergency lighting. Vendor examples may reference zencontrol, but guidance is vendor-neutral.

Important: DALI+ transports normal DALI semantics over IP/Thread. Treat logical addressing, groups and scenes with the same care as wired DALI-2. Thread provides the bearer and mesh behaviour; it does not remove application-level limits.

2. Normative & informative references (designers must hold)

• IEC 62386 series, especially Part 104 (wireless & IP transport) and Parts 101/102/103 for general, control gear and control devices.
• AS/NZS 2293 (Emergency lighting and exit signs for buildings), all applicable parts.
• Thread Group specifications (v1.2+ / v1.3) and OpenThread implementation notes.
• Building and electrical standards applicable to the site (NCC/BCA, AS/NZS 3000, etc.).

3. Definitions & assumptions

• Thread: IPv6 mesh over IEEE 802.15.4 at 2.4 GHz; self-forming, self-healing.
• Router / REED: Mainspowered nodes that forward traffic; max active routers per Thread network is 32. End devices (often battery) do not forward traffic.
• Wireless application controller (WAC): One per Thread network, connected to the site Ethernet. Hosts the DALI application (e.g., zencontrol), group/scene logic and emergency scheduling, and provides the Thread network interface (no Thread Border Router used).
• DALI+: DALI frames carried over IP/Thread; use DALI2 counts unless a certified extension explicitly states otherwise.

4. Design principles (at a glance)

1. Design the RF first: channel plan, router density, path diversity, and BR placement are the backbone of reliability.
2. Respect DALI2 limits: plan lines/segments and logical groupings as you would on wired DALI.
3. Engineer for the worst day: emergency test storms, power restoration surges, and dense occupancy sensor traffic.
4. Two ways out: every device should have at least two dissimilar RF paths to the wireless application controller (WAC).
5. Document everything: provide the artefacts in §13 so the design is auditable.

5. Channel selection & coexistence (2.4 GHz)

IEEE 802.15.4 channels are 11–26 (2405–2480 MHz). Choose channels to minimise overlap with WiFi (1/6/11) and other 2.4 GHz users.

Recommendations

• Prefer channels 15, 20, 25 (and 26 where lawful) for Thread PANs; coordinate with the site WiFi team.
• One channel per PAN; avoid cochannel PANs in adjacent/overlapping areas. Reuse channels across vertical separation (e.g., alternate floors) or where ≥30–40 m separation exists.
• Maintain ≥8 m physical separation between WACs/routers and highpower WiFi APs where practicable.
• Avoid placing Thread channels centered near 2450 MHz where microwaves operate (heavy interference in break rooms).
• Lock channel after commissioning; only change with a staged plan and rollback.

Site practice

• Perform a spectrum survey and record live WiFi use per floor/zone.
• Freeze the PAN ID, Extended PAN ID, Network Name, Channel, and Master Key in the design record.

6. Topology, distance & routing

6.1 Router density & spacing

• Target 25–40% of nodes as Routers (mainspowered luminaires or dedicated repeaters).
• Aim for routertorouter spacing of 8–15 m in typical offices; reduce to 6–10 m in heavy concrete cores; extend to 15–20 m in open warehouses.
• Keep at least two neighbour routers above the acceptance RSSI (see §9.3) for each node.

6.2 Hops & partitions

• Design for ≤ 4 router hops from any device to the wireless application controller (WAC) under normal operation; ≤ 6 at absolute worst after a failure.
• Provide overlapping router coverage so a single corridor/room isn’t isolated; ensure at least two alternate routes to the wireless application controller (WAC).

6.3 Sparse/emergency networks

• When luminaires are far apart, add dedicated mainspowered Thread routers (small, unobtrusive, no DALI load) at corners, tees, stair entries and every 10–15 m down long corridors.
• In firerated/isolated plant rooms, put at least one router inside the enclosure (or route an external antenna in), and a router immediately outside the doorway.

7. Wireless application controller (WAC) placement

• Topology: Exactly one WAC per Thread network. Each Thread network in a building has its own WAC, connected to the building Ethernet (preferably wired to a floor distributor). Avoid WiFi uplinks for controllers.
• Distribution (do not colocate):
  • Do not install multiple WACs together in the same rack/cabinet or room. Distribute WACs across the building (e.g., per wing/fire compartment) so a local event cannot impact multiple networks.
  • Aim for separate rooms and ≥10 m physical separation between WACs serving different Thread networks; place on independent circuits/UPS where practicable.
• Mounting & environment:
  • Do not mount a WAC inside an electrical distribution board/switchboard (heat, EMC, segregation requirements, and RF attenuation from metal enclosures). Use a dedicated, ventilated enclosure compliant with AS/NZS 3000 segregation.
  • Keep WACs away from dense metal (racks/ducts/switchboards) and ≥8 m from highpower WiFi APs. Maintain ≥300–500 mm clearance from large metallic objects/cable trays/ducting.
  • Provide adequate ventilation and observe manufacturer temperature/humidity limits. Avoid mounting adjacent to highEMI sources (VFDs, large UPS, induction motors).
  • In isolated plant rooms or heavy concrete areas, prefer locations with good RF egress; where necessary, use approved remote/external antennas to bring the antenna out of shielded spaces.
• Services & labelling: Provide structured Ethernet (PoE if supported), UPS, and clear labelling (Thread Network Name, PAN ID, channel, controller ID). Ensure maintenance access without ceiling removal.

8. Environmental & building conditions

8.1 Walls, slabs, glass & lifts

• Concrete, brick and block walls attenuate strongly; reinforced concrete is worst. Tinted/lowE glass and mirrors reflect RF.
• Lift shafts, risers and plant rooms behave like Faraday cages; assume minimal leakage across them.

8.2 Roof spaces & cavities

• Expect high temperatures and foil-backed insulation/sarking. Avoid burying radios above foil; if unavoidable, drop antennas below foil with approved extensions and maintain required clearances.
• Provide service loops and mounting to keep antennas ≥300 mm away from metal ceiling grid or foil faces.

8.3 HVAC ducting & metalwork

• Do not mount radios directly on ducting. Maintain ≥300–500 mm lateral clearance from large ducts, cable trays and metallic cladding. Use offset brackets or remote antennas.

8.4 Isolated concrete rooms

• Add an internal router and an external router by the door. Consider a wireless application controller (WAC) with an external antenna feedthrough where cable penetrations are allowed.

9. RF performance targets & acceptance

9.1 Link budget

• Thread uses 2.4 GHz OQPSK at 250 kbps. Typical indoor attenuation: drywall ~3 dB; brick 10–15 dB; 240 mm concrete ~20–25 dB. Foil/metal can block almost completely. Use conservative margins.

9.2 Design targets (recommendations)

• RSSI ≥ −70 dBm to at least two neighbour routers in steady state; never worse than −80 dBm for any primary path.
• LQI in the top half of the device’s scale for primary links.
• Path diversity: ≥2 dissimilar routes to wireless application controller (WAC).

9.3 Commissioning acceptance tests

• Active scan and record neighbour tables at ≥20% of device locations per zone.
• Multicast and group command tests with < 250 ms typical response for lighting scenes in clustered networks and < 1 s for sparse areas.
• Packet loss: < 1% unicast, < 5% multicast over 5minute windows under normal load.

10. Network sizing & segmentation

10.1 DALI/DALI+ logical limits

• Per DALI2 subnet/line plan for: up to 64 control gear and up to 64 control devices, 16 groups and 16 scenes per line. Use multiple lines/segments where counts exceed these.

10.2 Thread practical limits

• Max 32 active routers per PAN; design for 16–24 to leave headroom.
• Children per router are implementationdependent; for lighting, prefer mainspowered devices as Routers rather than many sleepy children.
• For very large floors, segment by area (e.g., east/west wings) into multiple Thread networks, each with its own wireless application controller (WAC); coordinate between networks over the building Ethernet/IP at the application layer.

11. Bandwidth & traffic engineering

• PHY rate is 250 kbps, but effective throughput is far lower after headers, security and multihop retransmissions.
• DALI frames are small; control traffic is low, but bursts occur during commissioning, emergency tests and firmware updates.

Design rules

• Stagger emergency tests by zone/time to avoid multicast storms.
• Avoid overtheair bulk firmware across a single PAN during business hours; stage by BR and timeslice if required.
• WACs are Ethernet connected; avoid WiFi uplinks for controllers. Locally terminate analytics (avoid streaming raw telemetry over Thread).

12. Emergency lighting specifics

• DALI emergency gear must meet AS/NZS 2293. Wireless is used for control/monitoring/testing; illumination performance is not dependent on comms.
• Ensure failsafe behaviour: loss of comms must not inhibit emergency function. Controllers should queue and retry test/report uploads.
• RF design for emergency: add routers at exits, stairwells and refuge areas; ensure two independent RF paths from every emergency luminaire.
• Test scheduling: spread automated discharge tests across the maintenance window; use perarea calendars.

13. Installation practice

• Use fixtures with external or optimally oriented antennas; avoid enclosing radios behind metal bezels/canopies.
• Maintain separation from highEMI sources (VFDs, switchgear, large UPS, induction motors). Route antenna leads away from power conductors.
• Label every device with PAN ID, channel, device role (Router/ED) and DALI address where relevant.
• For zencontrol or other controllers, maintain UPS and network QoS (DSCP/priority as per vendor guidance).
• Do not install WACs inside electrical distribution boards/switchboards; use a dedicated enclosure with ventilation and maintain segregation per AS/NZS 3000.
• Distribute WACs across the building (do not colocate); separate rooms/racks, independent circuits/UPS, and adequate physical spacing (≥10 m) reduce commonmode risk.

14. Commissioning workflow (checklist)

1. Presurvey: floor plans, materials, WiFi maps, potential RF obstacles.
2. Channel plan: allocate PANs and channels; agree with IT.
3. Pilot row/zone: validate router spacing and acceptance metrics (§9.3).
4. Bulk join: commission in batches; lock down network credentials.
5. Functional: groups, scenes, sensors, emergency configs.
6. Soak test: 48–72 h with logs; verify loss/latency.
7. Handover pack: all artefacts in §15.

15. Designer deliverables (attach to reduce liability)

• RF survey results and channel plan per floor/PAN
• Router density map and WAC locations with power/UPS notes
• Material/obstacle register (areas with concrete cores, foil insulation, ducts)
• DALI line/segment schedules (64/64/16/16 rationale) and addressing plan
• Emergency routing assurance map (two paths to each emergency luminaire)
• Commissioning records: neighbour tables, RSSI/LQI snapshots, acceptance test logs
• Test calendars (emergency and maintenance), firmware update policy
• Risk assessment and variations agreed with the client/IT

16. Placement rules of thumb (quick reference)

• Router spacing: 8–15 m office; 6–10 m concrete cores; 15–20 m open areas
• Clearance to metal: ≥300–500 mm; to WiFi APs: ≥8 m
• RSSI to two neighbours: ≥ −70 dBm (target), never worse than −80 dBm
• Max router hops to the WAC: ≤ 4 (design), ≤ 6 (contingency)
• PAN size: 16–24 routers typical; split before approaching 32

17. Risk notes & disclaimers

• Figures here are engineering targets, not legal standards. Always verify the latest standards and vendor datasheets on the project start date.
• Building materials and layouts vary greatly; perform onsite validation.
• For critical areas (e.g., hospitals, data centres), engage RF specialists for predictive and onsite testing.

18. Appendix A — Thread channels & planning

• 2.4 GHz 802.15.4: channels 11–26.
• Prefer 15/20/25 (26 if permitted) to coexist with WiFi 1/6/11.
• Avoid cochannel PANs in adjacent zones; reuse with adequate separation.

19. Appendix B — Obstacle guide (indicative)

• Drywall/plasterboard: ~3 dB
• Brick: ~10–15 dB
• 240 mm concrete: ~20–25 dB (more with rebar)
• LowE/tinted glass/mirrors: variable, often high reflection
• Metal/foil (ducts, trays, foil sarking): severe attenuation; treat as nearblocking

20. Appendix C — Emergency design quick map

• Add routers at: exits, stair heads, corridor intersections, plant room entries
• Ensure two distinct RF paths to the wireless application controller (WAC)
• Schedule tests in rolling windows; never across an entire PAN at once