Tesla Powerwall Firmware Upgrades - Observations

[cwagz]

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)

[jasonacox]

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.

[jasonacox]

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.

[mcbirse]

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.

[jasonacox]

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.

[mcbirse]

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.

[jasonacox]

Firmware 22.26.2

This 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%.

[longzheng]

On a related note, @jasonacox could we add firmware version tracking to the database and dashboard?

[jasonacox]

I really like that idea @longzheng !

[jasonacox]

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

[jasonacox]

Firmware 22.26.4

22.26.4 fc00d5dd	22-Nov-2022	STSTSM firmware showing 2022-10-26-g9b8e445626

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:

[longzheng]

Firmware 22.36.4

Mine 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 2023-02-08-gf072c58d6c.

Has only been a few hours so don't notice anything new.

[jasonacox]

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)?

[longzheng]

These are my alerts

Nothing new/unusual compared to the other user.

[jasonacox]

Firmware 22.36.6 (and rollback to 22.36.4)

22.36.6 cf1839cb	11-Mar-2023	STSTSM firmware showing 2023-03-04-gd9f19c06f2

Observations

• No issues seen yet

Upgrade Alerts

[robot498]

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.

[robot498]

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.

[jasonacox]

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.

[robot498]

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.

[robot498]

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.

[DMBlakeley]

Where can I find a description of the Alerts?

[jasonacox]

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

[rvry]

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).

[jasonacox]

Thanks @rvry - I added this note to the Alert list on pypowerwall.com.

[DMBlakeley]

Thanks for pointing out.

[longzheng]

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

[jasonacox]

Good find!

Telsla Energy Setup - Upgrade Now

There's a better way to set up Powerwall
Get the new app for Tesla professionals

Step 1: Disconnect from the TEG Wi-Fi network

• Turn off Wi-Fi on your phone

Step 2: Tap the button below to download Tesla Pros

• https://play.google.com/store/apps/details?id=com.tesla.teslapros&pli=1

Improvements include:

• Better update experience and quicker commissioning
• Access to more system information and self-tests
• Improved Neurio meter pairing
• Better diagnostics and alerts

[jgleigh]

Firmware 22.36.7

22.36.7 is out now.

[robot498]

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?

[robot498]

Forgot to mention that there was 0 volts between the negative terminals, such as one with a jumper and one without.

[jgleigh]

Just had a Gateway lockup with 22.36.7...hopefully they push 22.36.8 soon.

[anderep]

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.

[robot498]

@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!

[jasonacox]

Firmware 22.36.8

22.36.8 78f59883	27-Mar-2023	STSTSM firmware showing 2023-03-21-g677aad408c

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).

[cwagz]

I wonder why they don’t push these at like 2am.

[longzheng]

I also see BatteryUnexpectedPower on 22.36.6 when I did a manual restart of the Gateway.

[jasonacox]

Agree @cwagz ! Thanks @longzheng - not sure what it means.

[brianmsailing]

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.

[jgleigh]

@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.

[robot498]

@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!

[robot498]

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:
From 1+ to 2+: 2 or 3 mv, which seems correct - at the time there was about 3 amps flowing to MPPT 2, so the voltage is because of the resistance of the jumper.
From 3- to 4-: 0 mv.
From 3- to 2-: about 77 mv. So that seems to indicate that the negative jumper terminals are not common.

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.

[brianmsailing]

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.

[robot498]

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.

[dailow]

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

[jasonacox]

Firmware 22.36.9

22.36.9 c55384d2	11-Apr-2023	STSTSM firmware showing 2023-03-29-g66549e6ca7

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.

[jgleigh]

Just got a MciOpen at noon. This 22.36.x series has had more weird issues.

[jgleigh]

And again today! 🤬

[robot498]

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.

[jgleigh]

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.

[jgleigh]

Looks like it's reverted to the 7 am health check. Not ideal but better than noon.

[oralallen82]

See attached

…

