A list of issues from a test drive

[Crzyrndm]

This looks like exactly what I needed for a new BLE MCU project I'm developing so fortuitous timing in your release. Testing this out on Windows 10 (terminal didn't matter. Tested with Windows terminal (wt) + powershell 7, wt + windows powershell, wt + cmd, powershell 7 on default host console), I found a couple of immediate issues

Duplicated key presses

All inputs are being duplicated / reacted to twice. Filtering Example (typed /test) This is also present using the arrow keys to navigate the device list so trying to select a device can be very frustrating

Pairing

The device I'm working with requires that the connection is encrypted and blendr (seemingly) doesn't even try to pair. This results in a failed connection which is also not visible inside blendr. It just permanently shows At the very least "Just Works" pairing would be enough for early dev but support for the full set would be great https://www.bluetooth.com/blog/bluetooth-pairing-part-4/

Device list re- sorting during scan

During a scan, devices in the discovered list move. This makes connecting to the right one in a busy BLE environment extremely difficult (I have >50 devices in range)

u and r keys don't appear to work

Potentially this is related to the duplicated input, but right now "Hide unknown" and "restart scan" don't appear to do anything

"Unknown device"

Currently "unknown device" has no identity information. I have a couple of devices that are only identified by the fixed 48-bit MAC address. They're not standards compliant in any way, they're just known test addresses in my "lab" for running on device BLE checks against.

Would be good to be able to filter by MAC as well as displaying it. Some of my devices have duplicate names (for... reasons)

Characteristic Notification/Indication history

I haven't got this far yet (see pairing) and this is a bit of a wishlist item, but one thing I would really like to have is a log of (multiple) characteristic notifications. Several sensors I use transmit updates at a moderate frequency via notifications and being able to observe/record the history would be great

[dmtrKovalenko]

Ok that's very interesting insights. Thanks so much for the test run.

Very surprised with your issues related to key press, that should just work. Maybe you can provide info about terminal app, because I tested that (tbh not on windows) and I didn't have neither duplicates key press nor u/r problems.

[Crzyrndm]

Ok that's very interesting insights. Thanks so much for the test run.

Very surprised with your issues related to key press, that should just work. Maybe you can provide info about terminal app, because I tested that (tbh not on windows) and I didn't have neither duplicates key press nor u/r problems.

I will have a poke around and see if I can identify the source of the keypress issues.

[Crzyrndm]

Added some tracing events, the keypress events for "Press" and "release" are both causing the selected device to change. I assume this is true for all other cases as well

https://github.com/Crzyrndm/blendr/tree/keypress-duplication

2023-07-01T01:38:40.833981Z  INFO blendr::tui::peripheral_list: key=KeyEvent { code: Down, modifiers: NONE, kind: Press, state: NONE }
2023-07-01T01:38:40.834060Z  INFO blendr::tui::ui::list: 
2023-07-01T01:38:40.836892Z  INFO blendr::tui::peripheral_list: key=KeyEvent { code: Down, modifiers: NONE, kind: Release, state: NONE }
2023-07-01T01:38:40.836907Z  INFO blendr::tui::ui::list: selected=1
2023-07-01T01:38:50.886439Z  INFO blendr::tui::peripheral_list: key=KeyEvent { code: Down, modifiers: NONE, kind: Press, state: NONE }
2023-07-01T01:38:50.886490Z  INFO blendr::tui::ui::list: selected=2
2023-07-01T01:38:50.889529Z  INFO blendr::tui::peripheral_list: key=KeyEvent { code: Down, modifiers: NONE, kind: Release, state: NONE }
2023-07-01T01:38:50.889558Z  INFO blendr::tui::ui::list: selected=3

[Crzyrndm]

So with a simple filter to just press events (no release/repeat)

• duplicated navigation/filtering is gone
• u works (not sure if r works or not. May have misunderstood the functionality)
• > does connect (pairing unsure?)

That particular issue has a lot of side effects :/

[Crzyrndm]

bleplug pairing on windows is done at the OS level which is ... frustrating but anyway

Even after pairing I had no characteristics. It seems like there's a missing call to discover_services after connection?

[dmtrKovalenko]

Very interesting! I'll debug all of this tonight. That is very helpful!

[gitmalong]

Related to the keypress issue https://github.com/crossterm-rs/crossterm/issues/752

[chrysn]

I think that the resorting issue is particularly troublesome because it is completely unstable. If new devices popping up were added live, even mid-list, that'd be fine. On my system that list updates once per second, always comes out randomly sorted (neither alphabetical nor by RSSI), contains a lot of devices that are not nearby (i.e. that were once connected to and are remembered by bluez, but don't show an RSSI), and the cursor stays at the same line and doesn't move along with the selected device. Until something quite elaborate is established (maybe sorting by rolling-average RSSI where on changes the cursor moves with the selected device), I think it'd be best if that list was append-only for now.

[dmtrKovalenko]

I fixed a couple of issues mentioned here in v1.0.1:

1. List selection is now stable and does not move from the selecting device when new devices are popping around
2. Windows key pressing issue should be gone. Unfortunately, I don't have access to real Windows matching so if @Crzyrndm you can check it out that would be very helpful. 3. Notification/Read history. I started working on this feature but it appeared to be much bigger cause I want to add more features around it to make it really useful, so I will make work on this a little longer, probably will release it closer to the weekend.
3. Issue mentioned with pairing – I don't think it will be easy to implement as a part of this library, it should be done on OS level. I managed to connect and read the characteristics of my Ember mug that was paired with the computer before so I think it should work out of the box.

[chrysn]

4. Issue mentioned with pairing – I don't think it will be easy to implement as a part of this library, it should be done on OS level

I agree, this is probably handled well at the OS level -- with bugs better fixed there than worked around. To give an example, on my Debian sid system, some connections made the OS's "is that the same number" dialog pop up. On other occasions, things broke down completely -- but that also affected other BLE apps, so whatever that was was an OS / tool bug unrelated (even though possibly triggered by) blendr.