search

jasonacox / Powerwall-Dashboard

Grafana Monitoring Dashboard for Tesla Solar and Powerwall Systems
MIT License
270 stars 57 forks source link

Powerwall 3 Support #387

Open jesaf00 opened 7 months ago

jesaf00 commented 7 months ago

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 commented 7 months ago

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.

Screenshot 2023-11-18 at 5 27 14 PM Screenshot 2023-11-18 at 5 27 04 PM
jasonacox commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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. 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 commented 7 months ago

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 commented 7 months ago

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.

IMG_0033 IMG_0035 IMG_0048 IMG_0075 (1)

https://github.com/jasonacox/Powerwall-Dashboard/assets/136191207/918e5dea-0314-408d-9728-41b861c3b60e

jasonacox commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

@jesaf00 - Great suggestion from @vls29 at https://github.com/vloschiavo/powerwall2/discussions/99#discussioncomment-7613279: 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 commented 7 months ago

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 commented 7 months ago

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":"example@example.com","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":"example@example.com","password":"example","force_sm_off":false}' https://192.168.200.51/
jesaf00 commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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

image

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 commented 7 months ago

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:

  1. No access to web or /api using the local network.
  2. No access to web using the internal wifi network (now named TeslaPW_xxx).
  3. 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 commented 7 months ago

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 commented 7 months ago

@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 commented 7 months ago

@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 commented 7 months ago

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

zigam commented 7 months ago

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 commented 7 months ago

Yes, that does work.

zigam commented 7 months ago

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 commented 7 months ago

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

zigam commented 7 months ago

@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 commented 7 months ago

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 commented 7 months ago

@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 commented 7 months ago

curl: (6) Could not resolve host: application

zigam commented 7 months ago

curl: (6) Could not resolve host: application

Ah, that looks like a shell issue with the single quotes. Try this:

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
jasonacox commented 7 months ago

I updated pypowerwall (v0.6.3) to detect Powerwall 3 devices on your local network. I haven't added any additional support for the /tedapi APIs but this may help if you are looking for Powerwall 3 gateways on your local network.

# Install python package - or upgrade
pip3 install --upgrade pypowerwall

# Scan
python3 -m pypowerwall scan
pbburkhalter commented 7 months ago

curl: (28) Failed to connect to 192.168.91.1 port 443 after 21035 ms: Couldn't connect to server

zigam commented 7 months ago

curl: (28) Failed to connect to 192.168.91.1 port 443 after 21035 ms: Couldn't connect to server

Just to confirm, this was on the PW3 wifi and the previous /din command still works?

curl -k -u Tesla_Energy_Device:$GW_PWD https://192.168.91.1/tedapi/din
pbburkhalter commented 7 months ago

That is correct

zigam commented 7 months ago

Thanks for testing it! I'm curious if this works for others, regardless of whether they're running PW3 or PW2+.

stevecastaneda commented 7 months ago

I updated pypowerwall (v0.6.3) to detect Powerwall 3 devices on your local network

With my 4x PW3 install, I notice the scan will find the 3 x child powerwalls, but not the last one designated by the installers as the main.

jesaf00 commented 7 months ago

Sorry for the delay. The updated pypowerwall found 2 of the 3 PW3s but did not locate the second one at .204. I am having issues with connectivity so that may be related. 

pyPowerwall Network Scanner [0.6.3]
Scan local network for Tesla Powerwall Gateways

    Your network appears to be: 192.168.200.0/24

    Enter Network or press enter to use 192.168.200.0/24: 

    Running Scan...
      Host: 192.168.200.1 ... OPEN - Not a Powerwall
      Host: 192.168.200.6 ... OPEN - Not a Powerwall
      Host: 192.168.200.10 ... OPEN - Not a Powerwall
      Host: 192.168.200.51 ... OPEN - Found Powerwall 3 [Currently Unsupported]
      Host: 192.168.200.145 ... OPEN - Not a Powerwall
      Host: 192.168.200.213 ... OPEN - Not a Powerwall
      Host: 192.168.200.238 ... OPEN - Not a Powerwall
      Host: 192.168.200.246 ... OPEN - Found Powerwall 3 [Currently Unsupported]
      Done                           

Discovered 2 Powerwall Gateway
     192.168.200.51 [Powerwall-3] Firmware Currently Unsupported - See https://tinyurl.com/pw3support
     192.168.200.246 [Powerwall-3] Firmware Currently Unsupported - See https://tinyurl.com/pw3support
jasonacox commented 7 months ago

Thanks @jesaf00 and @stevecastaneda !

With my 4x PW3 install, I notice the scan will find the 3 x child powerwalls, but not the last one designated by the installers as the main.

@stevecastaneda on the main PW3 that it didn't find, what data do you get back when you run this against its endpoint? If you can, use it's local IP address (if you can figure it out) as well as connecting to its WiFI.

curl -v -k -u Tesla_Energy_Device:GW_PWD https://192.168.91.1/tedapi/din
jasonacox commented 7 months ago

