Noticed the Tesla Energy Gateway and app are consistently different by 2-3%. Anyone know why this would be? System has been only been online for a week.
-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
Tesla app and gateway showing different PW SOC%
- Thread starter destructure00
- Start date
woferry
Member
It's more complicated than that. At 100% both sources agree. But at 0% in the app the Gateway's reported value is roughly 5%. The offset between the two scales linearly across that range, though the rounding is also different, the app rounds down while the Gateway rounds 'normally' (0.5% => 1%). As a result the difference can even be 6% at times. There's another graph that floats around the forum that shows this, I drew my own as I preferred to visualize it differently.
So it looks like you were around 36.4% as reported by the Gateway's REST API to get that combination of readings.
So it looks like you were around 36.4% as reported by the Gateway's REST API to get that combination of readings.
It appears the app is programmed to provide a 5% buffer.
This was likely done to avoid completely discharging the PowerWalls.
Though the software should have handled this situation better. The TEG browser interface should provide the same reading.
And if they wanted to have a 5% reserve, they should show that in the readings on both the app and browser interface so it's clear to the customer what's going on...
This was likely done to avoid completely discharging the PowerWalls.
Though the software should have handled this situation better. The TEG browser interface should provide the same reading.
And if they wanted to have a 5% reserve, they should show that in the readings on both the app and browser interface so it's clear to the customer what's going on...
I agree with you. I suspect that tesla underestimated / underestimates how often someone would look at the local interface via the app. Its even possible that the team working on the app and showing that information and the team that worked on the firmware / powerwall have little interaction with each other.
Its fairly obvious from a customer point of view that these numbers should match / be displaying the same data, but I suspect that at the beginning, the team that works on the app was focused on "easy to use information" and the team that was focused on programming the firmware / web interface for the powerwall just displaying what the powerwall actually sees "accurate information". There wouldnt be any reason for the firmware team working on the powerwall itself to display anything other than what the powerwall sees.
The team building the app likely made a conscious decision to build in a buffer, since the expectation is the customer is going to mess with the settings in the app, to protect the customer from making a mistake / protect the product from the customer.
Thus, we end up with this very strange situation where 2 bits of data that are supposed to be reporting the same thing, report something different.
I certainly wasnt there, this is just my guess as to how something ends up this way. Many of you work in IT as well, so I bet the above thought processes look familar to you.
Innocent decisions trying to make a system easier to use / protect the customer from making a mistake end up with a system that, looking from the outside, makes zero sense (supposedly same data being different on the same system in two different places).
Not an excuse, just guessing at a reason.
I guess that this discrepancy doesn't bother me too much, though I admit I haven't dug too deeply into exactly how Tesla positions the app and the gateway web interface as far as customer use. I feel like the app is intended more for customers, and so the battery scaling should better represent what the customer should worry about, while the gateway page is more for support and savvy users, so a different number is not the worst thing. It wouldn't hurt to add to the gateway some note about it being the "unadjusted" or "raw" charge level. If nothing else, I certainly wouldn't want the API to provide the adjusted numbers.
That said, my main issues are first, that on neither scale is 0% power shutoff - it appears to be 10% on the gateway and 5% on the app - with no instruction/warning, even on the app, that at 5% you will lose power, as @bob_p was saying. Even if this is stated elsewhere in documentation, I feel it is important enough to be a warning directly on the app when the PW is low - change color, have a "low fuel warning" similar to in a car - or something to draw attention to the status. (They could even attempt an "x minutes remaining to outage" countdown, based on current usage and any solar coming in.) Second is trying to reconcile all the numbers with the promised 14 kWh / 13.5 kWh usable capacity for the battery. The many numbers tend to make this all very difficult to assess.
The other problem is the one @BrettS seemed to identify in the new car charging functionality - it looks like they used the raw numbers from the API and forgot to adjust them as the app does. The result is that when you tell it to stop at 40%, it doesn't actually stop until 37% on the app. If they are going to adjust customer-facing numbers to hide an extra buffer, they need to be consistent in doing so.
That said, my main issues are first, that on neither scale is 0% power shutoff - it appears to be 10% on the gateway and 5% on the app - with no instruction/warning, even on the app, that at 5% you will lose power, as @bob_p was saying. Even if this is stated elsewhere in documentation, I feel it is important enough to be a warning directly on the app when the PW is low - change color, have a "low fuel warning" similar to in a car - or something to draw attention to the status. (They could even attempt an "x minutes remaining to outage" countdown, based on current usage and any solar coming in.) Second is trying to reconcile all the numbers with the promised 14 kWh / 13.5 kWh usable capacity for the battery. The many numbers tend to make this all very difficult to assess.
The other problem is the one @BrettS seemed to identify in the new car charging functionality - it looks like they used the raw numbers from the API and forgot to adjust them as the app does. The result is that when you tell it to stop at 40%, it doesn't actually stop until 37% on the app. If they are going to adjust customer-facing numbers to hide an extra buffer, they need to be consistent in doing so.
