Same results for me after updating this morning.
Mine can’t connect to either. It seems to me that both require https now and I did change the .ini file accordingly but nothing gets written in the data stream file.
I guess I should turn on logging to see the same Java handshake error.
Check out this post Tesla Motors Club. Looks like there’s an issue that been discovered where you have to use a host name of Powerwall versus an IP to match the cert. I can’t test it as Tesla shutoff my PW2 web server. Might not work, but may be worth a try.
Here’s the URL:
That was the next thing to try - but it didn’t fix the issue.
Added an entry to the Windows host file (c:\windows\system32\drivers\etc\hosts):
192.168.0.63 powerwall
and now web browsing to https://powerwall/api/system_status/soe (after accepting all the warnings about insecure sites and self-signed certificates) gives the desired information:
{“percentage”:30.066038435853677}
However the Java VM can’t get through the invalid certificate authority checks, and still won’t access the information:
From pvoutput.log:
2018-07-18 09:39:17,280 INFO [Thread-2] (WebClient.java:162) - >>> https://powerwall:443/api/meters/aggregates
2018-07-18 09:39:17,561 INFO [Thread-2] (PowerwallLogReader.java:361) - >>> https://powerwall:443/api/system_status/soe
2018-07-18 09:39:18,967 INFO [Thread-1] (Controller.java:1869) - >>> 20180718,09:40,-1,-1,-1.0,3602,-1000.0,727.3,300,3602.145,1991118.164,1321.96,1973.01
2018-07-18 09:39:18,983 INFO [Thread-1] (WebClient.java:131) - >>> http://pvoutput.org:80/service/r2/addbatchstatus.jsp?data=20180718,09:40,-1,-1,-1.0,3602,-1000.0,727.3,300,3602.145,1991118.164,1321.96,,1973.01
2018-07-18 09:39:19,389 INFO [Thread-1] (Controller.java:1896) - <<< 20180718,09:40,1
(notice the second-last field, which is v11, is still empty).
Still wierd that the call for the ‘aggregates’ URL is getting results, but the call to the SOE URL is not.
Damn you Tesla, damn you all to heck!
BB, one thing I noticed:
With the ‘aggregates’ URL, changing ‘http’ to ‘https’ in pvoutput.ini caused the PVO service to automagically add the port ‘:443’ into the URL that was sent to the Internet.
However, there as no ‘:443’ added to the SOE URL.
powerwall.ini:
url=https://powerwall/api/meters/aggregates
soc-url=https://powerwall/api/system_status/soe
soc-parameter=v11
Produces in pvoutput.log:
2018-07-18 10:35:35,842 INFO [Thread-2] (WebClient.java:162) - >>> https://powerwall:443/api/meters/aggregates
2018-07-18 10:35:35,952 INFO [Thread-2] (PowerwallLogReader.java:361) - >>> https://powerwall/api/system_status/soe
2018-07-18 10:36:35,996 INFO [Thread-2] (WebClient.java:162) - >>> https://powerwall:443/api/meters/aggregates
2018-07-18 10:36:36,121 INFO [Thread-2] (PowerwallLogReader.java:361) - >>> https://powerwall/api/system_status/soe
Notice in the logs the ‘:443’ port override has been added to the aggregates URL, but not to the SOE URL.
Now the ‘:443’ doesn’t fix the issue - I added :443 into the SOE URL manually in the ini file and it still wouldn’t retrieve the data.
However, delving through the PVO source, this suggests to me that perhaps the SOE retrieval logic isn’t going through ‘getWebClient()’ in WebClient.java, which seems to have the logic for checking certificates and adding the ‘:443’ into the URL. Perhaps thats why the SOE retrieval is failing, but the other https retrieval is succeeding. But thats about the end of my Java-foo. Hope it helps.
Thanks for the logs.
Please download the following patch below -
- Rename to org.pvoutput.integration.jar
- Stop the service
- Copy this to the <pvoutput_install>/lib/ folder and replace the existing copy
- Start the service
If this is working then it will be included in the next release.
3 Likes
Yep, SOE is back with that.
1 Like
Yep, same here.
Thanks bankstownbloke!
Given Tesla’s direction since 1.20.0 making it increasingly difficult, and for some now actually impossible, to read the data directly from the Powerwall, is it possible to consider building Powerwall integration into the PVOutput on-line Auto Uploader (https://pvoutput.org/help.html#autoupload) functionality? I.e. Pull the data directly from Tesla’s web?
There are numerous community built applications already doing this (e.g. this Windows 10 app - https://www.microsoft.com/store/productId/9N3M45C4ZCJ4) and while it leads to slightly increased data latency, it would significantly improve reliability.
Thanks BB - great work as always. 
Also, willisave for providing the logs to BB.
1 Like
I’ve done some work on this with that intention, as I agree it seems to be the way Tesla are heading. So far I can retrieve my SoC from the Tesla servers, a few issues to work out with API tokens as well as the remaining commands for the other relevant data. Plus side to this method is no need for a local PC, downside is their server seems pretty unreliable based on the number of times the app doesn’t work, however I would expect retrieving history should be possible in these instances like with an efergy hub.
When I get some more time to work on it I’ll update here.
This can be a problem resulting in gaps in the data for current/spot data.
We won’t be implementing this unless there is a history service API for the day’s 5-minute data.
1 Like
Completely understandable, I read somewhere there is a 48 hour history, unfortunately the api is not documented but will see what I can work out
Edit: thinking about it there must be a 48 hr history of 5min data the app uses it
1 Like
I also confirm the patch works and restores the SOE collection for me.
Thanks BB for the rapid fix.
Thank you all. Two days out but now it is all good!
Well as of 5:15pm last night I have no access to the PW2, web page or access to the data. Nothing is working except for the stupid Tesla app. I can ping the PW2 - but no data.
Six days later it started working again - it took a phone call to Tesla support. Now with the latest version of the firmware (1.21.0) they state that customers will have access to wifi. Which is good news for us pvoutput org users.
Hi All, new here but been trying to get PVOutput to work from my PW2 for a few weeks and just finished another attempt to get it working. Got the editing done correctly and in the right directories this time, I think. In a folder under Program Files (x86) …… PVOutput
When I run Start-Service, I get a couple of error messages, and I am way out of my depth with what they mean.
In the cmd shell, first error is along the lines of “access denied” and the second one “need to run as an elevated service”. “Hit any key to continue”, and it just exits.
All and any help appreciated.
The service install needs to be run as an administrator -
OK, thanks for that, got the service to run/start without an error message but after more than
24 hours still no data showing up. Both test calls to the PW produce the expected results.
Must be another error somewhere now as well, I thought I had done the editing correctly and put the files in the right directories etc.
Just had a thought, do I have to create a seed file in c:|logs ? I was not quite sure on that bit.