minible
minible copied to clipboard
Allows connection from the OS Bluetooth management panel
Missing feature
Ability to connect the MiniBLE from the Computer Bluetooth management panel.
Justification
When several devices are paired, the MiniBLE will connect to any of them. If I want to use it from a specific device, I have the choice between using the Disconnect Device option until it reconnect to the device I want or disabling Bluetooth on the other device to force the MiniBLE to connect to the only remaining device.
An alternative would be to be able to connect to a specific device from the MiniBLE menu.
Workarounds
Mentioned above
Related to this issue #120
A list of paired devices to choose from (to attempt to connect to) on the mooltipass would be nice too
I use mine with 4-5 bluetooth devices and the bluetooth management is a real pain point for me
The whole BLE management interface needs a rethink. In particular, control over the BLE session management should be solely under the control of the Moolti hardware. This leads to the device being in one of three states:
- bluetooth OFF (radio off)
- bluetooth IDLE (radio on, no active BLE connection)
- bluetooth CONNECTED (radio on, BLE connected to another device)
When the Moolti is IDLE it listens for incoming connection requests from paired devices, but doesn't accept them until the connection request is confirmed by the user (thumbwheel yes/no). The connection prompt must display the remove devices name as stored in the pairing database. When the Moolti is CONNECTED it talks only to the connected device (present behaviour, and required by the BLE spec).
When the user disconnects a running BLE session, the Moolti goes back to IDLE state.
In this way the user always knows which device the Moolti is talking to.
The would result in the following Bluetooth menu items/operations:
- Status: show the current state (OFF, IDLE, CONNECTED), and if CONNECTED, the name of the device it is talking to. It might be useful to also display the Bluetooth MAC address, to help in varification of pairing requests, although this could instead be made available under the top-level Settings menu (where it should also be possible to set the Moolti's advertised BLE name).
- Off/On: turn the radio on or off. If transitioning to off, perform an implicit disconnect.
- Connect: connect to a paired device. A submenu would let you scroll through the list of paired devices to select the connection target.
- Disconnect: disconnect the current session, if any.
- Pairing: enter the device pairing menu. This would let you display the list of currently paired devices, and to initiate a new pairing request.
This greatly streamline the Bluetooth management interface, and ensures there is no ambiguity as to which device (if any) the Moolti is talking to. The later is critical in helping the user avoid sending credentials to the wrong device.
@rastagraffix that would be a great idea! However the Bluetooth protocol itself and its implementation on different operating systems doesn't allow this :/
Doesn't allow what, specifically? The MiniBLE is allowed to refuse any incoming connection request if it so chooses. So if, e.g., my iPhone initiates a connection request to the miniBLE and the user rejects the connection, the miniBLE is free to not respond to the connection request, in which case the connection never establishes itself and the initiator will eventually time out.
Or is there something else you're talking about?
Some operating systems, when connections attempts are unsuccessful, simply removing the matching pairing data. On top of this, doing so would me that the OS would constantly keep trying to connect to the Mini, therefore draining its battery.
If an os deletes a pairing just because it can’t connect, that’s just broken imho. And any auth app that can’t contact the mini BLE is going to time out pretty quickly, so I don’t see battery drain being a real issue.
Neither of these cases is any different than if the mini BLE lost connectivity because you walked away from the other device with the mini in your pocket. This sort of thing happens all the time without causing the end of civilization :-)