Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

Discussion: How to get status information from your Powerwalls

This site may earn commission on affiliate links.
This is the best I can do that's as "easy" as possible, all done in a Chrome browser.
  • Using your gmail account create a new blank Google Sheet.
  • In your new blank Google Sheet open Tools > Script editor:
  • When the Apps Script page loads in another tab, clear whatever is in there and paste in this code, and save. I noticed that sometimes my browser hangs and you just have to close the tabs and reload the Google Sheet and repeat it until it comes up.
  • Refresh the tab with your Google Sheet and you should see a new option appear called Custom Menu:
  • If you click on Custom Menu > Get Products, the first time it's going to ask you to authorize access for this script through a series of pages:
View attachment 670239 Click Continue.​

View attachment 670240 Pick the gmail account you want to use, if more than one.​

View attachment 670241 Click Advanced.​
View attachment 670244 Click Go to Untitled project.​
View attachment 670245 Click Allow.​
  • After you finish the Google authentication steps, one time only, it will show a pop-up asking for your access token. You can get your access token here (use at your own risk) but be careful not to save it where anyone can access it as it will grant full access to your Tesla products - solar, powerwall, and vehicles.
  • It will print out the data starting in whichever cell your cursor is in. You can add as many sheets as you want on bottom left corner with the + symbol, Add Sheet, and execute whichever of the Custom Menu items you want to print out data from Tesla API.

If you think it's easy enough, I can add more API calls in the Custom Menu over time. You'll just have to pick the the latest code in GitHub and paste over what was there previously in the Script Editor, save, and reload your Google Sheet.

I figured out how to get the access and refresh tokens working again via Google Apps Script. If you're interested, let me know and I can add it as a function to run from the Google Sheet.
 
Thank you! The script is working now, however when I select get battery data, it asks for battery ID, How do I get that?
Yay! If you run Get Products from the Google Sheet it will list all your Tesla products, vehicles, solar, and battery. It will be grouped with attributes like "energy_site_id" and "resource_type". The battery ID will be the "id" attribute in that group. Mine starts with "STE".
 
Hey y'all. Please let me know if a new thread is appropriate. I love what you've done with Google Sheets, but to try and diagnose my annoying Daily reset/shutdown of my Powerwall+ and/or Inverter after coolant top-off? problem, I just wanted to pull some status data from my Gateway directly to see if there was any kind of Alert that came along with the reset.

To that end, I ended up writing some shell scripts that use curl to regularly pull the info (oh, I should probably add my crontab entries.)

Feel free to have a look, add enhancements, etc.:

Thanks!
 
Oh hey, I found a new api endpoint, but it gives me a binary file: https://teg/api/devices/vitals

I'm interested in these bits that showed up with the strings command:
Code:
THC_State*
THC_STATE_AUTONOMOUSCONTROL
THC_AmbientTemp!

I used this curl command, after authenticating and storing a token in cookie.txt:
Code:
curl -c cookies.txt -b cookies.txt -s -k -O https://teg/api/devices/vitals
 
Oh hey, I found a new api endpoint, but it gives me a binary file: https://teg/api/devices/vitals

I'm interested in these bits that showed up with the strings command:
Code:
THC_State*
THC_STATE_AUTONOMOUSCONTROL
THC_AmbientTemp!

I used this curl command, after authenticating and storing a token in cookie.txt:
Code:
curl -c cookies.txt -b cookies.txt -s -k -O https://teg/api/devices/vitals
The binary data after the text strings is the value, in 64-bit IEEE-754 Floating Point notation. There is a ! character separating the text from the number, and the 8 bytes are in little-endian format.

For example, in the vitals file is the text:
Code:
THC_AmbientTemp!

This is followed by 8 bytes (shown here as hexadecimal digits):
Code:
CE CC CC CC CC CC 40 40

Here they are in big-endian format (again shown as hexadecimal digits):
Code:
40 40 CC CC CC CC CC CE

Those 8 bytes comprise the 64-bits of the IEEE-754 Floating Point number.

The decimal equivalent of that is 33.6 which is the temperature in Celsius. (92.5°F)


Text fields that are followed by a * character have a text value after them (enumeration).

The object:
Code:
THC_State*
has the value:
Code:
THC_STATE_AUTONOMOUSCONTROL


An interesting one in this file is:
Code:
POD_DC_Bus_Voltage!
which has a value of 428.1 volts.
 
Has anyone figured out which APIs are used to show the "Powerwall Charge Level" chart in the new Tesla app?
Looking at the endpoints list from the new app, I'm guessing this is either a new `kind` in `calendar_history`, or it's part of `telemetry_history` - but I haven't been able to get either to work.
 
Has anyone figured out which APIs are used to show the "Powerwall Charge Level" chart in the new Tesla app?
Looking at the endpoints list from the new app, I'm guessing this is either a new `kind` in `calendar_history`, or it's part of `telemetry_history` - but I haven't been able to get either to work.

