TEDAPI Bearer Authentication Mode

[kentsimon50]

Hi Jason and @Nexarian and @jasonacox-sam

I have a gateway2, powerwall 2 and stand alone tesla inverter. I have hardwire lan to the gateway/powerwall2 (192.168.10.12) and the inverter (192.168.3.135). I also have wifi connection to gateway/powerwall2 at (192.168.91.1). I have v26.26.4 on both my powerwall and inverter. (Don't worry, I have the different subnets connected together)

I am running pypowerwall-server connected to the wifi 192.168.91.1 to get data with vitals. I’m running from the same machine @Nexarian’s docker to connect to my inverter at 192.168.3.135 and get my strings(vitals) from my inverter. This is running 2 Powerwall-Dashboard stacks feeding 1 influxdb.

I am trying to do this with pypowerwall 17.3. I can now connect to the inverter 192.168.3.135 using “bearer” and get vitals!

My problems are

1. I can’t connect to the powerwall2 with pypowerwall v0.17.3 with “bearer” thru the lan and get vitals.
2. I can’t connect to the tesla inverter with pypowerwall-server v0.6.4 with “bearer” thru the lan and get vitals.

I don't know what I'm doing wrong or if it is possible. I've tried many different ways with and without PW_PASSWORD and PW_GW_PWD

My dream is to have pypowerwall-server with data from my powerwall2 and string data from my inverter. I can’t tell if this is available now or going to be in the future.

I”d like to get rid of my travel router at 192.168.91.1 since the wifi goes down every now and then.

[Nexarian]

@jasonacox-sam, Kent is referencing my branch here: https://github.com/Nexarian/pypowerwall/tree/re-work-proxy-next which contains an prototype version of the proxy that does multiple gateways and has an additional prototype of the bearer mode integrated. It's the baseline for a lot of the work I've merged in thus far.

@kentsimon50 -- I haven't yet sat down and integrated the pypowerwall-server with my newer PyPowerwall changes (just need to find the time), but there's one load-bearing question in what you wrote: Does my prototype docker image I sent you months ago NOT work with LAN/bearer on the Powerwall 2? My understanding was this does for both Powerwall 2 and the inverters, has that changed?

Are you specifying the V2026_06 API version? I could never get bearer auth to work without it.

[jasonacox-sam]

Thanks for linking the branch here, Nexarian — re-work-proxy-next as the baseline for the multi-gateway + bearer work is exactly the context this thread needed. And Kent, that stats/config dump was the key — it's what made it possible to pin down what's happening. There's a concrete answer to the load-bearing question, and a likely root cause for the Powerwall 2 side.

Yes — bearer is supposed to work on Powerwall 2 over the wired LAN. That's straight from the current library (pypowerwall 0.17.x) TEDAPI docs: bearer logs in via /api/login/Basic and works over the wired LAN IP (basic auth only answers on the gateway's Wi-Fi), and it explicitly supports "Powerwall 2 and solar-only gateways, but NOT Powerwall 3" (wired PW3 = v1r). The V2026_06 instinct is also right — bearer pairs with the Tesla-signed GraphQL query set introduced in V2026_06, and the library warns when it's combined with the older V2024_06 queries since gateways may reject them. So to close the loop on the prototype question: if that image didn't work with LAN/bearer on the PW2 back then, the V2026_06 requirement you called out — or a password present selecting hybrid/basic — is the likely culprit, not a PW2 limitation.

**Why the PW2 stats read tedapi_mode "off" / V2024_06 / basic":** those aren't a bearer→basic fallback — they're the proxy's default /statsvalues, shown when TEDAPI never engaged at all. The config dump shows bothPW_PASSWORDandPW_GW_PWDset. In the library's mode selection, bearer is only honored in **full TEDAPI mode**, which requiresPW_PASSWORDblank +PW_GW_PWD` set. With a password present, the library takes the hybrid/local path — and the hybrid client's embedded TEDAPI always speaks basic, which only answers on the gateway Wi-Fi, never the wired IP. So the requested bearer/V2026_06 settings were never actually applied against the wired gateway.

