I've tested this over various Raspberry Pi's(Pi Zero and Pi 2) and different versions of Raspbian lite(Latest to oldest version from 2015) and different versions of BlueZ (5.23, 5.43, 5.49). I have also tested this on multiple cheap CSR 4 USB Bluetooth devices as well as an ancient USB Bluetooth 2.1 module.

The issue is that when I change the Bluetooth class to 0x20041C (for a project of turning the Pi into a Bluetooth speaker), it always switches to 0x00041C and ignores my suggested Service Class part of the class identifier.

What I've been doing for changing the Bluetooth class is as so: I add Class = 0x20041C to both the file /etc/bluetooth/main.conf as well as the config specific to my Bluetooth device /var/lib/bluetooth/<MACADDRESS OF BLUETOOTH>/config. After that I restart the Pi to update the Bluetooth changes, and when I run hciconfig -a it shows the class for HCI0 (my USB bluetooth device) as 0x00041C. Even running

sudo hciconfig hci0 class 0x20041C

temporarily changes it, but once I restart the bluetooth service the Class just goes right back to 0x00041C.

As far as I'm aware there isn't anything that I am doing differently than all of the other countless tutorials online for working with Bluetooth on the Pi (as well as making bluetooth speakers with it) and I don't understand why my case is any different and causes this weirdly simple error.


/var/lib/bluetooth/settings is going to be volatile. If you change it there, it will be reverted back to original configuration.

In your /etc/systemd/system/ you should see a dbus-org.bluez.service which is symlinked and aliased from the /lib/system/system/bluetooth.service file.

If the service type is dbus, then you might want to configure it in there.

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.