Accuracy in cloud mode

[KateWilkins]

Problem
I’m forced to use the cloud mode as I’ve no way to use TEDAPI via WIFI (wired connection, I couldn’t make it work) and I’m noticing that there is a significant difference between the weekly solar figure from the dashboard vs the tesla app itself. It’s the UK so not great generation at this time of year sadly.

Is this a known issue? Is there anything I can do about it?

Last 24 hours
Dashboard - 1.1kWh
Tesla App. - 1.3kWh

To Reproduce
N/A

Screenshots
If applicable, add screenshots to help explain your problem.

System Details

• Powerwall Installation: PW3+GW2+Single 5 panel string on MPPT1
• Powerwall Firmware Version - 25.41.1
• Host System Hardware and OS - Linux, Ubuntu, Docker

Additional context
Powerwall Dashboard Installation: Cloud

[jasonacox]

I noticed you have this set on the dashboard:

I suggest changing the range to "Yesterday" instead of "Last 24 hours".

[KateWilkins]

Hi Jason,
Thanks for taking the time to respond. The solar generation period is pretty short and the last 24 covered the previous day, just in case I’ve taken another screenshot (attached), there is still a significant difference.

[jasonacox]

Hi @KateWilkins — thanks for reporting this and including your numbers. A few thoughts/questions below to help narrow down what might be going on in cloud mode. Being off 10% seems high, but the values are so low that it may not be an good example, for a few reasons.

Possible causes / things to check

• As noted in the README, when using cloud mode the data fidelity is lower than with local/TEDAPI mode; the sampling interval and what’s included may make the solar number drift vs what the Tesla app reports. 
• Cloud-mode may miss short solar spikes (e.g. when clouds pass or variable generation). These could be counted by the Tesla backend but lost in lower-frequency sampling.
• There may also be time-alignment (sample rate and sample time) that cause the approximation curve to be materially different, or gaps in data collection (e.g. if the host machine or container was down for some time), which could affect the weekly total.

Suggestions

Could you check a longer time window (month or multi-week) to see if the discrepancy remains proportional or grows (i.e. 1.3 → 1.1 is ~15% drop; does that scale over longer periods)?

Run the tesla-history tool to have it fill in any gaps that may have occured when the dashboard was being restarted or had connectivity issues. https://github.com/jasonacox/Powerwall-Dashboard/tree/main/tools/tesla-history

Expectations

By using the TEDAPI endpoint, I'm sampling at a much higher rate than Tesla and often see differences over 10% when measured in short timelines, but over a week, it is usually less than 1%.

[KateWilkins]

Hi Jason,

I've used the tool cover the period from 2025-01-01 to 2025-12-06:

----------------------------------------
(Powerwall-Dashboard) kate@epona:~/Powerwall-Dashboard$ python3 tools/tesla-history/tesla-history.py --start 2025-11-01 --end 2025-12-06
----------------------------------------
Tesla account: kate@t......r.dev
----------------------------------------
      Site ID: xxxxxxxxxxxxxxxxxxx
    Site type: Powerwall x1
    Site name: My Home
     Timezone: Europe/London
    Installed: 2025-07-09 17:19:51+01:00
  System time: 2025-12-06 21:00:21+00:00
----------------------------------------
Running for period: [2025-11-01 00:00:00+00:00] - [2025-12-06 00:00:00+00:00] (35 days, 0:00:00s)

Searching InfluxDB for data gaps (power usage)
* Found data gap: [2025-11-01 00:00:00+00:00] - [2025-11-26 16:41:00+00:00] (25 days, 16:41:00s)
* Found data gap: [2025-11-26 16:48:00+00:00] - [2025-11-26 17:10:00+00:00] (0:22:00s)

Searching InfluxDB for data gaps (grid status)
* Found data gap: [2025-11-01 00:00:00+00:00] - [2025-11-26 16:41:00+00:00] (25 days, 16:41:00s)
* Found data gap: [2025-11-26 16:48:00+00:00] - [2025-11-26 17:10:00+00:00] (0:22:00s)

Retrieving data for gap: [2025-11-01 00:00:00+00:00] - [2025-11-26 16:40:59+00:00] (25 days, 16:40:59s)
* Loading daily history: [2025-11-01] (Europe/London)
* Loading daily history: [2025-11-02] (Europe/London)
* Loading daily history: [2025-11-03] (Europe/London)
* Loading daily history: [2025-11-04] (Europe/London)
* Loading daily history: [2025-11-05] (Europe/London)
* Loading daily history: [2025-11-06] (Europe/London)
* Loading daily history: [2025-11-07] (Europe/London)
* Loading daily history: [2025-11-08] (Europe/London)
* Loading daily history: [2025-11-09] (Europe/London)
* Loading daily history: [2025-11-10] (Europe/London)
* Loading daily history: [2025-11-11] (Europe/London)
* Loading daily history: [2025-11-12] (Europe/London)
* Loading daily history: [2025-11-13] (Europe/London)
* Loading daily history: [2025-11-14] (Europe/London)
* Loading daily history: [2025-11-15] (Europe/London)
* Loading daily history: [2025-11-16] (Europe/London)
* Loading daily history: [2025-11-17] (Europe/London)
* Loading daily history: [2025-11-18] (Europe/London)
* Loading daily history: [2025-11-19] (Europe/London)
* Loading daily history: [2025-11-20] (Europe/London)
* Loading daily history: [2025-11-21] (Europe/London)
* Loading daily history: [2025-11-22] (Europe/London)
* Loading daily history: [2025-11-23] (Europe/London)
* Loading daily history: [2025-11-24] (Europe/London)
* Loading daily history: [2025-11-25] (Europe/London)
* Loading daily history: [2025-11-26] (Europe/London)
Retrieving data for gap: [2025-11-26 16:49:00+00:00] - [2025-11-26 17:09:59+00:00] (0:20:59s)

