ttu / ruuvitag-sensor

Python package for communicating with RuuviTag BLE Sensor and for decoding sensor data from broadcasted data
https://ttu.github.io/ruuvitag-sensor/
MIT License
195 stars 77 forks source link

RuuviTags not found with Intel AX200 USB #230

Closed JohnConnett closed 7 months ago

JohnConnett commented 10 months ago

Describe the bug Running the 1. Get sensor data synchronously with callback example doesn't find any RuuviTags:

(.venv) pi@topaz:~/Python/ruuvitag$ uname -a
Linux topaz 6.5.0-10-generic #10-Ubuntu SMP PREEMPT_DYNAMIC Fri Oct 13 13:49:38 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
(.venv) pi@topaz:~/Python/ruuvitag$ lsusb | grep Bluetooth
Bus 003 Device 004: ID 8087:0029 Intel Corp. AX200 Bluetooth
(.venv) pi@topaz:~/Python/ruuvitag$ cat scan.py
from ruuvitag_sensor.ruuvi import RuuviTagSensor

def handle_data(found_data):
    print(f"MAC {found_data[0]}")
    print(f"Data {found_data[1]}")

if __name__ == "__main__":
    RuuviTagSensor.get_data(handle_data)
(.venv) pi@topaz:~/Python/ruuvitag$ getcap /usr/bin/python3.11
/usr/bin/python3.11 cap_net_admin,cap_net_raw=eip
(.venv) pi@topaz:~/Python/ruuvitag$ python scan.py
^C(.venv) pi@topaz:~/Python/ruuvitag$

Running bluetoothctl on the same system doesn't discover any RuuviTags:

(.venv) pi@topaz:~/Python/ruuvitag$ bluetoothctl
Agent registered
[CHG] Controller 38:7A:0E:76:48:81 Pairable: yes
[bluetooth]# scan le
Discovery started
[CHG] Controller 38:7A:0E:76:48:81 Discovering: yes
[NEW] Device 3A:1A:52:FD:4D:76 ET-5150 Series
[NEW] Device 38:00:25:42:27:9F skylon
[DEL] Device 38:00:25:42:27:9F skylon
[DEL] Device 3A:1A:52:FD:4D:76 ET-5150 Series
[bluetooth]# 
             quit

(.venv) pi@topaz:~/P

However, running bluetoothctl on a nearby system running Ubuntu 22.04.3 LTS (Jammy Jellyfish) does discover some RuuviTags:

jrc@skylon:~/Python/ruuvitag$ uname -a
Linux skylon 5.15.0-88-generic #98-Ubuntu SMP Mon Oct 2 15:18:56 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
jrc@skylon:~/Python/ruuvitag$ lsusb | grep Bluetooth
Bus 001 Device 009: ID 8087:0029 Intel Corp. AX200 Bluetooth
jrc@skylon:~/Python/ruuvitag$ bluetoothctl
Agent registered
[bluetooth]# scan le
Discovery started
[CHG] Controller 38:00:25:42:27:9F Discovering: yes
[NEW] Device 3A:1A:52:FD:4D:76 ET-5150 Series
[NEW] Device FC:1B:17:CC:4F:A3 Ruuvi 4FA3
[NEW] Device EB:DF:CD:9A:C8:B4 Ruuvi C8B4
[NEW] Device FC:01:4E:67:FC:EB Ruuvi FCEB
[CHG] Device FC:1B:17:CC:4F:A3 ManufacturerData Key: 0x0499
[CHG] Device FC:1B:17:CC:4F:A3 ManufacturerData Value:
  05 0c dd 46 85 c5 f4 03 1c fd 50 ff ec aa 96 40  ...F......P....@
  2d 24 fc 1b 17 cc 4f a3                          -$....O.        
[bluetooth]# 
[NEW] Device F4:D9:4E:9A:E0:B1 Ruuvi E0B1
quitetooth]# 
jrc@skylon:~/Python/ruuvitag$ 

The 1. Get sensor data synchronously with callback example doesn't find any RuuviTags on this system either.

Running the same example on a Raspberry Pi 4 Model B running Raspbian 11 (bullseye) works as expected:

(.venv) pi@emonpi:~/Python/ruuvitag $ uname -a
Linux emonpi 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr  3 17:24:16 BST 2023 aarch64 GNU/Linux
(.venv) pi@emonpi:~/Python/ruuvitag $ getcap /usr/bin/python3.9
/usr/bin/python3.9 cap_net_admin,cap_net_raw=eip
(.venv) pi@emonpi:~/Python/ruuvitag $ python scan.py
MAC ED:B7:6D:1E:80:0D
Data {'data_format': 5, 'humidity': 53.28, 'temperature': 15.89, 'pressure': 1006.24, 'acceleration': 1088.3087797128167, 'acceleration_x': 996, 'acceleration_y': -436, 'acceleration_z': 48, 'tx_power': 4, 'battery': 2946, 'movement_counter': 248, 'measurement_sequence_number': 27159, 'mac': 'edb76d1e800d', 'rssi': -95}
[...]

I appreciate that this may be a setup or documentation error rather than a bug in ruuvitag-sensor. Would really appreciate clarification or an explanation!

Environment (please complete the following information):

ttu commented 10 months ago

Hi! The package uses deprecated BlueZ tools (hciconfig, hcitool and hcidump) with sync-communication, causing a fair share of issues on multiple users' systems. https://github.com/ttu/ruuvitag-sensor/#bluez

Unfortunately, I don't have any other recommendation than to use async-communication with the Bleak adapter. It will be the default adapter for Linux in the near future. I will add already a mention to the README that new users should start with async-communication, regardless of the OS they are using (https://github.com/ttu/ruuvitag-sensor/pull/231). https://github.com/ttu/ruuvitag-sensor#Bleak

ttu commented 7 months ago

If you encounter problems with BlueZ and prefer not to switch to asynchronous methods, it might be worthwhile to try the Bleson-adapter, although it is currently in an alpha state.