Cannot get devices from local API

Following the above conversation, I am unable to get devices from the BOND bridge:

$ curl -H "BOND-Token: 890XXXXXXXXa4460" -i http://10.0.0.245/v2/devices
HTTP/1.1 200 OK
Content-Length: 18
Content-Type: application/json; charset=utf-8

{"_":"615e7200"}

In the app, it shows two devices:

Out of curiosity, are these fairly high tech remotes with screens and such?
I saw Chris Merck mention in one of the threads that a fan was stored in the cloud and unavailable to the local API, but I don’t know the specifics around that. I just assumed that a more complicated remote would maybe be the one stored in the cloud.
(BOND Local API BETA Sign-Up)

The remotes don’t have displays. When I reverse engineered the cloud API it showed the fans for my old BOND. I have the newer hardware revision now (ZZ) which supports the local API. I would think that it should at least return the devices associated with the bridge.

Ah, you’re that guy! I followed the reverse engineering you did but was holding out hope for the official API.

I re-read the post about a cloud device. Seems like it’s backwards from what I remembered. There was a user that was missing 3 out of 4 devices, and Chris said “The 1 device that remains is because it is stored on the Cloud. Those devices are not currently available via the Local API. I know this is not evident from the current UI, and we are planning on straightening that out.”

So I feel like I’m barking up the wrong tree. Have to wait for Chris or others to actually help you since I don’t really see an answer.

Yup, that’s me! Official docs are much cleaner than anything I was able to put together. Thrilled that it’s a local API too!

1 Like

I may have gotten my subtraction wrong @residualimages :confused:

We do have two different types of devices internally: “legacy devices” and “cloud devices”. The “cloud devices” are currently only stored in the cloud and do not actually have any record on the BOND’s database, so, sadly they are not available via the Local API. — They will be available via the Cloud API when that is released.

We do plan to migrate the current “cloud devices” offline, at least for newly-recorded devices, once support for these more sophisticated protocols is there in the firmware.

So, for the time-being, you may see what @danmandle is seeing, and have missing devices on the Local API.

2 Likes

So how do we know which devices will be cloud only for the time being?

For now, there’s no way to tell until you check on the local API. We consider it a temporary issue that the devices are not accessible via local API, and are working on making all devices work offline.

@merck any updates on “cloud devices” being moved to the local API?

It’s probably the toughest technical challenge that we have attempted, but with big community upside… Will be attacking this after fully rolling out the V2 firmware.

1 Like

Where is that in the queue vs exposing the cloud API? Just trying to figure out if/where I can control my fans via any API before the height of summer.

Cloud API first for sure. :soon: @joaoricardo will announce it!

I just updated the firmware to 2.6.21-beta on a snowbird device:

{
    "target": "snowbird",
    "fw_ver": "v2.6.21-beta",
    "fw_date": "Fri May 24 21:31:07 UTC 2019",
    "uptime_s": 599,
    "upgrade_http": true,
    "api": 2,
    "_": "2523894a"
}

However, when I list devices, this is what I get:

http://x.x.x.x/v2/devices

{
    "_": "f4e91b3d"
}

I think that means that only the hash value of the devices object was returned, with no devices? That is unfortunate, because I actually have two devices configured: a fan and a fireplace. I assume that they must be cloud devices? @merck: Is there any way to confirm the device type for the devices attached to my BOND bridge (BD23512)? Thanks!

If they are usable in-app, but they aren’t visible on that endpoint, then it’s safe to say that they are ‘cloud’ devices.

I’ve also confirmed, yeah both of your devices store state in the backend and aren’t stored locally. Working on this now!

1 Like

@joaoricardo @jacob any updates on when the cloud API will be available? Also looking forward to the ST integration as a stopgap.

Hi @danmandle

We don’t have a release date yet, and any update about that will be posting in here.

Excited to have just got my bond (BH serial). Got it up and running on the beta app and firmware quickly (kudos to making that a smooth experience!) My only RF device now is a fireplace remote. Works great in the app. Bites that I ran into the same issue (guessing cloud-only device) - the /v2/devices endpoint only returns the root and no devices. I’m really interested in getting this working before I invest in a bunch of ceiling fans for my house. Would like to gain confidence with the simple on/off thing first. Also really interested in integrating with HomeAssistant. Should be relatively easy once the API returns all devices. Any new updates on migrating devices to be “local”?

1 Like

Welcome to the party, @maskedpirate!!

For the time being… If you create a second device, and when setting up, choose to bypass the automatic database match and record each remote button press manually, you should be able to force that (duplicate) device to be a local device (unless something changed of which I am not aware).

Quoting Chris Merck here:

Thanks @residualimages (and @merck )!!! Exactly what I needed. Was a bit more doc surfing to figure out the API for command tx vs the actions found in the upper portion of the docs but… got it working!!

And for anyone trying to do things with HomeAssistant, the quick and dirty version was using a rest_command…

rest_command:
  fireplace_on:
    url: http://192.../v2/devices/.../commands/.../tx
    method: PUT
    headers:
      BOND-Token: !secret bond_token
    payload: '{}'
  fireplace_off:
    url: http://192.../v2/devices/.../commands/.../tx
    method: PUT
    headers:
      BOND-Token: !secret bond_token
    payload: '{}'
1 Like

Nicely done / congratulations on the working solution, @maskedpirate. :partying_face: