Bond Integration - gotDeviceAction resp408,

🛎️ Get Help Integrations
1

I just got a "Smart by Bond" device and added the built-in integration to control it.

It seems to be spectacularly unreliable and the devices don't have "command retry" available. When I turn it off and on, it seems like every few times it doesn't get the command properly sent to the device (although the state seems to change on the Hubitat Device).

image
image820×297 44.2 KB

When this happens, the log shows the "gotDeviceAction resp 408" error. Trying again usually seems to work fine.

If "Command Retry" were available and functional (or if the driver simply retried automatically on that error--and least a few times), I'd have not problems.

However, this appears to be a "one and done" thing and I'm concerned that means my lights will randomly not get properly set. I used to have that problem globally and had to build retry loops into about everything--but Command Retry was magic & a far better solution. :slight_smile:

Also: When I try the "Set Level" command and put in a duration, I get this (it seems to work fine if I leave the duration out):

image
image1468×135 36.2 KB

And, also, when I turn the device off, even when it send the command and the device turns off, I don't see the "Switch" state change from "on" to "off" on the device page (refreshing the page doesn't help, but pressing the "Refresh" button updates it). It doesn't matter which child device I send the On/Off to, either. This makes it impossible to see the state change on dashboards, etc. when the light is turned on/off--until a manual refresh is performed.

@bobbyD @bcopeland : Any thoughts why this is happening and what to do?

ALSO: I now have a "Bond Bridge" device, a regular child device that has no states (but DOES have the off/on/level/start/refresh commands), plus another regular child device that has all those commands AND shows the state (with a "-L" suffix).

Any idea why the two devices and which I should be using?

2

I have a Bond Bridge (not a "Smart by Bond" device) for our single fan, and under the Bond parent, I have 2 child devices - one for the fan, and one for the light. Your "-L" is almost certainly the light's child.

3

Interesting.

In my case, this is ONLY a dimmable light (a wifi connected, low-voltage landscaping light controller)--I guess the app just likes creating two devices for everything? :slight_smile:

4

I'll be curious to hear what Bobby has to say, but I suspect the native Bond integration is written to primarily (if not exclusively) support fans.

I'm not sure it's built to handle other stuff (even if that other stuff is Bond-compatible), but I'd be interested to hear what staff has to say.

Though it's no longer being actively supported, you could try the community integration for giggles - I don't recall the details, but it uses a different eventstream-flow to integrate with Bond.

2 Likes
5

I prefer to not use deprecated drivers but, of course, I might end up preferring working drivers even more. lol

In any case, it seems pretty close--but just seems to be needing a few tweaks, I suspect:

  1. Command Retry (which, I believe, would necessitate the "Refresh" being issued every time).

  2. Code to either handle the "Duration" or remove the field (I believe the error indicates that the driver simply doesn't have a routine built to handle duration--even though that field is defined for the device).

6

And, there's a fatal error when Room Lighting tries to set them:

1000046776
10000467761344×2992 289 KB

7

My, hopefully temporary, workaround was to create a virtual dimmer device and a "sync" rule.

It seems to regularly need two passes to get the level set properly, but this allows me to use the working virtual dimmer in Room Lighting, etc. and use refreshes and looping to address the errors I had setting the device directly.

8

@bobbyD @support-agent

Any thoughts about this integration?

Thanks!

1 Like