BLE API issues with configuration

[Lord225]

Hello, I'm unable to get bleapi to work properly. Hardware: Raspberry Pi 4 (B) I tried configuring it with the docker-compose provided in the README, but it throws a "connection refused" error. I had to create a network and set the driver to host. Now, I am able to reach the service.

  bleapi:
    image: ghcr.io/pkuehnel/teslasolarchargerbleapi:latest
    container_name: TeslaSolarChargerBleApi
    privileged: true
    restart: unless-stopped
    networks:
      - network
    environment:
      - ASPNETCORE_URLS=http://+:7210
    volumes:
      - /home/lord225/tscbleapi:/externalFiles
      - /var/run/dbus:/var/run/dbus
networks:
  network:
    driver: host

but unfortunately, it still displays an error message about hci not being able to crate socket.

      Error: failed to find a BLE device: can't init hci: can't create socket: address family not supported by protocol

ble-logs.txt

lord225@raspberrypi:~ $ systemctl status bluetooth
● bluetooth.service - Bluetooth service
     Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; preset: enabled)
     Active: active (running) since Sun 2024-07-21 17:14:13 CEST; 16h ago
       Docs: man:bluetoothd(8)
   Main PID: 5563 (bluetoothd)
     Status: "Running"
      Tasks: 1 (limit: 1576)
        CPU: 934ms
     CGroup: /system.slice/bluetooth.service
             └─5563 /usr/libexec/bluetooth/bluetoothd

lord225@raspberrypi:~ $ ls /var/run/dbus
containers  system_bus_socket

lord225@raspberrypi:~ $ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 12 (bookworm)
Release:        12
Codename:       bookworm
lord225@raspberrypi:~ $  uname -a
Linux raspberrypi 6.6.20+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.6.20-1+rpt1 (2024-03-07) aarch64 GNU/Linux

I also tried older images of bleapi but same result. I checked stack stuff from stack exchange but nothing seem to help mabe you can identify the issue & help to find solution.

[Lord225]

I tried to execute curl in docker container(as below)

  bleapi:
    image: ghcr.io/pkuehnel/teslasolarchargerbleapi:latest
    container_name: TeslaSolarChargerBleApi
    privileged: true
    restart: unless-stopped
    network_mode: host
    environment:
      - ASPNETCORE_URLS=http://0.0.0.0:7210
    volumes:
      - /home/lord225/tscbleapi:/externalFiles
      - /var/run/dbus:/var/run/dbus

And indeed issue persists

(inside container)
root@raspberrypi:/app# curl http://localhost:7210/api/Pairing/PairCar?vin=XP7YGCEKXDB214743
Error: failed to find a BLE device: can't init hci: can't create socket: address family not supported by protocol

[pkuehnel]

Sorry I can not help you debugging the issue. I am just using Teslas Command CLI tool and have no idea what is happening inside of it. What I can tell: On a clean install of Raspbian OS on a Raspberry Pi 4 it is working.

[Lord225]

I figured out that it is a Docker issue. When I run vehicle-control on bare metal, it works "fine." So, if someone has trouble with this, I suggest trying to run tesla-control natively. I might share a script that connects to the API and allows integration with TeslaSolarCharger with python for example (my current state)

Also running it nativly shows an solution for that can't init hci error.

(from tesla-control)
Try again after granting this application CAP_NET_ADMIN:

        sudo setcap 'cap_net_admin=eip' "$(which tesla-control)"

add_cap:
 - NET_ADMIN

did not solve the issue.

I would like to ask for exac Raspbian version bsc you can install like 3 diffrent ones from Raspberry Imager alone

However, I found a new issue and am confused about how to approach it. My colleague is reporting the following error:

Error: failed to find BLE beacon for XP7YGCEKXPB214752 (S7f957137799819efC): can't scan: context deadline exceeded

This error occurs repeatedly. I'm not sure why it happens, as it is quite random. Sometimes BLE works fine, and I can honk, set amps, and start/stop charging without issues. Other times, the car just ignores the commands. I suspect it might be some kind of "DDoS" protection on the car's BLE or BLE connection issues.

I found out the hard way that TeslaSolarCharger will not back off BLE requests if they fail one after another, causing it to spam with requests. I suggest adding a feature in private async Task<DtoGenericTeslaResponse?> SendCommandToTeslaApi in TeslaFleetApiService.cs code to prevent BLE requests if the previous one failed. One simple solution might be to just store timestamp of last failed ble request (lines 511, 520 ect) and check in 499 if last failed request was in specific timeframe (configurable?) (if it was, fallback to FleetAPI). It will add some reliability and prevent system from freezing

[Lord225]

If you find this suggestion worthy, I might create a pull request. However, it involves only about 10 lines of code so setting env just for that will be painfull.

[pkuehnel]

I would like to ask for exac Raspbian version bsc you can install like 3 diffrent ones from Raspberry Imager alone

I used the default Raspberry Pi OS 64 bit from the official Raspberry Pi Imager.

However, I found a new issue and am confused about how to approach it. My colleague is reporting the following error:

Error: failed to find BLE beacon for XP7YGCEKXPB214752 (S7f957137799819efC): can't scan: context deadline exceeded

The error should come up if the Raspberry cannot find the car, e.g. because it is too far away. I am not sure why, but some told me it works about 15 meters away from the car. My experience is that everything further than 4–5 meters away or any wall between Raspberry and car leads to issues.

I found out the hard way that TeslaSolarCharger will not back off BLE requests if they fail one after another, causing it to spam with requests. I suggest adding a feature in private async Task<DtoGenericTeslaResponse?> SendCommandToTeslaApi in TeslaFleetApiService.cs code to prevent BLE requests if the previous one failed.

The BLE implementation was just a quick and super dirty fix regarding the rate limits. There is no error handling at all, and the user does not get any information about the errors. As soon as I have time, I will resolve these issues.