Firmware Upgrade 23.44.0 - Vitals Removed

[jasonacox]

We have reports of a new Powerwall firmware upgrade (23.44.0) in jasonacox/pypowerwall#57 which results in the removal of the device vitals data API. This API is what we poll to get string data, voltages, frequencies, temperatures, alerts and Powerwall capacity. Unfortunately, I don't think there is a lot we are going to be able to do to recover the device vitals API or data after this Firmware upgrade rolls out.

I believe this will be the first of many changes we will see. As you can see from the TEG portal UI and on the new Powerwall 3, it appears that the direction from Tesla is toward the "Tesla Pros" app to make it easier to install and manage for the majority of their customers. For data nerds like us, we are going to need to pivot and figure out new ways to get what we want. I'm hopeful there will be some easy/good way to accomplish that over next few months.

Request/Notice to the community:

• Help needed: If we were to lose the TEG Portal UI (which it seems likely), I would love to be able to reproduce the Power flow animation via the pypowerwall proxy. If anyone has the skill to reproduce or capture and download the HTML/JS/CSS code for it right now, I'm looking for that help. -- See: Localize PowerFlow Animation pypowerwall#58
• Help needed: What elements of the device vitals payload do you find most valuable? I would love to hear your prioritized list of what you would like to get if we could ask for it (e.g. PW full charge capacity, temps, frequencies, string data, voltages, alerts, etc) and if you have it, any story that demonstrates how having that data was helpful to you.
• Thanks to @mcbirse we now have a setup option to use the Tesla Cloud to pull basic metrics for Solar-only customers and the Powerwall 3 (which no longer has the TEG Portal UI). We can use that method for Powerwall 2/+ systems as well. I'm going to explore importing that into pypowerwall to provide a bridge for if/when other local APIs disappear. Again, I'm hopeful that we will see alternative ways to get the local API data, even if it isn't the full set of data we get now with the vitals payload.

I know changes like this can be frustrating, but I also acknowledge that the Tesla teams need to optimize for the entire customer base and not just us. Still, I'm hopeful that we will be able to figure out ways to bridge most of what we enjoy with the rich data from our Powerwalls, even if we have some work to do to get there.

[jasonacox]

Progress Update

