Bond Bridge Pro v3.12-beta

[merck]

This firmware includes important bugfixes detailed below. Stable version for BD-1000 (2nd-gen) and BD-1750 are slated for this Wednesday. So this beta is only for people facing either of these two issues and needing to solve it immediately.

• RFMan: fix out-of-order signal bug by @chrismerck in #1798 — This was impacting some “sequence-based” ceiling fans, and perhaps some shades. Contact @guyzaltus for details on which templates were impacted. Problem introduced in v3.8.4.
• Sidekick: adds support for recent Sidekick Scene Keypads, which previously would not be able to be added. They would not succeed on the Sidekick learn screen.

We have also added support for several new shade technologies in this firmware, which we will be announcing soon.

[residualimages]

Something seems weird now with the existing 8-scene-mode Sidekicks I have.
Not 100% sure if it is the firmware’s fault, or some other early adopter gremlin – but the app showed the two Sidekicks in “unknown” mode before Pro’s firmware update; after update, it shows them in “5 shade channels” mode, but my BPUP listener (and @kingwr 's Nodeserver) both now fail to “hear” button presses.
Tried the MENU → 5124 {STOP} code, and only the STOP LED flashes after that.

UPDATE / ADDITIONAL DETAILS:
from the CLI “livelog”, here are some sample outputs during key presses of Sidekick:

python bond livelog
←[1m  13283640:        BondSync:763  : USER : RX SHxxxxxxxx keystr keymap=0001 config=8 action=TAP ms=0 seq=297 rssi=157 RR=0 BL=2845 BH=2990 ←[0m
←[1m  13286282:        BondSync:763  : USER : RX SHxxxxxxxx keystr keymap=0002 config=8 action=HOLD_START ms=0 seq=298 rssi=156 RR=0 BL=2835 BH=2985 ←[0m
←[1m  13286333:        BondSync:763  : USER : RX SHxxxxxxxx keystr keymap=0002 config=8 action=HOLD_END ms=204 seq=299 rssi=156 RR=0 BL=2835 BH=2985 ←[0m
←[1m  13287471:        BondSync:763  : USER : RX SHxxxxxxxx keystr keymap=0004 config=8 action=TAP ms=0 seq=300 rssi=152 RR=0 BL=2835 BH=2985 ←[0m
←[1m  13288241:        BondSync:763  : USER : RX SHxxxxxxxx keystr keymap=0008 config=8 action=TAP ms=0 seq=301 rssi=150 RR=0 BL=2835 BH=2985 ←[0m
←[1m  13289013:        BondSync:763  : USER : RX SHxxxxxxxx keystr keymap=0010 config=8 action=TAP ms=0 seq=302 rssi=146 RR=0 BL=2835 BH=2985 ←[0m
←[1m  13289885:        BondSync:763  : USER : RX SHxxxxxxxx keystr keymap=0020 config=8 action=TAP ms=0 seq=303 rssi=141 RR=0 BL=2835 BH=2985 ←[0m
←[1m  13293354:        BondSync:763  : USER : RX SHxxxxxxxx keystr keymap=0001 config=8 action=DOUBLE_TAP ms=0 seq=304 rssi=145 RR=0 BL=2795 BH=2980 ←[0m

[merck]

Thanks for the report, @residualimages. Sounds like we missed a migration for the mode. (Maybe?)

We will check into this quickly.

[merck]

Nevermind, the mode (config) is showing right there on your screen. — Will setup this migration test and let you know.

[residualimages]

Whatever the gremlin is, it really seems as if keystream events aren’t being pushed to a subscribed BPUP address?

I still receive correct responses from ‘keepalive’ packets, and I do receive other BPUP events from actions I take in the Bond app…
But no BPUP packets are received when I press / hold / release / double tap Sidekick remotes.

Now, I’m not sure if that’s based on what mode the Sidekick thinks its in (even though CLI says config=8), or something about my early adopter syndrome causing issues within the Pro / Sidekick association (though they show in the Bond app with a signal strength and battery state). The Sidekicks do both show as “firmware unknown”, if that is of interest.
Originally, I had been able to pair the Sidekicks (per the printed instructions) within the Bond app after putting them into 8-button scene mode, despite receiving them in Shade packaging. The bullet point #2 from your first post in this thread seems to indicate something was at least sometimes difficult or impossible to pair in that mode, but I personally never experienced difficulties on previous firmware.

[residualimages]

If I use cURL instead of the CLI tool, I see these nodes - indicating a mode of 0, a keys of 0, and a firmware of null?
All of this is just to help you spot anything weird and/or replicate my migration to 3.12-beta from whatever state I got myself into before 3.12-beta (I know I was on 3.8.4-beta for a majority of my initial Sidekick config, not sure if I got on one in between that and 3.12-beta but I assume it’s likely).

{"__modified":"1675529808","name":"SHxxxxxxxx_Wall","location":"Virtual","mode":0,"keys":0,"chans":5,"techs":[240,240,240,240,240],"chan_links":{"1":[],"2":[],"3":[],"4":[],"5":[]},"key_links":{},"signal":100,"battery":100,"model":"SKS-500","fw_ver":null,"_":"230c8d58","__":"8a1d5e09","keystream":{"_":"00000000"}}

and

{"__modified":"1671655442","name":"SHxxxxxxxx","location":"Virtual","mode":0,"keys":0,"chans":5,"techs":[240,240,240,240,240],"chan_links":{"1":[],"2":[],"3":[],"4":[],"5":[]},"key_links":{},"signal":100,"battery":100,"model":"SKS-500","fw_ver":null,"_":"230c8d58","__":"8a1d5e09","keystream":{"_":"00000000"}}

[Superbean]

Ugh. When will we see ceiling fan control via HomeKit?

[residualimages]

@Superbean

When will we see ceiling fan control via HomeKit?

@endy mentioned about 30 days ago that there was no official timeline yet for ceiling fan support natively in Homekit, but that there were a couple workarounds available in the meantime that some community members were pursuing with pretty good success (HomeAssistant and/or Siri Shortcuts):

HomeKit on Beta!

@JazJonFL Thanks for reporting! Just requested Apple’s review for a new public beta build. Should be available in TestFlight in some hours (or day - Apple sometimes surprises us). @sarsonuk There is no timeframe for it to be official yet. We may work on some improvements in the following months, but not sure that we’ll make it stable enough to “get it out of beta” and support ceiling fans too. In the meantime, @JazJonFL was able to integrate ceiling fans into the Home app’s routines using t…

[merck]

Thanks for the reports. We found one migration issue for Sidekicks linked to shades, but we’ve not yet found the issue you are facing with simply upgrading a Sidekick used as a scene keypad. I’m guessing your Sidekick unit has some earlier firmware. Try tapping the menu button, or holding the 1 button and then recheck the API for the fw_ver to populate. If that fails, try removing and readding the Sidekick to the BBP.

[residualimages]

@merck

Try tapping the menu button, or holding the 1 button and then recheck the API for the fw_ver to populate. If that fails, try removing and readding the Sidekick to the BBP.

Thanks, Chris.
Neither tapping menu button nor holding “1” for 3 seconds worked.
Today for some reason, the Sidekick did allow me to do MENU → 5124 {STOP} and the 5124 played back (unlike previous recent attempts, but like it did during initial setup).
Still, via an API call the mode is still 0, keys is still 0, the chans is 5, techs looks to have an array, chan_links looks to have an array, key_links is null, firmware is “null”, and the keystream attribute seemed null-ish:
{"__modified":"1675529808","name":"SHxxxxxxxx_Wall","location":"Virtual","mode":0,"keys":0,"chans":5,"techs":[240,240,240,240,240],"chan_links":{"1":[],"2":[],"3":[],"4":[],"5":[]},"key_links":{},"signal":100,"battery":100,"model":"SKS-500","fw_ver":null,"_":"230c8d58","__":"8a1d5e09","keystream":{"_":"00000000"}}
Verified BPUP was still not sending keystream events.

So via the Bond app, I did the remove Sidekick, then re-added (including holding the “1” button on the same Sidekick).
Now the Bond app shows, for that Sidekick: Mode unsupported – your Sidekick is set to 8 scene keys mode, which is not supported on the app for now, but it will be in the near future. But rest assured that you can still use it with third-party integrations.
BPUP keystream events now seem to be being sent without issue. Hurray!
And now an API call shows what I assume to be a correct mode of 8, keys of 8, the chans is now 0, techs now has an empty array, chan_links now has an empty array, key_links is now populated with an array of 8, firmware is still “null”, and the keystream attribute seems less null:
{"__modified":"1677764796","name":"SHxxxxxxxx_Wall","location":"Virtual","mode":8,"keys":8,"chans":0,"techs":[],"chan_links":{},"key_links":{"1":[],"2":[],"3":[],"4":[],"5":[],"6":[],"7":[],"8":[]},"signal":100,"battery":100,"model":"SKS-500","fw_ver":null,"_":"4a127e33","__":"cfab7a90","keystream":{"_":"130302d0"}}

I did leave the other Sidekick in the “broken” state, in case you want to do any additional troubleshooting.

[merck]

We just released v3.12.6 for all Bridges (except 1st-gen).

In particular, this fixes the problem where Sidekicks on BBP were not being properly migrated. If you have re-added Sidekicks after the beta, you may see the old Sidekick appear after the upgrade, causing duplicates.

[residualimages]

Guessing that’s on Stable channel, not Beta?

[merck]

Indeed, v3.12.6 is on stable. Beta is unchanged. (Should we always update the beta to same version as stable?)

[residualimages]

I’d welcome other opinions, but I think it makes the most sense to me to keep beta at or ahead of stable?

[merck]

OK I just pushed the beta also. — The possibly confusing thing is that v3.12.6-beta and v3.12.6 are exactly the same firmware other than the version number. But I agree it makes sense to keep the beta at or ahead of stable so that users can stay on the “beta channel” and not have to magically know to switch to “stable channel” when a stable (but not beta) update is released.

[KMDonlon]

I agree with residualimages on keeping the beta version number ahead of the stable releases.