Having been bitten by a change in the Hue discovery protocol a while ago that I've only just got round to figuring out and fixing, I figured it would be useful to stick this up somewhere where Google can find it. So, here we go...
When a Hue bridge boots up, it has a brief interaction with the Hue servers at meethue.com and sends it the bridge ID, its IP address and port. This is stored under the IP address that the Hue servers have for you - essentially REMOTE_HOST in CGI terms (or 'the answer whatismyip.com gives you').
When an app (such as the Hue app or the Alexa skill) wants to know where your hub is, it connects to discovery.meethue.com, which will look at your IP, and if there's a record (or more than one if you have multiple bridges, I guess) for it, returns it/them, like so:
[
{
"id":"001788fff536899d",
"internalipaddress":"192.168.0.14",
"port":443
}
]
The app then knows it can go find the bridge on the given internal IP, and you're all happily sorted.
Spotted the issue yet?
Yup - the wired sockets and one of the Wifi networks on my home network are from the /27 my ISP gave me two decades ago. The Hue is (obviously) on a different IP to my phone, and because there was no NAT involved, the bridge's info was stored on meethue.com under its actual routed IP.
Result, the answer from discovery.meethue.com is:
[]
Zip. Nada. Discovery failed.
To quote @tweethue:
That could be the issue. The bridge is designed to be used with a simple home router.
Well, duh.
Top comments (0)