The likely fix for the PW2 stack: mirror the shape that already works for the inverter — clear PW_PASSWORD entirely, keep PW_GW_PWD, keep PW_TEDAPI_AUTH_MODE=bearer + PW_TEDAPI_API_VERSION=V2026_06, with PW_HOST on the gateway's wired LAN IP. It should come up as tedapi_mode: "full", auth=bearer in /stats — hardwired vitals, no travel router.

The server side (problem #2) is a real gap, not config: pypowerwall-server v0.6.4 pins pypowerwall==0.17.1 (bearer-capable since v0.17.0) but never exposes PW_TEDAPI_AUTH_MODE / PW_TEDAPI_API_VERSION — it builds the client without passing auth_mode, so its TEDAPI always speaks basic no matter what env vars are set. Since the pinned library already supports both knobs, wiring them through the server config (global + per-gateway) is a thin change, and re-work-proxy-next is a natural reference for it. Happy to prototype that pass-through so one server stack can serve both the PW2 vitals and the inverter strings. One trap to flag either way: setting PW_PASSWORD alongside PW_GW_PWD in the server also selects hybrid/basic, so the same blank-password rule will apply there.

— Sam 🔌

[kentsimon50]

@Nexarian I was never able to get your prototype to work with LAN/bearer on the Powerwall 2. I did not try your newer Docker v0.12.6 to see if it would connect to my powerwall 2. Is it different? I am specifying the V2026_06 API version for pypowerwal v0.17.3. I don't remember about before. This is what I get for the powerwall 2 stats

tedapi_mode | "off"
tedapi_api_version | "V2024_06"
tedapi_auth_mode | "basic"

config
PW_BIND_ADDRESS | ""
PW_PASSWORD | "*****"
PW_EMAIL | "kentsimon50@gmail.com"
PW_HOST | "192.168.10.12"
PW_TIMEZONE | "America/Los_Angeles"
PW_DEBUG | false
PW_CACHE_EXPIRE | 5
PW_BROWSER_CACHE | 0
PW_TIMEOUT | 5
PW_POOL_MAXSIZE | 15
PW_HTTPS | "no"
PW_PORT | 8675
PW_STYLE | "clear.js"
PW_SITEID | null
PW_AUTH_PATH | ".auth"
PW_AUTH_MODE | "cookie"
PW_CACHE_FILE | ".auth/.powerwall"
PW_CONTROL_SECRET | null
PW_GW_PWD | "**********"
PW_RSA_KEY_PATH | null
PW_WIFI_HOST | null
PW_TEDAPI_API_VERSION | "V2026_06"
PW_TEDAPI_AUTH_MODE | "bearer"
PW_NEG_SOLAR | true
PW_SITE_ZERO_THRESHOLD | 0
PW_SUPPRESS_NETWORK_ERRORS | false
PW_NETWORK_ERROR_RATE_LIMIT | 5
PW_FAIL_FAST | false
PW_GRACEFUL_DEGRADATION | true
PW_HEALTH_CHECK | true
PW_CACHE_TTL | 30
PW_TEDAPI_RECOVERY | true
PW_TEDAPI_PROBE_INTERVAL | 30
PW_FIRMWARE_CHECK_INTERVAL | 300

[kentsimon50]

@jasonacox-sam This is one run with no password. I can see that it tries TEDAPI
See errors below
Pypowerwall.env

PW_EMAIL=kentsimonxx@xxxxxxxx
#PW_PASSWORD=xxxxx
PW_HOST=192.168.10.12
PW_GW_PWD=xxxxxxxxxx
PW_TEDAPI_API_VERSION="V2026_06"
PW_TEDAPI_AUTH_MODE="bearer"
PW_DEBUG=yes

09/09/2026 08:46:15 PM [proxy] [INFO] pyPowerwall [0.17.3] Proxy Server [t101] - HTTP Port 8675 - DEBUG
09/09/2026 08:46:15 PM [pypowerwall] [DEBUG] pypowerwall [0.17.3]

09/09/2026 08:46:15 PM [proxy] [INFO] pyPowerwall Proxy Started
09/09/2026 08:46:15 PM [proxy] [INFO] NOTICE: This proxy is in maintenance mode - new features are being built in pypowerwall-server (https://github.com/jasonacox/pypowerwall-server). See proxy/README.md for details.
09/09/2026 08:46:15 PM [proxy] [INFO] Network error rate limiting: 5 errors/minute per function
09/09/2026 08:46:15 PM [proxy] [INFO] Graceful degradation enabled (PW_GRACEFUL_DEGRADATION=yes) - cached data TTL: 30s
09/09/2026 08:46:15 PM [proxy] [INFO] Connection health monitoring enabled (PW_HEALTH_CHECK=yes)
09/09/2026 08:46:15 PM [proxy] [INFO] Added trailing / to API Base URL: /pypowerwall/
09/09/2026 08:46:15 PM [pypowerwall] [DEBUG] Auto selecting local mode
09/09/2026 08:46:15 PM [pypowerwall] [DEBUG] password = [empty], gw_pwd = [set], rsa_key_path = [empty]
09/09/2026 08:46:15 PM [pypowerwall] [DEBUG] TEDAPI ** full **
09/09/2026 08:46:15 PM [pypowerwall.tedapi] [DEBUG] TEDAPI initialized with auth_mode=bearer, pwcacheexpire=5s, pwconfigexpire=5s, v1r=False
09/09/2026 08:46:15 PM [pypowerwall.tedapi] [DEBUG] Testing Connection to Powerwall Gateway: 192.168.10.12
09/09/2026 08:46:15 PM [pypowerwall.tedapi] [DEBUG] Bearer login to https://192.168.10.12/api/login/Basic
09/09/2026 08:46:19 PM [pypowerwall.tedapi] [ERROR] Unable to connect to Powerwall Gateway 192.168.10.12
09/09/2026 08:46:19 PM [pypowerwall.tedapi] [ERROR] Please verify the gateway password and that the host is reachable.
09/09/2026 08:46:19 PM [pypowerwall.tedapi] [ERROR] Error Details: 401 Client Error: Unauthorized for url: https://192.168.10.12/api/login/Basic
09/09/2026 08:46:19 PM [pypowerwall.tedapi] [ERROR] Failed to connect to Powerwall Gateway

[jasonacox-sam]

Thanks for running the no-password pass and posting the full startup log, Kent — that's exactly the report that makes this diagnosable. The good news: the config fix landed. The remaining failure is one specific thing — the gateway rejecting the installer login at /api/login/Basic — and a 401 means the gateway answered, so the wired path to it is working fine. This is purely credentials, not routing.

The log confirms every piece of the earlier advice engaged: password = [empty], gw_pwd = [set] → TEDAPI ** full ** → auth_mode=bearer initialized against the wired IP. So the mode-selection issue from the /stats dump is gone, and the failure mode changed with it.

What bearer actually sends there: in 0.17.3 the bearer flow's first move is POST /api/login/Basic with username="installer" and PW_GW_PWD (the full QR password). Two things follow:

• The Wi-Fi stack working doesn't vouch for this login. Basic mode (your working stack on the gateway Wi-Fi) never touches /api/login/Basic — it authenticates as HTTP Basic user Tesla_Energy_Device against the /tedapi/* endpoints. Same password, different account, different path. "Works over Wi-Fi" and "installer login says 401" can both be true.
• Your inverter connecting is why it works there — its gateway honors installer + QR password at that endpoint. Your Gateway 2 is rejecting the same shape, which is interesting: bearer was hardware-verified on a PW2 over both a Wi-Fi static route and the hardwired LAN when the mode landed, so yours is the first GW2 counterexample — worth pinning down exactly.

Two checks to isolate it:

1. Confirm this stack carries the Gateway 2's own QR password. With multiple stacks against multiple gateways, it's an easy mix-up — the working Wi-Fi stack's PW_GW_PWD for the PW2 is the reference value; make sure this env file has that identical value (watch for stray quotes or whitespace, or a stale copy the container was started with).
2. Probe which account your GW2 actually accepts, from the wired network against your own gateway:

# installer + full QR password (what bearer mode sends)
curl -sk -o /dev/null -w '%{http_code}\n' -X POST https://<GW_IP>/api/login/Basic \
  -H 'Content-Type: application/json' \
  -d '{"username":"installer","password":"<FULL_GW_PWD>","email":"x@example.com","force_sm_off":false}'

# customer + last 5 chars of the QR password (the platform derives the customer
# password from the gateway password's last 5 chars — the same pair v1r mode logs in with)
curl -sk -o /dev/null -w '%{http_code}\n' -X POST https://<GW_IP>/api/login/Basic \
  -H 'Content-Type: application/json' \
  -d '{"username":"customer","password":"<LAST_5_OF_GW_PWD>","email":"x@example.com","force_sm_off":false}'

(-o /dev/null on purpose — the response body contains the auth token, no reason to print it.)

How to read the results: if installer+full returns 200 from curl but pypowerwall got 401, the env value differs from what you curl'd with — sync it and you're done. If installer returns 401 but customer+last-5 returns 200, your GW2 only honors the customer account at that endpoint — and since that login also yields a Bearer token, teaching the library's bearer login to use that pair would be a small, contained change (the bearer prototype is Nexarian's, and this thread is the right place to settle it). If both come back 401, the gateway is gating /api/login/Basic itself on your firmware — a gateway-side behavior that would be good to know about either way.

Once the login lands, the two-gateway plan is still on track — the server-side bearer pass-through noted upthread remains the other open piece.

— Sam 🔌

[Nexarian]

I was never able to get your prototype to work with LAN/bearer on the Powerwall 2

Then we have a miscommunication/misunderstanding. I thought you had. If it NEVER worked, then it likely never will and this is relegated to solar-inverters only.

For PW2, then, you might need to explore the RSA token/v1r path... That's how to get LAN access back for the Powerwall 3

@jasonacox-sam I suspect we may need to update the docs. The source of "It works for PW2 and Inverter" was me, based on conversations I had with Kent months ago, but I probably only heard what I wanted to hear.

[kentsimon50]

I would love to make this work. Can you give me the whole code to login with curl? I do https://192.168.10.12/api/login/Basic and get

code	401
error	"bad credentials"
message	"Login Error"

I don't get a place to put installer + the QR password

[erikgieseler]

I tested this against my Powerwall 2 with Gateway 2 over LAN, with no static route configured.

Firmware: 26.26.4 68c2bc82

Both login attempts return HTTP 401:

curl -sk -o /dev/null -w '%{http_code}\n' -X POST https://192.168.180.2/api/login/Basic -H 'Content-Type: application/json' -d '{"username":"installer","password":"LAST5","email":"x@example.com","force_sm_off":false}'
'401
''000
'

curl -sk -o /dev/null -w '%{http_code}\n' -X POST https://192.168.180.2/api/login/Basic -H 'Content-Type: application/json' -d '{"username":"customer","password":"LAST5","email":"x@example.com","force_sm_off":false}'
'401
''000
'

I am currently using TEDAPI via WiFi with pypowerwall-server and an ESP32 Wi-Fi Bridge.

[jasonacox]

Soften the pypowerwall TEDAPI docs wording now rather than deleting the claim — attribute it to what's actually verified: solar-only gateway (Kent's inverter, confirmed today) and the original hardware verification runs. I'll flag the proposed wording change to @jasonacox before touching the library docs, since that repo's docs are his call.

