Fix issue where RSSI is incorrectly reported as -99

[peter-dolkens]

Upon investigating why my RSSI kept jumping to -99, I discovered that the bluetooth spec for HCI_Read_RSSI states:

The RSSI parameter returns the difference between the measured Received Signal Strength Indication (RSSI) and the limits of the Golden Receive Power Range for a Connection Handle to another BR/EDR Controller. Any positive RSSI value returned by the Controller indicates how many dB the RSSI is above the upper limit, any negative value indicates how many dB the RSSI is below the lower limit. The value zero indicates that the RSSI is inside the Golden Receive Power Range.

Currently, monitor.sh has a rule that sets the RSSI to -99 if it is reported as 0, causing the RSSI to be instantly reported as -99. I have removed this override which should result in more accurate presence detection - if something is close enough to be in the "golden range", then it's more likely to be at 0, than it is to be at -99, which is almost out-of-range.

Sources:

• https://stackoverflow.com/questions/30025139/bluez-bluetooth-api-and-distance-calibration-precision
• https://bluez-users.narkive.com/5nAqoY4A/hcitool-and-rssi-value-0
• https://www.cwnp.com/rssi-changing-definition/

[peter-dolkens]

For reference, this is what 4 hours of RSSI history looks like with these changes applied:

And this is similar history without these changes applies:

Notice the tendency to sit at -99, -66, and -33 - a result of reports returning within the "golden range"