This should be, without the ‘solar’. -
voltage=instant_average_voltage
When direction=out voltage is from solar, direction=in then it is from load. It is not possible to change this.
Temperature setting isn’t supported since PW does not report temperature.
Stategic deployment of foil might help ensure the local LAN connection is chosen as the better quality connection 
LoL - that might be the answer 
OK, have tried that, thanks.
When direction=in in both pvoutput.ini and powerwall.ini, then the voltage is uploaded and appears on the PVO chart OK.
But when direction=out in both pvoutput.ini and powerwall.ini, then the (other) voltage is uploaded into the system fine according to the logs from the background service, but theres no trace of the voltage in the PVO chart, or in the daily data once downloaded.
Here’s the line being uploaded from the background service on the PC when both directions are set to ‘out’, showing voltage being set to 233.7 correctly…
DATE;TIME;TEMPERATURE;VOLTAGE;POWER;ENERGY;TOTAL;V7;V8;V9;V10;V11;V12
20180614;19:11:13;-1000.0;233.7;-1;-1.000;-1.000;1020.000;988.447;432699.224;NaN;2.046;-1.520
But the PVO server seems to be discarding the voltage while accepting the other values (v7-v12) in the upload string. Is the system only accepting voltage values if there is positive solar at the same time? I’m testing this at night, so solar is 0 at the moment
…and this was the key. The default parameter loaded into the ‘power’ variable when direction=out is solar.instant_power, which at nighttime is slightly negative. Uncommenting the power line and setting it to load from instant_apparent_power instead, which seems to be always slightly positive at nighttime, has enabled the voltage value to be accepted and plotted.
@bankstownbloke would you consider modifying the system to accept a voltage value, even if the power is negative? or alternatively altering powerwall.ini in the default setting to default to instant_apparent_power instead of instant_power?
Here’s the solar portion of the Tesla PW2 JSON during nighttime: instant_power bubbles along between -1.6 and -4.5, while instant_apparent_power seems to bubble along in a similar range, but positive values close to 0.
solar:
last_communication_time “2018-06-14T18:59:59.586111511+10:00”
instant_power -2.569999933242798
instant_reactive_power 2.0299999713897705
instant_apparent_power 3.10679916811086
frequency 50.04999923706055
energy_exported 432699.224444464
energy_imported 506.17722224178317
instant_average_voltage 234.5500030517578
instant_total_current 0
i_a_current 0
i_b_current 0
i_c_current 0
The default is ‘instant_power’, to use ‘instant_apparent_power’ then in set -
power=instant_apparent_power
However, power value during the night won’t be accepted when the direction is ‘out’
My PW firmware updated 2 days ago from 1.15.1 to 1.19.0 and PVOutput Integration service broke as a result.
I’ve read elsewhere that from 1.18.x the PW uses HTTPS now using a self-signed cert.
I was able to get the PVOutput Integration Service working again by simply changing the two URLs in the \conf\powerwall.ini from HTTP to HTTPS .
Good to know - thanks for catching this.
I haven’t found a way to set the power reading to zero if it is below 20W. I’ve set the rule for the extended parameter but the table below the graph still shows the values below 20W - even if the extended parameter graph shows 0W. I don’t have a device except for weather so the rules there isn’t an option - how do I set this to 0W? BB help please. Maybe there is a way in the .ini file?
In powerwall.ini try adding -
rule=if (power < 25 && out) power = 0;
Restart the PVOutput Integration service.
I’d like to see if I’m alone with what appears to be sweeping changes by Tesla.
I was updated to 1.20.0 July 2nd. I have my Powerwall 2 configured to run on my local WiFi. I know that in order to access the Wizard that you now have to use https://. I also have configured my PVOUTPUT.org site to pull data from the Powerwall API and changed the integration service to use https as well. Here’s my site: https://pvoutput.org/intraday.jsp?id=45323&sid=41348.
This was all working well until last night at 6:30pm. I am unable to access the Wizard interface and my PVOUTPUT service stopped pulling data. I connected to the Powerwall’s onboard WiFi in order to connect to the Wizard - no luck. I tried powering off the Powerwall and resetting the Gateway to see if there was a problem - no luck.
So, I called Tesla support. After several go arounds with them here’s what I was told:
So, this is a real bummer. Seems that if I want to get PVOUTPUT going I have to buy my own Neurio and have it installed.
I would appreciate any insights.
Thanks for the info, I’m still in 1.15.1 and by the sounds of it want to stay there, very disappointing the direction this is headed. Even with a neurio or other such monitor it won’t give all the data, soc for one although it can be calculated but I use this extensively to automate other things. No api Also sounds like you loose the ability to locally control the powerwall, so if their servers are down or your internet etc you have no control of the battery unless the new wizard allows it, if it comes out in 4 weeks I’d be stunned based on their history of doing things.
“abusing the interface” - thats rich - just who’s battery is it now its been paid for??
One of the ‘innovations’ they added recently is that the gateway might spontaneously change which network interface it is using - see post in this thread above (Tesla Powerwall2 data to PVoutput?)
So possibly it isn’t actually using your wifi to send data back to home base, and might have been switched to cellular again, disabling access via wifi via your own gateway. Can you see the original WiFi SSID when the PW2 is acting as its own basestation (“TEG-xxx”)? If so, can you connect to it that way?
I am able to connect to the PW2 onboard WiFi TEG-7XX. My system gets assigned 192.168.91.109 and I know the PW2 interface is 192.168.91.1. I know that they also switched to requiring https. The browser shows “establishing a secure connection…” and then times out. This is the same behavior I get when I connect to the PW2 from my own WiFi network. I know that the PW2 is on my WiFi as I can see it on my router’s connected device list “192.168.1.100 00:23:A7:D9:XX:XX 1118431-00-G–T17I000XXXX”. It appears that they may have turned off the internal web server. I know it’s sending data to Tesla as the iOS app has realtime data (or as we all know near real-time). I don’t know what I did to trip their wire to shutoff the access. I only use the Integration Service for pvoutput.org. Now and then I would view the web interface. Which, BTW, with 1.20.0 was changed to allow you to change the network without entering into the full Wizard. It was a huge improvement.
Thanks for the comprehensive update.Will be very disappointing for a lot of people if this becomes widespread.
Just been updated to 1.20.0 firmware for the PW2 - so far no impact except that the battery % state isn’t showing on the graph.
Yep, same here. Changed links from http to https, everything working fine except battery SoC no longer populating.
PW0 log showing NaN for v11 which is my record for state of charge. Was working prior to upgrade to 1.20.0.
Hi BB - any chance modifying the code to take characters and convert to number? I’m kinda missing seeing the % of battery remaining.
Cheers
Would need specific examples of which characters and to which numbers.
I can confirm that access to the aggregates works after changing to https, but access to the SOE doesn’t, now my system upgraded to 1.20.0 this morning.
I can’t see any change in the JSON output after changing to https:
This is the JSON output from the older version of firmware, that worked with a ‘http://’ (no ‘s’) URL:
{“percentage”:87.6753292986828}
This is the JSON output from the new firmware for https://192.168.0.63/api/system_status/soe
{“percentage”:59.14959928762244}
There is an extra digit after the decimal point, would that affect the parsing?
Perhaps the issue is with the setting up the SSL link now that the ‘s’ in https is required - although hard to see how the https processing would be different between the SOE URL (which doesn’t work) and the ‘aggregates’ URL for the other stats (which does work ok). Is there any difference in the code setting up the SSL link and processing the self-signed certificate between these two accesses?
I can punch a hole in the firewall and give you live access to test against BB, if it would help.