Open jasonacox opened 2 weeks ago
Hi @pavandave, thanks for the details! I'm opening an issue here to track the fixes.
It appears that your setup is trying to log in using the PW2 credentials instead of sticking with the TEDAPI full
mode via the GW credentials only. That will cause the API rate limiting. That would also mean that it is running in hybrid
mode (you can see what tedapi_mode it is using by going to http://localhost:8675/help).
Please check your pypowerwall.env
and make sure that these two lines are empty (nothing to the right of the = sign):
PW_EMAIL=
PW_PASSWORD=
If not, remove the email and password, save the file and run ./compose-dash up -d
As to the failure of the setup.sh
- would you mind running a test? The setup.sh script has this curl test to see if the PW Gateway is available. Create a file like this and give it a run:
# Function to test an IP to see if it returns a ping
function test_ip() {
local IP=$1
if [ -z "${IP}" ]; then
return 1
fi
if curl -k --head --connect-timeout 1 --silent https://192.168.91.1 > /dev/null 2>&1; then
return 0
else
return 1
fi
}
# Can we reach 192.168.91.1
if test_ip "192.168.91.1"; then
echo "Found Powerwall Gateway"
else
echo "Failed"
fi
And just for full measure, can you also run: ping -c 1 192.168.91.1
?
Thanks for your help! I want to get the fixes in to help other PW3 owners.
@jasonacox
Updated the env file per your recommendation. I had used the template info but updated to the below and redeployed and that worked. This may just be me, but for PW3 stuff while folks are still figuring it out, maybe a note in docs that PW3 config file differs and should have nothing in for email/pass may be helpful.
Example of working env config:
PW_EMAIL=
PW_PASSWORD=
PW_HOST=192.168.91.1
PW_TIMEZONE=America/Chicago
TZ=America/Chicago
PW_DEBUG=yes
PW_STYLE=grafana-dark
PW_GW_PWD=<REDACTED>
Output of the help file url:
Stat | Value
-- | --
pypowerwall | 0.10.6 Proxy t63
mode | Local
gets | 437
posts | 0
errors | 0
timeout | 0
ts | 1718846081
start | 1718845771
clear | 1718845771
uptime | 0:05:10
mem | 39852
site_name | My Home
cloudmode | False
fleetapi | False
tedapi | True
tedapi_mode | full
siteid | None
counter | 0
authmode | cookie
URI: /version | 1
URI: /soe | 62
URI: /temps/pw | 62
URI: /strings | 62
URI: /alerts/pw | 62
URI: /aggregates | 62
URI: /freq | 62
URI: /pod | 62
URI: /help | 1
Screenshot of working dashboard:
I re-ran the setup.sh file and it worked but I think having that env file bypasses that check. If you want me to re-run without any credentials I can but when it comes to pinging 192.168.91.1 I found some strange behavior. From the WLS shell, I don't get a response.
PING 192.168.91.1 (192.168.91.1) 56(84) bytes of data.
--- 192.168.91.1 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
BUT from Windows terminal, I do,.
>ping 192.169.91.1
Pinging 192.169.91.1 with 32 bytes of data:
Reply from 192.169.91.1: bytes=32 time=7ms TTL=244
Reply from 192.169.91.1: bytes=32 time=5ms TTL=244
Reply from 192.169.91.1: bytes=32 time=4ms TTL=244
Reply from 192.169.91.1: bytes=32 time=4ms TTL=244
Ping statistics for 192.169.91.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 4ms, Maximum = 7ms, Average = 5ms
I'm not sure why this is differing on the same machine. But if option 4 is selected, I would consider getting rid of the ICMP repsonse check check in the PW3 scenario. Maybe run an API call to see if it returns a valid response, if not have the user validate their network or password (depending on the response).
Let me know if this helps or you would like me to test any further. I will gladly assist where possible.
Fantastic!
Can you try importing dashboard.json
to see if that works? That is the default recommended during setup. I notice you are using the dashboard-no-animation.json version. Or, alternatively, can you try this and post the results? http://localhost:8675/example.html
Also, on the ping, you are correct. I had a few others mention that ping was bad. It is actually using curl
as part of these setup.sh test. Can you run this in WSL?
curl -k --head --connect-timeout 1 https://192.168.91.1
Interestingly I finally got some ping responses from WLS but I just saw it this morning but it's not something promising.
--- 192.168.91.1 ping statistics ---
37236 packets transmitted, 26768 received, +13 errors, 28.1126% packet loss, time 37803487ms
rtt min/avg/max/mdev = 0.784/2.855/2115.668/28.530 ms, pipe 4
The curl command gives me this:
$ curl -k --head --connect-timeout 1 https://192.168.91.1
HTTP/2 404
content-type: text/plain; charset=utf-8
x-content-type-options: nosniff
content-length: 19
date: Thu, 20 Jun 2024 13:27:36 GMT
As for the core dashboard, I took the screenshot from the wrong dashboard. It works. I fiddled with something that turned the power flow into a white box for now but that's on me and I do see the main data I want to see.
I plan on migrating the dashboard to another machine soon. Will follow up with any additional feedback from there.
One interesting note about the power flow animation: If you have another browser window/tab open with that, only one of them will display at a time. I'm not entirely sure why as you can bypass it by using a different browser (e.g. Chrome and Edge) and they will both render.
Anyway, thanks for the posting these and your PR. I have some comments but will leave them in the PR.
One interesting note about the power flow animation: If you have another browser window/tab open with that, only one of them will display at a time. I'm not entirely sure why as you can bypass it by using a different browser (e.g. Chrome and Edge) and they will both render.
Anyway, thanks for the posting these and your PR. I have some comments but will leave them in the PR.
I'm not sure when it changed, but I can now open two tabs with both showing the animation in Chrome on my Chromebook. I thought it might be because I'm running Grafana 10.3.1, but I just tried opening the default Grafana 9.1.2 dashboard and it sometimes works depending on the sequence of what I do.
I'm not sure exactly what's going on, but in an Incognito window I can reliably open 2 tabs but the third fails to display the animation. A second ago I had the animation showing in one regular tab and two incognito tabs at the same time.
I just tried it in Edge under Windows 10 and was able to open the dashboard with animation in two regular and two InPrivate tabs at the same time. A third tab of either type shows a blank animation.
Interesting! Thanks @youzer-name - the same would occur with the example iframe built into pypowerwall: http://localhost:8675/example.html so I don't think this is a Grafana issue. I should look again to see if there is a better way to handle it.
I have a Powerwall3 and finally got time to spin this up. Running this all on W11 with WLS running Ubuntu. My PW3 is hardwired.
My experience is as follows:
Next. The main setup with option 4 didn't work for me. It could not find the gateway. Because the test above worked, I know my machine can get to my PW3. I had to create the pypowerwall.env file and then I re-ran through the setup with option 4 and was able to complete.
Went through rest of the guide but wasn't seeing anything on Grafana. Looked at docker logs and see that I am getting some information:
So we know I'm getting data and able to connect, but then I hit various excedptions and api rate limits:
Let me know if this helps or if you would like some more debugs from anything.
Originally posted by @pavandave in https://github.com/jasonacox/Powerwall-Dashboard/discussions/392#discussioncomment-9821192