I got my Tesla Wall Connector Gen 3 yesterday and wanted to integrate this with HA, did not find any integration so I started to find a way and just wanted to share how i did this. Probably there is better ways and deeper way of doing this then please let me know below, I’m just a newbie
I want four things when it comes to Tesla Wall Connector and these are:
See if a vehicle are connected to the charger
Be able to get how much energy last charging session was
Be able to control how much Amp the charger is giving to the vehicle
Be able to turn on/off the charging capabilities
I managed to get two out of four done yesterday and will instigate future how to solve all my asks. There is a API that is undocumented so it’s a bit like finding a needle in the haystack but below is some API calls:
http://>IP address</api/1/vitals
http://>IP address</api/1/wifi_status
http://>IP address</api/1/lifetime
http://>IP address</api/1/version
http://>IP address</tedapi/v1
The one I think is the most useful are the first one Vitals, so I created one sensor and one binary sensor. The sensor display how much energy Wh used by the last charging session and the binary sensor display if a vehicle is connected or not.
Leaving a comment for subscription. Have any further APIs been discovered? I also have the Use case of setting Amps remotely. Would like to contribute also. How did you reverse engineer the APIs?
Sorry to say I have not, I have tried to Wireshark the communication but have not been successful to find out more I also tried to look into the firmware but I’m not a hacker and it seams to encrypted.
I found one more API call:
http:///api/1/lifetime
It’s harder to find the way how to send Amps and on/off as it’s a POST command, so we need to figure out how the amps are formatted and where to send the info. It’s just a matter of testing back and forth to try to find the say, getting into the head of the engineering’s that built the API.
Great information. Is somebody already doing an integration based on this API-call data. Neat that there is serial number for HA unique ID too.
–
Just adding information about TWC from pi-hole, TWC gen3 seems to talk to “maestro-prd.sn.tesla.services” DNS-name… Then it also queries pool.ntp.org for time sync.
I saw that there is a new firmware but my charger did not auto update so I needed to do it manually. You can go to http://IP-of-charger/service and manually update the FW. After this you have power sharing as an option but to enable power sharing one would need add a second wall connecters and I don’t have that So if one have two and can do some Wireshark between these two it would be nice!
Other potential API directories and calls from firmware file…
/access
/alerts
/fwupdate
/installation
/service
/sharing, /sharing/add, /sharing/settings
/wifi
I updated to 21.29.1 fw-version of TWC and unfortunately /api/1/lifetime -stopped working. So if that data is important for you (like it would be for me) don’t upgrade.
The fault is the TWC is producing illegal JSON, as ‘nan’ is not allowed but ‘NaN’ would be.
I fixed the template as first solution found, using template’s regex_findall_index. But maybe rest-api “value” could be read and replaced with regex ‘nan’ to ‘NaN’ and then forward this data to template which decodes JSON as previously. That would be better solution…
sensor:
- name: "TWC lifetime contactor cycles"
value_template: '{{ value | regex_findall_index("contactor_cycles\":\s*(\d+)") | int }}'
- name: "TWC lifetime contactor cycles loaded"
value_template: '{{ value | regex_findall_index("contactor_cycles_loaded\":\s*(\d+)") | int }}'
- name: "TWC lifetime alert count"
value_template: '{{ value | regex_findall_index("alert_count\":\s*(\d+)") | int }}'
- name: "TWC lifetime thermal foldbacks"
value_template: '{{ value | regex_findall_index("thermal_foldbacks\":\s*(\d+)") | int }}'
- name: "TWC lifetime charge starts"
value_template: '{{ value | regex_findall_index("charge_starts\":\s*(\d+)") | int }}'
- name: "TWC lifetime energy kWh"
value_template: '{{ value | regex_findall_index("energy_wh\":\s*(\d+)") | multiply(0.001) | float(3) }}'
unit_of_measurement: kWh
device_class: energy
- name: "TWC lifetime connector cycles"
value_template: '{{ value | regex_findall_index("connector_cycles\":\s*(\d+)") | int }}'
- name: "TWC lifetime uptime"
value_template: '{{ value | regex_findall_index("uptime_s\":\s*(\d+)") | int }}'
unit_of_measurement: s
- name: "TWC lifetime charging time"
value_template: '{{ value | regex_findall_index("charging_time_s\":\s*(\d+)") | int }}'
unit_of_measurement: s
Hi,
I have updated to the 21.29.1 and all call works.
I tried to access /sharing, /sharing/add, /sharing/settings and it briefly display a page but does not allow to modify anything.
The pages :
/access
/alerts
/fwupdate
/installation
give an error
Wireshark and two devices are needed in deed for current control. When adding the slave units for power sharing, master needs to know the slave unit’s SSID and WIFI password.
However Wiresharking might be difficult, as the master is connecting to slave’s own hotspot. So the obvious way would be creating your own honeypot: RPI to advertise Tesla named Wifi, configure master TWC to connect RPI, record requests and start creating responses. Eventually it should be possible to figure out how master tries to limit slave current settings…
For time being this is too much work for me, but later. Better yet, if there is someone with more experience who is willing to dig into this
Easier approach might be connecting to Tesla Wifi right after power on, and keep the connection on forever… This would require a dedicated RPi. My first try with Chrome’s developer mode and copy-as-cURL failed. At least Chrome could keep the configuration state active for over 15 mins (changed succesfully the current setting after "uptime_s":2872).
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 templatesensor/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.