Smart by Bond: API "command" not working

I have been successful using the API from the terminal and creating some scripts to control my new Minka Timber fan. However, when trying to integrate with homebridge and working with the homebridge-bond developer, we have discovered that the curl -H “BOND-Token:XXXXXX” -i http://192.168.1.YYY/v2/devices/Z/commands does not work. It returns a “404 Not Found” error.

Every other thing I have tried works fine: the device info, properties, sending commands to the fans and lights, etc. Is this a bug particular to my device? I am running the latest firmware v2.9, but I found the issue using the previous version too.

1 Like

I haven’t tried this yet, but @jacob made it possible to supply the Token in the request body itself instead of a header (since firmware version 2.6.23) if you’re wanting to try a different method to verify it is indeed not functioning as expected:

https://forum.bondhome.io/t/local-api-documentation-v2-6-32/588/2

To get a list of devices on the Bond using the embedded token technique:

curl -i http://192.100.0.61/v2/devices -X GET -d "{\"_token\": \"f074b61f628018fd\"}"

thanks, same result with both methods :frowning:

Also I see you say all other calls are working - your example notes that http://v2/devices/commands doesn’t return anything when you should have a device number in the URL?
Like:
http://192.168.0.100/v2/devices/{device_id}/commands

sorry, I just edited my post. I had used “less than” and “greater than” to replace the ip address, device number, etc, and it gave unexpected results when posted. The edited post shows what I use.

Ah, yep, I see the edit.

I don’t have particularly useful insight now that we cleared up that every other call works, and verified syntax isn’t at fault here. :slight_smile:

I also just verified my BD (fw 2.8.4.2-beta) and my ZZ (fw 2.8.4.2-beta) Bridges both work with my commands calls still (via curl, as I don’t use Homebridge)

Wanted to add one piece of information that I think is missing - the device in question is a fan with BOND built in. This seems to be the one variable that is different from other users who aren’t seeing this issue.

NOTE: commands are only present on Bridge devices

(via http://docs-local.appbond.com/#tag/Devices/paths/~1v2~1devices~1{device_id}/get)

1 Like

Yes, I see it now. Thank you for confirming Smart by Bond devices do not have “commands”.

1 Like

@KCF @aarons22: Please use the “actions” API for controlling devices. The “commands” API is a lower level API that maps directly to signals transmitted by the Bond Bridge.

So, devices/x/actions/TurnLightOn will always turn on the light, no matter whether it is a Bond Bridge device, or Smart by Bond, or even one of the Smart by Bond fans with multiple lights (something reasonable will happen with both lights).

Are the API docs perhaps unclear in that regard?

@merck, the API docs are clear. We have no issues controlling devices. The problem is that the homebridge plugin for bond uses “commands” to figure out what are the possible speeds for the fan.

You don’t want to use / can’t use Properties and max_speed?

1 Like

@residualimages API docs for actions are great, and make a lot of sense when mapping actions from the devices/<device_id> endpoint!

Honestly I didn’t notice the Properties section until I re-examined the docs, and while max_speed would work for most users, it doesn’t account for users who don’t use all of the speeds in sequential order. For example, a user could decide they don’t need the granularity of 1-8 and use 1, 2, 5, 7, 8. In that case, it would return a max_speed of 8, but I have no way of knowing which speeds they actually programmed. While this isn’t super likely, homebridge forces me to specify a specific step value within the 0-100 range (so for three speeds, step value is 33, four values is 25, etc). As soon as user diverts from the assumption that max_speed requires me to make, things will break pretty quickly.

That’s why I ended up using the commands, since you get the argument directly. I look at the devices commands where action == SetSpeed and use those argument values.

2 Likes

Appreciate your time and the detailed reply, Aaron!
It’s a little work to integrate with each system, taking into consideration each of the platform-specific nuances, so I am glad you’re making it work.

@merck: do SBB-integrated retail fans all have default speeds 1-5, and do they retain all speeds in all circumstances, or can users specify speeds which are ‘available’ on SBB-integrated fans?

@aarons22 was quick! He already released a new version of the homebridge-bond plugin that works with Smart by Bond devices (using “properties” instead of “commands”). Kudos to him, and kudos to the Olibra team for making the API/docs available. I could only be happier if there was a bond bridge for my 2.4GHz fans :slight_smile:

2 Likes

@aarons22, nicely done, sir. :clap:
Thanks for the update, @KCF. :slight_smile:

I gave this a try. I posted commands for speeds 1, 2, 5, 7, 8. Properties returns, as expected, max_speed as 8. But if you issue SetSpeed for a non-existent speed, you get an HTTP 400 Bad Request: action not supported, which is not really fair, given that we claim you shouldn’t need to care about the Commands API.

What the firmware should be doing in this case is, assuming the nearest speed for which a command exists (rounding up) and updating the state with the speed of the command actually transmitted. That way if you are using a slider UI element to implement speed, the slider will update to the actual value once the state feedback is taken into account.

That said, you are using the Commands API as the Bond Home apps use it currently. We do have rough plans however to move to a slider control for speed everywhere, and just expose the command-level details when drilling into command editing.

1 Like