No RSSI

[Beetix]

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.

[qdot]

What platform/OS is this on?

[Beetix]

This is on Arch Linux x86_64.

Is the RSSI information really implemented? If so, what is the current way of retrieving it?

Thanks

[MattesWhite]

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.

[qdot]

We get RSSI in all major platforms as of v0.8, closing.

[rib]

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.

[rib]

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)

[qwandor]

Now fixed in dev by #198 for Windows and Linux, CoreBluetooth is still pending.