Bluetooth Low Energy and TWCManager

[ChutneyMary]

I've been reading the attached article and wondered if this has been considered for TWCManager -

https://shankar-k.medium.com/tesla-developer-api-guide-ble-key-pair-auth-and-vehicle-commands-part-3-485e4a357e7d

TLDR - The new official Tesla API has provision for Bluetooth LE commands including Stop/Start charging and set charging rate. AFAIK, the Raspberry Pi Zero W supports Bluetooth and typically resides in the Tesla Wall Charger within Bluetooth range.

It seems a logical extension to forgo all the API authentication, potential tiered subscription costs etc. and do direct control of charging via Bluetooth?

[MikeBishop]

That's a very exciting prospect -- thanks for finding that! I believe you still need the API registration in order to register the key on the car to use BLE commands, but this might help us stay in the lowest (and hopefully free) usage tier if we're never actually hitting the cloud API.

[ChutneyMary]

I hope Tesla has provisioned a non-cloud-based method for interaction with their vehicles. It would be remiss of them not to support people in remote localities out of internet range.

Here's hoping...I still can't get the Fleet API working!

[ChutneyMary]

Here are some resources I've found while trying to understand Bluetooth programming -

http://blog.kevindoran.co/bluetooth-programming-with-python-3/

https://people.csail.mit.edu/albert/bluez-intro/c212.html

[ChutneyMary]

Further resources are linked for anyone (@MikeBishop ?) thinking of progressing the Bluetooth API -

onokje/node-red-contrib-tesla#67 (comment)

The developer states that he has made "a tiny HTTP API to make BLE request to my Tesla". I haven't experimented with the code yet, but he goes on further to explain that no internet access is needed to interact with the vehicle over BLE.

[SamIAm789]

I'll post this here in case it helps anyone...

I've managed to get local access to my car via BLE using this program (https://github.com/tesla-local-control/tesla_ble_mqtt_docker) and home assistant. I use it to start and stop charging and let TWCManager determine the amps. I did have to scrape the amps offered from my local TWCManager webpage to use in the home assistant automations.

I'll hopefully migrate across to the BLE within TWCManager once it's up and running.

[RichieB2B]

Thanks for the update! There is no need to scrape the TWCManager web pages though. It has full MQTT support. You can use the prefix/config/maxAmpsForSlaves topic.

[SamIAm789]

Thanks for pointing that out. Much simpler!

[ngardiner]

HI @SamIAm789, take a look at the following document, I've got experimental support for the tesla-control BLE support in the TWCManager development tree (main) now, would be happy if anyone else wanted to test it out:

https://github.com/ngardiner/TWCManager/blob/main/LOCAL-CONTROL.md

[pflik]

I'm currently using BLE to set the amps and start/stop the charging with a granny charger. It works within home assistant and can be accessed via a web api. I'm assuming this could be easily build into TWC manager (the start and stop). Only thing you need to do is register the device as a key in your car.

You can find the project here.
https://github.com/yoziru/esphome-tesla-ble

Would be really cool to have this integrated with TWCmanager to be able to call this device instead of the fleet api

[MikeBishop]

That's a cool alternative. The current effort is on using BLE from the device on which TWCManager is running, since most of us already have it installed inside or near the TWC. But having that as a remote option would be interesting as well!

[pflik]

That's a cool alternative. The current effort is on using BLE from the device on which TWCManager is running, since most of us already have it installed inside or near the TWC. But having that as a remote option would be interesting as well!

this device is literally 7 euro's or so. Very cheap.

[pflik]

btw. Maybe another avenue to pursue. TWCManager is already able to push messages to MQTT, why don't we extend that to push a message when the car needs to be turned on or off. This can be picked up by another device abstracting the implementation (bluetooth, fleet API etc...).

Or, just extend the HASS implementation to be able to change the state of a switch (to turn on or off) and handle it in HASS. I literally have a switch in the dashboard that is able to turn on or off the charging of the car (via bluetooth).

I think the MQTT solution is a bit more elegant, since your not tying into specific implementations but either would be fine actually.

[RichieB2B]

Excellent idea. We could use these topics (following the Fleet API standard):
TWC/vehicles/{vehicle_tag}/command/charge_stop
TWC/vehicles/{vehicle_tag}/command/charge_start

Or we can use a single topic and send a value of stop or start to it:

TWC/vehicles/{vehicle_tag}/command/charge

[pflik]

maybe we need to look into also getting the car status via MQTT. SoC could be gotten from this as well as some other info. Or is TWCManager able to retrieve the SoC from the charging plug?

[MikeBishop]