@jasonacox-sam Please submit a PR to update the TEDAPI docs and remove the claim and clearly mark the details apply to solar-only gateways.

[Nexarian]

@erikgieseler Thanks Eric. @jasonacox I went through my email correspondence with Kent, he never actually said it worked with the Powerwall 2, I read what I wanted to read.

The good news, I think is that the RSA key approach that others have spent so much time on with the Powerwall 3 may ALSO work with the Powerwall 2 as Kent DID confirm he can do the Tesla offline registration: https://www.tesla.com/support/energy/powerwall/own/connecting-network

[erikgieseler]

I was able to successfully generate both tedapi_rsa_private.pem and tedapi_rsa_public.der with my Powerwall 2 / Gateway 2.

However, it is not clear to me from the documentation how I can actually test the RSA/v1r approach with my Powerwall 2.

I’m happy to test it on my PW2 and provide the results. If someone can point me to the exact steps, API endpoint, configuration, or command I should use, I’ll give it a try. 😉

[Nexarian]

Part of the problem here: I don't have a Powerwall. The net metering policies where I live (Pennsylvania) are such that a Powerwall doesn't make sense economically speaking.

[kentsimon50]

@Nexarian It was probably my misscomunication. I was hoping someone else had a powerwall 2 to test besides me and it was working.

