MDNS Discovery not working (Empty Array)

[steffenu]

const discovery = require('node-hue-api').discovery
;

async function getBridge() {
  const results = await discovery.mdnsSearch();

  // Results will be an array of bridges that were found
  console.log(JSON.stringify(results, null, 2));

}

getBridge();

This is not giving me any results ( Empty Array )
what can I do ?

• using the latest Beta

the api seems to work fine when I just use my ip directly:

const unauthenticatedApi = await hueApi.createLocal("192.168.1.105").connect();

Ok const results = await discovery.nupnpSearch();
seems to work .. but mdns still doesnt .. which I absolutely would need for realiable discovery :D

I have a pretty old router tplink TL-WR1043ND .. could this cause any issues ?

[peter-murray]

I had a few issues on my network when trying to write this as I have multiple VLANs and pretty complex firewall in place. When debugging my issues I used my firewall to capture the traffic and analyse it to see where things were not traversing as expected/intended.

This of course is not particularly simple stuff to work through when it does not work. There are some utilities and tools that you can use also on PC, Linux and MacOS that reveal what mDNS traffic and responses are present on your network like mDNS in MacOS for instance.

Is your client and bridge on the same network? If there might be some segregation, turning on things like Avahi (or mDNS discover option) on the router can help.

[steffenu]

Yes client and bridge are on the same network. Router is pretty old and has no such options ;). I will try again with firewalls disabled. Otherwise its probably my old routers fault.

[acouvreur]

Do you have any recommendations on running an app with this lib inside a container? The multicast will only try the availables interfaces.

And the docker container does not have my LAN interface, it only has its private network stack.

I'd also like to avoid using network mode host.

The mDNS discovery uses the 'bonjour' library which uses the 'multicast-dns' library.

We can customize the options like this

But even then, I'm not sure how to proceed from a container.

[tiptronic]

Seeing the same issue as @steffenu using beta 15 and node 19.6

Bridge, router, machine (Mac OS Ventura 13.3 (22E252)) all on the same network. No subnets, VLANs whatsoever...

node discoverBridgeViaMDNS.js
[]

node discoverBridgeViaNupnp.js
[
  {
    "ipaddress": "XXX.XXX.X.X",
    "config": {
      "name": "Philips hue 2",
      "ipaddress": "XXX.XXX.X.X",
      "modelid": "BSB002",
      "swversion": "1957113050"
    }
  }
]

The nupnpSearch function is marked deprecated, but I haven't had any success using the mdnsSearch...
I can see the bridge in thee _hap._tcp. and the _hue._tcp section of Discovery (Bonjour), but never got anything using mdnsSearch (ran right from the examples folder in the current repo).

Any hint or recommendation?

[peter-murray]

I have swapped out the bonjour library in favour of node-dns-sd, but the results are still sometimes returning empty arrays. I think this is just a Node.js issue at it's core in that the implementations are to 100% reliable.

That said, it seems to be a little more robust that the pervious version and if you only have one bridge, rather than wait for the time to expire, you can return on discovery but passing in a timeout (in ms) and the boolean returnOnFirstFound set to true. At least when it gets a match and you only have one bridge, then you get a faster discovery.

I released this change as 5.0.0-beta.16, let me know if that improves anything.

[tiptronic]

Hi Peter,
thanks for taking the time looking into this...
What I did (for now) is, I start the mDNS discovery twice (if it returns an empty array), which sometimes (mostly) works and - if not - I'm starting an UPNP search... Although marked as deprecated this works fine...

Unfortunately I can't just use beta 16 'as is', because I've got the problem, where imports don't work as long as the imports don't contain the .js suffix. (I had to rename all imports manually for now, because I don't know how to create a js-only build).

#220

[tiptronic]

@peter-murray I don't know if this is of any help or value, but yesterday I tried to find the bridge using:

https://github.com/agnat/node_mdns

only using default settings - and it seems to always find the bridge (and finds it pretty fast)...

Although I have to admit, I never worked on this before and likely don't know about potential implications (and there might be good reasons other implementations do some more - time-consuming - filtering/searching). I just wanted to mention that finding the brige using the above mentioned library was quick and reliable...
(I also only tested this on Mac Ventura 13.3.1 (22E261) INTEL...)

[peter-murray]

I had swapped out the library on this branch for node-dns-sd here; https://github.com/peter-murray/node-hue-api/tree/esmodule but have not ported things back yet.

[peter-murray]

That specific library, https://github.com/agnat/node_mdns unfortunately has platform specific bindings, so not something I can adopt with the library.

[tiptronic]

I had swapped out the library on this branch for node-dns-sd here; https://github.com/peter-murray/node-hue-api/tree/esmodule but have not ported things back yet.

Do you think this will make it into the main branch any time soon?

[peter-murray]

It is on my backlog.

To support it I have to port all the tests over to typescript which is painful and slow, as well as needing to address the bridge test lookups to mdns.

I am busy with work currently that will not afford me time to get to this until later in the month at best.

[tiptronic]

Thanks for the reply Peter - looking forward to it