Skip to content

Extra Delay

Bond Bridge and Bond Bridge Pro can insert a pause between back-to-back radio transmissions to different devices. Raising this pause—the extra_delay setting—is the first thing to try when a device responds perfectly on its own but ignores commands sent to it as part of a group, scene, or automation.1

Availability

  • Bond Bridge (BD-1000) or Bond Bridge Pro (BD-1750) with firmware v2.19 or higher for the local API
  • Firmware v4.7.11 or higher for the setting in the Bridge web interface
  • There is no control for this in the Bond Home app—use the web interface or the local API

How It Works

The Bridge has a single sub-GHz radio, so every command it sends passes through one queue, one transmission at a time. It makes no difference whether the commands came from a group, a scene, a schedule, a voice assistant, or a third-party control system: they line up and go out in order.

After each transmission, the Bridge waits 300 ms before sending to a different device on the same frequency (within 1 MHz). extra_delay adds your value on top of that built-in gap. It does nothing for commands to a single device, repeated commands to the same device, or devices on different frequencies, so individual control stays instant.

Some RF receivers need more quiet air than 300 ms after hearing a frame addressed to a neighboring unit before they will accept the next one. In our experience rolling-code shade motors are the most common case. Until the receiver recovers, it discards perfectly valid frames addressed to it—which looks, from the outside, like a device that is deaf only in groups.

Capabilities

  • Fixes "works alone, fails in a group"—the classic symptom this setting exists for
  • Applies to every source of commands—groups, scenes, schedules, voice assistants, and local integrations all share the same queue
  • Takes effect immediately—no reboot; the next transmission uses the new value
  • Survives reboots and power loss—the value is saved to the Bridge's flash memory
  • Accepts 0 to 10,000 ms—0 restores the default behavior

Limitations

  • Bridge-wide—the delay applies to every device on the Bridge; it cannot be set per device or per technology
  • Slows groups down—every device after the first waits the built-in 300 ms plus your value, so a group of eight devices at 500 ms takes about 4 s longer to finish
  • Not a fix for range or pairing—if the device also misses commands sent to it alone, the cause is elsewhere and no delay will help
  • Splitting the group is not a substitute—two smaller groups fired back to back line up in the same queue and produce the same RF pattern as one large group

Setup Guide

Step 1: Confirm the Symptom

  1. In the Bond Home app, send a command to the affected device by itself. It should respond every time.
  2. Send the same command to the group, or run the scene, that includes it. The affected device stays put while the others respond.

If the device also fails on its own, stop here. This is a range, interference, or pairing problem, and extra delay will not change it.

Step 2: Open the Bridge Web Interface

  1. In the Bond Home app, go to Devices > Bridge Settings > Network.
  2. Tap the IP address to copy it.

  3. From a computer or phone on the same network, open:

    http://<bridge-ip>/bridge

    For example: http://192.168.1.42/bridge

  4. Under Extra Delay, enter 500, then select Save.

The new delay is saved and applies to the next transmission. The Bridge does not reboot.

Step 3: Test and Tune

  1. Send the group command again. If every device responds, you are done.
  2. If the device still misses, raise the value to 1000, then 2000, retesting after each change.
  3. Once it works, repeat the group command two or three times, then trigger the automation the customer actually uses day to day—a "good night" scene, a sunset schedule—and confirm every device responds there too.
  4. If 3000 makes no difference, set the value back to 0. The device is missing commands for another reason.

Groups Get Slower

Devices in a group now start one after another with a visible stagger. Tell the customer to expect it, and keep the value as low as works reliably. A delay that fixes the problem at 500 ms gains nothing at 3000 ms except a slower scene.

Troubleshooting

The device responds to the group only when it happens to go first. Its receiver is still recovering from the traffic sent to the devices ahead of it. Raise the extra delay as in Step 3.

Group commands from the app work, but a scene or integration still misses the device. Automations often fire every device within a second, which produces the same queued transmissions as a group, so the same delay applies. If the scene still misses, raise the value one more step.

Save fails or the API returns 400. The value is outside 0–10,000 ms.

No value makes any difference. Extra delay only helps a receiver that is being overrun by traffic for its neighbors. Check range, re-pair the device, or reset the receiver's paired-remote list and pair it again.

For Developers: Local API

The setting lives on the /v2/bridge endpoint. Read the current value:

curl \
  -H "BOND-Token: <token>" \
  http://<bridge-ip>/v2/bridge

The response includes:

{
  "extra_delay": 0
}

To change it:

curl -X PATCH \
  -H "BOND-Token: <token>" \
  -H "Content-Type: application/json" \
  -d '{"extra_delay":500}' \
  http://<bridge-ip>/v2/bridge

The value is in milliseconds and must be between 0 and 10000; anything else returns 400. The change is saved immediately, takes effect on the next transmission, and does not reboot the Bridge. Repeat the GET to verify it took.

  1. The Bridge has always waited 300 ms between transmissions to different devices on the same frequency, a workaround added in 2017 after a voice-assistant scene with two devices reliably moved only one of them. The adjustable extra_delay setting was added to the local API in firmware v2.19 (2021) and to the Bridge web interface in v4.7.11 (2024). ↩