Charger template for tesla-ble

[skrul]

This change compliments the tesla-ble vehicle template (see #17866) by interfacing with TeslaBleHttpProxy to control charging. This is useful for folks that are using TeslaBleHttpProxy to communicate with their Tesla but who do not have the TWC (wall charger) but rather use the UMC (mobile charger).

Several of the field definitions are the same as the tesla-ble vehicle template since there seems to be a bit of overlap between the vehicle and charger devices.

An example config (has the same fields as the tesla-ble vehicle template):

chargers:
  - name: my_charger
    type: template
    template: tesla-ble
    vin: 5YJ3E1Exxxxxxxxxx
    url: http://10.0.0.104

[skrul]

@andig I noticed that chargers can take a power getter so I'm trying this since TeslaBleHttpProxy provides voltage and amps. However, it works fine without this (I assume evcc just estimates this but I haven't found that code yet). Curious if you think it is worth keeping?

[andig]

Dunno. Worth keeping it its better than the estimate.

[andig]

This wont work. Enabled is not charging. Enabled is „allowed to charge“.

[wimaha]

This works for 1 phase. You should check if 1 oder 3 phases are used.

[skrul]

@wimaha should I be multiplying by charger_phases?

[andig]

Friendly ping @wimaha

[wimaha]

I think if charger_phases is >= 2 you should multiply by 3. this way old Tesla are also supported.

[wimaha]

Is evcc polling one of the values to detect a new charging process?
If so the vehicle would not go to sleep.

[andig]

Like with every other wallbox evcc reads the connected/charging status each cycle.

[skrul]

@wimaha yes, the polling is a bit of an issue -- it does keep my car awake all the time:

Do any of the BLE commands not wake up the car? Perhaps there is something else that can be used for status and enabled. I did spend some time experimenting with esphome-tesla-ble and I think it was able to expose a few sensors without waking up the car, notably whether the car was sleeping and what the state of the charge flap is. If these are indeed available without waking up the car, perhaps status could be derived:

Charge flap closed = A (no vehicle connected)
Charge flap open = B (vehicle connected)
Car not sleeping = B (vehicle connected) or C (vehicle charging) depending on an active check of charging state

@andig I'm still not sure what enabled means -- you said "allowed to charge" but how would that differ from status B?

[skrul]

@wimaha Ah unfortunately I see now that checking the charge flap state requires the car to be awake. Perhaps the best thing to do here is going to be to buy a wall charger 😢

[Lenart12]

All vehicle_data requests wake up the car since they are part of the infotainment domain. Perhaps this is best solved by implementing a ?nowakeup=true modifier to the proxy. Btw it is also possible to get chare port state with body-controller-state, which does not wake up the car.

[skrul]

@Lenart12 oh that sounds promising! thanks, I'll dig into that 😄

[skrul]

Ah unfortunately it seems that body-controller-state does not report closureStatuses when the car is asleep 😢

[Lenart12]

It does! There is a bug in current version. wimaha/TeslaBleHttpProxy#87 (comment)

[skrul]

@Lenart12 very cool! I'll test your branch out. I'm curious what you think of the logic for status that I outlined above, particularly to determine the C state without waking up the car. It would require two commands (is car online, is car charging) which would be beyond evcc's config capabilities. I think it would require adding a new endpoint to TeslaBleHttpProxy, say /api/proxy/1/vehicles/VIN/evcc_charge_status or maybe give it a name that references the standard (?) that evcc uses for these states.

[Lenart12]

I guess I would add it like this, but I have no idea what this is about really... I'm using the proxy for another project; we just run in to the same problems :D

  status:
    source: http
    uri: {{ .url }}:{{ .port }}/api/1/vehicles/{{ .vin }}/vehicle_data?endpoints=charge_state&nowakeup=true
    method: GET
    jq: (if (.response.reason == "failed to get vehicle data: car is asleep") then "B"
      elif (.response.response.charge_state.charging_state == "Charging") then "C"
      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" 
      else "A" end)
    timeout: 30s

[skrul]

@andig Perhaps you could offer some guidance here. In order to get the charger state without waking the car using tesla-ble, I need to query one endpoint to determine the sleep state and charge flap state. If the care is asleep, the charger state is derived from the car flap state (flap closed = A, flap open = B). If the car is awake, I will query a different endpoint to get the actual charger state.

I don't think there is an existing provider that can handle this complex logic -- there are no get providers that have any kind of branching. Perhaps the switch provider could be enhanced to include a string getter? Or a new ifelse provider? Or am I missing a way to do this?

Alternatively, I can try adding a evcc-specific endpoint to TeslaBleHttpProxy, although I'm not sure the maintainer will want evcc-specific code in there.

[andig]

I don‘t think you can do that with templates.

[Lenart12]

What about fetching with source: javascript?

source: js
script: >-
  let bcs = fetch(...)

[skrul]

@Lenart12 this is a nice idea but unfortunately it seems that stuff like fetch and XMLHttpRequest are not available in the javascript environment that evcc provides. I also thought of trying this with the embedded go plugin but I don't think you can import additional modules.

[skrul]

Unfortunately, I don't think this is going to work. According to teslamotors/vehicle-command#368 the charge port status is not correctly reported using the BodyControllerState API. Unless there is some way to determine if the car is plugged in without waking it up, I don't think using TeslaBleHttpProxy as a custom evcc charger is going to work.