Does the Bond Bridge (or SBB devices) support any discovery protocols, such as SSDP?
It supports mdns. See the API documentation for details
I saw that, but avahi-browse on my home network returns lots of domains and services, just not the Bond bridge, despite the fact that I can ping it by both IP and .local.
Any suggestions on how to debug Bond bridge not responding to the mDNS discovery broadcast?
Alot of wireless access points do not route UPnP traffic from wireless lan to ethernet lan and vice versa. I would look at this first and 90% of the time this is the problem.
Thanks for that. Sounds like that mean mDNS discovery wouldn’t really be a reliable method for an integration to discover Bond bridges on the network, then, since they would all necessarily be connected through a Wi-Fi AP. Perhaps I should just stick with my current implementation where users specify hostnames and tokens in configuration.
We allow for both.
The majority of off the shelf access points are fine. Its just the professional grade ones that block the traffic.
Also my mistake on UPnP traffic. I mean UDP broadcast traffic.
mDNS is widely used by all manufacturers (i.e. Google, Sonoff, Shelly, WiFi printers) and works fine.
I did find some issue with Bond mDNS implementation, see the link.
For me changing my mDNS code (since I do have access to the code) fixed the issue. But I hope the Bridge developers will investigate further.
It also depends on the OS, it looks like you are on Linux?
PS. Better search forum before posting.
If I do an avahi-browse from my RPi (the device that runs the Bond integration), I see wireless my AVRs, wireless printers, iPads, and other devices connected to the Wi-fi network. Just not the Bond bridge. It is possible that all those other devices are in the local cache, but both the RPi and the Bond bridge have been on the network for over a year together, and they’ve exchange a lot of traffic. So unless those other devices were picked up in some other fashion (e.g. Bonjour or some other compatible but different service), I don’t understand why the Bond bridge would not be listed.
BTW, I did search the forum for “discovery” before posting, but thank you for the advice. I don’t know how I managed to spend 25 years on these types of forums without it.
@alexbk66 I didn’t come in 3 days ago looking for mDNS topics, though, because I was completely unaware mDNS could be utilized for service discovery. I though it was simply a way to resolve names in the .local TLD without an internal NS. Plus I think I only searched Integrations.
Now I know and I am investigating. Thanks for linking the other topic in - it has been helpful. I certainly did not give avahi-browse 30 mins. to resolve the Bond Bridge. If it didn’t show up in 5 seconds, I considered it failing (as would most of the users of my integration). I’ve done one other integration with a “discovery” process to find local devices, and it was SSDP and all devices respond within 2 to 3 seconds.
@alanchow I have Unifi AC-Pro and AC-Lite APs connected to unmanaged switches. From what I can read, the APs themselves are not blocking UDP broadcasts and Unifi recommends blocking UDP broadcasts at the port level on their managed switches. I don’t have any experience with Wireshark or other investigatory tools to monitor traffic (this issue has come up in another posting regarding failure of POST and then immediate GET failing and requiring a delay to which I haven’t responded). It will take me several months to ramp up in that area, I imagine, since I have only a handful of hours a week to play with these things. I will be pursuing it, however, so thanks for the info.
Bond bridge finally showed up in avahi-browse. Left it running for about an hour and a half.
Phew! Since I’ve had hit or miss success with mDNS, particularly on Windows based machines, I wrote a script to scan the whole subnet via cURL looking for BOND devices by just poking at their public /v2/sys/version node.
Not sure it’s better for what you are wanting to do, and it’s definitely not elegant, but it seems to traverse all 256 addresses in ~5 to 6 minutes (~280 to 360 seconds on a Windows machine at least).
Is something like this psuedo-code (using the max-time option for curl) useful as a brute force backup?
get the looped 0-255 output from something like:
curl -i -m 0.75 "http://" & IPBaseQuads & "." & subnetIncrementingQuad & "/v2/sys/version"
…and then see if each looped result output contains “{” (or something else BOND-response identifying)
@residualimages That is a possibility but you’re right - not exactly elegant. Here’s what I am thinking:
The Bond Bridge may broadcast its service type when power cycled - I am investigating this. Any discovery process for the bridges will need to have the bridge power-cycled in the last few minutes in order to retrieve the token ID. So, for the ISY nodeserver Discovery process, you would power cycle you Bond Bridge(s), and then, within a few minutes, run the nodeserver’s “Discover Devices” command. The mDNS broadcast should still be in the RPi’s or Polisy’s avahi-daemon cache, and the token should be available for retrieval. You could perform this procedure as many times as necessary to add all of your bridges or SBB devices since it ignores those for which nodes already exist, and you still have the option of putting an older or stubborn bridge in the custom configuration parameters by hostname/token pair. I could also let the discovery process run for some length of time (e.g., 10 minutes) and add bridges as the mDNS broadcast is received (you going around and power cycling them), but that would require that I start a thread for discovery, and is probably not worth the trouble.
(@kingwr An ISY aside, mostly jokingly - are we going to advocate / suggest as a quick way to automate it that we plug in the BOND Bridge to an Insteon on/off switch or plug and do the power cycling for the users? 
)
always the age-old … “but have you tried turning it off and on again”, but in this case it does things.
I’ve done many other integrations using the same Zeroconf library (C#) and it worked. But as I explained in the topic I linked - it doesn’t work for Bond.
I found the difference: Python code sends mDNS Question with Class.IN (the Internet), but C# implementation sends ANY = 255 (any class) - which supposedly should work better, but apparently it doesn’t work with your mDNS implementation (a bug?)
Just because I compile Zeroconf library from source - I changed it to send Class.IN request and now it works.
But I’m sure that this it just a workaround because the original Zeroconf code works for other integrations (Google, Sonoff, Shelly).
So, Bond still need to investigate the issue - even their Python example doesn’t discover on Windows at least. @merck
And that’s exactly where I landed. I am using Zeroconf for in python to get the bond IP address and host name from avahi-daemon, since it appears to be already installed in RPi installations. However, since I will be asking the users to power cycle the bridge just before performing the discovery (necessary to retrieve the token), it ensures the entry is in the cache of the avahi-daemon and zeroconf returns the service information immediately.
So, yes @merck there is some sort of problem with the Bond Bridge not responding to avahi-browse for a really, really long time and/or only broadcasting its mDNS info on reboot. Unfortunately, unlike @alexbk66 I don’t have the skills to rewrite zeroconf for python, but I may be OK as long as I have users reboot right before discovery.
I think it’s better to do one step at the time - discovery first - you don’t need token for that. Then once it’s discovered - ask for reboot. That’s what I do in my integration.
@merck that was really interesting, your Python Zeroconf sends the request which causes the bridge to reply, but then my C# code gets the reply - not the Python code.
My initial idea for the quick workaround was to have your Python code in the background sending the correct request - and then my C# mDNS recieve the reply 
@merck I may have spoken too soon. It does appear that using the Python Zeroconf or the avahi-browse command, the Bond Bridge responds every time as long as I specify _bond._tcp as the service type to browse for. If I do avahi-browse -a (all), the Bond Bridge only shows up if I power cycle it. I am specifically using the python-zeroconf from jstasiak that sits on top of the avahi-daemon, with no dbus or avahi-client library in between.
Don’t know if this helps or not with any debugging, but just wanted to put it out there.
1 Like