homebridge-harmonyhub
homebridge-harmonyhub copied to clipboard
KraigM
Unhandled Error Event 0.2.0 alpha
pi@raspberrypi:~ $ homebridge *** WARNING *** The program 'node' uses the Apple Bonjour compatibility layer of Avahi. *** WARNING *** Please fix your application to use the native API of Avahi! *** WARNING *** For more information see http://0pointer.de/avahi-compat?s=libdns_sd&e=node *** WARNING *** The program 'node' called 'DNSServiceRegister()' which is not supported (or only supported partially) in the Apple Bonjour compatibility layer of Avahi. *** WARNING *** Please fix your application to use the native API of Avahi! *** WARNING *** For more information see http://0pointer.de/avahi-compat?s=libdns_sd&e=node&f=DNSServiceRegister [8/7/2016, 9:08:39 PM] Loaded plugin: homebridge-harmonyhub [8/7/2016, 9:08:41 PM] Registering platform 'homebridge-harmonyhub.HarmonyHub' [8/7/2016, 9:08:41 PM] --- [8/7/2016, 9:08:41 PM] Loaded config.json with 0 accessories and 1 platforms. [8/7/2016, 9:08:41 PM] --- [8/7/2016, 9:08:41 PM] Loading 1 platforms... [8/7/2016, 9:08:41 PM] [Living Room] Initializing HarmonyHub platform... [8/7/2016, 9:08:41 PM] Loading 0 accessories... Scan this code with your HomeKit App on your iOS device to pair with Homebridge:
┌────────────┐
│ 031-45-154 │
└────────────┘
[8/7/2016, 9:08:41 PM] Homebridge is running on port 51826. events.js:141 throw er; // Unhandled 'error' event ^
Error: listen EADDRINUSE :::51826
at Object.exports._errnoException (util.js:837:11)
at exports._exceptionWithHostPort (util.js:860:20)
at Server._listen2 (net.js:1231:14)
at listen (net.js:1267:10)
at Server.listen (net.js:1363:5)
at EventedHTTPServer.listen (/usr/local/lib/node_modules/homebridge/node_modules/hap-nodejs/lib/util/eventedhttp.js:58:19)
at HAPServer.listen (/usr/local/lib/node_modules/homebridge/node_modules/hap-nodejs/lib/HAPServer.js:155:20)
at Bridge.Accessory.publish (/usr/local/lib/node_modules/homebridge/node_modules/hap-nodejs/lib/Accessory.js:480:16)
at Server._publish (/usr/local/lib/node_modules/homebridge/lib/server.js:92:16)
at Server.run (/usr/local/lib/node_modules/homebridge/lib/server.js:82:10)
at module.exports (/usr/local/lib/node_modules/homebridge/lib/cli.js:40:10)
at Object.
I get the same, I have 2 hubs configured, both with the IP address explicitly set. If I remove one of them from the config then the server starts correctly.
Aug 29 20:41:06 raspberrypi homebridge[1877]: events.js:141 Aug 29 20:41:06 raspberrypi homebridge[1877]: throw er; // Unhandled 'error' event Aug 29 20:41:06 raspberrypi homebridge[1877]: ^ Aug 29 20:41:06 raspberrypi homebridge[1877]: Error: bind EADDRINUSE 0.0.0.0:5224 Aug 29 20:41:06 raspberrypi homebridge[1877]: at Object.exports._errnoException (util.js:870:11) Aug 29 20:41:06 raspberrypi homebridge[1877]: at exports._exceptionWithHostPort (util.js:893:20) Aug 29 20:41:06 raspberrypi homebridge[1877]: at dgram.js:214:18 Aug 29 20:41:06 raspberrypi homebridge[1877]: at nextTickCallbackWith3Args (node.js:453:9) Aug 29 20:41:06 raspberrypi homebridge[1877]: at process._tickCallback (node.js:359:17) Aug 29 20:41:06 raspberrypi homebridge[1877]: at Function.Module.runMain (module.js:443:11) Aug 29 20:41:06 raspberrypi homebridge[1877]: at startup (node.js:139:18) Aug 29 20:41:06 raspberrypi homebridge[1877]: at node.js:968:3
Thats the issue. You cannot have 2 hubs configured anymore (at least as it stands). Version 0.2.0 handles multiple hubs for you so you no longer need it
Is there a reason you need to specify the 2 configurations with hard coded IPs (other than that is how it you used to have to do it)?
For me that was a legacy config, as you point out. Only reason I can think of is two or more hubs on separate broadcast domains.
Examples would be a different VLAN or subnet. i.e. in a situation where you couldn't rely on autodiscovery protocols like mDNS/bonjour to work.
Of course this doesn't stand if you can query one of the hubs about the other hubs on the same account?
@matt-cahill Fair point. Unfortunately that would involve a lot of tinkering with the new software as it relies heavily on automatic discovery (now used to detect connection loss and reconnection).
I almost wonder if the route to take with that would be to add accessories instead of platforms if you want to hard code a hub IP since now hubs are considered single accessories.
Do you fall under this case or are you more brainstorming possible reasons?
For me it's working by removing the hard coded IP addresses. I don't know about the original requester though.
If anything, it would be good to update the docs to make it clear that only one IP can be stated in the config but multiple devices are supported if discovered also possibly catch the miss-configuration and warn/error out rather than trying to bind to the designated port twice and crash.