No, the TWC doesn't know (or at least doesn't report to TWCManager) the SoC. We already support MQTT for listening to data from TeslaMate, so in theory adding another MQTT source should be feasible. The harder part is if the source can't report all the data we're expecting and we still need to use the API for some of it. What we currently fetch is:

        "battery_level": ["batteryLevel", lambda a: int(a)],
        "charge_limit_soc": ["chargeLimit", lambda a: int(a)],
        "display_name": ["name", lambda a: str(a)],
        "latitude": ["syncLat", lambda a: float(a)],
        "longitude": ["syncLon", lambda a: float(a)],
        "state": ["syncState", lambda a: a],
        "time_to_full_charge": ["timeToFullCharge", lambda a: int(float(a))],
        "charger_pilot_current": ["availableCurrent", lambda a: int(a)],
        "charger_actual_current": ["actualCurrent", lambda a: int(a)],
        "charger_phases": ["phases", lambda a: int(a)],
        "charger_voltage": ["voltage", lambda a: int(a)],
        "charging_state": ["chargingState", lambda a: str(a)],

...though not all of those values from the vehicle are currently used. We currently use the TWC's report of phase/voltage rather than the vehicle's, and display_name is probably not critical to receive over BLE.

[pflik]

Currently what i can get over BLE is divided into three categories:

control:

• Charge on/off
• Charging Amps
• Charging Limit
• Wake up car

Sensors

• Asleep
• chargeflap open/closed
• Doors open/closed
• User Presence

Diagnostics

• BLE connection on/of
• BLE signal strength
• BLE device Wifi signal
• Pair BLE Key
• Restart
• a bunch of other info not really relevant for TWCManager (like IP adres, force update, status of button on BLE device, restart BLE device, uptime, Version, RGB Led, Status Led) etc...

It's all through ESPhome, but we can easily expose it through mqtt. BTQW if bluetooth is in range, the location should just default to home location in any case.

[ngardiner]

Hi All,

With Feb 1 rapidly approaching, and the threat of Tesla API changes/charging looming, I've been doing some work on BLE integration. We've now got native BLE support via the tesla-control binary in the development build today. This covers start/stop charging and charge rate control.

The logic used to do this is a little clunky (from a code perspective, not an outcome perspective) and I have a PR under development to better handle the prioritisation of BLE over API. This is coming along well - I am controlling my vehicle's charging almost exclusively with BLE with fallback to API only when BLE fails for any reason (it's radio, so it does happen). I am about to add the ability to configure that prioritisation so that you can effectively cut API calls for start/stop charging/charge rate entirely if you would prefer, and keep it exclusively to BLE (which I intend to do going forward, because for me it has been working well).

The TeslaBLE module does not currently support the external ESP-based hardware for tesla BLE, but if it's about as straightforward as the native tesla-control BLE commands, I can't see why it couldn't be handled easily. I simply haven't had time to read up on the protocol/interface yet and don't have one so won't be able to test it once added - but would be great if we have interested testers to help there once I get some support added.

I had some temporary documentation previously, but I have now put some "proper" documentation here: https://github.com/ngardiner/TWCManager/blob/main/docs/modules/Vehicle_TeslaBLE.md

Certainly appreciate any feedback, if anyone else gets a chance to try it out. I admit that the peering process is a bit inelegant. It's a combination of the UI not being all that refined and it requiring actual physical interaction with the car to add the "card" (and that is a bit buggy too, but eventually works). If anyone gets really stuck I can spend a bit more time on it, but for me it worked fairly well.

[dehsgr]

@ngardiner currently I'm running node-red and tesla-ble-http-proxy for controlling my docker twcmanager instance. I would like to test your "native" twcmanager implementation to get rid of my tesla-ble-http-proxy container. Is there any possibility for getting a docker image with ble implementation for testing?

[dehsgr]

@ngardiner ist BLE function now included in TWCManager Docker image? I just updated my docker-compose.yml and pulled current ":latest" image.

Nevertheless vehicle details show:

And clicking [Pair...] button results in a blank page at URI /vehicle/localMgmt (epmty response):

[dehsgr]

I think it's related to:

2025-02-11T15:35:14+01:00 [debug] Set session cache file to '/root/.tesla-cache.json'
2025-02-11T15:35:14+01:00 [debug] Set key name to ''
2025-02-11T15:35:14+01:00 [debug] Set key file to ''
2025-02-11T15:35:14+01:00 [debug] Set OAuth token name to ''
2025-02-11T15:35:14+01:00 [debug] Set OAuth token file to ''
2025-02-11T15:35:14+01:00 [debug] Set keyring type to ''
2025-02-11T15:35:14+01:00 [debug] Set keyring Debug Logging to 'false'
2025-02-11T15:35:14+01:00 [debug] Skipping private key loading because FlagPrivateKey is not set
2025-02-11T15:35:14+01:00 [debug] No private key available
2025-02-11T15:35:14+01:00 [debug] Connecting over BLE...
2025-02-11T15:35:14+01:00 [debug] Creating new BLE device
Error: failed to find a BLE device: can't init hci: can't create socket: address family not supported by protocol
----------------------------------------
Exception occurred during processing of request from ('192.168.2.202', 61096)
Traceback (most recent call last):
  File "/usr/lib/python3.9/socketserver.py", line 650, in process_request_thread
    self.finish_request(request, client_address)
  File "/usr/lib/python3.9/socketserver.py", line 360, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/usr/src/TWCManager/lib/TWCManager/Control/HTTPControl.py", line 158, in __init__
    BaseHTTPRequestHandler.__init__(self, *args, **kwargs)
  File "/usr/lib/python3.9/socketserver.py", line 720, in __init__
    self.handle()
  File "/usr/lib/python3.9/http/server.py", line 434, in handle
    self.handle_one_request()
  File "/usr/lib/python3.9/http/server.py", line 422, in handle_one_request
    method()
  File "/usr/src/TWCManager/lib/TWCManager/Control/HTTPControl.py", line 1034, in do_POST
    self.master.getModuleByName("TeslaBLE").peerWithVehicle(vin)
  File "/usr/src/TWCManager/lib/TWCManager/Vehicle/TeslaBLE.py", line 90, in peerWithVehicle
    return self.parseCommandOutput(ret)
