Describe the issue you are experiencing
I am seeing a reproducible Bluetooth controller failure on Home Assistant OS
18.2 using the integrated Realtek RTL8821C controller (USB VID:PID 0bda:c821).
With four persistent BLE connections active, the Bluetooth controller
periodically fails. All four BLE links are lost essentially simultaneously,
the kernel reports btusb URB resubmit failures, and HAOS resets USB device
1-4. The RTL8821C is then reinitialized, its firmware is reloaded, and the
BLE devices reconnect.
I performed a controlled same-boot A/B/A test:
A1 - 4 persistent BLE connections, 5 s polling:
7 complete Bluetooth USB reset episodes in approximately 2 h 29 min.
B - 3 persistent BLE connections, 5 s polling:
approximately 40 h 50 min with no matching controller fault.
A2 - fourth connection re-enabled without rebooting the host:
10 complete Bluetooth USB reset episodes within approximately 6 h 21 min.
No host reboot was performed between the 3-device and 4-device phases.
The only intentional change was disabling and later re-enabling one BLE
device.
The BLE devices are four JBD battery-management systems. The application
performs read-only telemetry and serializes the GATT transactions, so the
four devices are not being polled concurrently at application level.
Reducing the polling interval load from 2 seconds to 5 seconds did not
eliminate the fault.
The issue has also been reported upstream to the Linux Bluetooth mailing
list. I can provide the lore.kernel.org thread link in Additional Information.
I am not claiming that four connections exceed an RTL8821C hardware limit.
The evidence shows that four persistent LE connections are a reproducible
exposing condition on this system.
What operating system image do you use?
generic-x86-64 (Generic UEFI capable x86-64 systems)
What version of Home Assistant Operating System is installed?
18.2
Did the problem occur after upgrading the Operating System?
No
Hardware details
Mini-PC, generic x86-64 bare-metal Home Assistant OS installation.
Bluetooth controller:
Realtek RTL8821C
USB VID:PID: 0bda:c821
lsusb:
Bus 001 Device 006: ID 0bda:c821 Realtek Bluetooth Radio
The Bluetooth controller is integrated in the mini-PC and is internally
connected via USB:
/sys/devices/pci0000:00/0000:00:15.0/usb1/1-4/1-4:1.0
It shares the Intel xHCI controller 0000:00:15.0 with another internal USB
device, but during the observed Bluetooth faults the kernel resets only
USB device 1-4, not the complete xHCI controller.
Kernel Bluetooth initialization:
Bluetooth: hci0: RTL: examining hci_ver=08 hci_rev=000c lmp_ver=08 lmp_subver=8821
Bluetooth: hci0: RTL: rom_version status=0 version=1
Bluetooth: hci0: RTL: loading rtl_bt/rtl8821c_fw.bin
Bluetooth: hci0: RTL: loading rtl_bt/rtl8821c_config.bin
Bluetooth: hci0: RTL: cfg_sz 10, total sz 34926
Bluetooth: hci0: RTL: fw version 0x75b8f098
Bluetooth: MGMT ver 1.23
Steps to reproduce the issue
-
Run Home Assistant OS 18.2 on generic-x86-64 with the integrated
Realtek RTL8821C Bluetooth controller (0bda:c821).
-
Maintain persistent BLE GATT connections to four JBD BMS devices.
-
Poll read-only telemetry every 5 seconds. Application-level BMS
transactions are serialized.
-
Leave all four BLE connections active.
-
After an irregular interval (from minutes to hours), observe that all
four BLE links are lost nearly simultaneously.
-
Check the host kernel log. Typical sequence:
Bluetooth: hci0: unexpected event for opcode 0xfc19
Bluetooth: hci0: urb ... failed to resubmit (2)
usb 1-4: reset full-speed USB device ... using xhci_hcd
Some events also contain:
Bluetooth: hci0: HCI reset during shutdown failed
Bluetooth: hci0: Opcode 0x0c03 failed: -110
-
After the USB reset, the RTL8821C is reinitialized and its firmware is
reloaded. The BLE devices subsequently reconnect.
Control test:
Disable one of the four BMS devices without rebooting the host.
With three persistent BLE connections the same system ran approximately
40 h 50 min without a matching controller fault.
Re-enable the fourth BMS without rebooting.
The controller fault reappears repeatedly.
Anything in the Supervisor logs that might be useful for us?
Nothing indicating the root cause in Supervisor logs.
The failure occurs below the Supervisor layer, in the Bluetooth/HCI/kernel
path. Home Assistant application logs mainly show the simultaneous loss of
the four BLE connections and subsequent reconnects.
Anything in the Host logs that might be useful for us?
Representative HAOS host kernel sequence:
[328062.316672] Bluetooth: hci0: unexpected event for opcode 0xfc19
[328064.313969] Bluetooth: hci0: HCI reset during shutdown failed
[328066.874086] Bluetooth: hci0: Opcode 0x0c03 failed: -110
[328066.956435] Bluetooth: hci0: urb 00000000ee8ad849 failed to resubmit (2)
[328067.079988] usb 1-4: reset full-speed USB device number 6 using xhci_hcd
A less severe occurrence:
[313301.505032] Bluetooth: hci0: urb 00000000589c932d failed to resubmit (2)
[313301.626468] usb 1-4: reset full-speed USB device number 6 using xhci_hcd
The first example demonstrates that the controller can also become
unresponsive to the standard HCI Reset command (0x0c03, ETIMEDOUT).
After the USB reset the kernel reloads rtl_bt/rtl8821c_fw.bin and
rtl_bt/rtl8821c_config.bin and Bluetooth operation resumes.
System information
System Information
| version |
core-2026.8.2 |
| installation_type |
Home Assistant OS |
| dev |
false |
| hassio |
true |
| docker |
true |
| container_arch |
amd64 |
| user |
root |
| virtualenv |
false |
| python_version |
3.14.6 |
| os_name |
Linux |
| os_version |
6.18.39-haos |
| arch |
x86_64 |
| timezone |
Europe/Zurich |
| config_dir |
/config |
Home Assistant Cloud
| logged_in |
false |
| can_reach_cert_server |
ok |
| can_reach_cloud_auth |
ok |
| can_reach_cloud |
ok |
HACS
| GitHub API |
ok |
| GitHub Content |
ok |
| GitHub Web |
ok |
| HACS Data |
ok |
| GitHub API Calls Remaining |
5000 |
| Installed Version |
2.0.5 |
| Stage |
running |
| Available Repositories |
4031 |
| Downloaded Repositories |
10 |
Home Assistant Supervisor
| host_os |
Home Assistant OS 18.2 |
| update_channel |
stable |
| supervisor_version |
supervisor-2026.07.5 |
| agent_version |
1.10.0 |
| docker_version |
29.6.2 |
| disk_total |
916.9 GB |
| disk_used |
161.3 GB |
| nameservers |
192.168.100.1 |
| healthy |
true |
| supported |
true |
| host_connectivity |
true |
| supervisor_connectivity |
true |
| ntp_synchronized |
true |
| virtualization |
|
| board |
generic-x86-64 |
| supervisor_api |
ok |
| version_api |
ok |
| installed_addons |
Matter Server (9.2.0), Samba share (12.10.0), SQLite Web (6.1.0), Grafana (12.1.0), Advanced SSH & Web Terminal (24.1.1), FTP (6.0.1), File editor (6.1.0), InfluxDB (5.0.2), Studio Code Server (6.0.1), Log Viewer (0.17.1), ESPHome Device Builder (2026.8.0) |
Dashboards
| dashboards |
3 |
| resources |
0 |
| views |
16 |
| mode |
storage |
Network Configuration
| adapters |
lo (disabled), enp2s0 (enabled, default, auto), docker0 (disabled), hassio (disabled), veth6477378 (disabled), veth028042b (disabled), veth0f52340 (disabled), veth4e7ce7d (disabled), vethcbdf3ab (disabled), veth172d36c (disabled), veth3823907 (disabled), vethd755e42 (disabled), vethaef56ed (disabled), vethc95bb12 (disabled), veth5c52628 (disabled) |
| ipv4_addresses |
lo (127.0.0.1/8), enp2s0 (192.168.100.12/24), docker0 (172.30.232.1/23), hassio (172.30.32.1/23), veth6477378 (), veth028042b (), veth0f52340 (), veth4e7ce7d (), vethcbdf3ab (), veth172d36c (), veth3823907 (), vethd755e42 (), vethaef56ed (), vethc95bb12 (), veth5c52628 () |
| ipv6_addresses |
lo (::1/128), enp2s0 (fe80::6722:cb21:798d:17d4/64), docker0 (fdee:314b:f7ad::1/64, fe80::a8e6:3bff:fefa:810c/64), hassio (fd0c:ac1e:2100::1/48, fe80::2454:9eff:fedd:3967/64), veth6477378 (fe80::844:c8ff:fe0e:27da/64), veth028042b (fe80::b0a9:faff:fe9e:ee2f/64), veth0f52340 (fe80::f4ec:dff:fe77:1442/64), veth4e7ce7d (fe80::14e7:d2ff:fecd:c558/64), vethcbdf3ab (fe80::5033:5bff:fe55:1f4c/64), veth172d36c (fe80::b818:c5ff:fede:1055/64), veth3823907 (fe80::c26:b5ff:fe12:7309/64), vethd755e42 (fe80::fcfc:ccff:fe11:c61/64), vethaef56ed (fe80::8414:c3ff:fea4:16ed/64), vethc95bb12 (fe80::b0b7:d0ff:fe56:149a/64), veth5c52628 (fe80::c08e:18ff:feb9:e3e4/64) |
| announce_addresses |
192.168.100.12, fe80::6722:cb21:798d:17d4 |
Recorder
| oldest_recorder_run |
23 giugno 2026 alle ore 11:28 |
| current_recorder_run |
23 agosto 2026 alle ore 09:25 |
| estimated_db_size |
15125.32 MiB |
| database_engine |
sqlite |
| database_version |
3.53.2 |
Additional information
Upstream Linux Bluetooth report:
https://lore.kernel.org/all/4_a5eV9Ms_joDG_tBnqf1zQ0bEV1lGmlPD51Icv3QcMVfTyqqDZgxiuaEzDCxf7sdYxD4sY8402l7bJBY8a7Lh-3AQcsFwtBaB51GQakTr4=@proton.me/
The upstream report contains the same A/B/A reproduction and kernel evidence.
Summary of the strongest reproduction result:
-
4 persistent BLE connections, 5 s polling:
repeated controller/USB reset failures.
-
3 persistent BLE connections, same host and same boot:
approximately 40 h 50 min without a matching controller fault.
-
Fourth persistent connection re-enabled without rebooting:
repeated controller failures returned, with 10 complete USB reset episodes
observed within approximately 6 h 21 min.
The observed kernel failure pattern includes:
Bluetooth: hci0: unexpected event for opcode 0xfc19
Bluetooth: hci0: HCI reset during shutdown failed
Bluetooth: hci0: Opcode 0x0c03 failed: -110
Bluetooth: hci0: urb ... failed to resubmit (2)
usb 1-4: reset full-speed USB device ... using xhci_hcd
Not every occurrence contains all of the lines above. In particular, some
events show the URB resubmit failure and USB reset without a visible 0xfc19
event beforehand.
The Bluetooth device is:
Realtek RTL8821C
USB VID:PID 0bda:c821
firmware: rtl_bt/rtl8821c_fw.bin
firmware version: 0x75b8f098
I can provide complete HA application logs and host dmesg logs if needed.
Describe the issue you are experiencing
I am seeing a reproducible Bluetooth controller failure on Home Assistant OS
18.2 using the integrated Realtek RTL8821C controller (USB VID:PID 0bda:c821).
With four persistent BLE connections active, the Bluetooth controller
periodically fails. All four BLE links are lost essentially simultaneously,
the kernel reports btusb URB resubmit failures, and HAOS resets USB device
1-4. The RTL8821C is then reinitialized, its firmware is reloaded, and the
BLE devices reconnect.
I performed a controlled same-boot A/B/A test:
A1 - 4 persistent BLE connections, 5 s polling:
7 complete Bluetooth USB reset episodes in approximately 2 h 29 min.
B - 3 persistent BLE connections, 5 s polling:
approximately 40 h 50 min with no matching controller fault.
A2 - fourth connection re-enabled without rebooting the host:
10 complete Bluetooth USB reset episodes within approximately 6 h 21 min.
No host reboot was performed between the 3-device and 4-device phases.
The only intentional change was disabling and later re-enabling one BLE
device.
The BLE devices are four JBD battery-management systems. The application
performs read-only telemetry and serializes the GATT transactions, so the
four devices are not being polled concurrently at application level.
Reducing the polling interval load from 2 seconds to 5 seconds did not
eliminate the fault.
The issue has also been reported upstream to the Linux Bluetooth mailing
list. I can provide the lore.kernel.org thread link in Additional Information.
I am not claiming that four connections exceed an RTL8821C hardware limit.
The evidence shows that four persistent LE connections are a reproducible
exposing condition on this system.
What operating system image do you use?
generic-x86-64 (Generic UEFI capable x86-64 systems)
What version of Home Assistant Operating System is installed?
18.2
Did the problem occur after upgrading the Operating System?
No
Hardware details
Mini-PC, generic x86-64 bare-metal Home Assistant OS installation.
Bluetooth controller:
Realtek RTL8821C
USB VID:PID: 0bda:c821
lsusb:
Bus 001 Device 006: ID 0bda:c821 Realtek Bluetooth Radio
The Bluetooth controller is integrated in the mini-PC and is internally
connected via USB:
/sys/devices/pci0000:00/0000:00:15.0/usb1/1-4/1-4:1.0
It shares the Intel xHCI controller 0000:00:15.0 with another internal USB
device, but during the observed Bluetooth faults the kernel resets only
USB device 1-4, not the complete xHCI controller.
Kernel Bluetooth initialization:
Bluetooth: hci0: RTL: examining hci_ver=08 hci_rev=000c lmp_ver=08 lmp_subver=8821
Bluetooth: hci0: RTL: rom_version status=0 version=1
Bluetooth: hci0: RTL: loading rtl_bt/rtl8821c_fw.bin
Bluetooth: hci0: RTL: loading rtl_bt/rtl8821c_config.bin
Bluetooth: hci0: RTL: cfg_sz 10, total sz 34926
Bluetooth: hci0: RTL: fw version 0x75b8f098
Bluetooth: MGMT ver 1.23
Steps to reproduce the issue
Run Home Assistant OS 18.2 on generic-x86-64 with the integrated
Realtek RTL8821C Bluetooth controller (0bda:c821).
Maintain persistent BLE GATT connections to four JBD BMS devices.
Poll read-only telemetry every 5 seconds. Application-level BMS
transactions are serialized.
Leave all four BLE connections active.
After an irregular interval (from minutes to hours), observe that all
four BLE links are lost nearly simultaneously.
Check the host kernel log. Typical sequence:
Bluetooth: hci0: unexpected event for opcode 0xfc19
Bluetooth: hci0: urb ... failed to resubmit (2)
usb 1-4: reset full-speed USB device ... using xhci_hcd
Some events also contain:
Bluetooth: hci0: HCI reset during shutdown failed
Bluetooth: hci0: Opcode 0x0c03 failed: -110
After the USB reset, the RTL8821C is reinitialized and its firmware is
reloaded. The BLE devices subsequently reconnect.
Control test:
Disable one of the four BMS devices without rebooting the host.
With three persistent BLE connections the same system ran approximately
40 h 50 min without a matching controller fault.
Re-enable the fourth BMS without rebooting.
The controller fault reappears repeatedly.
Anything in the Supervisor logs that might be useful for us?
Anything in the Host logs that might be useful for us?
System information
System Information
Home Assistant Cloud
HACS
Home Assistant Supervisor
Dashboards
Network Configuration
Recorder
Additional information
Upstream Linux Bluetooth report:
https://lore.kernel.org/all/4_a5eV9Ms_joDG_tBnqf1zQ0bEV1lGmlPD51Icv3QcMVfTyqqDZgxiuaEzDCxf7sdYxD4sY8402l7bJBY8a7Lh-3AQcsFwtBaB51GQakTr4=@proton.me/
The upstream report contains the same A/B/A reproduction and kernel evidence.
Summary of the strongest reproduction result:
4 persistent BLE connections, 5 s polling:
repeated controller/USB reset failures.
3 persistent BLE connections, same host and same boot:
approximately 40 h 50 min without a matching controller fault.
Fourth persistent connection re-enabled without rebooting:
repeated controller failures returned, with 10 complete USB reset episodes
observed within approximately 6 h 21 min.
The observed kernel failure pattern includes:
Bluetooth: hci0: unexpected event for opcode 0xfc19
Bluetooth: hci0: HCI reset during shutdown failed
Bluetooth: hci0: Opcode 0x0c03 failed: -110
Bluetooth: hci0: urb ... failed to resubmit (2)
usb 1-4: reset full-speed USB device ... using xhci_hcd
Not every occurrence contains all of the lines above. In particular, some
events show the URB resubmit failure and USB reset without a visible 0xfc19
event beforehand.
The Bluetooth device is:
Realtek RTL8821C
USB VID:PID 0bda:c821
firmware: rtl_bt/rtl8821c_fw.bin
firmware version: 0x75b8f098
I can provide complete HA application logs and host dmesg logs if needed.