Gateway Website PowerWall Reading off by 4%

[bob_p]

Compared to the PowerWall reading with our Tesla app, the Gateway's local website is consistently about 4% higher.

The Tesla app appears to be correct - with the reading around the value set for our reserve power.

Is anyone else seeing this?

Is there any fix to get the two readings to match?

 

[bmah]

Compared to the PowerWall reading with our Tesla app, the Gateway's local website is consistently about 4% higher.

The Tesla app appears to be correct - with the reading around the value set for our reserve power.

Is anyone else seeing this?

Is there any fix to get the two readings to match?

Yes there's a difference of a few percentage points between the local Web UI and the app. API calls seem to match the number in the local Web UI (and therefore also differ from the app), which is how I stumbled on this issue.

Some people have said that the difference is not constant, but it's a sliding scale. I personally have not looked into that aspect.

Bruce.

 

[JayClark]

On my system the gateway html interface usually shows between 4-2% higher than the app. It seems to be closer to 4% higher when my 4 PWs SOC are down around 20-30%, but as the SOC gets closer to 80% (which in the winter I usually don't go above) the difference seems to be as little as 2% at times. So possibly the difference reduces as the SOC gets higher, but that's just what I think I've noticed based on casual observations.

 

[JohnRatsey]

My recollection is that in mid-2018 Tesla realised that it wasn't good for the battery to deliver power down to 0% charge so they changed the operation to stop discharge when the true SoC (as reported by the gateway) reaches 5%. This was disguised by using a fudge factor in the app so that while 100% is the same on both sources of info, 0% on the app means 5% in the battery, and pro rata in between (ie 4% different at 24% SoC, 3% at 43% SoC, 2% at 62% and 1% difference at 81% SoC). This gives the battery a slightly easier life during normal operation (full discharge is bad for the chemistry) plus keeping some reserve in the battery means that it can run for some hours (days?) on standby if there's a power outage before the battery is completely drained. The downside is that there's about 0.65kWh less usabe capacity.

 

[bob_p]

The app and gateway web page should be reporting the same charge level.

It's confusing for customers to see different readings.

The app reading seems to be correct, since the solar power is diverted to charging the PowerWalls until the reserve power level is reached - as shown in the app. The web page is showing a value 4% higher at the point when the PowerWalls have reached the specified reserve power level and solar power is shifted to providing house power.

 

[JayClark]

The app and gateway web page should be reporting the same charge level.

It's confusing for customers to see different readings.

The app reading seems to be correct, since the solar power is diverted to charging the PowerWalls until the reserve power level is reached - as shown in the app. The web page is showing a value 4% higher at the point when the PowerWalls have reached the specified reserve power level and solar power is shifted to providing house power.

Agreed, in regard to these should read consistently. But what I've observed on my system seems to be different than your observations in regard to the reserve setting.

One thing I've observed after for many weeks of watching and not changing my settings, when I'm in TBC-Balanced mode, with a reserve set to say %50 via the app, the app was showing that the reserve was generally only showing the PWs charged to about 47% and then the balanced mode would start to discharge when needed anytime the PWs got above 47%. That was what drove me to check the % via the local HTML web server, where it shows being maintained at 50%. In my case, at least in this scenario, with my system it seems to use the HTML % at the threshold for TBC-Balanced & Reserve settings - but it's all a little bit like messing with voodoo and rain-dancing in terms of understanding how to set things and what the actual results will be, and the differing information in Tesla's own apps.

 

[aesculus]

The app reading seems to be correct, since the solar power is diverted to charging the PowerWalls until the reserve power level is reached - as shown in the app. The web page is showing a value 4% higher at the point when the PowerWalls have reached the specified reserve power level and solar power is shifted to providing house power.

Mine seem to show the 4% difference no matter what state the PW's are in.

 

[JohnRatsey]

I've just checked mine and the app says 68% (rounded to nearest whole number) while the API call says 69.5%.

I don't have a backup gateway - perhaps having the backup capability triggers different calculation in the app from what I'm seeing.

 

[cwied]

Note that the app does the adjustment both when setting the reserve and when displaying the charge level. When I last looked, setting the reserve through the API results in a slightly different value being displayed in the app (unless it's 100%, that is).

I actually believe I read somewhere that 0% in the API is not really 0% charge in the battery already. I suspect Tesla decided they needed a higher reserve value and decided to implement it in the app since that's easier and less risky than changing the Gateway firmware.

 

[BJReplay]

App 0% = GW 5%
App 100% = GW 100%

It is linear between those two points.

App never shows less than 0%, but GW will show lower values, if the powerwall is discharging when it reaches "App" 0%, it may run for a few minutes before shutting down. Usually it will then recharge from the grid (at least here in AUS) until it reaches App 0% / GW 5%.

 

[power.saver]

 

[JayClark]

App 0% = GW 5%
App 100% = GW 100%

It is linear between those two points.

App never shows less than 0%, but GW will show lower values, if the powerwall is discharging when it reaches "App" 0%, it may run for a few minutes before shutting down. Usually it will then recharge from the grid (at least here in AUS) until it reaches App 0% / GW 5%.

That matches what I’ve seen, I just haven’t been to zero, and didn’t think to look the last time it was at 100%.

 

[bob_p]

Since the power readings for house, solar, PowerWall and grid are all in KW, it would be very useful if Tesla displayed both the % of PowerWall charge AND the estimated KWh.

Longer term, if the PowerWalls start losing charge capacity, providing the estimated KWh of charge would be more useful - plus as Tesla gets more less sophisticated customers with PowerWalls, this should be as easy to use and understand as possible...

 

[jjrandorin]

Thanks for this thread, and information in it. I just got installed yesterday and logged into my PW on the local wireless just to look. My install was finished around 4pm yesterday, so not much sun left to charge my 2 freshly installed PWs. App shows 12% PW available, local interface of PW shows 17%. I remembered this thread, so re read it again.

Figured I would say first, thanks, as having information like this from other owners lets me know that there is nothing "wrong", and tesla would likely have told me "its fine, we dont report a problem" had I called in for support on it. Saves them a call, and me a bit of worry, so thanks all!

Since no one reported a delta of 5%, and mine shows 12% vs 17% on firmware 1.43.3 at these states of charge, I figured I would report out in this thread that in my case I see this amount of difference at this state of charge, in case someone else comes across this thread and wonders if anyone else has seen that.

 

[JayClark]

Since no one reported a delta of 5%, and mine shows 12% vs 17% on firmware 1.43.3 at these states of charge, I figured I would report out in this thread that in my case I see this amount of difference at this state of charge, in case someone else comes across this thread and wonders if anyone else has seen that.

Good information. It looks like on the low end SOC some are reporting as much to 5%. BJReplay seemed to show a GW reporting 5% delta when SOC is at lowest end with App showing 0%. Would be interesting to know when yours charges to 100% what the delta shows.

App 0% = GW 5%
App 100% = GW 100%

It is linear between those two points.

App never shows less than 0%, but GW will show lower values, if the powerwall is discharging when it reaches "App" 0%, it may run for a few minutes before shutting down. Usually it will then recharge from the grid (at least here in AUS) until it reaches App 0% / GW 5%.

 

[woferry]

Interesting that people seem to think this isn't cut & dried. My PW pretty much goes from 100% to <20% every day, and it's very clear to me that it's exactly as power.saver's graph depicts, nothing more to it than that (same thing that BJReplay said). Having worked on projects containing Lithium batteries I know that the same sort of 'fudging' of SoC percentages is very common (though I was more used to it at the high-end, where 95% SoC may be reported as 100%). I will note that the app and webpage seem to apply different rounding rules, so it sometimes appears to be off by 1% (i.e. more than the graph might suggest) due to the rounding differences. But comparing the raw API soe value to either rounded value makes it pretty straightforward in my experience, the webpage matches the soe value with rounding, and the app has the linear offset.

So I've recently been running with a 0% reserve, and when the REST API drops below 5.000% the app reports 0 and the PW goes to standby. Right now the soe reports 15.8703359784%, the webpage says 16% and the app says 11% (and flipping the equation in power.saver's graph computes to 11.44242105%, so rounding to 11% makes sense). While typing this the soe climbed to 17.3560695593%, the webpage now says 17% and the app says 13% (13.00631579%). But I believe the app reported 12% all the way up until the moment 13.0% was crossed, so the app may not round while the webpage rounds more normally (i.e. 17.5 => 18).

It seems to me one reason they might have added this offset, in the rare cases this winter where the PW hasn't been able to power the house overnight and hits my 0% reserve, the soe has dropped from 5% close to 0% (sub 1%) as the PW 'revs up' for morning charging. So without this buffer the battery presumably would have gone below their defined 0% soe. While my PW is returning to 5% soe on the API all of the solar goes straight to the PW, and the house continues to draw from the grid, once 5% is reached (i.e. the 0% app reserve) it does the normal (for the Self-powered mode I run in) PW gets what the house doesn't need from solar behavior.

 

[power.saver]

So I've recently been running with a 0% reserve

You like to live on the edge... if there is a power outage at night you may not make it until morning.

Are you doing this because of the season and lower solar production?

 

[woferry]

Yeah, not that concerned about outages during fair weather, would rather stay off the grid (it got down to 11% soe this morning, so any reserve above 5% would have meant the PW going to standby). With the next two days forecasting rain I'll probably bump the reserve up to 20% just to have some buffer should the power go out, even though it will put me on the grid a bit in the morning. In the summer I could easily run with a 20%+ reserve, mainly due to the reduced hours of darkness. But if I can run from when the sun goes down to when it comes back up without needing the grid, then a reserve doesn't really matter anyway, even in an outage (this does ignore the fact that there may not be enough sun on a rainy day to fully recharge, which is the only reason why I'd consider raising the reserve).

I am definitely interested in finding a way to automate the reserve setting based on a forecast of solar exposure in the upcoming day or two, I have a lead on that but want to get a bit farther along before saying anything more. If I can get it working I'll let others know how I did it.

 

[aesculus]

I am definitely interested in finding a way to automate the reserve setting based on a forecast of solar exposure in the upcoming day or two, I have a lead on that but want to get a bit farther along before saying anything more. If I can get it working I'll let others know how I did it

Looking forward to what you come up with. For those still on EVA I also wonder if you will fold in the value of returning some energy back to PG&E during afternoon peak? In my case I will probably only generate enough power during spring and fall to offset my consumption with my setup so I cannot completely go energy neutral, but might be able to go cost neutral or close to it if I can export during the afternoon peak period.

 

[JohnRatsey]

Since no one reported a delta of 5%, and mine shows 12% vs 17% on firmware 1.43.3 at these states of charge, I figured I would report out in this thread that in my case I see this amount of difference at this state of charge, in case someone else comes across this thread and wonders if anyone else has seen that.

The battery charge on the gateway home web page is rounded to the nearest whole number as is the charge shown by the App. Hence 17% on the Gateway web page might be anything between 16.5% and 17.5%. You can see a more accurate value by making an API call to http://x.x.x.x/api/system_status/soe. By my calculation (which may be wrong) using the factor given above, 16.6% reported by the gateway (rounded up to 17%) is 12.47% (rounded down to 12%) in the App.