search

ebaauw / homebridge-hue

Homebridge plugin for Philips Hue
Apache License 2.0
897 stars 91 forks source link

ph discover across vlans #1120

Closed BiGassKanga closed 1 year ago

BiGassKanga commented 1 year ago

Issue

My homebridge is on a separate vlan to my hue bridges,

PH discover does the discover on the vlan it is on 192.xxx.xxx.1

But I want to discover the bridges on 192.xxx.yyy.1

At the moment I can get ph discover to do a search on the vlan gateway (192.xxx.xxx.1). I want it to do the discover on the other vlan's gateway.

Question I have allowed the homebridge pi and the hue bridges to speak to one another across the vlans to get the security tokens etc? After the philips hue button is pressed?

Can i specify the gateway for the PH discover function?

If so how?

ebaauw commented 1 year ago

No, you cannot. This is not a limitation of ph, but simply how Hue implements discovery.

Bridge discovery uses the meethue portal for cloud-based discovery and UPnP or mDNS (Bonjour) for local discovery.

For meethue discovery to work, the Hue bridge needs to reach the portal using the same public IPv4 address as the client doing the discovery. It doesn’t matter whether the bridge and the discovery client are on the same subnet, as long as the bridge is reachable by the client.

Both UPnP and mDNS use a local link multicast address, so local discovery only works on the same subnet. You might be able to setup the router between the subnets to forward (“deflect”) UPnP or mDNS, but that’s beyond my experience.

Note that HomeKit uses mDNS to discover accessories, so Homebridge needs to be on the same subnet as your Apple devices. Unless you can configure your router as mDNS deflector.

BiGassKanga commented 1 year ago

Thank you. I've resolved the issue by doing the following steps. I'm sure there is a better way but this way worked

  1. Set a firewall rule to allow my IOT Vlan Homebridge to talk two way with my Hue bridges that are set on the Hue VLAN
  2. Temporarily moved my IOT Vlan Homebridge to be on the Hue VLAN. Got the meethue discovery to do its magic.
  3. Configured Hue Homebridge as appropriate on the Hue VLAN. Tested it. It worked. Add the bridges into HomeKit - tested it worked,
  4. Moved Homebridge from Hue VLAN to IOT Vlan. Tested. It worked.

Anyhow maybe I should ditch the Hue VLAN altogether and make everything on one VLAN. In any event I've learnt something today and want to say thank you for developing and maintaining a Homebridge Hue plugin which allows my non-Hue lights to work in HomeKit.

ebaauw commented 1 year ago

My home only has a separate subnet for guest access, everything else is on the same subnet. While I do have enough of a professional IT background to understand and setup multiple subnets/VLANs at home, I haven’t done so, because it’s too much of a hassle. I think, ideally, I would run Homebridge on a multi-homed system, with one leg in the “internal” VLAN were my devices (like the Hue bridge) reside, and one leg in the “user access” VLAN, were my Apple devices reside. Of course, this would disable any native apps (like the Hue app) connecting to my devices (like the Hue bridge), but if you believe in HomeKit’s security paradigm, that would be the right approach. As I said: too much hassle.

It’s somewhat frustrating to see that most protocols (HAP, Hue API, Sonos SOAP API, Nuki bridge API) are local and perfectly routable, but, for discovery, you still need Internet connectivity and/or the same subnet. My newer plugins (based on homebridge-lib) will remember previously discovered devices, so you would only need discovery for new devices and/or new device IP addresses. However, Homebridge Hue still uses the old Homebridge plugin model (of static platform accessories), and has no memory across sessions. Consequently, it needs to rediscover all devices on each Homebridge startup. Homebridge deCONZ and Homebridge Hue2 will remedy that.