Ruuvitag_sensor doesn't find devices on raspberry pi 3


#1

Hello,
I am trying to find ruuvi sensor beacon device from Raspberry Pi 3 but I am unable to get any data. I have followed instructions from https://github.com/ttu/ruuvitag-sensor to setup RuuviTag sensor but I have been unable to get it work:

    pi@raspberrypi:~ $ ruuvitag -f
    Finding RuuviTags. Stop with Ctrl+C.
    Start receiving broadcasts (device hci0)
    End Of File (EOF). Exception style platform.
    Stop receiving broadcasts

My Android phone can get data from beacon device correctly with Ruuvi Station.

This is bluetooth status on Raspberry Pi:

● bluetooth.service - Bluetooth service
   Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2018-04-16 12:29:47 UTC; 1h 51min ago
     Docs: man:bluetoothd(8)
 Main PID: 561 (bluetoothd)
   Status: "Running"
   CGroup: /system.slice/bluetooth.service
           └─561 /usr/lib/bluetooth/bluetoothd

 raspberrypi systemd[1]: Starting Bluetooth service...
raspberrypi bluetoothd[561]: Bluetooth daemon 5.43
raspberrypi systemd[1]: Started Bluetooth service.
raspberrypi bluetoothd[561]: Starting SDP server
raspberrypi bluetoothd[561]: Bluetooth management interface 1.14 initialized
raspberrypi bluetoothd[561]: Failed to obtain handles for "Service Changed" characteristic
raspberrypi bluetoothd[561]: Sap driver initialization failed.
raspberrypi bluetoothd[561]: sap-server: Operation not permitted (1)
raspberrypi bluetoothd[561]: Endpoint registered: sender=:1.6 path=/A2DP/SBC/Source/1
raspberrypi bluetoothd[561]: Endpoint registered: sender=:1.6 path=/A2DP/SBC/Sink/1

Unable to get sensor data
#2

What is the response to:

hcitool dev

hciconfig

hcidump -t -x | head -n40

If hcidump does not show anything leave it running and from another window/session issue

hcitool lescan


#3

Hello, thanks for reply. I executed following:

pi@raspberrypi:~ $ hcitool dev
Devices:
    hci0	B8:27:EB:81:87:83
pi@raspberrypi:~ $ hciconfig
hci0:	Type: Primary  Bus: UART
    BD Address: B8:27:EB:81:87:83  ACL MTU: 1021:8  SCO MTU: 64:1
    UP RUNNING 
    RX bytes:109942 acl:0 sco:0 events:3503 errors:0
    TX bytes:20221 acl:0 sco:0 commands:953 errors:0

pi@raspberrypi:~ $ hcidump -t -x | head -n40
HCI sniffer - Bluetooth packet analyzer ver 5.43
device: hci0 snap_len: 1500 filter: 0xffffffff
2018-04-17 07:10:07.684802 > HCI Event: Command Complete (0x0e) plen 4
    LE Set Scan Parameters (0x08|0x000b) ncmd 1
    status 0x00
2018-04-17 07:10:07.685824 > HCI Event: Command Complete (0x0e) plen 4
    LE Set Scan Enable (0x08|0x000c) ncmd 1
    status 0x00
2018-04-17 07:10:17.869192 > HCI Event: Command Complete (0x0e) plen 4
LE Set Scan Enable (0x08|0x000c) ncmd 1
status 0x00

hcidump -t -x | head -n40 did not show anything before I issued hcitool lescan from another window


#4

I got it working now. I had to execute following:

bluetoothctl

And then in bluetoothctl console:

power on
agent on
scan on

#5

This sounds like you have a GUI version of Raspbian (or some other OS), and the GUI bluetooth features are known to do some odd things from time to time, which would explain why you needed to manually turn on the bluetooth stuff from bluetoothctl.

The ruuvitag-sensor (like most other similar libraries/applications) use bluez under the hood (ie. hcitool, hcidump, etc), and not all implementations account for “unexpected” changes, configurations or situations, such as the entire adapter being powered down.


#6

Hello, thank you. I am using GUI version on Raspbian.


#7

Hello!

I am having the same problem. I ran the bluetoothctl command and added those commands (power on, agent on and scan on) in console. But it’s still not working. I have also given higher privileges to hcitool and hcidump. Any ideas?

python3 ~/.local/lib/python3.6/site-packages/ruuvitag_sensor -f
Finding RuuviTags. Stop with Ctrl+C.
Start receiving broadcasts (device hci0)
End Of File (EOF). Exception style platform.
Stop receiving broadcasts
hcitool dev
Devices:
	hci0	B8:27:EB:A5:A4:8D