NameError: name 'ret' is not defined

[ngardiner]

HI @dehsgr,

Yes unfortunately I'm hitting a brick wall with bluetooth support in Docker - it should work for you if you set the following in docker-compose.yml:

network_mode: host

But that doesn't feel like a solution to me - it breaks docker networking. For some it may work, others may be running containers with things like mqtt/hass/etc and it will break it.

I'm searching for an answer but everything I read suggests this has to be set for HCI BLE access to work in Docker. I wouldn't set it by default in docker-compose.yml as it may break things for everyone else who doesn't need bluetooth support.

[ngardiner]

I have found a potential workaround in this thread: moby/moby#16208 (comment)

It is very complex however, but something we could potentially build in as part of the pipeline. I'll try it out when I can to see if it actually works,

[dehsgr]

@ngardiner

I changed to network_mode: host for now. My docker-compose.yml now looks like:

version: "3.7"

services:
  twcmanager:
    container_name: twcmanager
    image: twcmanager/twcmanager:latest
    restart: unless-stopped
    healthcheck:
      test: "curl --fail http://localhost:8084/api/getStatus || exit 1"
      interval: 10s
      retries: 5
      start_period: 5s
      timeout: 10s
    devices:
      - "/dev/bus/usb:/dev/bus/usb"
      - "/dev/ttyUSB0:/dev/ttyUSB0"
    ports:
      - 8084:8084
    environment:
      - TZ=Europe/Berlin
      - DBUS_SYSTEM_BUS_ADDRESS=unix:path=/var/run/dbus/system_bus_socket
    volumes:
      - /etc/twcmanager:/etc/twcmanager
      - /etc/localtime:/etc/localtime:ro
      - /run/dbus:/run/dbus:ro
    cap_add:
      - CAP_NET_ADMIN  # Required for managing network interfaces (Bluetooth uses these)
      - CAP_NET_RAW    # Required for raw network access (Bluetooth uses this)
    command: sh -c "apt install -y curl && /usr/bin/python3 -m TWCManager"
    network_mode: host

Nevertheless vehicle page shows "not implemented" and trying to add my car results in the following error:

2025-02-17T11:17:25+01:00 [debug] Discovering services X0:Xc:X5:Xa:X3:X3...
2025-02-17T11:17:25+01:00 [info ] Connected to vehicle BLE
2025-02-17T11:17:25+01:00 [info ] Connecting to car...
2025-02-17T11:17:25+01:00 [info ] Starting dispatcher service...
2025-02-17T11:17:25+01:00 [debug] TX: 0a54125082014d320208092a470a430a410402ed802bac310244b7c45519b89c633bdaeb2a9edd9d2d189f762a3cb35bea6bd411fc90ce080e558c3ad663fe835e8efe9f74dd39b3ecd7f7ac356a5741ce3020021802
11:17:25 🔌 RS485    12 Tx@: C0 FB E0 77 77 21 18 09 00 00 00 00 00 00 00 00 10 C0
----------------------------------------
Exception occurred during processing of request from ('192.168.2.202', 49718)
Traceback (most recent call last):
  File "/usr/lib/python3.9/socketserver.py", line 650, in process_request_thread
    self.finish_request(request, client_address)
  File "/usr/lib/python3.9/socketserver.py", line 360, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/usr/src/TWCManager/lib/TWCManager/Control/HTTPControl.py", line 158, in __init__
    BaseHTTPRequestHandler.__init__(self, *args, **kwargs)
  File "/usr/lib/python3.9/socketserver.py", line 720, in __init__
    self.handle()
  File "/usr/lib/python3.9/http/server.py", line 434, in handle
    self.handle_one_request()
  File "/usr/lib/python3.9/http/server.py", line 422, in handle_one_request
    method()
  File "/usr/src/TWCManager/lib/TWCManager/Control/HTTPControl.py", line 1034, in do_POST
    self.master.getModuleByName("TeslaBLE").peerWithVehicle(vin)
  File "/usr/src/TWCManager/lib/TWCManager/Vehicle/TeslaBLE.py", line 90, in peerWithVehicle
    return self.parseCommandOutput(ret)
NameError: name 'ret' is not defined
----------------------------------------

[amasolov]

I'm getting the same 'NameError: name 'ret' is not defined' error with my Manual installation straight on my Pi Zero 2W

[RichieB2B]

I fixed that error in #629