Direct answer
For the Hue Bridge v2, controller eligibility, setup code, prior fabric, Thread/Wi-Fi and multi-admin support should be resolved. First, identify the exact protocol/controller and confirm active hub eligibility.
What this covers
- Hue Bridge v2 (BSB002)
- Hue Bridge v2; the hub every Zigbee accessory reports through, and the only component in a Hue system with its own network connection.
- The specific fault this record addresses: will not connect through Matter, HomeKit or another platform
What it does not cover
- ×The same symptom on a different Philips Hue product line, which has its own record and its own cited source
- ×An on-screen error code whose meaning has not been checked against this exact model's manual
- ×Live electrical, gas, sealed-system, internal battery-cell or structural repair — a technician boundary, not a self-service step
Differential
What actually causes this, and how to tell them apart
These are ordered by how often each one is the answer, not by how easy it is to try. The point of the middle column is that two causes producing the same headline symptom rarely produce the same detail — that detail is what tells you which one you have before you change anything.
- 1
The device is still commissioned to a fabric it can no longer reach
What separates it It appears in the old controller and works in none, or joins a new controller and drops out within minutes. A reset clears local settings on several implementations without clearing commissioning data.
How to confirm Remove it from every previous controller BEFORE resetting the hardware. Doing it in the other order is the single most common way this ends up unrecoverable without support.
- 2
The setup code has already been consumed
What separates it The code scans and is rejected as invalid or expired. Codes are consumed per commissioning attempt and a partially completed attempt can use one.
How to confirm Generate a fresh code from the manufacturer's own app rather than rescanning the printed label.
- 3
The platform does not support this device type
What separates it The device commissions successfully and some capabilities are missing on one platform. Standards cover a defined set of device types and attributes, and manufacturer-specific features fall outside them.
How to confirm Compare the capability list against what the standard defines for that device type. Missing extras is expected behaviour, not a fault.
- 4
The controller's own version is too old
What separates it Commissioning fails on one controller and succeeds on another. Support arrives in controller software releases, and an older hub simply does not know the device type.
How to confirm Check the controller's version against the manufacturer's stated requirement before changing anything on the device.
- 5
Multi-admin sharing was skipped in favour of a second commissioning
What separates it Adding the device to a second platform removed it from the first. Multi-admin exists precisely to avoid this, and commissioning again from scratch is not the same operation.
How to confirm Use the sharing or pairing-code flow from within the platform that already has it, rather than starting fresh from the printed code.
- 6
The device is on a network segment the controller cannot reach
What separates it Both are online and cannot find each other. IoT VLANs, guest networks and client isolation all break local discovery, which these protocols depend on.
How to confirm Put both on the same segment with isolation off for the test. Discovery here is local, not cloud-mediated.
Before you touch a setting
Record this first — changing settings destroys the evidence
Every item below stops existing the moment a reset, re-pair or settings change is made. Written down first, they are what separates the causes above; recovered afterwards, they are guesswork.
- Every controller and platform this device has ever been commissioned to, including ones no longer in use.
- The exact protocol involved and the exact controller version, both read rather than assumed.
- Whether the device commissions and then drops, or never commissions at all — these are different failures.
- Whether the setup code was printed or generated fresh in the manufacturer's app.
- Which network segment each of the device and the controller is on, and whether client isolation is enabled.
Remove it from every previous controller before touching the hardware
Reset / data riskThis order is the whole game. A reset clears local settings without clearing commissioning data on several implementations, and a device that still believes it belongs to an unreachable fabric will keep trying to rejoin it rather than accepting a new one — a state that frequently needs manufacturer support to clear.
Check the controller's version against the requirement
ReversibleSupport for a device type arrives in controller software, not in the accessory. Commissioning that fails on one controller and succeeds on another is a version gap, and nothing done to the device will close it.
Generate a fresh setup code rather than rescanning the label
ReversibleCodes are consumed per commissioning attempt and a partially completed attempt can use one. The printed label is a starting point, not a permanent credential.
Use multi-admin sharing to add a second platform
ReversibleCommissioning from scratch on a second platform can remove the device from the first. The sharing flow from inside the platform that already holds it is a different operation and is the one that keeps both.
Put the device and the controller on the same network segment
ReversibleDiscovery here is local rather than cloud-mediated, so IoT VLANs, guest networks and client isolation all break it while leaving both devices apparently online. Test with isolation off before concluding anything.
Confirm control from both platforms before finishing
ReversibleA device that works on the new platform and has silently dropped off the old one is a half-completed job. Test both, and test one of them away from the home network.
Model-specific
What is true of this model and not of its siblings
Generic advice for the product line fails here. Each item below is a property of this specific model family that changes which of the steps above apply to you.
- Model scope
- BSB002. Hue Bridge v2; the hub every Zigbee accessory reports through, and the only component in a Hue system with its own network connection.
- Capacity
- Philips states the Bridge supports up to 50 lights and 12 accessories. Those are two separate limits, and the accessory limit is the lower and the one people reach first — a switch or sensor that will not pair on a large system is worth checking against the 12-accessory figure before anything else.
- Network
- Connects to the router by Ethernet cable, not Wi-Fi. That is the single most useful fact about this device for troubleshooting: Wi-Fi problems cannot affect the Bridge's own connection, and a Wi-Fi fix will never help it. What can affect it is the cable, the router port and the router's client list.
- Radio to accessories
- Zigbee to every light and accessory. Accessories have no independent path to anything — they reach the Bridge over Zigbee and nothing else — so a Bridge fault presents as every light and switch failing at once, and no accessory-level check means anything until the Bridge is confirmed working.
- Power
- A supplied mains adapter, 120 V in the US, with standby power consumption stated as 0.1 W. There is no battery, so the Bridge stops with the power and returns with it, and everything commissioned to it stops too.
- Mesh behaviour
- Mains-powered Zigbee devices — the lights — repeat the mesh. Battery accessories such as dimmer switches and motion sensors do not. That is why adding another battery accessory never improves range, and adding a mains-powered light often does.
- Philips Hue's own specification
- Philips publishes the Bridge's specification at philips-hue.com/en-us/p/hue-bridge/046677458478, and its support section for the system at philips-hue.com/en-us/support/product/philips-hue-system/100005.
- Power path
- Mains adapter into a standard outlet. Switched outlets and outlets on a circuit that trips are the two failure modes that present as device faults. Use the supplied adapter — third-party adapters that supply the right voltage at the wrong current are a common cause of intermittent restarts.
- Radio
- Zigbee mesh through a bridge. The accessory has no independent internet path, so a bridge fault presents as every accessory failing at once. Mains-powered Zigbee devices repeat the mesh; battery ones do not, which is why adding a battery accessory never improves range.
- Radio
- Wired Ethernet available. A wired path removes signal strength, band steering and Wi-Fi credentials from the investigation entirely, and is worth using during diagnosis even if the device will end up wireless.
- Symptom boundary
- This record covers Philips Hue Hue Bridge v2 when it will not connect through Matter, HomeKit or another platform. A different symptom on the same hardware, or this symptom on a different Philips Hue product line, has its own record with its own causes and its own cited source.
Stop boundary
When this stops being a self-service repair
Continuing past any one of these costs more than the repair saves — in safety, in warranty, or in evidence a technician needs.
- !The device is locked to a fabric that no longer exists and will not accept a new commissioning after a documented reset. This generally needs the manufacturer.
- !The capability you need is not defined by the standard for this device type, which no configuration will produce.
Evidence ledger
Sources behind this answer
Visible sources support the visible claims. Home Product Support records the publisher, the fact used and the review date; community reports can suggest an issue but do not become a published fact on their own.
Where the manufacturer's article stops. Philips Hue Support publishes this as "Works with Philips Hue". Philips Hue's own list of the platforms and ecosystems it integrates with, which is the authority on what this device can be controlled from. What that article does not carry is the model boundary — it is written for a product line, and BSB002 is the scope applied here. Where a control label, terminal, indicator pattern or reset sequence differs on your unit, the manual for that exact model is the authority, not this page and not the article.
Exact questions
Common follow-ups
Does the Hue Bridge connect over Wi-Fi?+
No — it connects to your router by Ethernet cable. This is the most useful thing to know when troubleshooting it: a Wi-Fi problem cannot affect the Bridge's own connection, and no amount of Wi-Fi work will help. Check the cable, the router port and the router's client list instead.
How many devices can the Hue Bridge handle?+
Philips states up to 50 lights and 12 accessories. Those are separate limits, and the 12-accessory limit is the lower one — so a switch or sensor that refuses to pair on a large system is worth counting against that figure before assuming the accessory is faulty.
All my Hue lights stopped working at once.+
Check the Bridge first. Every light and accessory reaches it over Zigbee and has no independent path to anything else, so a Bridge fault takes the whole system out simultaneously. It also has no battery, so a power cut does the same thing.
Will adding another dimmer switch improve my Hue range?+
No. Mains-powered Zigbee devices — the lights — repeat the mesh; battery accessories such as switches and sensors do not. Adding a battery accessory adds a leaf to the network, not a relay. Adding a mains-powered light in the gap is what extends range.
How much power does the Bridge use?+
Philips states standby power consumption of 0.1 W, from a supplied mains adapter (120 V in the US). Its own consumption is negligible; what matters is that it has no battery, so anything depending on it stops during a power cut.
I reset it and now nothing can add it.+
That is the order problem, and it is the most common serious mistake on this symptom. A reset clears local settings without clearing commissioning data on several implementations, so the device still believes it belongs to a fabric it cannot reach and keeps trying to rejoin it. Removing it from the old controller first is what avoids this.
It joins and then disappears within minutes.+
That is the same disagreement seen from the other side — the device is being pulled back toward a fabric it still holds credentials for. It is not a signal problem, and improving the network will not change it.
The QR code says invalid.+
Setup codes are consumed per commissioning attempt, and a partially completed attempt can use one. Generate a fresh code in the manufacturer's own app instead of rescanning the printed label, which is a starting point rather than a permanent credential.
Adding it to a second platform removed it from the first.+
Commissioning from scratch is not the same operation as sharing. Multi-admin exists precisely so a device can belong to two platforms at once, and it is started from inside the platform that already holds the device — not from the printed code.
Some features are missing on one platform.+
Standards define a fixed set of device types and attributes, and manufacturer-specific extras fall outside them. Missing extras on a cross-platform integration is expected rather than broken, and the manufacturer's own app remains the place those features live.
Both devices are online and cannot find each other.+
Discovery here is local rather than cloud-mediated, so an IoT VLAN, a guest network or client isolation will break it while leaving both perfectly online. Put both on the same segment with isolation off before investigating anything else.
Is it worth using the manufacturer's app as well?+
Usually yes. The standard covers the common capabilities; the manufacturer's app covers everything else, including firmware updates and the settings that are not in the standard. Treating cross-platform control as a replacement rather than an addition is what produces most of the missing-feature complaints.
Does this answer apply to every Philips Hue model?+
No. It is scoped to BSB002. Hue Bridge v2; the hub every Zigbee accessory reports through, and the only component in a Hue system with its own network connection.
What should I record before troubleshooting Matter or HomeKit?+
Record the complete model identifier, exact message or indicator, software/firmware where visible, the operating stage and what still works.
Why is a factory reset not the first step?+
A reset can erase accounts, networks, maps, schedules or preferences without distinguishing Matter, HomeKit. The ordered checks preserve that evidence.
When should I stop and use qualified service?+
Keep setup codes private and do not reset locks/alarms casually.
Answer for the exact device and software version shown above.