The weird thing is that at the 192.168.91.1 end point I always have to give the password and GW_PWD. It will only connect in TEDAPI hybrid mode.

I know you are inverter only. I wish I could. My utility charges $ 0.08 /kwh and gives me $ 0.013 /kwh and $10 /kw demand at peak demand.

[Nexarian]

@erikgieseler @kentsimon50 Try this: https://github.com/jasonacox/pypowerwall/tree/main/tools/tedapi-lan

There's an older discussion on this as well: jasonacox/pypowerwall#165 (comment)

It converged on: Use the "v1r" route for Powerwalls, as nobody but Matthew seemed to be able to get the DIRECT RSA key approach working (though with AI assistance you might be more lucky nowadays)

[kentsimon50]

@Nexarian I got it. I took out the quotes. It's working on my inverter!!!

[kentsimon50]

@Nexarian I can't get the your container to mount any volumes. I copied my rsa key into the container into /data. No matter what I do I can't connect to Powerwall 2 TEDAPI v1r.

2026-09-15 18:11:06,256 - pypowerwall.tedapi.tedapi_v1r - ERROR - v1r login failed (401): {"code":401,"error":"bad credentials","message":"Login Error"}
2026-09-15 18:11:06,257 - pypowerwall.tedapi - ERROR - v1r: Login failed
2026-09-15 18:11:06,258 - pypowerwall.tedapi - ERROR - Failed to connect to Powerwall Gateway
2026-09-15 18:11:10,954 - pypowerwall.tedapi.tedapi_v1r - ERROR - v1r login failed (401): {"code":401,"error":"bad credentials","message":"Login Error"}
2026-09-15 18:11:10,955 - pypowerwall.tedapi - ERROR - v1r: Login failed

