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

Powerwall 2 Gateway API Documentation

This site may earn commission on affiliate links.
#21
cwied said:
When my Powerwalls were installed, they left the gateway plugged in to the ethernet cable, but did not set it up to actually use the Ethernet. The steps I used were the following:
1. Connect to the gateway's wifi SSID using password "S" + gateway serial ("STG...").
2. Run setup wizard on http://192.168.89.1 (I think that's the right subnet - check what you're connected to)- installer email doesn't matter, password as above.
3. In network section, turn on Ethernet.
4. Run through rest of setup wizard without changing anything.

After I did this, the gateway was on the Ethernet and I was able to connect to it using the address it retrieved over DHCP. I added the address to the static IP table on my DHCP server after I discovered that it grabbed a different one after a software update.
Click to expand...


That sounds like a great theory, but...

Here are the really curious clues:
  1. I tried to connect to the Gateway WiFi, and failed. I tried the WiFi password suggested and several permutations with no luck.
  2. The EtherNet seems to be on. There is a lot of of activity shown it's port on the basement Ethernet switch.
  3. I fired up WireShark on the same LAN as the Gateway and logged all of the 192.168.1.x addresses in use on my LAN. All of the addresses in use were either in the DHCP Lease table or in my spreadsheet of static IP's that I have assigned. A few of the DHCP leases had no ID; I verified what each of those were.
  4. I never gave the Tesla Tech login creds for my WiFi, and even if I did, it would show up on the router and local LAN. All of my WiFi access points are on the local Ethernet LAN.
  5. Cellular coverage is really bad in my basement.
How is the Gateway communicating to Tesla? The results show up on my App...
 
#22
Are you sure you're seeing all the network traffic in Wireshark? I had a cheap managed switch lying around (TP-link) and used port mirroring to verify I wasn't seeing traffic on the ethernet. After I configured the gateway, it showed up in the DHCP lease table as expected. If you can look at the arp table on your router, that'd probably be the best way to cover all the bases. My impression is static IPs are not reliable on the gateway, so I'd be surprised if it's set up that way.
 
#23
Thanks for your great work on this. I believe that GET /api/config returns what are called VINs but are effectively the product ID that you would then use through the public API to get access to the powerwall data - instead of /vehicles in the public API, it is /products

I didn't save my work when I was playing around with the public API, but I was able to successfully retrieve info about my powerwall (I don't have a car) via the /products API call
 
#24
Cottonwood said:
That sounds like a great theory, but...

Here are the really curious clues:
  1. I tried to connect to the Gateway WiFi, and failed. I tried the WiFi password suggested and several permutations with no luck.
  2. The EtherNet seems to be on. There is a lot of of activity shown it's port on the basement Ethernet switch.
  3. I fired up WireShark on the same LAN as the Gateway and logged all of the 192.168.1.x addresses in use on my LAN. All of the addresses in use were either in the DHCP Lease table or in my spreadsheet of static IP's that I have assigned. A few of the DHCP leases had no ID; I verified what each of those were.
  4. I never gave the Tesla Tech login creds for my WiFi, and even if I did, it would show up on the router and local LAN. All of my WiFi access points are on the local Ethernet LAN.
  5. Cellular coverage is really bad in my basement.
How is the Gateway communicating to Tesla? The results show up on my App...
Click to expand...


cwied was correct on all points. I had a typo in my transcribing of the Serial Number. Once I corrected that, everything worked as expected.
  1. The connection was via cellular, and I switched it back to Ethernet on my LAN.
  2. Now I can see the UI on my LAN which is much nicer, especially in crisis situations.
  3. I wonder what all the activity was on the Ethernet Switch when the Gateway was using cellular. Could that activity have just been link layer probs, etc?
Thanks to all for the help!
 
#25
i wiresharked gateway traffic on my router -- well of course it is all https'd when talking to tesla. not a big surprise but it means that we are limited to what we know from the wizard (which is not sufficient to tune up TBC autonomous mode).
 
#26
I've been tempted to set up an https proxy in the network to see how secure they made their communication. The other approach would be to check the communication between the mobile app and the server to see if the local API can be reverse-engineered through trial and error by using the server communication as a model. Of course it's also possible that they decided not to implement local endpoints for the new features at all and that it's only configurable remotely.

I'm still waiting for TBC,unfortunately, so can't play with any of it yet.
 
#28
Icepicknz said:
How long does the token last? Doesn’t appear to be that long even though the token response says for a day.

Also when I authorize I’m having to issue a run right afterwards so the powerwall continues to operate anyone else seen this?
Click to expand...

I always get a token before getting a command, so don't worry about it expiring.

Yes, as soon as you authorise, the powerwall stops. You must always issue a run. I've got my control code in a critical section, and a run outside the critical section and, just in case, in the exception handler around that, so it always re-starts.
 
#29
Hmm, I could have sworn that for me it stops after receiving commands, not after authenticating. I do always do all three at once too (authenticate, send command, commit changes) to avoid downtime. I haven't noticed the tokens expiring early, but my code automatically reauthenticates if it gets a permission denied response so I haven't actually tried it in a while.
 
