-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Powerwall 3 Local Access via TEDAPI #97
Comments
Thanks @ttl74ls100 ! I made the update. Starting with v0.10.0, you don't need to use this tool and can talk to tedapi via the library. I'll create an example and post it as well. |
Command Line ToolWith pyPowerwall v0.10.0, you can now run the TEDAPI tool via the command line (CLI):
It will prompt you for the Powerwall Gateway password (usually printed on the QR code on the gateway), and will then query the Powerwall for config and curren site data. It will display some and write entire payloads to
Using the LibraryThe following python script will connect to the gateway and display power data: # Import Class
from pypowerwall.tedapi import TEDAPI
gw_pwd = "THEGWPASS"
# Connect to Gateway
gw = TEDAPI(gw_pwd)
# Grab the Config and Live Status
config = gw.get_config()
status = gw.get_status()
# Print
site_info = config.get('site_info', {})
site_name = site_info.get('site_name', 'Unknown')
print(f"My Site: {site_name}")
meterAggregates = status.get('control', {}).get('meterAggregates', [])
for meter in meterAggregates:
location = meter.get('location', 'Unknown').title()
realPowerW = int(meter.get('realPowerW', 0))
print(f" - {location}: {realPowerW}W") |
Using a python:3.10-alpine container, I installed
Here are the version numbers from the install:
|
Thanks @ttl74ls100 - I can only replicate that if there is no route to the Gateway. I see where I need to adjust the code to help provide a clear message, but can you verify that you are able to ping / curl the Gateway (192.168.91.1) from that container host? |
I believe the gateway is working. For example, after the patch to
Could the issue be related to the 404 response? |
I should also highlight I am connecting to a Powerwall 3 |
@ttl74ls100 , I didn't expect this to work on the PW3! The fact that you got the first to work is a positive step. Thanks for helping test! 🙏 I updated the logic to give a bit more details to help diagnose: # First install the dev version
pip install pypowerwall==0.10.3.dev0
# Run again
python3 -m pypowerwall.tedapi
# Run with debug
python3 -m pypowerwall.tedapi --debug |
It worked.
Thanks for your help, Let me know if you need any PW3 testing. |
Excellent! Thank you, @ttl74ls100 ! It seems that the PW3 responds with 404 for the import pypowerwall
pypowerwall.set_debug()
# Set these
PW_HOST="192.168.91.1"
PW_GW_PWD="xxxxxxxx" # Your Gateway Password
pw = pypowerwall.Powerwall(PW_HOST, PW_GW_PWD ,gw_pwd=PW_GW_PWD)
# Get vitals - should work
pw.vitals()
# Get current power, level - likely will not work
pw.power()
pw.level()
# Get alerts - may partially work
pw.alerts() |
pw.vitals()
pw.power()
pw.level()
pw.alerts()
|
Thanks, @ttl74ls100 ! This is very helpful. I suspected we would see 404 for those calls but needed to confirm. I can build mappings from the tedapi to most of those calls. I'll work on something for you to try soon. |
Hi @ttl74ls100 - something for you to try: # First install the dev version
pip install pypowerwall==0.10.4.dev0 Simple Python test: import pypowerwall
PW_GW_PWD="GWPASSWD"
pw = pypowerwall.Powerwall("192.168.91.1", gw_pwd=PW_GW_PWD)
pw.power()
pw.level()
pw.battery_blocks() You can also try the pypowerwall proxy: docker run \
-p 8675:8675 \
-e PW_PORT='8675' \
-e PW_HOST='192.168.91.1' \
-e PW_GW_PWD="GWPASSWD" \
--name pypowerwall \
--restart unless-stopped \
jasonacox/pypowerwall:0.10.4t61-beta Try these URLs: |
Fantastic!!! Thanks for testing! 🙏
PS - if you want to test this with Powerwall-Dashboard, the manual steps:
|
Updated: the Powerwall-Dashboard will now provide an option to install for Powerwall 3 using the local gateway option. If you install and run |
I have a static route setup in the gateway/router (UniFi UDM) to the primary PW. The production Powerwall-Dashboard instance is running on a Proxmox VM and currently the I am using WSL on a Windows machine for I'll stand-up another instance of Powerwall-Dashboard using local access and let you know how it goes. |
Looks great @ttl74ls100 !! The Powerwall Capacity graph is puzzling. Can you show the results of http://localhost:8675/api/system_status ? It should have the capacity data. If it does check: http://localhost:8675/pod which is what the Dashboard is polling. It should list the different PW data points like |
/api/system_status {
"command_source": "Configuration",
"battery_target_power": 0,
"battery_target_reactive_power": 0,
"nominal_full_pack_energy": 28840,
"nominal_energy_remaining": 10570,
"max_power_energy_remaining": 0,
"max_power_energy_to_be_charged": 0,
"max_charge_power": null,
"max_discharge_power": null,
"max_apparent_power": null,
"instantaneous_max_discharge_power": 0,
"instantaneous_max_charge_power": 0,
"instantaneous_max_apparent_power": 0,
"hardware_capability_charge_power": 0,
"hardware_capability_discharge_power": 0,
"grid_services_power": null,
"system_island_state": "SystemGridConnected",
"available_blocks": 0,
"available_charger_blocks": 0,
"battery_blocks": [],
"ffr_power_availability_high": 0,
"ffr_power_availability_low": 0,
"load_charge_constraint": 0,
"max_sustained_ramp_rate": 0,
"grid_faults": [],
"can_reboot": "Yes",
"smart_inv_delta_p": 0,
"smart_inv_delta_q": 0,
"last_toggle_timestamp": "2023-10-13T04:08:05.957195-07:00",
"solar_real_power_limit": null,
"score": 10000,
"blocks_controlled": 0,
"primary": true,
"auxiliary_load": 0,
"all_enable_lines_high": true,
"inverter_nominal_usable_power": 0,
"expected_energy_remaining": 0
} /pod {
"time_remaining_hours": 11.0975932293044,
"backup_reserve_percent": 33.5
} |
Thanks @ttl74ls100 !
Ugh, there is the problem. For previous Powerwalls, we have an entry there for each Powerwall. Can you look at http://localhost:8675/tedapi/status and see if you have entries for 'esCan' -> 'bus' -> 'THC'? That is what builds the battery_block data. I wonder if it is missing data or a code problem. Also, the latest beta release I'm testing adds api locking which should help with overloading the /teadpi:
It may also be good to see what you have in your logs:
|
Status has a
Here is
docker logs pypowerwall
|
Thank you @ttl74ls100 - Sadly that is what I feared. The energy levels are not showing for Powerwall 3s. However, I can pull the aggregates and include them in the /pod API. Update to:
Edit the "Powerwall Capacity" graph you can add the total battery capacity and remaining metrics, you can create these queries: If you have a chance to try it, let me know how it work. Thanks again for all your help! |
Hi @ttl74ls100 - One thing we are missing for PW3 is the Firmware Version. It is not included in the TEDAPI payloads. Could you run this test for us? I suspect it is still a 404, but I would like to verify.
If anyone else finds an API to get the firmware version of a PW3, let us us know. |
404 |
Thanks @ttl74ls100 ! Bummer, but as I expected. I'll keep hunting... :) |
Just throwing my hat into the ring here as well, I have 4 PW3's (1 leader, 3 followers) and a AC Coupled Solar (Enphase) system, if any different requests are of use. Also happy to setup a shell if you want to get access to poke about. |
Thanks @welbymcroberts - There is also a discussion here where a new API has been found: jasonacox/Powerwall-Dashboard#392 (comment) I'm traveling this week so limited on what I can explore but it does look promising if we can find a way to unlock it. |
@welbymcroberts If you are interested in helping test, we are exploring a query that may give more PW3 data mentioned in the link above. You can test the script: https://github.com/jasonacox/pypowerwall/blob/main/tools/tedapi/ComponentsQuery.py (also requires downloading tedapi_pb2.py ) |
Found the PW3 firmware version!
Sample response.
|
This is awesome @geptto ! Thank you! 🙏 I created a test to get the firmware version:
My Powerwall 2/+ doesn't have some of the PW3 elements so I will be missing (404) some items, but I am getting the Firmware version:
|
I updated my Production Powerwall-Dashboard to use local access for the Powerwall 3. It works great. Thanks for all the work. I am having a strange occurrence. About once a day, data collection stops. Here is a sample from the
So here is the strange thing.... The following three commands resolves the problem and data collection resumes (without restarting any containers)
I have a static route setup in my Unifi router for 192.168.91.0/24 to 10.20.20.116. No other special network configuration other than the machine is a VM in Proxmox. I'm not sure how to diagnose this. I did have the idea to try to set |
Hi @ttl74ls100 , thanks for the report! I can't think of an easy fix, but see a few things here that might help with troubleshooting:
This is helpful. This is indicating either a network issue or the Gateway itself is in a bad state (like a server over loaded and can't respond). The fact that you can get a 404 on the LAN address seems to indicate that the Gateway web server is fine. That would point me towards this being a network issue (which includes everything from the VM, host, switch, router, firewall, etc). A few thoughts:
I agree, this is odd. Again, could it be the host? I would try:
I would love to hear if anyone else has ideas or is seeing the same thing. |
I had local access to PW3 working fine for about a week and a few days ago I started to run into the same issue mentioned here where it will randomly stop logging for a while. pypowerwall log shows: Max retries exceeded with url: /tedapi/v1 (Caused by ConnectTimeoutError(<urllib3.connection.HTTPSConnection object at 0x7f26e7ac6380>, 'Connection to 192.168.91.1 timed out. (connect timeout=5)')) If I notice it happening and just run a ping to 192.168.91.1 it will seem to make it start working again, or else it will randomly start working by itself a few hours later. @ttl74ls100 - did you ever get a resolution to this? |
Just to add more info, I have a Windows 11 host and I have a permanent route setup from the host. When I notice it occurring and run a ping to 192.168.91.1 the first few requests will time out until it suddenly starts working again. |
Thanks @leesamtao - The ping timeout does indicate a network issue. It is good that it eventually recovers, but why does it happen? I had issues were my PW would disappear from my network for 1-5m randomly throughout the day. I was using WiFi and figured my wireless router was just having trouble reaching the PW as it is the furthest device on our network, even though the signal strength looked good. Anyway, I switched to using a hardwired ethernet cable to the Powerwall and all those problems went away. Others report solid performance with WiFi so I suspect it has something to do with my WLAN, house geometry or the wifi lottery I got with the PW. ;) |
I'll keep looking into the network issues, though everything seems to function fine the whole time, just stops responding on 192.168.91.1 randomly, unfortunately hardwired ethernet isn't an option for my setup. Could there be an option for powerwall dashboard to pull the main energy data from the cloud since that seems to always work for me, but still pull the string data/vitals from the local access? If the string/vitals data goes out occasionally that's less an issue than missing hours of energy data randomly. |
@leesamtao I really do not know the root cause but can share some additional observations. I was having the drop-outs frequently (~ 1 per day), that resolved after I stopped my test environment that was also polling the same PW. I have not experimented to see if adding it back will cause the problem to return. I can reproduce the problem by restarting the access point used by the PW3. After the reboot I get the symptoms above (logging stops due to timeout errors, ping the PW3 IP, logging resumes). This happens any time I power down or apply firmware updates to the access point. I saw the same thing when the PW3 went offline for a minute one day, I assume to update its firmware. So, for me it is currently a matter of remembering to do the "ping fix" when I do maintenance on the network. I've considered a cron job to ping the PW3 IP every few mins to fix those times I do not notice right away. Given how easy it is to reproduce, I can do some diagnostic work if anyone has suggestions. I tried a few things but was unable to find anything unusual. |
This could be an arp issue if a simple ping resolves it. Are you setting the route to 192.168.91.1 on the host or via your router? If via the host, you might try refreshing the arp with |
Thanks for the additional info. Still happening typically once or twice a day, no pattern on the timing that I can identify. I did confirm it seems to only occur from my host windows machine. I can ping the powerwall from other machines without issue when it occurs. Pinging the powerall ip from the host machine has always fixed it once it occurs. Refreshing the arp table doesn't seem to change anything. Also tried a new static ip for the powerwall, same thing occurs. So it seems to be something with my windows host networking, but just at a loss for what it could be. Possible something with my router, as my host is the only ethernet connected device on my network. |
Thanks for the update @leesamtao . I don't use Windows, so I'm not going to be any help unfortunately. We do have some Windows gurus in the community that may chime in with some suggestions. |
can anyone confirm if this works with the "gateway 3"? |
pypowerwall/tools/tedapi/tedapi.py
Line 111 in 706afaf
Ubuntu, python3, Powerwall 3 x 2, using static route to PW
command line
python3 tedapi.py
Enter password
Result:
Request returns 404, which is expected.
Added line with comment
# no exception, so the request was successful
and script ran successfully.The text was updated successfully, but these errors were encountered: