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.
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
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?
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ā¦
hcidump intercepts packets from the HCI device to another program (like hcitool lescan) if no process is receiving packets hcidump does not display anything
Technically hcidump is just like tcpdump; nothingās going through the network interface(s) if nothing is generating traffic 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)
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.
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.