Watchdog api endpoint and running locally

Greetings! I contacted support and was directed to post here.

I recently bought a bond bridge to control some RF fans. My IoT network is disconnected from the internet; only allowing devices through for setup when needed. The bond bridge works great with home assistant using the local api, but I found that it was rebooting and still broadcasting its wifi setup network.

When searching I found the posts:

Which both mention a future option to disable to cloud watchdog/reboot. After looking at the local api docs, I found:


Which seem to indicate that this feature was added! Unfortunately I am unable to use either endpoint; the bond bridge just gives me a 404. I am able to use other endpoints, and the /v2/sys/version endpoint returns:

{“target”:“zermatt”,“fw_ver”:“v2.28.0”,“fw_date”:“Tue Nov 2 19:07:06 UTC 2021”,“uptime_s”:248,“boot_patch”:“not first boot”,“make”:“Olibra”,“model”:“BD-1000”,“branding_profile”:“OLIBRA_BD1000”,“bondid”:“xxx”,“upgrade_http”:true,“api”:2,"_":“xxx”}

The local api docs also mentions “If enabled, Bond will reboot if not connected to Bond Cloud within first 10 minutes of boot, or if disconnected for 3 minutes.” and that any http traffic to the bond bridge resets the watchdog timer, so I created a script that sends a request to the version endpoint every 5 minutes, but the bridge still brings up the Bond Config wifi ap. It seems to bring it up very quickly as well; within 60 seconds of the device being plugged in. Are the watchdog reboot and open access point separate things?

Is there any way I can get the bond to stop broadcasting the open access point?

I haven’t messed with the endpoints, but the documentation seems incorrect.

On my ZZ device, I see the watchdog endpoint under /v2/sys/wifi/watchdog rather than directly under /v2/sys/watchdog like the documentation shows (incorrectly).

1 Like

Thanks for the tip! The endpoints were indeed accessible at /v2/sys/wifi/watchdog. PATCHing rwdg_disable to true did stop the constant rebooting, so now I can get past 600s of uptime. I also tested taking my wifi router offline, waiting a bit and then bringing it back up and the device does still reconnect successfully.

Unfortunately its still bringing up the Bond Config ap, even with the watchdog turned off :frowning: Looking at the api docs I’m not seeing anything hopeful for disabling this; the closest might be to connect via ethernet and then use the /v2/debug/wifi endpoint to shut off the wifi radio; and since that doesn’t persist past restart I’d need to make a script to monitor the state and shut it down if it popped back up. Unfortunately that requires the Bond Pro to even try, which is 4x as expensive and doesn’t support IR.

I can’t leave it broadcasting all the time as it means anyone could take over the device just by getting in range (and it’s either rebooted in the last 10 mins, or they brute force the pin). I think its fine for initial setup (and providing the hosted setup that allows me to connect it to wifi without the app was great!), but once initial setup is done even if I wasn’t trying to run local only honestly I don’t want it broadcasting and being insecure just because the internet, or bond’s server, or my wifi, etc is temporarily down. There seems to be a reset button to allow resets, which means I can reset it; that is what should have it broadcasting the wifi ap again.

Whenever one of the Bond staff get a chance to stop by the forums (@merck or @endy or others), maybe they can give an update.

If you felt comfortable going to the beta channel (I honestly don’t find it unstable or anything), I believe they were working on some of the AP broadcast scenarios in the new firmware. (See your first link in your original post)

Thanks for your post @Acorns and thanks for tagging me @residualimages !

Just discussed this with the team. Unfortunately, there is no way to prevent the AP to show up if not connected to the cloud right now.
We tested it on the Bond Bridge Pro and it also broadcasts the Config AP if the connected ETH network doesn’t have internet access.

A “total offline” operation and the reset button change (to bring back the config AP) are on our roadmap for the v3.
Good to mention that we still don’t have a timeframe for the release right now, but we’re already working on it.

1 Like

Thanks for the reply. Is the v3 new hardware, or a new software release?

Right now, “v3” is referring to a major software release. No new hardware. — And, the “v2” hardware (ZZ, ZP units) will fully support the v3 firmware and apps.

1 Like

@endy I’m having the same issue. My Bond Bridge is blocked from the internet and I’m using only the local API. This seems to be triggering it to enable and broadcast the Bond Config network, which is unwanted and unnecessary.

It sounds like the v3 firmware will provide a solution, so I wanted to find out if “total offline” mode is still in scope for v3, and if so, whether there’s any ETA on a v3 beta.


1 Like

Adding this now… will get you a beta shortly, hopefully later today.


@spercure Ok, we’ve pushed v3.3.3-beta for 2nd-gen Bridges. 1st-gen will take an hour or so to deploy. Uses API as screenshotted above. This option not exposed in the apps. Use cURL or similar.

I should mention that you still will see some DNS requests and/or attempt to get time via ntp. These will fail and your schedules will not execute when running without internet connection. We do not currently support redirecting to a local ntp server, but if you really wanted our schedules without internet to the Bridge, you could patch the time endpoint to set the unixtime manually…

That was fast, thank you! I was able to update the configuration successfully (it seems that the key is “enabled”, not “enable” like the docs say):

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

Configuration is now:

  "host": "",
  "port": 0,
  "server_cert_check": false,
  "enabled": false,
  "cert_set": false,
  "key_set": false,
  "server_cert_set": false

However, after blocking internet access, the Bond Config wifi network is still being broadcast. Do I need to restart the bridge or do something else after making the API call?

1 Like

Yes, for the api/mqtt endpoint, all settings only take effect after reboot. You could even do it programmatically via PUT sys/reboot

Thanks, fixed on our API docs.

It would help if I had read the docs more carefully. :person_facepalming:

Everything is working perfectly now. Thank you again, it’s really great to be able to manage this behavior.

@merck Do I still need to disable the watchdog service to prevent constant rebooting when MQTT is disabled?

No need to also disable the watchdog. Disabling MQTT implicitly disables the watchdog.

@merck Hm, it seems like the watchdog isn’t getting disabled automatically on my bridge. I had manually turned off the watchdog via API and just re-enabled it. 10 minutes later, my uptime_s from sys/version dropped back to 0. This also seems to have triggered the Bond Config AP to start broadcasting again.

Rebooting the bridge gets it back into the expected state, but soon after startup, the watchdog does its thing and Bond Config is back! Disabling watchdog and rebooting again keeps Bond Config turned off.

Let me know if you need any more information to help troubleshoot this.

Thanks, fixed on our API docs.

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?


@merck In additional to the watchdog issue from my last post, I’ve also noticed the blue LED ring constantly spinning with MQTT and watchdog disabled. It seems like the only thing that ring should represent in offline mode is whether the wifi connection is good. (Maybe this is on the roadmap and just not implemented yet.)

1 Like

You’re totally right. It was an oversight in me pushing this out quickly. I only tested against my bridge which had the LED ring disabled :wink: On our issue tracker now… will get it patched up.