Bluetooth BLE not accessible via HA under DietPi

Creating a bug report/issue

I have searched the existing open and closed issues

Required Information

  • DietPi version | 9.19.2
  • Distro version | bookworm
  • Kernel version | 6.1.115-vendor-rk35xx
  • Architecture | arm64
  • SBC model | Orange Pi 5 (aarch64)

Additional Information (if applicable)

  • Software title | Home Assistant & HACS integration ha-ble-adv

Steps to reproduce

  1. Install HACS repository in Home Assistant
  2. Install ha-ble-adv integration in HACS
  3. Add Bluetooth adapter
  4. Use ha-ble-adv integration
  5. Expected behaviour

The integration should run,

Actual behaviour

Integration is aborted with “No Bluetooth adapter supporting BLE Advertising has been found.” Dump reveals:

{
  "home_assistant": {
    "installation_type": "Unknown",
    "version": "2025.7.1",
    "dev": false,
    "hassio": false,
    "virtualenv": false,
    "python_version": "3.13.5",
    "docker": false,
    "arch": "aarch64",
    "timezone": "Europe/Berlin",
    "os_name": "Linux",
    "os_version": "6.1.115-vendor-rk35xx",
    "run_as_root": false
  },
  "manifest": {
    "domain": "ble_adv",
    "name": "BLE ADV Ceiling Fan / Lamps",
    "after_dependencies": [
      "esphome"
    ],
    "codeowners": [
      "NicoIIT"
    ],
    "config_flow": true,
    "documentation": "https://github.com/NicoIIT/ha-ble-adv",
    "integration_type": "device",
    "iot_class": "assumed_state",
    "issue_tracker": "https://github.com/NicoIIT/ha-ble-adv/issues",
    "requirements": [
      "pycryptodome",
      "btsocket"
    ],
    "version": "v1.8.3",
    "is_built_in": false,
    "overwrites_built_in": false
  },
  "coordinator": {
    "hci": {
      "adapters": {},
      "ids": {},
      "logs": [],
      "supported_by_host": false
    },
    "esp": {
      "adapters": {},
      "ids": {},
      "logs": [
        "2025-12-02 16:48:02.493293 - BLE ADV Name Entities: []"
      ]
    },
    "ign_adapters": [],
    "ign_duration": 60000,
    "ign_cids": [
      65231,
      64903,
      65162,
      65163,
      64908,
      64918,
      65049,
      65183,
      65184,
      65061,
      65062,
      65063,
      65194,
      65068,
      64689,
      64822,
      65223,
      65224,
      65225,
      65226,
      65227,
      65228,
      65229,
      65230,
      64719,
      65104,
      65233,
      65234,
      65235,
      65236,
      65109,
      65110,
      64598,
      65240,
      65232,
      64994,
      64867,
      64866,
      64879,
      65008,
      64753,
      65267,
      65268,
      64627
    ],
    "ign_macs": [],
    "last_emitted": {},
    "last_unk_raw": {},
    "last_dec_raw": {}
  },
  "entries": {},
  "flow": [
    "2025-12-02 16:57:14.844611 - Config flow 'user' started."
  ]
}

Extra details

I have tried to get the ha-ble-adv integration working under DietPi, however, while the Bluetooth adapter is detected in DietPi, it cannot be used in the integration. The troubleshooting on Home · NicoIIT/ha-ble-adv Wiki · GitHub says that:

In order to be able to work, this component needs to be able to send RAW Bluetooth LE Advertising messages, as most of the protocols used are NOT following BLE ADV standards:
Service UUIDs used in improper ways, leading in merged messages
Devices not supporting trailing AD Flag part (as implemented by Bluez)

As a consequence, the Bluez stack as exposed via dbus is not usable as such, nor is the HA Bluetooth stack based on Bluez, and not allowing Advertising.
In order to bypass those limitations, the component is directly connecting to the Bluetooth HCI socket in order to be able to advertise RAW messages as well as listening to raw advertisements emitted by external controllers (Phone Apps, Physical remotes). In a docker container this is only possible if the container has an allowed access to the Bluetooth HCI Socket, which means:
Container is running ‘root’ as user, or in ‘privileged’ mode
Container is in network mode ‘host’
This should be the case in a standard HA installation, but if you have a particular install, then it will not work.
The solution is simply to tunnel the communications with the Bluetooth HCI Socket to another docker container running root / host network via a Unix Socket on a docker volume mounted by both docker containers:
HA Container(non root, non network ‘host’) ↔ Docker Volume ↔ Tunnel Container(root, ‘host’ network) ↔ Bluetooth HCI Socket
In fact, this is just a low cost dbus… The goal is only to have a workaround, the clean solution would be to have the Raw Advertising available in bluez via dbus."

However DietPi is not installed in docker but as HA Core, so what might be the issue here, how can in tunnel my connection running DietPi?

I know this is quite a niche issue but I have tried everything I could and the issue seems to be something with the DietPi Core version not allowing BLE communication, is there a way to grant permission for this?

