4

I have a Raspberry Pi 4 that I plan to use as a media center, and I want to pair a controller to it. However, using bluetoothctl to pair a controller results in the controller briefly pairing and then unpairing, at least as far as what the Pi is telling me; on the controller itself, the pairing lights never stop blinking.

I've tried this with both an Xbox One S controller and an 8Bitdo SN30 Pro; both have the same result.

[bluetooth]# agent on
Agent is already registered
[bluetooth]# show
Controller E4:5F:01:09:21:CE (public)
        Name: raspberrypi
        Alias: raspberrypi
        Class: 0x00000000
        Powered: yes
        Discoverable: no
        Pairable: no
        UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
        UUID: PnP Information           (00001200-0000-1000-8000-00805f9b34fb)
        UUID: Generic Access Profile    (00001800-0000-1000-8000-00805f9b34fb)
        Modalias: usb:v1D6Bp0246d0532
        Discovering: no
[bluetooth]# default-agent
[bluetooth]#
Default agent request successful
[bluetooth]# scan on
[bluetooth]#
Discovery started
[bluetooth]#
[CHG] Controller E4:5F:01:09:21:CE Discovering: yes
[bluetooth]#
[CHG] Device 40:87:18:E2:35:AE RSSI: -76
[bluetooth]#
[CHG] Device 77:01:6D:52:02:5A RSSI: -93
[bluetooth]#
[CHG] Device 77:01:6D:52:02:5A TxPower: 12
[bluetooth]#
[CHG] Device 40:87:18:E2:35:AE RSSI: -84
[bluetooth]#
[NEW] Device E4:17:D8:99:F7:83 8Bitdo SN30 Pro
[bluetooth]# trust E4:17:D8:99:F7:83
[bluetooth]#
[CHG] Device E4:17:D8:99:F7:83 Trusted: yes
[bluetooth]#
Changing E4:17:D8:99:F7:83 trust succeeded
[bluetooth]# pair E4:17:D8:99:F7:83
Attempting to pair with E4:17:D8:99:F7:83
[bluetooth]#

[8Bitdo SN30 Pro]#
[CHG] Device E4:17:D8:99:F7:83 Connected: yes
[8Bitdo SN30 Pro]#
[CHG] Device E4:17:D8:99:F7:83 Paired: no
[8Bitdo SN30 Pro]#


[bluetooth]#
[CHG] Device E4:17:D8:99:F7:83 Connected: no

I'm aware of the ERTM issue with Xbox One controllers, and I did disable ERTM; this did not help. I've also tried a Logitech K480 keyboard; that prompts for the passkey as you'd expect, but after typing in the passkey (or just after waiting a while) it disconnects. The keyboard never lights up the pairing light to show it's connected.

Edit: This is on Raspberry Pi OS Lite

toyota Supra
  • 560
  • 2
  • 6
  • 9
discourse
  • 41
  • 1
  • 1
  • 3
  • The default BT set up in RPi OS Desktop is significantly different than it is in RPi OS Lite. Please edit your question to indicate which are you using. – Seamus Mar 21 '21 at 22:14
  • @Seamus I'm not so sure that's true unless you just mean there's a GUI app that tends to override the cli -- but I would guess the GUI doesn't probably doesn't override what's done with the cli but will reflect it, ie., they are two views of the same system and should co-operate. – goldilocks Mar 22 '21 at 16:01
  • In my experience, it is true. You may wish to look over the log of my BT nutroll; I'd love to hear another opinion! – Seamus Mar 22 '21 at 16:50
  • Post more info about your device model. Use the command below cat /proc/cpuinfo – Rafael Pereira Ramos Apr 19 '21 at 00:02

2 Answers2

10

My research has continued and I now have a solution that works on the newest Raspbian 2021-03-04. I tried it with the desktop version, but lite should be the same as my previous observations showed that the issues were identical on both platforms.

To make Bluetooth work, three problems need to be fixed. For this, two config files need to be edited to disable a non-working plugin and fix two apparent race conditions:

  • You need to run sudo nano /lib/systemd/system/bluetooth.service and replace

    ExecStart=/usr/lib/bluetooth/bluetoothd

    by

    ExecStart=/usr/lib/bluetooth/bluetoothd --noplugin=sap

    This disables the non-working SAP plugin, which is required to even make the BT service run.

  • You need to run sudo nano /lib/systemd/system/bthelper@.service and replace

    [Service]
Type=simple
ExecStart=/usr/bin/bthelper %I

    by

    [Service]
Type=simple
ExecStartPre=/bin/sleep 2
ExecStart=/usr/bin/bthelper %I
ExecStartPost=sudo /etc/init.d/bluetooth restart

    The ExecStartPre delays the start of bthelper, which fixes the privacy bug, and the ExecStartPost restarts the BT service very near the end of the booting sequence and after the now newly delayed bthelper, which for unknown reasons makes successful pairings possible.

After rebooting, sudo bluetoothctl works as expected with pair, trust, and connect on all my Bluetooth devices.

Sources: Peppe80, headsettrouble, days of trial and error on my part

Rupert Hölzl
  • 201
  • 2
  • 5
  • I can confirm this fixed Bluetooth for me (it would scan okay, but could previously connect to nothing) on a Pi4 running with raspberrypi-kernel 1:1.20220830-1, Debian 11.5 (linux kernel 5.15.61) which came from a lite install. Thanks so much Rupert! I appreciate the time and effort I know this took you. – Peter Hansen Jan 30 '23 at 02:01
  • 1
    Thanks, Peter, for confirming that this works on "lite" as well! And it is also interesting to hear that you made the experience that this is still necessary on newer OS versions. There were some reports claiming that the issue had been fixed on newer versions and these steps were no longer needed, but for me this was never the case. I still need the above fixes every time. – Rupert Hölzl Jan 31 '23 at 08:05
0

The issue with devices being recognized, but not pairing, was fixed.

Use the latest Raspberry Pi OS image (May 7th) and update.

Bluetooth devices are working now with the Raspberry Pi 4B.

nino
  • 21
  • 3
  • "Using the latest image..." should not be necessary; if you have two buster systems (ie., same OS version) and update them, they will contain the same core software regardless of when the original image was from. – goldilocks Aug 05 '21 at 18:33