On Wed, Mar 20, 2024 at 8:16 PM Jason Cox ***@***.***> wrote: Can any of you post what you see in the alerts panel? I would like to see how our new build (v4.1.3) is working. Unfortunately (or fortunately for me?) I'm still on 23.36.4. — Reply to this email directly, view it on GitHub <#109 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIDLQFV5W3DMGPRUDKK3MN3YZIYGDAVCNFSM6AAAAAARLKZOSSVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DQNJZGU4DC> . You are receiving this because you were mentioned.Message ID: <jasonacox/Powerwall-Dashboard/repo-discussions/109/comments/8859581@ github.com>

[s0schen]

[s0schen]

Firmware 23.44.0 after they changed out a second powerwall under warranty and suddenly nothing was visible on Tesla app until they upgraded the firmware. I also have 2 inverters. Wondering if there is some API that will show the second inverter data.

[jgleigh]

Pretty sure the Powerwalls communicate with the Gateway over the hardline communication bus. The Neurios on the other hand connect over WiFi back to the TEG. The Neurios only monitor power output from the solar inverters.

[simonrb2000]

I'm having to reset my gateway password everyday or so. Says Bad Credentials. I have the latest version 4.1.3; did this version have a fix for this? Could the cause be it polling solar_powerwall when I don't have Powerwall+? Cheers

[jasonacox]

@simonrb2000 create #456 for you

[s0schen]

So I noticed http://localhost:8675/api/solar_powerwall/$1 through http://localhost:8675/api/solar_powerwall/$9 will give a response but unfortunately it still seems like the primary PW+ inverter and I can't find the argument that will get the vitals from the second PW inverter. I don't see anyone on their public APIs that show how to send the right arguments. https://developer.tesla.com/docs/fleet-api#energy-endpoints

[jasonacox]

Good find @s0schen - thanks for sharing. Unfortunately I only have one inverter so I'm not able to help with these. If anyone is able to use this finding and extend it to actually get the other inverter data, let us know! 🙏

[thekev]

So I noticed http://localhost:8675/api/solar_powerwall/$1 through http://localhost:8675/api/solar_powerwall/$9 will give a response

I am not able to reproduce, on 0.7.12 Proxy t44 and firmware 23.44.0:

$ curl 'http://localhost:8675/api/solar_powerwall/$1'
404 page not found

[jgleigh]

On 24.4.0 here and I'm seeing 404 responses as well. I have two Powerwall+ and would love to see both of them again in the data.

[ygelfand]

