Open Crzyrndm opened 1 year ago
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.
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.
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
So with a simple filter to just press events (no release/repeat)
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 :/
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?
Very interesting! I'll debug all of this tonight. That is very helpful!
Related to the keypress issue https://github.com/crossterm-rs/crossterm/issues/752
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.
I fixed a couple of issues mentioned here in v1.0.1:
- 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.
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 frustratingPairing
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
andr
keys don't appear to workPotentially 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