[Nexarian]

If the inverter is working and the PW2 isn't, and the PW2 works using the test APIs, then it's just a matter of figuring out the right plumbing and mounting the files. I'll have time to look into this later this week.

[Matthew1471]

@jasonacox-sam Do I have this right? There was some original optimism that the tedapi/v1 approach could work with the RSA key directly, but nobody but Matthew had ever seen that work, and so the community converged on /v1r with a dedicated subnet for hardwired LAN access for the Powerwall series.

Am I missing anything?

Also: Please provide @erikgieseler and @kentsimon50 instructions on what they should do.

I thought other people had been able to repeat what I'd done (I'd provided code) just I believe it never worked specifically on the Tesla Solar Inverter which is a specific product that isn't a PowerWall?

[erikgieseler]

I got my PW2 working via TEDAPI v1r, see #105 (comment)

[kentsimon50]

@Nexarian I have gotten your feat: per-gateway TEDAPI auth mode and API version to Work. I have both my Powerwall 2 and inverter running on it. Powerwall is TEDAPI v1r and inverter is bearer both on LAN.

I have 1 problems.

The solar is doubled because it's getting it from both gateways.

This is a large step forward.
Thanks

[erikgieseler]

Got it working with v0.6.6 of pypowerwall-server on Powerwall 2 / Gateway 2 (26.26.4) via TEDAPI v1r over LAN:

services:
  pypowerwall-server:
    image: jasonacox/pypowerwall-server:latest
    container_name: pypowerwall-server
    hostname: pypowerwall-server
    ports:
      - 8676:8675
    volumes:
      - ./pypowerwall-server:/data
      - /etc/localtime:/etc/localtime:ro
    environment:
      - PW_PORT=8675
      - PW_HOST=192.168.180.2
      - PW_GW_PWD=***
      - PW_RSA_KEY_PATH=/data/tedapi_rsa_private.pem
      - PW_WIFI_HOST=192.168.180.32
      - PW_EMAIL=***
      - PW_AUTH_PATH=/data
      - PW_CONTROL_SECRET=***
      - PW_CACHE_EXPIRE=4
      - PW_BIND_ADDRESS=0.0.0.0
      - PW_TIMEZONE=Europe/Berlin
      - MQTT_HOST=mosquitto
      - MQTT_PORT=1883
      - MQTT_USERNAME=admin
      - MQTT_PASSWORD=***
      - MQTT_TOPIC_PREFIX=pypowerwall
      - MQTT_RETAIN=false
      - MQTT_QOS=0
      - MQTT_HA_DISCOVERY=true
      - MQTT_HA_PREFIX=homeassistant
      - MQTT_CLIENT_ID=pypowerwall-server
      - TZ=Europe/Berlin
    networks:
      - default
      - mosquitto_default
    restart: always

