I currently have Homebridge installed on a RPi 2 and it is working very well. I’m curious to see what Home Assistant can add to my setup and I’d like to try it out.
Are there any known issues with installing Home Assistant on the same Raspberry Pi as Homebridge? Has anyone done this?
If it helps, I’m running Raspbian 8 (Jessie), Node 4.0.0, NPM 2.14.2, Homebridge 0.4.9
Thanks!
The two things I experienced were, that there should be only one instance of avahi daemon running and that it could be a little tricky to catch the right populated names of components in homebridge.
The first thing was due to my specific installation. I installed home-assistant and homebridge as docker container on an RPi 3 with hypriotos as base system. The hypriotos already delivers an avahi-daemon and the avahi-daemon inside the homebridge container therefor couldn’t start.
The second thing could be managed by customization of specific names for homebridge. Add homebridge_name: to your configuration for devices, sensors etc. you want to rename.
I’m not using Docker, so that’s one less bit of complexity to worry about 
Would I run into the multiple instances of Avahi if I were to use the all-in-one installer method for HA or do I need to go the manual step-by-step route?
I have installed homebridge and home assistant on a RPi 2 and have had no issues. I would suggest installing home assistant in a virtualenv so if you don’t like it, it can easily be removed. The biggest benefit I found with having home assistant with homebridge is it adds more devices compared to homebridge alone. In my case, I have a envisalink for a DSC alarm which interacts with home assistant but not with home bridge by itself. With both installed, homebridge tells my iphone through the home app, when a windows is open, alarm state, hall motion activated etc. as well as add all control devices that home assistant controls.
Thanks! This info is great!
I encountered an issue with port conflicts when using homebridge, home-assistant on the same Pi and LiFX lights. Both servers would try and set up a listener bound to the same port. Work-arounds so far:
netns to put each server in their own network namespace (I couldn’t find a way to select network interface via config in either server).I’m running with the second option right now and it’s working really well.
Hi MrTips, I’ve got the exact same problem that you encountered.
I’m relatively proficient with linux, but not too familiar with netns and network namespaces in general. I’m assuming I would need to create a namespace for each of the servers, somehow bind the servers to the namespace, and then somehow bridge the virtual interface to the physical one?
Would you be able to give some details on how you achieved your solution? or at least point me in the right direction?
Cheers.
I have both home assistant and homebridge running on the same raspberry pi 3. Works well, never had an issue. I installed HA with the all-in-one installer before installing homebridge.
Yeah actually I just put a little time into putting the setup into a script that I could run after the All in One installer to get me going from vanilla image to this setup in two commands.
Currently it has a few things that are specific to my setup but I intend to sanitise it and upload it to github. I’ll do that and let you know.
I couldn’t get a bridged virtual NIC in a network namespace to work correctly down the ethernet port alone so I went with two network connections over wifi and ethernet. I had to change the following:
I specifically only had problems when LiFX lights were configured in both systems. Configuring them in home-assistant only and pointing homebridge at home-assistant worked perfectly.
That would be great, actually, I do have a second NIC (eth1) in the machine I’m using, I may be able to bind it to a namespace for one of the two services.
I have a few homekit scenes for changing the temperature of my LIFX bulbs, so controlling via homebridge-homeassistant is definitely the backup plan (although I guess I could create the temp changing scenes under HASS instead, exposed as switches).
Also, I since noticed the following in the HomeBridge-lifx-lan github:
// LiFx LAN Platform for HomeBridge
//
// Remember to add platform to config.json. Example:
// "platforms": [
// {
// "platform": "LifxLan", // required
// "name": "LiFx LAN", // required
// "duration": 1000, // optional, the time to fade on/off in milliseconds
// ** optional node-lifx parameters **
// "broadcast": '255.255.255.255', // optional: Broadcast address for bulb discovery
// "lightOfflineTolerance": 3, // optional: A light is offline if not seen for the given amount of discoveries
// "messageHandlerTimeout": 45000, // optional: in ms, if not answer in time an error is provided to get methods
// "resendPacketDelay": 150, // optional: delay between packages if light did not receive a packet (for setting methods with callback)
// "resendMaxTimes": 3, // optional: resend packages x times if light did not receive a packet (for setting methods with callback)
// "debug": false, // optional: logs all messages in console if turned on
// "address": '0.0.0.0' // optional: specify which ipv4 address to bind to
// }
// ],
//
specifically: // “address”: ‘0.0.0.0’ // optional: specify which ipv4 address to bind to
I might try plugging in the second NIC tonight, getting a secondary IP and binding the homebridge plugin to the IP and see if that works. Failing that, I’ll try going with the network namespace binding to eth1 route.
Good find! I’ll give that a go on a secondary SD card tonight when i get home and compare notes with you. Should be easy enough to set up a vnic on one network port with two IPs and run it that way if it does bind correctly.
@chrisduran these are the commands in my rc.local that set up the network namespace
ip netns add hass
ip link set eth0 netns hass
ip netns exec hass ifconfig eth0 192.168.0.100/24 up
ip netns exec hass ifconfig lo 127.0.0.1/8 up
ip netns exec hass route add default gw 192.168.0.1
this leaves my wi-fi NIC as the only interface in the default network namespace which is where I start homebridge as usual with added wants and prerequisites.
I chose to put homebridge in the netns (arbitrary decision) so I changed the service user to root and added /sbin/ip netns exec hass sudo -u homeassistant to launch it inside the netns as the homebridge user. (Note the network and rc.local pre-reqs)
/etc/systemd/system/home-assistant.service
[Unit]
Description=Home Assistant
After=network.target rc.local.service
[Service]
Type=simple
User=root
ExecStart=/sbin/ip netns exec hass sudo -u homeassistant /srv/homeassistant/homeassistant_venv/bin/hass -c "/home/homeassistant/.homeassistant"
[Install]
WantedBy=multi-user.target
/etc/systemd/system/homebridge.service
[Unit]
Description=Node.js HomeKit Server
Wants=home-assistant.service
After=syslog.target network-online.target home-assistant.service
[Service]
Type=simple
User=homebridge
EnvironmentFile=/etc/default/homebridge
ExecStart=/usr/bin/homebridge \$HOMEBRIDGE_OPTS
Restart=on-failure
RestartSec=10
KillMode=process
[Install]
WantedBy=multi-user.target
I’ll let you know when i upload my raspberrypi setup script.
cheers
I added the following to my standard homebridge config
{
"platform": "LifxLan",
"name": "LiFx",
"address": "192.168.20.107"
},
and it binds as intended but I still get a port clash if I try and use a virtual NIC with home-assistant running on eth0 192.168.20.106 and homebridge on eth0:1.
This is with both services on one NIC and IP:
Feb 03 00:13:05 raspberrypi homebridge[1181]: LIFX Client UDP error
Feb 03 00:13:05 raspberrypi homebridge[1181]: Trace: { Error: bind EADDRINUSE 0.0.0.0:56700
Feb 03 00:13:05 raspberrypi homebridge[1181]: at Object.exports._errnoException (util.js:1023:11)
Feb 03 00:13:05 raspberrypi homebridge[1181]: at exports._exceptionWithHostPort (util.js:1046:20)
Feb 03 00:13:05 raspberrypi homebridge[1181]: at dgram.js:218:18
Feb 03 00:13:05 raspberrypi homebridge[1181]: at _combinedTickCallback (internal/process/next_tick.js:77:11)
Feb 03 00:13:05 raspberrypi homebridge[1181]: at process._tickCallback (internal/process/next_tick.js:98:9)
Feb 03 00:13:05 raspberrypi homebridge[1181]: at Module.runMain (module.js:607:11)
Feb 03 00:13:05 raspberrypi homebridge[1181]: at run (bootstrap_node.js:418:7)
Feb 03 00:13:05 raspberrypi homebridge[1181]: at startup (bootstrap_node.js:139:9)
Feb 03 00:13:05 raspberrypi homebridge[1181]: at bootstrap_node.js:533:3
Feb 03 00:13:05 raspberrypi homebridge[1181]: code: 'EADDRINUSE',
Feb 03 00:13:05 raspberrypi homebridge[1181]: errno: 'EADDRINUSE',
Feb 03 00:13:05 raspberrypi homebridge[1181]: syscall: 'bind',
Feb 03 00:13:05 raspberrypi homebridge[1181]: address: '0.0.0.0',
Feb 03 00:13:05 raspberrypi homebridge[1181]: port: 56700 }
Feb 03 00:13:05 raspberrypi homebridge[1181]: at Client.<anonymous> (/usr/lib/node_modules/homebridge-lifx-lan/node_modules/node-lifx/lib/lifx/client.js:147:13)
Feb 03 00:13:05 raspberrypi homebridge[1181]: at emitOne (events.js:96:13)
Feb 03 00:13:05 raspberrypi homebridge[1181]: at Socket.emit (events.js:189:7)
Feb 03 00:13:05 raspberrypi homebridge[1181]: at dgram.js:219:14
Feb 03 00:13:05 raspberrypi homebridge[1181]: at _combinedTickCallback (internal/process/next_tick.js:77:11)
Feb 03 00:13:05 raspberrypi homebridge[1181]: at process._tickCallback (internal/process/next_tick.js:98:9)
Feb 03 00:13:05 raspberrypi homebridge[1181]: at Module.runMain (module.js:607:11)
Feb 03 00:13:05 raspberrypi homebridge[1181]: at run (bootstrap_node.js:418:7)
Feb 03 00:13:05 raspberrypi homebridge[1181]: at startup (bootstrap_node.js:139:9)
Feb 03 00:13:05 raspberrypi homebridge[1181]: at bootstrap_node.js:533:3
This is with a virtual NIC on eth0 and node-lifx bound to a the virtual IP:
Feb 03 00:19:07 raspberrypi homebridge[1494]: LIFX Client UDP error
Feb 03 00:19:07 raspberrypi homebridge[1494]: Trace: { Error: bind EADDRINUSE 192.168.20.107:56700
Feb 03 00:19:07 raspberrypi homebridge[1494]: at Object.exports._errnoException (util.js:1023:11)
Feb 03 00:19:07 raspberrypi homebridge[1494]: at exports._exceptionWithHostPort (util.js:1046:20)
Feb 03 00:19:07 raspberrypi homebridge[1494]: at dgram.js:218:18
Feb 03 00:19:07 raspberrypi homebridge[1494]: at _combinedTickCallback (internal/process/next_tick.js:77:11)
Feb 03 00:19:07 raspberrypi homebridge[1494]: at process._tickCallback (internal/process/next_tick.js:98:9)
Feb 03 00:19:07 raspberrypi homebridge[1494]: at Module.runMain (module.js:607:11)
Feb 03 00:19:07 raspberrypi homebridge[1494]: at run (bootstrap_node.js:418:7)
Feb 03 00:19:07 raspberrypi homebridge[1494]: at startup (bootstrap_node.js:139:9)
Feb 03 00:19:07 raspberrypi homebridge[1494]: at bootstrap_node.js:533:3
Feb 03 00:19:07 raspberrypi homebridge[1494]: code: 'EADDRINUSE',
Feb 03 00:19:07 raspberrypi homebridge[1494]: errno: 'EADDRINUSE',
Feb 03 00:19:07 raspberrypi homebridge[1494]: syscall: 'bind',
Feb 03 00:19:07 raspberrypi homebridge[1494]: address: '192.168.20.107',
Feb 03 00:19:07 raspberrypi homebridge[1494]: port: 56700 }
Feb 03 00:19:07 raspberrypi homebridge[1494]: at Client.<anonymous> (/usr/lib/node_modules/homebridge-lifx-lan/node_modules/node-lifx/lib/lifx/client.js:147:13)
Feb 03 00:19:07 raspberrypi homebridge[1494]: at emitOne (events.js:96:13)
Feb 03 00:19:07 raspberrypi homebridge[1494]: at Socket.emit (events.js:189:7)
Feb 03 00:19:07 raspberrypi homebridge[1494]: at dgram.js:219:14
Feb 03 00:19:07 raspberrypi homebridge[1494]: at _combinedTickCallback (internal/process/next_tick.js:77:11)
Feb 03 00:19:07 raspberrypi homebridge[1494]: at process._tickCallback (internal/process/next_tick.js:98:9)
Feb 03 00:19:07 raspberrypi homebridge[1494]: at Module.runMain (module.js:607:11)
Feb 03 00:19:07 raspberrypi homebridge[1494]: at run (bootstrap_node.js:418:7)
Feb 03 00:19:07 raspberrypi homebridge[1494]: at startup (bootstrap_node.js:139:9)
Feb 03 00:19:07 raspberrypi homebridge[1494]: at bootstrap_node.js:533:3
If however I use two distinct physical interfaces then the bind works correctly and there is no port clash. This is somewhat of a win as it reduces complexity significantly over netns, so I’m going to test further.
Thanks for sharing your config, I’ve made a bit of progress here too. I’ve currently got both successfully binding to two IPs on a single NIC.
I’ve got the NIC getting the IP address 10.0.1.100 by DHCP reservation. I’ve also got a reserved region for static IPs from 10.0.1.231-10.0.1.254, so I assigned a secondary/alias IP manually from that range.
I then bound homeassistant’s lifx component to the primary IP, and homebridge-lifx-lan to the secondary (see below configuration extracts). It seems to have worked. I can now start both homebridge and homeassistant without errors, and I can control the light from both homekit and home assistant.
One thing I noticed is that at times the ios app (apple home) and web app (home assistant) can take a while to update the status of the light should it be controlled from the other app. This seems especially to be the case if controlling the app from home assistant. Usually reopening the app/refreshing the page does the trick.
My theory is that this is probably due to the routing configuration with the two IPs (I’ve not changed the routing at all), with the broadcast update from the lights not being picked up . This would be consistent with the fact that a refresh/app reload will update the lights due to a probable polling of the light when the device control is loaded and synchronised.
It probably isn’t too big a problem, as issuing a command or interacting with a widget seems to get the light into sync in short order, and I only plan on using homekit for voice control, so I don’t actually care too much that the status isn’t updating in the app immediately.
I might try creating a namespace and binding my second NIC to it this weekend to see if that changes the behaviour, or if this is more a standard sync delay that the LIFX bulbs have.
My config as follows:
/etc/network/interfaces
auto eno1
iface eno1 inet dhcp
iface eno1 inet static
address 10.0.1.240/24
homeassistant:
configuration.yaml
light:
- platform: lifx
broadcast: 10.0.1.255
server: 10.0.1.100
homebridge:
config.json
"platforms": [ {
"platform" : "LifxLan",
"name" : "LiFx",
"address" : "10.0.1.240" },
Ah cheers @chrisduran I missed the IP bind in the homeassistant config!
I’ll give that another go when I get home.
Is that network config correct, what’s the name of the virtual interface?
thanks
Matt
It confused me too, I was used to the eth0:0 style notation.
My understanding is that it is the newer ‘iproute2’ style syntax, as per https://askubuntu.com/questions/547289/how-can-i-from-cli-assign-multiple-ip-addresses-to-one-interface/547300
Here is an extract from the output of ip addr list
3: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 40:8d:5c:xx:xx:xx brd ff:ff:ff:ff:ff:ff
inet 10.0.1.100/24 brd 10.0.1.255 scope global eno1
valid_lft forever preferred_lft forever
inet 10.0.1.240/24 brd 10.0.1.255 scope global secondary eno1
valid_lft forever preferred_lft forever
the downside is that the secondary addr doesn’t show in ifconfig
Ah ok thanks, i’ll give it a bash. What distro are you on?
Ubuntu 16.04.1 LTS, I’m running this on a x86-64 host.
Also I see very latent updates with LiFX lights too, even when running the servers stand alone or with network namespaces.