homebridge/bonjour

A Bonjour/Zeroconf protocol implementation in JavaScript

Homebridge

Homebridge is a lightweight Node.js server you can run on your home network that emulates the iOS HomeKit API. It supports Plugins, which are community-contributed modules that provide a basic bridge from HomeKit to various 3rd-party APIs provided by manufacturers of "smart home" devices.

Since Siri supports devices added through HomeKit, this means that with Homebridge you can ask Siri to control devices that don't have any support for HomeKit at all. For instance, using just some of the available plugins, you can say:

• Siri, unlock the back door. [pictured to the right]
• Siri, open the garage door.
• Siri, turn on the coffee maker.
• Siri, turn on the living room lights.
• Siri, good morning!

You can explore all available plugins at the NPM website by searching for the keyword homebridge-plugin.

Community

The official Homebridge Discord server and Reddit community are where users can discuss Homebridge and ask for help.

HomeKit communities can also be found on both Discord and Reddit.

Installation

Raspberry Pi

Official Homebridge Raspberry Pi Image
Install Homebridge on Raspbian

---

Linux

Debian or Ubuntu Linux | Red Hat, CentOS or Fedora Linux | Arch / Manjaro Linux|Install Homebridge on Arch Linux

---

macOS

Install Homebridge on macOS

---

Windows 10 / 11

Install Homebridge on Windows 10 / 11 Using Hyper V

---

Docker

Install Homebridge on Docker
Synology | Unraid | QNAP | TrueNAS Scale

---

Synology DSM

Install Homebridge on Synology DSM 7

Other Platforms

Other Platforms

Adding Homebridge to iOS

1. Open the Home app on your device.
2. Tap the Home tab, then tap .
3. Tap Add Accessory, then scan the QR code shown in the Homebridge UI or your Homebridge logs.

If the bridge does not have any accessories yet, you may receive a message saying Additional Set-up Required, this is ok, as you add plugins they will show up in the Home app without the need to pair again (except for Cameras and TVs).

Cameras and most TV devices are exposed as separate accessories and each needs to be paired separately. See this wiki article for instructions.

Interacting with your Devices

Once your device has been added to HomeKit, you should be able to tell Siri to control your devices. However, realize that Siri is a cloud service, and iOS may need some time to synchronize your device information with iCloud.

One final thing to remember is that Siri will almost always prefer its default phrase handling over HomeKit devices. For instance, if you name your Sonos device "Radio" and try saying "Siri, turn on the Radio" then Siri will probably start playing an iTunes Radio station on your phone. Even if you name it "Sonos" and say "Siri, turn on the Sonos", Siri will probably just launch the Sonos app instead. This is why, for instance, the suggested name for the Sonos accessory is "Speakers".

Plugin Development

The https://developers.homebridge.io website contains the Homebridge API reference, available service and characteristic types, and plugin examples.

The Homebridge Plugin Template project provides a base you can use to create your own platform plugin.

There are many existing plugins you can study; you might start with the Homebridge Example Plugins or a plugin that already implements the device type you need.

When writing your plugin, you'll want Homebridge to load it from your development directory instead of publishing it to npm each time. Run this command inside your plugin project folder so your global installation of Homebridge can discover it:

npm link

You can undo this using the npm unlink command.

Then start Homebridge in debug mode:

homebridge -D

This will start up Homebridge and load your in-development plugin. Note that you can also direct Homebridge to load your configuration from somewhere besides the default ~/.homebridge, for example:

homebridge -D -U ~/.homebridge-dev

This is very useful when you are already using your development machine to host a "real" Homebridge instance (with all your accessories) that you don't want to disturb.

Common Issues

Home App Says Accessory Already Added

To fix this, Reset Homebridge.

My iOS App Can't Find Homebridge

Try the following:

1. Swap between the Bonjour HAP and Ciao mDNS Advertiser options. See the wiki for more details.
2. iOS DNS cache has gone stale or gotten misconfigured. To fix this, turn airplane mode on and back off to flush the DNS cache.

Limitations

• One bridge can only expose 150 accessories due to a HomeKit limit. You can however run your plugins as a Child Bridge or run Multiple Homebridge Instances to get around this limitation.
• Once an accessory has been added to the Home app, changing its name via Homebridge won't be automatically reflected in iOS. You must change it via the Home app as well.

Why Homebridge?

Technically, the device manufacturers should be the ones implementing the HomeKit API. And I'm sure they will - eventually. When they do, this project will be obsolete, and I hope that happens soon. In the meantime, Homebridge is a fun way to get a taste of the future, for those who just can't bear to wait until "real" HomeKit devices are on the market.

Credit

Homebridge was originally created by Nick Farina.

The original HomeKit API work was done by Khaos Tian in his HAP-NodeJS project.

bonjour's Issues

Homebridge 1.4.0, service browser and avahi advertiser

Analysis