I would love to know this too. I've tried guessing a few different "kind"s, such as 'percentage_charged' but that just returns
Code:
{'response': None, 'error': 'kind `percentage_charged` is not supported', 'error_description': ''}

I even tried passing the Tesla iOS App traffic through an SSL proxy to sniff the commands but that doesn't work because it appears the Tesla App uses SSL Certificate Pinning where the app itself verifies the Tesla root certificate and does not accept the SSL Proxy certificate. And if one passes the traffic through a normal Proxy, the Tesla App works, but all you see is encrypted data which is useless.

In the past, I have estimated the powerwall charge level from the accumulated power flows, but of course due to conversion losses and other factors, that just drifts over time and has to be corrected. So to get the exact values would be great. If only we knew the API command to pull them...
 
  • Like
Reactions: tomho
I’ve done some more playing around with the API but haven’t had success on extracting the historical battery percentage charged data. Surely someone on the planet knows how to do it and can answer here 😄

I didn’t have any success getting any data out of the “telemetry_history” endpoint, everything I tried produced an empty response. So I have no idea what that one is supposed to do.

So I suspect the required command is either a new “kind” in the “calendar_history” endpoint, or an entirely new endpoint not listed in Tim Dorr’s endpoints file. I don’t know how/where he gets that endpoint file from, so it’s not guaranteed to be 100% comprehensive.

I suspect the battery percentage history is a new report that is different to all the other ones you can pull. For a start, on the Tesla App if you select “download my data” when the daily charts are being displayed, the downloaded CSV does include the battery percentage history for that day as shown in the chart in the App. BUT it is only reported at every 15-minute interval and not the intermediate 5-minute intervals - they are shown as blank cells. That strongly suggests the downloaded CSV file is a merge of data from two different endpoints.

So - I am pleading for any Tesla employees lurking here to put us out of our misery! 🙏 Thanks!
 
So I suspect the required command is either a new “kind” in the “calendar_history” endpoint, or an entirely new endpoint not listed in Tim Dorr’s endpoints file. I don’t know how/where he gets that endpoint file from, so it’s not guaranteed to be 100% comprehensive.
The endpoints file is easily discoverable by decompiling the APK. I think it's safe to assume that this is the source of the list on Tim's repo and that it's accurate.
Unfortunately this info isn't sufficient to know how these APIs are designed to be used. I also tried using an HTTP proxy on an older Android emulator but I couldn't get it to work either.
 
The endpoints file is easily discoverable by decompiling the APK. I think it's safe to assume that this is the source of the list on Tim's repo and that it's accurate.
I see - I live in an iOS world and have no idea if there is a comparable way of doing that on Apple. I’m not an App developer.

I’ve only found one command so far in the API which, when throwing an error, actually returns useful data as to what the permitted inputs are instead of just telling you ‘x’ is not supported. Unfortunately, it was not for ‘kind’ in ‘calendar_history’ 🤬

What I am pleased about is that at least now I can automate the downloading of historical PW2 power data and get it in Watts instead of kW rounded to one decimal place (as per the CSV file) - and jump directly to specific days rather than laboriously scroll manually through previous days in the App and hitting ‘download my data’. I always thought 100W resolution in the CSV file was inadequate to do proper analysis.
 
  • Like
Reactions: BGbreeder
Thank you @power.saver! I'm good at poking around things with Chrome and curl, but not so much with binary data. I've posted your findings to Vince's repo where he's been documenting the API: Found a new endpoint, but it returns a binary file · Issue #51 · vloschiavo/powerwall2

(I also realized belatedly that he already published a perfectly functional shell script that would effectively do the same thing as mine.)
@darryllee or @power.saver, has anyone implemented a decoder for the binary data yet? The base64 part is easy, but then has anyone figured out the overall structure of the binary data to properly step through the variables and populate a data structure? I observed that the byte preceding each variable name tells the length of that name, and @power.saver identified the meaning and structure of some of the characters following the variable name. The presence of linefeed characters after each variable is unusual for a binary file, and some of the instances of linefeed appear to be just part of some binary value.

I'm interested in this endpoint because it contains the individual MPPT data for the solar inverter in the Powerwall+.
 
@darryllee or @power.saver, has anyone implemented a decoder for the binary data yet? The base64 part is easy, but then has anyone figured out the overall structure of the binary data to properly step through the variables and populate a data structure? I observed that the byte preceding each variable name tells the length of that name, and @power.saver identified the meaning and structure of some of the characters following the variable name. The presence of linefeed characters after each variable is unusual for a binary file, and some of the instances of linefeed appear to be just part of some binary value.

I'm interested in this endpoint because it contains the individual MPPT data for the solar inverter in the Powerwall+.
I've done nothing further than what was posted earlier. This file isn't very useful to me as I don't have PW+ or Tesla inverters. I'm not sure that a fixed structure exists. They keep adding data to this file and it changes the position of some of the other elements. I think you have to parse it with the so far known rules for the fields to see what it contains.