linux下需通过d-bus接口获取ble设备rssi，监听propertieschanged信号或调用getall方法读取org.bluez.device1的rssi字段，且设备须处于已发现或已连接状态；windows需用bluetoothleadvertisementwatcher在received事件中获取rawsignalstrengthindbm。
BlueZ里怎么拿到BLE设备的RSSI值？
Linux下用BlueZ读RSSI，核心不是靠bluetoothctl交互命令——它不暴露实时RSSI；得走D-Bus接口，监听PropertiesChanged信号或主动调用GetAll方法查RSSI属性。常见错误是只连上设备就以为能直接读，其实必须先完成Pair或Trust（取决于策略），且设备得在扫描期间被发现过，否则D-Bus路径都不存在。
-
org.bluez.Device1接口的RSSI字段只在设备处于“已发现”或“已连接”状态时有效，断连后立刻失效 - 用
gdbus命令行调试时，路径形如/org/bluez/hci0/dev_AA_BB_CC_DD_EE_FF，必须替换成真实MAC（冒号换成下划线） - c++里推荐用
QtDBus或原生libdbus，别手写xml解析——D-Bus返回的RSSI是int16类型，单位dBm，典型值-127 ~ 0，负得越少信号越强
windows上用BluetoothLEDevice::FromBluetoothAddressAsync为啥读不到RSSI？
WinRT API里RSSI不是设备对象的固有属性，而是扫描结果的一部分。直接从地址构造BluetoothLEDevice对象，得到的是一个空壳，ConnectionStatus为Disconnected，所有信号相关字段（包括RSSI）都是nullptr或默认值。
- 必须用
BluetoothLEAdvertisementWatcher启动扫描，在Received事件回调里取args->RawSignalStrengthInDBm() - 扫描模式要用
Active（而非Passive），否则某些设备不发完整广播包，RSSI可能不准或缺失 - 注意权限：AppxManifest里要声明
bluetooth和bluetooth.genericAttributeProfile能力，否则Watcher启动失败且无明确报错
跨平台C++代码里该不该缓存RSSI？
不该主动缓存。RSSI本身波动剧烈，同一设备在1秒内可能变化10dB以上，缓存会误导逻辑判断。更糟的是，BlueZ的D-Bus属性和WinRT的RawSignalStrengthInDBm都非实时推送——BlueZ需轮询或监听信号，WinRT依赖扫描周期（默认1.28秒），强行缓存反而放大延迟。
- 每次需要时重新获取：BlueZ走D-Bus
GetAll，WinRT重触发一次Watcher.Start()并等下个Received - 如果做信号趋势判断（比如靠近/远离），应基于连续3~5次原始值计算移动平均，而不是存一个“最新RSSI”变量
- 别把
RSSI当距离换算——没有校准过的设备，-60dBm既可能是1米也可能是5米，环境反射影响太大
为什么hcitool rssi返回Can't read RSSI？
这个命令依赖底层HCI命令Read RSSI（OGF=0x08, OCF=0x0005），但仅对已建立ACL连接的BR/EDR设备有效，对BLE设备完全无效。很多用户误以为它能扫BLE，其实BlueZ 5.60+已明确废弃该用法。
立即学习“C++免费学习笔记（深入）”；
- 确认设备类型：
hcitool con看是否在连接列表里，且类型是BR/EDR（不是LE） - BLE必须用
bluetoothctl里的scan on+devices，或D-Bus方式，hcitool对此无支持 - 部分USB蓝牙适配器（尤其Realtek芯片）固件不支持该HCI命令，即使对BR/EDR设备也会报错，换Intel或Cambridge Silicon Radio芯片的dongle可解决
实际用的时候，最常卡住的点是权限和状态同步：BlueZ要sudo setcap 'cap_net_raw,cap_net_admin+eip' $(which bluetoothd)才允许普通用户访问D-Bus属性；Windows上Watcher必须在ui线程创建，放在线程池里会静默失败。这些细节不踩一遍很难意识到。