networks:
  default:
  mosquitto_default:
    external: true

[Nexarian]

@jasonacox-sam We need to do a thorough scrub of the documentation in pypowerwall, pypowerwall-server, and Powerwall Dashboard

In some cases they're still saying that hardwired LAN access isn't available at all referencing last year's 25.10 update, and some now say mis-mashed hybrid things. But the state of truth as I see it now:

• Wifi always works: 192.168.91.1 directly, static routes, or even v1r/bearer mode. Your pick!
• Hardwired LAN: No static routes. RSA/v1r for Powerwalls (2 & 3 at least, does anyone still have a Powerwall 1?), bearer for vanilla inverters,
• I'm genuinely not sure what the status of gateways that don't have inverters/batteries attached are. Either we say that plainly or we get some who have them to investigate.

I have two PRs out right now to aid with the bearer/inverter space:

• For those who have multiple inverters, improve deadlock condition
• Pipe through TEDAPI version and TEDAPI auth mode

[jasonacox-sam]

Agreed — the docs have drifted behind the actual connectivity state, and your summary matches what kentsimon50 and erikgieseler have now demonstrated in this thread (v1r for PW2/PW3 on hardwired LAN, bearer for inverters, wifi always available). I'll take a documentation scrub pass across pypowerwall, pypowerwall-server, and Powerwall-Dashboard to align them with that state of truth, referencing this discussion and #109 as the anchors. Will coordinate with Jason before pushing doc changes.

On your open question — gateways with no batteries/inverters attached — agreed the honest move is to state plainly that it's untested until someone with that hardware investigates.

— Sam 🔌

[jasonacox]

@jasonacox-sam Create doc revision issues for those projects to make sure we don't forget this.

[jasonacox-sam]

Done — doc-revision issues created so this stays tracked:

• pypowerwall#387 — TEDAPI docs scrub: merge #380 (bearer = solar-inverter only), retire the "no hardwired LAN since 25.10" wording, drop the mandatory static-route/vendor-subnet requirement for v1r, add the clock note, mark no-battery/no-inverter gateways untested.
• pypowerwall-server#116 — document PW_TEDAPI_AUTH_MODE / PW_TEDAPI_API_VERSION / PW_RSA_KEY_PATH (global + per-gateway once feat: per-gateway TEDAPI auth mode and API version (bearer / V2026_06) #109 lands), plus working example configs for PW2-via-v1r and inverter-via-bearer.
• Powerwall-Dashboard#864 — update setup guidance so the wired v1r/bearer paths appear alongside the gateway Wi-Fi option.

Each issue carries the same state-of-truth summary from this thread so the wording is consistent across projects when the scrub happens.

— Sam 🔌

[kentsimon50]

Hi @jasonacox and @Nexarian and @jasonacox-sam

I am running your new pypowerwall-server v.0.7.1 on my production system. I have firmware v.26.26.4. I am connected with TEDAPI v1r on my Powerwall2. I am very excited to see that you say I can see my fan but it's not there! I look at vitals and pod no fans. Am I doing something wrong?

[jasonacox-sam]

Hi Kent — nothing wrong on your end, and thanks for running v0.7.1 in production.

Quick context on how the fan data works: it comes from the TEDAPI client (get_fan_speeds()), not from the local /vitals API — so v1r mode is exactly the right transport, and you're not missing a config step. The feature was verified on Powerwall 3, where each inverter reports two fans (FANn_actual / FANn_duty). On Powerwall 2 the expected shape is one fan per PVAC block, but I'll be honest: we haven't yet confirmed a PW2 gateway (26.26.4) actually returns those PVAC fan blocks over v1r — you may be the first data point.

