/v2/devices Not Getting All Devices

-i, --include is the Response header. The token is in the Request header.

After further research, -i isn’t required, you can also use -v for verbose. This looks to be an issue with the endpoint and it being a bit non-standard. Here a discussion around it:

Basically, the response is returning 204 No Content, but there is a non-zero Content-Length. Since this doesn’t match, Postman throws an error but cURL just vomits the full output out. Why the server (bond) needs to send a valid response if there is no content, is a separate issue.

As far as usability and programming an integration, it’s not terribly critical since you’re going to use cURL in code anyway, however, for testing and development, a tool like Postman is extremely useful. I imagine other tools will have similar issues with this, but as far as I know, Postman is one of the best in this space.

That being said, I’d love for someone to prove me wrong and figure out a way to use Postman to make /tx PUT requests.

:man_facepalming: oh yeah. Duh. Thanks :blush:

The reason for the contradiction is, that on the (unreleased) BOND Cloud API, these objects will be expanded in the reply, while they are “stubbed” in the Local API. — Other than that, we are maintaining exactly the same logical API between the Local and Cloud.

Perhaps we could make two sets of example responses, one expanded and one stubbed.

Indeed on the backend (Cloud API) it is desirable to have fewer calls, perhaps with larger reply bodies. However, for the Local API, we need to keep the memory usage down, and the maximum reply size is a major driver of memory usage.

That said, if this stubbed Local API design is really a problem, we could make the HTTP replies use Chunked transfers, but it would involve significant development effort that may be better invested in BOND-specific features.

Agreed that a 204 should have no HTTP content! Will check into this.

Actually, as @residualimages guessed, this is not guaranteed. – What’s happening is, the JSON object is stored as a linked-list in RAM, and the JSON library we are using (cJSON) is rendering the output in the same order as is stored in memory. When you reboot, the commands are read from a flash database, the order of which may change during compaction. So, order of the JSON object key:value pairs is totally arbitrary.

Glad you like the openness! We’ll expose everthing we reasonably can…

1 Like

So you anticipate the Cloud API still making several Local API calls that get packaged up into a single response for the Cloud API? That makes sense, just making sure I understand.

Maybe I worded this poorly. The response does indeed have no content, but the headers state there is content. This seems to confuse Postman and it blows up. @residualimages mentioned in another topic that supplying Content-Length of 2 in the request “works” but that shouldn’t be required I don’t think. It does work though.

If using cURL, as long as you supply -i or -v, the command works. Without this, it too fails, albeit, less dramatically.

From an architecture standpoint, are you just storing this LL in RAM for speed’s sake? Is there a downside to reading from the flash storage for this? Not that the order matters (or should matter) in a JSON response. The discussion around order was really just me working through figuring out what was what.

@merck Great work though! I’m really excited about everything and I’ve began working on a basic DTH for SmartThings based on the local API but I’m worried SmartThings is going to have a hard time with the local IP because custom stuff generally executes in their cloud. A temporary workaround could be NAT’ing it through via my public IP, but with http, that’s not a great workaround. I happen to run pfSense at home and can utilize haproxy to route the traffic over SSL and to the bond hub unencrypted but many won’t have that option.

Any thoughts to the original post in this topic? Why am I only seeing 2 devices when I have 3 configured? There isn’t a large difference between them. What would make a device a “cloud” device persay? Is this one that the app “auto” sets up? Or is it the other way around?

Thanks for the thorough replies!

Well, actually the Cloud API just requires one request down to the BOND for PUT/POST/PATCH/DELETE, and for GET, the backend uses cached data (the “BOND shadow”) so no request is needed. – There’s a separate mechanism for maintaining the up-to-date status of the shadow.

So, you can expect the Cloud API to be quite performant.

It’s just the typical write-through-cache design pattern. (Used because RAM speed >> flash speed).

About half of the remote controls we have an a cloud-based database, the other half work offline. So when you use the database search feature during device setup, there’s a (very roughly) 50% chance your remote is in the cloud-only database. We don’t have a way to tell at this time which is which. It didn’t matter before Local API :slight_smile:

We do intend to make all devices available offline, but that will take some doing. (Requires devices to be able to dynamically generate complex packets offline.)

1 Like

Is there any merit in me spending the time to individually map (to a new device) the functions of my remote/fan combo that isn’t showing up and not using the search feature?

Will this make it show up today in the Local API then?

So if you just set up the device totally manually (each button scanned and saved), then you’re guaranteed local storage / offline compatibility?

(Or, what @Maverick0984 said haha)

1 Like

Yes, that will work, though you may be in for a surprise if you try this with an LCD-screen remote (a so-called “state remote”).

Yikes. It is indeed an LCD screen remote. Specifically, a Casablanca Intelitouch 3.

