FabianSeveral times a week I receive letters from users who have reached the capacity limit of the Philips Hue Bridge. 50 lamps are recommended by the manufacturer, up to 63 are theoretically possible. But in many cases that is no longer sufficient.
Every year, Signify launches dozens of new lamps on the market, and as the clear number one in the market, it always proves again and again that once you start with a few lamps, you quickly want more. But you better not reach the limit of the bridge – then comfort will soon be a thing of the past.
So it is no longer unusual for users to need two or even three bridges to operate their system – but then a great amount of comfort is lost. In the Hue app, only the lamps of one bridge can be controlled at a time, accessories are tied to one bridge, and even language assistants such as Amazon Alexa or Google Assistant only work with one bridge.
Join the petition now and help
A solution is therefore being searched for. Either the performance of the Hue Bridge has to be increased by an update or a new, better model has to be released. Alternatively I can imagine a working multi-bridge solution.
To show Signify that such a solution is necessary, I started a petition. Join in now and help get something going that is long overdue. Even if you're not currently affected by the problem, you should look to the future now. Maybe together we can achieve something.
Note: This article contains affiliate links. We receive a commission for purchases via these links, which we use to finance this blog. The purchase price remains unchanged for you.
The difficulty is not the bridge hardware or software or ZigBee (64K nodes). The problem is that ZigBee doesn’t have many time slots each second. ZigBee can send at most 50 commands per second, and in practice only 25. At 50 lights, the bridge needs 2 seconds to command all lights on or all lights off. The illusion of simultaneous response relies on device feature to allow a command to be scheduled to execute after a specified time delay. People don’t mind a little network delay and there is some additional obfuscation provided by the default behavior to change gradually rather than immediately turn on or turn off. The 2 second delay before the gradual change starts is accepted. If there were 100 lights the delay before they began to change would be 4 seconds, 200 lights 8 seconds, and so on. The system begins to feel a little sluggish at 50 lights (2 seconds). At 100 lights the delay would rankle.
It would add very little cost to add a second ZigBee radio on to the existing bridge hardware, but it wouldn’t solve the problem. Even on a different ZigBee channel, whenever one radio was transmitting the other would be deaf. This is also why the Wifi radio hardware in the Hue Bridge is disabled in software and the bridge has to use wired networking. In theory it should be possible to coordinate network transmit scheduling to keep the radios from deafening each other. In practice, that probably allows far fewer ZigBee commands per second and makes the system unresponsive with just a handful of lamps.
The only approach that allows a second ZigBee mesh on a different radio channel to double the command rate is to physically separate the ZigBee gateways.