I have seen a few posts about people having issues with mDNS and trying to find devices on the LAN. I am curious what everyone is using for this, as it seems like everyone will be solving the same issue. I am surprised it isn’t part of the Edge SDK.
I am working on an mDNS library that Edge driver developers can use. I already have a working Edge driver that uses it for anyone to try. It’s on my test channel. With it, you can get a list of all service types available on your LAN, query a specific service type, and get IP and port data.
3 Likes
Hi, @blueyetisoftware!
Actually, the engineering team is actively working on having this feature available, there’s no ETA yet but it come in a future update.
Thank you for bringing it up! 
2 Likes
I would encourage them to take a look at @TAustin 's repo when it is available. I have been trying it out in a pre-release and it seems to work pretty well.
2 Likes
1 Like
@rossetyler I am starting work on my hue driver and was thinking about writing my own mdns discovery for it. I was using upnp but they deprecated it and will be removing in in Q2. Before writing my own, I tried to give your code a shot. I get PTR records for the Hue hub, but no SRV records, so your code returns no results. Hue uses a service type _hue._tcp.local. I am ideally looking for the name and ip address. The name is available in the PTR if I modify your code. Any suggestions?
I have a Philips Hue.
I have Wireshark.
I unplug the network from the Hue (alternately, unplug power).
I run wireshark with a capture filter of “ether host :MACADDRESS:” where :MACADDRESS: is the colon delimited MAC address of my Philips Hue.
I plug my Hue back in.
Rather than explain exactly what I see, I suggest that you do the same.
The mDNS traffic I see suggests that before the Hue will provide an mDNS A record resolution for itself (host name to IPv4 address mapping), it makes sure that nobody else on the network is already doing the same.
As a good citizen, it is trying to avoid collisions on its name.
When it finds none, it provides many unsolicited mDNS responses to all on the network to flush their cache of any resolutions that it plans to be authoritive for.
The host name that I see is MACADDRESS.local where MACADDRESS is the MAC address of the Hue without the colons.
I can ping MACADDRESS.local from my Linux machine that uses mDNS hostname resolution.
I think, perhaps, you are mistaking these unsolicited responses as responses to your mDNS A record resolution question.
My code should work to resolve MACADDRESS.local to the Hue’s IPv4 address.
If this is not good enough for you, then you may be able to divine what other mDNS content is available from the Hue by digging through the Wireshark capture and use that to get to its address.
Please let me know how this works for you.
1 Like
To make sure we are on the same page, I don’t see a MAC address but see these instance names Philips Hue - XXXXXX._hue._tcp.local where XXXXXX is 6 character ID of the hub. This is probably sufficient since that is the true device network ID, and I can use that to later grab the IP address which can change. Just interesting that they are behaving a little differently. I’ll keep messing with it to see what I can get out of there. Thanks for the tips.
My Philips Hue definitely responds to an mDNS A record question for MACADDRESS.local.
I also see unsolicited mDNS responses referring to the same upon network (re)initialization.
Does yours behave differently?
Yes. I ended up rolling my own discovery because I wanted access to the additional records that are also in the PTR responses. Here is what I get from all of the different record types for a Hue hub. I masked out the IPs and Hub IDs. To be clear Hue-First is the hub name, and not the mac address.
{
"ptr":["Philips Hue - XXXXXX._hue._tcp.local","Philips Hue - YYYYYY._hue._tcp.local"],
"a":{
"Hue-Second.local":"IPV4_2",
"Hue-First.local":"IPV4_1"
},
"aaaa":{
"Hue-Second.local":"IPV6_2",
"Hue-First.local":"IPV6_1"
},
"srv":{
"Philips Hue - XXXXXX._hue._tcp.local":{
"target":"Hue-First.local",
"port":443
},
"Philips Hue - YYYYYY._hue._tcp.local":{
"target":"Hue-Second.local",
"port":443
}
}
}