I have 3 ceiling fans, all respond instantly to bond commands.
However I have 2 devices that I added as generic devices: 1) an IR speaker and 2) an RF fireplace remote. Both of these respond with ~5 sec delay after issuing a command in the app, but after the delay the blue ring flashes on the hub and the devices respond as expected.
I am using a v1 Hub and beta 2.29.2 firmware.
Just speculating, but it seems like maybe the generic devices are going through the cloud and the fans are acting locally. Is this expected behavior or could it be a bug in the beta with v1 hubs?
As far as I know based on what Bond staff said in the early days on here, generic recorded devices are always stored locally and Templated / auto-discovered devices are the ones that may or may not always be local, depending on complexity.
It’s good that you’ve noticed the Bridge’s LED blinks are delayed, not just the command.
I’m curious if anyone else has had this issue; my only (occasional) issues with my generic devices are NOT similar to yours.
Thanks for the reply, I appreciate you sharing your thoughts!
It seems like the delay I am experiencing may be due to a difference in the way templated devices are handled compared to learned generic devices. Hopefully the delay can be fixed by the devs in a future release.
I assume you refer to a 1-st Generation Bond Bridge, that is, one with a serial starting A or B, and that you are using the V2 Bond Home app.
In the 1-st generation Bridge, there’s a separate microcontroller that manages the radio, and it takes more time to load that MCU with a raw-recorded signal than with a synthesized signal as used by most templates. However, the delay should be more like 2 seconds, not 5 seconds. Note that the 2nd-generation Bond Bridges (and the Bond Bridge Pro) do not have this delay because we run everything from the WiFi SoC.
@residualimages is right: the raw-recorded devices are 100% local, and >99% of other devices are also local. We have some legacy of “cloud devices” which are still not migrated from V1 and early in the V2 system, but that would not apply to raw-recorded devices.
It could be that things got slowed down a bit in the newer firmware for the 1-st generation Bridges, but unfortunately we run into trouble firmware updating these older Bridges and so our options for continued upgrades are limited.
Sorry I cannot be of more assistance in this matter.
@merck, thank you for providing additional information and perspective, this helps me to understand how things work. And yes, I am using the 1st gen hub with BB serial number and the V2 app.
It does seem the delay increased noticeably after I updated from 2.17.4 to 2.29.2. Not a big deal, but I might consider upgrading the hub to 2nd gen or whatever is coming next (pro is overkill for me).
Ok, yeah you may consider the 2nd-generation Bond Bridge (which is what we sell on our website and Amazon when we are the official seller. Other sellers are at your own risk.) — The 2nd-generation bridge has totally redesigned electronics and firmware. It boots faster, is more reliable on WiFi, and generally is more responsive.
I went ahead and upgraded (replaced) my hardware, from 1st-gen snowbird bridge to 2nd-gen zermatt bridge. It was painless with the recently added backup/restore functionality. There is a noticeable speed improvement for learned devices and the improved wifi compatibility may be important when I upgrade my home wifi in the future.
For anyone else reading, the regression issue with the ~5sec delay in Snowbird (A/B units) firmware has been fixed in v2.29.2.1-beta firmware, now available.
