BLE adapter silently hangs after hours of operation on Raspberry Pi Zero W (not a proxy bug)

[JohnnyFFM]

Background

This is not a bug in TeslaBleHttpProxy — the proxy itself works great. I'm opening this to share findings and see if other users (especially Pi Zero W users) have encountered this or found a workaround.

Hardware

• Device: Raspberry Pi Zero W Rev 1.1
• Bluetooth: Built-in Broadcom BCM43438, HCI 4.1, Bus: UART
• Kernel: 6.12.62+rpt-rpi-v6 (Raspbian Bookworm, latest as of 2026-03)
• BlueZ: 5.66
• Setup: Systemd service (not Docker), charging_manager role
• Integration: EVCC polling vehicle_data?endpoints=charge_state every ~2.5 minutes

Distance to car: 1 meter.

Problem

After approximately 5 hours of operation, the BLE adapter silently locks up. The proxy continues to receive HTTP requests, but BLE operations never execute. No errors or warnings are logged — requests just
silently hang.

Log pattern when working:

Received HTTP request (VehicleData)
VehicleData endpoint cache expired
Connecting to Vehicle ...
Scanning for vehicle ...
Beacon found
Creating vehicle object ...
Starting VCSEC session ...
Starting Infotainment session ...
Connection to vehicle established
Executing command (vehicle_data)
Successfully executed

Log pattern when hung:

Received HTTP request (VehicleData)
VehicleData endpoint cache expired
(nothing else — no scanning, no connecting, no errors)

The proxy accepts HTTP connections but times out without responding. Attempting sudo hciconfig hci0 reset returns:
Can't down device hci0: Device or resource busy (16)

The only fix is restarting the service first (sudo systemctl restart tesla), then resetting the adapter (sudo hciconfig hci0 reset).

What I've tried

• Kernel + firmware upgrade to latest Raspbian Bookworm packages (new kernel 6.12.62, new BT firmware) — did not fix the issue
• Added CAP_SYS_ADMIN ambient capability to the systemd service (in addition to CAP_NET_ADMIN) — did not fix the issue
• The issue appears related to the known go-ble/ble library problems discussed in Infinite loop in NewConnection teslamotors/vehicle-command#346 and TeslaBleHttpProxy gets into a bad state, eats memory and cpu #76

Current workaround

Restarting the systemd service + resetting the HCI adapter recovers the connection immediately.

Questions for other users

• Has anyone run this reliably on a Pi Zero W for extended periods (days/weeks)?
• Are there any BlueZ or kernel parameters that improve long-running BLE stability?

[pacioc193]

I used it for several hours without any issues with a fork. However, for the past few weeks, it has been hanging so badly. Because of this, I would like to reinstall it from scratch using the original project. But it seems that the tissue isn't the fork, is it?

[pacioc193]

Retry error error="failed to connect to vehicle (A): ble: failed to scan for xxxxxxxxxxxxxx: Command Disallowed"

This is my error... i put in place a script that reboot the bluetooth stack in case an error is present.

#!/bin/bash

BOT_TOKEN="YOUR_BOT_TOKEN"
CHAT_ID="YOUR_CHAT_ID"
MESSAGE="Tesla BLE Proxy: Bluetooth stack blocked. Resetting hci0."

ERRORS=$(journalctl -u teslablehttpproxy.service --since "5 minutes ago" | grep -c "Command Disallowed")

if [ "$ERRORS" -gt 0 ]; then
echo "Stack blocked detected. Sending alert and resetting..."

curl -s -X POST \"https://api.telegram.org/bot${BOT_TOKEN}/sendMessage\" \
    -d chat_id=\"${CHAT_ID}\" \
    -d text=\"${MESSAGE}\" > /dev/null

hciconfig hci0 down
sleep 2
hciconfig hci0 up

systemctl restart teslablehttpproxy.service

fi

[versendaal]

I'm also having issues with a Pi Zero W when using it in EVCC. After a while, it becomes somewhat unresponsive, can't read the battery state of the car and issue commands. So usually, i just give the Pi a reboot with my phone (ssh) before i plugin for the charge sessions.

[pacioc193]

I tried some fix in my fork :

https://github.com/pacioc193/TeslaBleHttpProxy

Could you confirm me that you are using a Charging Manager token and not an Owner Token?