Add available_ble_devices() method

[lukipuki]

Summary
The available_ble_devices() is requested by many users to detect BLE devices running Meshtastic.

Also refactored BleHandler:

• added available_peripherals method, factoring out logic out of BleHandler::find_ble_radio.
• added comments
• added BleDevice struct with name (optional) and MAC address

Related Issues
#32

Checklist

• Tests pass locally
• Documentation updated if needed

[andrewdavidmackenzie]

Need to make public the BleDevice struct, in the stream module like BleId?

[lukipuki]

Need to make public the BleDevice struct, in the stream module like BleId?

Made it public, also added Clone and Eq.

[andrewdavidmackenzie]

Could I request Debug too please? 🙏

[lukipuki]

Done

[andrewdavidmackenzie]

BleId implemented from_name(). WOuld be useful here too, I think not available?

[lukipuki]

Doesn't this work?

if let Some(name) = ble_device.name {
    let ble_id = BleId::from_name(&name);
}

We can add more convenience functions, but right now I want to focus on core functionality. I can add more in followup PRs.

[lukipuki]

The implemented From<BDaddr> suggests how it's supposed to be used (ble_device.mac_address.into()), using the name is only more fragile than a MAC address which is unique.

[andrewdavidmackenzie]

Were you thinking about keeping BleId?

The following methods in ble_handler.rs still use it, such as:

• new()
• find_ble_radio()

plus build_ble_stream in utils.

It would be cleaner for the client that discovers devices, and then connects to one of them if it could use the discovered BleDevice to build_ble_stream(). Meanwhile I use utils::stream::build_ble_stream(&device.mac_address.into()...

====

Unrelated, but I am saving the last device I connected to in a file, and re-connecting on start-up. For that I user serde of a struct containing BleId/BleDevice.

I can understand if you don't want to derive Serialize and Deserialize on BleDevice. But if you did, it would save me some code to implement that one way or another. I was trying to save just the BDAddr in the file (as guaranteed to always be there) but that type is not public?

[lukipuki]

The discussion in the original PR #66 concluded that a larger BleId enum, which simulated both the current BleId and BleDevice at the same time, was not convenient to use. Hence the current split.

There'll be users wanting to refer to devices using a MAC address and using a name. This is common for meshtastic tooling, e.g. meshtastic --ble <arg> takes both a name and a MAC address. build_ble_stream mimics that. Hence I'd keep BleId too.

We could add a convenience function taking in BleDevice directly, but let's do it in a followup PR.

[lukipuki]

I think we can:

• Add From<BleDevice> for BleId which would call ble_device.mac_address.into()
• Then change build_ble_stream() to accept any T: Into<BleId>, so both BleId and BleDevice would work as parameters

I will do this in a followup.

[andrewdavidmackenzie]

I think that's fine.

Either that or use only BleDevice() (easy to create one with just a mac), and then build_ble_stream() uses BleDevice, and only uses the mac field of it?

[andrewdavidmackenzie]

The trouble I am having is impedence matching:

• a list of BleDevices discovered (have MAC for sure, maybe have Name)

• with a UI/file/CLI selection based on name

I think my only way out is to:

• serialize to file with MAC at least and optional Name
• deserialize from file back to BleDevice (from MAC) and then find it in the discovered devices.

So, either I:

• serialize BleDevice directly (handy if it derived Serialize, Deserialize)
• serialize the BDAddr field only manually (need that type public, and handy if it derived Serialize, Deserialize)

[lukipuki]

I'd like to merge this PR today.

I'll think about making usability better, including

• easier calling of build_ble_stream() after available_ble_devices(), e.g. by making available_ble_devices() accept more types
• serialization/deserialization
• using available_ble_devices() in the BLE example
• ... any other

However, these will be in future PRs.

[andrewdavidmackenzie]

Ok. I need the serialization one to be able to switch to main branch in my app, so will watch for it. Others are good ones I'll use when available

…

On Sun, Nov 2, 2025, 12:30 PM Lukáš Poláček ***@***.***> wrote: *lukipuki* left a comment (meshtastic/rust#72) <#72 (comment)> I'd like to merge this PR today. I'll think about making usability better, including - easier calling of build_ble_stream() after available_ble_devices(), e.g. by making available_ble_devices() accept more types - serialization/deserialization - using available_ble_devices() in the BLE example - ... any other However, these will be in future PRs. — Reply to this email directly, view it on GitHub <#72 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABKF4LC6WU34ROXCWOALXHT32XTLRAVCNFSM6AAAAACKRHYL2OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTINZXHA4DINRTGA> . You are receiving this because you commented.Message ID: ***@***.***>