if you can provide connectivity to the gateway/inverter provided (TEG-*) wifi, you can use my proxy (https://github.com/ygelfand/go-powerwall) as a drop in replacement. It should provide all but temperature data on individual powerwall+'s still.

[thekev]

@ygelfand I have poor connectivity, but I have seen the data using the pypowerwall.git/tools/tedapi/status.py. Once I get an external antenna or some other solution to the weak signal, I will probably roll your proxy. Thanks.

[stevecastaneda]

Firmware 24.12.3

My Powerwall 3s updated last night to Firmware 24.12.3 from 24.4.2-1.

• 3 out of 4 units updated fine, and the 4th is stuck on the old version. Ticket opened with Tesla.
• It appears the default LED now is white instead of green. No mention of white in support docs.

[ygelfand]

@jasonacox I may have misconfigured something with telegraf. I have a hybrid configuration mixing pypowerwall and @ygelfand ’s tedapi proxy. I’ll give that a look tomorrow.

$ curl -s http://localhost:8675/freq | jq .
{
  "PW1_name": null,
...
  "grid_status": 1
}

my proxy should result in the same endpoint for grid status, so you just need "$BASE_URI/api/v1/freq" in inputs.http for telegraf.conf. Data from there should look similar (though w/ nested json objects, but they get processed the same in the end).

[thekev]

Looks like this might be the culprit:

$ curl -s http://10.69.186.45:8080/api/v1/freq | jq .ISLAND.GridState
"ISLAND_GridState_Grid_Compliant"

vs.

$ curl -s http://localhost:8675/freq | jq .grid_status
1

[ygelfand]

Looks like this might be the culprit:

$ curl -s http://10.69.186.45:8080/api/v1/freq | jq .ISLAND.GridState
"ISLAND_GridState_Grid_Compliant"

is there no .grid_status coming from /api/v1/freq ? ISLAND_GridState_Grid_Compliant is expected. Can take this back to to my repo if you want to avoid the noise here, but it should also return grid_status: 1

[mcbirse]

Noting another new alert since upgrade to 24.12.3 - ChargeOnlyFromSolarOverride

Appears to be triggered when the Powerwall is sitting at the Reserve charge level and the system needs to add a bit of charge to maintain the reserve?

[jgleigh]

My max production while clipping dropped from 7.8kW to 7kW after this update. :(

[youzer-name]

Ah, I didn't get that you were talking about a surge. I was thinking about a power cut or momentary interruption. But I haven't seen the gateway taking multiple seconds to disconnect from the grid for anything that's happened to me (so far), but fortunately I've never experienced the kinds of grid issues you're talking about.

[anderep]

Firmware 24.20.0

Got upgraded to 24.20.0 at midnight last night.

[MattMake]

@MattMake - Added panels for current and voltages: https://github.com/jasonacox/Powerwall-Dashboard/releases/tag/v4.4.6

Working great, thanks for updating!

[oralallen82]

It's been tagged by Tesla support verbally as a bug, however it appears to be persistent in 24.28.0, so some are wondering if this change was intentional by Tesla. Here is a thread on TMC that (partly) discusses this: https://teslamotorsclub.com/tmc/threads/24-20-0-firmware-observations-problems.331559/

Thanks for this. I just completed chatting with Tesla Powerwall support and they indicated:

"I do see grid charging as you mentioned. We can remotely set a configuration to the Powerwall so it can deny grid charging. Please allow up to 24 hours for the Powerwall to download the latest command. If you experience grid charging after 24 hours please do not hesitate to reach back out"

[oralallen82]

I just tested it and it appears to have been resolved. Setting by backup % greater than my current level it pulls all from solar and doesn't pull from the grid except for home loads.

[youzer-name]

I posted about this back in June: #486. My system started doing this when it upgraded to 24.12.3.

They did the same change on my config but I had them revert the change as I still wanted the option to charge from the grid if needed.

[maxEntropyProd]

This was occurring on 24.12.3 [edited]. Also, charging from grid does not occur if solar production exceeds ~3.9 kW, so you need to test when solar is less than that.

This appears to be associated with the VPP feature. Some have reported that their app has the ability to set battery reserve % for both backup and VPP; however, I only see just backup reserve, which I think is causing the problem for me.

[kylebrowning]

Firmware 24.28.0

[E8586]

I got 24.28.1. the update started at noon and since than the Ventilator of the Powerwall is running full speed and the Dashboard is not working anymore. I also cannot log into the Powerwall directly. The System itself is working normal and the Tesla App is also working.
The Fan finally stopped. I can access the Web Interface via WiFi but not via my Ethernet connection. It‘s telling, thatbEthernet is configured but not connected. I did check the Cable and everything looks good.

[BMWE85]

Everything is working fine again. During the night it just started to work. I'm wondering if this was glitch during the update and the system tried to update more than once as it took nearly half a Day.

[jasonacox]

When you commission the system, I recall that fans will definitely spin up while the the system boots and activates the solar array, etc. I have seen that happen during upgrades as well. But they would return to normal after 20-30m except under heavy generation or high ambient temperature. I assume @BMWE85 is the same person as @E8586 ? If not, @E8586 is your system still offline? I would check to see if the upgrade caused the gateway to get a new IP address (DHCP) and a python3 -m pypowerwall scan would help find it if needed.

[E8586]

Yes, it‘s the same Person. The System is back to normal. It came back at about 8:30pm last night. I can access it via Ethernet and also the Powerwall Dashboard is working as usual.
it was just confusing that it took several hours instead of the usual 20-30 minutes.

[jgleigh]

I got 24.28.1 last night as well.

[jasonacox]

Firmware 24.28.1

@jgleigh reporting 24.28.1 so opening new thread for any observations.

[MattMake]

Mine upgraded at 1:09am on Wednesday night, had similar errors in my alerts that cleared within an hour or two.

[mcbirse]

Also got upgraded to 24.28.1 this afternoon 3:48pm Sydney time.

EvnTime: 2024-09-12 15:48:28
Message: Firmware version has been updated
Details: Version changed from 24.20.0 c128851f to 24.28.1 bf092653
Up time: 51.924959877s

[jgleigh]

@mcbirse Where do you get that event information from?

[oralallen82]

@mcbirse Where do you get that event information from?

I get a similar notification like that from Hubitat

[mcbirse]

Hey @jgleigh - that is an e-mail alert sent via the pwstatus script that I wrote.

It's available from the Powerwall Dashboard tools repository if you want to try it.

[oralallen82]

I'll check when I get back home tomorrow.

…

On Fri, Sep 6, 2024, 10:15 PM Jason Cox ***@***.***> wrote: Hey @oralallen82 <https://github.com/oralallen82> , I'm curious, what happens if you try: # Connect to Cloud python3 -m pypowerwall setup # or fleetapi # Get Current Settings python3 -m pypowerwall get # Turn on Grid charging python3 -m pypowerwall set -gridcharging on # Turn off Grid charging python3 -m pypowerwall set -gridcharging off — Reply to this email directly, view it on GitHub <#109 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIDLQFTRIKFNVTTTGX7BVKLZVJVWBAVCNFSM6AAAAAARLKZOSSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTANJXGQ4DONA> . You are receiving this because you were mentioned.Message ID: <jasonacox/Powerwall-Dashboard/repo-discussions/109/comments/10574874@ github.com>

[oralallen82]

I just noticed a new weird behavior on 24.28.1 The system ignores by backup %. I have a rule on the NetZero App that when I start charging the model 3 to set the backup % to the current state. I checked and the automation ran successfully. I even saw the App have the correct backup % for some reason the system is still pulling from the battery. Has anyone seen this?

[BJReplay]

Firmware 24.36.1

Just got upgraded to 24.36.1 f997968b

Had been on 23.36.3 for a long time.

Lost a lot of alerts (not surprised, just disappointed, having been upgraded after sitting on an old version for so long).

Also lost frequency and voltage and temperature.

Will now update Powerwall Dashboard to the latest versions (just in case), but because I run a custom docker config (I have a custom network config to allow other services to run, the upgrade is a difficult process because I need to do it manually).

[rjs3273]

I just got 24.36.1 last night on my powerwall 3. All telemetry that I was getting previously have continued.
No issues for me so far on

• powerwall 3 with its own built-in gateway, v24.36.1
• Powerwall-Dashboard v4.5.5
  I have not tried to reboot, reconnect or toggle the switch since the firmware update. I suppose it is possible that I would not be able to reconnect if I did, but for now at least, it's all good.

I don't want to sound like I'm gloating! Just trying to confirm that the problem is hardware version specific, like you guessed.

[BJReplay]

I don't want to sound like I'm gloating! Just trying to confirm that the problem is hardware version specific, like you guessed.

Interesting that you got v24.36.1 when I'm now on v24.36.2. I swear that the releases are made by work experience kids (or as you'd say in the US, interns) without testing.

I have disabled Powerwall Dashboard and my own internal service in the hope that Home Assistant can stay connected for more than 24 hours on 24.36.2.

If I were to guess - and it is only a guess, of course - there's either a memory leak or similar, or they've done something that means that older hardware simply can't run this firmware for an extended period of time with more than one device trying to poll for updates without locking up and locking out users.

The reason I suspect a memory leak (or worse) is that when it goes bad, you can't log in, that that smells like a buffer overrun or memory corruption in the gateway such that the stored password (or stored hash or the password) has been overwritten, so when you attempt to log in, the gateway thinks you're supplying an incorrect password.

@jasonacox feel free to close the associated issue - as noted just above, I've stopped running Powerwall Dashboard in the hope that I can get more than a few hours stability out of the gateway: control of charging / reserve levels (which I've got running out of home assistant) is more important than the beautiful graphs that I was getting from the dashboard, unfortunately.

