Powerwall 3 Support #387

jesaf00 · 2023-11-18T23:38:37Z

Problem
Powerwall 3 not compatible with Powerwall-Dashboard

Enhancement
I would like to help make it work if I can

Additional context
I have 3x Powerwall 3s just installed with a tesla backup switch and would like to be able to use this tool.

jesaf00 · 2023-11-18T23:39:39Z

My primary powerwall is 192.168.200.51 and pyPowerwall does not see it as a PW. I am unable to login via web with instructions from any previous PW.

jasonacox · 2023-11-19T01:57:41Z

Hi @jesaf00 - Congrats on getting the new Powerwall!

Do you know if it is on your local network? If so, can you log in to your Powerwall web portal? Tesla has instructions (link) but I wonder if it works for your setup. The pypowerwall library uses the APIs on that web portal for Powerwall/2/+.

Can you also provide the model number / picture of the Powerwall?

jesaf00 · 2023-11-19T02:59:39Z

I can send the specific model info from the side tomorrow. But here are some pics. Sent from my iPhoneOn Nov 18, 2023, at 7:57 PM, Jason Cox ***@***.***> wrote: Hi @jesaf00 - Congrats on getting the new Powerwall! Do you know if it is on your local network? If so, can you log in to your Powerwall web portal? Tesla has instructions (link) but I wonder if it works for your setup. The pypowerwall library uses the APIs on that web portal for Powerwall/2/+. Can you also provide the model number / picture of the Powerwall? —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

jesaf00 · 2023-11-19T03:14:19Z

Sorry, forgot to mention that yes it is on my local network. 2 of 3 are showing on my WiFi but only one switched to the correct network after I changed using the app. I am unable to log into the PW using the instructions for previous PWs. I get a 404 right away or after ignoring the self signed cert. Sent from my iPhoneOn Nov 18, 2023, at 8:59 PM, Jerry Schulze ***@***.***> wrote:I can send the specific model info from the side tomorrow. But here are some pics. <image0.jpeg><image1.jpeg><image2.jpeg>Sent from my iPhoneOn Nov 18, 2023, at 7:57 PM, Jason Cox ***@***.***> wrote: Hi @jesaf00 - Congrats on getting the new Powerwall! Do you know if it is on your local network? If so, can you log in to your Powerwall web portal? Tesla has instructions (link) but I wonder if it works for your setup. The pypowerwall library uses the APIs on that web portal for Powerwall/2/+. Can you also provide the model number / picture of the Powerwall? —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

jasonacox · 2023-11-19T05:40:16Z

The key will be figuring out how to log in to the web portal as that is essentially what pypowerwall is doing.

You can try some of the URLs (replace the IP with the address of your Powerwall):

https://10.1.2.3/summary?mode=kiosk
https://10.1.2.3/api/site_info

jesaf00 · 2023-11-19T17:16:16Z

HI, those urls with my IP produce a 404 after bypassing the certificate. Attached are the photos and the part number is 1707000-25-G. Connecting to the PW3s wifi directly does the same thing when accessing 91.1 ip. Also, the wifi network is not teg, it is TeslaPW_xxxxx.

404error.mov

jasonacox · 2023-11-19T18:44:51Z

Thanks @jesaf00 ! The new Powerwalls look nice. Thanks for the video. Just to confirm, you also tried the landing page https://192.168.200.51/ by itself?

I'm worried. If you are able to connect to their local WiFi but still unable to get to any web portal, that could indicate that Tesla is removing the local access (and APIs) and switching to Cloud only control and monitoring similar to the solar-only configurations. The good news is that @mcbirse 's tesla-history code will likely be able to get that data, but the bad news is that it won't be at the same fidelity as local API provides and will be limited (local API for PW/2/+ can provide string, voltage, frequency, alert and temp data).

Since you are likely one of the first to get these, the local access may still be under development. Also, since you are getting a 404, we know it does still have a webserver running. They may not have a customer page, but there could still be APIs. You might try this:

https://192.168.200.51/api/login/Basic

There definitely isn't much on the internet about PW3 other than "they are coming in 2024." I'll reach out to see if anyone else has discovered the APIs.

If you still have the contact with the installer, can you ask if there is a local web portal (or APIs) that customers can access/use? Feel free to direct them to this dashboard project if they wonder why. :)

jesaf00 · 2023-11-19T18:48:59Z

Hi Jason, yes I tried just the IP and https://192.168.200.51/api/login/Basic also gives 404, arg! I am having a couple of issues with these also so hopefully I can just get the working correctly. I am running a port scanner to see what other ports might be open besides 443 and will let you know.

https://teslamotorsclub.com/tmc/posts/7917791/

jasonacox · 2023-11-19T18:58:16Z

Thanks for that link!

Good idea on the port scanner. Again, the 404 does provide hope that there is an underlying API (a new one) that we just don't know yet. However, without a UI, it will be hard to determine what they are unless Tesla is willing to provide it to us. Perhaps the installer application makes calls to this and we could pick it up by traffic sniffing.

jasonacox · 2023-11-19T21:08:43Z

@jesaf00 - Great suggestion from @vls29 at vloschiavo/powerwall2#99 (comment): If you can, try to run a verbose curl against the Powerwall 3. Even if it is a 404, there might be payload or header data that could be helpful.

curl -v -k  https://192.168.200.51

