Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

Question related to pvoutput-integration-service / pvoutput.org

This site may earn commission on affiliate links.
I've downloaded the pvoutput-integration-service (pvoutput / PVOutput Integration Service / Downloads — Bitbucket) to a headless Windows machine, and following the directions at MikesGear (Monitoring Tesla’s Powerwall2 on PVOutput.org/), have a data stream from the Powerwall APIs going to PVOutput.org). See: 13495Tesla 15.435kW | Live Output. Any help would be much appreciated! Unfortunately, the default view at PVOutput.org is not showing any solar generation data.

My Powerwall.ini file reads:

url=https://192.168.1.154/api/meters/aggregates
poll=60
direction=in
voltage=instant_average_voltage
v7=battery.instant_power
v8=load.instant_power
v10=site.instant_power
v12=solar.instant_power
soc-url=https://192.168.1.154/api/system_status/soe
soc-parameter=v11

Here's some sample log output generated by pvoutput-integration-service:

DATE;TIME;TEMPERATURE;VOLTAGE;POWER;ENERGY;TOTAL;V7;V8;V9;V10;V11;V12
20190605;10:05:25;-1000.0;124.9;6286;-1.000;-1.000;10.000;6286.216;NaN;-4009.160;97.836;10306.940
20190605;10:06:26;-1000.0;124.6;6274;-1.000;-1.000;0.000;6274.027;NaN;-4001.830;97.832;10273.160
20190605;10:07:26;-1000.0;125.4;6808;-1.000;-1.000;0.000;6808.842;NaN;-3487.480;97.824;10316.410
20190605;10:08:26;-1000.0;125.5;6330;-1.000;-1.000;-10.000;6330.644;NaN;-4021.540;97.836;10361.940

Here is the json data returned from my Powerwall:

{
"site":{
"last_communication_time":"2019-06-05T10:12:24.584970071-04:00",
"instant_power":-3664.159912109375,
"instant_reactive_power":-921.6500244140625,
"instant_apparent_power":3778.2941427331757,
"frequency":60,
"energy_exported":217051.75555555546,
"energy_imported":745489.6386111111,
"instant_average_voltage":125.26000213623047,
"instant_total_current":0,
"i_a_current":0,
"i_b_current":0,
"i_c_current":0,
"timeout":1500000000
},
"battery":{
"last_communication_time":"2019-06-05T10:12:24.590259346-04:00",
"instant_power":0,
"instant_reactive_power":860,
"instant_apparent_power":860,
"frequency":60.006,
"energy_exported":51870,
"energy_imported":88230,
"instant_average_voltage":250.15000000000003,
"instant_total_current":-0.4,
"i_a_current":0,
"i_b_current":0,
"i_c_current":0,
"timeout":1500000000
},
"load":{
"last_communication_time":"2019-06-05T10:12:24.584970071-04:00",
"instant_power":6893.3364788902145,
"instant_reactive_power":-132.86897843141247,
"instant_apparent_power":6894.61688396302,
"frequency":60,
"energy_exported":0,
"energy_imported":2211580.6069444446,
"instant_average_voltage":125.26000213623047,
"instant_total_current":55.03222386499043,
"i_a_current":0,
"i_b_current":0,
"i_c_current":0,
"timeout":1500000000
},
"solar":{
"last_communication_time":"2019-06-05T10:12:24.585086403-04:00",
"instant_power":10551.05029296875,
"instant_reactive_power":-34.470001220703125,
"instant_apparent_power":10551.106599107987,
"frequency":60,
"energy_exported":1720026.566672781,
"energy_imported":523.8427838920683,
"instant_average_voltage":125.25,
"instant_total_current":0,
"i_a_current":0,
"i_b_current":0,
"i_c_current":0,
"timeout":1500000000
}
}
 
This is a bit off-topic, but I'm trying to set up the python version of the PVoutput integration service (courtesy ekul135's ekul135/Powerwall2PVOutput), but ran into an issue.

I'm finding that my powerwall2 reports as "unreachable" on my network. ping and tracert don't reach it from my linux box.

This is despite being able to see it as 192.168.2.11 on my ASUS router, and being able to log into it if I join its TEG wireless directly.

Any tips on what I need to do to my powerwall2 to enable incoming connections to it on my home wifi?
 
This is a bit off-topic, but I'm trying to set up the python version of the PVoutput integration service (courtesy ekul135's ekul135/Powerwall2PVOutput), but ran into an issue.

I'm finding that my powerwall2 reports as "unreachable" on my network. ping and tracert don't reach it from my linux box.

This is despite being able to see it as 192.168.2.11 on my ASUS router, and being able to log into it if I join its TEG wireless directly.

Any tips on what I need to do to my powerwall2 to enable incoming connections to it on my home wifi?
Configure the BackUpGateway (BUG) to be on your WiFi network.