Any help is much appreciated. I’m pretty new to this tbh.

Did you enable Bluetooth via dietpi-config? AFAIU Bluez is not needed, but the kernel modules need to be enabled.

No tunnelling or such needed, as HA core sits on the host directly in our case.

yes, Bluetooth is activated and the controller shows up under bluetoothctl list. Adapter is also detected by Home Assistant but not by the HACS integration

Is it possible that the kernel does not support HCI raw?

hcitools works at least, no idea about RAW though, how would I check that?

I’m not sure, do you have the file /proc/config.gz ?
And you can also try

hciconfig -a

which will show supported features of your device, with does not necessarily mean the that kernel can use them.

And you can check enabled modules with lsmod

Kernel build config is at /boot/config-6.1.115-vendor-rk35xx.

Since it is the vendior kernel, possible that there is some limitation. I don’t know the respective kernel setting, but if that turns out to be unset or no, the mainline kernel could be tested instead. Just VPU integration is still limited: no RKMMP.

Yes, the file is there.

hciconfig -a

Type: Primary Bus: USB
BD Address: [BLURRED] ACL MTU: 310:10 SCO MTU: 64:8
UP RUNNING
RX bytes:1306877 acl:0 sco:0 events:30198 errors:0
TX bytes:2773 acl:0 sco:0 commands:63 errors:0
Features: 0xff 0xff 0x8f 0xfe 0xdb 0xff 0x5b 0x87
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH HOLD SNIFF PARK
Link mode: PERIPHERAL ACCEPT
Name: ‘DietPi’
Class: 0x400000
Service Classes: Telephony
Device Class: Miscellaneous,
HCI Version: 4.0 (0x6) Revision: 0x22bb
LMP Version: 4.0 (0x6) Subversion: 0x22bb
Manufacturer: Cambridge Silicon Radio (10)

Bluetooth adapter works, is found in HA and can be used but cannot be detected by the ble-adv HACS repository.

lsmod looks ok as well

rfcomm 61440 2
btusb 53248 0
btmtk 16384 1 btusb
btrtl 24576 1 btusb
btbcm 24576 1 btusb
btintel 36864 1 btusb
bnep 24576 2
cifs 630784 2
cifs_arc4 16384 1 cifs

Found the following in the kernel build config:

# Bluetooth device drivers
#
CONFIG_BT_INTEL=m
CONFIG_BT_BCM=m
CONFIG_BT_RTL=m
CONFIG_BT_QCA=m
CONFIG_BT_MTK=m
CONFIG_BT_HCIBTUSB=m
CONFIG_BT_HCIBTUSB_AUTOSUSPEND=y
CONFIG_BT_HCIBTUSB_BCM=y
CONFIG_BT_HCIBTUSB_MTK=y
CONFIG_BT_HCIBTUSB_RTL=y
CONFIG_BT_HCIBTSDIO=m
CONFIG_BT_HCIUART=m
CONFIG_BT_HCIUART_SERDEV=y
CONFIG_BT_HCIUART_H4=y
# CONFIG_BT_HCIUART_NOKIA is not set
CONFIG_BT_HCIUART_BCSP=y
CONFIG_BT_HCIUART_ATH3K=y
# CONFIG_BT_HCIUART_LL is not set
CONFIG_BT_HCIUART_3WIRE=y
CONFIG_BT_HCIUART_INTEL=y
CONFIG_BT_HCIUART_BCM=y
CONFIG_BT_HCIUART_RTL=y
CONFIG_BT_HCIUART_QCA=y
CONFIG_BT_HCIUART_AG6XX=y
# CONFIG_BT_HCIUART_MRVL is not set
CONFIG_BT_HCIBCM203X=m
CONFIG_BT_HCIBPA10X=m
CONFIG_BT_HCIBFUSB=m
CONFIG_BT_HCIVHCI=m
CONFIG_BT_MRVL=m
CONFIG_BT_MRVL_SDIO=m
CONFIG_BT_ATH3K=m
CONFIG_BT_MTKSDIO=m
# CONFIG_BT_MTKUART is not set
# CONFIG_BT_VIRTIO is not set
CONFIG_BT_HCIBTUSB_RTLBTUSB=m
# end of Bluetooth device drivers

Any issues there? I still feel like the main issue is that the HACS repository detects HA as non-root. I tried with an esp-proxy as well, is detected by HA Core but not by the HACS repository, so I cannot use it.

Maybe the way it tries to access the Bluetooth device/socket requires additional permissions.

… hmm yeah, the HCI does not appear as device node or so, but raw access is done via socket which requires CAP_NET_RAW it seems. Not ideal security-wise, but if this is how HACS needs it:

sudo mkdir /etc/systemd/system/home-assistant.service.d
echo -e '[Service]\nAmbientCapabilities=CAP_NET_RAW' | sudo tee /etc/systemd/system/home-assistant.service.d/ble_hci_access.conf
sudo systemctl daemon-reload
sudo systemctl restart home-assistant

Did not fix it unfortumately, Problem persists, diagnostics dump also unchanged