Watchdog api endpoint and running locally

[merck]

@spercure

It was previously mentioned that the docs also have the endpoint for the watchdog endpoint incorrect, as it’s actually /v2/sys/wifi/watchdog, not sys/watchdog. Could this be fixed as well?

Tnx for reporting, and tnx @endy for fixing the docs.

@spercure

I’ve also noticed the blue LED ring constantly spinning with MQTT and watchdog disabled.

Ok, we (again @endy) have a fix for this available now in v3.3.7-beta for all (yes, all) Bridges.

Still checking into the reported issue where watchdog is not properly disabled by the api/mqtt.enable=false.

[spercure]

@merck Thanks for the update! I’ve upgraded to v3.3.7-beta and the blue light still spins when I block the bridge at the router. Is this expected behavior?

[merck]

@spercure

the blue light still spins when I block the bridge at the router. Is this expected behavior?

Well… we discovered that the api/mqtt.enabled field is messy. What you actually need to do is

curl -i http://<bridge>/v2/api/mqtt -H "BOND-Token: <token>" -X PATCH -d '{"enable": false}'

And you will see:

{
  ...
  "enabled": true
}

Then reboot. It will still say enabled: true but this is actually disabled. We are fixing the polarity of the field and the typo for next beta. But this should get you going.

[spercure]

@merck

What you actually need to do is

curl -i http://<bridge>/v2/api/mqtt -H "BOND-Token: <token>" -X PATCH -d '{"enable": false}'

Then reboot.

That’s exactly what I’ve been doing, and the blue light still spins when I block the bridge from the internet.

@merck

It will still say enabled: true but this is actually disabled.

Interestingly, it says enabled: false for me after the reboot.

[merck]

I know, that was very confusing. Anyways, in the v3.3.8 firmware (available now in stable channel), we fixed this issue.

[spercure]

@merck I can confirm that my issues seem to be resolved by 3.3.8:

• The blue light stays off and does not start spinning when the bridge is blocked at the router.
• Leaving watchdog enabled no longer causes the bridge to reboot or the Bond Config network to start broadcasting when MQTT is disabled.

Things are looking good. Thanks again for getting this implemented!

[endy]

Hey!

Would like to check with you all the desired behavior of the Config AP on a specific case.

In the event that Bond can’t connect to the Wi-Fi network (because of a SSID/Password wrong/changed, router shuts down, get out of the Wi-Fi range, etc), the Config AP should broadcast or not?

Right now it doesn’t broadcast, as the documentation says:

[Added in v3.3.3] If true (default), Bond will attempt MQTT connection. If MQTT connection fails, Bond becomes discoverable again via Config AP. If false, Bond will not attempt MQTT connection and Config AP will remain deactivated.

I’m asking because I faced this (took my office Bond to my home to work remotely some days) and would like to know what you think and want for the feature.

Thanks in advance!

[spercure]

@endy I can definitely see how the config network can be useful even with MQTT disabled. My preference would be that the config network only be broadcast if the bridge can’t connect to wifi within 5 minutes of bootup. Requiring a power cycle makes it an intentional action and would satisfy the scenario of moving the bridge between locations without having it become reconfigurable just because the wifi is temporarily down.

[merck]

@spercure

satisfy the scenario of moving the bridge between locations

Thanks for the feedback.

Actually this scenario can be already handled by performing a Wi-Fi Reset aka “Green reset”, where you hold down the setup button until the LED ring goes solid green then release. Only the network settings are erased, and the Config network re-appears.

@endy I think we can handle the expectation here by calling this an “Offline Mode”, with the expectation that Wi-Fi and/or internet connections will be unstable, and users do not want their devices rebooting (watchdog) or becoming discoverable (Config AP).

Lastly, for any security conscious users reading, we understand the concern that the Config AP reappearing after a Wi-Fi/Internet connection failure may be a security concern. For this reason, when the Config AP re-appears more than 10 minutes after power cycle, the PIN number is required before the Bond can be set up on a new account.

[y8yPE6AM]

Hello everyone,

I have the same problem described above

• I have a Bond Bridge that is Connected to my NoT Wifi with v3.8.4
• This Network has no internet action.
• I control Bond Bridge through Hubitat (irrelevant I think)

