I’m using Postman and I’m only getting 2 devices in the response to GET /v2/devices
I should have 3. Any thoughts?
Additionally, when querying the individual devices, I’m not getting any usable list of commands, however, things like name and location seem accurate. I’d post a screenshot of that too, but as a new user, I can only post 1 image.
Maybe this gives a hint, though I do not know which devices are which and which devices you have.
Can you use cURL and traverse each of the command nodes for each of the devices?
curl -H “BOND-Token: XYZ” -i http://192.168.x.x/v2/devices/00000003/commands/
curl -H “BOND-Token: XYZ” -i http://192.168.x.x/v2/devices/00000039/commands/
That’s real interesting. I like others don’t yet know what would make something a cloud or legacy device but I have 2 normal, plain Jane ceiling fans and a single “hacky” device that thinks it is a fan but is actually just an RF remote for a Christmas tree setup I have tied to IFTTT and a SmartThings custom device.
1 of the fans is in the list and the hacky device is the other. I’d expect maybe both fans to be the ones that show up instead of the hacky device if I was only going to see 2. Must be how they were paired I guess. Either way, Bond sees them as 3 fans.
Also, I actually don’t see anything in the command list. It’s just empty. Here’s an example of the 1st one 00000003 but they both look the same:
Could this have to do with the fact that I didn’t actually re-pair anything after upgrading to the beta firmware? I know we were told we’d have to but everything remained and works still so I figured I’d be fine.
Could be. I personally didn’t have to re-setup, but I think there were comments from others that they did have to re-pair?
I wonder if you pair one device to see if commands node populates, and if so, if you pair the other two again if the new firmware does anything different about cloud vs local?
It’s still a mysterious distinction to me.
I didn’t see the /commands so I added that and I get this now:
Obviously not all that useful unless I reverse engineer each one. I guess it’s probably in order?
I’m all for tinkering and trying to figure this out, but if this is some issue they are working to fix, I also don’t want to waste my time and appreciate the Local API, even though it’s a WIP. Maybe my feedback can help the devs.
Each node can be dug down into individually - tells you command name, etc. I did it for all my devices and all my commands and compiled the entire tree over ~20 minutes for 3 devices.
Right now, you have to find the command you want and use the tx action with a PUT.
Later the API will have actions you call, which is more convenient.
Also, no. Haha. Sorry to break the news to you it’s seemingly random as far as order.
I guess I’m confused why I’m not getting a response that matches the documentation? Is this just the spec they are working towards but aren’t there yet?
Each return node that has {} is another level deep and has to be dug into via the “root” / “parent” to get the “children” nodes.
The screenshot is a little misleading.
/v2/devices/00000001/commands would only return the “aabbccdd” {} , “00112233” {}, “abcdef01” {} nodes.
To get details you would go into each node individually like so:
/v2/devices/00000001/commands/aabbccdd/
/v2/devices/00000001/commands/00112233/
/v2/devices/00000001/commands/abcdef01/
It does look like there is an order, at least for me.
The command id is simple hex and in numerical order appears to correspond to order I have it in the app. Just to give you an idea:
I’m not done yet though, this would represent a “so far”.
It’s not guaranteed so don’t assume.
Here the documentation speaks about the “only one level of the tree is returned” for speed and simplicity (and to effectively operate within MQTT message size constraints):
http://docs-local.appbond.com/#section/Hash-Tree
You generally want to limit API calls, not artificially inflate them for some hierarchy on the backend. I’ll defer to them though for now as they know their software better than I of course.
The documentation is somewhat contradictory though as in one spot it seems like a single API call will retrieve everything I’d need and then this hash-tree / one layer bit you linked.
As far as the “order”, it’s a simple id, it’s going to go based on creation so the order will be the order you added commands during pairing I imagine. I just added them like a sane person so they are in ascending order for me.
As I’m digging into this, they are offering quite a bit of detail down to the binary data that will get sent in the RF signal. Woah. I know I’d never need this level of detail but it’s cool that it’s available.
Oh I can agree it’s definitely alpha more than beta right now.
But I’ve been wrestling with it and getting good results (with some trial and error initially, for sure).
I wish the commands were organized in a sane manner, just to play nicely with OCD haha.
Here are two examples of fans where I initially pushed two buttons and the BOND servers auto recognized and completed the remainder of the commands. No rhyme or reason I can see for the order of the commands:
Power Off Fan, Speed 2, Speed 4, Speed 6, Light Toggle, Light Dimmer, Speed 1, Speed 3, Speed 5, Reverse, Light Toggle
Speed 1, Speed 3, Power Off Fan, Light Off, Speed 2, Speed 4, Toggle Light, Reverse
I’ve never had the luxury of auto-recognized commands I don’t think. Or maybe I did on the one device I can’t see 
Still haven’t quite worked out how to actually send a command through the API. /tx with a PUT is resulting in no response for me and the documentation doesn’t list a 200 has a response code so maybe they aren’t done with it?
This is the format I use on command line, and the same basic idea when programatically calling the PUT request:
curl -i -H “BOND-Token: XYZ” http://192.168.x.x/v2/devices/00000003/commands/aabbccdd/tx -X PUT -d {}
That’s what I’m doing, although I’m using Postman instead of CLI Curl.
EDIT: Curl produced a 204 so that’s good I suppose. Curious why Postman doesn’t work.
I had to set my ISY to send the request as raw text vs URL encoded or other formats.
Haven’t used Postman personally - do you have those kinds of options in it?
Yeah, it does that. I’ve narrowed it down to the -i param. I’m not finding a way for Postman to support this and if I import the cURL command in, the -i or --include is dropped.
If I don’t include the -i, Postman and cURL fail.
Not really sure who to point the finger at here but Postman is a pretty widely used development tool.
-i, --include : This flag will include http header.
Makes sense that it fails without, since the authentication key is a header.
