Just wondering, what’s the difference in controlling BB vs SBB? Documentation says that there’s no difference, but a lot of functions have “Only for SBB”.
Also, BB is a hub which controls many devices. But SBB is a single device? There must be some difference in talking to these devices.
Excuse me if my questions sound stupid - I just started…
The Bridge hooks into existing RF (in supported ranges) and IR remote controls, with each individual Bridge able to store and control many, many RF and IR devices (I forget the total number in the new firmware revisions).
The Smart By Bond (SBB) device is a way to retrofit a single “dumb” (not remote controlled) ceiling fan with remote light and fan control, as well as a very low latency stateful API reporting and control / integration options using the same API.
I think you miss-understood this - SBB is actually the “smart” device which supports the Bond protocol out-of-the box. That’s my understanding at least.
I am coming from a personal knowledge viewpoint, because I have installed and used early versions of both the SBB devices and the Bridges, and also purchased 2 of my own SBB kits through the retail channel (via the link I posted here).
I am not guessing, but rather informing based on knowledge.
See also:
EDIT: That being said, I believe there are some retail ceiling fans from some BOND partner OEMs which include the same kit as above in the ceiling fan retail packing (so it’s not a retrofit, but rather, an initial install).
That’s info I’ve got from Chris Merck:
We do not produce SBB but just the firmware, our partners do. Here’s the cheapest unit available: https://www.homedepot.com/p/Universal-Smart-Wi-Fi-4-Speed-Ceiling-Fan-Remote-Works-with-Google-Assistant-SmartThings-and-Alexa-99434/311264804
So the remote you mentioned is just one of devices using SBB
Olibra’s partner, the Minka Group, makers of stylish ceiling fans under the Minka Aire label, will be the first of many vendors installing SBB technology into its current and future product lineups.
Some fans come with a Smart by Bond function inbuilt which lets users control theme without any additional hardware. Fans with this feature include the Minka Barn, Timber, Sleek and Windmolen.
So what are the API differences between Bridges and SBB devices? For example, do SBB devices have a bondid property in the Get Version info API results? What target do SBB devices report. Can SBB devices have a name separate from device name(s), like Bond Bridges do? How would I get such a name, assuming that the Get Bridge info API is not callable. What is the best way to distinguish a Bond Bridge from an SBB device just from the Get Version info API results?
Yeah, it has this field.
There are many different SBB targets.
No, they only have the device name, and same for location.
Hmm… I’d check for a “target” of “snowbird” or “zermatt” (implying that you’re interacting with a Bond Bridge) if that’s what you really want.
Though if you’re using the Actions API to integrate, you probably don’t need to distinguish between Bridge devices and SBB devices, as we designed the API to make the behavior the same.
But the field returns null?
Well, except for handling the device ID, which has to be concatenated with the bondid to be unique, and not being able to call Get Bridge Info API to get the name for the SBB device (separate from the controllable device(s)). I will need to distinguish between Bridges and SBB devices for those reasons, not really control. For simplicity, I create a parent node for each bridge or SBB device, then a child node for each of the controllable devices returned from the Get Device List API for a particular bridge or SBB device (and yet a separate child node for an embedded light in a ceiling fan or a fan in a fireplace, so they can all be controlled independently).
Thanks for the info, though!
One more question: I actually use the call to the Get Bridge Info API (/v2/bridge) to both retrieve the name of the bridge, and to verify that the supplied token is correct. If I can’t call the /v2/bridge endpoint for SBB devices (and I haven’t enumarated devices on the bridge/SBB yet), is there another SBB level API similar to /v2/bridge I can call to validate the token?
Nope, just a string like Bond Bridge. SBBs use a bit of a longer ID scheme: 7 letters followed 5 numbers each.
Remember, my user reported bondid = null? The correct id is still available from mDNS, but not bondid.
Yeah, if I remember correctly, that user was on v2.6.something firmware. Unfortunately, bondid wasn’t added to that endpoint until v2.7.10 (in August of last year). Before that we were just relying on mDNS, which isn’t the greatest.
Users should be receiving prompts to upgrade their firmware when they set up on WiFi, I’m not sure whether that user didn’t get the prompt or just rejected it.
BTW we have an auto-upgrade API in the works, as you previously suggested. I’ll get a spec out for feedback soon.
Any followup from this user? Did an upgrade help?
I changed my code to used mDNS id, so not sure about user feedback after FW upgrade. I’ll check.
I don’t think there’s anything of interest for a typical integration outside of the devices tree and sys/version.
I checked users log for SBB:
SBB devices don’t have this endpoint.
Unfortunately calling /sys/version doesn’t serve to validate token, evidently, even if token is specified. So I am going to check target for “zermatt” or “snowbird,” and if it is, call /v2/bridge endpoint to retrieve name (and test token), and if not, then call /v2/devices solely to test token, knowing that I am just going to turn around and call /v2/devices again to retrieve the list of devices. Not pretty, but should work.
Let me know if this fits long term API plans or if something about this is wrong.
Yeah, the root topic, sys, sys/version, and the token topic allow unauthenticated access. (Though the token topic locks a while after boot or when a client asks it to unlock)
One potential alternative is to check for a 404 on v2/bridge
Everything is correct here.
Agreed, everything you’ve laid out should work, but maybe down the line you could abstract away the Bridge and skip checking whether the device is a Bridge or SBB. Just hold in memory the Bond ID and use this ID to build the parent nodes of the devices (and construct the qualified IDs: Bond ID + Dev ID).
Since the Devices themselves have a name, location, etc., knowing about the Bond’s name/location is IMO only relevant if the user needs to add a Bridge device and they have multiple Bridges. In this situation, the user’d want to make sure they pick the Bridge closest to their Device, and they’d want to know it’s “name” for this, not its ID, which may be meaningless to them.