Two quick checks would pin it down:

1. Open http://<server>:8675/fans/pw and http://<server>:8675/fans in a browser — if both come back empty ({}), the gateway isn't returning fan vitals in the v1r payload.
2. Open /vitals (or http://<server>:8675/api/system/vitals) and search the JSON for Fan — if the raw vitals have PVAC_Fan_Speed_Actual_RPM entries but /fans is empty, that's a parsing gap on our side and I'll fix it.

If you can paste what those return (redact anything sensitive), I'll take it from there. — Sam 🔌

[kentsimon50]

{"VITALS":{"text":"Device vitals generated from Tesla Powerwall Gateway TEDAPI","timestamp":1790626690.114477,"gateway":"192.168.10.12","pyPowerwall":"0.18.2"},"NEURIO--VAH5105AB1298":{"NEURIO_CT0_InstRealPower":336.95379638671875,"NEURIO_CT0_InstReactivePower":-0.2230532318353653,"NEURIO_CT0_InstVoltage":124.68425750732422,"NEURIO_CT0_InstCurrent":2.9637386798858643,"NEURIO_CT0_Location":null,"NEURIO_CT1_InstRealPower":0,"NEURIO_CT1_InstReactivePower":-0.06347816437482834,"NEURIO_CT1_InstVoltage":124.5162353515625,"NEURIO_CT1_InstCurrent":0.011543350294232368,"NEURIO_CT1_Location":null,"NEURIO_CT2_InstRealPower":0,"NEURIO_CT2_InstReactivePower":-0.03180123493075371,"NEURIO_CT2_InstVoltage":124.49083709716797,"NEURIO_CT2_InstCurrent":0.01324507687240839,"NEURIO_CT2_Location":null,"NEURIO_CT3_InstRealPower":0.03177317976951599,"NEURIO_CT3_InstReactivePower":-0.06354635953903198,"NEURIO_CT3_InstVoltage":124.68425750732422,"NEURIO_CT3_InstCurrent":0.013550585135817528,"NEURIO_CT3_Location":null,"componentParentDin":"1232100-00-H--xx","firmwareVersion":null,"lastCommunicationTime":"2026-09-28T14:18:05-06:00","manufacturer":null,"meterAttributes":{"meterLocation":[]},"serialNumber":"VAH5105AB1298"},"STSTSM--1232100-00-H--xx":{"STSTSM-Location":"Gateway","alerts":["SelfConsumptionReservedLimit","SystemConnectedToGrid","FWUpdateSucceeded","GridCodesWrite","PodCommissionTime"],"firmwareVersion":null,"lastCommunicationTime":null,"manufacturer":"TESLA","partNumber":"1232100-00-H","serialNumber":"xx","teslaEnergyEcuAttributes":{"ecuType":207}},"TEPINV--3012170-10-C--TG1220010005WH":{"PINV_EnergyCharged":null,"PINV_EnergyDischarged":null,"PINV_Fout":59.967,"PINV_GridState":"Grid_Compliant","PINV_HardwareEnableLine":null,"PINV_PllFrequency":null,"PINV_PllLocked":null,"PINV_Pnom":5800,"PINV_Pout":-0.24,"PINV_PowerLimiter":null,"PINV_Qout":null,"PINV_ReadyForGridForming":null,"PINV_State":"PINV_GridFollowing","PINV_VSplit1":123.9,"PINV_VSplit2":123.80000000000001,"PINV_Vout":247.70000000000002,"alerts":["PINV_a067_overvoltageNeutralChassis"],"componentParentDin":"TETHC--3012170-10-C--TG1220010005WH","firmwareVersion":null,"lastCommunicationTime":null,"manufacturer":"TESLA","partNumber":"3012170-10-C","serialNumber":"TG1220010005WH","teslaEnergyEcuAttributes":{"ecuType":253}},"TEPOD--3012170-10-C--TG1220010005WH":{"POD_ActiveHeating":null,"POD_CCVhold":null,"POD_ChargeComplete":null,"POD_ChargeRequest":null,"POD_DischargeComplete":null,"POD_PermanentlyFaulted":null,"POD_PersistentlyFaulted":null,"POD_available_charge_power":null,"POD_available_dischg_power":null,"POD_enable_line":null,"POD_nom_energy_remaining":7123,"POD_nom_energy_to_be_charged":6563,"POD_nom_full_pack_energy":13686,"POD_state":null,"alerts":[],"componentParentDin":"TETHC--3012170-10-C--TG1220010005WH","firmwareVersion":null,"lastCommunicationTime":null,"manufacturer":"TESLA","partNumber":"3012170-10-C","serialNumber":"TG1220010005WH","teslaEnergyEcuAttributes":{"ecuType":226}},"TESLA--None":{"componentParentDin":"STSTSM--1232100-00-H--xx","lastCommunicationTime":null,"manufacturer":"TESLA","meterAttributes":{"meterLocation":[1]},"serialNumber":null},"TESYNC--1493315-01-G--JBL22294YBG0QY":{"ISLAND_FreqL1_Load":59.97,"ISLAND_FreqL1_Main":59.95,"ISLAND_FreqL2_Load":59.97,"ISLAND_FreqL2_Main":59.96,"ISLAND_FreqL3_Load":0,"ISLAND_FreqL3_Main":0,"ISLAND_GridConnected":"ISLAND_GridConnected_Connected","ISLAND_GridState":"ISLAND_GridState_Grid_Compliant","ISLAND_L1L2PhaseDelta":null,"ISLAND_L1L3PhaseDelta":null,"ISLAND_L1MicrogridOk":null,"ISLAND_L2L3PhaseDelta":null,"ISLAND_L2MicrogridOk":null,"ISLAND_L3MicrogridOk":null,"ISLAND_PhaseL1_Main_Load":null,"ISLAND_PhaseL2_Main_Load":null,"ISLAND_PhaseL3_Main_Load":null,"ISLAND_ReadyForSynchronization":null,"ISLAND_VL1N_Load":125,"ISLAND_VL1N_Main":125,"ISLAND_VL2N_Load":125,"ISLAND_VL2N_Main":125,"ISLAND_VL3N_Load":0,"ISLAND_VL3N_Main":0,"METER_X_CTA_I":1.9055,"METER_X_CTA_InstReactivePower":-56,"METER_X_CTA_InstRealPower":-74,"METER_X_CTB_I":1.9455,"METER_X_CTB_InstReactivePower":-86,"METER_X_CTB_InstRealPower":65,"METER_X_CTC_I":0,"METER_X_CTC_InstReactivePower":0,"METER_X_CTC_InstRealPower":0,"METER_X_LifetimeEnergyExport":null,"METER_X_LifetimeEnergyImport":null,"METER_X_VL1N":123.89,"METER_X_VL2N":123.82000000000001,"METER_X_VL3N":0,"METER_Y_CTA_I":0,"METER_Y_CTA_InstReactivePower":0,"METER_Y_CTA_InstRealPower":0,"METER_Y_CTB_I":0,"METER_Y_CTB_InstReactivePower":0,"METER_Y_CTB_InstRealPower":0,"METER_Y_CTC_I":3.08,"METER_Y_CTC_InstReactivePower":2,"METER_Y_CTC_InstRealPower":367,"METER_Y_LifetimeEnergyExport":null,"METER_Y_LifetimeEnergyImport":null,"METER_Y_VL1N":123.91,"METER_Y_VL2N":123.83,"METER_Y_VL3N":0,"SYNC_ExternallyPowered":null,"SYNC_SiteSwitchEnabled":null,"alerts":[],"componentParentDin":"STSTSM--1232100-00-H--xx","firmwareVersion":null,"manufacturer":"TESLA","partNumber":"1493315-01-G","serialNumber":"JBL22294YBG0QY","teslaEnergyEcuAttributes":{"ecuType":259}},"TETHC--3012170-10-C--TG1220010005WH":{"THC_AmbientTemp":24.400000000000006,"THC_State":null,"alerts":[],"componentParentDin":"STSTSM--1232100-00-H--xx","firmwareVersion":null,"lastCommunicationTime":null,"manufacturer":"TESLA","partNumber":"3012170-10-C","serialNumber":"TG1220010005WH","teslaEnergyEcuAttributes":{"ecuType":224}}}