[jasonacox]

I understand @BJReplay and would love to fix this for you if I could. If you don't mind, I would like to leave this open to confirm that it is an issue of having multiple pollers.

One thought... There is a long term option if running just home assistant works. Just switch pypowerwall to cloud mode for Powerwall Dashboard. It will only poll the cloud so won't impact your gateway, and you will still get the trending data and some extended data (though reduced). To do that run setup.sh or, as I recall, if you have a custom install, do it manually:

• In pypowerwall.evn, set PW_HOST to empty (no IP address)
• Set PW_EMAIL to your Tesla email.
• Run cloud setup mode and restart:

docker exec -it pypowerwall python3 -m pypowerwall setup [email protected]
docker restart pypowerwall

[BJReplay]

There is a long term option if running just home assistant works. Just switch pypowerwall to cloud mode for Powerwall Dashboard

Good point!

Worth turning it back on.

[petersloan]

When my powerwall 3s were commissioned, Tesla support was called to verify the install as it was the first PW3 that the installer had done. Support was very concerned about the firmware version I was on before (not sure if historical FW versions are stored somewhere in influx?) as I guess there have been significant issues commissioning multiple PW 3s on older FW versions. I had been using 192.168.91.1 IP directly through the ETH port but a few hours after the firmware update to 24.36.1, I started getting permission denied errors. I finally had to use an old Cisco RE1000 to connect to the TeslaPW_* AP and pipe that into a new virtual interface configured for DHCP on my pfSense firewall. This then allowed pypowerwall to start hitting 192.168.91.1 again.

