Bond Bridge requires reboot to re-enable Google Home commands

I’ve setup multiple Select Blind shades which can all be controlled without issue through the Bond app. I enabled the integration with Google Home and can see all of my blinds in the Google Home app. The current open/close status of the blinds appears to always work. Shortly after closing the blinds via the Bond app, the Google Home app shows the updated status.

What periodically breaks is the Google Home app’s ability to send the open/close command. Tapping open or close will just result in a toast saying something went wrong.

The integration remains in this state across relinking of the Bond integration, refreshing the list of devices, using another phone with the Google Home app, etc.

The only fix appears to be to reboot the Bond Bridge device by unplugging it for a minute.

I don’t know what causes this, but it appears to be in the Google → Bond direction but not the Bond → Google direction. And again, the Bond app → Bridge commands work fine.

All I can think of here is that, for some reason your Bridge may be losing its internet connection. Our Google Home integration works like this:

GH Cloud ----HTTPS----> Bond Cloud ----MQTT/TLS---> Bond Bridge

But the app works both like this:

Bond App ----MQTT/TLS----> Bond Cloud ----MQTT/TLS---> Bond Bridge

and like this at the same time:

Bond App ----HTTP---> Bond Bridge

So my hypothesis is that your unit is losing the MQTT connection, but it is still on the local network so it still responds to the app when your phone is on the local network.

You can test this hypothesis by turning off Wifi from your phone to force the communication via MQTT over the cellular data network. See if the Bond Home app can still operate the Bridge during the GH outage.

The problem reoccurred in the Google Home app and the behavior is exactly as you described. The Bond app also failed to control the shades when I was disconnected from WiFi*.

The other thing I noticed was my scheduled close didn’t occur on time, but instead instantly triggered when I came home afterwards and my phone connected to WiFi. Just wondering, but what if I were gone for a week while in this state? Would the app be smart enough to collapse 14 open/close pairs to just the latest state? Or would it play all scheduled events in quick succession since other devices are more complicated than open/closed?

My current network is a Starlink dish with their modem acting as an AP. I’m about to replace that with Ubiquiti gear; we’ll see if it reoccurs with that setup.

*When this happened, the Android app displayed a long toast that was truncated about ensuring the Bond Bridge was connected to WiFi. I have my font and size settings set to defaults.

OK, great. So we know it’s at least problem with the Bridge staying connected to MQTT.

The Bond Bridge has a real time clock, but no backup battery. So if disconnected from the Internet, after the next reboot (which occurs every 10 minutes if the cloud connection drops), then it will be unable to run schedules because it cannot reach the ntp pool to get the current time.


During this outage, what’s going on with the Bond Bridge’s light ring? Is it spinning blue (IP, no MQTT connection) or solid orange (failed to get or lost IP).

This is also a recurring problem for me. Any ideas why it’s started all of a sudden?

Edit to add, light on bridge is solid blue.

I’ve completely rebuilt my network. The Starlink router is in bridge mode and there are now 2 Ubiquiti APs and a new switch connecting them. The Bond Bridge still has the same behavior where after about a day, it’ll lose the connection and only respond to the Bond app when the phone is connected to the local WiFi.

During the outage the ring is a solid blue.

Odd. I would expect that if the MQTT connection was dropping that you would get a spinning blue light ring, or at least that is what is supposed to happen. I do note that it takes ~3 min for the ring to start spinning after losing the connection.

If you have a Bond Bridge Pro, it would be possible to capture some logs that may shed light. We have a way to get UDP-based logs locally with BD-1000 but currently it has an issue that prevents using it here.

Are you guys sure that the light ring doesn’t spin blue when it is in the state of works-locally-but-not-from-internet?

I just reconfirmed everything. The bridge has been in this state for many days and the ring has been solid blue every time I’ve looked at it.

Perhaps the connection is “open” but otherwise broken in a way it doesn’t realize. The Starlink dish does periodically reboot to install updates (but all service is restored quickly for everything else, including a variety of Nest and MyQ IoT devices).

Not sure if this is related, my widgets stop working along with Google home… Just happened after working fine for a while then just breaks. Will try a reboot on my end to see if this fixes the issue

Confirmed, a reboot corrected my widgets and Google home functions

1 Like

You’ve discovered the fact that the widgets do not work locally. Unlike the app which works via both local network HTTP and via cloud MQTT, the widgets use an HTTPS API to our cloud. You notice the difference only when the Bridge drops off MQTT so it no longer is receiving commands from the broker.

So, we will do what we can to look out for the root cause of this pattern of connectivity loss, and as we look at new iOS widgets (required by iOS 18) we will see if we can make them use the dual-transport technique that we employ on the main app.

1 Like

Appreciate that, it does seem to be a fairly recent issue… Perhaps on the last few betas… have had my unit for several years and never experienced this prior.