503 Service Unavailable: Vehicle does not wake up via Proxy without manual intervention (CURL/Official App)

[Gioblack87]

I am using the tesla-ble-http-proxy to manage my Tesla Model Y (2021) charging via evcc. I am experiencing a persistent loop of 503 Service Unavailable errors.

The core issue is that the vehicle does not wake up automatically through the proxy's regular polling. Even when evcc or the proxy attempts to connect, I receive Error="vehicle is sleeping". I am forced to manually trigger a wake-up using a CURL command to the /wake_up endpoint or by opening the official Tesla App. Only after this manual intervention does the proxy eventually establish a connection.
Environment

Vehicle: Tesla Model Y (ModelGio) - VIN: [TESLA-VIN]

Installation: Docker (image: wimaha/tesla-ble-http-proxy:latest)

Client: evcc (version 0.300.8)

Hardware: Raspberry Pi 5 (running both the proxy and evcc)

Log Outputs

Tesla BLE Proxy Logs (showing the failure to wake the car):
Plaintext

2026/02/08 18:17:40 INFO Connecting to Vehicle ...
2026/02/08 18:17:41 ERRO Cannot connect to vehicle Error="vehicle is sleeping"
2026/02/08 18:19:40 INFO Connecting to Vehicle ...
2026/02/08 18:19:41 ERRO Cannot connect to vehicle Error="vehicle is sleeping"

evcc Logs (receiving the 503 error from proxy):
Plaintext

[lp-1 ] ERROR 2026/02/08 18:19:41 charger status: unexpected status: 503 (Service Unavailable) GET http://192.168.1.145:8080/api/1/vehicles/[TESLA-VIN]/vehicle_data?endpoints=charge_state

Steps to Reproduce

Ensure the vehicle is in deep sleep.

Observe that the proxy fails to connect during standard polling, returning "vehicle is sleeping".

Note: The vehicle only wakes up if I manually send a CURL -X POST .../wake_up or open the Tesla official app. The proxy does not seem to successfully "ping" the car into waking up on its own.

Expected Behavior

The proxy should be able to wake the vehicle via BLE during a connection attempt or at least hold the request until the vehicle responds, rather than returning an immediate 503 error which causes the charging logic (evcc) to fail.

[wimaha]

Thanks for the report. This usually happens when the proxy doesn’t receive the wakeup flag for vehicle_data requests.

By design, the proxy does not wake the car for vehicle_data unless you pass wakeup=true:
/api/1/vehicles/{VIN}/vehicle_data?endpoints=charge_state&wakeup=true
Details are in the README – Vehicle Data.

If we woke the car on every poll, it would effectively never sleep, which would drain the battery and work against Tesla’s sleep logic. That’s why wake-up is opt-in.

To move forward, could you share your evcc configuration and explain why you need to poll the car? That will help narrow down a suitable setup.

[Gioblack87]

Thanks for the clarification. I fully understand the logic regarding the 12V battery drain and I agree that the proxy should not wake the car on every single poll.

However, the issue I am facing is that evcc (using the built-in tesla-ble template) treats the 503 Service Unavailable response as a hard error/connection failure, rather than a "Vehicle Sleeping" state. Consequently, it aborts the operation and does not attempt to send a wake-up command automatically when I try to start charging (e.g., in 'Now' mode).

I am relying on evcc to manage the charging logic based on solar surplus. Here is my current evcc.yaml configuration for the vehicle:
YAML

vehicles:

• name: ev4
  type: template
  template: tesla-ble
  title: ModelGio
  capacity: 82
  vin: "[TESLA-VIN]"
  url: "http://192.168.1.145:8080" # Pointing to the Proxy
  icon: car

Since I cannot easily modify the internal code of evcc to append &wakeup=true to the URL dynamically, do you have a recommended configuration for evcc (perhaps using a generic custom vehicle type instead of the tesla-ble template) that would allow me to handle this "opt-in" wake-up logic correctly?

Currently, I have to use an external Home Assistant automation to force a CURL request to /wake_up to make the car visible to evcc, but I would prefer a cleaner integration within evcc itself if possible.

[JKSProds]

In happens the same with my config. I even tried to use custom charger in EVCC with API requests to the Proxy Server. But it tries to check the status of the charger and instead of returning the last status before going to sleep it returns that the vehicle is a sleep and returns 503 to evcc with stops the next step in evcc. Maybe you could return the last status if vehicle is a sleep so that evcc send the command to charge and wakes the vehicle. Is that possible?

Below are the logs of EVCC:

