Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

failed to connect to vehicle (A): context deadline exceeded #98

Open
pre5ton opened this issue Feb 5, 2025 · 8 comments
Open

failed to connect to vehicle (A): context deadline exceeded #98

pre5ton opened this issue Feb 5, 2025 · 8 comments

Comments

@pre5ton
Copy link

pre5ton commented Feb 5, 2025 •
edited
Loading

Hello,

Hoping someone can point me towards a solution. Have a new Raspberry Pi 5 located immediately next to the vehicle (~3 feet away), but continue to receive the error "failed to connect to vehicle (A): context deadline exceeded". Followed documentation exactly as outlined. Any support is appreciated.

I went through possible issues and cannot identify what I'm doing wrong, list of checks below.

Used VNC Viewer to access Raspberry Pi GUI to ensure bluetooth is enabled.
Ensured vehicle is awake (door open, screen on)
No errors in logs
Multiple positions of Raspberry Pi

Logs

2025/02/05 02:58:47 INFO TeslaBleHttpProxy 2.0.3 is loading ...
2025/02/05 02:58:47 INFO TeslaBleHttpProxy httpListenAddress=:8080
2025/02/05 02:58:47 INFO BleControl initialized
2025/02/05 02:58:47 INFO TeslaBleHttpProxy is running!
2025/02/05 03:02:50 can't accept: listner timed out
@michael-robbins
Copy link

How'd you setup the container/software? Where did you get up to? Did you setup the virtual key thing?

@pre5ton
Copy link
Author

pre5ton commented Feb 16, 2025

Followed instructions outlined here exactly - https://github.com/wimaha/TeslaBleHttpProxy/blob/main/docs/installation.md

Software is running in docker.

Can access dashboard page and created the virtual keys without issue.

Error is received when attempting to send the virtual key to the vehicle.

@michael-robbins
Copy link

Ah yeah, I've got a rpi5 with it running in docker myself, same setup, and it's working, so just trying to find what's different with your setup.

Can you paste here the docker run command, or docker compose config?

@pre5ton
Copy link
Author

pre5ton commented Feb 18, 2025 •
edited
Loading

Here is the docker compose config:

services:
  tesla-ble-http-proxy:
    image: wimaha/tesla-ble-http-proxy
    container_name: tesla-ble-http-proxy
    environment:
      - cacheMaxAge=30 # Optional, but recommended to set this to anything more>
    volumes:
      - ~/TeslaBleHttpProxy/key:/key
      - /var/run/dbus:/var/run/dbus
    restart: always
    privileged: true
    network_mode: host
    cap_add:
      - NET_ADMIN
      - SYS_ADMIN

Running the below OS version loaded using the official Raspberry Pi imager.

Raspberry Pi OS with desktop
Release date: November 19th 2024
System: 64-bit
Kernel version: 6.6
Debian version: 12 (bookworm)
Size: 1,179MB

@pre5ton
Copy link
Author

pre5ton commented Feb 18, 2025 •
edited
Loading

I tried to send the keys to the vehicle again while I had the Pi running and this time it worked! Not sure what changed...

I have two vehicles (both Teslas) so setup the key in both vehicles. The first one I sent the keys to the vehicle when I was not in the car and it says they were sent, went to the garage and there was nothing on the display, but tapped the key card anyways. Locks show a "BLE" key now. Second one I sent the key while in the vehicle, tapped the card and it added "unknown key".

Now when setting up in EVCC I'm receiving the below errors when trying to retrieve vehicle SOC or sending charging commands. Effectively the same errors as in the subject post.

Proxy is at 192.168.1.120 and running on port 8080.


