Thank you very much for your great extension. I bought it a few days ago.
What I want: I want to check the RSSI Signalstrength
of a specific Device (MAC) every second to find the way to it. (if the Signal gets stronger, I know that I am walking in the right direction.
Is it possible to get rssi in Bluetooth classic programmatically for Android frequently, for example every second? What do you recommend?
Please find below the answer
Taifun
It's challenging to get highly frequent (e.g., every second) and reliable RSSI updates for Bluetooth Classic devices programmatically on Android, especially for connected devices. Here's a breakdown of why and what you might consider:
Challenges with Frequent Bluetooth Classic RSSI
Discovery Mode Limitation:
For Bluetooth Classic, RSSI values are primarily reported during the device discovery process (when you call BluetoothAdapter.startDiscovery()).
When a device is discovered, an ACTION_FOUND intent is broadcast, and this intent contains the RSSI value as an extra (BluetoothDevice.EXTRA_RSSI).
The problem is that running discovery constantly consumes a lot of battery and can interfere with existing connections by significantly reducing available bandwidth. It's generally not recommended for continuous, frequent updates for a specific device you're already connected to.
No Direct getRssi() for Connected Devices (Classic):
Unlike Bluetooth Low Energy (BLE), where you can actively request RSSI updates from a connected GATT device using BluetoothGatt.readRemoteRssi(), Bluetooth Classic doesn't have a direct equivalent method in the public Android API for constantly polling RSSI from an already connected device.
Some older discussions mention workarounds or private APIs, but these are generally unreliable, not officially supported, and can break with Android updates.
RSSI Fluctuation and Reliability:
RSSI values are inherently unstable and can fluctuate significantly even over short periods due to factors like:
Obstacles (people, walls, furniture)
Device orientation
Battery level of the devices
Multipath fading
Interference from other 2.4 GHz devices (Wi-Fi, microwaves)
This makes precise distance estimation or even consistent tracking based solely on raw RSSI challenging.
What do I recommend?
Given these limitations, here are my recommendations:
Re-evaluate "every second" for Bluetooth Classic:
If your goal is simply to detect proximity or general signal strength trends, refreshing every few seconds (e.g., 5-10 seconds) during discovery might be acceptable. However, keep the battery drain in mind.
If you absolutely need high-frequency updates, Bluetooth Classic might not be the best fit for this specific requirement.
Consider Bluetooth Low Energy (BLE) if possible:
This is the strongest recommendation if high-frequency RSSI is critical. BLE is designed for low-power, short-burst data, and it has much better programmatic control over RSSI.
With BLE, once connected to a GATT server, you can use BluetoothGatt.readRemoteRssi() to request an RSSI update, and you'll receive the result in the onReadRemoteRssi() callback. You can call this method as frequently as needed (within reasonable limits dictated by the connection interval and device capabilities).
Many modern devices support both Bluetooth Classic and BLE. If your target device also has a BLE interface, switching to BLE for RSSI monitoring would be ideal.
If stuck with Bluetooth Classic and need approximate frequent updates:
Repeated Discovery with Caution:
You could try initiating a BluetoothAdapter.startDiscovery() periodically (e.g., every 5-10 seconds) and listening for ACTION_FOUND broadcasts.
Warning: This is highly inefficient, battery-intensive, and can negatively impact ongoing Bluetooth Classic connections (e.g., audio streaming). Android itself discourages discovery while connected.
You'd need to stop discovery (BluetoothAdapter.cancelDiscovery()) before starting it again to manage resources.
Monitor Connection State: While not giving you RSSI directly, you can monitor the connection state (BluetoothAdapter.ACTION_CONNECTION_STATE_CHANGED) to know if the device is still connected. This might be a substitute if your primary need is just to know if the device is in range and connected.
Hardware-Level Solutions (Advanced):
For highly precise and frequent RSSI, sometimes the limitation is in the Android API or the Bluetooth stack itself. In very specialized cases (e.g., custom hardware development), you might interact directly with the Bluetooth chip's firmware, but this is far beyond typical Android app development.
In summary: For frequent, programmatic RSSI updates on Android, Bluetooth Low Energy (BLE) is vastly superior and recommended over Bluetooth Classic. If you are absolutely tied to Bluetooth Classic, recognize the inherent limitations and consider whether "every second" is truly a strict requirement, as it will be challenging to achieve reliably and efficiently.
For paired devices try property AddressesAndNames from the Bluetooth Client component
For all devices try the Scan method of the Bluetooth extension and get rhe scan result returned in event AfterSasnning in 2 lists (paired und unpaired devices)
The scan result is identical to the result from the AddressesAndNames property,.
Returns the list of Bluetooth devices. Each element of the returned list is a String consisting of the device’s address, a space, and the device’s name. Additionally you can get RSSI and the device type, see rhe documentation
After scanning for Bluetooth devices using start discovery I get mac addresses back, but without device names. Permissions are granted.
Below please find the answer
Taifun
This issue often occurs because the device's name isn't immediately available during the initial discovery process. Here's a breakdown of why this happens and what you can do about it.
Why It Happens
The Bluetooth scanning process, specifically startDiscovery(), is designed to find nearby devices and their basic information as quickly as possible. The initial scan primarily returns the Bluetooth MAC address, also known as the device's unique identifier. The device name is a separate piece of information that needs to be retrieved through a more detailed process.
In many cases, the device name is included in the advertising packet sent out by the remote device. However, some devices may not include their name in these packets, or the packets might be truncated. When this happens, your app receives the MAC address but a null or empty string for the name.
Solutions
To get the device names, you'll need to use a different approach. The most common solution is to create a Bluetooth connection to the device after discovering its MAC address. Once a connection is established, you can query the device for its detailed information, including its name.
Here's a general outline of the steps:
Start Discovery: Use startDiscovery() to get a list of nearby devices and their MAC addresses.
Get MAC Addresses: Store the MAC addresses you find in a list.
Create a Connection: For each MAC address, use the BluetoothDevice object to create a BluetoothSocket.
Connect and Query: Attempt to connect to the device using the socket. If the connection is successful, you can now retrieve the device's name. You can use methods like device.getName() after the connection is established or when you have a BluetoothDevice object.
A second, more modern solution for Android developers, is to use the BluetoothLeScanner API for Bluetooth Low Energy (BLE) devices. This API provides more control over the scan process and can often retrieve device names more reliably. You can use a ScanFilter to only look for devices with specific names, but you can also perform a general scan and parse the ScanResult object, which often contains the device's name in its getDevice() or getScanRecord() methods.
By connecting to the device or using a more advanced scanning method, you can consistently get the device names you're looking for.