I don't know for sure this was directly caused by the firmware upgrade or by the commissioning process but prior to this, hitting the TEDAPI on 192.168.91.1 directly via the PW eth port was not an issue. Personally I really enjoy having access to the vitals as in Chicago, on my particular distribution branch, I can see significant voltage swings almost to the point where I can look at the voltage and predict the realtime price of power. The load is also not well balanced off the transformer as during the summer, during peak cooling loads, one of the legs significantly drops compared to the other (1-3 volt mismatch) despite my home consumption only a few hundred watts.

Just wanted to note this for future reference.

[mcbirse]

Firmware 24.36.2

My system upgraded to 24.36.2 46990655 (from 24.28.1) this afternoon at 4.45pm Sydney time.

Other than the usual alerts, no issues noted so far and everything kept working as normal.

EvnTime: 2024-11-21 16:46:38
Message: Firmware version has been updated
Details: Version changed from 24.28.1 bf092653 to 24.36.2 46990655
Up time: 54.733939865s

[jgleigh]

Same here. No issues seen so far.

[oralallen82]

I couldn't get TEDAPI setup to work, my setup is running in a docker container on my Pi4 any guides would be appreciated.

…

On Thu, Dec 5, 2024, 1:04 PM petersloan ***@***.***> wrote: When my powerwall 3s were commissioned, Tesla support was called to verify the install as it was the first PW3 that the installer had done. Support was very concerned about the firmware version I was on before (not sure if historical FW versions are stored somewhere in influx?) as I guess there have been significant issues commissioning multiple PW 3s on older FW versions. I had been using 192.168.91.1 IP directly through the ETH port but a few hours after the firmware update to 24.36.1, I started getting permission denied errors. I finally had to use an old Cisco RE1000 to connect to the TeslaPW_* AP and pipe that into a new virtual interface configured for DHCP on my pfSense firewall. This then allowed pypowerwall to start hitting 192.168.91.1 again. I don't know for sure this was directly caused by the firmware upgrade or by the commissioning process but prior to this, hitting the TEDAPI on 192.168.91.1 directly via the PW eth port was not an issue. Just wanted to note this for future reference. — Reply to this email directly, view it on GitHub <#109 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIDLQFUGPPOEEBUTZCGWM2L2ECPSPAVCNFSM6AAAAAARLKZOSSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCNBXG4YDCMQ> . You are receiving this because you were mentioned.Message ID: <jasonacox/Powerwall-Dashboard/repo-discussions/109/comments/11477012@ github.com>

