This can be left as power W and it will convert it to Wh automatically.
excellent, my battery instantaneous data is in V9 but if its selectable even better, very much appreciated
1 Like
Hi pv135 - I was thinking the same thing when I was comparing my retailer data to my pvoutput data but was going to look at it this weekend. Looks like you might have already done the dirty work, can you share by posting your parameter setup? Cheers in advance.
yes mate of course happy to share
heres me
https://pvoutput.org/intraday.jsp?id=62806&sid=55875
powerwall,ini is
url=http://xxx.xxx.x.x/api/meters/aggregates
poll=30
direction=in
v8=site.instant_power
v9=battery.instant_power
v10=load.instant_power
v11=solar.instant_power
soc-url=http://xxx.xxx.x.x/api/system_status/soe
soc-parameter=v12
and the extended data parameters are
So to explain the rule v7=-v8 gives me an inverse of the gird graph (I called grid-), I don’t want to see that on the live graph so I have a modifier of ‘divide by 1000’ on it so its so small it doesn’t show on the live graph. The summary of this as w to kWh is only calculated from the values greater than 0 which is the total Export to the grid and the summary of v8 is total import from the grid. I also set V8 CR/DR to debit and in the tarrif section of the settings enter the import and export costs. On the daily summary I then get a cost which does not include the daily connection fee, at least i know if I get to $1.55CR I’m breaking even here. Unfortunately the cost does not sum on the other views (weekly etc) but the import and export values do which I like very much as its a simple calculation to work out the cost of a given period.
Just a side note, Instead of having this grid- graph to generate export I was previously uploading the site.energy_imported and site.energy_exported values from the powerwall and making their summary ''change" but the way i do it now saves me an extra data field.
I have just re-run all my data back through pvoutput (I’m a bit of a nerd for that sort of thing) to get it all lined up after the changes and find that the total of import and export of either method are virtually identical and very much lined up with what my physical meter is displaying.
Will probably have to run it all through again if BB chooses to implement the battery model suggested but would be worth it for a lifetime and accurate import / export.
Hope this makes sense and is some help
1 Like
sorry mean to do it as a reply, see full post above
Fantastic thank you, I’ll give it a go and let you know if any problems
Thanks for the development of this capability of PVOutput - it’s great being able track the powerwall’s performance.
I am wondering if anyone else has noticed a discrepancy arise over the past few days, where the tesla app is reporting a different SOC to what is shown through the api?
It appears that Tesla may have limited the discharge to a minimum of 5% as I have noticed that the past few days have resulted in my PVOutput flatlining at 5% and starting to charge from the grid. Yet when I login to the Tesla app it is reporting 0%. I’ve also checked the custom settings to ensure the reserve is set to 0%.
Just curious if this is an issue unique to my setup or if others have noticed this?
The Tesla app always displays a percentage lower than the actual charge percentage, usually I find about 3% but i’ve not run mine to 0% so it could be stop at 5% actual as well.
PVOutput alters nothing just merely displays the information given to it, which is the actual percentage reported by the powerwall. I believe this is done so the powerwall has a small reserve left in it to restart it in a blackout and “fully” discharged state.
Yep, completely understand that pvoutput is just reporting the extended parameter from the ip address soc link. It’s just that for the first 3 months that figure matched the Tesla app or was within 1% for my setup, so I was just curious if Tesla had pushed a new 5% limit OTA since the change appeared to have occured a couple of days ago.
In fact, wouldn’t have noticed it, had it not been for PVoutput, as previously the SOC would go down to zero on the x axis, but it nows sits above it at 5% when fully discharged.
Don’t think there is anywhere Tesla document changes unfortunately. Mine updated to firmware 1.12.0 about a week ago, as long as I’ve had it its always been a 3% difference
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.