Retrieving backup event history
* Creating grid status data: [2025-11-01 00:00:00+00:00] - [2025-11-26 16:40:59+00:00] (25 days, 16:40:59s)
* Creating grid status data: [2025-11-26 16:49:00+00:00] - [2025-11-26 17:09:59+00:00] (0:20:59s)

Writing to InfluxDB
Updating InfluxDB
Done.

I've only been up and running with Solar since 2025-11-26, installed the dash the day after so not a huge history. Even after running the history script the last 30 days on the dash shows 8.9kWh vs 11.2kWh in the app, its not the same divergence by day. Given both Dashboard and Tesla app are using Tesla Cloud base data the discrepancy is odd, I could understand the sampling rate issue if local was with TEDAPI and app is using CLOUD, I don't know the API in detail so could be I'm naive in thinking the APP sees the same date as the dashboard?

I've put in the data by day and there is no consistent error, its mostly proportional to the amount of generation on that day, typically the more generated the lower the error but even that isn't hard/fast as there is one outlier on the day when the most solar was generated

		Dashboard		App		Difference
26/11/25	1.500		1.600	6.67%
27/11/25	0.004		0.300	7042.86%
28/11/25	1.500		1.600	6.67%
29/11/25	0.747		0.900	20.48%
30/11/25	2.000		2.200	10.00%
1/12/25		0.00011		0.200	181718.18%
2/12/25		1.100		1.300	18.18%
3/12/25		1.400		1.600	14.29%
4/12/25		0.104		0.300	189.02%
5/12/25		0.311		0.500	60.82%
6/12/25		0.239		0.500	109.47%
			
Total		8.905		11.000	
			
By Day		8.900		11.200	25.84%

[jasonacox]

Thanks for all the data.

I agree with you, it is odd, but I have to say, I'm a bit shocked at how low your solar production is. It is very low. I have to believe that is some of the issue here. Since the Dashboard is basically just gather samples and computing the area under the curve (integrals), when your kW values are so low, even a minor deviation or offset of the samples could materially change the area. Are you really only producing 1kWh per day? My lowest day with full cloud cover is 13kWh, but I'm in Los Angels instead of London, so probably not a fair comparison. 😊

Is the home usage data closer? I see you are at ~6kWh/day. That may be a more realistic test. I have used that to compare my Dashboard data with my utility company. It is extremely close (1% or less) even when the Tesla App reported something different. I figured that was likely due to sampling directly (local TEDAPI access) at a much higher frequency. But as you noted, you are using cloud and so we shoudl be seeing the same data they use.

I know many others in the community have compared their data, but again, they have much higher production numbers so not a fair comparison.

[BuongiornoTexas]

The UK has a reputation for short cloudy days in mid-winter!

@KateWilkins You might also be able to do a comparison solar export values as measure by Tesla, your utility and the dashboard - I have high confidence in my utility and lower confidence in either tesla number (no disrespect @jasonacox - it's about confidence in the raw data from the tesla unit), so I use the utility for cross validation.

[jasonacox]

Thanks for the help @BuongiornoTexas - and tend to agree. ;-)

@KateWilkins - Please forgive the curiosity, but do you know why your Powerwall charge state disappears for part of the day?

[KateWilkins]

@BuongiornoTexas is right, it’s grey, damp and grim here in the UK this time of year, sun angle is very low and only about 8 hours of daylight. Whilst I’m a big supporter of renewables then solar here is just not so viable with land cost and house density, it means payback periods are a bit silly. The installer who did my powerwall wanted £8.6k for 10 panel roof installation, my house alignment means it only gets full sun from around 0700 to 1300 and as you can see above sun is in short supply, payback period was 12+ years. So in the end I bought 5 x 425W panels and fence mounted them myself, they get sun from around 11:00 to 15:00 in winter, total cost of my homemade install about £450. I wish it was better but we have to make the best of what we have. It was a fun project.

@jasonacox The dropout on the charge state is odd, nothing showing like that on the app graphs. 🤷‍♀️

On the very very low days (300Wh or less) then could be, certainly aligns with the lower error when charge is higher but at >1.5kWh I would have thought it would be closer, the 2.2kWh day is still 10% out. I’m going to have a play with tha API and script something to pull the data from the cloud and hand calculate..