[petersloan]

@oralallen82 Please see https://github.com/jasonacox/Powerwall-Dashboard/?tab=readme-ov-file#extended-device-vitals-metrics-beta

Note that for PW3, in addition to ensuring you have a route to 192.168.91.1, I was only able to get this to work by connecting directly to the AP on the leader powerwall using the password on the QR code. On the RP4, assuming you are PW3, you might need to add a USB WiFi dongle (or an additional one if you are already using one) and use that to connect to the leader TELSAPW_* AP. For PW3, you do not connect to the gateway as the gateway is slaved to the leader PW.

If your RP4 is out of range of the Powerwall, you will need an alternative solution such as a eth->wifi media adapter. You can always use the Cloud mode minus the vitals if the setup is beyond what it is worth to you.

If you need additional assistance, likely this should be moved to its own discussion.

[oralallen82]

Got it thanks. I have Powerwall 2+ I tried but I may be missing something obvious.

…

On Thu, Dec 5, 2024, 3:17 PM petersloan ***@***.***> wrote: @oralallen82 <https://github.com/oralallen82> Please see https://github.com/jasonacox/Powerwall-Dashboard/?tab=readme-ov-file#extended-device-vitals-metrics-beta Note that for PW3, in addition to ensuring you have a route to 192.168.91.1, I was only able to get this to work by connecting directly to the AP on the leader powerwall using the password on the QR code. On the RP4, assuming you are PW3, you might need to add a USB WiFi dongle (or an additional one if you are already using one) and use that to connect to the leader TELSAPW_* AP. For PW3, you do not connect to the gateway as the gateway is slaved to the leader PW. If you need additional assistance, likely this should be moved to its own discussion. — Reply to this email directly, view it on GitHub <#109 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIDLQFUJYHHNGJFFZIL7TQL2EC7GBAVCNFSM6AAAAAARLKZOSSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCNBXHAYDGMQ> . You are receiving this because you were mentioned.Message ID: <jasonacox/Powerwall-Dashboard/repo-discussions/109/comments/11478032@ github.com>

[DarmainTheDonkey]

Hi from the Isle of Wight in the UK. I have two PW2 units and I have created a wall mounted display, using a 64x64 RGB LED panel and an RPi Zero W. Using your libraries I have created a graphical output of my system, not a million miles from the Tesla API, in design. Its all working fine and looks great. Thank you for your continued efforts here.
But the issue I do have is that I have to attach it to the cloud. My attempts to attach to the local Gateway has proved fruitless. The error I get is "unable to authenticate". I am using my correct credentials and I have been in contact with my installer to makes sure the Gateway knows who I am. Apparently it does. However, try as I might I cannot connect. The Gateway is running 24.36.2. Any idea why this is the case? Many thanks, Dave

[jasonacox]

Hi @DarmainTheDonkey I would love to see a picture of your LED panel! My old-school display is here: https://github.com/jasonacox/Powerwall-Display?tab=readme-ov-file#powerwall-display and it uses the pypowerwall proxy for data access.

When you run scan, do you see your Powerwall Gateway on your local network?

python3 -m pypowerwall scan

If so, you could set up the route to access the TEDAPI API (PW3 full mode) for your PW2. You can re-run setup to switch to that local mode. For gateway password, use the WiFi password often found on the QR sticker on the Powerwall Gateway.

# If you set up the route you can check it
./verify.sh

# Run setup
./setup.sh

As to the standard (original) local access via username/password, "Unable to authenticate" does indicate a problem with the password. You should be able to go to the PW IP address in your web browser and log in using that same password. Double check your password and are sure it is correct, try using the last 5 characters of the password written on the Powerwall Gateway.