[main ] INFO 2025/02/17 17:53:26 evcc 0.200.1
[main ] INFO 2025/02/17 17:53:26 using config file: /etc/evcc.yaml
[db ] INFO 2025/02/17 17:53:26 using sqlite database: /root/.evcc/evcc.db
[main ] INFO 2025/02/17 17:53:27 listening at :7070
[site ] INFO 2025/02/17 17:53:27 site config:
[site ] INFO 2025/02/17 17:53:27 meters: grid ✓ pv ✓ battery ✗
[site ] INFO 2025/02/17 17:53:27 grid: power ✓ energy ✗ currents ✓
[site ] INFO 2025/02/17 17:53:27 pv 1: power ✓ energy ✓ currents ✓
[site ] INFO 2025/02/17 17:53:27 vehicles:
[site ] INFO 2025/02/17 17:53:27 vehicle 1: range ✓ finish ✗ status ✓ climate ✗ wakeup ✓
[site ] INFO 2025/02/17 17:53:27 vehicle 2: range ✓ finish ✗ status ✓ climate ✗ wakeup ✓
[lp-1 ] INFO 2025/02/17 17:53:27 loadpoint 1:
[lp-1 ] INFO 2025/02/17 17:53:27 mode: pv
[lp-1 ] INFO 2025/02/17 17:53:27 charger: power ✓ energy ✗ currents ✓ phases ✗ wakeup ✗
[lp-1 ] INFO 2025/02/17 17:53:27 meters: charge ✓
[lp-1 ] INFO 2025/02/17 17:53:27 charge: power ✓ energy ✗ currents ✓
[lp-1 ] DEBUG 2025/02/17 17:53:27 phase timer inactive
[lp-1 ] DEBUG 2025/02/17 17:53:27 pv timer inactive
[site ] DEBUG 2025/02/17 17:53:27 ----
[lp-1 ] DEBUG 2025/02/17 17:53:27 charge power: 0W
[lp-1 ] DEBUG 2025/02/17 17:53:27 charge currents: [0 0 0]A
[site ] DEBUG 2025/02/17 17:53:27 grid power: 610W
[site ] DEBUG 2025/02/17 17:53:31 pv 1 power: 293W
[site ] DEBUG 2025/02/17 17:53:48 grid currents: [4.57 3.92 0]A
[site ] DEBUG 2025/02/17 17:53:48 site power: 610W
[lp-1 ] DEBUG 2025/02/17 17:53:48 charge voltages: [2.1 2.1 2.1]V
[lp-1 ] DEBUG 2025/02/17 17:53:48 charger status: B
[lp-1 ] INFO 2025/02/17 17:53:48 car connected
[lp-1 ] DEBUG 2025/02/17 17:53:48 vehicle api refresh
[lp-1 ] DEBUG 2025/02/17 17:53:48 pv timer elapse
[lp-1 ] DEBUG 2025/02/17 17:53:48 pv timer inactive
[main ] ERROR 2025/02/17 17:54:18 vehicle status: Get "http://192.168.1.120:8080/api/1/vehicles/5YJ3E1EA7MXXXXX63/vehicle_data?endpoints=charge_state": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
[main ] ERROR 2025/02/17 17:54:48 vehicle status: Get "http://192.168.1.120:8080/api/1/vehicles/5YJ3E1EAXMXXXXX22/vehicle_data?endpoints=charge_state": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
[lp-1 ] INFO 2025/02/17 17:54:48 vehicle updated: unknown -> Jamie
[lp-1 ] INFO 2025/02/17 17:54:48 vehicle updated: Jamie -> unknown
[lp-1 ] DEBUG 2025/02/17 17:54:48 pv charge current: 0A = 0A + -2.65A (610W @ 1p)
[lp-1 ] DEBUG 2025/02/17 17:54:48 pv enable timer reset
[lp-1 ] DEBUG 2025/02/17 17:54:48 pv timer inactive
[lp-1 ] INFO 2025/02/17 17:54:48 vehicle updated: unknown -> Jamie
[lp-1 ] DEBUG 2025/02/17 17:56:52 set charge mode: now
[site ] DEBUG 2025/02/17 17:56:52 ----
[lp-1 ] DEBUG 2025/02/17 17:56:52 charge power: 0W
[lp-1 ] DEBUG 2025/02/17 17:56:52 charge currents: [0 0 0]A
[site ] DEBUG 2025/02/17 17:56:55 pv 1 power: 278W
[site ] DEBUG 2025/02/17 17:56:58 grid power: 534W
[site ] DEBUG 2025/02/17 17:57:12 grid currents: [3.99 4.07 0]A
[site ] DEBUG 2025/02/17 17:57:12 site power: 534W
[lp-1 ] DEBUG 2025/02/17 17:57:12 charge voltages: [2.1 2.1 2.1]V
[lp-1 ] DEBUG 2025/02/17 17:57:12 charger status: B
[lp-1 ] ERROR 2025/02/17 17:57:42 vehicle soc: Get "http://192.168.1.120:8080/api/1/vehicles/5YJ3E1EA7MXXXXX63/vehicle_data?endpoints=charge_state": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
[lp-1 ] DEBUG 2025/02/17 17:57:42 max charge current: 32A
[lp-1 ] DEBUG 2025/02/17 17:57:42 charger enable
[lp-1 ] DEBUG 2025/02/17 17:57:42 wake-up timer: start

