From time to time, you will encounter situations where common DALI is wired to multiple bridges. When this happens, you may experience comms errors, controller saying "Other Controllers Detected" and in some cases, loopback scenarios where commands are endlessly fed back into the system, often flooding the network. This can be fixed by correcting the wiring or turning off components on the devices to ensure that they are not in conflict.
The Setup
Each Thread-DALI bridge has two ways of being reached:
- Wirelessly, over Thread — it answers queries directly.
- Over the wired DALI bus — it can forward Thread commands onto DALI, collect the response, and send it back over Thread.
Bridges also forward in the other direction: commands they hear on the DALI bus get republished onto Thread, so Thread-side controllers and devices stay in sync with what's happening on the wire.
A single DALI bus can have:
- Plain DALI-native devices (no Thread).
- More than one Thread-DALI bridge wired onto it.
The Problem
When two Thread-DALI bridges share the same DALI bus, things go wrong in several ways depending on configuration.
Problem 1: Both bridges are bridging
A query goes out on Thread for a device. You get two answers back:
- The target device answers directly over Thread.
- The other bridge hears the same Thread query, forwards it onto the DALI bus, receives the DALI reply from the same target, and sends that reply back over Thread.
Two responses arrive. They represent the same answer but came via different paths, and the requester can't tell. This looks like a cloned dali address to the controller and it will generally react by deleting and readdressing the two addresses, in order to recover the legitimate device that should be at this address, which in this case is both of the "devices" it discovers.
Problem 2: Only one bridge is bridging
Turning off bridging on one of the two bridges helps for queries aimed at plain DALI-native devices — only the still-bridging device forwards those, so one clean response comes back.
But queries aimed at one of the Thread bridges themselves still double up:
- The target bridge answers directly over Thread.
- The target bridge is also still a device on the DALI bus, so it also answers on DALI. The other (still-bridging) device picks up that DALI reply and relays it back over Thread.
Same duplication, different path. Disabling bridging stops a device from forwarding other devices' traffic, but it doesn't stop the device from responding to DALI queries aimed at itself.
Problem 3: Bridges belonging to different Thread controllers
This one is worse than duplication — it's a fight.
If the two Thread-DALI bridges on the shared DALI bus are paired to different Thread controllers, each controller independently believes it owns the DALI devices reachable through its bridge. Both controllers can issue commands for the same DALI device at the same time, and both bridges put those commands onto the shared DALI bus.
What you see:
- Controller A tells its bridge to set a DALI device to one state. The bridge puts that command on the bus.
- Controller B, around the same time, tells its bridge to set the same DALI device to a different state. That bridge puts its command on the bus too.
- The DALI device flip-flops, or settles on whichever command landed last, and neither controller's view of the world matches reality.
It also compounds Problems 1 and 2: queries from either controller can produce duplicate replies, and now those replies may be inconsistent with each other because the two controllers have been issuing conflicting commands.
The root cause is that a single DALI bus has effectively been given two owners. DALI itself has no concept of arbitrating between them.
Problem 4: DALI-to-Thread forwarding loop
This one isn't just confusing — it can take the whole Thread network down.
Bridges forward DALI traffic up to Thread, not just Thread traffic down to DALI. That's normally fine. But with two bridging bridges sharing a DALI bus, it creates a feedback loop:
- A device on the DALI bus issues a command — say, recall max.
- Both bridges hear it on the DALI bus and dutifully forward it to Thread.
- Each bridge then hears the other bridge's Thread transmission of that same command and treats it as a Thread command that needs to go down to DALI.
- Both bridges put recall max back onto the DALI bus.
- Both bridges hear it on DALI again and forward it to Thread again.
- Repeat, immediately, forever.
The loop has no natural damping. Each cycle generates more Thread traffic and more DALI traffic than the last, and the Thread mesh saturates very quickly. The DALI bus is also flooded with redundant repeats of the same command.
The trigger doesn't have to be recall max — any DALI-side command will set it off. The mechanism is just: two bridges, each forwarding what the other forwards, with no deduplication.
The Fix
Four things need to be true at the same time:
- Only one bridge on the shared DALI bus should have bridging enabled. This is what makes plain DALI-native devices reachable from Thread without duplicate forwarding — and it's also what prevents the DALI-to-Thread feedback loop, since a loop requires at least two forwarders.
- A bridge that has a thread connection to the controller, whose bridging is turned off should also have its DALI turned off. Otherwise it's still answering on both transports and you get doubled replies for queries aimed at it. There are reasons to have a bridge a solitary DALI device (such as if you wish to simply use the device as a switch / sensor slave, so this is not a concrete rule. As long as they are not on the thread, this is fine.
- All bridges sharing a DALI bus must belong to the same Thread controller. A DALI bus has one owner. If two bridges on the same bus are paired to different controllers, you have two owners issuing conflicting commands, and the bus state becomes unpredictable. Either re-pair the bridges to a single controller, or physically separate the DALI buses so each controller owns its own.
- Never have more than one bridge forwarding on a shared DALI bus. Even briefly. The feedback loop in Problem 4 starts the moment any DALI-side command is issued, and it escalates fast enough to disrupt Thread within seconds.
Put differently: each Thread-DALI bridge should present itself on exactly one transport at a time, each DALI bus should have exactly one controller in charge of it, and each DALI bus should have exactly one bridge doing the forwarding.
If the controller can talk to the device (frequently a challenge), you may be able to turn off the bridging and DALI yourself. This can be done in the Device Location -> Peripheral view.
Quick Reference
| Bridge role on the shared bus | Thread response | DALI response | Controller |
|---|---|---|---|
| Bridging device (one per bus) | On | On (for itself and forwarded traffic) | Same as all other bridges on this bus |
| Non-bridging device | On | Off | Same as all other bridges on this bus |
| Plain DALI-native device | n/a | On | n/a |
Case Study: Recovering a Smart Switch Stuck in Comms Error
This is a worked example showing why both settings — bridging and DALI response — matter, and the order operations need to happen in to recover a device cleanly.
The setup
- 256.60 — a smart switch. Has both Thread and DALI.
- 256.23 — a PIR. Has both Thread and DALI. Sits on the same shared DALI bus as 256.60.
- Other DALI-native devices also live under 256.23's bridge.
The PIR (256.23) needs to keep bridging on, because it's the path to the other DALI-native devices on that bus. So we can't just turn bridging off everywhere — one bridge has to remain the forwarder.
The symptom
256.60 is in comms error. It's physically there and working, but the controller's view of it is broken because two devices are answering for it:
- 256.60 itself, answering directly over its own Thread.
- 256.23, which receives Thread queries aimed at 256.60, forwards them down to the DALI bus, hears 256.60 answer on DALI (because 256.60's DALI response is still on), and relays that answer back up to Thread.
This is Problem 2 from above, in the wild.
The mistake — turning off bridging only
The first attempt was to turn off bridging on 256.60. That seemed like the obvious move and it does help in one direction: 256.60 can no longer be used as the forwarder for other devices on the bus.
But it doesn't fix the comms error on 256.60 itself. Because 256.60's DALI response is still on, 256.23 can still query 256.60 over DALI and answer for it on Thread. So 256.60 is still appearing twice on the network — once via its own Thread, once via 256.23's bridge — and the controller still sees it in comms error.
It also didn't fully clean things up for 256.23: 256.23 was still reachable in two ways (its own Thread, and via 256.60 querying it over DALI back when 256.60's bridging had been on), and 256.23 was also in comms error.
The lesson here: turning off bridging stops a device forwarding other devices' traffic. It does not stop the device itself being reachable over DALI. Those are two separate settings, and recovering a device in comms error needs both.
The fix — order of operations
The recovery had to be done in a specific order, because at every step there must be exactly one path to each device:
- Turn off bridging and DALI response on 256.23. This silences the PIR completely on the shared DALI bus. It's now only reachable via its own Thread. Crucially, it can no longer answer for 256.60 over DALI, because it's no longer participating on DALI at all.
- Let the controller recover 256.60. With only one path to it (its own Thread), the duplicate-answer condition is gone and the comms error clears.
- Turn off DALI response on 256.60. Now 256.60 presents on Thread only — it won't answer DALI queries aimed at itself, so it can't be double-answered in future when bridging is restored on the bus.
- Turn bridging and DALI response back on for 256.23. The PIR resumes its job as the bus's single forwarder. 256.60 is reachable only via its own Thread; 256.23 doesn't answer for it because 256.60 is no longer responding on DALI.
End state: each device has exactly one path to it. 256.23 is the bus's single forwarder for the DALI-native devices. 256.60 lives on Thread only. No duplicates, no comms errors.
Takeaway
When you have a Thread-capable device in comms error on a shared DALI bus, "turn off bridging" is not enough. You have to turn off DALI response on that device as well, otherwise another bridge on the same bus will keep answering for it. And if a second Thread-capable device is also misbehaving, silence it completely first (bridging and DALI off) before trying to recover the first one — otherwise you're still chasing duplicate paths.
Comments
0 comments
Please sign in to leave a comment.