Have a look at exposing vehicle data over BLE

[michael-robbins]

Looks like as of 3 weeks ago exposing the vehicle data over BLE is possible now?

teslamotors/vehicle-command#330

[michael-robbins]

Specifically https://developer.tesla.com/docs/fleet-api/endpoints/vehicle-endpoints#vehicle-data seems possible and would be great.

My main goal here is to somehow see what the set_charging_amps is, as well as the vehicle SoC. To tie this into my home charging setup over BLE.

[wimaha]

Hi, I have uploaded version 1.3.0 on dev. You can try it. The Get-Request: /api/1/vehicles/{vin}/vehicle_data should be possible. It returns everything in charge_state.

[michael-robbins]

This is great, a few small requests though!

I can see it's returning a string for response aka:

{
  "result": true,
  "reason": "The command was successfully processed.",
  "vin": "...",
  "command": "vehicle_data",
  "response": "{\n  \"chargeState\": {\n    \....... more json"
}

It'd be great if response could be (un)marshaled json instead? Maybe we could try to see if it can be decoded into json and that data structure provided instead?

I'd love to see something like:

{
  "result": true,
  "reason": "The command was successfully processed.",
  "vin": "...",
  "command": "vehicle_data",
  "response": {
    "chargeState": {
      "chargingAmps": 32
    }
}

Just thinking forward if I bring this into home assistant I'll need to 'double decode' the response which I'm not sure if that's even possible.

Currently I've done this in order to get to the data:

/usr/bin/curl -X GET http://localhost:8081/api/1/vehicles/my_vin/vehicle_data | jq -r .response  | jq

[michael-robbins]

We could use the top level "result": true to determine if the response object contains parsed data or is like ?empty?

[michael-robbins]

Okey so I got it working in home assistant as-is anyway via:

restful command:

rest_command:
  get_vehicle_data:
    url: "http://localhost:8081/api/1/vehicles/{{ vin }}/vehicle_data"
    method: get

Action in automation:

action: rest_command.get_vehicle_data
metadata: {}
data:
  vin: "{{ tesla_vin }}"
response_variable: vehicle_data_response
enabled: true

Template if condition or something:

{% set vehicle_payload = vehicle_data_response["content"] %}

{% if vehicle_payload["result"] %}
{% set vehicle_data = vehicle_payload["response"] | from_json %}
{% else %}
{% set vehicle_data = {} %}
{% endif %}

{{ vehicle_data["chargeState"]["batteryLevel"] >= vehicle_data["chargeState"]["chargeLimitSoc"] }}

jinja templating has a from_json that'll take a json string and give you the object.

So up to you if you want to do any json (un)marshalling, otherwise the current branch is fine by me!

well done with it, got my tesla fully charging via local-only integrations now, no tesla HTTP API or any oauth keys required!

[wimaha]

Thank you for your feedback! I appreciate it.

I have updated the version on dev with the following changes:

• The response ist now correctly marshaled
• Flatten so that the API matches the Web API

[michael-robbins]

Looking great! Love the flattening of chargingState!

/usr/bin/curl -X GET http://localhost:8081/api/1/vehicles/$my_vin/vehicle_data | jq .response
{
  "chargeState": {
    "chargingState": "Stopped",
    "fastChargerType": "ACSingleWireCAN",
    "fastChargerBrand": "Tesla",
    "chargeLimitSoc": 70,
    "chargeLimitSocStd": 80,
    "chargeLimitSocMin": 50,
    "chargeLimitSocMax": 100,
....
}

I'll start working it into my HA automation! Cheers 🍻

[wimaha]

Nice! :-)
Next step for me is to ensure conformity with the vehicles endpoint API. So the variables should change from chargeState to charge_state or chargingState to charging_state.

[wimaha]

I have made another update on dev. Know you will get the same structure like described here: https://developer.tesla.com/docs/fleet-api/endpoints/vehicle-endpoints#vehicle-data

Example:

 "response": {
    "charge_state": {
      "timestamp": 1733778511,
      "charging_state": "Disconnected",
      "charge_limit_soc": 80,
      "charge_limit_soc_std": 80,
      "charge_limit_soc_min": 50,
      "charge_limit_soc_max": 100,
      "battery_heater_on": false,
      "not_enough_power_to_heat": false,
      "max_range_charge_counter": 0,
      "fast_charger_present": false,
      "fast_charger_type": "",
      "battery_range": 112.00361,
      "est_battery_range": 96.82592,
      "ideal_battery_range": 112.00361,
      "battery_level": 45,
      ...

You will also get climate_state. If you only want the charge_state you specify it with a query parameter as described In the link above. Example: /api/1/vehicles/{VIN}/vehicle_data?endpoints=charge_state.

Maybe I release this version before I add the other data categories.

[michael-robbins]

Yeah sweet! Let me build and test again tonight, but I've got it all working nicely now anyway, and looks like you can test yourself too, so feel free to cut a version your happy with 🍻 I'll just update my side as we go!

Interestingly enough, what other things are there? I'm guessing all of these? https://tesla-api.timdorr.com/vehicle/state

[michael-robbins]

Ohh sorry I got you now, within https://developer.tesla.com/docs/fleet-api/endpoints/vehicle-endpoints#vehicle-data you can click through to the Vehicle Data response payload and you're talking about the various top level dicts you can return.

Yeah cool! I'm only really interested in the charge stuff for my use case, but depends, I could see the climate_state or vehicle_config being interesting to expose locally in HA as sensors!

[wimaha]

In the http api there are the following endpoints: 'charge_state', 'climate_state', 'closures_state', 'drive_state', 'gui_settings', 'location_data', 'charge_schedule_data', 'preconditioning_schedule_data', 'vehicle_config', 'vehicle_state', 'vehicle_data_combo'

I don't know if any of these are accessible via ble.

[sftman18]

For the tesla-control BLE binary, these are the options accepted for the "state" parameter:

Fetch vehicle state over BLE.
CATEGORY: One of climate, precondition-schedule, parental-controls, media, media-detail, software-update, charge, drive, closures, charge-schedule, tire-pressure

I see in PR338 that they are going to expose a new state parameter "location" soon.

[demod-au]

Thanks for this update. Upgraded successfully. I'm now back to where I was before the API "lockdown". The charge stats are a great enhancement.

[michael-robbins]

With the endpoints parameter I was trying to figure out the string split delimiter (it's ;), and was messing with a few, anything apart from the right one is just accepted and immediate returns as if it's a success?

$ curl http://localhost:8081/api/1/vehicles/${my_vin}/vehicle_data?endpoints=charge_state,climate_state
{"result":true,"reason":"The command was successfully processed.","vin":"my_vin","command":"vehicle_data"}

And on the container logs I see:

2024/12/15 09:49:11 INFO sending command=vehicle_data body=map[endpoints:[charge_state,climate_state]]

So possibly just some minor validation/error returning would be epic (not like I'll experience this moving forward, but anyway)

[wimaha]

Will add a validation in next release. :-)
I will close this issue. If someone needs more vehicle data please file a PR or open a new issue.