Steps to connect wired LAN to TEG WiFi using GL-iNet Opal travel router

[youzer-name]

I originally posted this in a thread on firmware updates, but that thread is getting very long and covers a lot of related topics, so I thought it might be useful to re-post this under its own thread to make it easier to find in searches.

There are a few different solutions that have been posted to connect to the TEG WiFi to enable vitals data using either a WiFi adapter on the PWD host or via a travel router-type device. I went with a travel router and chose the GL-iNet Opal model due to its reasonable cost ($35 on Amazon when I bought it) and OpenWRT-based firmware which I was familiar with from my main router. I was able to run an Ethernet cable from my main router to a spot near by Powerwall Gateway, so I set this up with a wired connection from the LAN to the Opal.

My setup is complicated by my choice to put the Opal on my IOT VLAN while my PWD host is on my main VLAN, so users with a simpler network setup may be able to skip some of the steps that I needed.

The overview of the connection is (devices in bold, connections in brackets):

PWD <--Main VLAN Ethernet 192.168.0.x--> Main Router <--IOT Ethernet [192.168.2.x] --> Opal <--WiFi [192.168.91.x]--> TEG

Here is a slightly edited version of my original post from #109 (reply in thread)

---

• I'm using a GL-iNet SFT-1200 (Opal) travel router and my main router is a GL-iNet MT6000 (Flint 2) running the op24 branch of their firmware.
• I put the Opal on my IOT VLAN which is where my wired connection to the Powerwall Gateway resides. My PWD runs on my main VLAN.
• I didn't initially change anything on the LAN settings of the Opal. It was originally broadcasting its 2.4 and 5 GHz WiFi networks and using the default 192.168.8.1/24 subnet for the LAN. After everything was set up I disabled the Opal's WiFi access point interfaces
• The first thing I did was use the link on the Opal's main "Internet" page to activate the repeater mode. I scanned for networks and connected to the TEG network
• I connected the WAN port of the Opal to my IOT network via Ethernet. My router assigned it an address of 192.168.2.215 and I set that as a static lease on the main router. The travel router needs a static IP or a static lease so routes can be created
• I went to the Opal's OpenWRT interface (from main screen: Advanced -> click link to LuCI) and made some changes:
  • In Network -> Interfaces, I selected the TEG network and went to the firewall settings. I created a new firewall zone called "wwan".
  • The wired connection was in a zone that included both wan and wan6. I think the TEG connection was also in the same zone at first, but I thought it would be easier to have separate zones so I could manage the forwarding between them
  • In Network -> Firewall, I set the wan zone to allow input so I can manage the router from the main LAN side
    and set forwarding to/from the wan and wwan zones so the traffic could pass between the networks. I enabled masquerading and MSS clamping on the WWAN zone

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. I don't think this is needed if your PWD host is in the same VLAN as the WAN/ethernet side of the Opal.

In Network -> Static Routes:

• Back in the GL-iNet GUI, under Network -> Multi-Wan, I clicked the settings gear icon for both the Ethernet and Repeater networks and turned off the internet status tracking so it would keep the network available even when there was no internet connection detected.
  • This is an easy-to-miss key step. By default the Opal will try to manage multiple WAN connections and will not use any connections where it can't ping the internet. This is obviously always the case for the TEG network, and I don't want it dropping the wired connection back to the main LAN if the internet goes down, so I disabled the health check on both networks.

On the main router I added a static route for the gateway's subnet:

• Under Network -> Routing -> Static IPV4 Routes I added a rule to route traffic for the TEG network via the LAN IP of the Opal.

Finally, I had to do one last step on the main router. I route all of my internet traffic via a VPN, and if I didn't add these last two rules, other IPV4 rules would send the traffic out via the VPN. This step shouldn't be needed for anyone with a simpler network setup.

Under Network -> Routing -> IPv4 Rules, I added rules to route the traffic in both directions.

If you use this guide and find any issues or have suggestions for improvement, please let me know.

EDIT: Adding one additional step to ensure the TEG connection comes back up after a router reboot. The GL-iNet routers do not start the 'Repeater' connection if the router reboots. To ensure the connection auto-starts, you can disable the repeater function as follows:

From the OpenWRT interface:

Go to System -> Startup, find "repeater" on the list, click the 'Enabled' button. It will change to show 'Disabled'.

The 'Repeater' interface on the GL-iNet main page where you first connected to the TEG network will no longer be displayed. You can access/edit the TEG WiFi connection from the OpenWRT interface under Network -> Wireless

[jasonacox]

Thank you @youzer-name !

[cstout1]

