Support/Implement full local BLE

[bjv]

Hi Peter,

referring to #1800, first thanks for your information.

Then, I would like to place the Feature Request to implement full local BLE support without any need of cloud telemetry or support.
These would keep costs low and also increase security since everything regarding the car is handled locally.

As from your words in #1800 I am not sure if you are aware, that it would be possible to keep TSC (including all relevant telemetry) completely local without any need of official telemetry, API, cloud or costs.

I (kind of) re-implemented TSC (my relevant features, "Überschussladen" and "MinSoC") locally with the help of https://github.com/tesla-local-control/tesla_ble_mqtt_docker and Home Assistant now.
Since the mentioned project offers all BLE telemetry and commands via MQTT, it may also be easy to integrate into TSC.

As a POC with this Projekt and HA, I went completely local and - sad to say - as a former supporter moved away from TSC.
If the project would have been in another language I would have done my implementations as a PR for TSC.

Instead I maybe will have to wait if local BLE Support will be coming.

Anyways, thanks a lot for all of your work; I had a great time using TSC so far.

[pkuehnel]

Is planned, currently the main issue is, that BLE is somewhat instable for some people (especially when trying to poll data while the car is away, so that's the main reason for Fleet Telemetry being implemented: Detection, if the car is at home), which is currently unknown why this happens, see

tesla-local-control/tesla_ble_mqtt_docker#67
tesla-local-control/tesla_ble_mqtt_core#142
The root cause is on Teslas underlaying BLE communication package, see
teslamotors/vehicle-command#272
teslamotors/vehicle-command#370
teslamotors/vehicle-command#353

Currently some people are working on fixing that. As soon as this is fixed, I will implement that including a bunch of other things like getting Soc for other car brands and OCPP integration. As this will be a major rework it will take some time. I want to be sure, that BLE is as stable as possible as I would rather not spend much time on debugging and support instead of further developing TSC, so implementation will come as soon as BLE is super stable.

Just as a notice: I never had these issues, but some have. Your linked project has the same issues.

[Lenart12]

Hi, I just want to offer my input since you mentioned 3 of my PRs in vehicle-command repo to add that I'm already using all the new features/fixes you talked about in my project https://github.com/Lenart12/TeslaBle2Mqtt which i specifically made because I was unhappy with how slow and unreliable tesla-local-control was. And so far it has been super stable (way more than tesla-local-control in my testing). Probably your best bet is to use TeslaBleHttpProxy and adapt it for full local BLE control as it is the least amount of work for you (first wimaha/TeslaBleHttpProxy#95 needs to gets merged).

[pkuehnel]

But you use the https://github.com/teslamotors/vehicle-command CLI as the underlying code for communication with the car, right? Which parameters do you use to call it in a stable way? Can you give me the source doe from your project? (I have absolutely no idea of Go)

Edit: I have a working HTTP proxy for BLE, which is currently closed source, due to the use of some packages with weird licensing rules, that require it to be closed source.

[Lenart12]

That's correct. The main benefit of using TeslaBleHttpProxy which uses vehicle-command over tesla-local-command (tlc) is that it does not keep recreating (resetting) the BT adapter connection which causes issues many issues on linux (see here). In contrast tlc by design can not reuse the same device "connection" because the vehicle-control utility can not do so and so for every command resets the adapter which causes issues.

My code is here https://github.com/Lenart12/TeslaBleHttpProxy

[pkuehnel]

My code is here https://github.com/Lenart12/TeslaBleHttpProxy

I meant the specific part where you are calling Tesla's tesla-control

[Lenart12]

It's used as an imported package https://github.com/Lenart12/TeslaBleHttpProxy/blob/08842367659954b2ffb9717e2322ccc0b55efe95/internal/ble/control/control.go#L293-L347

[pkuehnel]

In contrast tlc by design can not reuse the same device "connection" because the vehicle-control utility can not do so and so for every command resets the adapter which causes issues.

Does this mean TeslaBleHttpProxy does not support multiple VINS at the same time?

[Lenart12]

It does support multiple VINs, I mean BT "connection" as in socket to unrelying HCI device, which can then support multiple clients.

[pkuehnel]

Thanks for your input, will look into it.