Otherwise, add a static routes on your router that connects your network to 192.168.2.* and 192.168.2.* to your network.
 
  • Helpful
Reactions: Story
Doesn't sound like 192.168.2.* is the same network as your Linux box? That's where you have to fix it.

Get it on the same network/mask as your Linux box, or add the static routes so your router can be the bridge.

Thanks again for the quick reply. Actually, all my devices are on that network, just some are on 5G and some are ethernet connected (like my diskstation). The BUG is on that network, and it talks to Tesla just fine...the app talks to it easily.

I'll check the network mask, though. Is that a setting I can modify on my BUG?
 
One interesting tidbit: On my mac laptop, if I join my BUG's wifi at TEG* and talk to it at 192.168.91.1, then I can also reach the 192.168.2.1 server, and query the APIs.

https://192.168.2.11/api/meters/aggregates

works fine, and produces the data I'll paste in below.

BUT if I connect to my 192.168.2.* network, I cannot reach https://192.168.2.11 at all.

Surely I'm missing some basic network setting here. :(


Anyways, here's the output of the web page above:

{"site":{"last_communication_time":"2019-07-09T00:28:37.680570975-07:00","instant_power":1609.089942932129,"instant_reactive_power":-966.2300109863281,"instant_apparent_power":1876.9046002863229,"frequency":60,"energy_exported":860960.1986113214,"energy_imported":1038805.3202779881,"instant_average_voltage":121.65999984741211,"instant_total_current":0,"i_a_current":0,"i_b_current":0,"i_c_current":0,"timeout":1500000000},"battery":{"last_communication_time":"2019-07-09T00:28:37.690161235-07:00","instant_power":-10,"instant_reactive_power":810,"instant_apparent_power":810.0617260431454,"frequency":59.984,"energy_exported":310490,"energy_imported":361870,"instant_average_voltage":242.95,"instant_total_current":-0.5,"i_a_current":0,"i_b_current":0,"i_c_current":0,"timeout":1500000000},"load":{"last_communication_time":"2019-07-09T00:28:37.680570975-07:00","instant_power":1620.9486754422362,"instant_reactive_power":-74.07875560097503,"instant_apparent_power":1622.640524099324,"frequency":60,"energy_exported":0,"energy_imported":1546681.0274999999,"instant_average_voltage":121.65999984741211,"instant_total_current":13.323595902311817,"i_a_current":0,"i_b_current":0,"i_c_current":0,"timeout":1500000000},"solar":{"last_communication_time":"2019-07-09T00:28:37.680817973-07:00","instant_power":13.350000143051147,"instant_reactive_power":85.37999725341797,"instant_apparent_power":86.41739659821468,"frequency":60,"energy_exported":1422797.886389501,"energy_imported":2581.980556167762,"instant_average_voltage":121.69499969482422,"instant_total_current":0,"i_a_current":0,"i_b_current":0,"i_c_current":0,"timeout":1500000000}}
 
Sorry, then I don't understand.

* being able to connect to 192.168.91.1 tells me your BUG isn't connected to your home's WiFi -- else it should have changed its IP and 91.1 would not be working anymore
* BUG having an actual 2.* IP suggests it's either connected by Ethernet with DHCP IP, or it has a static IP, or I'm wrong about the WiFi connect
* not being able to ping it from your Linux router suggests it's not on the same network as your LAN, but the 2.* is your LAN, and static IPs should work, unless there's a collision with another device using the same IP
* matching netmask shouldn't be a problem if everything is set via DHCP, unless the BUG has a static IP with somehow the wrong netmask

ifconfig dump your interfaces in the terminal on your Mac, and Linux just to see if there's anything mismatching?
 
  • Helpful
Reactions: Story
OK, I logged onto the BUG's network (TEG*) and had it rescan wifi, and re-added it to my home wifi LAN. Then I waited.

Now I can ping and get to the API pages from my Mac laptop, using my home wifi! Big progress, gives me hope for the next steps.

However, my linux synology diskstation still doesn't reach the BUG via ping. I'm not sure what's up with that, since my mac can also talk to my linux diskstation (I'm ssh'ing in to run all this stuff!)

Here's the ifconfig for the diskstation -- yes, it has two network interfaces, one static and one DHCP.

thanks so much for all the suggestions, sometimes networking is black magic to me.



eth0 Link encap:Ethernet HWaddr 00:11:32:18:ED:FF

inet addr:192.168.2.185 Bcast:192.168.2.255 Mask:255.255.255.0

inet6 addr: fe80::211:32ff:fe18:edff/64 Scope:Link

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

RX packets:10233826 errors:0 dropped:0 overruns:0 frame:0

TX packets:5698973 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:1000

