I want to say it worked -- but I still get the 'unauthorized' thing. I think this may be me, and not the app though. The interface used to be a telnet to the local interface that didn't require a username or password unless you wanted to control things. Now, telnet seems not to respond, and the app seems to be going to the HTTPS interface -- is that in fact true?
If so, I'll have to do some research, as I suspect mine is still set to "customer" and serial number, but I don't actually recall. And my normal Tesla App password doesn't work on the https interface through a browser with "customer", my e-mail, and my Tesla App password.
I'll have to mess with it this weekend when I have more time! Sorry.
It could be the driver also. With the new Tesla firmware they are requiring login even just to get the data, so I am trying to work that. But it may not be quite right. The problem with not owning one myself.
I'm still getting "Unauthorized" as above with 1.1.2.
If you are connecting to the local Powerwall address, I assume you want the local login (and not my Tesla account password). Both use my email address. I can make REST queries to the local IP once I use the local login password.
Minor changes to Login to attempt to get the now-required cookie. As always, this is an attempt as I do not have a PowerWall myself nor access to one (or a development system for it) so I am trying to match up to other information posted online about it. If anyone wants to provide information back, please set your device to Trace logging prior to selecting the Login command. You can send me the trace information as a private message and feel free to redact anything you might want to.
Thanks to @Darwin and some late-evening (for me) exchanges of information it looks like we have figured out the proper login and data retrieval checks.
Updated Version(s):
TeslaDriver.groovy = 1.1.4
Change(s):
Corrections to the login method to retrieve the cookies it now includes in the returned headers as these are required for data queries. For whatever reason Tesla thought it would be good to require two separate ones that are received at the same time rather than a single combined one.
Changes to the query methods to include the new AuthCookie and UserRecord data required instead of the old Token method.
Changes to the driver version checking to make it more readable:
Driver renamed to Driver Name
Version renamed to Driver Version
Driver Version Status added to show users the status of the driver version check instead of Version doing double-duty
I still cannot get it to work. I see you are still using the local auth, and it looks like it is passing the correct parameters, but it doesn't seem to succeed.
It is with great excitement that I read every post in this thread. First, I want to extend my gratitude to @snell for working on this despite not having a Powerwall 2. I do have one PW2 for my home for almost 3 years and love it. However, getting data from it to 3rd party tools has been very frustrating. I am stuck at the same point as everyone else. I cannot successfully authenticate to my PW2.
I know it can be done though. I am also running a VM to capture data via a Python script which regularly posts my solar production data to https://www.pvoutput.org. The author of this script has it posted to Github. Maybe it will provide some additional insight into the stronger authentication now required by Tesla.
I also found this Github link for more insight into the PW2 and Backup Gateway.
It would be awesome for PW2 and Hubitat users if we can get this working! I would love to see all my Smarthome stats on one dashboard. I'm happy to provide data logs from my environment to help this effort.
Sorry for making you folks have to try this stuff out. This is certainly one of the big problems with not having this type of equipment myself and with Tesla not having any public method for trying or validating. Anyways, here is yet another minor tweak to try to get the login working again.
Updated Version(s):
TeslaDriver.groovy = 1.1.5
Change(s):
Changed the login method from a body command to a query command... based on my notes from discussions with @Darwin. No idea if this was actually the correct thing to do. Here are the notes in case it does not work and someone tweaks it and gets it to work (the notes are in regards to what is currently line 252 in the driver). After that, hopefully the new cookie method will work:
I just tried your TeslaDriver, It would not successfully log In for me initially with the code as written, but worked if I changed the body parameter from the string you had:
So that query part I changed it to is wrong then... I just do not know what @Darwin meant then... since I have tried a couple ways and it has not worked for you folks. Sorry. I have reached out to get more specifics. I will keep trying, hopefully we will all get this working.
It looks like Hubitat requires the query to be a map vs. a string that is also allowed for body. The following should work. I don't believe 'email' and 'force_sm_off' are required for gateway customer access, but shouldn't hurt anything.
@Darwin: Thanks! I have incorporated that line as-is for the updated version so hopefully everybody will be set.
Updated Version(s):
TeslaDriver.groovy = 1.1.6
Change(s):
Updated login method per @Darwin's feedback. Let me know if it works and if there are any other issues.
** Other Item(s):**
As a note, I will be gone for a few days traveling without access to my computers (or Hubitats)... so I will not be able to deal with any code changes until at least the weekend. But I will be TRYING to check the forum at least (cannot guarantee it though). Have to get to bed early, early flight. Good luck and thanks again @Darwin.
I just did a test with Postman and verified that the email and force_sm_off do not seem to be required. Also, I have tried with ignoreSSLIssues true and false and both work from Postman.
I also just tried the driver with a hard coded values for my password and email address and I was able to successfully login!! Seems like some progress at least. I do not have any values returned yet but at least my login was successful. I modified the 1.1.5 driver for my test.
I downloaded the 1.1.6 code, @snell, and it worked for me!! Yeah!!! Looking at my logs, I see a successful login and an auth token returned. I also have the Tesla Child driver installed and enabled Child Devices. However, I do not see any values being returned from the Powerwall 2.
At least it looks like the login issue may be resolved. Would love to see others validate.
I do see the following error in my logs when the driver attempts to read the data? dev:5722021-06-07 07:40:05.054 pm errorTesla Powerwall 2 - AuthCookie and/or UserRecord missing, will attempt Login again.
Once the error passes, the login is done again and is successful returning a new auth token.
One other thing to add, in the log there is the following: dev:5722021-06-07 07:50:46.364 pm traceTesla Powerwall 2 - State: AuthCookie = AuthCookie=InIztJIdH2E3IZ28CTRrmZYL7lQRp2JS6daWLHZ-J1jNrE2p6LFkb8LYtBSSJMdQXUdhLvThn8CW08u6XOKv0w==
The interesting part to me is the beginning beginning with "State: AuthCookie = AuthCookie=" which suggests to me that there is no AuthCookie present, followed by the AuthCookie getting set.
Looks like I made a goof and am not parsing it properly. The problem with not seeing the actual responses.
If someone could send me the response in a PM (you can edit the codes and such) I would appreciate it. As long as I can see the general response and layout of it.
I was able to re-add the local gateway code back into the PW Manager (thanks by the way for working that with me). You can see the header parsing code that worked for me on line 568 and the new assembled response header on line 548. Feel free to use as-is if it helps.
Update to login area to make it fairly close to what @Darwin pointed out (I tried to keep differences to my variable names and groovy syntax only).
Update to the headers for the regularly checked data to use the auth code/user code reported.
Caveat(s):
As has repeatedly happened with this area... I will not actually KNOW this is fixed until someone can try it out for me. Hopefully this is the final attempt at this piece but I know I have said that before.