[lp-1 ] DEBUG 2026/02/09 10:25:38 charge power: 0W [circuit-garage] DEBUG 2026/02/09 10:25:38 power: 0W [circuit-garage] DEBUG 2026/02/09 10:25:38 current: 0A [circuit-main] DEBUG 2026/02/09 10:25:38 power: 85.72W [circuit-main] DEBUG 2026/02/09 10:25:38 current: 0.375A [site ] DEBUG 2026/02/09 10:25:38 pv 1 power: 0W [site ] DEBUG 2026/02/09 10:25:38 !! solar production: accumulate add db:4 0.000W power (was: Accumulated: 0.000kWh updated: 2026-02-09 10:25:08 +0100 CET) [site ] DEBUG 2026/02/09 10:25:38 !! solar production: accumulate moved db:4 from 0.000 to 0.000 [site ] DEBUG 2026/02/09 10:25:38 grid power: 86W [site ] DEBUG 2026/02/09 10:25:38 grid powers: [86 0 0]W [site ] DEBUG 2026/02/09 10:25:38 grid currents: [0.426 0 0]A [site ] DEBUG 2026/02/09 10:25:38 site power: 86W [lp-1 ] DEBUG 2026/02/09 10:25:38 charge total import: 0.000kWh [lp-1 ] ERROR 2026/02/09 10:26:02 charger status: unexpected status: 503 (Service Unavailable) GET http://10.0.0.245:8080/api/1/vehicles/XXXXXXXXXXXXXX/vehicle_data?endpoints=charge_state [site ] DEBUG 2026/02/09 10:26:02 solar forecast: accumulated 0.001Wh from 2026-02-09 10:25:32 +0100 CET to 2026-02-09 10:26:02 +0100 CET [site ] DEBUG 2026/02/09 10:26:02 solar forecast: produced 0.000 [site ] DEBUG 2026/02/09 10:26:02 solar forecast: accumulated 51.372kWh, produced 0.000kWh, scale 0.000 [site ] DEBUG 2026/02/09 10:26:08 ---- [lp-1 ] DEBUG 2026/02/09 10:26:08 charge power: 0W [circuit-garage] DEBUG 2026/02/09 10:26:08 power: 0W [circuit-garage] DEBUG 2026/02/09 10:26:08 current: 0A [circuit-main] DEBUG 2026/02/09 10:26:08 power: 84.87W [circuit-main] DEBUG 2026/02/09 10:26:08 current: 0.37A [site ] DEBUG 2026/02/09 10:26:08 pv 1 power: 0W [site ] DEBUG 2026/02/09 10:26:08 !! solar production: accumulate add db:4 0.000W power (was: Accumulated: 0.000kWh updated: 2026-02-09 10:25:38 +0100 CET) [site ] DEBUG 2026/02/09 10:26:08 !! solar production: accumulate moved db:4 from 0.000 to 0.000 [site ] DEBUG 2026/02/09 10:26:08 grid power: 85W [site ] DEBUG 2026/02/09 10:26:08 grid powers: [85 0 0]W [site ] DEBUG 2026/02/09 10:26:08 grid currents: [0.427 0 0]A [site ] DEBUG 2026/02/09 10:26:08 site power: 85W [lp-1 ] DEBUG 2026/02/09 10:26:08 charge total import: 0.000kWh [lp-1 ] ERROR 2026/02/09 10:26:32 charger status: unexpected status: 503 (Service Unavailable) GET http://10.0.0.245:8080/api/1/vehicles/XXXXXXXXXXXXXX/vehicle_data?endpoints=charge_state [site ] DEBUG 2026/02/09 10:26:32 solar forecast: accumulated 0.001Wh from 2026-02-09 10:26:02 +0100 CET to 2026-02-09 10:26:32 +0100 CET [site ] DEBUG 2026/02/09 10:26:32 solar forecast: produced 0.000 [site ] DEBUG 2026/02/09 10:26:32 solar forecast: accumulated 51.373kWh, produced 0.000kWh, scale 0.000 [site ] DEBUG 2026/02/09 10:26:38 ---- [lp-1 ] DEBUG 2026/02/09 10:26:38 charge power: 2W [circuit-garage] DEBUG 2026/02/09 10:26:38 power: 1.57W [circuit-garage] DEBUG 2026/02/09 10:26:38 current: 0A [circuit-main] DEBUG 2026/02/09 10:26:38 power: 84.78W [circuit-main] DEBUG 2026/02/09 10:26:38 current: 0.369A [site ] DEBUG 2026/02/09 10:26:38 pv 1 power: 0W [site ] DEBUG 2026/02/09 10:26:38 !! solar production: accumulate add db:4 0.000W power (was: Accumulated: 0.000kWh updated: 2026-02-09 10:26:08 +0100 CET) [site ] DEBUG 2026/02/09 10:26:38 !! solar production: accumulate moved db:4 from 0.000 to 0.000 [site ] DEBUG 2026/02/09 10:26:38 grid power: 85W [site ] DEBUG 2026/02/09 10:26:38 grid powers: [85 0 0]W [site ] DEBUG 2026/02/09 10:26:38 grid currents: [0.425 0 0]A [site ] DEBUG 2026/02/09 10:26:38 site power: 85W [lp-1 ] DEBUG 2026/02/09 10:26:38 charge total import: 0.000kWh

And the EVCC config:

`chargers:

• name: my_charger
  type: custom
  status:
  source: http
  uri: "${TESLA_BLE_PROXY}:8080/api/1/vehicles/${TESLA_VIN}/vehicle_data?endpoints=charge_state"
  method: GET
  jq: >
  if (.response.response.charge_state.charging_state == "Charging"
  and .response.response.charge_state.charger_power > 0) then "C"
  elif (.response.response.charge_state.charging_state == "Charging") then "B"
  elif (.response.response.charge_state.charging_state == "Stopped") then "B"
  elif (.response.response.charge_state.charging_state == "NoPower") then "B"
  elif (.response.response.charge_state.charging_state == "Complete") then "B"
  elif (.response.response.charge_state.charging_state == "Starting") then "B"
  else "A" end
  timeout: 30s
  enabled:
  source: http
  uri: "${TESLA_BLE_PROXY}:8080/api/1/vehicles/${TESLA_VIN}/vehicle_data?endpoints=charge_state"
  method: GET
  jq: (.response.response.charge_state.charging_state == "Charging"
  and .response.response.charge_state.charger_power > 0)
  timeout: 30s
  cache: 25s
  enable:
  source: http
  uri: "${TESLA_BLE_PROXY}:8080/api/1/vehicles/${TESLA_VIN}/command/{{if .enable}}charge_start{{else}}charge_stop{{end}}"
  method: POST
  body: ""
  timeout: 30s
  cache: 25s
  maxcurrent:
  source: http
  uri: "${TESLA_BLE_PROXY}:8080/api/1/vehicles/${TESLA_VIN}/command/set_charging_amps"
  method: POST
  body: '{"charging_amps": "{{.maxcurrent}}"}'
  timeout: 30s
  wakeup:
  source: http
  uri: "${TESLA_BLE_PROXY}:8080/api/1/vehicles/${TESLA_VIN}/command/wake_up"
  method: POST
  body: ''
  timeout: 30s
  `

Hope you can help as I need always to manualy wake up the vehicle.

[JKSProds]

@wimaha I've never programmed with Go language but made a fork of this project and changed the error return to ok in the following func (func VehicleData(w http.ResponseWriter, r *http.Request)). Also even with error, vehicle asleep or when it can't connect, it returns the last cache even if too old. I'm not familiar with this project or this language, but made some simples changes to see if it fixes the problem affecting me. There's probably some better fixes for this problem. But I didn't want to break the excelente work you did.

For now I realized the following tests:

Car goes to sleep and still returns data without 503 code and awaking the vehicle.
Also when It goes to sleep and I start charging with now mode it awakes the vehicle and starts charging.

I'll try it for the next few days and let you know.

I changed the following code:

if len(cachedData) > 0 { logging.Debug("BLE fetch failed, serving partial data from cache", "VIN", vin, "CachedEndpoints", len(cachedData)) combinedResponse := make(map[string]json.RawMessage) for endpoint, data := range cachedData { combinedResponse[endpoint] = data } responseJson, err := json.Marshal(combinedResponse) if err != nil { response.Result = true response.Reason = apiResponse.Error return } response.Result = true response.Reason = "The request was partially processed from cache. Some data may be stale." response.Response = responseJson } else { response.Result = true response.Reason = apiResponse.Error }

[Gioblack87]

That is a very clever workaround! By suppressing the 503 error and serving cached data, you effectively prevent evcc from aborting the connection, keeping the vehicle "alive" in the UI.

However, I would be a bit concerned about stale data logic.
For example: if I arrive home with 10% battery, plug in, and the car sleeps immediately... but the last cached state was from 3 hours ago at 50% battery:

1. The proxy will tell evcc the car is at 50%.
2. evcc might decide not to charge (or calculate charge duration incorrectly) based on that false 50% reading.

For now, I think I will stick to my Home Assistant external automation. It ensures that when I wake the car (based on Solar > 1500W), evcc gets fresh, real-time data from the BMS, avoiding any logic errors due to old cache.

But please keep us updated on your tests! If it proves reliable over a week, it might be a viable fork for many users.

[JKSProds]

@Gioblack87 evcc tries to get data every 30 seconds. I don't think that the car will go to sleep in less that 30 seconds. At least mine takes several minutes.

I could also make sure every X hours it forces to awake the car to get new information. Or after a period of no connection to the car, when it detects the beacon for the first time it could awake it first to get fresh info. Or do you have another suggestion?

However, for now I'll try, test it and let you know. Hopefully we won't need it or by that time @wimaha returns from his vacation.

[JKSProds]

@Gioblack87 this last week I charged the car 2 times and it awaked the car automatically and controlled the charging. The car always goes to sleep and the proxy returns the cached info. Everything great!

Today I did a few tweaks:

1. I detected that if I disconnected the car and leaved before the 30 seconds window, the proxy wouldn't have time to update the Disconnected from the charger, so if the car is out of range I automatically send's the Disconnected info, even if the cached info is different.
2. Regarding the stale info what I did was create a new variable "vehicleOutOfRange" that gets set every time it can't find the car (If it's a sleep it doesn't get set). Once it re-detects for the first time (once the car gets home, even if it's asleep) it wakes it up, gets fresh info and stops trying to wake the car up.

However I'm still testing this tweaks. Hope that this fixes the situations you mentioned above as I did the best I know how, with in mind that I never programmed in Go. But hope that @wimaha can replicate them better on this project.