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');
refreshUI(cloudDeviceList);
let localDeviceList = queryBondLocal(bridgeId, 'downloadDeviceList');
refreshUI(localDeviceList);
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:
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.
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.
E.g.
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).
Thanks!
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!
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.
Just set my Bond up today using local only (no internet) and hardcoding my signal transmissions with the local API to turn on some lights and fans.
I noticed that the device was trying to contact the cloud server and was still broadcasting the Wifi SSID. I realize this is to prevent locking yourself out of the device, but I don’t necessarily want to connect this device to the internet or have an unsecured SSID being broadcasted 24/7.
I saw dxdc mentioned in this thread that a command to disable the wifi hotspot if the Bond is being used for local only would be useful. Has something like this been implemented in any beta releases to date? Is there a plan to implement some way to disable the wifi broadcasting? Maybe a setting to only broadcast the SSID immediately after the device is powered on?
Thanks
@new_bond_user have you tried the various wifi settings in the API docs?
http://docs-local.appbond.com/#tag/Wi-Fi-Watchdog/paths/~1v2~1sys~1wifi~1watchdog/get
We haven’t yet gotten around to specifying all the details or implementing it, but yes, a “local only” feature is on our wishlist.
And yes, suppressing the AP broadcast would be one of the two big components of that feature. (The other being suppressing the watchdog reboot) It’d probably only broadcast its access point if it’s unable to associate with the configured WiFi. Currently, as you pointed out, it looks for a connection with our cloud.
So I just had this very same thing start happening this week - ZZ series, v2.4.15. It only seems to resolve with a reboot of the Bond Bridge; the thing that tipped me off is that Alexa wasn’t able to control it, but I could control it through the Bond app.
Is there a good way for me to troubleshoot this?
For the record, it seems like it’s connected to WiFi just fine, and seems to be sending traffic according to my router.
Yeah mine does the same, if I reboot it will go away but will just present itself again down the line. +1 for a resolving this in future updates.
I have the same issue with GH. I thought it was linked to a dropped internet connection… I have also had the first command with GH fail, but the second work, not sure if it’s related…
@borski and @sburke781 - are you meaning for your replies to be in the Google Home / Alexa not working thread?
Or are your posts somehow related to this thread, about the Bond Bridge setup network / WiFi SSID being visible?
They are related. When Alexa stops being able to control it, the open config SSID is broadcasted, all the while I can control it from my phone still.
I was mostly wanting to indicate I was seeing similar behaviour, though in a different product in GH, and was speculating that perhaps the issues were related. I have logged a similar thread myself noting down some of my experiences, but haven’t had time to finish testing different options.