hciconfig
hci0:	Type: Primary  Bus: UART
	BD Address: B8:27:EB:A5:A4:8D  ACL MTU: 1021:8  SCO MTU: 64:1
	UP RUNNING 
	RX bytes:4164 acl:0 sco:0 events:240 errors:0
	TX bytes:5718 acl:0 sco:0 commands:230 errors:0
hcidump -t -x | head -n40
HCI sniffer - Bluetooth packet analyzer ver 5.43
device: hci0 snap_len: 1500 filter: 0xffffffff
2018-11-20 08:24:18.554309 < HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7
    type 0x01 (active)
    interval 10.000ms window 10.000ms
    own address: 0x00 (Public) policy: All
2018-11-20 08:24:18.555018 > HCI Event: Command Complete (0x0e) plen 4
    LE Set Scan Parameters (0x08|0x000b) ncmd 1
    status 0x00
2018-11-20 08:24:18.555118 < HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2
    value 0x01 (scanning enabled)
    filter duplicates 0x01 (enabled)
2018-11-20 08:24:18.555588 > HCI Event: Command Complete (0x0e) plen 4
    LE Set Scan Enable (0x08|0x000c) ncmd 1
    status 0x00
2018-11-20 08:24:18.587427 > HCI Event: LE Meta Event (0x3e) plen 43
    LE Advertising Report
      ADV_NONCONN_IND - Non connectable undirected advertising (3)
      bdaddr E6:72:E5:7F:2E:AA (Random)
      Flags: 0x06
      Complete service classes: 0xfeaa
      Unknown type 0x16 with 22 bytes data
      RSSI: -69
2018-11-20 08:24:18.696698 > HCI Event: LE Meta Event (0x3e) plen 40
    LE Advertising Report
      ADV_NONCONN_IND - Non connectable undirected advertising (3)
      bdaddr 78:BD:BC:5C:D2:05 (Public)
      Unknown type 0xff with 26 bytes data
      RSSI: -80
2018-11-20 08:24:18.718851 > HCI Event: LE Meta Event (0x3e) plen 43
    LE Advertising Report
      ADV_NONCONN_IND - Non connectable undirected advertising (3)
      bdaddr ED:D2:67:E4:82:AE (Random)
      Flags: 0x06
      Complete service classes: 0xfeaa
      Unknown type 0x16 with 22 bytes data
      RSSI: -67

#8

I, too, need to do that for hcidump to work, and I’m not even using any GUI version – I’m running Raspbian Stretch Lite (released on 2018-11-13 with kernel 4.14). And what’s worse, when I quit bluetoothctl, hcidump stops working! So I would need to keep bluetoothctl open in some terminal all the time. That cannot be how this is all supposed to work! Is that how it works for you too, @mikkoyli? Any good ideas on how to get the Bluetooth scanning to be always on, @Scrin?

Edit: I’ve got a Raspberry Pi 3 Model B.


#9

Adding the current user into the bluetooth group (and a reboot afterwards for good measure) seems to have done the trick for me:

pi@raspberrypi:~ $ sudo adduser pi bluetooth

Now I can run RuuviCollector and it receives the data! RuuviCollector not receiving the data was actually my original issue, but I asked about hcidump because I thought it was the issue, because of the “If you don’t get any data, check that you are able to run ‘hcitool lescan’ and ‘hcidump --raw’ without issues” message it displays on startup…


#10

hcidump intercepts packets from the HCI device to another program (like hcitool lescan) if no process is receiving packets hcidump does not display anything


#11

Great, that explains it, thank you very much! I thought hcidump was analogous to tcpdump in that you could just capture all traffic that goes through an interface. But someone else has created an application more like that: Bluewalker - Simple BLE scanner for Linux with support for reading Ruuvi tag data


#12

Technically hcidump is just like tcpdump; nothing’s going through the network interface(s) if nothing is generating traffic :wink: although on most network interfaces you can enable promiscuous mode to reveal traffic “not intended for you but still getting to you”, which is partially what ie. hcitool lescan does (it does not reveal directed traffic targeted at other devices though)


#13

Hmm, yeah, I feel like I’m digging myself deeper into the this-guy-has-no-idea-what-he-is-talking-about swamp, but… I was thinking of broadcast messages on Ethernet networks. They aren’t necessarily directed to anyone special but to everyone, and I figured that Bluetooth broadcast messages would be the same in that when a message is directed to everyone, everyone will understand to receive that message, too. However, now I realize that of course there’s some code in the protocol stack that specifically listens to broadcast messages as well. So apparently the Bluetooth stack has no such “default listener”, as it wouldn’t know what to do with some random broadcast messages anyway.