It was pushed out for the app about 2 or 3 versions ago - recent but not really recent. It is annoying but I think it is because they want to reserve an amount in case you run the battery dry when on backup - they want enough juice to be able to start the solar working again when in backup mode (e.g. no grid available). At least that is what I got out of various forums discussing the subject.
I followed the tutorial from @spludge to get 2 instances of the PVOutput connector running, and to get the extended data. However my extended data graph is blank. It is sending data from my Powerwall 2 as I can see Generation, Consumption, export data in the detailed graph now.
I can see both logs with data going in
Log1
DATE;TIME;TEMPERATURE;VOLTAGE;POWER;ENERGY;TOTAL;V7;V8;V9;V10;V11;V12
20180310;00:00:27;-1000.0;241.8;652;-1.000;-1.000;0.000;652.405;NaN;646.110;100.000;0.600
Log2
DATE;TIME;TEMPERATURE;VOLTAGE;POWER;ENERGY;TOTAL;V7;V8;V9;V10;V11;V12
20180310;00:00:02;-1000.0;241.8;0;-1.000;-1.000;0.000;735.206;NaN;657.470;100.000;0.660
Client is hitting the service on both
pvoutput1
2018-03-10 08:23:53,142 INFO [Thread-1] (WebClient.java:131) - >>> http://pvoutput.org:80/service/r2/addbatchstatus.jsp?data=20180310,08:25,-1,-1,-1.0,646,-1000.0,241.9,-10,646.884,,137.96,100,513.62
2018-03-10 08:23:53,286 INFO [Thread-1] (Controller.java:1896) - <<< 20180310,08:25,1
2018-03-10 08:24:01,833 INFO [Thread-10] (WebClient.java:162) - >>> http://<MY_PW_IP>:80/api/meters/aggregates
2018-03-10 08:24:01,844 INFO [Thread-10] (PowerwallLogReader.java:361) - >>> http://192.168.1.114/api/system_status/soe
2018-03-10 08:24:31,899 INFO [Thread-10] (WebClient.java:162) - >>> http://<MY_PW_IP>:80/api/meters/aggregates
2018-03-10 08:24:31,915 INFO [Thread-10] (PowerwallLogReader.java:361) - >>> http://<MY_PW_IP>/api/system_status/soe
pvoutput2
2018-03-10 08:23:55,134 INFO [Thread-1] (WebClient.java:131) - >>> http://pvoutput.org:80/service/r2/addbatchstatus.jsp?data=20180310,08:25,-1.0,518,-1,-1,-1000.0,241.8,0,649.947,,134.26,100,518.91
2018-03-10 08:23:55,233 INFO [Thread-1] (Controller.java:1896) - <<< 20180310,08:25,1
2018-03-10 08:24:07,719 INFO [Thread-10] (WebClient.java:162) - >>> http://<MY_PW_IP>:80/api/meters/aggregates
2018-03-10 08:24:07,736 INFO [Thread-10] (PowerwallLogReader.java:361) - >>> http://192.168.1.114/api/system_status/soe
2018-03-10 08:24:37,798 INFO [Thread-10] (WebClient.java:162) - >>> http://<MY_PW_IP>:80/api/meters/aggregates
2018-03-10 08:24:37,913 INFO [Thread-10] (PowerwallLogReader.java:361) - >>> http://<MY_PW_IP>/api/system_status/soe
I configured both powerwall.ini as such according to the writeup
v7=battery.instant_power
v8=load.instant_power
v10=site.instant_power
v12=solar.instant_power
soc-url=http://<MY_PW_IP>/api/system_status/soe
soc-parameter=v11
One is configured in the “IN” direction, and the other is configured in the “OUT” direction. Here is my link https://pvoutput.org/list.jsp?userid=64864
If anyone has any advice it would be appreciated.
SO it looks like the extended data is only view-able through the Live view and not daily. Mybe because I don’t have enough data yet? Also what seems to be the optimal extended parameters mapping and data for most people with a Powerwall? This graphs oevr top of eachother which I suppose is ok, Maybe changing the axis on load to below the graph? Again any insight would be helpful, and thanks!
have you setup the extended parameters “summary” field, it’s these are set to none you wont get any daily summaries, in most cases you will want it “W to kWh” to give the total power.
With regards to the graphs themselves it takes a bit of trial and error to get it so you can see all data. I believe the graph is rendered in the following order
Axis 0 first
lowest to highest extended parameters
Axis 1
lowest to highest extended parameters
so on mine
https://pvoutput.org/intraday.jsp?id=62806&sid=55875
it renders in order axis 0 v7,v8,v9,v10,v11 then axis 1 v12
I found it best to put area graphs first, and dark colours before light colours and as a result I can see all my graphs, that said I am colour blind to hate colour coding so it probably looks weird to most i just to pick colours I can differentiate easily.
Takes some fiddling but worth the time now before you get too much data, hope this helps
1 Like
I changed the “Summary” field values from None to “W to KW” so we’ll see what we get in a day or two. That part of the extended parameters description led me to believe that those were for a summary that would be emailed or as a downloadable PDF so I left them off because I was uninterested in that. Thank you for the recommendation!
no worries, looks like its all working
Hil folks. Got my powerwall here in SA three weeks ago. Ive set up a Raspberry pi to monitor based on the mikesgear post and have the service running but like some folks above ive not been retrieving extended data successfully.
The log shows
20180714;15:51:19;-1000.0;-1.0;598;-1.000;-1.000;NaN;NaN;NaN;NaN;100.000;NaN
20180714;15:51:32;-1000.0;-1.0;606;-1.000;-1.000;NaN;NaN;NaN;NaN;100.000;NaN
20180714;15:51:44;-1000.0;-1.0;623;-1.000;-1.000;NaN;NaN;NaN;NaN;100.000;NaN
Seems im missing something.
Powerwall.ini shows
url=http://x.x.x.x/api/meters/aggregates
poll=30
direction=in
voltage=instant_average_voltage
v7=battery.instant_power
v8=load.instant_power
v10=site.instant_power
v12=solar.instant_power
soc-url=http://x.x.x.x/api/system_status/soe
soc-parameter=v11
powerwall.ini (END)
Suggestions welcome
Have a look at the other powerwall thread, I think from 1.18 firmware you access the powerwall though https not http, which one can be reached in a browser if you just type http://x.x.x.x/api/meters/aggregates or https://x.x.x.x/api/meters/aggregates?
1 Like
Thanks. good advice.
Ive also grabbed the latest version and loaded it.
Make sure you also grab the patch described at Tesla Powerwall2 data to PVoutput?.
Unless BB has been very very quick, you’ll need this to get the charge percentage out of https://x.x.x.x/api/system_status/soe working.
1 Like
The latest release v1.5.3.1 now includes the patch
1 Like
Thanks guys.
I found my problem. There were trailing spaces on the URL’s that broke the code.
Ive downloaded the patch and updated the URL’s to https. QAll working I just need to adjust the scaling of some of the parameters in PVOutput itself.
In case anyone is interested I setup a docker that can run the pvoutput service, currently only setup to work with powerwalls but can easily work with any of the others with minor tweaks.
It uses the latest build 1.5.3.1 and uses a very minimal system based on alpine linux
3 Likes
Sorry to bother, The instruction says:
map /config to a directory on the host her settings will live
What MacOS command would you use for doing the mapping?
docker --config ?
Also to synch Timezone, I found this online:
docker run -e “America/Los_Angeles”
would that do it? The posts say that for the " workaround to work , tzdata of course has to be installed in the container you’re trying to run."
Update:
this seems to do it:
$docker run -v ~/PVConfig:/config -e “TZ=${TZ}” bshep/pvoutput
Just so you know. I run two decker containers, on for production and one for consumption, started about 2 minutes apart, with uploads every 5 minutes. I keep separate log and ini folders as in:
$docker run -v ~/PVConfig:/config -e “TZ=${TZ}” bshep/pvoutput
$docker run -v ~/PVConfigOut:/config -e “TZ=${TZ}” bshep/pvoutput
Works beautifully.
5 minutes uploads last for about a day and a half, then the Powerwall “refuses” the connection. I am trying to see if 15-minutes intervals last longer.
Hi - I had a PW2 installed today. My solar system is setup already using the Solaredge interface - https://pvoutput.org/list.jsp?userid=11554
Can I add the PW2 to the existing system or should I replace the solaredge configuration with the PW2 using the pvoutput integrator?
Thanks in advance,
Paul
I updated the version from 1.5.4 to 1.5.4.1, nothing else has changed so please let me know if you have any issues.
I am getting this message in the logs:
2019-07-14 07:08:02,973 INFO [Thread-2] (WebClient.java:243) - >>> http://192.168.0.17:80/api/meters/aggregates
2019-07-14 07:08:02,985 ERROR [Thread-2] (AHttpLogReader.java:463) - Http Error
javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
at sun.security.ssl.SSLSessionImpl.getPeerCertificates(Unknown Source)
at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:128)
at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:397)
at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:148)
at org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:149)
at org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:121)
at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:573)
at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:425)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:820)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:754)
at org.pvoutput.integration.reader.AHttpLogReader$ASimpleLogFileWriter.get(AHttpLogReader.java:430)
at org.pvoutput.integration.reader.AHttpLogReader$ASimpleLogFileWriter.run(AHttpLogReader.java:354)