1

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

4
  • 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 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 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 at 16:50
  • Post more info about your device model. Use the command below cat /proc/cpuinfo – Rafael Pereira Ramos Apr 19 at 0:02
2

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.