V3.2.4-beta for Smart by Bond

BETA
1

We are proud to release today a beta version of v3 firmware for Smart by Bond ceiling fans and smart lighting products from our partner brands.

What’s New

The major new feature in v3 is Groups, native in the Bond Home app.

Smart by Bond fans and lights can be combined together into groups and controlled from a new “Groups” tab in the Bond Home app.

Scheduling Groups is not something currently supported, but coming soon :wink: .

API Changes

Please see this other post for details on the API changes:

2 Likes
2

Everything seems to be working fine for me. Still have a few that needed a power cycle and update at few times to get them past 89% but they did eventually update.

3

Has a version for the BD-1000 2nd generation been released yet?

1 Like
4

Just in case I missed it, was there an api added to get all the states from a single endpoint?

Why I’m asking…. when Home Assistant restarts it has to do an initial sync to get the states after it starts BPUP to get the current state. Polling for each of those devices takes a while when there are many devices which delays startup.

Maybe there is a better way?

5

We have not added such an endpoint.

What I think you are asking for

I imagine you are thinking of something like:

devices/00112233/state ==>

{"open":0,"position":0,"_":"fc9a5b5d","__":"fc9a5b5d"}

devices/_all/state ==>

{
  "00112233":{"open":0,"position":0,"_":"fc9a5b5d","__":"fc9a5b5d"},
  "44556677":{"open":1,"position":42,"_":"020f020f","__":"020f020f"},
  ...
}

This is of course theoretically possible, but there’s a couple issues:

  1. content length limit of 8000 bytes that we currently impose on Bond request (and response) bodies.
  2. integrations would need to be updated to understand any of these _all topics.

What I propose

Perhaps a compromise would be a way to do a GET against a wildcard topic, via BPUP. Then you could do something like:

BPUP GET topic=devices/+/state

And what this actually does is, triggers the Bridge to respond, over BPUP with n messages, one for each device, on the original topics.

So this way, no new parsing needs to happen on the HA side. You’d just need to add a single line to your startup code and then your current callbacks would handle all the states. It’s a bit verbose, but hey it’s better than having to poll all those HTTP calls.

LMK what you think.

We’ve got a lot on our plates, but making things easier for control-system integrators is high priority over here, so we could squeeze this in.

1 Like
6

I think that will work. We should know when its complete by checking we got one for every device. I realized we probably need BPUP GET topic=devices/+/properties as well since we poll both endpoints at startup.

Edit: so we actually hit 3 endpoints per device /v2/devices/{device_id} /v2/devices/{device_id}/state /v2/devices/{device_id}/properties

We have a Semaphore to rate limit the number of requests to the bond device to prevent timeouts

7

Not yet. But I think this is the week :thinking:

1 Like
8

So it turns out we can cut the startup time in half without any api changes

It would still be nice to reduce the request overhead, but I wouldn’t rush to squeeze it in as its likely diminishing returns at this point.

Thanks for engaging on the topic as it got me thinking on how to improve it with the existing constraints.

2 Likes