[SOLVED] How to automatically reconnect to the Bluetooth audio device used before of reboot or shutdown, just like Windows or Android?

Imagine that you have a set of Bluetooth speakers, connected to your computer via a Bluetooth adapter.

With the note about the usage of bleeding edge Slackware-current.

This works absolutely fine, no mater which audio server I use, be it PulseAudio or PipeWire. However, there's a caveat:

I should manually reconnect the speakers from Bluetooth panel from system tray of Plasma5. At every reboot or shutdown.

Then, there is the question from the title: once connected to a Bluetooth audio device, how can be configured the Bluetooth to auto-reconnect to this particular device after the system restart or shutdown?

Windows does this. Android does this. Probably also MacOS/X does this.

Did you do pair and trust? The device should be on or active on start up.

I don't know about Bluetooth speakers, mine are wired, but my Bluetooth mouse automatically connects on my laptop. It is paired and trusted.

Originally Posted by PROBLEMCHYLD Did you do pair and trust?

Of course.

Originally Posted by PROBLEMCHYLD The device should be on or active on start up.

At least this says the theory, and I read also in another places that that should happen.

BUT, this does not happens. Like I said, I should connect the device manually.

[bluetooth]# list
Controller 00:1A:7D:DA:71:0A BlueZ 5.56 [default]
[KN330]# show
Controller 00:1A:7D:DA:71:0A (public)
        Name: BlueZ 5.56
        Alias: BlueZ 5.56
        Class: 0x007c0104
        Powered: yes
        Discoverable: no
        DiscoverableTimeout: 0x000000b4
        Pairable: yes
        UUID: Message Notification Se.. (00001133-0000-1000-8000-00805f9b34fb)
        UUID: A/V Remote Control        (0000110e-0000-1000-8000-00805f9b34fb)
        UUID: OBEX Object Push          (00001105-0000-1000-8000-00805f9b34fb)
        UUID: Message Access Server     (00001132-0000-1000-8000-00805f9b34fb)
        UUID: PnP Information           (00001200-0000-1000-8000-00805f9b34fb)
        UUID: IrMC Sync                 (00001104-0000-1000-8000-00805f9b34fb)
        UUID: Headset                   (00001108-0000-1000-8000-00805f9b34fb)
        UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb)
        UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
        UUID: Phonebook Access Server   (0000112f-0000-1000-8000-00805f9b34fb)
        UUID: Audio Sink                (0000110b-0000-1000-8000-00805f9b34fb)
        UUID: Device Information        (0000180a-0000-1000-8000-00805f9b34fb)
        UUID: Generic Access Profile    (00001800-0000-1000-8000-00805f9b34fb)
        UUID: Handsfree Audio Gateway   (0000111f-0000-1000-8000-00805f9b34fb)
        UUID: Audio Source              (0000110a-0000-1000-8000-00805f9b34fb)
        UUID: OBEX File Transfer        (00001106-0000-1000-8000-00805f9b34fb)
        Modalias: usb:v1D6Bp0246d0538
        Discovering: no
        Roles: central
        Roles: peripheral
Advertising Features:
        ActiveInstances: 0x00 (0)
        SupportedInstances: 0x05 (5)
        SupportedIncludes: tx-power
        SupportedIncludes: appearance
        SupportedIncludes: local-name
[bluetooth]# devices
Device 6B:F1:3B:8C:C2:FE KN330
[KN330]# info 6B:F1:3B:8C:C2:FE   
Device 6B:F1:3B:8C:C2:FE (public)
        Name: KN330
        Alias: KN330
        Class: 0x00240404
        Icon: audio-card
        Paired: yes
        Trusted: yes
        Blocked: no
        Connected: yes
        LegacyPairing: no
        UUID: Serial Port               (00001101-0000-1000-8000-00805f9b34fb)
        UUID: Audio Sink                (0000110b-0000-1000-8000-00805f9b34fb)
        UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb)
        UUID: Advanced Audio Distribu.. (0000110d-0000-1000-8000-00805f9b34fb)
        UUID: A/V Remote Control        (0000110e-0000-1000-8000-00805f9b34fb)

This is what says the bluetoothctl.

BTW, if matters, the Bluetooth speakers are in fact an Chinese soundbar, powered via USB and having a wire and connector to connect directly at a computer Line-Out, and which was sold also with a Bluetooth adapter, also powered via USB.

Apparently, the Bluetooth adapter works as expected, and Windows 10 does fine what I expect to do, as in thread's title - autoconecting the previous connected devices on startup.

On the computer side is a (cheap) Chinese Bluetooth USB adapter for PC, if this also matters.

With the note that I have other Bluetooth adapters, and no matter which adapters combination I did, the auto-connection on reboot is done only on Windows. Tested on multiple computers.

@LuckyCyborg

Unfortunately, the Bluetooth audio devices get a different behavior compared with the Bluetooth mouses or keyboards.

From what I understand, this happens because those Bluetooth audio devices should be connected AFTER the audio server starts, otherwise the connection will fail.

How usually both PulseAudio and PipeWire servers are started on user login by the XDG autostart, probably the best place to issue a Bluetooth re-connection command is after they are started, then either will be directly by the DE or via XDG autostart.

So, a possible way to issue a re-connection command could be via a XDG autostart desktop file, like this:

/etc/xdg/autostart/bluetooth-speakers.desktop

[Desktop Entry]
Version=1.0
Name=Bluetooth Speakers
Comment=Connect the Bluetooth Speakers
Exec=/bin/sh -c 'sleep 1; echo "connect <BLUETOOTH_DEVICE_MAC>" | bluetoothctl'
Terminal=false
Type=Application
X-GNOME-Autostart-Phase=Initialization
X-KDE-autostart-phase=1

This sleeping for 1 second is needed for leaving time for the audio server to be started too, otherwise the device re-connection will silently fail.

This XDG desktop file is what I use myself, but probably there could be better ways, like enumerating somehow the connected Bluetooth devices on desktop shutdown and storing the result somewhere, then issuing the re-connection on the next login.

Originally Posted by ZhaoLin1457 @LuckyCyborg Unfortunately, the Bluetooth audio devices get a different behavior compared with the Bluetooth mouses or keyboards. From what I understand, this happens because those Bluetooth audio devices should be connected AFTER the audio server starts, otherwise the connection will fail. How usually both PulseAudio and PipeWire servers are started on user login by the XDG autostart, probably the best place to issue a Bluetooth re-connection command is after they are started, then either will be directly by the DE or via XDG autostart. So, a possible way to issue a re-connection command could be via a XDG autostart desktop file, like this: /etc/xdg/autostart/bluetooth-speakers.desktop [Desktop Entry] Version=1.0 Name=Bluetooth Speakers Comment=Connect the Bluetooth Speakers Exec=/bin/sh -c 'sleep 1; echo "connect <BLUETOOTH_DEVICE_MAC>" | bluetoothctl' Terminal=false Type=Application X-GNOME-Autostart-Phase=Initialization X-KDE-autostart-phase=1 This sleeping for 1 second is needed for leaving time for the audio server to be started too, otherwise the device re-connection will silently fail. This XDG desktop file is what I use myself, but probably there could be better ways, like enumerating somehow the connected Bluetooth devices on desktop shutdown and storing the result somewhere, then issuing the re-connection on the next login.

Well, honestly I hoped for a configuration trick, BUT your explanation makes sense and this XDG autostart file does the job.

Thank you very much!