I am trying to integrate with SBB fans but don’t have one on hand for testing. I would like to identify them uniquely and distinguish them from standalone bridges and other connected fans. Here are a few questions I have:
I have read that SBB fans all have an ID starting with “K”. I am expecting to find this in the BPUP reply. Is this correct?
Are there any other clues to differentiate the Bond vs. Bond Pro vs SBB? Can the Bond be differentiated from the Pro?
Are there any other SBB devices beside fans?
For SBB fans, do they have both a device ID and bridge ID, or just one? If I call v2/devices/{device_id} would I use the BPUP id starting with “K” or is there an additional device ID.
I believe all SBB fans are expected to start with K, but I do not know if that is guaranteed. Also, as #3 is answered below, there are other types of SBB devices.
I believe this is the last official answer we saw from the Bond team - also, from what I recall the last time I was able to use one of my SBB devices was that the device ID node was always “1”. I’m not 100% certain of that, though I am fairly certain. The caveat to it, even if it is true, is that I don’t know if that is guaranteed. Finally, only Bridges have the v2/bridge mode, I believe?
From what I’ve read, there are a number of Smart by Bond device types either on, or coming to, market from various partner companies. There is the outdoor / landscape lighting controller, and there is mention in the API docs about “in-wall switches and dimmers and other SBB products”.
As I recall, there is always a Bond root ID (Bridge or SBB) and also Device ID for any configured devices on the root; in the case of SBB there should always be at least one device. Again, I think historically I had seen it as a device ID of “1”. You cannot just call BondRoot/Commands or Actions or anything directly - it’s always BondRoot/v2/devices/deviceID/commands etc.
@marcio - if you are able to drop by and correct anything I said incorrectly, or add additional details, I will of course defer to you (or other Bond team members).
I did have an alpha tester for my integration try it with their SBB fan and it sounds like it did respond to v2/bridge. So it sounds to me like there is both a “bridge” and “device” from a data modeling perspective, even if they are the same physical device.
Being able to separate SBB from the standalone bridges would be great, either by the ID or by something in the v2/version endpoint. If anyone feels like sharing their v2/version output for SBB devices, that would be greatly appreciated.
I’ll have to dig out one of my SBBs and update it (even though it won’t be connected to an actual fan device) tomorrow if someone doesn’t post an update for you before then.
BTW, I did confirm with an old note that “/v2/devices/1/actions/” was the endpoint I was hitting for Actions on a SBB device - showing that the device ID of “1” was what I was getting.
In the particular SBB device I am using for this example (a HomeDepot item), I did not get a response from v2/bridge:
curl -H "BOND-Token: xxxxxxxxxxxxxxxx" -i http://192.n.n.n/v2/devices
HTTP/1.1 200 OK
Content-Length: 39
Content-Type: application/json; charset=utf-8
{"_":"548663cd","1":{"_":"9a8e7326"}}
curl -H "BOND-Token: xxxxxxxxxxxxxxxx" -i http://192.n.n.n/v2/bridge
HTTP/1.1 404 Not Found
Content-Length: 0
This image is a bit unwieldy, but I believe it is a full traversal of all the nodes under /v2 (the script I use to enumerate these in a tree node is a bit … inelegant).
I did manually collapse each of the “_” hash object nodes before taking the scrolling screenshot since those are of no value really as a reference.
If this image doesn’t post well / can’t be clicked and zoomed in well enough, I can convert to text and post that instead. Looks like if you click it once, it opens a little bigger; clicking again makes it legible and scrollable, at least for me.
Here it is:
