Bug fixes, missing commands and endpoints

[Lenart12]

This pull request includes several updates to the TeslaBleHttpProxy project. It changes quite a bit of things and is fairly large. The most important changes are summarized below:

Code Refactoring:

• Scan for vehicle BLE advertisements to check for vehicle presence and abort quickly if none are detected, using my contributions to vehicle-command repository.
• Expose BLE connection status via /api/proxy/1/vehicles/VIN/connection_status. Closes Add BT information #78
• Refactored the internal/api/handlers/tesla.go to make sure all endpoints use operated connection command processing logic, including body-controller-state.
• Moved body-controller-state endpoint to /api/proxy/1/vehicles/VIN/body_controller_state to be consistent with naming scheme. Moved wake_up to /api/1/vehicles/VIN/wake_up to be consistent with Tesla API.
• Implemented most of the missing fleet commands and added stubs for missing/unsupported ones
• Simplified json formatting for vehicle_data and added missing categories. Added manual json formatting for body-controller-state, fixes vehicleLockState missing for unlocked vehicle? #87 .
• Removed unused imports and redundant code in internal/api/handlers/tesla.go.
• Fixed an issue where a command would retry forever and block other commands if it was slow enough. Also fixed retries if connection expires.
• Work around a bug where starting infotainment session after car wake up would never finish.
• Allow wake_up command to wait for car to wake up with wait=true parameter
• Command line interface with backwards compatibility.
• Allow changing keys directory.
• Support proxy base url and X-Ingress-Path for running this app behind a reverse proxy.

Configuration Enhancements:

• Introduced a new scanTimeout configuration parameter in config/config.go to control the scan duration for BLE beacons.
• Updated the cacheMaxAge environment variable default value in the README.md to 5 seconds.
• Introduced keys parameter to allow reading keys from a different directory.
• Introduced dashboardBaseUrl and apiBaseUrl for configuring paths when running behind a reverse proxy.

Dependency Updates:

• Updated the github.com/teslamotors/vehicle-command dependency in go.mod to a newer version.
• Removed outdated replace directives for dependencies in go.mod, since go_bleConnectFix is now not neccesary anymore :^)

Documentation Updates:

• Updated the README.md to include a reference to TeslaBle2Mqtt and added a comprehensive list of supported endpoints for vehicle data.
• Simplified the list of supported vehicle commands and provided an example of how to use the wait parameter.
• Added a new section for BLE connection status in the README.md.
• Added a new section for installing the addon through a home assistant repository. Closes Home Assistant Add-On #82

[wimaha]

Thank you for all if this! I will Review when I‘m back Home.

[balgerion]

Gents, is this PR still going to be implemented/merged, or has the plan changed and it's no longer relevant?

[Lenart12]

I'm now providing builds for this PR, for both versions of the bluetooth library.
Docker images
Binaries

Using raw hci communication or bluez: add the -bluez suffix to any tag name.
docker pull ghcr.io/lenart12/teslablehttpproxy:latest
or
docker pull ghcr.io/lenart12/teslablehttpproxy:latest-bluez

[AloisKlingler]

ghcr.io/lenart12/teslablehttpproxy:latest-bluez

no matching manifest for linux/arm/v6 in the manifest list entries
:-/

[Lenart12]

Arm v6 has been largely end of life/support for 3 years now... What devices are you using?

[AloisKlingler]

Arm v6 has been largely end of life/support for 3 years now... What devices are you using?

rpi zero1 uses armv6. it is ultra lightweight, cheap and electricity saving. ;-)

[Lenart12]

I added it :^) thanks for that info!

[AloisKlingler]

I'm now providing builds for this PR, for both versions of the bluetooth library. Docker images Binaries

Using raw hci communication or bluez: add the -bluez suffix to any tag name. docker pull ghcr.io/lenart12/teslablehttpproxy:latest or docker pull ghcr.io/lenart12/teslablehttpproxy:latest-bluez

running here.
FYI, also the one without -bluez asked for bluez:

2025/04/29 14:38:30 INFO TeslaBleHttpProxy v3.0.1-bluez is loading ...
2025/04/29 14:38:31 FATA Failed to initialize Bluetooth adapter: err="ble: failed to enable device: could not activate BlueZ adapter: Unit dbus-org.bluez.service not found."

I started bluetooth service (which was with previous implementation not necessary) and is running now.

in my docker-compose:
#image: wimaha/tesla-ble-http-proxy
image: ghcr.io/lenart12/teslablehttpproxy:latest

followed by compose up -d with fresh pulling.

[Lenart12]

Yes, I noticed this. I'm working on a fix. In the meantime you can use tag 3, 3.0 or 3.0.1 instead. Sorry :/

[balgerion]

Im using your fork of http proxy for EVCC and tesla MQTT so
Two questions:
Does it work together with EVCC? I can validate the car from EVCC — is there any conflict over the Bluetooth connection?

Does it let the car sleep? It seems to be constantly sending BLE connections to the car.
Edit: The car is sleeping fine, so just question about EVCC

[Lenart12]

@AloisKlingler using latest tag is fixed. Thanks for the heads up!

@balgerion Support with EVCC is mixed even with wimaha version. You can use it for vehicle, but not for charger (see here evcc-io/evcc#18194). And it will constantly wake the car. Just the way evcc + this proxy interract. TeslaBle2Mqtt is made with this proxy in mind, so it can be smarter about waking the car. Maybe you can look in to using MQTT to connect to evcc instead. (If you do please open a issue on TB2M repository and I can add it as an example)

It's not compatible as a api urls changed/moved to be the same as tesla fleet api, so you would need to modify the existing tesla-ble template - fairly easy to do so.

[balgerion]

@Lenart12 I've been using TeslaBleHttpProx with https://github.com/Haveacry/twc3teslamate as a "charger" in EVCC for the past 5 months without any issues. It doesn't wake my car – it just works.
Your fork can validate the car using the Tesla BLE template. I can test charging tomorrow.

[bicaluv]

@Lenart12 :

I'm now providing builds for this PR, for both versions of the bluetooth library. Docker images Binaries

Using raw hci communication or bluez: add the -bluez suffix to any tag name. docker pull ghcr.io/lenart12/teslablehttpproxy:latest or docker pull ghcr.io/lenart12/teslablehttpproxy:latest-bluez

May I ask, what are the differences / advantages of using bluez over hci?

[bicaluv]

@Lenart12:

And another question: Will I have to change evcc config because of the API changes you made?
E.g.: api/1/vehicles/VIN/wake_up instead of the former /api/1/vehicles/{{ .vin }}/command/wake_up which is used in evcc Tesla BLE template implementation?

[balgerion]

@bicaluv Did you have time to modify BLE template or create a custom MQTT charger in EVCC? I can look into it tomorrow, but if you have a working solution, I’d gladly just copy it.

[balgerion]

ok i started to working on custom template for evcc but

This is Lenart12 fork -- Spaming so many commands that bluetooth dosent have time to process them

Wimha:

[bicaluv]

@balgerion : Which BLE driver do you use? I'm using the hci implementation and do not see this much of calls.
But too sad, can't use it anyway, because of:

2025/05/01 11:25:10 INFO connecting to Vehicle ...
2025/05/01 11:25:10 WARN failed to connect to vehicle (A): the vehicle is already connected to the maximum number of BLE devices

Which is common to our situation where 4 people have access to the car using the iPhones and where all 4 may be around the driveway, where the car is parked.

[bicaluv]

Using blueZ or hci I get some errors:

2025/05/01 11:49:53 INFO connecting to Vehicle ...
2025/05/01 11:49:54 ERRO can't connect to vehicle error="vehicle not in range: ble: failed to scan for LRXXXXX: context deadline exceeded"

BT devices is only 50 cm from car and the error does only occur every now and then.
Noticed that it happens every 2 minutes.
Using hci, it takes much more attempt to reestablish a valid connection, while using blueZ only one retry is necessary.

[balgerion]

In my case, HCI is spamming commands. The Bluetooth device is 5 meters away from the car, but this hasn’t been an issue with the Wimha version — it’s been rock-solid for 5 months of daily use.

BlueZ performs better overall, but it’s not stable and throws some strange errors.

[Lenart12]

@balgerion can you send me more logs about this behaviour and how to recreate it. You can make an issue on my fork.