Posting this because I spent way too much time troubleshooting it, and I couldn’t find this documented anywhere in Behringer’s manual. Let me start by saying I love the product. Besides that, Behringer, you need to do better. If you guys hand me the source code, I could probably fix this issue in 30 minutes.

My FLOW 8 would stay connected to FLOW Mix normally, but if the app was closed or disconnected for long enough, usually a day or two, Bluetooth would eventually get stuck.

Once it happened:

• PAIR APP would fail
• PAIR AUDIO would also fail
• None of my iOS devices could connect
• The rest of the mixer continued working normally
• Physically power cycling the FLOW 8 immediately fixed Bluetooth

Firmware on mine:

FLOW 8 V11749
BT E-1.97

The workaround

Hold the MAIN button for several seconds until the FLOW 8 shuts down or enters standby. Then press MAIN again to bring it back up.

Bluetooth comes back immediately afterward.

You do not need to unplug the mixer or factory reset it.

This functionality doesn't appear to be documented in the normal FLOW 8 user guide. I ended up finding evidence for it while digging through the V11749 firmware trying to figure out why the Bluetooth stack was getting stuck.

Some references from the decrypted V11749 firmware image:

0x6960B HCI_VS_InitializeAfterHCIReset
0x6962C HCI_VS_InitializeAfterHCIReset %s
0x69751 HCITR_COMOpen
0x6976E RESET
0x697A4 RESETTING

Those are part of the Bluetooth/HCI initialization and reset code in the firmware. The image also contains separate Bluetooth pairing, A2DP/AVRCP, BLE, and controller initialization routines.

So this isn't just the FLOW Mix app refusing to reconnect. In my case, both BLE app pairing and Bluetooth audio pairing stop working at the same time, which strongly points to the FLOW 8's Bluetooth subsystem getting stuck.

TL;DR: If your FLOW 8 suddenly won't connect to FLOW Mix and PAIR APP and PAIR AUDIO both fail:

Hold MAIN --> let the mixer shut down --> press MAIN again --> pair normally.

Worked immediately on mine without wiping any settings.

The issue is a simple controller/stack stale connection state that's caused by extended BLE disconnection, combined with missing automatic BLE subsystem recovery.

Just remember that not every self hosted application has a team of experienced devs behind it ensuring security is adequate. It’s super cool to setup 15 different services/containers and configure them exactly how you want, until it comes time to maintain and update.

Every other day I see a new self hosted program that someone made in an afternoon. Usually, there’s absolutely zero security or failsafe built in if a bad actor were to target you. Also, you never know who’s an upcoming, eager developer, versus a seasoned red black-hat trying to sneak malware into your Docker stack.

There’s been countless CVEs that affect self hosted applications. And many more we haven’t discovered yet. Last week my buddy had to take his main machine offline because the application he was hosting was unknowingly working as a botnet.

You’d have to pay me a lot of money to get me to self host some shit Bob Smith vibe coded in his basement. Even if the author doesn’t have malicious intentions, you can’t expect professional, or even an acceptable level security unless there’s a real team working on the project. Even then, no one is safe.

If you’re just starting out and aren’t too sure what you’re doing, please stick with the basics until you get your footing. Hosting is fun, but you quickly get diminishing returns when you enter the phase “Damn, what else should I host?”.

With all that being said I run lots of containers, but only ones that have been tried, tested, and proven to have responsive developer(s). Good luck!

Edit: I wasn’t expecting so many technical people to show up to this thread. It truly was awesome seeing everyone’s view on this, but just remember this post was made for people who are new to self hosting or are not technically inclined. There’s many people who started from ground zero, including myself. I wish someone would have been transparent with me and actually explain why hosting anything and everything may be a bad idea in the long term.

This weekend, it wasn’t a chmod or stray cron script that took me out of commission. A lightning strike fried my firewall NIC.

What I learned: A UPS does not stop lightning. It does, however, give you a few extra seconds to appreciate the damage. Also, make sure all of your drops and cable runs are shielded.

I think I’ve graduated to advanced homelabber. Not even an act of god can keep my servers down for long.

Also, every outage is just an excuse to buy better hardware.

I’ll have 2 beers this time.

Because I have to go back and figure out how the hell I crafted the wilderness of my legacy homelab as a beginner. Usually, some random shit breaks and causes mass destruction on my Saturday night. I wish someone would’ve taught me chmod 3 years ago. I’ll have a beer and a turkey sub.

After patiently waiting months for maintainers to fix this issue, I got tired and decided to fix it myself. Basically, the whole reason that the integration 2FA login does not work anymore is because the built in iCloud integration was using an outdated pyicloud dependency. Running this script swaps it to the newest version, which is 2.6.4 from the original 2.4.1. I also threw in a rollback command (with a preemptive backup) if for whatever reason you have issues or want to rollback after the issue is fixed.

This will cause your HA instance to load a local override manifest.json in the folder /config/custom_components/icloud/manifest.json. Home Assistant normally uses /usr/src/homeassistant/homeassistant/components/icloud/manifest.json. If you update Home Assistant, the iCloud override will be persistent because it lives in /config. I recommend checkikng future update logs around the iCloud integration so once the pyicloud version is bumped you can undo the local override and go back to the built in integration.

cd /config

ts="$(date +%Y%m%d-%H%M%S)"
backup_dir="/config/backups/icloud-self-patch-$ts"
work_dir="/config/tmp-icloud-self-patch-$ts"

mkdir -p "$backup_dir" "$work_dir"

# Back up anything you might want to restore later.
for item in \
  /config/custom_components/icloud \
  /config/.storage/icloud \
  /config/.storage/core.config_entries \
  /config/.storage/core.device_registry \
  /config/.storage/core.entity_registry
do
  if [ -e "$item" ]; then
    cp -a "$item" "$backup_dir"/
  fi
done

# Copy Home Assistant's built-in iCloud integration from the running container.
docker cp homeassistant:/usr/src/homeassistant/homeassistant/components/icloud "$work_dir/icloud" || {
  echo "ERROR: Could not copy the built-in iCloud integration."
  exit 1
}

manifest="$work_dir/icloud/manifest.json"

# Make sure this is the expected iCloud integration before changing it.
grep -q '"pyicloud==2.4.1"' "$manifest" || {
  echo "ERROR: Expected pyicloud==2.4.1 was not found. Nothing was changed."
  exit 1
}

# Change the pyicloud version.
python3 - <<PY
import json
from pathlib import Path

manifest = Path("$manifest")
data = json.loads(manifest.read_text())

data["requirements"] = ["pyicloud==2.6.4"]
data["version"] = "1.0.0-local-pyicloud-2.6.4"

manifest.write_text(json.dumps(data, indent=2) + "\n")
PY

# Install the patched copy as a local Home Assistant override.
mkdir -p /config/custom_components
rm -rf /config/custom_components/icloud
cp -a "$work_dir/icloud" /config/custom_components/icloud

echo "Done."
echo "Backup saved here: $backup_dir"
echo "Restart Home Assistant Core now."



ha core restart




##Rollback if needed

rm -rf /config/custom_components/icloud
ha core restart