The Bond Bridge works correctly but:

• The light is Spinning blue which indicates connecting to Bond cloud.
• The Bond Bridge Wifi is broadcasting - I guess to help me connect to it

From above I read that the setting needs to be disabled through API. Is that still the only way to do it or is there a setting I can change somewhere?

Thanks

[cal]

I have the same situation (3.8.4, no internet, Hubitat, Bond works correct but with spinning blue light), and thus the same question as @y8yPE6AM

Also, if this the only way to do this is to access the API, how does one access the API??

Are there step by step instructions for both accessing the API and for what to edit once you access it?

Thanks

[residualimages]

Hello @cal –

Accessing the API is done with a computer (Mac, Windows, 'nix) and a command line / terminal.
You will need some information from the Bond Bridge (which you can find in the Bond app) and have your computer connected to the same network as the Bond Bridge (whether or not is has internet).

In the computer’s command line, you will put a variation of this command:
curl -i http://< bridge >/v2/api/mqtt -H "BOND-Token: < token >" -X PATCH -d '{"enable": false}'

You will have to replace < bridge > with the IP address of your Bond Bridge, and the < token > with your “local token”; both of these are visible in the BOND app under the Bridge’s Settings page (expand advanced to see Local Token, and you can also tap Network Info from there to see the IP address).

Also, depending on Mac vs Windows vs 'nix computers / command line / terminals, you may have to mess with the " or ’ after -d above, so that it properly formats the string of data.
If all of that gets you started down the right path, good!
If not, please let us know where you got lost.

[y8yPE6AM]

Hello again,

Run the command now, but the blue light is still there.

Here is the response I got from the command

HTTP/1.1 200 OK
BOND-Flags: 4
Content-Length: 151
Content-Type: application/json; charset=utf-8

{“host”:“”,“port”:0,“server_cert_check”:false,“enabled”:true,“cert_set”:false,“key_set”:false,“server_cert_set”:false,“_”:“e27e11af”,“__”:“e27e11af”}

Can you please check and let me know if you see something I missed here?

[cal]

Thank you for the detailed instructions. Appreciated.

I see that @y8yPE6AM reports making this change, but that “the blue light is still there.” By this I presume @y8yPE6AM means the blue light on the Bond is still blinking/spinning after making the change.
Although the instructions are clear, I’m somewhat reluctant to start doing things I really don’t understand. My entire reason for making the change is to stop the blinking/spinning bue light, and if the change does not do that, I won’t mess around with something I don’t understand.

So…

1. Has anyone else tested and can confirm making this command line change stops the blue light blinking/spinning? Can you also confirm that after the change you can still use the app to adjust the intensity/brightness of what I presume is now a solid blue light?
2. Any word from Bond on if / when they might add capability to the app to indicate the Bond should work offline?

[y8yPE6AM]

I confirm. Blue light is still blinking

[spercure]

When I change the MQTT setting on my bridge, I use enabled (with a d at the end), not enable as suggested above. The API Docs also say the name of the setting is “enabled”.

So the command would be:

curl -i http://< bridge >/v2/api/mqtt -H "BOND-Token: < token >" -X PATCH -d '{"enabled": false}'

After changing the setting, the bridge should also be rebooted:

curl -i http://< bridge >/v2/sys/reboot -X PUT -d '{"_token": "< token >"}' --max-time 5

[y8yPE6AM]

Hey @residualimages / @merck . Problem persists here even with latest version of software. Can you please have a look and help us fix?

[spercure]

Did you try the corrected commands I posted? The last API response you provided showed enabled = true instead of false, like it should be.

[y8yPE6AM]

• I did everything around April where my last post was and it did not solve the problem.

-Was expecting/hoping that with updates it would be solved - it didnt

• Tried again everything today, and it seems to have worked. Lets hope it remains

Thank you

[spercure]

Glad that worked!

For anyone visiting this thread in the future, please refer to this post for the correct commands to put your bridge in offline mode, disable MQTT and the Watchdog service, and prevent the blue light from spinning.

Some of the early posts in this thread incorrectly specify the use of enable instead of enabled.