docker-homebridge
docker-homebridge copied to clipboard
Docker Desktop: Host Networking on macOS and Windows.
Current Situation
The wiki states here that Windows and macOS are not supported as they lack the --net=host parameter. This is no longer the case in Docker Desktop 4.34.0. Homebridge does indeed start and appears to function as expected with one minor issue, the detected IP addresses are that of the docker container itself, and not the host.
Proposed Change
Allow a configuration variable to force Homebridge to advertise itself on a given IP address even if it's not bound to it, this should allow HomeKit to find the Homeridge instance.
Additional Context
Docker Desktop documentation: https://docs.docker.com/engine/network/drivers/host/#docker-desktop
Let me test this out, then will update the documentation.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This issue has been closed as no further activity has occurred.
Noticed this issue has been re-opened. When will it be fixed? Recently I was having trouble adding HomeBridge to HomeKit.
So I took some time today to look at this closer on my Intel Mac mini, running macOS Monterey. And while I was able to make some progress, was not able to get homebridge to work.
For the setup, I first enabled host networking in the Docker Desktop
I then used the current docker-compose.yml file for docker-home bridge, and was able to start homebridge. And was able to access the UI via the url http://docker-desktop.local:8581
I was able to install a couple of plugins without issue, and things appeared to work from the Homebridge UI side of things.
But I was unable to pair Homebridge with the home app on my phone.
And looking deeper, the issue is how Docker handle's local ip addresses on MacOS versus linux. On linux the docker container uses the same IP address as the host, while on MacOS it uses its own IP address on a different network.
My host / primary network is 192.168.1.x, and not what you see here.
What was interesting, was that I could access the homebridge instances and the UI remotely by using the host computers IP address and the proper port number from inside the container.
To get homebridge to work, we would likely need to fool the mDNS Advertiser to think it is working from the host interface, and use its IP address in the advertisements.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Bumping this feature ask
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This issue has been closed as no further activity has occurred.
It works with docker hosted by OrbStack !!!
@TINKPA Could you elaborate how you got it working with OrbStack? For me, the detected IP address is still of the docker container itself
It works with docker hosted by OrbStack !!!
Yeah, i am curious on that too. i have an Orbstack install and cant get the MDNS stuff moving the way i want.
services:
homebridge:
container_name: homebridge
image: homebridge/homebridge:latest
restart: unless-stopped
network_mode: host
volumes:
- ./homebridge:/homebridge
logging:
driver: json-file
options:
max-size: "10mb"
max-file: "1"
environment:
- TZ=America/Denver
labels:
- "com.centurylinklabs.watchtower.enable=false"
It works with docker hosted by OrbStack !!!
Yeah, i am curious on that too. i have an Orbstack install and cant get the MDNS stuff moving the way i want.
services: homebridge: container_name: homebridge image: homebridge/homebridge:latest restart: unless-stopped network_mode: host volumes: - ./homebridge:/homebridge logging: driver: json-file options: max-size: "10mb" max-file: "1" environment: - TZ=America/Denver labels: - "com.centurylinklabs.watchtower.enable=false"
Doesn’t work for me either.
It won't work, not until https://github.com/orbstack/orbstack/issues/342 is implemented. There are workarounds to retransmit the mDNS announcements though, but I'm not in favour of them.
It won't work, not until orbstack/orbstack#342 is implemented. There are workarounds to retransmit the mDNS announcements though, but I'm not in favour of them.
Yeah, I have been struggling with dns-sd since yesterday, which even if it works is a workaround at best.
I see from the other thread you shared that some other container managers like cheetah already support this. However I don’t think I can move away from the mount point performance of Orbstack.
Let’s see when they implement this.
I can confirm that if you use Colima on Mac, Homebridge works properly out of the gate. Presumably because it is running your containers on a Linux VM. Thought this might be useful knowledge for anyone interested in working with this.
I can confirm that if you use Colima on Mac, Homebridge works properly out of the gate. Presumably because it is running your containers on a Linux VM. Thought this might be useful knowledge for anyone interested in working with this.
Thanks for confirming. I think all container managers on macOS run the containers in a Linux VM. Colima may be doing something different on the network side.
I can confirm that if you use Colima on Mac, Homebridge works properly out of the gate. Presumably because it is running your containers on a Linux VM. Thought this might be useful knowledge for anyone interested in working with this.
Could you be more specific about how you set up Homebridge with Colima? With Docker Desktop I'm seeing what https://github.com/homebridge/docker-homebridge/issues/570#issuecomment-2552047963 mentions — the container has a 'docker0' interface with an IP address of 172.17.0.1, which is not the same as my local network's subnet (and I can't even ping it from the Mac side). I also got "Port Conflict Host Networking: failed to bind port 5353 on the host. Check if it is already in use". Makes sense of course if they're trying to share the same IP address!
This issue should not be closed. Not fixed yet.