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 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.
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).
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?
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).
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?
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.
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.