Powerwall 2 over LAN v1r (Gateway 1): per-pack lifetime energy, heatsink temperature and fault flags via msaSignals

[jcl-bit]

Thanks for the v1r work and for PR #390. The note there that the signal-name variables are not covered by the signature turned out to apply to the device controller query on Powerwall 2 as well, and it unlocks data that pypowerwall currently returns as null on PW2. Sharing what I found in case it is useful, and happy to test anything.

Setup

• 4 x Powerwall 2 on a Backup Gateway 1 (part 1118431), firmware 26.34.0, wired LAN
• pypowerwall 0.18.2 with an owner-registered RSA key (pairing below)
• No customer password: /api/login/Basic returns 401 for the documented Gateway 1 default (last five of the serial, tested on an earlier firmware) and for the full serial, and Tesla support declined to release the customer password. TEDAPI v1r PW2 Mode (Gateway 1) only requires Legacy (Customer) password pypowerwall-server#143 and PW2 v1r TEDAPI - working in python with legacy password and serial number password, documentation requires update? #393 here describe Gateway 1 setups that used a Tesla One legacy password for v1r. On this one, once the key was VERIFIED, signed reads worked with no password at all
• Reads only. Nothing in this post writes to the gateway

Pairing on a PW2 system

This is a one-time step per gateway, and it was the part a PW2 owner is most likely to get stuck on:

