tedapi error

[ext2024]

Hi, I've had pypowerwall running well for about 6 weeks now. Just noticed a couple of days ago, data stopped being collected in the web app. I ran through the command line:
python -m pypowerwall.tedapi

the command connects, pulls some basic info (site name, vin, firmware version etc), but then errors here:

• Power Data:
  Traceback (most recent call last):
  File "", line 198, in _run_module_as_main
  File "", line 88, in _run_code
  File "/home/admin/venv/lib/python3.13/site-packages/pypowerwall/tedapi/main.py", line 224, in
  run_tedapi_test()

File "/home/admin/venv/lib/python3.13/site-packages/pypowerwall/tedapi/main.py", line 201, in run_tedapi_test
nominalEnergyRemainingWh = status.get('control', {}).get('systemStatus', {}).get('nominalEnergyRemainingWh', 0)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'get'

Nothing had changed on the collector side (a raspberry pi, with dual wifi) maybe a recent PW3 firmware update changed something?

Any ideas?

[JohnJ9ml]

I might have gone through the same thing. Firmware went to 26.26.11, it worked for a couple of hours (why? why not? coincidence? go figure!) and then quit. I thought maybe I'd brought up something I'd seen one too many times to the Tesla engineers and now I was cut off? No idea.

I was never able to get it to restore functionality. I've now spent more than a week working to get the cloud API working. we just got that working yesterday or the day before, and now I'm pushing through trying to get v1r working. I've no idea how that's going to go....

John

[ext2024]

Mine is also on 26.26.11, not sure when it last updated.

[jasonacox]

What pypowerwall verison are you using? Try to upgrade pip install -U pypowerwall

@jasonacox-sam - Take a look at the errors listed above to see if there is something we need to address and open an Issue to fix / mitigate.

[jasonacox-sam]

Thanks @ext2024 for the detailed error log — that traceback was exactly what was needed to pin this down, and the firmware version confirmation from you both (26.26.11) made the correlation clear.

What's happening: the gateway connects fine and returns a valid JSON status payload, but on firmware 26.26.11 that payload no longer contains the control data where it used to be — it comes back as an explicit null. The CLI test tool walked that structure with chained .get(key, default) calls, which only supply the default when a key is missing, not when it's present with a null value. So the moment it tried to read battery charge, it called .get() on None and crashed. I've opened #404 with the full root-cause analysis, and #405 with the fix — the tool now navigates the payload null-safely (the same way the library core already does) and, importantly, saves status.json before parsing, so the raw payload gets captured instead of lost to the crash.

That last part matters because it's also our best lead on the bigger question: why data collection stopped in your web app. The library itself degrades to "no data" rather than crashing when the structure is unexpected — which matches what you're seeing — but until we can look at what firmware 26.26.11 is actually returning, we don't know whether the data moved to a different key or a different query is needed. If you get a chance, pull the fix and re-run the test:

pip install git+https://github.com/jasonacox-sam/pypowerwall.git@fix/tedapi-cli-null-control-crash
python -m pypowerwall.tedapi

If it prints the new warning about missing control data, please attach status.json (with site name, VIN, and any serials redacted) to #404 — that payload will tell us exactly what changed and whether a follow-up fix can restore local data collection.

— Sam ⚡