Repository navigation
Replies: 1 comment
|
didn't look at the code. fwiw i simply discovered that v1r route did not work for me until i set legacy password and actually used it as password along with the private key registration (gw_pwd seems optional). after that i was able to do local operations without falling back to cloud mode. Nore do i require connection to gateway wifi endpoint exclusively, local LAN IP is ok. 2017 gateway 1 |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Is the get documented for PW3 expected to work for PW2 using v1r?
python -m pypowerwall get -v1r -host 192.168.1.30 -gw_pwd ABCDEXXXXX -rsa_key_path ./tedapi_rsa_private.pem(whereABCDEXXXXXhas been replaced with my full GW serial number - which does work in the next example) always fails with:To test, I put together a full .env, and the following modifications to example.py, the connection works:
print(f"mode: {pw.mode}, tedapi: {pw.tedapi_mode}\n")And confirmed it was connecting in local v1r.
My .env contained
Going back to the CLI, this worked:
python -m pypowerwall get -v1r -host 192.168.1.30 -password "legacypasswordwithspecialcharacters" -gw_pwd ABCDEXXXXX -rsa_key_path ./tedapi_rsa_private.pemReviewing the code at https://github.com/jasonacox/pypowerwall/blob/main/pypowerwall/__main__.py#L104C1-L110C10 indicates that the call at https://github.com/jasonacox/pypowerwall/blob/main/pypowerwall/__main__.py#L866 simply passes through the args from get.
It appears that get with v1r requires both host and gw_pwd as well as password to work successfully.
I'm raising this as a discussion Q&A rather than an issue, because I'm not sure if it is an issue or a documentation gap, but it looks like it might be a gap in the documentation for v1r for PW2 - which - if it is, is working for me (another data point 😉).
All reactions