Connecting to Inverter from Public Internet

[hulkster]

Long-time lurker who has admired this project since I started the "journey" earlier this year ... and (finally) got Solar running a month ago. FYI FWIW that I had a wrap-up interview with Project Advisor Manager and told them that "next time you are in a meeting with Elon (LOL!), show him the Powerwall-Dashboard."

My question is about connecting to the Inverter from the Public Internet. It appears that most people connect from "inside" their house LAN ... but I'm thinking of pulling the data from a computer "outside" my house - i.e. from the the public Internet. I run a dedicated server (running AlmaLinux9) so it would be nice to host it there.

Obviously I need to "expose" the inverter so it's accessible ... and putting it in the DMZ (i.e. full access) would not be a good idea. I'm guessing that Powerwall-Dashboard pulls everything via requests to port 80, so that's all I need to expose ... and since I'd remap it to something else (plus restrict IP address to my server), I assume that's easily changeable.

I went through the Discussion threads and didn't see anyone talk about doing this ... but can't believe I wouldn't be the first to consider it. Any comments on my idea?

Thanks!

P.S. The Tesla Inverter (7.6kW 1538000-45-A) is currently running 23.12.3 - it won't allow login via the webpage as it redirects to the "use the Tesla Pro's App" screen. While using the App does work (and shows me per-string data which I'm particularly interested in), obviously something like Powerwall-Dashboard is MUCH better!

[BJReplay]

I went through the Discussion threads and didn't see anyone talk about doing this ... but can't believe I wouldn't be the first to consider it. Any comments on my idea?

Here you go - #107

[bparruck]

I think it is a bad idea, primarily being the security risk. Also, if you pulling the data every 5s, that's quite a bit of traffic. A better solution may be to host the powerwall proxy (pypowerwall container) on a small computer inside the network and create another container on the same computer to read the data from proxy and to post the data to the cloud for storage and analysis.

[jasonacox]

If you want to use a simple ssh vpn: #173 (comment)

Proxy the Proxy for External View

There is a way to see your Grafana dashboard from outside your home network. It will require that you allow and NAT both port 80 for Grafana as well as port 8675 for pypowerwall. A VPN could be set up to allow this as well and is a safer approach. My low-budget VPN uses a locked down SSH host exposed via NAT port 7654. I use a simple script on my Mac to load the Dashboard while outside my home, like this:

#!/bin/bash

# Define the internal server IP address
SERVER=10.0.10.10
# Define the external ssh address - assumes you have already set up ssh keys
PUBLIC=user@my.home.address

# Create the tunnel
ssh -N -p 7654 $PUBLIC -L 9000:$SERVER:9000 -L 8675:$SERVER:8675

# View the Dashboard
echo "Open http://localhost:9000''

Warning

Opening up Grafana or pypowerwall proxy to the public internet does come with risks. It does mean that anyone knowing the address can see your Powerwall data. However, more importantly, if a vulnerability exists in either of these tools, a hacker could potentially gain access to your internal network. This is why I would recommend a VPN approach.

[jasonacox]

"next time you are in a meeting with Elon (LOL!), show him the Powerwall-Dashboard."

🤣 Thanks @hulkster

[hulkster]

Thanks for the comments. To be clear, my situation is more similar to what @BJReplay referenced. Excellent reminder @jasonacox that one should always be concerned about security stuff ... so I would need to take steps on my server since it is already public facing.

My situation is Solar Only ... so per #183 (which I commented on with my experience to try to be helpful), it does not appear you can get String Data (from /device/vitals) ... or at least has not been figured out yet.

Speaking of being helpful, when I did the install of Docker/Grafana on CentOS7, it comes up on port3000, not 9000. Also, I think (?) Grafana changed the name from "Configured" to "Connection" .... so if I'm not being a dumb-a** (very possible!), worth updating the excellent installation directions.

[mcbirse]

So after re-confirming that changing all three "user" entries (grafana, weather411, and tesla-history) in powerwall.yml works, I tried various permutations of doing less ... and it works if I only change the "user" entry for BOTH grafana and tesla-history ... does not appear I need to do for weather411. I don't know if that is helpful info (?)

Thanks, I suspected this would be the case. The weather411 container only needs read access (can be seen in powerwall.yml volume section where it has read_only: true defined) so is probably still able to read the config file with a different or wrong user/group.

But, both grafana and the tesla-history script need write access (grafana for the db, and tesla-history for creating the .conf and .auth file and periodic updates to the .auth file). So, the user/group for those containers needs to be correct to write files in their relevant directories.

I've been meaning to get back to some updates for the Solar-Only related setup of the dashboard, as it was never quite finalised and is still listed as beta / under development... even though it is pretty much done and working for a lot of people. I've got some other pending changes for the tesla-history anyway so once I have some time to work on it will include a proposed change to address the user/group issues for the containers.

[hulkster]

I'm happy to be a Beta-tester for you @mcbirse when have something to test

[hulkster]

I did some more testing, and I think the code changes are fairly straightforward ... but disclaimer I'm a total newbie to Docker & Python, so someone knowledgeable should check. Note this is for solar-only ... may need to do something similar with pypowerwall for those with powerwalls.

cd tools/solar-only
cp compose.env.sample compose.env
Change GRAFANAUSER from 1000:1000 to my UID:GID (later should be docker group)
Duplicate that line except call it TESLAHISTORYUSER
This is what I ended up with:
GRAFANAUSER="5555:498"
TESLAHISTORYUSER="5555:498"

Modify line 66 in powerwall.yml
BEFORE: user: "1000:1000"
AFTER: user: "${TESLAHISTORYUSER}"

BTW, it might make sense to just declare a GENERICUSER in compose.env and use that throughout powerwall.yml, since I'm not sure much is gained by running the different services as different users (?)

setup.sh now runs without an problem. As @mcbirse pointed out, weather411 only needs read access, so there isn't a write issue with that.

[mcbirse]

I had already thought about using a single user variable, something like PWDUSER, since the Powerwall-Dashboard project likely is using the same user account for the entire project and it's docker containers.

Please feel free to raise a PR with your proposed change... or I will get to this along with other changes I have in the works once I have time.

[hulkster]

Sounds great - seems like a logical approach - maybe call it PWDUSERGROUP since it is a doublet(?)

I'll defer to people like you @mcbirse who understand the code-base better to submit the change.

Thanks for your fine work ... and bonus points if you can sneak an option to "only bind to localhost" in the code changes per #360 ;-)