Uhmmm. Thanks for the clarification. I don’t have it connected by ethernet cable.
Wait... if you don't have it connected via a cable, what did you mean by "I have the gateway connected to my local network"?
The gateway of the powerwall can be connected via ethernet or wifi. I have it connected to my network via Wifi.
You should be able to connect to it using whatever IP your network has provided it whether wifi or wired.
1 Like
Hey Darwin, I've spoken to you over on the TMC forum in the past. Been using your PW Manager since August to change modes, reserve levels, and stormwatch status, worked great until Tesla's changes last week.
I've hacked together a workaround (for reserve levels only) using python script developed by blueice89 over on TMC to control the powerwalls, and using a node.js script running on a Raspberry Pi to listen for a web request, then call the python script with the appropriate parameters. It's not ideal, but was the best I could do given my lack of programming knowledge. The web request is triggered by Hubitat. It works to keep me running on PWs during the peak period....not quite as nice as your solution, but it does the job. I'm leaving the PWs in Self-Powered mode all the time, and just changing the reserve to 0% at start of peak period and 100% at end of peak period.
I can share the info with you if you were interested in taking a look, either for your own usage or if you were interested in modifying the PW Manager app to do something similar.
Is anyone else seeing the same using the local gateway now? I had to sign back in on a web browser to see the local PW status, wondering if Tesla changed the local API as well.
Another user has indicated that they DO appear to have changed the API and now have a cookie needed after authentication.
Somewhat fitting considering your profile picture.
1 Like
Lmao! Need 
looks like needs the same oauth2 that the car api is now using.. havent found an implementation yet in groovy and my attempts locked out my account so gave up for now.
Tesla Powerwall Manager also fails to auth to the remote site, and it breaks functionality like turning things off during outage and back on when the grid is back online. 
I'm hoping there will be some updates coming! 
1 Like
Just re-reading that and it might come off a bit too complain-ey, I should also mention how much I appreciate the functionality that's not been hampered by Tesla auth changes too.
As a fully off-grid (except 4G terrestrial wireless Internet) installation, I use this app to turn on secondary 12v battery chargers whenever the generator runs. The 12v system actually runs my Hubitat and the Internet connection and 2 of the 3 mesh Wi-Fi APs, along with my drinking water pressure pump - so as the days get shorter down under, the 12v system needs a bit more touching up from the mains batteries, and this little automation provided a bit extra to my scheduled boosts alone. So I appreciated that function in the app. 
Side question, anyone have a good solution for taking a 12v input and driving a (10v) Fibaro implant, or something else to give proper telemetry on the 12v power and react more directly?
Chris
I’ve committed an update to the Powerwall Manager app to now allow you to paste in an access token directly into the app to allow authorization with the Tesla server. Unfortunately, the app no longer supports direct access to the local gateway. You will need to generate and paste in a new token at least every 45 days.
There are several approaches for generating new Tesla tokens, including python scripts and the ‘Auth App for Tesla’ for IOS and Android.
Due to what appears to be limitations in the current way Hubitat handles URL redirection and HTTP headers, I’m not sure the app will ever directly support authorization with the Tesla server by entering in your account and password information alone. The issue with local gateway access also appears to be related to limitations in the Hubitat HTTP map header interface (that currently does not allow multiple Set-Cookie headers). I would love to be proven wrong, so if anyone here has a solution, it would be greatly appreciated.
The app does now allow you to generate and serve the access token posted via a script running on a local server for those wanting a hands-off approach for refreshing the token periodically. Thanks @kahn-hubitat for outlining the approach.
Only limited testing, so please let me know of any issues.
1 Like
The Powerwall Manager has been updated to add the local gateway polling option back in. Thank you @snell for helping work through the new gateway auth cookie API changes.
This update also overhauls the scheduling infrastructure to allow an unlimited number of schedules, schedule naming, and adds optional month restrictions – so those of us with seasonal time-of-use utility plans or other seasonal requirements should hopefully not need to manually update schedules in the app as often.
The scheduling update was a fairly major infrastructure change, so if you update, please verify that your prior schedules have remained intact.
1 Like
Thank you! It is working for me.
1 Like
FYI, the local polling connection is working for me as well. FWIW, using the Tesla OAuth method requiring an updated token every 45 days or so also worked for me but given that I am only interested in local monitoring from Hubitat to Powerwall, the gateway authentication method is ideal for me. Hopefully Tesla will keep this in place.
1 Like
Powerwall Manager version v0.3.30 is now available. This update includes the option to specify a refresh token instead of an access token, eliminating the need to enter a token every 45 days. The update also includes the ability to command and schedule off-grid operation. Both app and driver should be updated for this change. Thank you @x10send.
1 Like
I've got the Tesla server logon working with the refresh token but am having trouble with the local access setup. From a browser I can log onto the gateway with the last 5 of the password on the gateway sticker. On the local access setup I'm getting a timeout error.
For the dashboard setup I get this error.
I am using the same IP and last 5 password that works from a browser and the Hubitat and gateway are on the same network. I also have the latest version of app and driver.
It's certainly possible that I'm not robustly handling this particular network configuration properly in the code, but the ConnectTimeoutException makes me wonder if maybe Hubitat can't reach the Powerwall Gateway's subnet. (Otherwise, if the subnet was valid to Hubitat, but the IP wasn't, it would likely result in a "no route to host/unreachable" error, and a simple password authorization error should give you a "401 unauthorized" error).
Do you have any other pinger or Powerwall apps or drivers installed on Hubitat that you can use to verify that your Hubitat can see the gateway's address?
As far as the Dashboard Tile iFrame issue, I'm now seeing this same dashboard error you have captured above when running on Chrome. Safari now also has a different problem, although Firefox and Fully Kiosk Browser both still seem to work for me when displaying this as a tile on a Dashboard. All my dashboards run on FullyKiosk, so I hadn't noticed any issues. I'm wondering if Chrome and Safari have added additional protection against iFrame access - or at least the way I'm implementing this. I'll investigate further. There may be a way to permit this for certain browsers.
@Darwin I'm using your app/driver pair. I find that it fails to automatically refresh the Powerwall values. It only updates if I manually click poll and refresh - but when I do, it successfully gets updated values. However, it never updates on the polling interval. I've updated to the latest (Jan 19) version and that hasn't made a difference.
I'm using the local gateway connection - no Tesla token is configured. I turned on debug logging and I see this in the logs:
[debug] Input Access Token Valid: false
and looking at the code, that looks like a path to validate the Tesla token (which I said is not configured in the app).
I'm using Snell's driver pair, also, and it doesn't have an issue talking to the local gateway connection. But I like the notifications in your app better.
Any ideas on how I can debug this?
.
UPDATE: I uninstalled and re-installed the app and reinitialized it. It did one query, then it logged this on the time for the 2nd query:
but it proceeded to query the device, so at the moment it is working.
I typically run with both server and gateway polling enabled and admittedly don't do too much testing with just the gateway. I was going to suggest re-entering the gateway data to re-initialize the polling, but your clean install certainly takes care of that. It's very possible I failed to migrate one of the updates properly and your set up needed a full-initialization to get things properly working again. Let me know if this rears its ugly head again. I'll toss in a few more debug or trace statements in this area for future reference.
1 Like
