This library connects to every _hap service, not just homebridges

[lilyball]

This plugin attempts to connect to every single discovered _hap service regardless of what it is, in search of homebridges. Looking at my local services right now, it appears that homebridge sets md=homebridge for every bridge it advertises, so I would expect this plugin should only connect to those. If there is a need to connect to a different HAP-NodeJS server that is not homebridge, this should be supported through an option to set a different md parameter to filter on.

If filteirng on md is a problem, then at the very least this should filter on ci=2, as that signals that this device is a bridge. Again, perhaps there should be an escape hatch for specifying other ci options to handle the scenario where someone uses HAP-NodeJS to advertise an individual accessory and someone wants to connect to it. But since this primarily appears to be for talking to homebridge, it should default to searching for things that look like homebridge instead of connecting to everything.

The reason for filing this issue right now is a bug that causes zombie _hap._tcp. services (NRCHKB/node-red-contrib-homekit-bridged#477), and my logs are as a result filled every 15 minutes with a bunch of spam that looks like

Feb 28 12:28:49 raspberrypi Node-RED[1997]: 2022-02-28T20:28:49.098Z hapNodeJSClient HAP Discover failed 1.4.3 -> http://172.19.0.1:40229 error Error: connect ECONNREFUSED 172.19.0.1:40229
Feb 28 12:28:49 raspberrypi Node-RED[1997]:     at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1159:16) {
Feb 28 12:28:49 raspberrypi Node-RED[1997]:   errno: -111,
Feb 28 12:28:49 raspberrypi Node-RED[1997]:   code: 'ECONNREFUSED',
Feb 28 12:28:49 raspberrypi Node-RED[1997]:   syscall: 'connect',
Feb 28 12:28:49 raspberrypi Node-RED[1997]:   address: '172.19.0.1',
Feb 28 12:28:49 raspberrypi Node-RED[1997]:   port: 40229,
Feb 28 12:28:49 raspberrypi Node-RED[1997]:   attempts: 5
Feb 28 12:28:49 raspberrypi Node-RED[1997]: }

Also lsof -i shows that I have a lot of active connections to the same HomeKit accessory. This HomeKit accessory is somewhat buggy (and is using port 80 as its HAP server for some reason), and its PIN is definitely not the PIN I'm searching for, but something is keeping the connections alive. I don't know if this library is simply expecting the remote service to hang up when pairing fails, or if something else is going on, but at this moment I have 135 active connections to it, and that seems consistent with the idea that I'm getting yet another established connection on every refresh (which is 15 minutes). The accessory is using protocol version 1.0 but I'm not sure what that actually changes (besides the lack of a sh parameter, whose meaning is redacted from the current Non-Commercial HAP Specification).

In any case, if this library filtered either on md=homebridge or ci=2 then it wouldn't even attempt to connect to this accessory. Though obviously it should also figure out and fix whatever is causing the connection to persist despite the incorrect PIN.

[NorthernMan54]

The ability to use the library with any hap-nodejs implementation is a feature and not an issue. I use it with my HomeKit-bridged devices, to expose them to Alexa.

For you issue with HomeKit-bridged, have you tried setting the bridge port in the config settings for HomeKit-bridged? It should reduce the number of zombie mdns records.

For the PIN code issue, on my rainy day list is to add a PIN check as part of the discovery phase, to prevent this issue.

For the stuck connection issue, the code is doing a simple request to retrieve a list of accessories from the device, and if it’s a true native HomeKit device, the call should immediately fail, as I’m not using a native HomeKit secure connection. The code is here

Hap-Node-Client/HAPNodeJSClient.js

Line 716 in c61d716

request({

[lilyball]

The ability to use the library with any hap-nodejs implementation is a feature and not an issue. I use it with my HomeKit-bridged devices, to expose them to Alexa.

At the very least the API should offer a way to filter based on md and/or ci (and strongly encourage the use of this) so it's not connecting to every device.

For you issue with HomeKit-bridged, have you tried setting the bridge port in the config settings for HomeKit-bridged? It should reduce the number of zombie mdns records.

I haven't tried that. I did however restart the entire nodered service and the problem has stopped happening, at least for now. I'm somewhat mystified, but since the bug occurred before, I'm guessing it will happen again. In any case, my one worry with hardcoding the port is whether that will actually stop zombie services, or whether it will just advertise multiple services with the same port.

if it’s a true native HomeKit device, the call should immediately fail, as I’m not using a native HomeKit secure connection.

It is ia true native HomeKit device, but it's been awfully flaky and the HomeKit implementation is terrible (it's missing most functionality from the HomeKit accessory).

Looking at the code, I just tried sending my own request and what I get back is "HTTP/1.1 470 Connection Authorization Required\r\n\r\n", at which point it just hangs (even if I specify Connection: close). I think this library just doesn't ever do anything to shut down that connection.

[NorthernMan54]

@lilyball I was recently working thru removing the dependency on the request package ( long since deprecated ) and replacing it with Axios and making a couple of other improvements, including better detection of native HomeKit devices and devices with an incorrect PIN and saw this during testing. That is from my Wyze cam using the Homebridge-camera-ffmpeg plugin. Your thought about filtering based on MD or CI would break the support of this device.

{
  ipAddress: '192.168.1.13',
  instance: {
    name: 'Porch Camera FB13',
    host: '192.168.1.13',
    port: 38759,
    url: 'http://192.168.1.13:38759',
    deviceID: '74:C4:D5:32:62:EC',
    txt: {
      'c#': '2',
      ff: '0',
      id: '74:C4:D5:32:62:EC',
      md: 'Wyze Cam V2',
      pv: '1.1',
      's#': '1',
      sf: '0',
      ci: '17',
      sh: '/l9qew=='
    }
  },
  accessories: { accessories: [ [Object] ] },
  deviceID: '74:C4:D5:32:62:EC',
  name: 'Wyze Cam V2'
}

If you have a free moment, and you can recreate the original issue with the timeout errors from that flaky HomeKit device, could you try out the current beta of Homebridge-automation ? It uses axios instead of request and I want to see if the behaviour is improved.

npm install node-red-contrib-homebridge-automation@beta