jesaf00 · 2023-11-19T21:10:33Z

Here is the output

Last login: Sun Nov 19 10:28:14 on ttys001
jerry@MBP14M3aceblack ~ % curl -v -k  https://192.168.200.51
*   Trying 192.168.200.51:443...
* Connected to 192.168.200.51 (192.168.200.51) port 443 (#0)
* ALPN: offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / AEAD-AES128-GCM-SHA256
* ALPN: server accepted h2
* Server certificate:
*  subject: C=US; ST=California; L=Palo Alto; O=Tesla; OU=Tesla Energy Products; CN=d9528c5155a2621cf41a465e671195cc
*  start date: Jul 14 12:33:48 2023 GMT
*  expire date: Jul  7 12:33:45 2048 GMT
*  issuer: C=US; ST=California; L=Palo Alto; O=Tesla; OU=Tesla Energy Products; CN=d9528c5155a2621cf41a465e671195cc CA
*  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
* using HTTP/2
* h2 [:method: GET]
* h2 [:scheme: https]
* h2 [:authority: 192.168.200.51]
* h2 [:path: /]
* h2 [user-agent: curl/8.1.2]
* h2 [accept: */*]
* Using Stream ID: 1 (easy handle 0x12900e200)
> GET / HTTP/2
> Host: 192.168.200.51
> User-Agent: curl/8.1.2
> Accept: */*
> 
< HTTP/2 404 
< content-type: text/plain; charset=utf-8
< x-content-type-options: nosniff
< content-length: 19
< date: Sun, 19 Nov 2023 21:09:20 GMT
< 
404 page not found
* Connection #0 to host 192.168.200.51 left intact
jerry@MBP14M3aceblack ~ %

jasonacox · 2023-11-19T21:27:07Z

Thanks Jerry. Not much here, sadly. For completeness, it would be good to try some POSTs as well:

# Powerwall 2 Login Endpoint
curl -v -k -s -i -X POST -H "Content-Type: application/json" -d '{"username":"[email protected]","password":"example","force_sm_off":false}' https://192.168.200.51/api/login/Basic

# Root Endpoint
curl -v -k -s -i -X POST -H "Content-Type: application/json" -d '{"username":"[email protected]","password":"example","force_sm_off":false}' https://192.168.200.51/

jesaf00 · 2023-11-20T02:01:10Z

Not sure this gave anything different. Is the password my Tesla.com password?

 https://192.168.200.51/api/login/Basic
*   Trying 192.168.200.51:443...
* Connected to 192.168.200.51 (192.168.200.51) port 443 (#0)
* ALPN: offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / AEAD-AES128-GCM-SHA256
* ALPN: server accepted h2
* Server certificate:
*  subject: C=US; ST=California; L=Palo Alto; O=Tesla; OU=Tesla Energy Products; CN=d9528c5155a2621cf41a465e671195cc
*  start date: Jul 14 12:33:48 2023 GMT
*  expire date: Jul  7 12:33:45 2048 GMT
*  issuer: C=US; ST=California; L=Palo Alto; O=Tesla; OU=Tesla Energy Products; CN=d9528c5155a2621cf41a465e671195cc CA
*  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
* using HTTP/2
* h2 [:method: POST]
* h2 [:scheme: https]
* h2 [:authority: 192.168.200.51]
* h2 [:path: /api/login/Basic]
* h2 [user-agent: curl/8.1.2]
* h2 [accept: */*]
* h2 [content-type: application/json]
* h2 [content-length: 101]
* Using Stream ID: 1 (easy handle 0x13a00da00)
> POST /api/login/Basic HTTP/2
> Host: 192.168.200.51
> User-Agent: curl/8.1.2
> Accept: */*
> Content-Type: application/json
> Content-Length: 101
> 
* We are completely uploaded and fine
< HTTP/2 404 
HTTP/2 404 
< content-type: text/plain; charset=utf-8
content-type: text/plain; charset=utf-8
< x-content-type-options: nosniff
x-content-type-options: nosniff
< content-length: 19
content-length: 19
< date: Mon, 20 Nov 2023 01:58:28 GMT
date: Mon, 20 Nov 2023 01:58:28 GMT

< 
404 page not found
* Connection #0 to host 192.168.200.51 left intact

https://192.168.200.51               
*   Trying 192.168.200.51:443...
* Connected to 192.168.200.51 (192.168.200.51) port 443 (#0)
* ALPN: offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / AEAD-AES128-GCM-SHA256
* ALPN: server accepted h2
* Server certificate:
*  subject: C=US; ST=California; L=Palo Alto; O=Tesla; OU=Tesla Energy Products; CN=d9528c5155a2621cf41a465e671195cc
*  start date: Jul 14 12:33:48 2023 GMT
*  expire date: Jul  7 12:33:45 2048 GMT
*  issuer: C=US; ST=California; L=Palo Alto; O=Tesla; OU=Tesla Energy Products; CN=d9528c5155a2621cf41a465e671195cc CA
*  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
* using HTTP/2
* h2 [:method: POST]
* h2 [:scheme: https]
* h2 [:authority: 192.168.200.51]
* h2 [:path: /]
* h2 [user-agent: curl/8.1.2]
* h2 [accept: */*]
* h2 [content-type: application/json]
* h2 [content-length: 101]
* Using Stream ID: 1 (easy handle 0x15a80d000)
> POST / HTTP/2
> Host: 192.168.200.51
> User-Agent: curl/8.1.2
> Accept: */*
> Content-Type: application/json
> Content-Length: 101
> 
* We are completely uploaded and fine
< HTTP/2 404 
HTTP/2 404 
< content-type: text/plain; charset=utf-8
content-type: text/plain; charset=utf-8
< x-content-type-options: nosniff
x-content-type-options: nosniff
< content-length: 19
content-length: 19
< date: Mon, 20 Nov 2023 02:00:01 GMT
date: Mon, 20 Nov 2023 02:00:01 GMT

< 
404 page not found
* Connection #0 to host 192.168.200.51 left intact

jasonacox · 2023-11-20T02:49:00Z

Thanks again! Unfortunately, it didn't give us much more. Also, the user/password doesn't matter. If it was working it would have given us something like an access denied message instead of a 404.

How did the installer configure the Powerwalls? Was it the Tesla Pro app?

Are you able to connect to each Powerwall separately? In my Powerwall+ setup, the backup gateway is a separate box and has its own WiFi access point which is where the web portal works. I wonder if there are other access points. If so, it would be good to run the curl commands against those.

longzheng · 2023-11-20T07:04:26Z

It looks like Powerwall 3 can be designed without a Backup Gateway 2, I'm guessing that's what OP has.

Because the dashboard/portal exists on the gateway at the moment, I'm guessing there's no dashboard/portal when connecting directly to a Powerwall 3?

zigam · 2023-11-20T08:10:22Z

This was the case for PW2 as well, with a backup switch (i.e. no gateway) one of the Powerwalls is designated a "site controller" and acts as the gateway, with the same web and API interface.

However, the access seems to have changed with PW3. Based on reports here and from TMC forums:

No access to web or /api using the local network.
No access to web using the internal wifi network (now named TeslaPW_xxx).
Access is possible using the Tesla Pros app, which uses the internal wifi network. Tesla Pros seems to be using a new binary /tedapi endpoint which I posted about here.

jasonacox · 2023-11-20T17:52:34Z

This is great @zigam ! It is possible the Powerwall 3 has this same binary to be compatible with the Tesla Pros app.

@jesaf00 could you try these curl commands to see if you get anything on the PW3?

# Log in to the TeslaPW_xxx wifi 

# First just check to see if the API is responsive
curl -v -k https://192.168.91.1/tedapi/din
curl -v -k https://192.168.91.1/tedapi/v1

# Store the gateway password
export GW_PWD="<FULL_GATEWAY_PWD>"

# Get the device din, e.g. 1232100-10-E--CN321329G1E123.
curl -k -u Tesla_Energy_Device:$GW_PWD https://192.168.91.1/tedapi/din

Next, if that works, download this and rename to request.bin - edit it to have your DIN.
request.bin.txt

# Request the configuration (binary file - protobuf payload?)
curl -k -H 'Content-type: application/octet-string' -u Tesla_Energy_Device:$GW_PWD --data-binary @request.bin https://192.168.91.1/tedapi/v1

pbburkhalter · 2023-11-20T18:31:17Z

@jasonacox here's the output from my recently installed PW3's

curl -v -k https://192.168.1.73/tedapi/din
*   Trying 192.168.1.73:443...
* Connected to 192.168.1.73 (192.168.1.73) port 443
* schannel: disabled automatic use of client certificate
* schannel: using IP address, SNI is not supported by OS.
* ALPN: curl offers http/1.1
* ALPN: server accepted http/1.1
* using HTTP/1.1
> GET /tedapi/din HTTP/1.1
> Host: 192.168.1.73
> User-Agent: curl/8.4.0
> Accept: */*
>
* schannel: remote party requests renegotiation
* schannel: renegotiating SSL/TLS connection
* schannel: SSL/TLS connection renegotiated
< HTTP/1.1 403 Forbidden
< Content-Type: application/json
< X-Content-Type-Options: nosniff
< Date: Mon, 20 Nov 2023 18:27:08 GMT
< Content-Length: 102
<
{"code":403,"error":"Unable to GET to resource","message":"User does not have adequate access rights"}* Connection #0 to host 192.168.1.73 left intact

curl -v -k https://192.168.1.73/tedapi/v1
*   Trying 192.168.1.73:443...
* Connected to 192.168.1.73 (192.168.1.73) port 443
* schannel: disabled automatic use of client certificate
* schannel: using IP address, SNI is not supported by OS.
* ALPN: curl offers http/1.1
* ALPN: server accepted http/1.1
* using HTTP/1.1
> GET /tedapi/v1 HTTP/1.1
> Host: 192.168.1.73
> User-Agent: curl/8.4.0
> Accept: */*
>
* schannel: remote party requests renegotiation
* schannel: renegotiating SSL/TLS connection
* schannel: SSL/TLS connection renegotiated
< HTTP/1.1 405 Method Not Allowed
< Content-Type: text/plain; charset=utf-8
< X-Content-Type-Options: nosniff
< Date: Mon, 20 Nov 2023 18:29:00 GMT
< Content-Length: 19
<
Method Not Allowed
* Connection #0 to host 192.168.1.73 left intact

zigam · 2023-11-20T18:36:38Z

@pbburkhalter you'll have to run these commands while on the TeslaPW_xxx wifi network. The ip address on that network will likely be 192.168.91.1.

pbburkhalter · 2023-11-20T18:37:57Z

Oops. I did just connect to that and got the same results.

zigam · 2023-11-20T18:42:59Z

Those responses are actually expected because auth was not provided and the second one requires a POST. This is the one that will hopefully work:

# Full gateway password should be on the sticker inside the PW3.
export GW_PWD="<FULL_GATEWAY_PWD>"

# Get the device din, e.g. 1232100-10-E--CN321329G1E123.
curl -k -u Tesla_Energy_Device:$GW_PWD https://192.168.91.1/tedapi/din

pbburkhalter · 2023-11-20T19:05:27Z

Yes, that does work.

zigam · 2023-11-20T19:25:54Z

Great! The next step would be an actual RPC call. Goes without saying that this is uncharted territory, so proceed at your own risk :)

Download request.bin.txt, rename it to request.bin, and edit the file by replacing the din with your own din from the command above. You have to do this carefully, the din in the file ends with 123 so the z character remains in the file. Assuming your din is the same length as the one currently in the file (1232100-10-E--CN321329G1E123), the file should remain at 63 bytes. Then:

# Request the configuration.
curl -k -H 'Content-type: application/octet-string' -u Tesla_Energy_Device:$GW_PWD --data-binary @request.bin https://192.168.91.1/tedapi/v1

If this works, you should get a response with the entire configuration of your system. 🤞

pbburkhalter · 2023-11-20T20:38:26Z

Doesn't work from a command line or PowerShell but I'm open to ideas.

zigam · 2023-11-20T20:57:40Z

@pbburkhalter what's the error? I think the other way to investigate the protocol would be to install a debugging proxy on the phone and capture Tesla Pros traffic. This is a bit more involved, but if you want to spend the time (and a bit of money, the proxy app costs $9) I'd be happy to help. ziga.mahkovec AT gmail.com.

pbburkhalter · 2023-11-20T21:20:48Z

Sorry I should have clarified I'm not using the Tesla pros app... I am just running it on my computer connected to the PowerWall wi-fi network

zigam · 2023-11-20T21:26:11Z

@pbburkhalter right but these curl requests are replaying what the Tesla Pros app does. So if they don't work for you, you'd have to inspect the requests that the app generates so we can learn how to reproduce them.

The error you got from curl would also be helpful.

pbburkhalter · 2023-11-20T21:44:43Z

curl: (6) Could not resolve host: application

jasonacox · 2024-09-07T14:25:02Z

@heynorm - That's great news! ❤️ Thanks for the encouragement! Would you be willing to share a screenshot of your dashboard that shows the strings? I took some guesses building the CQs and queries and would love to see how it is working.

@rmotapar - To get the string data, you will need to use the local (and routed) 192.168.91.1 extended device metrics endpoint which is where the tedapi API lives.

Can you share what you get by running the verify.sh script or http://localhost:8675/help? If you see that you are running cloud mode, you will need to make some changes. Make sure you have the network routing set up (see here) so that you can ping 192.168.91.1 from the host that runs the Dashboard, and then rerun setup.sh as @heynorm mentions but select option 4 (Powerwall 3 using the local Tesla Gateway).

rmotapar · 2024-09-07T15:23:05Z

@rmotapar - To get the string data, you will need to use the local (and routed) 192.168.91.1 extended device metrics endpoint which is where the tedapi API lives.

Yes, I am using the tedapi and I added a static route in my Unifi router so all devices in my network can access/ping 192.168.91.1. Tested via curl and I am able to invoke the tedapi endpoints successfully.

I did customize my dashboard a bit to make it work through reverse proxy so I may have messed up something. @heynorm thanks for reporting that string data is working for you. I will do a fresh install and will report back the results.

@jasonacox
P.S We might want to add instructions on how to add static routes at the router level so one doesn't have to run the ip route commands on each node hosting the dashboard.

rmotapar · 2024-09-07T15:30:07Z

@jasonacox Here are the results of the verify.sh script. It does say Not Connected under TEDAPI Vitals.

`Verify Powerwall-Dashboard 4.5.1 on Linux - Timezone: America/Chicago

This script will attempt to verify all the services needed to run
Powerwall-Dashboard. Use this output when you open an issue for help:
https://github.com/jasonacox/Powerwall-Dashboard/issues/new

Checking pypowerwall

Config File pypowerwall.env: GOOD
Container (pypowerwall): GOOD
Service (port 8675): GOOD
Version: 0.11.0 Proxy t64
Powerwall State: CONNECTED - Firmware: 24.28.1
Site Name: My Home
Gateway TEDAPI: Available (192.168.91.1)
TEDAPI Vitals: Not Connected
Cloud Mode: NO
`

jasonacox · 2024-09-07T15:38:04Z

P.S We might want to add instructions on how to add static routes at the router level so one doesn't have to run the ip route commands on each node that needs access to 192.168.91.1.

That is one option, but I have been hesitant to do that because it opens up this protected installer API of your Powerwall to your entire LAN traffic. Technically it shouldn't matter if everything on your network behaves well. But more important, my router won't allow static routes so I focused on host level routes. 😉 If someone who has a Unifi wants to write up the details in a Discussion thread or PR, I would gladly add that link to the setup instructions. 🙏

rmotapar · 2024-09-07T15:43:50Z

P.S We might want to add instructions on how to add static routes at the router level so one doesn't have to run the ip route commands on each node that needs access to 192.168.91.1.

That is one option, but I have been hesitant to do that because it opens up this protected installer API of your Powerwall to your entire LAN traffic. Technically it shouldn't matter if everything on your network behaves well. But more important, my router won't allow static routes so I focused on host level routes. 😉 If someone who has a Unifi wants to write up the details in a Discussion thread or PR, I would gladly add that link to the setup instructions. 🙏

Yeah, totally makes sense to be cautious about opening up the protected installer API to entire LAN. I will see if I can create a PR.

jasonacox · 2024-09-07T15:49:56Z

Here are the results of the verify.sh script. It does say Not Connected under TEDAPI Vitals.

Yes, that is a bug - thanks to @SCHibbard who reported it here: #515

I did change the dashboard.json to add the additional PW3 strings (E & F) and to account for multiple PW3's. Are you still not getting string data? Can you check a few of these (you probably don't want to post them, just check to see if they contain the string data payloads):

http://localhost:8675/tedapi/status - this is the raw API that the Tesla One app uses for live data
http://localhost:8675/tedapi/config - this is the API that shows the system config data
http://localhost:8675/strings

SCHibbard · 2024-09-07T16:10:25Z

Just updated from 4.3.2 to 4.5.1 yesterday, and tackled the network mods (running on Ubuntu). Like @jasonacox, a little hesitant to place the static route in my router, but don't like that lack of persistence of the setting over reboots. Putting the command in a cron task causes it to fire before the network is ready, so did a Q&D script to run in cron as an "@reboot". It will run for 15 seconds or until the response of the command says the routing already exists:

#!/bin/bash
declare -i i=0
while (( i < 15 )); do
    RETURN="$(ip route add 192.168.91.0/24 via <PW_IP_ADDRESS> 2>&1)"
    if [ "$RETURN" != "RTNETLINK answers: File exists" ]; then
        declare -i i=i+1
        sleep 1
    else
        RETURN="Success"
        break
    fi
done
NOW="$(date)"
echo "${NOW}: result=${RETURN}, delay=${i}" >> /<your folder>/PW_routing.log

heynorm · 2024-09-07T16:32:49Z

Jason, Here is a snapshot of the string stuff in the dashboard for yesterday along with the output from http://localhost:8675/strings run just now: [cid:10bb71ff-7d61-4d0a-8f8f-5a0d892599d9] { "A": { "Connected": true, "Current": 0.6999999999999997, "Power": 225.39999999999992, "State": "Pv_Active", "Voltage": 322 }, "A1": { "Connected": true, "Current": 3.6999999999999997, "Power": 1132.1999999999998, "State": "Pv_Active", "Voltage": 306 }, "B": { "Connected": true, "Current": 0.6999999999999997, "Power": 263.1999999999999, "State": "Pv_Active", "Voltage": 376 }, "B1": { "Connected": true, "Current": 3.15, "Power": 856.8, "State": "Pv_Active", "Voltage": 272 }, "C": { "Connected": true, "Current": 0.7499999999999997, "Power": 224.9999999999999, "State": "Pv_Active", "Voltage": 300 }, "C1": { "Connected": true, "Current": 3.3, "Power": 1069.2, "State": "Pv_Active", "Voltage": 324 }, "D": { "Connected": true, "Current": 0.04999999999999964, "Power": 0.0, "State": "Pv_Active", "Voltage": 0 }, "D1": { "Connected": true, "Current": 0, "Power": 0, "State": "Pv_Active", "Voltage": 0 }, "E": { "Connected": true, "Current": 0, "Power": 0, "State": "Pv_Active", "Voltage": 0 }, "E1": { "Connected": true, "Current": 0, "Power": 0, "State": "Pv_Active", "Voltage": 0 }, "F": { "Connected": true, "Current": 0, "Power": 0, "State": "Pv_Active_Parallel", "Voltage": 0 }, "F1": { "Connected": true, "Current": 0, "Power": 0, "State": "Pv_Active_Parallel", "Voltage": 0 } } Let me know if you need more details about my config.

…

________________________________ From: Jason Cox ***@***.***> Sent: Saturday, September 7, 2024 7:25 AM To: jasonacox/Powerwall-Dashboard ***@***.***> Cc: heynorm ***@***.***>; Mention ***@***.***> Subject: Re: [jasonacox/Powerwall-Dashboard] Powerwall 3 Support (Issue #387) @heynorm<https://github.com/heynorm> - That's great news! ❤️ Thanks for the encouragement! Would you be willing to share a screenshot of your dashboard that shows the strings? I took some guesses building the CQs and queries and would love to see how it is working. @rmotapar<https://github.com/rmotapar> - To get the string data, you will need to use the local (and routed) 192.168.91.1 extended device metrics endpoint which is where the tedapi API lives. Can you share what you get by running the verify.sh script or http://localhost:8675/help? If you see that you are running cloud mode, you will need to make some changes. Make sure you have the network routing set up (see here<https://github.com/jasonacox/Powerwall-Dashboard?tab=readme-ov-file#extended-device-vitals-metrics-beta>) so that you can ping 192.168.91.1 from the host that runs the Dashboard, and then rerun setup.sh as @heynorm<https://github.com/heynorm> mentions but select option 4 (Powerwall 3 using the local Tesla Gateway). — Reply to this email directly, view it on GitHub<#387 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/APUXY3FHXVG7II6G6MCXJ73ZVMEFLAVCNFSM6AAAAAA7RJOQ36VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMZVGIZTKNBRHA>. You are receiving this because you were mentioned.

heynorm · 2024-09-07T18:27:40Z

Jason - resposting with the screenshot for the above comment:

jasonacox · 2024-09-07T18:35:23Z

Thanks @heynorm ! That looks great! It may be nice to disable the ghost strings automatically but from what you show in the graph, it seems they do get some phantom power occasionally.

jasonacox · 2024-09-07T18:50:24Z

Thanks @SCHibbard - nice script! Thanks for sharing. MacOS and Windows have an easy way to set persistent routes, but Linux seems to have dozens of ways and they are all "non-trivial". I wonder if it would be helpful to have a setup-route.sh script (or part of setup.sh) that will detect OS and do the needful for you? Of course, it would be optional and those who want to set it up via their router could still do so.

heynorm · 2024-09-07T19:14:50Z

Yeah - I see that phantom power on the ghost strings in the Tesla One app as well. I wonder what that is all about.

…

________________________________ From: Jason Cox ***@***.***> Sent: Saturday, September 7, 2024 11:35 AM To: jasonacox/Powerwall-Dashboard ***@***.***> Cc: heynorm ***@***.***>; Mention ***@***.***> Subject: Re: [jasonacox/Powerwall-Dashboard] Powerwall 3 Support (Issue #387) Thanks @heynorm<https://github.com/heynorm> ! That looks great! It may be nice to disable the ghost strings automatically but from what you show in the graph, it seems they do get some phantom power occasionally. — Reply to this email directly, view it on GitHub<#387 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/APUXY3CUOEP7ZG77UJRQJPDZVNBQHAVCNFSM6AAAAAA7RJOQ36VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMZWGQYDCMJQGE>. You are receiving this because you were mentioned.Message ID: ***@***.***>

rmotapar · 2024-09-07T19:37:07Z

http://localhost:8675/strings

@jasonacox /status and /config seem to be working but /strings returns an empty response. I reinstalled the entire thing from scratch. Not sure what I am missing.

agoddard · 2024-09-07T20:18:08Z

New PW3 strings support, additional Alerts & PW capacity data is amazing, thank you!

rmotapar · 2024-09-07T20:30:36Z

@jasonacox Here's the error I am seeing in pypowerwall when /strings endpoint is being called:

----------------------------------------
Exception occurred during processing of request from ('172.19.0.1', 54858)
Traceback (most recent call last):
  File "/usr/local/lib/python3.10/socketserver.py", line 683, in process_request_thread
    self.finish_request(request, client_address)
  File "/usr/local/lib/python3.10/socketserver.py", line 360, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/usr/local/lib/python3.10/socketserver.py", line 747, in __init__
    self.handle()
  File "/usr/local/lib/python3.10/http/server.py", line 433, in handle
    self.handle_one_request()
  File "/usr/local/lib/python3.10/http/server.py", line 421, in handle_one_request
    method()
  File "/app/server.py", line 348, in do_GET
    message: str = pw.strings(jsonformat=True) or json.dumps({})
  File "/usr/local/lib/python3.10/site-packages/pypowerwall/__init__.py", line 398, in strings
    v: dict = self.vitals() or {}
  File "/usr/local/lib/python3.10/site-packages/pypowerwall/__init__.py", line 378, in vitals
    output = self.client.vitals()
  File "/usr/local/lib/python3.10/site-packages/pypowerwall/tedapi/pypowerwall_tedapi.py", line 552, in vitals
    return self.tedapi.vitals()
  File "/usr/local/lib/python3.10/site-packages/pypowerwall/tedapi/__init__.py", line 1291, in vitals
    pw3_data = self.get_pw3_vitals(force) or {}
  File "/usr/local/lib/python3.10/site-packages/pypowerwall/tedapi/__init__.py", line 633, in get_pw3_vitals
    for alert in components[component][0]['activeAlerts']:
IndexError: list index out of range
----------------------------------------

I am seeing the same error for pw.temps() as well. Not sure if it matters, I have two powerwalls. What endpoint can I try on the gateway (https://192.168.91.1/tedapi/<vitals?>) to see if it's returning any string data?

rmotapar · 2024-09-07T21:53:12Z

@jasonacox It seems related to the second powerwall I have (the follower). I ran the PW3_String.py script and it gave me the same error. I do see the string data for the main powerwall but it errored out when fetching the string data for the follower

 + Fetching ComponentsQuery from Powerwall (XXXXXXXXMAIN  Powerwall3)...
    - Alerts:
       - Alert: BAGGR_a003_BAGGR_Controller_Mia
       - Alert: BMS_a014_SW_End_Of_Charge
       - Alert: HVP_a046_SW_BRICK_DVDT_PYRO_WARNING
       - Alert: PWS_a004_MciSelfTestEF
    - PW1 Nominal Energy Remaining: 14.47 Nominal Full Pack Energy: 14.47 Energy to be Charged: 0.0
    - String A = State: Pv_Active Voltage: 118 Current: 0.7999999999999997 Power: 94.39999999999996
    - String B = State: Pv_Active Voltage: 234 Current: 0.9499999999999997 Power: 222.29999999999993
    - String C = State: Pv_Active Voltage: 392 Current: 4.35 Power: 1705.1999999999998
    - String D = State: Pv_Active Voltage: 342 Current: 8.85 Power: 3026.7
    - String E = State: Pv_Active Voltage: 0 Current: 0.04999999999999964 Power: 0.0
    - String F = State: Pv_Active_Parallel Voltage: 0 Current: -3.608224830031759e-16 Power: -0.0
 + Fetching ComponentsQuery from Powerwall (XXXXXXXXFOLLOWER Powerwall3Follower)...
    - Alerts:
Traceback (most recent call last):
  File "/home/rammy/dev/docker/solar/pypowerwall/tools/tedapi/PW3_Strings.py", line 182, in <module>
    for alert in components[component][0]['activeAlerts']:
IndexError: list index out of range

Created a PR on pypowerwall. Please take a look. With the change, I am seeing the right output.

jasonacox · 2024-09-07T22:23:45Z

I am seeing the same error for pw.temps() as well.

Can you share what you see with that? Sadly, we lost access to temps in the new Firmware vitals payload, but want to make sure it isn't some other logic bug.

jasonacox · 2024-09-07T23:51:54Z

@rmotapar I hope that the new update fixes the string issue you identified: v4.5.2

./update.sh

rmotapar · 2024-09-07T23:54:53Z

@rmotapar I hope that the new update fixes the string issue you identified: v4.5.2
./update.sh

Thank you @jasonacox It's working beautifully! Thank you so much for the quick turn around. Data just started showing up on the dashboard. Here's how it looks:

jasonacox · 2024-09-07T23:58:18Z

Fantastic!! Thanks @rmotapar!

rmotapar · 2024-09-08T00:03:12Z

I am seeing the same error for pw.temps() as well.

Can you share what you see with that? Sadly, we lost access to temps in the new Firmware vitals payload, but want to make sure it isn't some other logic bug.

Here's what I saw in the logs with pypowerwall:0.11.0

Exception occurred during processing of request from ('172.19.0.6', 59472)
Traceback (most recent call last):
  File "/usr/local/lib/python3.10/socketserver.py", line 683, in process_request_thread
    self.finish_request(request, client_address)
  File "/usr/local/lib/python3.10/socketserver.py", line 360, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/usr/local/lib/python3.10/socketserver.py", line 747, in __init__
    self.handle()
  File "/usr/local/lib/python3.10/http/server.py", line 433, in handle
    self.handle_one_request()
  File "/usr/local/lib/python3.10/http/server.py", line 421, in handle_one_request
    method()
  File "/app/server.py", line 378, in do_GET
    temps = pw.temps()
  File "/usr/local/lib/python3.10/site-packages/pypowerwall/__init__.py", line 566, in temps
    devices: dict = self.vitals() or {}
  File "/usr/local/lib/python3.10/site-packages/pypowerwall/__init__.py", line 378, in vitals
    output = self.client.vitals()
  File "/usr/local/lib/python3.10/site-packages/pypowerwall/tedapi/pypowerwall_tedapi.py", line 552, in vitals
    return self.tedapi.vitals()
  File "/usr/local/lib/python3.10/site-packages/pypowerwall/tedapi/__init__.py", line 1291, in vitals
    pw3_data = self.get_pw3_vitals(force) or {}
  File "/usr/local/lib/python3.10/site-packages/pypowerwall/tedapi/__init__.py", line 633, in get_pw3_vitals
    for alert in components[component][0]['activeAlerts']:
IndexError: list index out of range

With the latest pypowerwall:0.11.1, I am not seeing any of these but /temps is returning an empty response.

jasonacox · 2024-09-08T00:18:06Z

With the latest pypowerwall:0.11.1, I am not seeing any of these but /temps is returning an empty response.

Yes, the temps are likely gone forever. 😞 If anyone manages to spot temps on any of the API or the app, please let me know. 😉 The error you were seeing before was essentially the same one that impacted /strings (part of get_pw3_vitals()).

SCHibbard · 2024-09-08T17:21:43Z

Thanks @SCHibbard - nice script! Thanks for sharing. MacOS and Windows have an easy way to set persistent routes, but Linux seems to have dozens of ways and they are all "non-trivial". I wonder if it would be helpful to have a setup-route.sh script (or part of setup.sh) that will detect OS and do the needful for you? Of course, it would be optional and those who want to set it up via their router could still do so.

@jasonacox: thought about it being in setup.sh, but need sudo to add the task to cron - so yes, not so simple. Option would be a separate script for just this with instructions to run as Super User. You'd think an OS used on so many servers would have set this up as optionally persistent by now!

SCHibbard · 2024-09-09T14:06:30Z

Thought about the cron / sudo issue, and figure it's not a big deal if a script asks for su credentials during install. Created a script to build the crontask script and edit crontab. Will test it on my production system probably next weekend. @jasoncox: Would you like that as a separate script, should I try to build it into your setup.sh, or do you want to merge it into setup.sh?

jasonacox · 2024-09-10T03:00:40Z

Awesome! And good question. I'm tending to favor keeping it as a separate script, similar to tz.sh and weather.sh. That would make it easier for users wanting to do a manual install, or for existing installs that are using temp routes to activate a persistent route. We could still have setup.sh call it if the user wishes.

SCHibbard · 2024-09-11T21:52:07Z

@jasonacox : attached the script I used to create the TDAPI network routing script and add its cron task. Played with it on my sandbox, and today got a chance to upgrade Powerwall Dashboard on my production system, so tried it there. Worked fine! Note changed extension from .sh to .txt so GitHub issues would accept it.
TDAPI_network.txt

jukasdrj · 2024-10-15T23:44:25Z

Thank you all for running with this. I just finished my install of PW3 & solar; joining one of the Tesla Electric VPP here in Texas. I got the netzero hosted app to work fine, running it locally has been a pile though. Your efforts are awesome and I appreciate all your work.

jasonacox · 2024-10-17T05:59:48Z

Thanks for the kind feedback @jukasdrj !

jasonacox changed the title ~~I have a Powerwall 3 and willing to test~~ Powerwall 3 Support Nov 20, 2023

jasonacox mentioned this issue Nov 20, 2023

v0.6.3 Powerwall 3 Detection jasonacox/pypowerwall#55

Merged

jasonacox mentioned this issue Sep 7, 2024

Check if activeAlerts exists before listing alerts jasonacox/pypowerwall#112

Merged

jasonacox mentioned this issue Sep 12, 2024

TEDAPI network route script #519

Closed

Powerwall 3 Support #387

Powerwall 3 Support #387

Comments

jesaf00 commented Nov 18, 2023 • edited by jasonacox Loading

jesaf00 commented Nov 18, 2023 • edited Loading

jasonacox commented Nov 19, 2023

jesaf00 commented Nov 19, 2023 via email

jesaf00 commented Nov 19, 2023 via email

jasonacox commented Nov 19, 2023

jesaf00 commented Nov 19, 2023 • edited Loading

jasonacox commented Nov 19, 2023 • edited Loading

jesaf00 commented Nov 19, 2023

jasonacox commented Nov 19, 2023

jasonacox commented Nov 19, 2023

jesaf00 commented Nov 19, 2023 • edited by jasonacox Loading

jasonacox commented Nov 19, 2023

jesaf00 commented Nov 20, 2023 • edited by jasonacox Loading

jasonacox commented Nov 20, 2023

longzheng commented Nov 20, 2023

zigam commented Nov 20, 2023

jasonacox commented Nov 20, 2023

pbburkhalter commented Nov 20, 2023 • edited Loading

zigam commented Nov 20, 2023 • edited Loading

pbburkhalter commented Nov 20, 2023

zigam commented Nov 20, 2023 • edited Loading

pbburkhalter commented Nov 20, 2023

zigam commented Nov 20, 2023

pbburkhalter commented Nov 20, 2023

zigam commented Nov 20, 2023

pbburkhalter commented Nov 20, 2023

zigam commented Nov 20, 2023

pbburkhalter commented Nov 20, 2023

jasonacox commented Sep 7, 2024

rmotapar commented Sep 7, 2024 • edited Loading

rmotapar commented Sep 7, 2024

`Verify Powerwall-Dashboard 4.5.1 on Linux - Timezone: America/Chicago

Checking pypowerwall

jasonacox commented Sep 7, 2024

rmotapar commented Sep 7, 2024

jasonacox commented Sep 7, 2024

SCHibbard commented Sep 7, 2024 • edited Loading

heynorm commented Sep 7, 2024 via email

heynorm commented Sep 7, 2024

jasonacox commented Sep 7, 2024

jasonacox commented Sep 7, 2024

heynorm commented Sep 7, 2024 via email

rmotapar commented Sep 7, 2024

agoddard commented Sep 7, 2024

rmotapar commented Sep 7, 2024 • edited Loading

rmotapar commented Sep 7, 2024

jasonacox commented Sep 7, 2024

jasonacox commented Sep 7, 2024

rmotapar commented Sep 7, 2024

jasonacox commented Sep 7, 2024

rmotapar commented Sep 8, 2024

jasonacox commented Sep 8, 2024

SCHibbard commented Sep 8, 2024 • edited Loading

SCHibbard commented Sep 9, 2024

jasonacox commented Sep 10, 2024

SCHibbard commented Sep 11, 2024

jukasdrj commented Oct 15, 2024

jasonacox commented Oct 17, 2024

jesaf00 commented Nov 18, 2023 •

edited by jasonacox

Loading

jesaf00 commented Nov 18, 2023 •

edited

Loading

jesaf00 commented Nov 19, 2023 •

edited

Loading

jasonacox commented Nov 19, 2023 •

edited

Loading

jesaf00 commented Nov 19, 2023 •

edited by jasonacox

Loading

jesaf00 commented Nov 20, 2023 •

edited by jasonacox

Loading

pbburkhalter commented Nov 20, 2023 •

edited

Loading

zigam commented Nov 20, 2023 •

edited

Loading

zigam commented Nov 20, 2023 •

edited

Loading

rmotapar commented Sep 7, 2024 •

edited

Loading

SCHibbard commented Sep 7, 2024 •

edited

Loading

rmotapar commented Sep 7, 2024 •

edited

Loading

SCHibbard commented Sep 8, 2024 •

edited

Loading