Before moving to 24.10 about 2 months ago homebridge was working on bluefin with the docker create app button in the ui. I figured once I moved over that I wouldn’t have an issue getting it working again. I can get the app up and running with no problem with my old back up and with a new setup, however I can’t get anything to add to HomeKit. I think it has to do with networking since it’s only picking up the 172.x.x.x network. Has anyone run into this and have a solution. I was thinking that creating a bridge might help, but every time I go to create one it never actually creates it. Thanks for any and all advice in advance!
Edit: I forgot to add that I have used the Dockge app, the truenas IX app in the discover apps section, and the custom app all with the same result.
It sounds like there may not be a lot of folks running homebridge on EE yet, but I just ran into this same problem. The main issue stems from homebridge needing to run on the host network since macvlan or static ip’s aren’t available yet for the docker stack on EE. I could get the UI to run if I didn’t use host network, but then none of the devices in home bridge would show up or would show as not responding in the home app. It looks like 5353 mdns isn’t forwarding through for network discovery without using a static IP or using the host. The issue with making homebridge run on the host network is a conflict for mDNS for truenas itself. Truenas uses mdns to broadcast in finder and explorer as a network device. if you go to network and then settings in truenas, you can turn off mdns and then run homebridge on the host network until static IP’s or macvlan is enabled in a future update to Truenas Scale. I know its not optimal and is a workaround, but it worked for me and at least allows me to control my iot devices in the home app now which is more valuable than truenas using mdns.
If you tried a custom app, then you can do anything, including, using your own different IP. You can use cli to make networks too. Just depends how comfortable you are.
I tried that using a compose.yaml file and putting it as a custom app, tried it in portainer and tried it using dockge and couldn’t get it to bind fully. Have you tried doing it with RC2? A little about my network config on the truenas box: I only have 1 ethernet connected, set up as a bridge network with a static ip. I’m not able to get any inbound traffic to work on custom networks with any of the above mentioned solutions. Any other thoughts?
It’s just docker stuff, same as any other docker system. I did have one app that was using it on Eel with a bridge, yes, but then I went another way and I don’t have the old compose file. I switched desktops in the meantime and just don’t have it sadly.
So, the only thing I can tell you is, with compose, you can do it. Doubtful you can with the ix app to create custom apps, you’ll need your own compose file.
So I tried the custom app and I tried compose with dockge and here is my yaml file below. I want it to be on 192.168.1.251:8581. The crazy thing is whenever I do set it to the static ip I can get the container to start but I can’t get the ui to come up on that ip:port. Also when I do set it this way it makes my network go crazy forcing my unifi router to reset. I made sure that it’s an unused ip address and everything.
Well I use Time Machine for backing up all of our devices and mdns is required for that. So turning that off would be a no-go for us. Wife runs her business with a couple of them and need to have her backups as up to date as possible.
The Yaml file looks very similar to what I was trying to make work. I eventually did get it to respond/connect with a static ip and do some nslookups and pings in the terminal for the container using a custom macvlan network instead of bridging, but was unable to access the UI or ping the container from any outside sources. The only way I’ve been able to make it work was to attach it to the host and then disable mDNS on the TrueNAS itself.
Fingers crossed someone else comes up with a solution before having to wait for IX Systems to make the UI able to configure bridge and macvlan networks. Unfortunately Homebridge and several other containers that require host or static ip’s won’t work fully until this is an option.
Dang! So much for all of your current apps will work with the new version! I just don’t see why it worked perfectly fine with docker on dragonfish with jailmaker AND with the custom app where it pulled the docker image.
As I said I don’t remember and I don’t have a reason to try it again. I’m curious about a few things without spending time to create one, why is your subnet setting 192.168.0.0/16? Seems wrong. And the network you created, did you attach it to br0 or eth#? I believe it had to be on the bridge (br0). Did you add the custom IP as an alias to the bridge?
This is what I have it to now but still can’t get the UI to come up. Keeps saying npm error request to https://registry.npmjs.org/homebridge failed, reason: getaddrinfo EAI_AGAIN registry.npmjs.org. In the logs it shows the 192.168.1.135 as net0 and joining the mDNS on that same ip.
EDIT: it’s net0 not eth0. The 172.xxx.xxx.xxx address shows as eth0.
I upgraded to EE yesterday. Other Apps are easy to deploy where only a few changes are needed. But I can’t get HomeBridge to run.
Like you said, HomeBridge requires connection to the home network.
If you choose host network, port forwarding cannot be configured. And default Web UI on port 8581 won’t open.
I tried to not choose host network and map 8581 to another port (in my case 10081) then I can access Web UI.
In this situation, HomeBridge has access to Internet and Plugins can be upgraded normally. But the Settings of HomeBridge shows that the App only listens to 172.X.X.X interface, which makes it impossible to connect to IOT devices in the home network. Mapping HomeBridge service port 51354 to host network doesn’t help either.
I think this issue is related to the new way of configuring Apps that comes with Electric Eel because users cannot choose network interface for the App anymore. As a result, HomeBridge either fails to listen to the correct interface or there is no access to Web UI.