Improve route documentation and add example

[Nexarian]

When using the TEDAPI over a LAN from Linux, it's critical to add a network route. However, I wanted to do this programmatically from Python before calling pypowerwall to get data.

This adds what I've learned and two example functions showing how to do just that.

[jasonacox]

Thanks @Nexarian !

You have a good point about making it easier for people to add the route. A contributor on the Powerwall Dashboard project provided this script that adds the route for multiple OS variants. It may make more sense to just add that here.

Here is the script: https://github.com/jasonacox/Powerwall-Dashboard/blob/main/add_route.sh

Your example is great for Linux. A significant portion of the community is using MacOS and Windows. I'm good with it as an example we can include and reference, but we should also mention add_route.sh option or add support for the other OS variants.

[Nexarian]

1. I'm surprised your documentation did not include onlink -- That is required for my use. Onlink appears to be a networking version of sudo or force. The OS simply assumes the route exists without validating. I couldn't find easy equivalents on Windows or Mac OS, but I didn't search very hard.

2. I am currently using WSL2. The add_route.sh script says that doesn't work. It does, I've included instructions in the PR that show how. You have to have a bridged network.

3. Good point about people using it for Mac OS & Linux. I haven't tested for either of those. Right now, I'm still trying to get Powerwall Dashboard to work at all on my 2x standalone inverters with a goal of running it from my Raspberry PI. Because I also want string data, I have to find a way to add route 1, consume data, delete route 1, add route 2, consume data, delete route 2, repeat just for that portion of the data. I'm not yet sure how to do that. I'm also trying to figure out how to redirect the influxdb storage to an external platter drive, as those are better for persistent read/write storage than a PI SD card (I know that time-series databases burn up SD cards).

4. We should pick where these instructions live, and then put ALL the data about it there and simply link to it. If it's more useful for Powerwall Dashboard, great. I see no reason why we can't have examples in both Python and bash.

You may also find this reddit thread useful: https://www.reddit.com/r/TeslaSolar/comments/1d4vpkg/teg_network_access/

[jasonacox]

I'm surprised your documentation did not include onlink

I'm not familiar with onlink and couldn't find anything in a search. Do you have more info? In any case, we would want a solution that works for the main supported platforms at least for the Dashboard project (Linux, MacOS, Win, RPi).

am currently using WSL2. The add_route.sh script says that doesn't work. It does

I'm not a Windows guru, so I probably didn't fully test this but the community reported that route changes in WSL do not stick (post reboot) and to get a persistent route set on the machine, the recommendation was to use the windows cmd route -p add ${TARGET_IP} mask ${NETMASK} ${PW_IP}. If there is a a better way, it may be good to add that.

We should pick where these instructions live, and then put ALL the data about it there and simply link to it. If it's more useful for Powerwall Dashboard, great. I see no reason why we can't have examples in both Python and bash.

I'm not sure I fully understand. I suspect you have a brilliant idea here. Technically this is the repo for the python pypowerwall library that builds the pip package. I think this is the best place to put the python examples for routing and link to the bash option on the Dashboard page. Is that the idea?

[Nexarian]

onlink means that the routing should "pretend that the nexthop is directly attached to this link, even if it does not match any interface prefix" Source

It's not a Linux specific concept. Windows has it too, but it hides it more. Mac OS, being a Linux variation, will also have this buried in its settings. It's considered an advanced "You should probably not use this, because if you need this your network is probably misconfigured" setting. Yes, the way Tesla does this does break some rules, so we have to as well.

I suspect you have a brilliant idea here.

Not really, just rigorous. I want one source of truth. That can live in either package. Whichever package doesn't have it should link to the documentation in the other.

I think this is the best place to put the python examples for routing and link to the bash option on the Dashboard page. Is that the idea?

No. Because now we STILL have two sources of truth. And any changes or updates to knowledge on this topic will require a PR to both packages. I want a one-stop-shop for all things related to the complex and arcane IP routing requirements that Tesla makes us do. We're likely to continue to learn more, and if there are multiple copies, they will diverge and bit-rot.

The counterargument could be that users of Powerwall Dashboard shouldn't need to dig into the minutia of pypowerwall to make things work... True, that should be completely automated by the setup script, but due to some of the issues with how this works we're not there. This is an advanced sandbox, and we have to respect that our users are intelligent enough to play in it.

To pivot this example: This ecosystem only has one list for all the alerts that we've seen from Tesla solar products. You might imagine that Powerwall Dashboard would have a copy of the list too, for the same reasons described above "We don't want to make users look at pypowerwall." Still, why would you duplicate the list?

[Nexarian]

As to WSL: I need to do more testing, I'll get back to you. Also my Raspberry Pi 3 is just too slow (not enough RAM) to make this happen, so I've ordered a 5 to see if I can get things working on that.