BOND Wifi Hotspot is still visible?

Running v2.10.8-beta firmware on my Bond. Strangely, in my Wifi settings, I still see the SSID for the Bond Config hotspot.

As long as Bond is connected and set up for a user’s SSID – the native Bond Wifi hotspot should be turned off for security reasons.

The hotspot reappears if Bond is unable to connect to the Bond Cloud (MQTT). Is it possible you’re on WiFi but the cloud connection is not there? Symptom would be no control of Bridge from a phone on mobile data only.

@merck thanks for the speedy reply. You’re exactly right! I unplugged the BOND device and rebooted it and it worked fine after that.

It seems like the Bond is not recovering well from network outages (from the ISP; not a power outage). Maybe it doesn’t keep checking for cloud access periodically after a network failure?

Also, probably worth adding a command to disable the Wifi hotspot if Bond is being used in local-only mode. This could even be an API command.

Lastly, this also fixed a “bug” that I saw in the latest iOS beta app where my device list was out of sync. It would populate with an “old” list of devices on start up and finally refresh with the “new” list. So, I realized this is what must have been happening in the background:

let cloudDeviceList = queryBondCloud(bridgeId, 'downloadDeviceList');
let localDeviceList = queryBondLocal(bridgeId, 'downloadDeviceList');

This approach leads to the out-of-sync errors I was seeing as well. Also, it was never obvious within the app that my device wasn’t connected to the Bond Cloud. I would suggest a possible revision to the logic to address these issues, as follows.

let localDeviceList = [];
let cloudDeviceList = [];
let updatedUI = false; 

if (queryBondCloud(bridgeId, 'doesLocalDeviceHaveMqtt')) {
    cloudDeviceList = queryBondCloud(bridgeId, 'downloadDeviceList');
    updatedUI = refreshUI(cloudDeviceList);

if (userHasActiveWifiConnection()) {
    localDeviceList = queryBondLocal(bridgeId, 'downloadDeviceList');
    if (!deviceListIsEqual(localDeviceList, cloudDeviceList)) {
        updatedUI = refreshUI(localDeviceList);

        // Let the bridge decide whether or not it should update
        // Bond Cloud (based on active MQTT)
        queryBondLocal(bridgeId, 'sendDeviceListToBondCloud'); // send async

if (!updatedUI) {
    refreshUIShowError("Can't connect to Bond bridge!");

@dxdc Whoah, thanks for the suggestions in such clear pseudo-code!

However, there’s two things going on in the background though which you didn’t take into account in your analysis since you had no way to know about them:

  1. Bond Home app communicates with the hardware over the “Local” API both via HTTP and via MQTT simultaneously. Requests have UUIDs which the hardware uses to de-duplicate requests. So, from the high-level perspective, there’s no difference between “local” and “remote” communications with the Bond Bridge.

  2. There’s a concept of the app syncing with the Bond Cloud to get a list of devices, which is happening prior to syncing with the hardware. This is intended as an optimization.

It would seem that you’re seeing a conflict between the info provided by path #1 and path #2. We’ve seen this once before, and will take your case into consideration. @marcio

Re: original issue with WiFi hotspot, can you send me the first 4x digits of your Bond ID (serial number)? That will let us figure out what WiFi stack you are on.

Clever. The only issue that I can forsee with this kind of approach are race conditions, since the device doesn’t necessarily know the order that the events arrive. While it will ignore duplicate UUID, these requests can come out of order due to latency differences.


  • Req #UUID 1 sent (local)
  • Req #UUID 2 sent (local)
  • Req #UUID 3 sent (remote)

This could be received by the user’s device as 1, 3, 2 and cause things to get off-sync. In fact, it could (in theory) also be received by the device as 2, 1, 3.

One (potential) way to deal with this - if you aren’t already handling this case - is to implement a kind of “rolling code” technology where the UUID’s are incremented in a specific way so that the device knows whether any prior requests were sent (and are missing). If so, it could wait for a short timeout (e.g., 300 ms) to receive any other queued commands. If that doesn’t happen, it should still run the received command, but then ignore any other commands send before that one as well.

(NOTE: The above approach should be run on a per-device basis; not globally. So the UUID could be bondBridgeId-deviceId-.... for example).


I’m sure this isn’t an issue for most people, but it’s just in the case that a user connects their device to Bond Cloud but then later their device loses access (as mine did). Another simple optimization though would be to store the device list locally on the user’s phone (in the iPhone cache). That seems more straightforward since it would reflect the state that the user last expected.

Re: original issue with WiFi hotspot, can you send me the first 4x digits of your Bond ID (serial number)? That will let us figure out what WiFi stack you are on.

Sure: BH3079

For requests where order of operation is important, we just chain on the reply from the previous request. Works quite well! It is however quite important to have proper mutexes on the firmware. Those nearly-simultaneous requests over MQTT+HTTP give the multithreading a workout!

1 Like

@jacob is @dxdc’s problem a known issue on the Snowbird stack?

It was a previously-open issue, but I thought I successfully closed it months ago. It’s pretty easy to simulate an outage, I’ll give it a shot and see if I can reproduce it tomorrow.

Side note: It seems I’m not getting notifications for posts in this Beta category, and not seeing unread/new counts for posts in the category when I check the forums… I think something’s off with the configuration?

Apparently Discourse re-muted all Beta categories for me… I think I’ve been missing out on a lot of posts!

I haven’t yet been able to reproduce this.

Strangely, it normally works fine for me (after an outage) so not 100% sure the cause.