Hello,
We run a Bluetooth Mesh network with about 1,000 nodes. Our master node (antenna) consists of:
· An MCU running Zephyr Mesh and keeping the CDB.
· An embedded host (separate processor) that talks to the MCU over UART and serves the web UI.
The master handles provisioning, configuration, and command dispatch. With many nodes, the MCU’s RAM gets saturated by the CDB (UUID, DevKey, unicast, etc.), causing severe performance degradation (long delays and slow boot), even when nodes are physically powered off.
To mitigate this, we want to offload all node data (including DevKeys) to the embedded host (which has plenty of memory) and keep the MCU lean. Operational idea:
1. The host stores the full database (DevKeys, addresses, etc.).
2. When we need to send a configuration command to node X, the host sends the MCU the unicast of X and DevKey of X.
3. On the MCU, register a short-lived CDB entry (unicast + DevKey) so that Config Client can sign/encipher properly, send the bt_mesh_cfg_cli_* messages, and then delete that entry to free RAM.
Obstacle: After deleting a node from the CDB via bt_mesh_cdb_node_del(node, true), we cannot always reuse the same unicast later to recreate that “ephemeral” node; it looks like something still marks the address as allocated unless we reboot.
Alternative idea we considered:
· Perform a bt_mesh_cdb_clear() to wipe the CDB after certain operations, and immediately recreate the minimal state (local/provisioner node, net/app keys, etc.) which we would also keep on the host.
· The goal is to keep the MCU RAM as low as possible (only the local node + ephemeral targets during operations).
We’d like to know whether this approach is viable and recommended, or if there’s a cleaner way to achieve the same result.
Specific questions:
1. Using a DevKey on demand without a full CDB entry
Is there a supported way in Zephyr for Config Client to use a DevKey provided at runtime (from the host) without creating a full CDB entry for that unicast? (e.g., a keyring hook, API to inject/update a DevKey per unicast, or a pluggable key-store backend).
2. Reusing unicast addresses without reboot
After bt_mesh_cdb_node_del(node, true), what additional steps (without reboot) ensure the same unicast becomes immediately reusable? (Do we need to force a settings flush or clear any internal allocation map?).
3. bt_mesh_cdb_clear() and immediate reconstruction
If we clear the CDB entirely and recreate the local/provisioner node, net/app keys, etc., on the fly:
· Is this safe and supported without a full stack reset?
· What’s the recommended sequence (stop bearer, clear CDB, re-init keys, enable bearer, etc.) to avoid inconsistent states?
4. Best practices for large networks on MCUs
Beyond this “ephemeral CDB” approach, would you recommend a fully external key store (akin to the serial provisioner model) so the MCU only handles the radio and the host manages all node data? If so, are there examples/guides to decouple DevKey resolution from the internal CDB?
We’d greatly appreciate any guidance or best practices to reduce MCU RAM footprint and keep stable performance with >1,000 nodes.
Thank you very much for your time and help!
Best regards.