The one that shows up in the Local API is not that and is just a more standard “dumb” remote, though still Casablanca.

I actually kind of wish there was a nicer looking wall mounted RF fan / light controller. The remotes can be lost, have batteries, and look kind of funky sitting on the wall, if they even have that option.

Please do share how fun the surprise is if you try that, @Maverick0984! Wish I had a stateful remote to try.

Maybe just add the device again vs replacing it so that if it gets too fun you can abort? :stuck_out_tongue:

Yeah, I’d just make a new one and have them coexist. The “stateful” bit isn’t all that great to be honest. It’s usually correct, I guess, but not something I’d count on.

Does SmartThings have an equivalent that would let you do something like my (rough) setup?

We’re limited to Z-Wave / ZigBee for the most part. I can do whatever I want with an RF device and the Bond though. It helps to be able to write code to do the latter bit.

The problem with the existing Z-Wave options is they are all single purpose, single gang. So if you have a fan + light combo, it’ll take 2 gang slots. While some of my wall switches are 2 or 3 gang boxes already, the others are spoken for and the fan/light combo occupies 1 spot. Cutting drywall and adding a bigger box to make room for an additional spot isn’t something I want to do at all. I like using as little wall space as possible and don’t want children’s bedrooms to have a 3 or 4 gang, confusing wall setup for a small child.

Also, the ones that exist in Z-wave, made by GE all look identical, which some may like, but that means if you have a lamp, fan, lights hanging off the fan, they all look the same! So you have to actually remember what they are and then only have dimming (%) functionality from the wall switch. So no single button, single speed abilities.

It actually seems like the size of radios for Z-Wave / ZigBee are some of the issues here meaning we’re a ways off and RF might be the answer right now. I’m real interested in the Beta for a device that I got an email from, from here, but I never got a response after sign up :frowning: hint, hint.

As far as Z-Wave based scene controllers, which is kind of what you are working with, yes, SmartThings can do that, but that requires the network to be up of course. We’re kind of picky on the physical look of them too. I don’t want something that’s handwritten or says “Scene 2” which has to be translated to mean Speed 2 or Lights 2, etc. I’m still open to ideas. I saw your post yesterday but wasn’t sure what exactly I was looking at.

1 Like

I hadn’t checked in to see if things had gotten better from when I looked a few years ago before going all in on Insteon (at first with their consumer hub). Sucks that the home automation world is still so piecemeal and requires us coding to homogenate everything. But I do so love the opportunity to leverage local API controls, such as this new feature of the BOND bridge. :+1:

I do use Z-Wave and a few other protocols as well these days with my ISY994i; when I upgraded from the locked in Insteon hub to the vastly superior ISY, I had to pick Z-Wave -or- Zigbee to add in addition to my Insteon and IR control; since the August locks are Z-Wave that’s where I turned.

It looks like yours is still 2 switch integration, right? The left is the fan and the right is the light? That sort of setup can be done with pure Z-Wave today and SmartThings, no coding required. Although, you don’t get the cool lightup preset buttons.

I really want both in a single switch.

Honestly, I’d love a single switch to be dual load controlled and RF / Z-Wave / ZigBee.

The load being hardwired gets your instant local control and the others get your smart control with a couple second delay.

At this point though, I’d settle for a single switch that isn’t hardwired and is controlled 100% via SmartThings/Bond (or other).

Insteon has a large variety of single gang switches / keypads, etc that can be wired into your house (controlling an actual physical electrical load and / or controlling loads via programs or linking), as well as battery powered remotes.

By choice. I have 8 buttons (or really any combination of 4, 5, 6, 7, or 8 via button change out kits) available on the keypad to program whatever I want. I only did fan and light separately to show differences.
Right now a blank button (#5) is doing my dimming control of ceiling fan light (video not updated).

Also, neither switch nor keypad is actually controlling a load physically. Wirenutted wires in the gangbox always send power to the ceiling fan and its light.

For the loads / devices I control with APIs or Insteon virtual multiway switches, I hardwire power to the load so whatever device it is always live, rather than having a switch or keypad control the load. I power the Insteon keypad / switches with line and just cap off its load. Insteon by nature, and also through the ISY994 series controllers (though not the consumer hubs) actually is local control as well. Faster than Z-Wave or APIs, but local APIs are fairly quick. Aside from my Rachio irrigation and Harmony remotes, everything is local.

Would be cool. Didn’t they use to have Z-Wave versions of double switches like this? Looks like it’s hard to find / discontinued but the PDF manual shows load 1 and load 2 hardwire.

Yes, I had a couple of them actually. They were expensive. Ended up selling them as they were kind of quirky.

That’s only On/Off though of course.