Here is my EVCC.yaml:

# open evcc at http://evcc.local:7070
network:
  schema: http
  host: evcc.local # .local suffix announces the hostname on MDNS
  port: 7070

log: debug
levels:
  cache: error

# unique installation id
plant: 5d950f0aa49cf5306f1e7ea76278dcc770ca9a56abb3aebf6fd51397a1XXXXX

interval: 300s # control cycle interval

sponsortoken: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJldmNjLmlvIiwic3ViIjoicHJlNXRvbiIsImV4cCI6MTgxNjUyNzYwMCwiaWF0IjoxNzIxOTE5NjAwLCJzcmMiOiJnaCJ9.EORnfLHnTgf30Vtvy5iBqzvTApNwYQ6BC1mFXCXXXXX

# sponsors can set telemetry: true to enable anonymous data aggregation
# see https://github.com/evcc-io/evcc/discussions/4554
telemetry: false

meters:
- type: template
  template: enphase 
  usage: grid  
  host: 192.168.1.83  
  token: eyJraWQiOiI3ZDEwMDA1ZC03ODk5LTRkMGQtYmNiNC0yNDRmOThlZTE1NmIiLCJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiJ9.eyJhdWQiOiIxMjE5MjYwNjE2MzgiLCJpc3MiOiJFbnRyZXoiLCJlbnBoYXNlVXNlciI6Im93bmVyIiwiZXhwIjoxNzUzMTEyMTQzLCJpYXQiOjE3MjE1NzYxNDMsImp0aSI6ImU4MjU0ZWQwLWFkYjMtNGRkYi1hOGM0LTllNWY3ZmFjODIzNSIsInVzZXJuYW1lIjoiaC5wcmVzdG9ud2hpdGVAZ21haWwuY29tIn0.A8Idz1mnvDxDK2b9sIZ3Z9iJztE3LS63PoPZwLSbs4fCG0kZ5TIwwU6M4ljHGUml8V897TF0Z5GWorWbOXXXXX  
  name: grid1

chargers:
- type: template
  template: twc3 
  host: 192.168.1.96  
  name: wallbox4

vehicles:
  - name: jamie_tesla
    type: template
    template: tesla-ble
    title: Jamie
    capacity: 50
    vin: 5YJ3E1EA7MXXXXX63
    url: http://192.168.1.120
    port: 8080
  - name: preston_tesla
    type: template
    template: tesla-ble
    title: Preston
    capacity: 50
    vin: 5YJ3E1EAXMXXXXX22
    url: http://192.168.1.120
    port: 8080

loadpoints:
- title: Home
  charger: wallbox4
  mode: pv

site:
  title: Home
  meters:
    grid: grid1

@pre5ton
Copy link
Author

pre5ton commented Feb 18, 2025 •
edited
Loading

Still testing, but believe I may have solved it. The issue stems around the queries failing to resolve due to the DNS being used. I am not using my own router and am using my AT&T Fiber combined modem/router device which uses AT&T's DNS to resolve queries. It was odd to me that both the raspberry pi 5 running TeslaBleHttpProxy and my unraid server running EVCC were both returning similar errors. I changed both my unraid server and my pi to use Google & CloudFlare DNS servers and the issue seems to be resolved.

EDIT: My one vehicle that had the BLE key sent from TeslaBleHttpProxy to the vehicle successfully worked for several hours without issue with EVCC. I tried to deploy the key to my wife's vehicle again and I'm back in the same loop of TeslaBleHttpProxy providing the context deadline exceeded error when trying to send the key to the vehicle. I have tried from multiple computers/devices using several different DNS servers and result is the same. Also tried wired and wireless on the pi and relocating the pi to multiple different locations (including 2 feet from the vehicle).

