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

Discrepancy between app and Powerwall API

This site may earn commission on affiliate links.
You're not looking at DHCP leases, you're looking at W-Fi networks. How is your gateway connected to your network? Wi-Fi or Ethernet or not at all?
This is really perplexing me. I am assuming the gateway is connected by Wi-fi. But I cannot see it connected I tried to view DCHP leases using ipconfig and also by typing the router ip address in my browser. I only have 9 wireless devices connected to my router but non of them are the powerwall. It's not connected by Ethernet. So I have no idea.
 
I am using PVOutput to log the house load, PW SoC, solar and grid. I am using an old laptop to poll the Backup Gateway, using the monitor service from PVOutput. You will need IP address of the Backup Gateway.

Besides WiFi and Ethernet, PW can also connect to internet via cellular service. If that is the case, you won't find the Backup Gateway on your LAN.
 
This is really perplexing me. I am assuming the gateway is connected by Wi-fi. But I cannot see it connected I tried to view DCHP leases using ipconfig and also by typing the router ip address in my browser. I only have 9 wireless devices connected to my router but non of them are the powerwall. It's not connected by Ethernet. So I have no idea.

Tesla doesn't like to use Wi-Fi because spotty connectivity becomes a support issue, so they prefer Ethernet or LTE. There's a good chance they just connected it using LTE. If there's a strong Wi-Fi signal from your house where the gateway is located, you can reconfigure it to use Wi-Fi. Or alternatively (and probably a better idea), you can connect a computer to that TEG-xxxx network using Wi-Fi. You won't have Internet access (maybe use two Wi-Fi adapters at once if you need that), but you'll be able to access the API. The password for the TEG network is the gateway serial number. It looks something like ST17G#######. Once you've connected to that network, you can connect a browser to the gateway's IP address. I don't recall what that is off-hand, but hopefully someone else can chime in with it, or I can explain how you can figure it out. (Hint: It will be in your arp table right after you connect, and it might also be your computer's gateway address.)
 
  • Informative
Reactions: Kren
Tesla doesn't like to use Wi-Fi because spotty connectivity becomes a support issue, so they prefer Ethernet or LTE. There's a good chance they just connected it using LTE. If there's a strong Wi-Fi signal from your house where the gateway is located, you can reconfigure it to use Wi-Fi. Or alternatively (and probably a better idea), you can connect a computer to that TEG-xxxx network using Wi-Fi. You won't have Internet access (maybe use two Wi-Fi adapters at once if you need that), but you'll be able to access the API. The password for the TEG network is the gateway serial number. It looks something like ST17G#######. Once you've connected to that network, you can connect a browser to the gateway's IP address. I don't recall what that is off-hand, but hopefully someone else can chime in with it, or I can explain how you can figure it out. (Hint: It will be in your arp table right after you connect, and it might also be your computer's gateway address.)
Works! thank you. I tried logging into the TEC-xxx but I did not put the letter S before the serial number. Once I did that I was able to log in. I used the arp-a command to find the ip address. So now I am up and running.
 
  • Like
Reactions: Ulmo and Parzival
I am using PVOutput to log the house load, PW SoC, solar and grid. I am using an old laptop to poll the Backup Gateway, using the monitor service from PVOutput. You will need IP address of the Backup Gateway.

Besides WiFi and Ethernet, PW can also connect to internet via cellular service. If that is the case, you won't find the Backup Gateway on your LAN.
Thanks. I have found the gateway ip address so now I can check out PVOutput.
 
We should form a team. Is there a TMC team on PVOutput?[/QUdOTE]
Good idea. There's no team that I know of. I am trying to produce the field test data required by SGIP when/if they come to do a field test inspection for the final ICF documentation. It may be unnecessary if Tesla plays nice and supplies it for us. But even so it is really cool to view detailed Powerwall stats.
 
  • Like
Reactions: NuShrike
I'm a bit amused that people continue to develop a way to monitor their PW2 when it has been developed and refined on pvoutput.org. I guess it boils down to the ownership of the data, it really is the only explanation I can come up with - feedback though about the subject is appreciated.
It wasn't developed when I started to use it. If it was available, I'd have considered it strongly. Now, it would take me more time to learn than just using my own system.
 
Last edited:
Others reported that their reserve percentage changed when they were upgraded to 1.10.2; This also happened to me. I had the reserve at 25% and it was knocked down to 21% if my memory serves correctly. I adjusted it back to 25% and it's remained there.

I decided to write some software this evening to scrape data from the Gateway's API and stuff it into InfluxDB, and before I even got started, I noticed that the API shows "SOE" is 27.45%, yet the phone app shows 24%. The Gateway itself shows 27%. Anyone else seeing this?

It's as if they decided to start reserving some of the PW2 capacity.
Yes, I noticed that a few weeks ago. I didn't have time to investigate.
After testing for a few days, I can confirm that 33.50% is consistently the point at which my Powerwalls stop discharging when the reserve is set to 30%.
I noticed something similar. As many of you, I moved the cutoff point after Tesla's change. Right now I have it set to 34% (in the app), and last night it stopped at 36% (from the pack reading). The numbers I recorded are:

total_pack_energy | energy_left | battery_power | time | stamp | percentage | pversion | energy_site_id | resource_type | gateway_id
-------------------+-------------+---------------+-------------------------------+-------------------------------+----------------------+----------+----------------+---------------+---------------------------
| | | 2018-01-30 03:01:01.33659-08 | 2018-01-30 03:02:13.594034-08 | 36.85277382645803400 | 3 | | |
| | | 2018-01-30 03:01:01.904404-08 | 2018-01-30 03:02:13.597091-08 | 36.85015290519877600 | 3 | | |
28117 | 9430 | -10 | 2018-01-30 03:01:01.913572-08 | 2018-01-30 03:01:12.382437-08 | 36.85015290519877600 | 3 | 2157152 | battery | 1118431-00-E--T17F0002742

I read it from both mothership and directly from pack. The line with more data is from mothership, I believe.

In the above data, you can see that energy_left/total_pack_energy=.335, yet "percentage" is 36.8%, a difference of 3.26%. I think this suggests a different full point. I wonder which is the public facing data; which one does the app show? I'll have to check when I wake up. If I was hiding a reserve at the bottom, then publically it would show more depleted, not less. If I was hiding a buffer at the top, I would publically show more full, not less, and that seems to be what it is showing. Anybody find the 100% point recently?


Here's another datapoint. From the pack directly it tells me 52.75041780748854000%, and from the mothership it shows 14452 / 28123, which is 51.3885%. I noticed that the mothership is only updating occasionally, not frequently, so it could just be the lag showing higher data. However, the watthours calculation is lower than the % showed by the direct pack API.

I forgot to look at my phone app, which I never use unless I have to set something. It is showing 50% and the PowerWall direct shows 52.00014%, with 14129/28123 from the mothership, which calculates to 50.24%. So, the Tesla mothership watthours (delayed) is most similar to the Tesla app output. That suggests the hiding in the app is of a lower buffer, with a different 0 point. It should be easy to calculate the new 0 point.

I remember checking the mothership's concept of what full was, and it remained similar throughout its life. Here are some of the readings:

2017-08-17 03:25:37.860632-07 | 28116
2017-08-17 03:26:33.108192-07 | 28116

2017-08-20 00:03:31.225451-07 | 28117
2017-08-20 00:04:26.36844-07 | 28117
2017-08-20 00:05:21.626918-07 | 28119
2017-08-20 00:06:16.786134-07 | 28119

2017-08-20 00:35:41.405585-07 | 28110
2017-08-20 00:36:36.673334-07 | 28104

2017-08-20 18:45:00.895807-07 | 28103
2017-08-20 18:45:56.190174-07 | 28098

2017-08-22 02:15:35.386004-07 | 28123
2017-08-22 02:16:30.663724-07 | 28124

2017-08-24 08:21:47.968099-07 | 28118
2017-08-24 08:22:43.390152-07 | 28123

2018-01-31 00:19:01.684043-08 | 28123
2018-01-31 00:19:56.969238-08 | 28123

Maybe Tesla has learned to start hiding its degradation using some sort of degradation buffer. 28123Wh is very similar to 28116Wh, showing no degradation, and in fact a slight improvement. Here's the distribution I have:

count | total_pack_energy
----------+-------------------
326 | 0
17 | 28076
16 | 28081
17 | 28083
664 | 28086
33 | 28087
62 | 28089
51 | 28090
66 | 28091
68 | 28092
117 | 28093
216 | 28094
200 | 28095
311 | 28096
333 | 28097
896 | 28098
253 | 28099
468 | 28100
3000 | 28101
2013 | 28102
5891 | 28103
3119 | 28104
9889 | 28105
5128 | 28106
4356 | 28107
7568 | 28108
36352 | 28109
4982 | 28110
9876 | 28111
11783 | 28112
11795 | 28113
5452 | 28114
11599 | 28115
15327 | 28116
19794 | 28117
27975 | 28118
9086 | 28119
5301 | 28120
9826 | 28121
5333 | 28122
3184 | 28123
2410 | 28124
5552 | 28125
8590 | 28126
2961 | 28127
741 | 28128
587 | 28129
1135 | 28130
653 | 28131
337 | 28132
185 | 28133
68 | 28134
134 | 28135
84 | 28136
33 | 28137
51 | 28138
34 | 28139
17 | 28140
16628836 |
(59 rows)

The max:

pwlog=> select time from pack where total_pack_energy=28140 order by time;
time
-------------------------------
2017-12-30 05:58:11.274115-08
2017-12-30 05:59:06.491339-08
2017-12-30 06:00:01.756309-08
2017-12-30 06:00:57.037803-08
2017-12-30 06:01:52.25308-08
2017-12-30 06:02:47.524162-08
2017-12-30 06:03:42.722639-08
2017-12-30 06:04:37.948361-08
2017-12-30 06:05:33.162738-08
2017-12-30 06:06:28.381336-08
2017-12-30 06:07:23.612364-08
2017-12-30 06:08:18.854164-08
2017-12-30 06:09:14.075368-08
2017-12-30 06:10:09.334325-08
2017-12-30 06:11:04.561314-08
2017-12-30 06:11:59.760391-08
2017-12-30 06:12:54.971712-08
(17 rows)

pwlog=>

The min:

pwlog=> select time from pack where total_pack_energy=28076 order by time;
time
-------------------------------
2017-11-10 06:32:41.312161-08
2017-11-10 06:33:36.482477-08
2017-11-10 06:34:31.669688-08
2017-11-10 06:35:26.818195-08
2017-11-10 06:36:21.981751-08
2017-11-10 06:37:17.228368-08
2017-11-10 06:38:12.475164-08
2017-11-10 06:39:07.656126-08
2017-11-10 06:40:02.848216-08
2017-11-10 06:40:58.010454-08
2017-11-10 06:41:53.180975-08
2017-11-10 06:42:48.334094-08
2017-11-10 06:43:43.491538-08
2017-11-10 06:44:38.655114-08
2017-11-10 06:45:33.879906-08
2017-11-10 06:46:29.095528-08
2017-11-10 06:47:24.528452-08
(17 rows)

pwlog=>

Odd. With more data:

pwlog=> select time,energy_left,percentage from pack where total_pack_energy=28076 order by time;
time | energy_left | percentage
-------------------------------+-------------+---------------------
2017-11-10 06:32:41.312161-08 | 1248 | 4.44460272801737900
2017-11-10 06:33:36.482477-08 | 1248 | 4.44753053448705600
2017-11-10 06:34:31.669688-08 | 1248 | 4.44396966136096600
2017-11-10 06:35:26.818195-08 | 1248 | 4.50889679715302450
2017-11-10 06:36:21.981751-08 | 1248 | 4.47134211463154150
2017-11-10 06:37:17.228368-08 | 1248 | 4.44737216920666500
2017-11-10 06:38:12.475164-08 | 1248 | 4.50193957080323150
2017-11-10 06:39:07.656126-08 | 1248 | 4.47814324362807900
2017-11-10 06:40:02.848216-08 | 1248 | 4.50145897089175100
2017-11-10 06:40:58.010454-08 | 1248 | 4.47150129944106200
2017-11-10 06:41:53.180975-08 | 1248 | 4.53203372345345300
2017-11-10 06:42:48.334094-08 | 1248 | 4.43993448693299200
2017-11-10 06:43:43.491538-08 | 1248 | 4.43993448693299200
2017-11-10 06:44:38.655114-08 | 1248 | 4.43993448693299200
2017-11-10 06:45:33.879906-08 | 1248 | 4.43637399416079200
2017-11-10 06:46:29.095528-08 | 1248 | 4.43637399416079200
2017-11-10 06:47:24.528452-08 | 1248 | 4.43281350138859200
(17 rows)

pwlog=>

pwlog=> select time,energy_left,percentage from pack where total_pack_energy=28140 order by time;
time | energy_left | percentage
-------------------------------+-------------+----------------------
2017-12-30 05:58:11.274115-08 | 8751 | 34.49256809615247500
2017-12-30 05:59:06.491339-08 | 8751 | 34.49735073432666000
2017-12-30 06:00:01.756309-08 | 8751 | 34.45171849427169000
2017-12-30 06:00:57.037803-08 | 8751 | 34.50078225003555600
2017-12-30 06:01:52.25308-08 | 8751 | 34.49011520409614000
2017-12-30 06:02:47.524162-08 | 8751 | 34.47282299373933000
2017-12-30 06:03:42.722639-08 | 8751 | 34.49980440271702000
2017-12-30 06:04:37.948361-08 | 8751 | 34.46436192915066000
2017-12-30 06:05:33.162738-08 | 8751 | 34.48104147399872000
2017-12-30 06:06:28.381336-08 | 8751 | 34.43736881425877500
2017-12-30 06:07:23.612364-08 | 8751 | 34.47147531654574000
2017-12-30 06:08:18.854164-08 | 8751 | 34.49134160651424000
2017-12-30 06:09:14.075368-08 | 8751 | 34.47270140494397600
2017-12-30 06:10:09.334325-08 | 8751 | 34.46902340137990000
2017-12-30 06:11:04.561314-08 | 8751 | 34.49612403100775000
2017-12-30 06:11:59.760391-08 | 8751 | 34.47392758056485000
2017-12-30 06:12:54.971712-08 | 8751 | 34.47625822514671500
(17 rows)

pwlog=>

The low state of charge explains the odd numbers I suppose. Yes, it seems right after I look at that entire day.

I had a few weeks where I had trouble telling the PW reserve to go higher than 5%, and I was getting used to winter. I don't remember if November 10 was that period, but it seems about right. During most of winter, I have had the reserve set to around 35%, to target an average daily charge of 50% for best PW lithium battery health.
 
Last edited:
Thanks. I have found the gateway ip address so now I can check out PVOutput.
One way to do this is look at how the PowerWalls are plugged in, and then find a computer in your home that is also attached the same way, and then look at the computer's IP# (could be any device that tells its own IP: computer, smartphone, television, etc.), and then just try every IP# around that IP#. Such as if your IP# is:

10.218.149.208

Then, you can try:

http://10.218.149.209/api/meters/aggregates
http://10.218.149.207/api/meters/aggregates
http://10.218.149.210/api/meters/aggregates
http://10.218.149.206/api/meters/aggregates
...
all the way up to
http://10.218.149.255/api/meters/aggregates
and down to
http://10.218.149.0/api/meters/aggregates

(Those last two often don't work since they are reserved.)

If none of them work, you can start in to:
http://10.218.150.0/api/meters/aggregates
http://10.218.150.1/api/meters/aggregates

http://10.218.148.255/api/meters/aggregates
http://10.218.148.254/api/meters/aggregates

A simple script could perform that very fast, but it is not that bad to do manually for about 20 or 30 IP#s, and usually, that's enough to find it in a home setting.
 
  • Like
Reactions: Kren
Access to the Tesla gateway seems t have stopped - I can see IP address on local area WIFI but can no longer connect to it in the way I have been doing for 9 months collecting data vis the api. Stopped yesterday - mobile app shows PW version 1.19.0 - suspect has a firewall or some sort of security now? Are others experiencing this or is it local to my installation?
 
Due to having a bad mothership auth token and the new knowledge of the % command direct via the LAN, I had no mothership data for 4.5 months and no apparent need for it to know the % in my graphs. I decided to turn it back on so I could get the total_pack_energy and energy_left data that I didn't realize was missing. I got it working (using my TeslaFi account; the wk057 script I had stopped working).

Here's what has alarmed me: The most change ever happened in that time. (See total_pack_energy.) Does anybody have any information on this? Was there a formula change, or did my battery simply degrade that much? I have no total_pack_energy and energy_left data in the intervening time. I really wish I had the data running during that period, so I knew (a) if they changed the constants and/or formulas, and (b) what caused it. If I knew what caused the degradation, it would be good info. It could have been hot days or cold days. It could have been a week in winter when we had only 10% power and no way to charge, which is why we need more control over the PowerWall so we can charge it from grid when necessary (I can't do that). It could have been recently when we have had whole weeks when it never gets below 50%. We haven't had a high number of hot days, but there have been a few. We've had many more overcast days with almost no charging.

Screen Shot 2018-07-01 at 8.34.09 PM.png
 
Today I updated my Index of /powerflow/2017/ and Index of /powerflow/2018/, and for everything past April 29, 2018, I have PV estimate forecasts from Solcast - Solar irradiance tools for forecasting and solar GIS data for my solar array. While doing that, I cleaned up my grapher a bit, and came up with this formula to convert between the data I get from
Code:
https://${pwGateWayLANhost}/api/system_status/soe
(which seems closer to raw) and what I get from the Tesla Mothership via their API (which seems more cooked) (PostgreSQL syntax):

Code:
COALESCE(percentage, (percentage_charged*.96)+4, ((CAST(energy_left AS FLOAT)/total_pack_energy)*96)+4)

That gives a percent; if you want a fraction of 1, divide by 100.

Tesla Mothership's API data has this equality (I don't know how their floating point works) (the below also in PostgreSQL syntax):
Code:
percentage_charged = ((CAST(energy_left AS FLOAT)/total_pack_energy)

Tesla Mothership's API data lags the PowerWall; it is only updated every so often (the period is currently about every 15 minutes on the quarter hour). However, the PowerWall buffers this data to send to the Tesla MoterShip for their app, and I have no access to that other than via the app with screenshots; if I want the data, I have to collect it myself real time, as before.

Here's a sample output:
24.png

As you can see, the forecast (yellow) closely matches what I get in my solar array (green). The only two things they don't exactly are the exact pattern of local clouds as they pass by (but they are even very good at that), and the local ground-based shade, and I could use the data I already have to do some fancy four dimensional math and calculate that on my own if I wanted to. Their data has the direction of the sun and everything. I haven't checked their data; they might already do those four dimensional calculations using three dimensional map data (such as for mountain shading of big utility based solar systems). This is really great stuff.

I could see a grid operator having the solar providers use this data to give accurate forecasts, and then a redundant network put in place so that the complex system doesn't have that many failures. This could increase the grid certainty a huge amount. With stuff like this, it would be easy to see solar as almost as deterministic as rotational generation, and with a few batteries, then it's game over for the old "but it's variable" excuse; scrubbing their boilers will eventually become more variable than drone dusters on solar fields.

There are some errors above with clouds that refract light into the solar panels more than direct sunlight would ever shine on them; the forecaster thinks I'm being impeded, but they don't know that it has the exact refraction of increased solar (over what direct sunlight would give). I guess there are more things to smooth out after all.
 
Last edited:
  • Informative
Reactions: Kren and NuShrike