With Homebridge 1.4.0 and the avahi advertiser I found that my homebridge-alexa and Homebridge-automation plugins stopped being able to discover all the homebridge instances on the local network. Under the covers in both I'm using the mDNS/Bonjour browser capability of bonjour-hap to discover the _hap services.

After a lot of debugging into the issue, and sniffing of network traffic have found the trigger for issue and want to discuss solutions.

For a trigger I found that when you have alot of homebridge instances on a single host, in my case 15 + instances, the response packet from the mdns query spans multiple packets and the second packets browser response data is not including the ip addresses. The browser callback is called for each service, but the service data returned is missing the ip address details from any services in the second packet.

When I look with Wireshark, I see packets being returned, the first 1453 bytes and the second 920.

Looking at the query response packets in detail, I can see a single type 'A' record in the first packet and none in the second. Am thinking that possible some service address caching is needed.

This function does not take into account query responses that span multiple packets.

bonjour/lib/Browser.js

Line 187 in eaca22a

records

I was able to code a quick hacky workaround, and it did mitigate the issue, but this will take more research into what the RFC says in regards to responses spanning multiple packets.

        if(service.addresses.length) {
          console.log("Adding to cache", service.host, service.addresses);
          _addressCache[service.host] = service.addresses;
        } else if (_addressCache[service.host]) {
          console.log("Using cache", service.host, _addressCache[service.host]);
          service.addresses = _addressCache[service.host];
        }

@oznu If your using my hap-node-client you will have the same issue.

Expected Behavior

See above

Steps To Reproduce

See above

Logs

See above

Configuration

See above

Environment

• OS:
• Software:
• Node:
• npm:

Process Supervisor

systemd

Additional Context

No response

Bump multicast-dns dependency

multicast-dns v7.2.3 upgrades the dns-packet dependency to resolve this concern

Address records should not be cached

This library appears to cache address records for announced services. The problem is if my computer’s available addresses change, the cache is now wrong. So either it shouldn’t be caching the records at all, or it should detect when the network interfaces change and invalidate all cached records.

I noticed this because I turned off wifi on my raspberry pi but the _hap._tcp. services continued to resolve to both the wifi and ethernet IP addresses.

I can’t prove this experimentally right now because my local device would have cached the data (and this library doesn’t send goodbye packets), and I restarted Homebridge already, but skimming through the code suggests that what I’ve written is correct. It looks like the only thing that will update the address records (beyond destroying and creating the Service) is calling updateTxt() as that throws away the cached packet.

Fix MDNS Announcements

To be compliant, the A and AAAA records (of the target of an announcement) should be published das "additional" records, not as answers

Does not respond to _services._dns-sd._udp.

RFC 6763 §9 defines a special meta-query _services._dns-sd._udp.<Domain> that yields a set of PTR records that identify all service types available on the local network. This is used for network administration tools, as well as some developer tools like Discovery.

Unfortunately, it seems as though this library doesn't support this meta-service. As a result, if homebridge is the only software advertising _hap._tcp. on the local network (or if the other advertisers are similarly bugged, like Philips Hue is), then tools using _services._dns-sd._udp. to find service types won't be able to detect the presence of _hap._tcp.

I consider this a bug. This library should learn to handle that meta-service correctly.

Also be sure to keep in mind RFC 6762 §7 which documents known-answer suppression. Ideally it would also implement §7.4 (duplicate answer suppression), as this is a shared record and other hosts may already declare that _hap._tcp. is on the network (also see §6 which documents response delay). Hopefully this is already implemented in the lower-level multicast-dns library though, as this is a feature of multicast DNS, not of Bonjour specifically.

ipv6 and addresses published under mDNS

Analysis

I was investigating some issues with ipv6 support with my plugins and noticed this behaviour when looking into connectivity issues. When running under MacOS, and using the bonjour-hap advertiser I saw multiple ipv6 address advertised for my homebridge instance.

Looking at ifconfig on my Mac, I see the multiple ipv6 interfaces and ipv6 address, but majority are marked inactive with the primary interface being fe80::cf2:38da:84b:10b3%en0

Here is the same when using the ciao advertiser

@Supereg Are you seeing something similar in your environments ? I'm wondering if these inactive ipv6 address under bonjour-hap could be potential issues with the recent updates ? Should be recommending not to use bonjour-hap under ipv6 environments ?

Expected Behavior

not sure

Steps To Reproduce

Use the advertiser bonjour-hap

Logs

none

Configuration

none

Environment

• OS: MacOS 12.6.2
• Software: Homebridge homebridge v1.6.0-beta.4
• Node: node v18.12.0
• npm:

Process Supervisor

hb-service

Additional Context

No response

Does not send goodbye packets

When a service is unregistered (or the whole server undergoes clean shutdown), it should be sending a goodbye packet for any service it's previously announced to the world (see RFC 6762 §10.1). I don't see any evidence of this in the source.

The purpose of this is to allow other hosts that have cached the existence of services being broadcast by this server to learn that the service is no longer available.