Advanced

Use this page when your first success path is already working and you need tighter control.

When should you use advanced patterns?

You need a custom central manager or storage implementation.
You are tuning scan/connection behavior for noisy BLE environments.
You need deterministic lifecycle control across app restarts.

Custom runtime wiring

If platform helpers are not enough, initialize the shared SDK directly:

import { MeshNetworkManager } from "@blemeshjs/sdk";

const mesh = MeshNetworkManager.instance;
mesh.init(myCentralManager, myStorage);
await mesh.setup();

✅ Best practice

Keep one long-lived manager instance. Recreating the manager frequently leads to scan race conditions and harder-to-reason state.

Scan and connection strategy

Use short, explicit scan windows and connect on user intent:

mesh.connection.scan({ timeout: 8_000, notifyOnWaitingForAdvertisements: true });

Then stop scans as soon as you have a candidate:

mesh.connection.stopScan();

⚠️ Gotcha

Running long overlapping scans across multiple screens is a common source of flaky behavior.

Provisioning strategy for production UX

Use quick(...) for fast onboarding. Move to manual connect -> identify -> start when you need stronger user confirmation of physical device identity.

Persistence and recovery

Mesh state is persistent and should be treated as critical app data.

Persist after topology changes.
Reuse the same storage backend across sessions.
Recover with setup() at startup before UI workflows begin.

💡 Pro tip

Build a startup health check that verifies BLE readiness and confirms a mesh network is present before enabling provisioning or control UI.

At this point, you should have a reliable baseline for production-grade behavior.

Next, you will want to read Troubleshooting for failure-mode playbooks.