"shellyEntries" gets some responses. "httpEntries" does not.
I've got 2 different third-party mDNS scanner apps, both show TONS of stuff on _http._tcp but they never show up in Hubitat. This runs in a callback from this line in my code: subscribe(location, 'systemStart', 'systemStartHandler') and I've tried rebooting the hub.
The fact that one of them works and the other doesn't pretty much eliminates it being something I've done wrong, since if that was the case then neither would be working. I've also tried using ONLY the _http._tcp one by itself, in case it was an issue of only being able to use one at a time, and that didn't make any difference.
Is there something else that needs done here? Or some other way to register/unregister the listeners that isn't "documented" in the post @gopher.ny posted a while back about this?
Let me know if there's any logs or other diagnostic data I can provide on this, @gopher.ny
I'd really like to wrap up a few things on my new Shelly Device Manager app, but it relies on mDNS to discover new Shelly devices quickly. I have a work-around where it just fires off a sequential subnet scan for everything on /24 looking for devices that respond to the /shelly endpoint, but that's slow since anything more than 1 address per second causes Hubitat to complain about too many inflight async HTTP request.
I'm wondering if maybe some sort of internal app or the built-in Shelly integration is somehow interfering with getting mDNS for _http._tcp properly.
Cool, everyone should have vacation time. When he's back hopefully I can help get this sorted out. I know it's a new feature he's been working on, or at least he's the one who announced it a while back, so he's at least familiar with it.
@daniel.winks, check out hubitat.helper.ShellyHelper.getDeviceInfoEntries() method. The built-in integration is hogging relevant mDNS listeners. There will be a handful of useful fields in the returned list of objects, the same data that the built-in integration uses.
long deviceId
boolean disabled
String name
String ipAddress
String macAddress
int generation
boolean online
boolean onlineCheckDone
boolean unknown // true if device exists and is a stub
boolean firmwareUpdateAvailable
This works very nicely. By chance, is there any sort of hubitat.helper.SonosHelper? Or for that matter, is there a complete list of these helpers somewhere?
You should be able to use registerMDNSListener('_sonos._tcp') followed by getMDNSEntries('_sonos._tcp'). Shelly gets a special treatment because there are different generations of their devices.
Same here, registerMDNSListener('_esphomelib._tcp') followed by getMDNSEntries('_esphomelib._tcp') should work.
It was only _http._tcp that was affected, but the issue with that is that Shelly are just one of many things that use _http._tcp. ESPHome uses it, along with _esphomelib._tcp. I personally don't presently have anything else on _http._tcp that I want to discover, but if it's being "hogged" internally by the Shelly integration then that will definitely cause issues.