RX bytes:10558597479 (9.8 GiB) TX bytes:2782726175 (2.5 GiB)

Interrupt:16 memory 0xc0400000-c0420000


eth1 Link encap:Ethernet HWaddr 00:11:32:18:EE:00

inet addr:192.168.2.2 Bcast:192.168.2.255 Mask:255.255.255.0

inet6 addr: fe80::211:32ff:fe18:ee00/64 Scope:Link

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

RX packets:2306872 errors:0 dropped:0 overruns:0 frame:0

TX packets:1320032 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:1000

RX bytes:2245583842 (2.0 GiB) TX bytes:873381017 (832.9 MiB)

Interrupt:17 memory 0xc0300000-c0320000


lo Link encap:Local Loopback

inet addr:127.0.0.1 Mask:255.0.0.0

inet6 addr: ::1/128 Scope:Host

UP LOOPBACK RUNNING MTU:65536 Metric:1

RX packets:363869 errors:0 dropped:0 overruns:0 frame:0

TX packets:363869 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:0

RX bytes:39006061 (37.1 MiB) TX bytes:39006061 (37.1 MiB)
 
OK, I logged onto the BUG's network (TEG*) and had it rescan wifi, and re-added it to my home wifi LAN. Then I waited.

Now I can ping and get to the API pages from my Mac laptop, using my home wifi! Big progress, gives me hope for the next steps.

However, my linux synology diskstation still doesn't reach the BUG via ping. I'm not sure what's up with that, since my mac can also talk to my linux diskstation (I'm ssh'ing in to run all this stuff!)

Here's the ifconfig for the diskstation -- yes, it has two network interfaces, one static and one DHCP.

thanks so much for all the suggestions, sometimes networking is black magic to me.
Yay I'm glad there some progress on the WiFi side.

The Diskstation's two interfaces look okay:
* do you have a firewall turned on -- on the Synology? (stock install usually does not have the Synology FW turned on. If on, you need to expand access?)
* you can ping your Synology from the Mac and vice versa? Your Mac with any DHCP IP can always ping the Synology?
 
While I debug that, and try getting just my Mac Python app talking properly, does anyone have tips on how to get the Tesla BUG to use a static IP on Wifi? I don't see any configuration for that, but perhaps it's somewhere in the API documentation?
Get the BUG's mac address, go to your ASUS router, and assign that mac a permanent IP.

Probably what you've also already done for your Synology? If not, it's a good thing to do, so you can get rid of the dual-IPs on it.
 
  • Helpful
Reactions: Story
You may be hitting the same issue I did when I put pvoutput on the diskstation. For me, the issue related to the https call...basically, I had to find the right certificate(s) (from the powerwall interface) and add them into the trusted store on the diskstation. If you really want, I can dust off my notes about how I got it working, but I think a much better solution would be to install the docker app for your diskstation and then use a docker container to run the service...it's less work and much more future-proof.

I meant to do it but someone else appears to have beat me to it:

Docker Hub

I'll admit I haven't gotten around to switching over to that approach because I have it working now directly, but I will switch eventually because it will be much easier to maintain the docker environment than the direct synology one.
 
  • Informative
  • Helpful
Reactions: Story and NuShrike
You may be hitting the same issue I did when I put pvoutput on the diskstation. For me, the issue related to the https call...basically, I had to find the right certificate(s) (from the powerwall interface) and add them into the trusted store on the diskstation. If you really want, I can dust off my notes about how I got it working, but I think a much better solution would be to install the docker app for your diskstation and then use a docker container to run the service...it's less work and much more future-proof.

I meant to do it but someone else appears to have beat me to it:

Docker Hub

I'll admit I haven't gotten around to switching over to that approach because I have it working now directly, but I will switch eventually because it will be much easier to maintain the docker environment than the direct synology one.

Sweet! I've got the docker running, and I think all the settings and .ini files properly edited....

BUT I still get the "no network access" error. Any ideas? I'm guessing I need to enable a network port...or perhaps I still have to do the SSL Cert override?

[pvoutput starts up...omitting details before the error message...]

2019-07-16 00:23:53,527 INFO [Thread-0] (Controller.java:731) - Startup Complete: Waiting for data...

2019-07-16 00:23:53,528 WARN [Thread-0] (Controller.java:787) - Log directory '/volume1/docker/pvoutput/config/logs' does not exist

2019-07-16 00:23:54,569 INFO [Thread-9] (DefaultRequestDirector.java:586) - I/O exception (java.net.NoRouteToHostException) caught when connecting to the target host: Host is unreachable (Host unreachable)

2019-07-16 00:23:54,573 INFO [Thread-9] (DefaultRequestDirector.java:593) - Retrying connect

2019-07-16 00:23:57,570 INFO [Thread-9] (DefaultRequestDirector.java:586) - I/O exception (java.net.NoRouteToHostException) caught when connecting to the target host: Host is unreachable (Host unreachable)