Thank you for posting this and especially for the added repeater edit at the bottom. I came back to see if anyone had a way to auto-connect the repeater connection as it appears my gl.inet has been rebooting occasionally and then I have to go back and use tesla-history.py to fill in the blanks. Hoping this does the trick to keep that connection persistent.

[rick-davis-39]

good write up, I'm doing something very similar (without the complexity). OpenWrt lan to my subnet for Dashboard/pypowerwall proxy & wwan to Powerwall AP. Couple of questions, have you observed that MSS clamping is a necessity on wwan and have you had any instances where you could still ping the wwan interface but not the PW AP (192.168.91.1)? I ask this as pypowerwall has not received data on a few occasions with this setup and any insight from other OpenWrt users may help me help narrow down the issue. No obstacles between client & AP, -30 to -35 dBm signal. System/kernel logs during periods of brief insability show no issue. Restarting the interface resumes normal operation which indicates to me that the PW AP is happy. Setup below:

I am using an IP Set for allowed clients and management. Basic FW rules for access. I chose to do it this way as I prefer global deny. No issues here.

[youzer-name]

good write up, I'm doing something very similar (without the complexity). OpenWrt lan to my subnet for Dashboard/pypowerwall proxy & wwan to Powerwall AP. Couple of questions, have you observed that MSS clamping is a necessity on wwan and have you had any instances where you could still ping the wwan interface but not the PW AP (192.168.91.1)? I ask this as pypowerwall has not received data on a few occasions with this setup and any insight from other OpenWrt users may help me help narrow down the issue. No obstacles between client & AP, -30 to -35 dBm signal. System/kernel logs during periods of brief insability show no issue. Restarting the interface resumes normal operation which indicates to me that the PW AP is happy.

I haven't noticed anything related to MSS clamping. I have to admit I don't fully understand what that option does, but from what I read, it seemed like it was harmless if on, but potentially could avoid issues that would occur with it off.

I also haven't noticed any instability on the connection. I did have the Opal reboot for an unknown reason the other day, which is what led me to add the note about disabling repeater mode so the WiFi would reconnect after a reboot. I was having occasional momentary data drops that were self-correcting, but I don't think I've had a single one of those since using the Tesla One app to disable the gateway's WiFi connection to my LAN. So my only connections now are Ethernet between the gateway and LAN on my IOT network, and WiFi between the Opal router and Gateway on the TEG network.

I suspect that asking the gateway's WiFi to try to act as both a client and an AP was the cause of those occasional short interruptions. The whole reason I went to the travel router is that I had found that my Flint 2 router, while technically capable of running a 2.4 GHz AP and client at the same time, was not doing it well. I had frequent connection issues that I was auto-correcting via a script, and I had one IOT device that would not stay connected to my router's IOT WiFi until I removed the TEG client network from the main router.

[rick-davis-39]

thanks, maybe disabling the PW Wifi as a client might be the way to go given that I also have ethernet to PW. It's very hard to trouble-shoot given the fact that everything could be rock solid for a week or more without any connection drops and then it occurs. Mostly self correcting.

[cstout1]

Too early to tell, but Tesla might have made another change. As of early this morning I can no longer connect to the TEG-XXX network via Opal or computer.

Edit: A reset of the TEG (quick method, hold red button for 5 seconds) actually worked to restore the connection. Not sure if maintaining this direct wifi connection is stressing the TEG's wifi card.

[jasonacox]

What version of the dashboard (pypowerall) are you running? The more recent one (pypowerwall v0.13.2) has logic to reduce the load on the TEDAPI endpoint which may help.

[cstout1]

Currently on Version: 0.14.0 Proxy t80 and keeping my eyes on it. Connection seems to drop every couple days but the reconnect on boot setting seems to be working for me. The inability to connect at all to the TEG-XXX SSID is definitely a new issue and one I hope was a fluke. I'll be sure to report back if it happens again - not that there's much that can be done, but at least we'll have a point of reference for new behaviors to be on the lookout for.

[jasonacox]

Also, keep an eye on http://localhost:8675/health - It contains data about the health of the endpoints, like:

{
  "/vitals": {
    "total_calls": 78361,
    "successful_calls": 78356,
    "failed_calls": 5,
    "success_rate_percent": 99.99,
    "last_success_age_seconds": 0.12461471557617188,
    "last_failure_age_seconds": 176752.1493856907
  }
}

[youzer-name]

Also, keep an eye on http://localhost:8675/health - It contains data about the health of the endpoints, like:

I have a Powerwall 2's with a Gateway 2, so I get no strings data from my non-integrated inverters (one old Solar City Fronius, one SolarEdge). I see that all of my failures are in the /strings endpoint, which does not return any data for my system. Even though the failures are only .5% of the requests, the other 99.5% aren't returning any data. Is there a way to disable the strings endpoint in pypowerwall?