1. Generate a dedicated RSA key and sign in to the Tesla account through pypowerwall's login (owner account, browser login window).
2. Submit the public key with pypowerwall's registration flow. It returned state 1, PENDING_VERIFICATION, and stayed there on repeated checks.
3. Physical proof at the site. The registration prompt describes the PW3 procedure. On this system, what completed it was turning the external On/Off switch on one of the Powerwall 2 units off for about 15 seconds and back on. The key is registered to the gateway (it signs against the gateway's DIN), but the proof was that battery switch. The gateway's reset button was not involved.
4. The next status check returned state 3, VERIFIED, and signed reads worked from then on, on ports 443 and 4445, without the customer password.

Two small things seen on Windows during the login step, happy to file them separately if useful: the native login printed the tokens to the console even with debug off, and the token dictionary it returned was empty, so the exchange result had to be captured directly before saving the auth cache.

What works

The V2024_06 device_controller_full query takes msaComp and msaSignals as variables. Replacing or extending them works the same way EXTRA_SIGNAL_NAMES does for the PW3 components query:

import dataclasses, json
from pypowerwall.tedapi.queries import QueryRole, get_query

q = get_query(QueryRole.DEVICE_CONTROLLER_FULL)
v = json.loads(q.b_value)
v["msaComp"] = {"types": ["PVS", "PVAC", "TESYNC", "TEPINV", "TETHC", "STSTSM", "TEMSA", "TEPOD"]}
v["msaSignals"] += ["PINV_EnergyCharged", "PINV_EnergyDischarged", "PINV_HeatsinkTemp",
                    "POD_PermanentlyFaulted", "POD_PersistentlyFaulted"]
q = dataclasses.replace(q, b_value=json.dumps(v, separators=(",", ":")))

Signals that came back live through msaSignals and are not already in the stock query:

• TEPINV, per battery module: PINV_EnergyCharged, PINV_EnergyDischarged, PINV_LifetimeEnergyCharged, PINV_LifetimeEnergyDischarged, PINV_HeatsinkTemp, PINV_Qout, PINV_PllFrequency, PINV_PllLocked, PINV_ReadyForGridForming, PINV_HardwareEnableLine
• TEPOD, per battery module, only once TEPOD is added to msaComp: POD_PermanentlyFaulted, POD_PersistentlyFaulted, POD_ActiveHeating, POD_CCVhold, POD_ChargeComplete, POD_ChargeRequest, POD_DischargeComplete, POD_enable_line, POD_available_charge_power, POD_available_dischg_power, POD_nom_energy_to_be_charged
• TETHC, per Powerwall: THC_State
• TESYNC, gateway: ISLAND_L1L2PhaseDelta, ISLAND_L1L3PhaseDelta, ISLAND_L2L3PhaseDelta, ISLAND_L1MicrogridOk, ISLAND_L2MicrogridOk, ISLAND_L3MicrogridOk, ISLAND_ReadyForSynchronization, ISLAND_PhaseL1_Main_Load, ISLAND_PhaseL2_Main_Load, SYNC_ExternallyPowered, SYNC_SiteSwitchEnabled

The same path also returns values the stock query already provides (THC_AmbientTemp from the stock msaSignals; PINV_Pout, PINV_Vout, PINV_Fout, PINV_VSplit1, PINV_VSplit2, PINV_State, PINV_GridState, PINV_Pnom, the two POD nominal energy values and the ISLAND_* voltages and frequencies from the stock esCan section), and they agree.

Requested through msaSignals but echoed back null on this system: PINV_PowerLimiter and POD_state (battery side), and ISLAND_GridState, METER_X_* and METER_Y_* including their LifetimeEnergyImport / LifetimeEnergyExport (gateway side; ISLAND_GridState does come through the stock esCan section). Of the stock msaSignals, the METER_Z_* CT and voltage names, MSA_* and PVAC_Fan_Speed_* also come back null here, and METER_Z_LifetimeEnergyImport / Export are not echoed at all, so this gateway does not recognise them. The site's solar is on a SolarEdge inverter, so the Tesla PVAC and PVS slots are MIA anyway.

Two things to watch for

• An unrecognised component type in msaComp makes the gateway return null for the entire query, not just drop that type. Tested one at a time on top of the stock list: adding TEPOD is accepted (10 more components), while adding any one of TESLA, TEBMS, TEGW, TEISLAND or TEMETER nulls the whole response. So a single bad guess in the type list silently blanks every other value, and new types are worth adding one at a time.
• TEPINV and TEPOD share one serial per module, so their signals join exactly. TETHC carries the Powerwall's package serial (the same one embedded in control.batteryBlocks[].din) and only pairs to its module by component order in components.msa. Six empty slots per family come back with no serial and no live signals.

Evidence the counters are real

• Units: the four PINV_EnergyDischarged values summed to 31.5285 MWh, against 31.4896 MWh of cumulative battery discharge from the Fleet API calendar history read the same morning, 0.12 % apart. So the counters are Wh, and they measure per-pack lifetime discharge, the quantity the per-pack warranty throughput cap is expressed in.
• Liveness: over 74 minutes of 30-second polling while the battery charged, the four PINV_EnergyCharged counters rose 3,782 Wh in total (948, 940, 948 and 946 Wh). Integrating the gateway's own battery meter power over the same span gives 3,786.6 Wh of charging, 0.1 % apart. The discharged counters stayed flat, and the battery did not discharge in that window.
• Temperatures are live: over the first two hours PINV_HeatsinkTemp ranged from about 40 to 56 °C, swinging 15 °C within an hour, while THC_AmbientTemp sat at 31 to 34 °C. The heatsink did not simply follow charge power, though: it read about 41 °C during a 6.7 kW charge and fell to 40 °C as charging rose from about 2.5 to 4.8 kW, so I would treat it as a temperature, not a load proxy. Given the constant PCH_heatsinkTemp you found on PW3, I checked this one moves before relying on it.
• A full read with these signals takes 0.2 to 0.4 s on port 443 (port 4445 serves the same endpoint at about 1.3 s). Polling every 30 s since mid-morning has produced no 429s so far, though that is only hours, not weeks.

Networking status works on a Gateway 1 too

common.getNetworkingStatusRequest (V2026_06 energy_device protobuf, DELIVERY_CHANNEL_LOCAL_HTTPS, sender.local = LOCAL_PARTICIPANT_INSTALLER, sent through post_v1r) answers on this Backup Gateway 1 with per-interface connectedPhysical, connectedInternet, connectedTesla, signal strength and activeRoute for eth and wifi (gsm comes back empty on this unit). These are the gateway's own network links, so the gateway generation is what matters here, not the batteries; the only public capture I found was from a PW3 with a Gateway 2. It is a useful local answer to "the app has gone blank: is the gateway down, or only its path to Tesla?" getSystemInfoRequest works the same way.

Question

Would you be interested in a PR that adds a device controller role to EXTRA_SIGNAL_NAMES for PW2 (append only, starting with PINV_EnergyCharged, PINV_EnergyDischarged, PINV_HeatsinkTemp and the two POD_*Faulted flags), and fills the TEPINV values that are currently null in the TEDAPI-sourced vitals? If so, let me know what liveness evidence you would want per signal and I will gather it. TEPOD in msaComp could be a separate, opt-in step given the null-response behaviour above.

[jasonacox]

Thanks, this is excellent work, and the evidence is exactly the kind I want: the per-pack counters agree with the battery meter and with Fleet API history, and you checked the heatsink temperature actually moves before relying on it. Yes, please send a PR. You have the hardware, and I'll validate on our side with our two Powerwall 3s.

A few things that will make it straightforward to merge:

1. Signals only, through EXTRA_SIGNAL_NAMES. Add a QueryRole.DEVICE_CONTROLLER_FULL: {"msaSignals": (...)} entry, the same pattern as the PW3 temperatures in feat(tedapi): restore Powerwall 3 temperatures #390. The capture JSON stays untouched; names are only appended.
2. Fill the existing placeholders. PW2 TEDAPI vitals already have PINV_EnergyCharged, PINV_EnergyDischarged, PINV_PllFrequency, PINV_Qout, THC_State, SYNC_* and so on, hard-coded to None. They mirror the original local /api/devices/vitals, which reported real values there (see docs/vitals-example.json, Wh units, matching yours). New names like PINV_HeatsinkTemp and PINV_LifetimeEnergy* can go on the same blocks as new keys. Pass through whatever the gateway sends, None included. Please don't change temps(), the /temps shape, or existing keys.
3. Matching TEPINV/TEPOD to our blocks is the part I'll look at hardest. Our blocks are named by package serial (from esCan.bus.THC), while the msa TEPINV/TEPOD components use the module serial. Please make that mapping explicit, skip the serial-less empty slots (we hit a phantom-device bug from those on PW3 in fix(tedapi): read PVAC fan speeds from esCan PVAC_Logging (V2026_06) #406), and leave the value as None rather than guess when the mapping is ambiguous.
4. TEPOD in msaComp: separate PR, later. One unrecognized type nulling the whole query could blank vitals for every user on a gateway or firmware that doesn't know TEPOD, and we can't test Gateway 2 or older firmware broadly. When we get there it needs to be opt-in, or fall back to the stock list when the extended query returns null.
5. Fixtures: a redacted raw device-controller response with the extended signals (serials replaced) for the unit tests. Please also confirm whether the msa component order matches the battery order and stays stable across a gateway restart.

On my side: the Powerwall 3 gets this same device-controller query, so before merging I'll confirm on our two PW3s that the extra names come back null or are dropped and that nothing else in the response changes.

Two of your side notes: the login printing tokens is a real bug, tracked in #415. Your Powerwall 2 pairing step (switching one unit's On/Off switch off for 15 seconds) would be very welcome as a short addition to the README's v1r section, in this PR or a docs one. The networking-status idea is interesting too. Let's take it up after this lands.

[jcl-bit]

Thanks Jason, that is a clear set of guardrails and I am happy to work within all of them. The PR will add signal names only, through EXTRA_SIGNAL_NAMES. It will fill the existing placeholders, add the new names as new keys, and leave temps(), the /temps shape and the existing keys alone. TEPOD in msaComp can wait for its own opt-in PR. Agreed, blanking vitals for anyone on an unknown gateway or firmware is not worth the risk.

On your ordering question, I measured it on my four PW2 units (Backup Gateway 1, firmware 26.34.0) rather than guess. Each msa component has only partNumber, serialNumber, activeAlerts and signals. There is no type or parent field, and the package and module serials share nothing, so there is no explicit key. The link is order: each TETHC (package serial) is followed directly by its TEPINV (module serial). The TETHC order matches esCan.bus.THC and control.batteryBlocks exactly. As an independent check, each module's voltages best match the esCan.bus.PINV entry at the same index, which is the slot vitals already pairs with esCan.bus.THC.

On stability, the order and pairing were identical in six full reads across 46 hours, with different signal lists. They also never changed in 532 reads from my own collector over 45 hours. All of that is within a single boot, though. The gateway has not restarted since before I started collecting, so I cannot honestly say yet that it survives a restart. I will capture it on either side of the next restart and post the result here before the PR leaves draft.

For the mapping itself, I plan to skip components by empty serialNumber rather than by "has no live signals". Two serial-less MSA components here return a live ISLAND_GridConnected, so a liveness filter would let phantoms through. A TETHC pairs with the next serial-bearing TEPINV only if its serial is in esCan.bus.THC. Any irregularity leaves every msa-sourced PINV value as None. THC_State and SYNC_* join directly on serial, so they do not depend on order at all.

On scope, with the stock msaComp my gateway returns 10 of the placeholders live: PINV_EnergyCharged, PINV_EnergyDischarged, PINV_HardwareEnableLine, PINV_PllFrequency, PINV_PllLocked, PINV_Qout, PINV_ReadyForGridForming, THC_State, SYNC_ExternallyPowered and SYNC_SiteSwitchEnabled. PINV_PowerLimiter comes back null and will pass through as None. The POD_* names need TEPOD, so they wait for that PR. I have no Tesla solar inverter, so I cannot test the PVAC and PVS ones. One detail for the pass-through: booleans arrive in boolValue and enums in textValue, with value null, so it has to read whichever field is set.

The redacted fixture is ready, with serials replaced by PACKAGE_SERIAL_n and MODULE_SERIAL_n so the pairing stays visible. It will go in with the PR, and so will the README pairing note. Thanks also for picking up the token printing in #415.