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 NameAndMac to the BleId enum
• added comments

Related Issues
#32

Checklist

• Tests pass locally
• Documentation updated if needed

[andrewdavidmackenzie]

In my code I wanted to derive Debug and CLone for this struct:

#[derive(Debug, Clone)]
pub enum DiscoveryEvent {
    BLERadioFound(BleId),
    BLERadioLost(BleId),
}

but neither are provided for BleId

[lukipuki]

Added

[andrewdavidmackenzie]

Thanks.

I wanted to maintain a Vec of found (in previous iteration of discovery loop) radios, and then detect new discoveries and "losses".

But because of the form of BleId, this is kind of hard to do.... as you can't in the code be sure what you will get back each loop. I guess I will need to convert both to string and store that in the Vec and hope the BleId returned doesn't shift over time (why would it!?)

This is done like this as you cannot be guaranteed one or the other?
e.g. it couldn't be a struct with a MacAddress (for sure) and an Option for the name?

pub enum BleId {
    /// ID constructed from a name
    Name(String),
    /// ID represented from a MAC address
    MacAddress(BDAddr),
}

[andrewdavidmackenzie]

Also, detecting if I already have discovered it in the Vec will require PartialEq:-(

[lukipuki]

This is the part of the API I originally struggled with and that's why I haven't posted this for two months.

I have another idea for API:

• available_ble_devices returns a tuple (BDaddr, String) (or it could be a new struct), not BleID. This is to indicate that we always have both MAC + name available.
• The users convert BDaddr to MacAddress to use it in build_ble_stream. We will provide a .into() method for simplicity.

[andrewdavidmackenzie]

If they are both always there, you could just make it a struct with BDaddr and String. Would make using it easier. PartialEq could use address (I assume two devices could be assigned the same name by their respective users?).
Display or to_string() could use name.

It would remove the need for matching on enums to do almost anything with BleId.

[matthewCmatt]

Might also be nice to include this in examples/basic_ble.rs, just because this is IMO part of the core bluetooth flow.

[lukipuki]

Might also be nice to include this in examples/basic_ble.rs, just because this is IMO part of the core bluetooth flow.

I'll do this in a followup PR, let's get this working first. Network Management Client claims it works: meshtastic/network-management-client#515 (comment)

[matthewCmatt]

I'll do this in a followup PR, let's get this working first. Network Management Client claims it works: meshtastic/network-management-client#515 (comment)

Sounds good @lukipuki, there's rustdocs so the example script is just icing on the cake

[andrewdavidmackenzie]

In case you missed the comment. For me to be able to use BleId in a vec and then determine if a particular BleId is there or not, it would also need to derive PartialEq.

I can't implement it due to the foreign crate + foreign trait limitation.

[andrewdavidmackenzie]

I implemented my own BleId compare to advance.

While testing, it seems that using available_devices() with a 1 or 2 or 3 second delay, oscillates between returning my one device, or returning zero.

I had to extend the scan time to 4 seconds to get a stable list (of 1 device) being returned.

I guess that's just the nature of BTLE and the radio I happen to have. It makes the list less "fresh" though.

The ideal API would be some form of streaming discovery API with messages for devices lost and found.

[andrewdavidmackenzie]

My next step will be to connect to device, using build_ble_stream() I assume.

[andrewdavidmackenzie]

For me, this new method is working. Do you plan to do more before merging the PR.

If you wanted to capture some of the above comments above for possible future enhancements, I could write an issue or two?

[lukipuki]

Thanks for the offer, but there's no need to create a GitHub issue for this. I've just been busy with a hobby project that involves using Meshtastic in the field, broadcasting split times for sport events over LoRa. Now that the colder months are approaching, I'll be spending less time outdoors and more time coding again.

I'll hopefully get to this within the next week or two.

[lukipuki]

Closing in favor of another approach, I'll drop BleId::NameAndMac.

[lukipuki]

Continuing in #68