I saw that in version 4.1 one can alter the charge Amp’s so I guess it will be in the API soon:) I know it’s not taking care if one would charge a non Tesla or Tesla not own by the owner of the charger but for personal use it would be perfect to change the charge Amp via the API.
As @Klangen82 pointed out, Tesla app can control only Tesla cars. We have a non-Tesla so 
TWC gen 3 is currently the cheapest charger with fixed cable and DC-fault current measurement. And there is HW for current adjustment, so I want to use it.
I did a small try out with the TWC:
- I added a new SSID to my WIFI: TeslaWallConnector_001122, password must be 12 characters, with capital letters (numbers were not accepted by TWC)
- Rebooted TWC
- Started capture in LAN
- Joined to TWC’s own WIFI, with a laptop
- Selected Add second TWC
Capture did show just some mDNS messages (pcap -file here:
MDNS.pcapng - Google Drive ). To me it looks pretty much the same as in normal startup (mDNS sent to normal WIFI network).
The next step would be creating a Python script that sends back something similar, so that TWC believes it has found a friendly neighbour… What would be an easy way of creating random mDNS messages?
I’ve got an old version of the firmware, don’t want to manually update it so I’ve come up with my own command_line and template integration:
Add more template sensor/binary_sensor entries if you want to expand the sensor list - just pull the values from the sensor.twc_lifetime or sensor.twc_vitals sensor attributes as I have done with the mine.
The idea is that you dont want to be polling the endpoints separately for each value, but instead poll once to extract all the info into a single sensor w/attributes then split those out to separate sensors using template sensors.
sensor:
- platform: command_line
name: "TWC lifetime"
unit_of_measurement: "kWh"
json_attributes:
- contactor_cycles
- contactor_cycles_loaded
- alert_count
- thermal_foldbacks
- charge_starts
- connector_cycles
- uptime_s
- charging_time_s
- energy_wh
command: "curl -s 'http://192.168.4.22/api/1/lifetime' | sed 's/:nan/:NaN/g'"
value_template: "{{ value_json.energy_wh | multiply(0.001) | round(1) }}"
- platform: command_line
name: "TWC vitals"
unit_of_measurement: "A"
json_attributes:
- contactor_closed
- vehicle_connected
- session_s
- grid_v
- grid_hz
- vehicle_current_a
- currentA_a
- currentB_a
- currentC_a
- currentN_a
- voltageA_v
- voltageB_v
- voltageC_v
- relay_coil_v
- pcba_temp_c
- handle_temp_c
- mcu_temp_c
- uptime_s
- input_thermopile_uv
- prox_v
- pilot_high_v
- pilot_low_v
- session_energy_wh
- config_status
- evse_state
command: "curl -s 'http://192.168.4.22/api/1/vitals' | sed 's/:nan/:NaN/g'"
value_template: "{{ value_json.vehicle_current_a | round(1) }}"
- platform: statistics
entity_id: sensor.twc_lifetime
template:
- sensor:
- name: "TWC Delivery Current"
unit_of_measurement: "A"
device_class: current
state: >
{{ state_attr('sensor.twc_vitals', 'vehicle_current_a') }}
- name: "TWC Delivery Power"
unit_of_measurement: "kW"
device_class: power
state: >
{{ (state_attr('sensor.twc_vitals', 'vehicle_current_a') * state_attr('sensor.twc_vitals', 'voltageA_v')) | multiply(0.001) | round(1) }}
- name: "TWC Session kWh"
unit_of_measurement: "kWh"
device_class: energy
state: >
{{ state_attr('sensor.twc_vitals', 'session_energy_wh') | multiply(0.001) | round(1) }}
- name: "TWC Handle Temperature"
unit_of_measurement: "°C"
device_class: temperature
state: >
{{ state_attr('sensor.twc_vitals', 'handle_temp_c') }}
- name: "TWC MCU Temperature"
unit_of_measurement: "°C"
device_class: temperature
state: >
{{ state_attr('sensor.twc_vitals', 'mcu_temp_c') }}
- name: "TWC PCBA Temperature"
unit_of_measurement: "°C"
device_class: temperature
state: >
{{ state_attr('sensor.twc_vitals', 'pcba_temp_c') }}
- binary_sensor:
- name: "TWC Vehicle Charging"
device_class: battery_charging
state: >
{{ is_state_attr('sensor.twc_vitals', 'contactor_closed', true) }}
- name: "TWC Vehicle Connected"
device_class: connectivity
state: >
{{ is_state_attr('sensor.twc_vitals', 'vehicle_connected', true) }}
homeassistant:
customize:
sensor.twc_lifetime:
device_class: energy
state_class: total_increasing
Just to let people know on this thread that there is a Gen 3 integration coming with the 2021.12 release:
I tested it but it will no connect to my wall connector 
I can access the web interface from my laptop and from HA.
Perhaps raise a bug report on GitHub?
1 Like
This is a great integration so thanks for finding these API calls. One question I had though, is what do the numbers for ease_state mean? When my car is idle it seems to be 4, but when charging it seems to change from 1 to 11 to 9. Just curious if there is a mapping for what those numbers mean.
Thanks
3 Likes
I found out that a long press on the Tesla charging port button can enable the maintenance mode on gen 3 TWC (SSID advertisement and changing charging current is possible.
According to some teardown videos there are 4 thinner wires connected to charging port. One or more likely two wires are connected to the button. So it would be possible to install there some wireless relay to enable the maintenance mode one-the-fly. By default this would stop any Tesla charging for the time when button is pressed, but charge does resume immediately. Another option is to disable the actual button by leaving the wires unconnected.
Has anybody tried this yet?
Hi,
i tried the Lifetime api but the Wh values it returns are a bit strange. I made a simple test, used the Lifetime api before a charging session and again right after the charging is ready. The delta between these two Wh readings was aroun 120000 Wh, e.g. about 120 kWh. The actual energy charged was about 36 kWh based on the info from the car. Any idea what unit the claimed Wh provided by Lifetime is?
Can anyone advise on how to interpret this data? I’m surprised to see current & voltage for 3 phases, even though I am using standard US 240 split-phase power. All three are reporting current & voltage during charging. What’s the meaning of Phase A,B, and C?
I’d like to chart KW in use but am unclear which values I should be using.
The unit Wh is correct. I can only assume, but there is something wrong with the way the wall connector measures the consumed energy. I am experiencing similar issues with large non-realistic readings. Looking into the historical data from my wall connector I am noticing that the api reports a large chunks of energy consumed in no time especially when the car was unplugged.
Did anyone else experience similar energy reports?
Is there a way to pilot charging current for gen3 via api? Thanks
5 Likes
Hi Miroslav,
I do have the same spurious power consumptions and I just contacted Tesla and sent them some examples…
Lets wait for their explanation 
1 Like
Hi davrog10! Have you ever figured out how to pilot the charging current for the Tesla wall connector gen 3 via API? I am very interested in it…
Hi Jarkko! Have you ever figured out how to pilot the charging current for the Tesla wall connector gen 3 via API? I am very interested in it…
Hi Oliman,
No progress on that front so far. We have two electric cars, and currently we are keeping Tesla in front of TWC (and with that car controlling the charge happens via car).
On plus side is the capability to use also below 6A currents. Negatives include also no support for other cars (I just had a loaner for 4 weeks).
Summary of different possible ways to control the pilot from charger:
- Tesla to publish API, this would be awesome
- Reverse engineering from firmware image (I failed here)
- Reverse engineering communication between two TWC gen 3 and create virtual master device based on this (I was too lazy to do this properly, with only one charger this requires a lot of iteration)
- Set up RPi to join the TWC Wifi and keep TWC in the state where the RPi can change the current
- Turn on the maintenance mode on request with the button trick
1 Like
I sent a reminder mail on Friday (after a full week waiting in vain for an answer)… Still no response…
There is no other way to get any support but via mail and they are simply not answering… There is not only an evident bug in the firmware of the company invented “computers on wheels” but TESLA is not even reacting in any way…
Btw: I updated my Wall Connector to revision 21.36.6+g195ba83f335ac2, but the spurious energy consumption will still be reported and accumulate over time.
Update: There was only one jump after the latest firmware update till now… The bug may have been successfully fixed:
1 Like
We have a pair of Gen3 wall connectors with load sharing configured - When sharing is enabled, the secondary unit drops off the local network and I cannot access the API endpoint. When connecting to the local access point to come up with 192.168.92.2 in the wifi config page (despite being connected to it to read the info on 192.168.92.1) in the rather than the one assigned by the site, but I can’t reach that, even via the master wall connector,
Is this a known issue / firmware bug? I checked and we’re still on the 21.36.5 release with no new updates available
1 Like
I don’t have two wall connectors so I cannot test this out. But what I understand you only have one wall connector connected as master to you local wifi then the others connect to the master via wifi. So you should be able to get all info from the master, but I have no way to test this. I’m just curious what you see when you are accessing this address? http://IP_master/api/1/vitals and http://IP_master/api/1/wifi_status (change the IP_master to the master IP address you see on your local network)
Maybe you could post your findings?
You can read about how it works here Gen 3 Wall Connector Power Sharing | Tesla and you can also download the latest firmware (21.36.6)