Looking for advice running homebridge on a Raspberry Pi
I’ve been curious about homebridge for quite some time and have been considering picking up a Raspberry Pi to run it. I’m interested to know about others experiences with it, and what sort of difficulties I might expect to troubleshoot in the future.
I had it running on a Pi3 using the official homebridge image without any problems related to the Pi itself. Usually when there is a problem it’s because of a homebridge plugin or a config error.
I recommend assigning a fixed IP for the Pi‘s MAC address in your router.
You will also want to update Node.js regularly, which can be done with the hb-service CLI tool that comes preinstalled if you used the image. Therefore basic knowledge of using the console is required. If I remember correctly the console can be accessed in the Homebridge UI.
Better than assigning a static IP on the system/router is probably to create a DHCP reservation instead, that way you can never run into an issue where 2 machines end up with the same IP, and you don't have to mess around with the assignment pool scope.
This might be what you meant, but just to clarify for those who might not know.
Gotcha. DHCP is a pretty good start if you want to learn more about networking.
DHCP (Dynamic Host Control Protocol) is a pretty straightforward networking protocol which is responsible for giving machines on a network their IP addresses so that those machines can route their traffic to and from other networks.
On home networks, usually your router is acting as the DHCP server, but it could also be served from something like a regular computer.
The actual conversation between machines in the protocol is called DORA - Discover, Offer, Request, Acknowledge. The DHCP server (router for example) is always listening for a machine to send out a broadcast over the network asking "Discover". When the server sees this, it sends an IP address it knows is available to that machine saying "Offer". The machine looking to get the IP will usually then accept that IP saying "Request", and finally the server replies back one more time to tell the machine it heard what it said with "Acknowledge". At this point, the server marks that IP as in-use on the network, and the machine can begin using the IP to network.
When the machine gets the IP, it also gets a lease time after which the IP expires and the machine has to ask the server for a new one.
The server keeps track of available IP addresses that are not assigned to other machines, but any network has a limited number of IP addresses it can hand out. This delves out into a subject called subnetting, but just know that on most home networks, there are usually 253 IP addresses that can be leased. It would be 256, but on your average home network, 192.168.1.0 refers to the network itself, 192.168.1.255 is the address machines send to if they want to broadcast to all machines, and your router or DHCP server will be taking up one, and it usually sits at 192.168.1.254.
Now, before DHCP existed, you would just manually set an IP address yourself on each machine, but of course if you have 253 devices or something, its hard to manage and track, hence why DHCP is a necessity, but computers still let you manually set an unchanging (static) IP address, where an IP that changes (because it occasionally gets a new one from DHCP) is dynamic.
As a result, you can run into problems if you have a static IP on a machine that exists on a network running DHCP because the DHCP server does not necessarily know what static IP that machine has. It is possible that the DHCP server will hand out that same IP to another machine, and the result of this is that the 2 machines that ended up with the same IP both get knocked offline because traffic no longer routes correctly.
So what about servers and stuff where you really want the same IP on a machine all the time, but also want the benefits of DHCP?
There are a couple solutions to this, one of which is to shorten the IP scope DHCP can use so that it never leases a few addresses, and then you can use them as static IP addresses.
The more modern solution is a DHCP reservation which is where you give a machines hardware (MAC) address to the DHCP server along with an IP. That way, any time a machine sends out a "Discover", the DHCP server can check if its MAC address is in its reservation list. If it is, it gives it the IP listed there every time, if not, it just gives it some other IP from the pool. The Server will never hand out the IP's listed in the reservations list to any machine unless it is the matching machine, and you never have to deal with setting static IP's manually on your machines.
Thanks for the reply. I read it over a couple of times, and I think I get it, but a lot of it is going over my head without doing this hands on myself.
I’ll save your comment and report back once I’m able to work on this.
No worries, know that the best way to learn in my opinion is from the OSI model. It breaks networking into 7 layers so that its easier to understand how stuff works and where it is. If you pursue it, learn starting at layer 1 (the physical layer), and then upwards from there.