Replies: 94 comments 501 replies
-
|
Yes! It appears that this was one of the features of this upgrade. I see others reported it on Reddit including someone saying that it used to do this in the past (slow charge after 95%) but that it was dropped about a year ago until this 'foxtrot" version brought it back. I do find the "drops" to be interesting. That seems more like a computational error on % capacity than a reasonable behavior of the battery.
|
Beta Was this translation helpful? Give feedback.
-
|
Another example... It seems like at 95%, it slows the charge significantly, 22% of what it was before. At each percentage point, it seems to drop even more (bends happening at 96% and 97%. But at 98% it jumps to 100%.
I'm not sure if this will help long term battery degradation but at least in my case, the slope has been flattening as new firmware version come out.
|
Beta Was this translation helpful? Give feedback.
-
|
I haven't seen this behaviour yet (or in the past either) - my system is still on firmware 22.18.3 21c0ad81. It does seem odd with the sudden drops and I agree, it seems like a calculation error on the charge level, which likely updates once load is applied to the battery again. Regarding the charge percentage drop to zero during firmware updates as seen in @cwagz's graph - I have been meaning to suggest a proposed change to pypowerwall around this, but haven't gotten around to it. I have observed (and have logged data) that during a firmware update, the local gateway will still respond to certain requests (i.e. soe & aggregates) but it returns a value of zero for all measurements while the firmware updates. Interestingly, requests for other data like freq or battery temperature, do still return valid values (not zero) or simply you do not receive a response. Personally I think it would be better if pypowerwall detected this (could be simple, i.e. if charge percent and all aggregate measurements = zero), and then does NOT return data. Returning zero value data points causes some issues... noted recently in #103 which is when I started some investigating. @jasonacox - thoughts? I could raise this as an issue in pypowerwall perhaps if you agree. |
Beta Was this translation helpful? Give feedback.
-
|
It's a reasonable idea @mcbirse. Thanks for raising it. However, my concern is that the "zero" data is a correct representation of the response from the Powerwall Gateway (which Tesla could someday change themselves). Since the pyPowerwall library is an API for the Powerwall, the expectation is that it delivers accurately what Tesla is saying. While not altering the API itself, I would entertain adding this augmentation logic to the pyPowerwall Proxy that Powerwall-Dashboard uses with a configuration setting that would cause it to produce "None" responses during a detected firmware upgrade event. Of course, if Tesla changes the pattern where all measurements drop to zero during upgrades it would stop working. It could be a moving target. 😜 It may be better to use the authoritative upgrade signal (alert or some vitals setting?) and key off of that. |
Beta Was this translation helpful? Give feedback.
-
|
I think you're right... the "zero" data is a correct representation of the response. And knowing Tesla, they could very well change the behaviour of the responses in the future, so it's probably not worthwhile trying to second guess and filter responses. From checking my data, it appears the "zero" responses are for a short period only during a firmware upgrade (5 minutes). As per #103 it is fairly easy to delete these data periods if they are not wanted. I guess if there was demand for this it could be looked at further. |
Beta Was this translation helpful? Give feedback.
-
Firmware 22.26.2This version seems to have fixed the slow charging issue with the Powerwall. With version 22.26.1, it started trickle charging at around 85-90% and would never get above 95%. With this new version it charges up to 98% and then starts trickle charging at 0.7 kW to the final 100%.
|
Beta Was this translation helpful? Give feedback.
-
|
On a related note, @jasonacox could we add firmware version tracking to the database and dashboard? |
Beta Was this translation helpful? Give feedback.
-
|
I really like that idea @longzheng ! |
Beta Was this translation helpful? Give feedback.
-
|
The latest dashboard nows shows current Firmware version.
It is not getting stored in InfluxDB but we could add a telegraf call for http://powerwall:8675/version |
Beta Was this translation helpful? Give feedback.
-
Firmware 22.26.4
This version seems to have changed the pattern for Powerwall charging from solar. I set the reserve limit to 90% to drive all solar energy to the Powerwalls for charging. I noticed that the Powerwall charging plateaued at 3.6kW and the additional solar power displaced grid usage despite not being at the PW reserve limit. I wonder if the new firmware is limiting charging to 1.8kW per Powerwall to extend life of the battery? Does anyone else see this?
To early to see if this would actually help slow battery degradation. In the past year since I have been recording capacity, the degradation has slowed. I don't know if that is related to these software updates better managing the life of the PWs:
|
Beta Was this translation helpful? Give feedback.
-
Firmware 22.36.4Mine just updated to 22.36.4 71cc31f1 at 4:12pm today. I'm in Melbourne Australia and I'm on Tesla's VPP called the Tesla Energy Plan in Australia. The STSTSM firmware is Has only been a few hours so don't notice anything new. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @longzheng ! Others are reporting the upgrade and have pasted their Alerts here: #158 (comment) Did you see anything new/unusual on your Alerts panel in the dashboard (if you have it installed)? |
Beta Was this translation helpful? Give feedback.
-
|
These are my alerts
Nothing new/unusual compared to the other user. |
Beta Was this translation helpful? Give feedback.
-
Firmware 22.36.6 (and rollback to 22.36.4)
Observations
Upgrade Alerts
|
Beta Was this translation helpful? Give feedback.
-
|
I should also mention: Today was kind of crazy for our solar production, because clouds were in and out. And we were getting high numbers sometimes due to cloud reflections. For example, we peaked at about 6.67 kw, but for this time of year we normally peak around 5 kw. I wonder if that somehow caused a false arc fault.
|
Beta Was this translation helpful? Give feedback.
-
|
The system has been running fine for the last few days until this afternoon. We have had clouds in and out all day - sometimes very high solar output from cloud reflections. We got 5 arc faults and on the fifth one, the solar is locked off on the pw+. Our old solar system still working OK. About 10 months ago when the pw+ system was about one month old, we also had the solar lockout due to arc faults. Then there was no problem after they upgraded firmware. Now we have this new firmware 22.36.4 and seeing the arc lockout again. Not sure yet if this is due to new firmware or not. Later I will reset the arc lockout and see how it goes. |
Beta Was this translation helpful? Give feedback.
-
|
Wow! I do love the visibility the Alert graph gives us. But that still feel a bit like a hardware issue to me. Strange how it happens for all the PVS data points at the same time. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, that Alerts logging and display is awesome! Now I know that it takes 5 arc faults to cause a PV lockout. I reset the lockout at around 3 pm yesterday and it worked fine after that. I am currently thinking that the arc faults are from sudden changes in current due to cloud movement and reflections. When I got the first PV lockout last year due to arc faults, it was also a cloudy/sunny day. Last night there were several other alerts I had not seen before - mainly for checking the system. All is well today. My pw+ solar has two strings of six 400w panels each. The string current for both when the arc faults occurred are in lock step, as usual. String A always has just a bit more power output. Last night I did some tug tests on the wires in the pw solar disconnect and pw inverter and all looked good. Here is the string current for the time when the arc faults occurred yesterday: What I don't know is if the recent firmware update made arc faults more sensitive or not. For about 10 months, I had no PV lockouts and as I mentioned before, the Tesla techs at that time said there was a known firmware problem causing false arc faults and my firmware had been upgraded. Thanks to the Powerwall Dashboard, I can now keep track of a lot more data, especially the alarms. |
Beta Was this translation helpful? Give feedback.
-
|
Today we had dark clouds and rain all morning. There were sudden spikes when it got sunny off and on in the afternoon. One arc fault occurred at 3:30. After 5 minutes, it turned back on at 430 watts, then after 15 more minutes it went back to full power (about 3.5 kw at the time). There were more spikes later but no more arc faults.
Will see if I get 22.36.7 tonight. I live in Rancho Mirage, CA (about 7 miles east of Palm Springs) - the desert - and dark clouds and sun are rare here. This year it had been nice to get some decent rain for a change. |
Beta Was this translation helpful? Give feedback.
-
|
Where can I find a description of the Alerts? |
Beta Was this translation helpful? Give feedback.
-
|
Unfortunately there isn't anything official from Telsa but the community has gathered a list based on experience: https://github.com/jasonacox/pypowerwall#devices-and-alerts |
Beta Was this translation helpful? Give feedback.
-
|
For that alert page, I think POD_w058_SW_App_Boot alert is used to autostart a generator. I'm offgrid with two powerwalls and a generator and autostart is configured to come on at 25% charge and off at 50% charge. I see this alert fire whenever that happens and it lasts for the entire period of the purple line "SystemConnectedToGrid" (grid for me is generator).
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks @rvry - I added this note to the Alert list on pypowerwall.com. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for pointing out. |
Beta Was this translation helpful? Give feedback.
-
|
I'm not sure which version 22.36.4 or 22.36.6 added this but I noticed there's a new graphic/link on the Powerwall Gateway login screen for the Tesla Pro app
The Android app is here https://play.google.com/store/apps/details?id=com.tesla.teslapros |
Beta Was this translation helpful? Give feedback.
-
|
Good find! Telsla Energy Setup - Upgrade NowThere's a better way to set up Powerwall Step 1: Disconnect from the TEG Wi-Fi network
Step 2: Tap the button below to download Tesla Pros Improvements include:
|
Beta Was this translation helpful? Give feedback.
-
Firmware 22.36.722.36.7 is out now. |
Beta Was this translation helpful? Give feedback.
-
|
Even today, I am pulling down around 18A at peak production on the Tesla system, so if only using one MPPT rated at 13A max, it would seem that it would fry or shutdown. But all is working perfectly. I wonder if one MPPT can actually handle 18A. Just now I measured voltages on the jumper terminals in the inverter. From any negative terminal (1-, 2-, 3-, 4-) to 1+ or 2+, I get the expected voltage of around 210 VDC. So it seems like the negative jumpers are connected together internally. But then why are jumpers needed, as @jasonacox mentioned. Maybe just to carry more current? |
Beta Was this translation helpful? Give feedback.
-
|
Forgot to mention that there was 0 volts between the negative terminals, such as one with a jumper and one without. |
Beta Was this translation helpful? Give feedback.
-
|
Just had a Gateway lockup with 22.36.7...hopefully they push 22.36.8 soon. |
Beta Was this translation helpful? Give feedback.
-
|
The jumpers are to bond the positive terminals, I don’t think necessary for negative as all are common rail. But if paralleling mppt’s you need to tell Inverter that the mppt’s are bonded. Or the mppt’s will hunt individually fighting each other. |
Beta Was this translation helpful? Give feedback.
-
|
@anderep Thanks for the info. Is -2 connected with -3 on the common rail? Or is -1 connected to -2, and -3 connected to -4? See my posts below. I did measure a tiny voltage between -2 and -3 after I fixed the negative jumper. After I connected the negative jumpers according to the installation instructions, I have not seen any arc faults yet. Also, when Tesla came out to check it (after I had fixed the jumper), the lead technician said that the negative jumper did need to be fixed (as I did) - and nothing should be jumpered between 1or 2 to 3 or 4. Hopefully the inverter is configured correctly, as you mentioned. Do you have a schematic for the inverter? We would love to see it! |
Beta Was this translation helpful? Give feedback.
-
Firmware 22.36.8
Firmware updated today - I Only new alert was "Battery Unexpected Power" but that could have been due to the timing (highest production time of day with 100% Powerwalls and pushing to Grid).
|
Beta Was this translation helpful? Give feedback.
-
|
I wonder why they don’t push these at like 2am. |
Beta Was this translation helpful? Give feedback.
-
|
I also see
|
Beta Was this translation helpful? Give feedback.
-
|
Agree @cwagz ! Thanks @longzheng - not sure what it means. |
Beta Was this translation helpful? Give feedback.
-
|
Yes the jumper is in the wrong spot. I have one of my jumpers as well incorrectly setup. You can fix this your self quite easily with a screwdriver and at night. Wait until the sun has fully set and it’s dark use a screw driver to push in the 3 terminal and move to the 1 terminal. |
Beta Was this translation helpful? Give feedback.
-
|
@robot498 I would love to see a schematic of the inverter. It sure appears all the negative terminals are common. If they weren't tied together inside the inverter, then MPPT1 would have never worked since it wasn't a complete circuit. The jumper could be a redundant path and help spread the current. A schematic could answer most of these questions. |
Beta Was this translation helpful? Give feedback.
-
|
@jgleigh: Yes, it would be great to see that schematic! I am still suspicious of firmware changes, too. Last year the Tesla techs knew about a false arc fault problem in firmware. When they came out, they just checked that the firmware was the latest and that the diagnostics passed. At the time, I did not know the PV lockout was after 5 arc faults (I thought it was after one). So I don't know if I had any arc faults but no lockouts after they left. The recent problems started after the 22.36.6 firmware update. A lot of unknowns! |
Beta Was this translation helpful? Give feedback.
-
|
Today I was looking around on the web for more information about the inverter jumpers - I happened to see a picture of someone using a clamp meter in the inverter. I have one and today I put it on the jumper from 1+ to 2+. It measured slightly less than half of the incoming current from the parallel strings, which makes sense - that is the current flowing to MPPT 2. So before I changed that negative jumper, I could have done the same check to see if any current was flowing into MPPT 2. I may put the jumper back and try that, but since all is working well, not sure I want to change anything now. It's not so easy to pop the jumper pin using the screwdriver, and it would be terrible luck to break something. Today I did measure millivolts between some jumper terminals: The system has been flawless since changing the jumper and there were two heavy cloud spike days since then, but time will tell. I may end up telling Tesla after next week not to come out since there is not much they could do, unless I see some arc faults in the coming week. |
Beta Was this translation helpful? Give feedback.
-
|
I agree. I looked at the wring from the connector board where you have plugged in the solar wires and the 7 wires going to the actual inverter board. On my box there are 4 red and 3 black. My guess is that 1 and 2 are separate negatives and 3 and 4 are shared negatives. |
Beta Was this translation helpful? Give feedback.
-
|
Just to follow up: A Tesla crew came out today (I had decided not to cancel the appointment to fix the MPPT jumper). I told them the situation about arc faults and that I already fixed the incorrect MPPT jumper connection. Immediately the lead technician said that was the correct thing to do. The entire crew seemed very knowledgeable. I displayed a couple of screens from Powerwall Dashboard showing the arc faults and PV lockout that occurred on March 20, and also showed some cloud spikes on days after fixing the jumper when there was no problem. They checked the inverter wiring and also went up on the roof to check connections for any evidence of arcing - non was found. I was pleased with the service they did today. Yesterday was another good test: dark clouds and bright sun. At one point I saw 24 amps coming down from my 2 pw+ six panel strings (normally peaks 19 - 20 amps this time of year), and there were no arc faults or any other problems. |
Beta Was this translation helpful? Give feedback.
-
|
Looks like they added the PW versions to the release notes also. Guess we should be seeing 23.4 releasing soon. https://www.tesla.com/support/energy/powerwall/mobile-app/software-updates |
Beta Was this translation helpful? Give feedback.
-
Firmware 22.36.9
Only issue I saw was the power flow animation panel had an "Aw, snap!" error and required a refresh. I don't know if this was was a browser issue or if the recent iframe updates made it more brittle during upgrades. I would love to hear if anyone else experiences an issue. |
Beta Was this translation helpful? Give feedback.
-
|
Just got a MciOpen at noon. This 22.36.x series has had more weird issues. |
Beta Was this translation helpful? Give feedback.
-
|
And again today! 🤬 |
Beta Was this translation helpful? Give feedback.
-
|
Just FYI: I have only been seeing MciOpen on my system in the morning about 7 am, when it looks like it is checking rapid shutdown. Here are today's alarms so far, but I checked previous days and see the same thing.
|
Beta Was this translation helpful? Give feedback.
-
|
Yeah something is off and it's doing its daily checks at noon instead of early in the morning. I'm going to try a full system reboot tonight to see if it clears itself. |
Beta Was this translation helpful? Give feedback.
-
|
Looks like it's reverted to the 7 am health check. Not ideal but better than noon. |
Beta Was this translation helpful? Give feedback.
-
|
Given you already have the RPi in the mix, I have been quite successful running the pypowerwall proxy piece on an RPi that is in the neighborhood of the primary PW, then running everything else for the dashboard and my own code requests elsewhere in the household making the proxy requests to that box. Even with debug logging on and running in a container, the load on the RPi is pretty low. |
Beta Was this translation helpful? Give feedback.
-
|
I too suffered the latest Tesla Powerwall 3 update and loss on ethernet connectivity to the TEDAI stats. Love the simplicity of this software and enables access to more frequent updates compared to the Teslemetry subscription. |
Beta Was this translation helpful? Give feedback.
-
25.10.4 with a Travel Router Bridgetl;dr if you don't want to putz around with Pis and USB WiFi cards, you can use a travel router as a standalone WiFi-to-WiFi (or WiFi-to-ethernet, if you prefer) bridge. Unfortunately I caught the new firmware version with the access cut-off about 12 days ago, and had to sit sadly with no data coming in until I found some time. I didn't want to bother with dealing with the WiFi connection to the PW from the machine I'm currently running pypowerwall on, and definitely not anything with USB WiFi cards. It's on a Pi now, but I'll ultimately be moving it to my main Docker server, and I really didn't want to be fiddling around with networking on the same machine. Instead, I picked up the GL.iNet GL-SFT1200, a fairly inexpensive travel router. I had its bigger brother kicking around in my travel bag already to extend hotel/AirBnB/cafe networks with VPN behind it for travel, so the hardware is decent. It runs OpenWRT - it has a nice GUI in front, but for advanced stuff you're in OpenWRT. I don't have any ethernet ports near where I'd want the thing to be able to reach the PW's WiFi, so I did end up setting it as a WiFi-to-WiFi bridge of sorts. In the GUI, I set the TeslaPW network as the WAN connection. Through the regular OpenWRT UI, I was able to use the second radio to connect to my primary WiFi network and set the interface to get an IP over DHCP (with static lease). At that point, the bridge has an IP address on the same LAN as whatever you're running pypowerwall on, so you can point your route to that as the next hop for 192.168.91.1 and things should pop right back in. I do like this approach quite a bit for my use case, because it's very self-contained for the networking portion, and I just end up with a static IP on my network that I can point at without anything else needing to know what's happening. If you're doing WiFi-to-WiFi, it has pretty decent antennas so you can place it wherever there's overlap between both networks and a power outlet. It also looks pretty slick, so low jank-factor. If you're following for WiFi-to-WiFi, make sure to check out youzer-name's trick for making sure it doesn't delete one of the WiFi connections on reboot.
|
Beta Was this translation helpful? Give feedback.
-
|
@Nexarian Actually I couldn't figure out your script but this is all I needed for my setup: sudo iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE |
Beta Was this translation helpful? Give feedback.
-
|
@mccahan I'm really struggling here. I feel like I've got it 90% configured, but there's one thing missing I can't figure out what it is. My primary difference from your post is that I'm not doing wifi-wifi, I'm doing wifi-lan. I got a GL-SFT1200 and did the following:
Pinging 192.168.91.1 produces a timeout. What on earth did I miss? I'll gladly write a step by step for this wifi-lan option if we're able to get it working. Thanks so much to everyone in this thread for posting such helpful write ups on various successes in getting reconnected to TEDAPI. |
Beta Was this translation helpful? Give feedback.
-
|
This thread is getting pretty long, so you may not have seen my post where I set up an Opal router from Ethernet (LAN) to WiFi (TEG network). See here: #109 (reply in thread). I'm not clear from your bullet points what firewall zone your TEG connection is in and if you've added the firewall rules that may be needed to allow traffic between that and the LAN. I went the route of having the WWAN and LAN in separate firewall zones and created firewall rules to allow the traffic between them. I also had to disable the internet connectivity check on Opal in the Multi-WAN settings to keep it connected to the TEG network, as it was trying to ping the internet through the TEG network which obviously won't work. There is more than one way to set this up, but I think my post is detailed enough that if you want to copy my working setup, all the steps should be there. |
Beta Was this translation helpful? Give feedback.
-
|
I reset to defaults and followed your steps and I'm now back in business with full vitals reporting in PWD. Thanks so much, @youzer-name |
Beta Was this translation helpful? Give feedback.
-
|
@cstout1 - Were there any missing steps in my post or anything that didn't work? If not, I'll copy it out of this thread and post it under its own discussion topic to make it easier for others to find. The Opal or other GL-iNet devices seem to be a popular choice for setting up the bridge, so it might be good to have a stand-alone post with a working ethernet to WiFi setup. |
Beta Was this translation helpful? Give feedback.
-
|
Kudos to @mccahan. My PW3 w/expansion pack was upgraded to 25.10.4. Added a GL.iNet GL-SFT1200 ("Opal") positioned about 10 feet from the PW3 which is other side of a brick wall (WiFi connected), signal strength is fine. In my case I have Ethernet near the Opal so configured a static IP on the LAN side (192.168.0.240) and as a client on the PW3 side (aka "Internet" on the Opal). Disabled LAN side WiFi as it is not needed. I run Powerwall-Dashboard in a Proxmox VM (Debian 12) on a server elsewhere on my LAN. In that VM I added a permanent static route: Working fine, hopefully low/zero maintenance. Screenshot from Opal's OpenWRT Status page (irrelevant sections removed): |
Beta Was this translation helpful? Give feedback.
-
|
I've had some connection issues with my router's direct connection to the TEG network. I'm using a GL-iNet MT6000 and running the 2.4 GHz radio as both a client to the TEG and an AP for my IOT network. I bought an Opal travel router to see if I could use that instead. I'm not a complete noob when it comes to OpenWRT or networking, but I feel like one when I'm trying to set up the Opal. The only way I can get the Opal to connect to the TEG WiFi is using the GL-iNet "Repeater" mode via their GUI. When I try to directly create it as a client in the OpenWRT interface, it creates the network but it never connects. The same happened when I tried to create a 5 GHz client back to my home network. The network appears in the OpenWRT interface, but it never seems to connect and get an IP assigned. I think at one point I got the Opal to connect to the TEG using the repeater mode and I was able to set its LAN connection to a static IP on my home network, but my screens didn't look like @martinmanyhats above. Instead of the IPV4 upstream being the LAN, it was showing the TEG as the upstream. It did seem to be connected to both networks at that point, but I can't be sure if it would have worked in that state. I did something very bad to my router when trying to set up the new static route and had to restore a backup, and decided it was time to ask for help. I'm not used to the older version of OpenWRT that runs on the Opal, so I think I'm missing something with the interface or firewall setup to make this work. I can set this up as a 2.4 GHz WiFi to 5 GHz WiFi bridge or I can run Ethernet to the Opal and just use WiFi for the TEG side. I'm hoping one of you can give me a little more detail on the step-by-step instructions to get this set up starting from scratch with the Opal. |
Beta Was this translation helpful? Give feedback.
-
|
Hey @youzer-name Hmm I'd have to parse this a bit. I should've taken some notes on my setup steps, I might have to go back and do that at some point. In a working state, the GL Admin Panel on mine shows that Repeater is disabled. If it's tolerable, what I might do in your situation is to run your existing router as-is, and use your new router as just the wireless-to-ethernet client into the TEG network (you can probably do this just fine using the GL Admin Panel, or following #109 (comment) should work). If you definitely want things on a single device, you might be hitting issues where your 2.4GHz radio can only operate on one channel at a time, and I think I've seen where OpenWRT is making it look like it's ready to associate to the AP on another channel than it's broadcasting but never actually gets an IP. |
Beta Was this translation helpful? Give feedback.
-
|
@mccahan Through a ton of trial and error, and using the Gemini LLM which spat out a bunch of very confident but obviously incorrect responses, I finally got it working. I knew I was close when I was able to ping the Powerwall from my main router itself, which showed the travel router was doing its thing. It took a bit more tweaking of the routing before I was able to ping it from other devices connected to the router. At one point I was able to traceroute from a LAN computer to the Powerwall address and I could see the second hop was to the travel router, but pings were still failing. I needed to add some extra static routes because I route most outbound traffic via a VPN connection, and I pretty much need static routes covering all possible traffic paths. I'll describe my setup process in case it helps anyone else. I'm not sure I have everything in the correct sequence, but I think I remember all the steps.
[ Edit 2025-06-14: Updated this image to show masquerade and MSS clamping active. They were not originally on and the TEDAPI/vitals connection was not working ]
I also had to add a static route on the Opal to deal with the traffic headed back to the LAN on 192.168.0.x:
On the main router I added/modified 3 routes:
I'm pretty sure that last step wouldn't be needed for most users. I still don't fully understand the way the static IPv4 routes and IPv4 rules interact with each other, not to mention the settings in each network interface for "use default gateway" that also creates default routes. Maybe I'll ask Gemini to explain it to me some time so I can understand it even less 😏 |
Beta Was this translation helpful? Give feedback.
-
|
Static routes and connecting from a VM, through a host, to a router, to another router, wirelessly bridging a connection to the powerwall is...a lot. I feel like I'm nearly there though, but I can't get PWD to connect. I ran the |
Beta Was this translation helpful? Give feedback.
-
|
The add_route.sh script no longer works with the latest Firmware. I need to pull that out of the repo or at least disable it. To get what you want will require some manual routing steps. My preferred path (and only one I use) is to always connect direct from the Powerwall-Dashboard host to the Powerwall WiFi (see #607), though many in the community are making it work by using a bridge method as you mention. This gist may help: https://gist.github.com/jasonacox/91479957d0605248d7eadb919585616c |
Beta Was this translation helpful? Give feedback.
-
|
It all works now with travel router. Thanks to mccahan above. I flashed DD-WRT onto my TP-link TL-WR703N. Then with help from AI friend, I basically did the following, summarised:
To check, go to Status -> WAN and make sure it has got an IP address from Powerwall. Then clear previous static routes and set up static route using Finally reboot or start powerwall-dashboard or powerwall3mqtt addon. |
Beta Was this translation helpful? Give feedback.
-
Firmware 25.18.1 (9eca33eb)the PW3s were upgraded this morning from 25.10.4 to 25.18.1. All seems A-OK with PD v4.7.1 and TEDAPI (via wi-fi)
|
Beta Was this translation helpful? Give feedback.
-
|
@oralallen82 What is your setup. What version PW, method of connection (ETH, Wifi, or connected to TEG/PW AP), etc. Without knowing details such as this, we can't know if this is surprising or not. |
Beta Was this translation helpful? Give feedback.
-
Currently running Latest version of the dashboard 4.8.0 Powerwall 2 currently running 25.10.4 I am using option 1 and I believe that I setup with wired initially but may have switched to wireless a few months ago. Let me know if you need more information Checking pypowerwall
Checking telegraf
Checking influxdb
Checking grafana
Checking weather411
All tests succeeded. |
Beta Was this translation helpful? Give feedback.
-
|
@oralallen82 TEDAPI Vitals: Not Connected The TEDAPI isn't working in your setup. |
Beta Was this translation helpful? Give feedback.
-
Ah thanks for pointing that out. I don't think missing the vitals is a bit issue for me. I do have a spare raspberry pi laying around it I wanted to get it back up and running. I thought that after the update the dashboard etc. would stop working. |
Beta Was this translation helpful? Give feedback.
-
|
That's all I'm using. I setup the RPi to bridge between my LAN and the GW wifi. Setup IP forwarding and SNAT on the RPi and TEDAPI comes back to life. https://gist.github.com/jasonacox/91479957d0605248d7eadb919585616c |
Beta Was this translation helpful? Give feedback.
-
|
For me, I think also “worked” until I rebooted the container running the
dashboard. I was still getting string data etc, but couldn’t see live
powerflow on the dashboard.
…On Tue, Jun 24, 2025 at 09:28 petersloan ***@***.***> wrote:
@oralallen82 <https://github.com/oralallen82> What is your setup. What
version PW, method of connection (ETH, Wifi, or connected to TEG/PW AP),
etc. Without knowing details such as this, we can't know if this is
surprising or not.
—
Reply to this email directly, view it on GitHub
<#109 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAHGXCA4DSKPCRJ64XPPDIL3FGREZAVCNFSM6AAAAAARLKZOSSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGNJWGU3TKMA>
.
You are receiving this because you commented.Message ID:
<jasonacox/Powerwall-Dashboard/repo-discussions/109/comments/13565750@
github.com>
|
Beta Was this translation helpful? Give feedback.
-
|
./verify.sh output implies TEDAPI not in use.
Checking pypowerwall
----------------------------------------------------------------------------
- Config File pypowerwall.env: GOOD
- Container (pypowerwall): GOOD
- Service (port 8675): GOOD
- Version: 0.12.12 Proxy t73
- Powerwall State: CONNECTED - Firmware: 25.10.4
- Site Name: Home Energy Gateway
- Powerwall Gateway TEDAPI: Not Available (192.168.91.1)
- Cloud Mode: NO
When I look at the pypowerwall container log in Docker I see this, which made me think I was using TEDAPI.
06/13/2025 04:01:16 AM [pypowerwall] [ERROR] Failed to get /api/system_status/grid_status
06/08/2025 08:53:10 PM [pypowerwall.local.pypowerwall_local] [ERROR] Firmware 251004 detected - Does not support vitals API - disabling.
06/08/2025 08:53:10 PM [pypowerwall.local.pypowerwall_local] [ERROR] 404 Powerwall API not found at https://10.0.0.164/api/devices/vitals
06/08/2025 08:53:10 PM [pypowerwall.local.pypowerwall_local] [ERROR] Firmware 251004 detected - Does not support vitals API - disabling.
06/08/2025 08:53:10 PM [pypowerwall.local.pypowerwall_local] [ERROR] 404 Powerwall API not found at https://10.0.0.164/api/devices/vitals
06/08/2025 08:53:02 PM [proxy] [INFO] Connected to Energy Gateway 10.0.0.164 (Home Energy Gateway)
06/08/2025 08:53:02 PM [proxy] [INFO] pyPowerwall Proxy Server - Local Mode
06/08/2025 08:53:02 PM [proxy] [INFO] pyPowerwall Proxy Started
06/08/2025 08:53:02 PM [proxy] [INFO] pyPowerwall [0.12.12] Proxy Server [t73] - HTTP Port 8675
But that said, virtually every graph I want to see for my day to day monitoring is coming in just find through this API. The only gaps in my data are self inflicted (e.g. unexpected Synology failure while we were away causing data gaps). Otherwise 100% of my charts in the standard Grafana PWD dashboard are populated.
***@***.***
…-cl
From: Jason Cox ***@***.***>
Sent: Tuesday, June 24, 2025 7:16 PM
To: jasonacox/Powerwall-Dashboard ***@***.***>
Cc: Chuck ***@***.***>; Mention ***@***.***>
Subject: Re: [jasonacox/Powerwall-Dashboard] Tesla Powerwall Firmware Upgrades - Observations (Discussion #109)
Thanks for sharing @clukas1967<https://url.emailprotection.link/?buEq4eyNl9NRYRhKUfm4VcHx7QafvcrllaGS_V6NGkszGLyipb2fXjTC9nNCP71d9ThwMey9YZgrh_1WqCorHTg~~> - nice diagram! I can get that configuration to work on my PW2 systems for local (1) access, but it does not work for TEDAPI (extended metrics). I assume your dashboard is set to hit a local IP (e.g. 10.1.2.33) vs the gw one (192.168.91.1). Does ./verify.sh show that you are connected to TEDAPI?
—
Reply to this email directly, view it on GitHub<https://url.emailprotection.link/?bKY0BbSpyVCimgE5ulKWZCBnmbKjlFI1T5cEwpAMWuF2J1ibgFxEUM3EFicrIx3QRLufCIqdXmWL-dXn8Lx7oOLafxZzfPqjG3_qo3qchtK2WOzHFaiItNgNPT2zeuN4PIZ1cd3nYBXWODDGPN6rMurGn0R6QLlE5aJzvj5Y1Onw~>, or unsubscribe<https://url.emailprotection.link/?bXMDIGZhxCkZy1yXK1IAmriK2eEmEJzfy5CueJ8x6f5u9RKYkQEAMAm5gA3j9MG4SyIGhn_6T0-lU5PWzBG1MAjvggHqOUYs0tSadoZ04EhJRnqReOfKt8cxCC6PQlJNYbsJSI6ahHMvyIvz0u5T38qeCO7Fp73v9C4dx3u7qGvDkL9mGqbJ52y8DgJcWG7UcgRppsaxVDNmM2ua5iMJXfJzvO95JeFLNhDd-PTCkulUYYdHjfnwEOEY1z-G03XPv>.
You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>
|
Beta Was this translation helpful? Give feedback.
-
|
Makes sense. You can try the history tool (https://github.com/jasonacox/Powerwall-Dashboard/tree/main/tools/tesla-history) to pull the missing data from Tesla. |
Beta Was this translation helpful? Give feedback.
-
|
Hee hee. Yes I know. Per other threads on PWD Github I have leaned hard on history tool in the past to initially populate the InfluxDB back to the date of original system install (pulled a couple of years of data).
That said, allow me to make another plug for the RFE I proposed last September to automagically invoke the history tool when PWD boots up after a failure and notices that there is a gap of days or up to a several weeks between today’s date and the last valid data in InfluxDB.
#12 (comment)
We were recently away for 5 weeks, and during this window (which you can see in the image I included in the last post) there are two gaps due to weird PG&E outages. Normally we’re the only house on the block with power when PG&E goes down but every once in a while my Synology crashes during the PW switchover and often does not reboot. If I’m home no problem but when we’re on the road I intentionally don’t have remote Synology access deep behind my double DMZs so there is a gap.
PWD should automatically detect there is valid previous data and fill in any gap when docker boots up on the next restart.
…-cl
From: Jason Cox ***@***.***>
Sent: Tuesday, June 24, 2025 10:25 PM
To: jasonacox/Powerwall-Dashboard ***@***.***>
Cc: Chuck ***@***.***>; Mention ***@***.***>
Subject: Re: [jasonacox/Powerwall-Dashboard] Tesla Powerwall Firmware Upgrades - Observations (Discussion #109)
Makes sense. You can try the history tool (https://github.com/jasonacox/Powerwall-Dashboard/tree/main/tools/tesla-history<https://url.emailprotection.link/?bFTuQSPsbREV8mLmIPlmiFogAP9qMesyrI1b0VQWGWy2gQ7EJkqIuj51jMkGhJyj3nd-hvdat3pTZOYvKKrHO-0iEynyI9U1n5gy58G4rY59M1DoqmpMwNPAkplf60b6g>) to pull the missing data from Tesla.
—
Reply to this email directly, view it on GitHub<https://url.emailprotection.link/?b6Uq29LOApUEQttYZf3acQ1JGN8ilCVSMVg79rDi-_H0cF2RPqU7h_eIQd9X74LD1P3tsZwp-CWvOaT0zfJqemac9R5gzlrnAofuwy0Q2yMOrWt-XhRnXwuokXCurWTRF1XPau60wFg-XptmA0DQxtSlT7rI4lzeHzwcGPoHN77E~>, or unsubscribe<https://url.emailprotection.link/?bfh22Ncd8ZLvjg-xmbjA3-FBNt-X2qasUxaRZ3U2xpg4tX9hna6XHR9L_MgM39cDqQeiD5XyJaxzB_5YWSOEO7iGN0h1r3ilwdWTykLkMln6tFDIjEG__yMKaV3QWe1RX3DnHaGkx61BgONyMPswr27jEElGiFt9-CNO_HVlw_UrlIdByjcHqsdHSwxdz6IQDMkV8PePkmYgPAgFuT8_N_pRjvtjFjScknN7wzqmBQQXnr3xX1RgJO9_Yld1oEZlU>.
You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>
|
Beta Was this translation helpful? Give feedback.
-
|
I would recommend a UPS for your Synology. The Powerwall is a backup battery, not a UPS. I have a UPS for all my core systems. Also, as a note, Powerwall 2 and + users have a lot of options if they are not interested in the extended metrics, including LAN access. Unfortunately, Powerwall 3 users have no choice but to use the WiFi access point. |
Beta Was this translation helpful? Give feedback.
-
|
@clukas1967 it's safe to re-run the tesla-history.py file, so if Synology supports it you might just do it with a cron job every day or what have you. E.g., create #!/usr/bin/env bash
# Calculate timestamps
START=$(date -d "2 weeks ago" +"%Y-%m-%d %H:%M:%S")
END=$(date +"%Y-%m-%d %H:%M:%S")
# Run the Python script
python3 ~/Powerwall-Dashboard/tools/tesla-history/tesla-history.py --start "$START" --end "$END"Then Adjusting for paths and timelines as necessary |
Beta Was this translation helpful? Give feedback.
-
This is the way. The history tool backfills, and, from memory even has convenience parameters like today and yesterday. |
Beta Was this translation helpful? Give feedback.
-
|
I have a UPS with 30 minutes of coverage and the Powerwalls both. UPS is wired into Synology via USB and tested annually (in fact just got a new battery 2 months ago before our trip). Synology still crashes hard unpredictably with power fluctuations. Very frustrating. Hence the RFE.
From: Jason Cox ***@***.***>
Sent: Tuesday, June 24, 2025 10:39 PM
To: jasonacox/Powerwall-Dashboard ***@***.***>
Cc: Chuck ***@***.***>; Mention ***@***.***>
Subject: Re: [jasonacox/Powerwall-Dashboard] Tesla Powerwall Firmware Upgrades - Observations (Discussion #109)
I would recommend a UPS for your Synology. The Powerwall is a backup battery, not a UPS. I have a UPS for all my core systems.
Also, as a note, Powerwall 2 and + users have a lot of options if they are not interested in the extended metrics, including LAN access. Unfortunately, Powerwall 3 users have no choice but to use the WiFi access point.
—
Reply to this email directly, view it on GitHub<https://url.emailprotection.link/?b9XOrpYYp8YjhrHINhxyYyrzHm1I0s6zzLBJtFWPorPn9QD9Ut5maG65oprImq3buHeruuLVjtAXJ2iXVgavvcz3IkKywiKn00AUYBll4NGOtGMpMjLT3eIrXClLiX-xlmBS4zfQpd9VaQq1PqF9aleH8b3V_Vh5Zpe-pC_vwe90~>, or unsubscribe<https://url.emailprotection.link/?b1iyHXFb_q0WPgz8p6QcJVAwHR_2kxqAHGzrSgm7yrmaccwH4CURpft1ZO-yjUZcauCSJWoLteXS2QMjO5HqMV6zHYndnMthVC6iuhALdrVfxDJeLe6N6UNVzZRCwOxvHs7O_hkr6NhEjc32eLrbB3ElZmUlKgplj-CI0fx9zx1zlABbajtsIyNVdI-6ZtncEdzNnulcgbEhVCe13wO3I-NuJhRS3rKVJulEFgomRw4d6w9SjXGT6BEGi0r6Z35It>.
You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>
|
Beta Was this translation helpful? Give feedback.
-
What is that? |
Beta Was this translation helpful? Give feedback.
-
|
That said, allow me to make another plug for the RFE I proposed last September to automagically invoke the history tool when PWD boots up after a failure and notices that there is a gap of days or up to a several weeks between today’s date and the last valid data in InfluxDB.
#12 (comment)
From: Jason Cox ***@***.***>
Sent: Tuesday, June 24, 2025 11:32 PM
To: jasonacox/Powerwall-Dashboard ***@***.***>
Cc: Chuck ***@***.***>; Mention ***@***.***>
Subject: Re: [jasonacox/Powerwall-Dashboard] Tesla Powerwall Firmware Upgrades - Observations (Discussion #109)
Hence the RFE.
What is that?
—
Reply to this email directly, view it on GitHub<https://url.emailprotection.link/?bge0qq8kM0knpcXY51KeodDsRPOcr9s2Kv4OpmeOhW0uQlNIzoZ8X46TJulzniuGV_htrCSo4MvGC4MGsP3d0a0OlLmlcHskCA5jx8_AgI-qTJ4lysLt09pWV45TKyPjXe9dDZKIZqb5Kv9f5Wd8OS3Pq3WJ9nR_Dw60cUQPZkZg~>, or unsubscribe<https://url.emailprotection.link/?bPuH4oWp4J1xg7q4vVT5lgmoU7oklzX1rSoPIVIDQcWbpozgX51jgxRPdLB53QrRtNb9qoX6qBgKxXrAnSGJ2Ehb4YdkUMX1q-5HZwmx7OUd-beSxud7-PJNn1QV1Xvaz_IWqtcuiA3T63pkfVK1WpnAC3tMmbLSILHHq0TcrtdIrKpJTl_bnC6X3VTMk4wNvdbVeLqMy3QmbBP4gTIITJObL0zP8mFMIAWkzN6IsexqxkbdfSkJ3XoUQssviVsy1>.
You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>
|
Beta Was this translation helpful? Give feedback.
-
|
Is there any possibility that the PW3 is now also blocking WIFI access? Single PW3 at 25.18.1 Both powerwall-dashboard and powerwall3mqtt Home Assistant addon stopped working around similar time 2 days ago (24th). Checking through the connection, from Linux container to WIFI travel router. I've found I can no longer ping 192.168.91.1. Not even from the DD-WRT travel router that connects to PW3 via WIFI.
According to Home Assistant fleetAPI integration, I'm already on 25.18.1 before 23rd. So I'm at a complete loss what has changed causing PW3 to not respond to pings via WIFI. Anything else I can try? |
Beta Was this translation helpful? Give feedback.
-
|
This seems to be unique to your setup, but I'm creating an issue for you: #648 |
Beta Was this translation helpful? Give feedback.
-
Firmware 25.18.2 (e1f565d8)My system just updated to 25.18.2 e1f565d8 this afternoon ~4.40pm Sydney time. No issues so far that I can tell. Everything kept working / no dropouts or resets required (using TEDAPI via WiFi with a TP-Link nano router to bridge to LAN).
|
Beta Was this translation helpful? Give feedback.
-
|
I've been on this version for about a week. My observations: The most important one:
Other minor observations:
|
Beta Was this translation helpful? Give feedback.
-
|
I have the "IslandChecksFailed" on 25.10.4, so maybe not new, but you are seeing them now in your configuration. The potential MCI update is interesting. |
Beta Was this translation helpful? Give feedback.
-
|
More details on the MCI. This is what my alerts looked like yesterday for the entire day: Even checking Tesla One, the relevant strings were "green." In the past they would be greyed out and have additional errors if they were producing in spite of the MCI error such as |
Beta Was this translation helpful? Give feedback.
-
|
I'm also running 25.18.2, but not sure when that upgrade occured, as it seems rather perfectly smooth this time. All is working on wifi. I see two very short (4 min) IslandChecksFailed alterts over the last week. The one alert I find strange is "ChargeOnlyFromSolarOverride", which turns off for 2 to 3 hours corresponding to a VPP event, but otherwise is always on. |
Beta Was this translation helpful? Give feedback.
-
|
also on 25.18.2, for me |
Beta Was this translation helpful? Give feedback.
-
Firmware 25.18.4 (b6b41ca8)My system just updated to 25.18.4 b6b41ca8 this afternoon ~4.30pm Sydney time (was on 25.18.2 e1f565d8 for only 2 weeks which seems short, for me anyway). Still getting metrics okay and no connection issues, however now seeing alert BatteryUnexpectedPower which I have rarely seen before. 
|
Beta Was this translation helpful? Give feedback.
-
|
My system upgraded as well, but without the BatteryUnexpectedPower alert. Does it stay on or just happen in the evening? |
Beta Was this translation helpful? Give feedback.
-
|
The BatteryUnexpectedPower alert was present for 10 mins and then went away. I checked back on my previous firmware updates and this was the first time the alert occurred for me like this. I have however seen it on a few other occasions, which appeared to coincide with a transition from charging/not charging perhaps. I did note while this alert is present, charging/discharging of the Powerwall is stopped (regardless of SOC). Seeing it active for 10 mins was initially what concerned me. Especially since my SOC was at 40% and energy flow to/from the Powerwall was zero during that time. It's that panic you get whenever you do a firmware update! 😄 Perhaps just some sort of protection mechanism immediately after a firmware update, until everything settles. Probably not an issue or anything to worry about though. |
Beta Was this translation helpful? Give feedback.
-
|
Huh - Since being upgraded to 25.10.4 I've lost all alerts except for What could be wrong on my end? I'm using a static route over LAN (192.168.91.0/24) to my GW, current FW is 25.18.4. |
Beta Was this translation helpful? Give feedback.
-
|
Static route with LAN you say? That should have stopped working... So probably what's wrong is you're not actually getting TEDAPI data anymore. |
Beta Was this translation helpful? Give feedback.
-
|
I'm still getting PW capacity data, and as far as I know the only way to get that was from /api/system_status Have I missed something along the way? |
Beta Was this translation helpful? Give feedback.
-
|
As of Powerwall Firmware version 25.10.0, network routing to the TEDAPI endpoint (192.168.91.1) is no longer supported by Tesla. You must connect directly to the Powerwall's WiFi access point to use TEDAPI features. If you previously set up a static route for TEDAPI, you can remove it using |
Beta Was this translation helpful? Give feedback.
and others
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Tesla Powerwall Firmware Versions
This is an attempt to help navigate the Firmware discussions. Table lists the most recent Firmware versions at the top.
Table added by @jasonacox
Firmware 22.26.1
Just curious if others are seeing the same behavior.
I have noticed, especially since the "foxtrot" firmware version, that my Powewalls are charging much less "smoothly". It seems to be going from 90% to 100% in steps now. I imagine this is better for the batteries. Also, I am seeing a much larger drop in charge level at 4:00PM when my system switches to battery to cover the TOU period.
The system is currently on firmware 22.26.1 1da541cb.
Charge level drops by 5% immediately at 4:00PM. It used to drop by 3%.
Charge behavior and initial drop on older firmware versions: (you can see the foxtrot upgrade here too)
Beta Was this translation helpful? Give feedback.
All reactions