#30
cwied said:
I've been tempted to set up an https proxy in the network to see how secure they made their communication. The other approach would be to check the communication between the mobile app and the server to see if the local API can be reverse-engineered through trial and error by using the server communication as a model. Of course it's also possible that they decided not to implement local endpoints for the new features at all and that it's only configurable remotely.

I've tried a man-in-the-middle attack on the gateway's https data, but it wants a server certificate signed by an internal Tesla CA, and rejected my fake certificate. Absent a viable attack on RSA (doesn't currently exist), or patching the firmware directly in the gateway (don't see it happening until gateways start failing out of warranty at the earliest), the data is going to remain invisible.

I did patch the Tesla Android ap to allow a MIM attack on its data (It uses certificate pinning, so just installing a new CA isn't sufficient). It is also using JSON to communicate with the server, but I couldn't see any obvious link between what it's sending and what the gateway's own web interface accepts. I'll take another look when the TOU version of the ap becomes available to me.
Click to expand...
 
#31
BJReplay said:
I always get a token before getting a command, so don't worry about it expiring.

Yes, as soon as you authorise, the powerwall stops. You must always issue a run. I've got my control code in a critical section, and a run outside the critical section and, just in case, in the exception handler around that, so it always re-starts.
Click to expand...

I've also noticed that the powerall stops for a short period when the reserve percentage is set, so one wants to avoid doing that during a blackout.There remains the relatively remote possibility that a blackout starts just as one does this, and the question of whether the system that's making the change, and all hardware involved in the networking, will remain up long enough for the commit to be performed.
 
#33
Does anyone know if there is a unique identifier when querying the gateway using GET api/aggregates. I can use pvoutput to generate a daily logfile. But I need to prove that this data came from my specific powerwalls. Any suggestion of help would be greatly appreciated.
 
#34
Kren said:
Does anyone know if there is a unique identifier when querying the gateway using GET api/aggregates. I can use pvoutput to generate a daily logfile. But I need to prove that this data came from my specific powerwalls. Any suggestion of help would be greatly appreciated.
Click to expand...

The value you're using as the password appears to be the serial number, so it shoud be unique, as should the MAC address. However, nothing you retrieve from the gateway could possibly consitute proof, in a formal sense, that the associated data also came from the gateway because anything you can retrieve can also be falsified.
 
#35
Sylvia Else said:
The value you're using as the password appears to be the serial number, so it shoud be unique, as should the MAC address. However, nothing you retrieve from the gateway could possibly consitute proof, in a formal sense, that the associated data also came from the gateway because anything you can retrieve can also be falsified.
Click to expand...
That's a good point. Thanks.
 
#36
Anyone else running 1.17.2 and having issues with the API?

I have a gateway and 2 powerwall2 at home, the gateway part number is 1118431-01-G with serial ST17KXXXX (1.15.10)

At a second address I had a single gateway part number 1118431-01-H installed with serial STG1180XXXXX (1.17.2)

It would appear the second address I can't connect to the API, I get
"Invalid Credentials","message":"Login Error", I even tried setting
force_sm_off":true after seeing this in a git hub fault category for someone else running 1.17.2.

Powerwall isn't behaving correctly and i have a fault logged with tesla but they don't work weekends (the joys of getting an install done on a friday!), so hope to hear back tomorrow on whats going on.
 
#38
Icepicknz said:
running 1.18.0
While i can set ToU setting in the app; can't do via the API

curl --header "Authorization: BearerTOKEN==" -X POST -d '{"mode":"autonomous","backup_reserve_percent":5}' http://192.168.33.5/api/operation
{"code":500,"error":"Mode must be either self_consumption or backup","message":"Unable to set operational mode"}Barrys-MacBook-Pro:~ barrymurphy$
Click to expand...

Unfortunately this seems to be the way they're going to leave it for now. It appears that they're only going to support TOU as a "preconfigured mode" in the wizard, so there isn't a local API endpoint to configure it. I'm guessing they don't want the installers to have to worry about setting up rate plans and explaining the difference between cost savings and balanced.
 
#39
Thats a real shame; however understandable. I will still be using API calls as my ToU is a bit more complex than standard, just wanted to enable their ToU so that it charged the batteries faster (runs twice as fast as 'backup').

Im also noticing the API calls don't always activate. while i see they have taken the call to self consume and the app even shows it, I have to do the API call multiple times sometimes to get it to self consume :/
 
You must log in or register to reply here.

Similar threads

D
Can't access Gateway 2 through network?
Replies
2
Views
854
Tesla Energy
DrSmile
D
A
unusual message on gateway local access
Replies
1
Views
417
Tesla Energy
jgleigh
jgleigh
E
Wrong Grid Reading by Powerwall
Replies
22
Views
4K
Tesla Energy
jgleigh
jgleigh
A
Powerwall 2 Monitoring
Replies
1
Views
1K
Tesla Energy
jjrandorin
J
EightBitWhit
(Please) rate my setup - how does this look?
Replies
25
Views
1K
Tesla Energy
EightBitWhit
EightBitWhit
Top
Back
Blog
New
Forum list
Marketplace
Menu