2019-07-16 00:23:57,572 INFO [Thread-9] (DefaultRequestDirector.java:593) - Retrying connect

2019-07-16 00:24:00,576 INFO [Thread-9] (DefaultRequestDirector.java:586) - I/O exception (java.net.NoRouteToHostException) caught when connecting to the target host: Host is unreachable (Host unreachable)

2019-07-16 00:24:00,577 INFO [Thread-9] (DefaultRequestDirector.java:593) - Retrying connect

2019-07-16 00:24:03,586 ERROR [Thread-9] (AHttpLogReader.java:463) - Http Error

java.net.NoRouteToHostException: Host is unreachable (Host unreachable)

at java.base/java.net.PlainSocketImpl.socketConnect(Native Method)

at java.base/java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:399)

at java.base/java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:242)

at java.base/java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:224)

at java.base/java.net.SocksSocketImpl.connect(SocksSocketImpl.java:322)

at java.base/java.net.Socket.connect(Socket.java:591)

at java.base/sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:285)

at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:375)

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)
 
I noticed you referenced "joining the TEG network"...and that doing so allows you to connect to the PW. I ran into the same issue before realizing I was missing the "gateway" component. It was just never installed when my installation happened. I called Tesla (many, many months after my install was completed) and they sent one to me right away...it is trivial to install. I think you need that in order to get this working.
 
I noticed you referenced "joining the TEG network"...and that doing so allows you to connect to the PW. I ran into the same issue before realizing I was missing the "gateway" component. It was just never installed when my installation happened. I called Tesla (many, many months after my install was completed) and they sent one to me right away...it is trivial to install. I think you need that in order to get this working.

Hi dotbombjoe -- I assume you were replying to me?

How would I know if I'm missing the gateway component?

Dave
 
If the "gateway" component is the black box that you connect to your network, it's not necessary. As I understand it, it just sends the data from the solar inverter to the Tesla servers. I have a non-Tesla solar installation with Powerwalls, and I have full functionality with the pvoutput integration without the extra box. The gateway that's part of the Powerwall installation (the box installed on the wall) has all the functionality necessary to measure the power output of both solar and the Powerwalls. I believe the other gateway is left over from the Solarcity days and is (mostly) redundant if a Powerwall is installed.
 
If the "gateway" component is the black box that you connect to your network, it's not necessary. As I understand it, it just sends the data from the solar inverter to the Tesla servers. I have a non-Tesla solar installation with Powerwalls, and I have full functionality with the pvoutput integration without the extra box. The gateway that's part of the Powerwall installation (the box installed on the wall) has all the functionality necessary to measure the power output of both solar and the Powerwalls. I believe the other gateway is left over from the Solarcity days and is (mostly) redundant if a Powerwall is installed.

That sounds right to me. I suspect my issue re: needing the gateway may be related to how the powerwall was configured/setup. All I know is that I cannot access the PW unless I connect to its "TEG" wifi network -- it doesn't appear to be on my network. The gateway device makes it accessible in my case (without other changes to the PW).

It makes complete sense to me though, that a simple re-configuration on the PW could eliminate the need for this 'gateway' device. In my case, Tesla called to report they weren't getting my data after they received notice I had PTO. When they realized I didn't have a gateway, they told me that was the issue and sent one out for self-install. Again, perhaps just the support people not understanding the issue fully.

I've never checked out the config screens on the PW but others have posted here about it, so maybe you can search for one of those threads and see if you can address the issue that way?
 
Yay I'm glad there some progress on the WiFi side.

The Diskstation's two interfaces look okay:
* do you have a firewall turned on -- on the Synology? (stock install usually does not have the Synology FW turned on. If on, you need to expand access?)
* you can ping your Synology from the Mac and vice versa? Your Mac with any DHCP IP can always ping the Synology?


No firewall, and I can not only ping the Synology but ssh into it from my Mac, no issues...

I think it's something about either certificate, or not enabling outbound network connections? Not sure why I can't ping from my diskstation command line (terminal window)
 
No firewall, and I can not only ping the Synology but ssh into it from my Mac, no issues...

I think it's something about either certificate, or not enabling outbound network connections? Not sure why I can't ping from my diskstation command line (terminal window)

For what its worth, the "no route to host" means that the docker container's network isn't able to navigate to the PW. If you can get to it from your network via your browser, that implies to me that it is just the docker container that can't get there, which would make a lot of sense if your docker container isn't configured properly. Docker containers don't necessarily share the hosts network...they can be their own isolated network.

When you are in the Docker app on the Synology...can you click on the container area, click details on the container, and then let me know what your network tab shows? Is it in "bridge" mode?
 
  • Helpful
Reactions: Story