• Localized Power Flow Animation - Localize PowerFlow Animation pypowerwall#58 - Nice side effect is that it loads much faster.
• Default (index) page served up by proxy (http://pypowerwall/) will render Powerflow Animation
• Animation assets (html, css, js, images, fonts, svg) will render from local filesystem instead of pulling from Powerwall TEG portal.
• Start prep for possible API removals from Powerwall TEG portal (see NOAPI settings)

If anyone wants to test, edit your powerwall.yml and replace the pypowerwall version with this test version: jasonacox/pypowerwall:0.6.4t29 and run ./compose-dash.sh up -d.

[jaffro2k]

Hi @jasonacox - apart from the live data feeds from the gateway over time (which for me is just so darn useful that this data is pulled together) - I would say the Powerwall Temps and Powerwall Capacity feeds are the most useful. As I have 4 x non-Tesla solar inverters I don't get any of the other info - and frequency and voltages don't mean that much (am sure they would be worthwhile for troubleshooting issues if they arose with Tesla themselves). Hope this helps! Am not a developer but if you need help petitioning Tesla just let us know!

[mcbirse]

Hi Jason - we could add another mode/option to pypowerwall to retrieve live data via the Tesla Cloud API instead of via the TEG.

It is possible to get live data for the basic metrics via the "SITE_DATA" cloud API endpoint command. Also we can retrieve some other data relevant to us via "SITE_CONFIG".

This would be better than using "calendar history data" like the tesla-history script does, and in fact a great improvement for the solar-only users as well anyway. The tesla-history script could still be useful to fill in data gaps if the connection to the Tesla cloud server was down for a period.

Is it okay to be polling the Tesla Owners API website directly e.g. every 5 seconds?

I think it is. I just did some testing with the Tesla App open on a mobile device, and set up a packet capture to watch frequency of poll requests from the app - it appears with the app open and showing the power flow, requests are sent every 4 seconds.

So to have pypowerwall polling live data from the cloud every 5 seconds seems reasonable, and is essentially the same as someone leaving the app open forever on a mobile or tablet to show the live power flow.

What metrics are available from the cloud?

From "SITE_DATA" we can get the following live metrics:

• Basic power metrics

"response": {
    "solar_power": 738,
    "battery_power": -250,
    "load_power": 488,
    "grid_power": 0,
}

• Charge percentage

"response": {
    "percentage_charged": 60.87642617009513,
}

• Grid status

"response": {
    "grid_status": "Active",
    "island_status": "on_grid",
}

• PW Charge and remaining PW Capacity:

"response": {
    "energy_left": 7938.894736842106,
    "total_pack_energy": 13041,
}

From "SITE_CONFIG" we can get the following live metrics:

• Backup reserve percentage

"response": {
    "backup_reserve_percent": 30,
}

Maybe pypowerwall could retrieve the live metrics that are available from the cloud, and interpret those as the return values for the api url provided by the proxy. This would minimise other changes like to the telegraf config or InfluxDB CQ's hopefully?

So it should be possible to return some metrics from the cloud for the below telegraf inputs:

[[inputs.http]]
	urls = [
		"http://pypowerwall:8675/aggregates",
		"http://pypowerwall:8675/soe",
		"http://pypowerwall:8675/freq",
		"http://pypowerwall:8675/pod"
	]

With "aggregates" I think the "instant_power" values for solar, load, etc. can be set to the equivalent returned cloud power metrics (i.e. solar, battery, load, grid), however need to confirm for sure these values match.

For "freq" we can at least set the value for "grid_status" from the interpreted cloud response, but not much else unfortunately (I cannot find any voltages, frequencies, etc. from the cloud API).

For "pod" we can set values for "backup_reserve_percent" and the "PWx_POD_nom_energy_remaining" and "PWx_POD_nom_full_pack_energy".

However for "PWx_POD" values this may pose a problem for users with >1 Powerwall? The cloud response may not return individual Powerwall's "energy_remaining" and "full_pack_energy" but a combined value. I cannot test this as I only have 1 Powerwall.

The inputs below would not be possible, as the data is not available from the cloud by the looks of it.

[[inputs.http]]
	urls = [
		"http://pypowerwall:8675/strings",
		"http://pypowerwall:8675/temps/pw",
		"http://pypowerwall:8675/alerts/pw"
	]

Thoughts @jasonacox ?

[mcbirse]

I should have some time tonight to test cloud.py - if I see any issues and I know how to fix them, are you happy for me to push commits direct to the teslacloud branch or prefer a PR?

[jasonacox]

Yes, push the commits. I don't think I will have time to do anything tonight, and we can manage the merge details if they occur. I have the animation "flashing" problem replicated by switching to cloud only mode so I'm going to add local API URLs back one-by-one to see if I can isolate the one causing the problem.

[mcbirse]

Thanks, will do. I just set up in a test environment now and also see the animation flashing problem when switched to cloud only mode.

[mcbirse]

Pushed a fix for this error:

  File "/home/admin/.venv/lib/python3.11/site-packages/pypowerwall-0.7.0-py3.11.egg/pypowerwall/cloud.py", line 376, in poll
    solar_inverters = len(lookup(config, ("response", "components", "inverters")) or 0)
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: object of type 'int' has no len()

The "lookup" will return None as my site config data does not return a list of "inverters" at all. I guess only Powerwall+ owners will have "inverters" returned in the response.

"solar" -> "num_meters_aggregated" is "1" for me from the cloud though. I assume because components->solar is "true" with my setup, so will replicate that behaviour and set solar_inverters to 1 if true when unable to get count of inverters, otherwise 0.

I have 2 non-Tesla inverters, but my Powerwall doesn't know that.

[jasonacox]

Good catch! I merged it with my changes.

[ThePnuts]

Love that you guys already have a plan in place to cover some of the losses we may see.

For me, I like PW full charge capacity and temps.
My battery is only a little over a year old, but I like the idea of being able to see how it hold up with age and what my capacity is.
Temps is nice as my battery is in a garage and it can get hot here in the summer. I have on my todo list to setup an alert if it passes a threshold. Not sure if I would do anything though, so it might just be a thing I keep track off. I have an older electric car and the heat degrades the battery much quicker in the summer with use.

[jvanderaa]

I'm on the opposite end of this piece and need alerts when it gets too cold, so I can manually turn on a heater for a while in the garage.

[aristobrat]

I also love (and am grateful) that you guys are already working on a plan!

My prioritization would be: PW full charge capacity, string data, alerts, temps, voltages, frequencies. String data is second for me because I have seven strings (six arrays) and can't imagine trying to troubleshoot solar production questions/issues without comparing string data. String data made me feel OK about not having panel level data.

[wiltocking]

Just got hit with the update sadly. I also second these priorities, especially string data, we have north/south panels and it’s useful for troubleshooting to be able to see which is generating and when. Hope we can get some of that data back.

[furuike-oh]

My priority:
Live data feeds (Grid, solar, powerwall, home), as well as the associated monthly breakdowns.
String data (voltage, current, power) -- This helps me troubleshoot solar issues.
Full charge capacity
Temperature

The voltage and frequency data is nice but I don't need it as I have string panels.

[ripclaw786]

Jason, thank you for all your work on pyPowerwall.

My priorities are:

1. Charge capacity (this aided me in proving that one of my Powerwall's wasn't functioning as expected and Tesla flew out a replacement to me)
2. Temperature (my Powerwalls are in my garage and it gets really hot in Summer)
3. the live animation (I have the Powerwall dashboard open in a tab 24/7/365)
4. Frequency, voltages and alerts are nice so please keep them
5. Weather wouldn't be that important to me
6. String voltages, etc. and Inverter power are at the bottom of the list

Thanks.

[ibmaster]

Any tricks or suggestions on how to prevent Powerwall firmware updates? I'm stuck on release 23.12.11 and would be happy to keep it that way indefinitely to preserve the data-logging...

[jasonacox]

Good question. I thought about it myself. I don't know of a good way to do that that wouldn't impact other functions (including Tesla App).

I do have some good news. @mcbirse and I have been updating pypowerwall to use the Tesla Cloud to pull live data (the same current data you get via the Tesla app) every 5s. It will be able to give us power metrics (solar, home, grid, Powerwalls), grid status, and battery level. There are s few more data points but not all the others mentioned above. See teslacloud branch. I was also able to get the power flow animation to work without using local Powerwall access (using Tesla cloud data)

I'm hopeful we will still be able to get more data points. I'm exploring some options with others in the community. I'm also hopeful that Tesla will be generous in leaking some APIs to enable enhanced local monitoring. That would be a nice Christmas present. 😂🎄

[jasonacox]

The latest pypowerwall release, v0.7.3, adds the ability to use the Tesla Owners API (via TeslaPy) to pull basic information and some extended information (e.g. firmware version, Powerwall full charge capacity, etc.). This could be helpful for Powerwall 3 (and Solar only) owners that do not have local API access. For those with local access, the release also adds aggregate Powerwall nominal_full_pack_energy and nominal_energy_remaining values that can be helpful in determining the degradation of the Powerwall capacity over time. Many probably used this data in the past from the vitals data. It is aggregate (total for the site) instead of separate (vitals data had it per Powerwall).

See release notes starting with https://github.com/jasonacox/pypowerwall/releases/tag/v0.7.1. This doesn't restore the rich data set in the vitals API but it does provide some. We continue to be hopeful that we will see an opportunity to restore more of the vitals data set for those that have lost it.

[BJReplay]

@jasonacox I just saw the last comment in this issue over at vloschiavo/powerwall2#55 (comment) which mentions a possibility for continuing to get the vitals out of the powerwall via capturing the Bearer token after logging in as customer. Since (I assume - making a big assumption having not grabbed the code of pypowerwall) that you're logging in as customer since you ask for the login details you may be able to grab the bearer token to use it to grab the vitals (if you're not already doing this).

[larosseqnx]

Running 23.44.0 If you could let me know how to use the above I would be happy to post back the experience.

[jasonacox]

Hi @larosseqnx - Some have already confirmed that the vitals API endpoint is gone in 23.44.0, but you can still test it. Copy the python code above and paste it into an editor, edit the PASSWORD and HOST, and save it as test.py (or something similar). Run python3 test.py

[longzheng]

I didn't use this script but tested Postman directly, even with the bearer token the /api/devices/vitals endpoint returns 404 with the bearer token. I tried either customer or installer login.

GET /api/devices/vitals HTTP/1.1
Authorization: Bearer REDACTED
User-Agent: PostmanRuntime/7.36.1
Accept: */*
Host: 192.168.1.68
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
 
HTTP/1.1 404 Not Found
Content-Type: text/plain; charset=utf-8
X-Content-Type-Options: nosniff
Date: Tue, 23 Jan 2024 07:37:15 GMT
Content-Length: 19
 
404 page not found

[jasonacox]

Thanks @longzheng - yes, starting with Firmware 23.44.0, the vitals data API endpoint has been removed (hence 404). The authentication mode doesn't seem to matter.

[longzheng]

No worries, yes I'm aware but just wanted to sanity check this in case it was overlooked for some reason.

[larosseqnx]

Data from api/meters/aggregates:
{'site': {'
lots
of
stuff
'}

Attempting to get data from Powerwall at https://224.0.0.100/api/system_status/soe
Data from api/system_status/soe:
{'percentage': 26.105108954403956}

Attempting to get data from Powerwall at https://224.0.0.100/api/devices/vitals
Error: 404, 404 page not found

ERROR Unable to get api/devices/vitals:

[jasonacox]

Thanks @larosseqnx ! That confirms what we believe is true. Starting with Firmware 23.44.0, the vitals data API endpoint has been removed (or changed). The authentication mode doesn't seem to matter.

If anyone has 23.44.0 and is savvy with Developer Tools in Chrome, it would be good to see if there are any new APIs that show up when you log in to the Powerwall Gateway portal (TEG) and flip through the different menu screens. Getting some screenshots would be good to compare with prior firmware versions.

[BJReplay]

If anyone has 23.44.0

Not Yet

is savvy with Developer Tools in Chrome

I've fought my way out of websites that haven't wanted to play nice before :)

I've also played around wireshark and transparent proxies and packet capture when I've had to to consider poking around to see what can be seen with Tesla Pros - but I think that's probably a dead end, because - at least for my testing, it required a hard login (toggle the switch on the Powerwall) to authenticate even with older firmware, so even if it exposes where the end points are - and that could be useful - if they are only exposed via Telsa Pros, and that is only available via toggling the switch...

[jasonacox]

Tesla Pros ... dead end

I tend to agree. It may be useful information to have, but as we have also seen in #392, the payloads are binary (Protobuf) and require local access with the toggle. Also, without care, it seems like a query required to get device info has the potential of changing the config (possible danger and likely gonna void any warranties).

I'm still hopeful that we will see a new and better path open up to give us some if not all of the data lost by the firmware upgrade.

Also, in the event that we lose all API access (similar to the new Powerall 3), pypowerwall can be configured to use the Tesla Owners cloud data to provide the same APIs (minus most vitals). An update for Powerwall-Dashboard is being built to accommodate: see #414.

[jasonacox]

🔥 CRITICAL Upgrade - Please take a moment and upgrade your installation of Powerwall-Dashboard to get the latest pypowerwall proxy. The latest release includes a critical patch that fixes 404 HTTP status code handling for API calls. Older versions of pypowerwall will cause a repeating loop of login attempts to the Powerwall Gateway, eventually resulting in rate limiting and failure to get any metrics.

NOTE: If you have firmware 23.44.0 you are impacted due to the removal of the /vitals API endpoint causing a 404 File Not Found error. PLEASE UPGRADE AS SOON AS POSSIBLE.

🟢 Powerwall-Dashboard - Version v3.0.8

Also, if you are using the pypowerwall python library for your own scripts, make sure you upgrade to the latest version (v0.7.6).

[furuike-oh]

Please remind me how to upgrade?

[jasonacox]

Hi @furuike-oh - You can use the upgrade.sh script located in the Powerwall-Dashboard directory.

[jasonacox]

Update on Efforts

As more of the community get the firmware 23.44.0 upgrade (which removes the vitals API), I figure it is time to do a quick update on efforts.

The general speculation is that Tesla was planning to remove all local (LAN based) customer accessible APIs and shift to the Tesla App for customers (cloud based) as the only way to get this data and the Tesla Pros app for installers and advanced metrics. The vitals API is the first to go. The Powerwall 3 was released with NO local API and NO web portal access (see #387 ).

I understand that Tesla needs to upgrade the system to serve all their customers, making the installation and use a better experience for everyone. That may impact those of us automation/data enthusiast, who are using unofficial APIs to get our data or control our systems. However, I'm also optimistic that we will be able to find a new way to get at least the basic data via local APIs and even hopeful that we may get more with some additional work.

Some work is already going on in this area:

• Cloud Based Option - This project and pypowerwall will support a Tesla Cloud based mode very soon (doing last testing with @mcbirse - who has done much of this work! 🙏 ). We originally started this effort to enable Tesla Solar-only owners to use the same dashboard, but this has the advantage of working for every Tesla Energy system (including Powerwall 3). If all the APIs are removed, this will be a path to still gather and display live data via the project.
• Tesla FleetAPI - I have been exploring and adding tooling to support the official Tesla API (also cloud based) for accessing Tesla Energy products for monitoring and control. This may be a better approach than the unofficial Tesla Owners API and the TeslaPy python API that many projects like ours are using to access Tesla systems (including Vehicles) via the Tesla Cloud. It requires a bit more setup work but at least the APIs are published by Tesla.
• Tesla Pros API - This new locally accessible API is not very accessible. It is only available on the Gateway WiFi access point and oriented toward setup instead of monitoring. Also, it likely has a wide blast radius for destroying your system (and warranty for that matter) if used incorrectly as it is made for the installer (always in Wizard mode). I'm hopeful there will be another less risky path.

More coming... As I said above, I'm still hopeful that a local API will persist (hopefully with some vital like data 🙏 ) or be created soon (for Powerwall 3). Having a local portal and related API set is extremely helpful for power and internet outage events. I believe all Tesla Powerwall would benefit and appreciate that. If you agree, please 👍

In general, I have heard feedback from the community that these data points which are at risk, are priorities (with ☁️ indicating available via Cloud Mode and available with latest pypowerwall release, ❌ indicating only available via local access pre-23.44.0, ⚡ indicates available via local access post 23.44.0 and ✅ indicating no risk)

• Basic Live Power Data (Solar, Grid, Home, Powerwall, Battery Levels) ☁️⚡
• Powerwall Full Charge Capacity (for degradation trending) ☁️ ⚡
• Live Animation of Power Flows ☁️ ⚡
• Version Data (Firmware, ID) ☁️ ⚡
• Alerts ❌
• Solar Panel String and Inverter Data (voltage, current, power) ❌
• Powerwall Temperatures ❌
• Frequencies and Voltage ❌ ⚡(some)
• Weather Data (this doesn't come from Tesla so it is not impacted) ✅

[jasonacox]

I don't think there is anything in the cloud that is not also available via local LAN endpoints, even post 23.44.0. In fact, the local will have a bit more information. I might have confused things with the graphics above (or maybe I'm missing something?).

[furuike-oh]

I was under the impression that Powerwall capacity was available through the cloud API but not the local API. Am I incorrect?

[jasonacox]

I have great news for you! We found the capacity data for each Powerwall in the local /api/system_status call and in v4.0.0 we added logic to pypowerwall proxy to use that data for Powerwall capacity even if the vitals API is removed (some visual here).

The cloud has Powerwall capacity, but only aggregate (total), not individual Powerwall, so you will want to use the local API if you can. Powerwall 3 users will still only have the cloud data.

[DerickJohnson]

Man, I'm always so happy to see how far ahead you guys are on this stuff. I rely on the alerts (troubleshooting) and individual battery metrics (for Self Generation Incentive Program). For the alerts, I may have mentioned it in another post here, but for months no one could figure out what was wrong with my system, it just wasn't working and customer service kept blaming wifi. They replaced several parts, including the gateway. Once I had the alerts set up in my dashboard, I saw the inverter comms flagging and so I went to the comms connection on one of my inverters and kept the alerts open while moving some cables around (carefully, of course). I noticed immediately that the comms signal went solid, and if I held the cable in that position, eventually the system came up. So I just reinforced both sides of that comms cable and it worked! Also for SGIP, I needed individual battery monitoring, but PG&E claimed that Tesla said it was impossible to monitor batteries individually through a single gateway, so I needed the individual battery data to show that they were indeed monitorable for discharge info.

All in all, this project has been immensely helpful and satisfying to just have available when needed. Whatever can be maintained is awesome, and I'll start poking around as well! Thanks for the great work!

[jasonacox]

What a great story @DerickJohnson !!! Thanks for sharing the details. More good reason why we need customer accessible data and how helpful it can be. 😁 And thanks for the encouraging words. 🙏

[larosseqnx]

Alerts, IMO would be the Vital Vitals, then Freq/V.

What does teh process of altering from local data acquisition to cloud based data acquisition look like?

[jasonacox]

Good point @larosseqnx - I re-stacked the list in more priority rank for the vitals.

What does teh process of altering from local data acquisition to cloud based data acquisition look like?

In the future this will be done by re-running setup.sh and selecting cloud mode. Until that PR (#414) is merged, you can still do this manually following these instructions: #414 (comment)

[larosseqnx]

@jasonacox wonderful thank you much. Will stand by for merge :)

[ceeeekay]

HI there, I've just been affected by 23.44.0 and loss of vitals - most importantly for me, the charge info per battery.

I do notice some of the same info is available in an array from /api/system_status in the battery_blocks object.

Would this be a good way forward for now, or would we expect this endpoint to also be removed?

The reason I'm so interested here is that one of my PWs seems to be losing a lot of capacity (23%) after only 3 years, and the other one is new as of last week, so I'd like to keep an eye on these.

[Stephen2615]

@ceeeekay A bit off topic but have you asked Tesla about losing so much charge capacity over three years. Also, I tried the @jasonacox update and I can see Frequency data not that it is useful in any way that I can think of.

[jasonacox]

I can see Frequency data not that it is useful in any way that I can think of.

Thanks for confirming! The new v4.0.0 build has been released for anyone wanting to upgrade (upgrade.sh).

As to frequency data, I used it to help troubleshoot odd behavior by some of our electronic equipment. We had a sensor and air supply system that would lock up and need to be power cycled. It turned out that it would not handle frequencies that dropped below ~59.5hz which will occur during Island mode (power outage) events. The air system pushed a software upgrade and we haven't seen it occur again, but it was helpful in spotting the cause.

[aristobrat]

x2 on using frequency data to troubleshoot odd equipment behavior during island mode (power outage) events.

[ceeeekay]

@Stephen2615 It will be a discussion I have with them or the installer in the near future. For now it hasn't lost 30% within 10 years, so I know exactly what Tesla's response will be, hence me wanting to keep an eagle eye on the capacity for the time being.

I might run it by the installer anyway in sort of "Hey this is likely going to be an issue soon" approach, but for now I'll leave them alone because I asked a lot of questions post-install of the second PW and panels last week, and they're a bunch of nice guys and I don't want to overly annoy them :)

@jasonacox

Awesome! Thanks for testing.

YW! Thanks for the awesome dashboard! It's nice to finally have everything in one place instead of the many bits and pieces I had installed around home.

[thekev]

Yeah. The frequency data is how I learned to contact Tesla and have them reduce my off grid inverter shutdown frequency. All my UPS were freaking out, even the Eaton double conversion unit. The cause was obvious with that data.

I’m so mad they removed vitals. Why? BFD! Just let it rot. It’s more work to remove than to ignore. Shrug.

[anderep]

Will or has PD been updated to get data from second wifi adapter connected to teg?

[fasternfaster]

What is needed to make it work with 2 gateways? Do I need to hardwire them? I don't think 2 separate Wi-Fi networks on top of my own mesh is good.

[jasonacox]

I'm sure there are other experts here that may be able to help us. However, if it were me, I would set up a Raspberry Pi hardwired to my LAN and then create multiple WiFi networks on the RPi, one to each of the Powerwalls. Technically you wouldn't have to hardwire to the LAN and could create 3 WiFi networks onthe RPi (your mesh + PW1 + PW2) but I haven't tried that. I would not add routing so it would not bridge the networks but the RPi would see all of them so it would be able to run the Dashboard to query the PWs.

[mcbirse]

Here's another idea for people looking to do this... and this is what I've done.

I actually did want to bridge the TEG installer WiFi to my local LAN, while also maintaining the direct ethernet connection to the Gateway at the same time, since I knew this was working well and very stable and I still wanted to use that as the primary endpoint for polling by pypowerwall.

Also, I didn't want to spend time messing around with a multi-homed system setup as it's a PITA sometimes. I was just looking for a simple / quick / cheap solution.

So, I bought a TP-Link TL-WR802N Wireless Nano Router which can operate in a few different WiFi modes.

In my case, I set it up in WiFi client mode connecting to the TEG installer WiFi. On the LAN side, I connected the nano router to a DMZ on my firewall, but you could just connect to a switch depending on your local LAN setup and how you configure the nano router LAN interface.

I looked at some alternate products to the TP-Link, from GL.iNet I think, which could also be configured to do the same or more.

I ended up using the same ethernet cable for both my direct ethernet connection to the gateway and the nano router... Previously I had an electrician run a cable through the house from the home office / network equipment to my garage where the gateway is..... but only 1 cable! In hindsight I should have had 2 cables run. Meh.

I didn't want to spend another $600 on an electrician so ended up using a network splitter at each end to utilise the one CAT 5 cable (gateway port only supports 100Mbps anyway, so that's fine). Below is the splitter and the nano router mounted near my gateway.

A very neat solution at the end of the day.

The nano router is connected to the TEG installer WiFi, and being close to the gateway the connection is actually very fast and stable. It's bridged to my LAN so I have access directly to 192.168.91.1 from any host on my network.

And, I still have the original direct ethernet connection to the gateway available as well, which I use as the primary data source for pypowerwall.

Hopefully this helps someone... using a cheap WiFi nano travel router can be a viable solution and works well for me.

[jasonacox]

That's brilliant @mcbirse . Simple connection for those of us with one TEG (no RPi to configure). I have to get one to try.

I don't know if it would love the multiple gateway problem. I looked at the manual but doesn't look like it runs NAP in client mode but I can't tell. That would be needed if you had two TEGs and wanted two of these.

[anderep]

I added second wifi adapter to my RPi for Gateway access.

[aristobrat]

• Gateway Support - This will allow access to the /tedapi API on the local Powerwall Gateway WiFi and will map back most of the data points we had in /vitals. Of course it requires connecting to that WiFi access point.

@jasonacox, for folks with multiple PWs, does this provide string data from all of the PWs?

[jasonacox]

I only have one so I can't confirm, but it should.

[BJReplay]

I set it up in WiFi client mode connecting to the TEG installer WiFi.

Is there any reason why you couldn't set up a WiFi client directly on your router if it can reach the gateway and it supports running WiFi interfaces in both AP mode and client mode at the same time?

My GateWay and Router are in the same equipement cupboard. They're currently wired together directly by ethernet (of course), but I'm running OpenWrt and believe I should be able to add a client interface to a radio at the same time as an access point interface.

I don't know enough not to be dangerous, but I'm hard wired from my PC to my router, so I'm tempted to just try it...

[jasonacox]

You are right. It feels like there are a lot of ways to make this work. It would be great to hear what works and collate that into the setup instruction as options. Of course, I still need to get the code working in pypowerwall. Back to coding... ;)

[BJReplay]

It works.

Running OpenWRT (23.05, but I feel this should work for all recent-ish versions).

I used https://openwrt.org/docs/guide-user/network/wifi/relay_configuration as a bit of a pointer, but the steps were pretty simple:

All screen shots in dark mode (I couldn't be bothered switching to light mode and blinding myself)...

You could also do this via the command line if you're smart, but I'm not.

Once logged into your router GUI, choose Network, Wireless

Choose your 2.4GHz radio, hit Scan

Select your Powerwall Gateway, hit Join Network

Key in your password - it varies depending on the age and generation of your gateway.
Make sure you don't replace the wireless configuration for the radio - you want to add this to existing configs (so you keep any existing access point configurations).
Make sure you change the firewall zone from wan to lan.
My screenshot also shows wwan as I took this screenshot after I'd already proven this worked.

Hit Submit

On the next screen, you shouldn't need to change anything, just hit save.

Then hit Save and Apply.

You may lose internet access at this point, as your router may prefer the newly added wwan connection for internet access. Don't worry, we're about to fix it.

Go to Network, Interfaces,

Choose wwan (newly created), click on Edit

Turn off Use default gateway
Turn off Use DNS servers advertise by peer

Hit Save
Hit Save and Apply

Stop your new wwan interface.

Restart your main internet interface - this will ensure that your router knows to get internet access from your main internet wan connection, and not the newly created wwan connection.

Start your new wan interface.

Browse to 192.168.91.1

Bask in the glory of being able to connect to your powerwall via the TEG WiFi interface via your LAN.

[jasonacox]

Nice job @BJReplay !!!

[Stephen2615]

Just when I thought I had some free time. I just happen to have an Asus R7000 laying around my place doing nothing. Let me see if I can destroy it.