@zigam Testing this on my PW+ system using the script and modifying the request.bin with my DIN.

export GW_USER="Tesla_Energy_Device"
export GW_PWD="XXXXXXXXXX"
export GW_IP="192.168.91.1"

echo "-- DIN Payload --"
curl -v -k -u "$GW_USER:$GW_PWD" https://$GW_IP/tedapi/din

echo "-- Config Payload --"
curl -v -k -H 'Content-type: application/octet-string' -u "$GW_USER:$GW_PWD" --data-binary @request.bin https://$GW_IP/tedapi/v1

Connecting to TEG-xxx wifi:

Connected to Local Network:

jesaf00 commented 7 months ago

According to Rockyproc at https://teslamotorsclub.com/tmc/posts/7919661/ , he was able to get more info from Home Assistant + HACS.

stevecastaneda commented 7 months ago

@stevecastaneda on the main PW3 that it didn't find, what data do you get back when you run this against its endpoint? If you can, use it's local IP address (if you can figure it out) as well as connecting to its WiFI.

curl -v -k -u Tesla_Energy_Device:GW_PWD https://192.168.91.1/tedapi/din
jasonacox commented 7 months ago

According to Rockyproc at https://teslamotorsclub.com/tmc/posts/7919661/ , he was able to get more info from Home Assistant + HACS.

Thanks @jesaf00 ! However, unless I'm reading it wrong, The Home Assistant "Tesla Custom Integration" that the post mentions, uses the Tesla Cloud. There is another one for powerwalls that uses https://github.com/jrester/tesla_powerwall. That library uses a similar approach to pypowerwall but would be interesting to verify.

The Tesla Custom Integration is similar to what the tesla-history and solar-only tools do. You can get some of the main data that way but it is delayed and doesn't include some things like voltage, frequencies, temperatures, alerts, capacity-degredation, string data, etc.

Connected to Local Network: {"code":403,"error":"Unable to GET to resource","message":"User does not have adequate access rights"}

Thanks @stevecastaneda ! The pypowerwall scan is looking for this exact string to find Powerwall 3 instances on your local network. Can you run it again to see if it just happened to miss it the first time? I may need to expand the timeout.

stevecastaneda commented 7 months ago

Thanks @stevecastaneda ! The pypowerwall scan is looking for this exact string to find Powerwall 3 instances on your local network. Can you run it again to see if it just happened to miss it the first time? I may need to expand the timeout.

You're right - a second scan found the one missing in the first, but then didn't find a different one in the 2nd scan. +1 to adding time to the timeout.

jasonacox commented 7 months ago

@stevecastaneda - The default is 400ms (0.4s) and you can adjust it via command line. I can change the default if you can help me find the sweet spot. Of course, the issue is that the higher we go, the longer the scan takes. Try a few of these:


# timeout set to 500ms = 0.5s
python3 -m pypowerwall scan 0.5

# timeout set to 1s
python3 -m pypowerwall scan 1
jesaf00 commented 7 months ago

.5 didn't get all three and neither did .1, however when I query that one specifically it worked.

`pyPowerwall Network Scanner [0.6.3] Scan local network for Tesla Powerwall Gateways

Your network appears to be: 192.168.200.0/24

Enter Network or press enter to use 192.168.200.0/24: 

Running Scan...
  Host: 192.168.200.1 ... OPEN - Not a Powerwall
  Host: 192.168.200.6 ... OPEN - Not a Powerwall
  Host: 192.168.200.10 ... OPEN - Not a Powerwall
  Host: 192.168.200.51 ... OPEN - Found Powerwall 3 [Currently Unsupported]
  Host: 192.168.200.145 ... OPEN - Not a Powerwall
  Host: 192.168.200.213 ... OPEN - Not a Powerwall
  Host: 192.168.200.238 ... OPEN - Not a Powerwall
  Done

Discovered 1 Powerwall Gateway 192.168.200.51 [Powerwall-3] Firmware Currently Unsupported - See https://tinyurl.com/pw3support

jerry@AOBM Powerwall-Dashboard % python3 -m pypowerwall scan 1
/Users/jerry/Library/Python/3.9/lib/python/site-packages/urllib3/init.py:34: NotOpenSSLWarning: urllib3 v2 only supports OpenSSL 1.1.1+, currently the 'ssl' module is compiled with 'LibreSSL 2.8.3'. See: https://github.com/urllib3/urllib3/issues/3020 warnings.warn(

pyPowerwall Network Scanner [0.6.3] Scan local network for Tesla Powerwall Gateways

Your network appears to be: 192.168.200.0/24

Enter Network or press enter to use 192.168.200.0/24: 

Running Scan...
  Host: 192.168.200.1 ... OPEN - Not a Powerwall
  Host: 192.168.200.6 ... OPEN - Not a Powerwall
  Host: 192.168.200.10 ... OPEN - Not a Powerwall
  Host: 192.168.200.51 ... OPEN - Found Powerwall 3 [Currently Unsupported]
  Host: 192.168.200.145 ... OPEN - Not a Powerwall
  Host: 192.168.200.204 ... OPEN - Found Powerwall 3 [Currently Unsupported]
  Host: 192.168.200.213 ... OPEN - Not a Powerwall
  Host: 192.168.200.238 ... OPEN - Not a Powerwall
  Done

Discovered 2 Powerwall Gateway 192.168.200.51 [Powerwall-3] Firmware Currently Unsupported - See https://tinyurl.com/pw3support 192.168.200.204 [Powerwall-3] Firmware Currently Unsupported - See https://tinyurl.com/pw3support

jerry@AOBM Powerwall-Dashboard % python3 -m pypowerwall scan 1 /Users/jerry/Library/Python/3.9/lib/python/site-packages/urllib3/init.py:34: NotOpenSSLWarning: urllib3 v2 only supports OpenSSL 1.1.1+, currently the 'ssl' module is compiled with 'LibreSSL 2.8.3'. See: https://github.com/urllib3/urllib3/issues/3020 warnings.warn(

pyPowerwall Network Scanner [0.6.3] Scan local network for Tesla Powerwall Gateways

Your network appears to be: 192.168.200.0/24

Enter Network or press enter to use 192.168.200.0/24: 192.168.200.53/32

Running Scan...
  Host: 192.168.200.53 ... OPEN - Found Powerwall 3 [Currently Unsupported]
  Done

Discovered 1 Powerwall Gateway 192.168.200.53 [Powerwall-3] Firmware Currently Unsupported - See https://tinyurl.com/pw3support

`

