homebridge/ciao

Register with a sleep proxy to wake homebridge during MacOS sleep

honeywelluser opened this issue · 6 comments

honeywelluser commented

Describe Your Problem:
Forgive the blue sky noob question. I have homebridge working well on MacOS. Obviously the service is unavailable during MacOS sleep (and I could/should commission a Rpi).

However, as confirmed by _dns-sd -B _sleep-proxy.udp local I have available sleep proxies on the LAN (HomePod, Airport, AppleTV etc). Other services successfully wake MacOS as necessary. Wouldn’t it be cool if MacOS woke when I used HomeKit?

I considered registering the homebridge service with the proxy (dns-sd -R...) but I don’t know the requisite port/service details. I poked around Node.js and homebridge forums and searches but got nobody trying/succeeding to do this.

  • Am I asking the impossible?
  • Anyone considered this?
  • It seems naively straightforward for homebridge to register itself (or I register it) with a sleep proxy...

Best wishes all!

Logs:
n/a

Homebridge Config:
All standard, just a couple of plugins:
homebridge-evohome v0.7.3
homebridge-away-mode v1.5.2

Environment:

  • Node.js Version: v14.15.3
  • NPM Version: 6.14.9
  • Homebridge Version: 1.1.7
  • Operating System: MacOS V11.1 (20C69)
  • Process Supervisor: Systemd / init.d / pm2 / launchctl / Docker / hb-service / other / none
Supereg commented

As homebridge is not using the mDNS Responder of the system (like mDNSResponder on macOS) but ships its own mDNS Responder implementation, we indeed do not support this feature (yet).
The current release versions of homebridge use the bonjour-hap library to do mDNS service discovery. With 1.2.x. we moved to a newly written replacement for the library: ciao. However this release didn't went that well and was since pulled.

With the upcoming 1.3.0 (see homebridge/homebridge#2765) version we add the ciao library as a configuration option, but ship with bonjour-hap as default for now, until we can be sure that ciao is stable enough.

I got some plans where instead of advertising our own address records, we just redirect to the ones advertised by the system itself (e.g. by the mDNSResponder). This would automatically enable sleep proxy support without the need to reimplement the whole thing (and supporting sleep proxy isn't that simple, as we are dealing with node and can't really interface directly with the operating system kernel).

Such compatibility as you request is planned. There is no time schedule for this. If we ship it, it will be definitely only available with the ciao library.

EDIT: As stated, this addresses the ciao library, thus I moved the issue to that repo.

  • 👍1
honeywelluser commented

I appreciate your reply.

Whilst awaiting a ciao nirvana, is there a dirty OS hack to manually register homebridge with the sleep proxy:
  dns-sd -R name type domain port [key=value ...]

Supereg commented

I think there is no way to create a hack as described from the outside. You would need to alter the records advertised by ciao, and the conflict detection would prevent this.
However maybe we can get a somewhat hacky option into ciao/homebrige to specify a hostname override, until we have such a described automatic detection. This will fail if the host should change its hostname (or rather the hostname advertised over mDNS), but should work most of the time.

  • 👍1
adriancable commented

@Supereg - way back in the sands of time (HAP-NodeJS 0.4.41 and earlier, to be exact) the 'mdns' package was used, which used the native mDNS stack (Avahi/mDNSResponder etc.) Then, in 0.4.42, this was replaced with the 'bonjour' npm package, which shortly thereafter was forked to 'bonjour-hap'. And the rest (along with, as it appears, pain for some people) is history.

Do you know why the 'mdns' package stopped being used? Since the native libraries (Avahi/mDNSResponder) are likely extremely reliable, it kind of seems 'obvious' we should just use that. And yet, presumably there was a good reason to instead ditch the native stuff, and re-implement in the 'bonjour' npm library, which started the painful journey of mdns->bonjour->bonjour-hap->ciao and now ciao->bonjour-hap again. Do you know the reason?

Thanks!

  • 😄1
Supereg commented

@adriancable sorry for the long turnaround time.

As it is really only a native binding for Apples mDNSResponder or avahi on linux systems, it pretty much was a hell for users to install. Especially back in the days for Windows, requiring the Apple Bonjour SDK to be installed (and some visual studio stuff, according to the mdns readme).
Additionally we have cases, where users are seemingly not running e.g. avahi at all. Support for windows 10 native responder is seemingly also lacking.

But you are right, using the systems native responder, is the best choice in terms of efficiency (and feature compatibility with stuff like sleep proxies).
Thus we are currently considering options where we can ship prebuilt binaries for the mdns package, and use ciao or bonjour-hap as a backup in the other cases.

meghrathod commented

Any progress on this issue?