btleplug
btleplug copied to clipboard
deviceplug
No RSSI
Describe the bug Can't get RSSI
Expected behavior RSSI information for each message received
Actual behavior No RSSI information
Additional context RSSI mentioned here to set tx_power_level. Don't quite understand why. tx_power_level should be retrieved from the message sent by the peripheral while the RSSI should be retrieved from the central's radio.
This is on Arch Linux x86_64.
Is the RSSI information really implemented? If so, what is the current way of retrieving it?
Thanks
Hi, I need the RSSI information for a current project. If someone gives me a rough instruction what is necessary to implement this feature I can write a PR.
Can we maybe re-open this issue, since I think TX power was maybe being considered as equivalent to RSSI here?
The current status looks like:
In the bluez backend tx_power_level is correctly reported
In the winrt backend tx_power_level is actually the RSSI
In the corebluetooth backend tx_power_level is always None
It looks like DeviceInfo in the bluez backend includes the rssi which could be easy to export
In the winrt backend there is rss and tx power state under BluetoothLEAdvertisementReceivedEventArgs so tx_power_level can be updated to reflect the transmission power and it could also export the receiver power.
I'm not familiar with how to get either the tx or rssi state in corebluetooth, but guess it's probably easily accessible somehow.
looking at the osx api I see that the tx is exposed via: https://developer.apple.com/documentation/corebluetooth/cbadvertisementdatatxpowerlevelkey
The rssi is exposed asynchronously via: https://developer.apple.com/documentation/corebluetooth/cbperipheral/1519111-readrssi
(and then it depends whether on ios or osx exactly how the rssi value is received)
Now fixed in dev by #198 for Windows and Linux, CoreBluetooth is still pending.
