Mirroring/intercepting SunPower Monitoring Traffic?

[apara]

I am not sure if would be possible to install a trusted CA on that device. I could try to connect my machine to the "service" port on the device, but I am not sure where to go from there. Is there some SSH access that I can enable?

So, I know the communication is going over the power block adapter. I see that they are using some Go Daddy certificate and talking to some AWS machine. I still see some clear text HTTP posts going for 100 and 102 lines. I am just surprised that they would do a remote software upgrade on the device. Did not expect them to be this technical.

[JJNorcal]

Apara, I may be mistaken. Looks like mitmproxy would require installation of a root cert on the PVS itself.

[JJNorcal]

Yes. ManInTheMiddleProxy. Sorry for the confusion.

[apara]

Is this what you mean? https://mitmproxy.org/

[apara]

I will check into mtmproxy, but I never setup the WIFI connection (so the unit would not know the password) and the status was always sent over the power line adapter. In fact, I still get the 100/102 messages in the clear text, but the 130/140 lines are no longer appearing. To ensure that it is indeed the IP of the unit, I watched my router while unplugging the cable from the network. Sure enough, the IP in question disappeared from the network. I also tried to "reboot" the entire system by turning off the power at the main panel. The system came back, with a different MAC but I still did not see the production numbers as I was hoping.

These are the only messages I am seeing:

POST /Command/SMS2DataCollector.aspx HTTP/1.1
Host: collector.sunpowermonitor.com
Content-Type: text/plain
Content-Length: 72

100 SPMS 10 ZT170285000441C0308 20170629230949
102 L0eO+4aUacNCTIxqy/B6

[JJNorcal]

I had a similar moment some time back. I wasn't getting expected packets, yet SP kept registering data. Turned out that I have two network connections to the PVS5. I was keying off of a power line adapter, and the PVS had switched over to wifi.

I'm still getting clear text. I haven't had any interruptions.

You can set up mtmproxy and inspect encrypted packets.

Please send an update when you have one.

[apara]

I see calls going out to:

splunk.pvs5.p2e.io
search1.pvs5.p2e.io
ec2-52-7-213-242.compute-1.amazonaws.com


Is the party over?

[apara]

I am in the PST timezone, so as of yesterday 8am PST I have not seen any more captures.

I just came home today and the only thing I see being captured in the log are the 100 and 102 messages:

06/29/2017 04:09:50 PM|INFO|PROCESSING (204): [POST /Command/SMS2DataCollector.aspx HTTP/1.1

Host: collector.sunpowermonitor.com

Content-Type: text/plain

Content-Length: 72

100 SPMS 10 ZT170285000441C0308 2017062923094
102 L0eO+4aUacNCTIxqy/B6

I am no longer seeing other reporting.

Yet the website is still reporting proper results... What gives?

[toddn]

8am in what timezone? I noticed a gap in my consumption data starting at 4:35am Pacific which is what triggered the discovery of my PVS5x not having connectivity through my home internet connection. I had expected that it had been missing internet connectivity for about four hours, since it was around 8am when I checked -- but instead it had been completely disconnected (from my home interne) since mid-day June 21.

I'm logging *all* the LAN traffic coming out of the PVS5x, and there's no other host getting POSTs. There is encrypted traffic to an EC2 splunk instance -- perhaps SunPower is changing how they collect the data.

[apara]

Oddly enough, something similar happened to me as well. Last night, I noticed that the data stopped coming in at around 8 am. I checked the logs and sure enough, there was nothing there. It was late at night, so was not able to test for 140/130 but after restarting I noticed that only 100/101 (i think) were coming in every 30 minutes. I will check again today to see if the data stream recovered, but it could be that there is a "BACKUP" host, so that if your network goes down, the system may switch to another endpoint at a different IP address.

Anyhow, we'll see...

[toddn]

Has anyone had their PVS5x stop POSTing clear text data back to collector.sunpowermonitor.com? And if so, do you know how to have it start again?

About 10 days ago, the networking device that I use to monitor traffic from the PVS5x disconnected from my home network. I did not notice this because, somehow, the usage data was still being uploaded to the SunPower monitoring website (I haven't built out my own homebrew graphing yet.) I'm assuming it was done through the backup cellular connection, since there was definitely no way that the PVS5x had internet connectivity through my home network.

Since resolving the networking problem between the PVS5x and my home internet connection, I have observed the PVS5x POST message 100 (my system serial number) to /Command/SMS2DataCollector.aspx, however I've seen no POSTS to /Data/SMS2DataCollector.aspx and consequently no message 130, 141, or 140 data. And yet the monitoring website is still being updated with new data.

Curiously after I discovered the lack of internet connection, there was no LED indication on the PVS5x that there was a network problem. I did powercycle the PVS5x last night to see if that would help and it has not.

Any thoughts or experiences would be appreciated. Thanks!

[apara]

Here is how my packet output looks like (with some 130 lines snipped out):

100 SPMS 10 ZT170285000441C0308 20170619003543
120 20170619003500 ZT170285000441C0308 0 360 0 1 0 1035361 0.03 24348 12496

130 20170619003000 414051707015080 AC_Module_Type_C 28.6732 0.0579 244.6653 0.3435 0.0605 54.061 1.1044 44.75 59.988 0
130 20170619003000 414051707015260 AC_Module_Type_C 28.6014 0.0555 245.3928 0.4019 0.058 53.8978 1.0619 47 59.9862 0
130 20170619003000 414051707014786 AC_Module_Type_C 28.9052 0.1654 244.9078 0.7069 0.172 53.8727 3.1672 56.625 59.9862 0
...
141 20170619003000 PVS5M562239c PVS5M0400c 1 5.8942 5.9624 121.9598 122.7836 -0.662 -0.2178 392.38
140 20170619003000 PVS5M562239c PVS5M0400c 100 -211.52 -0.8799 0.8759 1.4509 -0.606 59.969 0
140 20170619003000 PVS5M562239p PVS5M0400p 50 0 0 0 0 1 59.969 0
102 AngZdD3DD7u2WG/LDEnV

By using parts of code developed by Eric Hampshire, while learning Python, and comparing this data with the old SunPower monitoring system, I think the 130 line maps like this:

0) 130 -- reporting type
1) 20170618195000 -- date/time
2) 414051708000625 -- serial number
3) AC_Module_Type_C -- description