Adding logs from TeslaBleHttpProxy container:
2025/02/18 18:58:21 INFO TeslaBleHttpProxy 2.0.3 is loading ...
2025/02/18 18:58:21 INFO TeslaBleHttpProxy httpListenAddress=:8080
2025/02/18 18:58:21 INFO BleControl initialized
2025/02/18 18:58:21 INFO TeslaBleHttpProxy is running!
2025/02/18 18:58:49 can't accept: listner timed out
2025/02/18 18:59:26 INFO TeslaBleHttpProxy 2.0.3 is loading ...
2025/02/18 18:59:26 INFO TeslaBleHttpProxy httpListenAddress=:8080
2025/02/18 18:59:26 INFO BleControl initialized
2025/02/18 18:59:26 INFO TeslaBleHttpProxy is running!
2025/02/18 19:01:35 can't accept: listner timed out
2025/02/18 19:02:35 INFO TeslaBleHttpProxy 2.0.3 is loading ...
2025/02/18 19:02:35 INFO TeslaBleHttpProxy httpListenAddress=:8080
2025/02/18 19:02:35 INFO BleControl initialized
2025/02/18 19:02:35 INFO TeslaBleHttpProxy is running!
2025/02/18 19:03:26 can't accept: listner timed out
2025/02/18 19:06:17 INFO TeslaBleHttpProxy 2.0.3 is loading ...
2025/02/18 19:06:17 INFO TeslaBleHttpProxy httpListenAddress=:8080
2025/02/18 19:06:17 INFO BleControl initialized
2025/02/18 19:06:17 INFO TeslaBleHttpProxy is running!
2025/02/18 19:07:23 can't accept: listner timed out
2025/02/18 19:12:08 INFO TeslaBleHttpProxy 2.0.3 is loading ...
2025/02/18 19:12:08 INFO TeslaBleHttpProxy httpListenAddress=:8080
2025/02/18 19:12:08 INFO BleControl initialized
2025/02/18 19:12:08 INFO TeslaBleHttpProxy is running!
2025/02/18 19:14:45 can't accept: listner timed out

@michael-robbins
Copy link

michael-robbins commented Feb 19, 2025 •
edited
Loading

Given you're talking to the IP address of the raspberry pi, DNS shouldn't even be in the picture here, and nothing requires internet/hostname resolution either, unless I missed something above.

Try to post things inside code block (with 3x backticks ` in a row without spaces before and after):

like this

easy to paste

formats like code

My setup is similar:

  tesla-ble-http-proxy:
    image: wimaha/tesla-ble-http-proxy:latest
    container_name: tesla-ble-http-proxy

    privileged: true
    network_mode: host
    cap_add:
      - NET_ADMIN
      - SYS_ADMIN

    environment:
      - httpListenAddress=:8081

    volumes:
      - tesla-ble-http-proxy-key:/key
      - /var/run/dbus:/var/run/dbus

    restart: unless-stopped

Along with a bog standard Raspberry Pi 4 running in the garage alongside the car.

Key transmission 'just worked', sometimes I'll see errors around the vehicle is already connected to the maximum number of BLE devices but I think that might be the bluetooth on the raspberry pi acting weirdly... not exactly sure...

I'm not using EVCC, just my own Home Assistant automations (https://github.com/michael-robbins/ha-snippets/blob/main/README.md) which seem to be working.

I'd verify everything 'locally' by running curl from the raspberry pi itself
For example:

curl 'http://localhost:8081/api/1/vehicles/<your vin>/body_controller_state'

curl 'http://localhost:8081/api/1/vehicles/<your vin>/vehicle_data?endpoints=charge_state;climate_state'

Just to verify TeslaBleHttpProxy is doing the job correctly before going to EVCC!

@pre5ton
Copy link
Author

pre5ton commented Feb 20, 2025

My current issue is the same one as in the original post. I can't get TeslaBleHttpProxy to send the keys to my vehicle (errors provided above).

Also, corrected formatting of above posts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@michael-robbins @pre5ton