stevecastaneda commented 7 months ago

python3 -m pypowerwall scan 0.5

Odd, this time it worked fine. I would say that 500ms felt quick so it may not be a bad idea just to buffer by another 100ms.

jasonacox commented 7 months ago

Thanks @jesaf00 ! Feel free to try something even higher... like 2, 5 or even 10. That would likely mean your connection (WiFi) isn't very strong or is dropping packets, but may be worth trying.

jasonacox commented 7 months ago

@mcbirse - I wonder if the solar-only daemon updates for tesla-history would automatically support PW3? They would use the tesla-solar option but use the standard dashboard.json (but remove the animation and other panels that won't populate). I believe al the Powerwall data is also pulled in via tesla-history (unless I'm reading it wrong) so PW3 users could at least start getting dashboard data.

jasonacox commented 7 months ago

I added a research discussion thread for /tedapi support (for PW2/+ and PW3): https://github.com/jasonacox/Powerwall-Dashboard/discussions/392

mcbirse commented 7 months ago

@mcbirse - I wonder if the solar-only daemon updates for tesla-history would automatically support PW3? They would use the tesla-solar option but use the standard dashboard.json (but remove the animation and other panels that won't populate). I believe al the Powerwall data is also pulled in via tesla-history (unless I'm reading it wrong) so PW3 users could at least start getting dashboard data.

Correct @jasonacox - anyone with a Powerwall system could install the dashboard using the "solar-only" option, and then use the standard dashboard.json - pretty much how I've been testing the whole solar-only offshoot.

All of the Powerwall power metrics should be pulled from the cloud, including backup events so grid status data is populated, and of course the analysis data will populate too (power flow animation and extended data, e.g. voltages, alerts, etc. will not however).

Can a PW3 user test installing the Powerwall Dashboard in solar-mode mode and see if it works? 🤞

Seems timely the solar-only offshoot has now been merged as a setup option just this week! 🚀

jasonacox commented 7 months ago

Thanks @mcbirse ! I was thinking the same thing (timely release of the solar-only setup that can work for Powerwall 3 owners)! If this works, we should update the script and README to include language that this supports Powerwall 3 (Tesla Cloud version).

@jesaf00 - I know you already installed the Powerwall-Dashboard. Would you be willing to test this?

Powerwall 3 Dashboard Setup

# Install Powerwall-Dashboard (if not already installed)
git clone https://github.com/jasonacox/Powerwall-Dashboard.git
cd Powerwall-Dashboard

# If already installed, remove old configuration
rm compose.env

# Run Setup
./setup.sh

You will see this:

  Powerwall Dashboard (v3.0.0) - SETUP
  -----------------------------------------
  Select configuration profile:

  1 - default     (Powerwall w/ Gateway on LAN)
  2 - solar-only  (No Gateway - data retrieved from Tesla Cloud)

For Powerwall 3 owners, select profile "2 - solar-only (No Gateway - data retrieved from Tesla Cloud)"

When you install the dashboard configuration file, you can use the default (dashboard.json). It will have some panels that don't work but after a while you should start seeing data populate.

Powerwall 3 - Load History

You an load the historic data from the Tesla Cloud into your dashboard as @mcbirse mentions, with something like this:

docker exec -it tesla-history python3 tesla-history.py --start "2023-01-01 00:00:00" --end "2024-01-01 00:00:00"