4) 27.8296 -- total lifetime energy in kWh

AC Power(5) = Voltage (6) * Current (7)

5) 0.3109 -- average AC power in kW (currently picking up from sun AC, max .360 kW)
6) 248.4238 -- average AC voltage in V
7) 1.2782 -- average AC current in A

DC Power(8) = Voltage (9) * Current (10)

8) 0.3245 -- average DC power MPPT 1 in kW (currently picking up from the sun)
9) 52.6426 -- average DC voltage MPPT 1 in V
10) 6.142 -- average DC current MPPT 1 in A

11) 65.125 -- panel temperature in C
12) 60.006 -- average operating frequency in Hz
13) 0

While I think I have the 130 line figured out, does anyone know how to read the 140 line and why there are two of them in my output:

140 20170619003000 PVS5M562239c PVS5M0400c 100 -211.52 -0.8799 0.8759 1.4509 -0.606 59.969 0
140 20170619003000 PVS5M562239p PVS5M0400p 50 0 0 0 0 1 59.969 0

Thanks.

[DanKegel]

My equipment is completely different, but my vendor sends out silly packets once a day, too. I figure they aren't affected by the crud, so they don't care.

[JJNorcal]

I've seen a handful of malformed 130s now. They occur maybe once or twice a week, always coinciding with the first 130 of a new day.

As an example, these two 130s were transmitted in the same packet:

130\t20170611124000\t1913171660\tSMA-SB-7700TL-US-22\t\t\t\t\t\t\t\t0\t16.7\t59.9999\t0\n
130\t20170611124500\t1913171660\tSMA-SB-7700TL-US-22\t\t11752.6205\t0\t\t\t0\t297.1212\t0\t16.6875\t 59.9906\t0\n

The bogus 130 line contains 8 non-blank fields, whereas good 130s contain 12.

The missing fields has resulted in my app sending the frequency (59.9999) above as instantaneous power, with PVO rejecting it as too big.

I decided to block all 130s that don't contain 12 fields.

Questions: (1) Has anybody else received any malformed packets? (2) Does anybody know how to determine if there is a PVS firmware update available?

[JJNorcal]

Tshark based sniffing has performed very well. App stoppage has not recurred, and perfect PVO reports for a week.

There was one malformed 130 packet, which coincided with the first 130 leading into the zeros that start a new day. An extra field led to lifetime energy being reported instead of an instantaneous zero power. PVO rejected the datapoint as "too big". I wouldn't have noticed the event had I not replayed saved packets on Windows while playing with Visual Studio node debugging. So one apparently bad packet after a week, found playing and confirmed by subsequent reviewing of live log file.