Output from /health:

{ "pypowerwall": "0.14.0 Proxy t80", "cache_ttl_seconds": 30, "graceful_degradation": true, "fail_fast_mode": false, "health_check_enabled": true, "startup_time": "2025-07-28T07:57:45", "current_time": "2025-08-01T10:05:57.182051", "proxy_stats": { "total_gets": 596827, "total_posts": 0, "total_errors": 0, "total_timeouts": 2090 }, "connection_health": { "consecutive_failures": 0, "total_failures": 1579, "total_successes": 945998, "is_degraded": false, "last_success_time": 1754057155.47336, "last_success_age_seconds": 1.70884537696838 }, "cached_data": { "cache_size": 3, "endpoints": { "/aggregates": { "age_seconds": 2.15124845504761, "is_expired": false }, "/soe": { "age_seconds": 2.15548157691956, "is_expired": false }, "/strings": { "age_seconds": 1.78107070922852, "is_expired": false } } }, "endpoint_statistics": { "/aggregates": { "total_calls": 73804, "successful_calls": 73804, "failed_calls": 0, "success_rate_percent": 100, "last_success_age_seconds": 2.1512610912323 }, "/soe": { "total_calls": 70658, "successful_calls": 70658, "failed_calls": 0, "success_rate_percent": 100, "last_success_age_seconds": 2.15549564361572 }, "/strings": { "total_calls": 70658, "successful_calls": 70307, "failed_calls": 351, "success_rate_percent": 99.5, "last_success_age_seconds": 1.78109240531921, "last_failure_age_seconds": 52.1510920524597 } } }

[jasonacox]

Hi @youzer-name - you would need to remove it from telegraf.conf:

Powerwall-Dashboard/telegraf.conf

Lines 101 to 114 in 00a8b05

	[[inputs.http]]
	urls = [
	"http://pypowerwall:8675/aggregates",
	"http://pypowerwall:8675/soe",
	"http://pypowerwall:8675/strings",
	"http://pypowerwall:8675/temps/pw",
	"http://pypowerwall:8675/freq",
	"http://pypowerwall:8675/pod",
	"http://pypowerwall:8675/fans/pw"
	]
	method = "GET"
	insecure_skip_verify = true
	timeout = "4s"
	data_format = "json"

Technically /strings just calls the same API as vitals and parses out the string, then caches the vitals payload. In TEDAPI, that means caching the /teadapi/status endpoint which is used by other calls. If you remove strings from the telegrapf polling, those errors could just migrate to another endpoint (since /strings was just playing the role of filling the cache for other calls).

[cstout1]

Well, I got 9 days and now I can't connect to TEG-XXX again. Such a bummer.

{
  "pypowerwall": "0.14.0 Proxy t80",
  "cache_ttl_seconds": 30,
  "graceful_degradation": true,
  "fail_fast_mode": false,
  "health_check_enabled": true,
  "startup_time": "2025-07-29T16:43:03",
  "current_time": "2025-08-08T12:34:02.799319",
  "proxy_stats": {
    "total_gets": 1600358,
    "total_posts": 0,
    "total_errors": 84,
    "total_timeouts": 59685
  },
  "connection_health": {
    "consecutive_failures": 0,
    "total_failures": 41132,
    "total_successes": 2375247,
    "is_degraded": false,
    "last_success_time": 1754681640.56425,
    "last_success_age_seconds": 2.23507690429688
  },
  "cached_data": {
    "cache_size": 3,
    "endpoints": {
      "/aggregates": {
        "age_seconds": 2.61112666130066,
        "is_expired": false
      },
      "/soe": {
        "age_seconds": 2.78765916824341,
        "is_expired": false
      },
      "/strings": {
        "age_seconds": 2.35256743431091,
        "is_expired": false
      }
    }
  },
  "endpoint_statistics": {
    "/aggregates": {
      "total_calls": 209837,
      "successful_calls": 209825,
      "failed_calls": 12,
      "success_rate_percent": 99.99,
      "last_success_age_seconds": 2.61105561256409,
      "last_failure_age_seconds": 798831.642764568
    },
    "/strings": {
      "total_calls": 169544,
      "successful_calls": 161938,
      "failed_calls": 7606,
      "success_rate_percent": 95.51,
      "last_success_age_seconds": 2.35257053375244,
      "last_failure_age_seconds": 17.7114598751068
    },
    "/soe": {
      "total_calls": 169544,
      "successful_calls": 169540,
      "failed_calls": 4,
      "success_rate_percent": 100,
      "last_success_age_seconds": 2.7876615524292,
      "last_failure_age_seconds": 798832.663225174
    }
  }
}