Mirroring/intercepting SunPower Monitoring Traffic?

[Ethan Blackwood]

Hi Ethan

I like the idea about the donation of 16kwh but I would appreciate that you not advertise on this forum unless you want to get banned,

Hi , I am not advertise here , I just see this news on a website , thank you for your kindness .

[SunEagle]

The ‘Buy 100, Donate 1’ Trend in Energy Tech – Humanitarian Aid or Strategic Marketing?"

A recent initiative by Shenzhen Calion Power has sparked debate in the energy sector:

The company pledges to donate one 16KWh ESS unit to Ukraine for every 100 units sold globally.

The system boasts 4-input flexibility (solar/wind/diesel/grid) and a 10,000-cycle lifespan, potentially offering long-term support to crisis zones.

Key Discussion Points:

Hi Ethan

I like the idea about the donation of 16kwh but I would appreciate that you not advertise on this forum unless you want to get banned,

[Ethan Blackwood]

The ‘Buy 100, Donate 1’ Trend in Energy Tech – Humanitarian Aid or Strategic Marketing?"

A recent initiative by Shenzhen Calion Power has sparked debate in the energy sector:

The company pledges to donate one 16KWh ESS unit to Ukraine for every 100 units sold globally.

The system boasts 4-input flexibility (solar/wind/diesel/grid) and a 10,000-cycle lifespan, potentially offering long-term support to crisis zones.

Key Discussion Points:

[astroboy]

I take it the PVS2 didn't always behave like this, but I am not sure what caused the change in behavior and I don't have any old data to compare to. I really need to spend some time analyzing those batches, but based on some very limited glances it appears that the lifetime production values for each inverter keep increasing and there is no apparent resending of records as I think someone speculated.

that's right, this was new behavior that happened around the time i necroposted in this thread. i don't know exactly when it started. my assumption has been that it's just some bug in the PVS2 firmware that happened to rear it's head at some point in early 2025.

you're right that each message still seems to have unique data. the timestamps are just clobbered and so it's hard to know for what time periods the data actually belongs to since the message come in bursts at the same time. also i noticed that in the first 30 minutes of the hour there are enough messages with unique timestamps that my script sends the right stuff to PVO, but in the 2nd half of the hour there don't seem to be any messages at all, and i assume all the data for that period comes in the first message transmitted at the top of the hour. in the following, the # preceding the timestamp is the number of messages that appeared at that wall clock time. you can see the big gap between 16:33:45 and 17:03:52. i can't remember anymore at what interval it used to send messages before this problem, but it seems like 20 messages in 5 minutes is excessive (for instance, @ 17:08:53). i suppose from the delta in total generation and instantaneous power one could compute how much time is represented by a given sample.

11 Tue Apr 8 16:03:35 2025 inverter sent message 130 to sunpower
7  Tue Apr 8 16:03:36 2025 inverter sent message 130 to sunpower
21 Tue Apr 8 16:08:38 2025 inverter sent message 130 to sunpower
20 Tue Apr 8 16:13:39 2025 inverter sent message 130 to sunpower
20 Tue Apr 8 16:18:40 2025 inverter sent message 130 to sunpower
20 Tue Apr 8 16:23:42 2025 inverter sent message 130 to sunpower
20 Tue Apr 8 16:28:43 2025 inverter sent message 130 to sunpower
4  Tue Apr 8 16:33:45 2025 inverter sent message 130 to sunpower
17 Tue Apr 8 17:03:52 2025 inverter sent message 130 to sunpower
20 Tue Apr 8 17:08:53 2025 inverter sent message 130 to sunpower
5  Tue Apr 8 17:13:55 2025 inverter sent message 130 to sunpower
15 Tue Apr 8 17:13:56 2025 inverter sent message 130 to sunpower
5  Tue Apr 8 17:18:56 2025 inverter sent message 130 to sunpower
15 Tue Apr 8 17:18:57 2025 inverter sent message 130 to sunpower
20 Tue Apr 8 17:23:58 2025 inverter sent message 130 to sunpower

as a result of this my PVO data looks like this:

Screenshot 2025-04-08 at 5.36.39 PM.png

[hmwt]

i put a CNAME mapping into my DNS server and it seems like the PVS2 might not know what to do with that; it doesn't seem to try to dereference the pointer it's given. i briefly tried just hardcoding the IP address that collector.sunstrongmonitoring.com currently resolves to and that might have caused the PVS2 to start sending message again (but it is still broken, sending bursts of messages that are apparently 5 minute data with the same timestamp.) were you able to get CNAME to work or did you have to hardcode the IP address?

I use a hardcoded IP address in my instance of PiHole that allows such a mapping. I haven't looked into any CNAME mapping, but on Reddit some folks apparently got it to work with pfSense. Don't really have time to figure that out at the moment.

And yes, my PVS is sending those bursts of 130/131s every five minutes, with the actual time stamps in the 130/131 messages being the full hour. It isn't always the same full hour for each 130/131 message (there are some batches that apparently cross the full hour boundary), and it's not always the same number of messages, i.e., it's not like there is one record for each minute in the five minute interval or something like that.

I take it the PVS2 didn't always behave like this, but I am not sure what caused the change in behavior and I don't have any old data to compare to. I really need to spend some time analyzing those batches, but based on some very limited glances it appears that the lifetime production values for each inverter keep increasing and there is no apparent resending of records as I think someone speculated.

[astroboy]

Thanks. I'll probably just log them, but don't really see much value in them unless it's useful for some failure diagnostics.

yeah, i just sent them to the PVO extended data. this was somewhat useful for me during a period in which my inverter would not reliably start in the morning. it turned out that PGE had goosed the voltage a bit to solve some problem further down the network from my house, but they were then outside of the 5% tolerance that NEC requires (and the SMA5000 rigidly adheres to.)

I'm in the process of logging a few days worth of data while the sunstrong server is still accepting my system's data transmissions. At a glance at some of the interactions it seems the 1002 responses from the server are all just timestamps, so that would be easy to reproduce.

sounds good.

i put a CNAME mapping into my DNS server and it seems like the PVS2 might not know what to do with that; it doesn't seem to try to dereference the pointer it's given. i briefly tried just hardcoding the IP address that collector.sunstrongmonitoring.com currently resolves to and that might have caused the PVS2 to start sending message again (but it is still broken, sending bursts of messages that are apparently 5 minute data with the same timestamp.) were you able to get CNAME to work or did you have to hardcode the IP address?

[hmwt]

hmwt message 131 seems to contain the voltage on phase1 and phase2 of the main AC power, and that's all.

Thanks. I'll probably just log them, but don't really see much value in them unless it's useful for some failure diagnostics.

i'm not sure i logged enough traffic to really understand what the inverter is expecting to receive back from any replacement for collector.sunpowermonitor.com. but maybe if collector.sunstrongmonitoring.com will understand the messages coming from an un-upgraded PVS2 then we can still see what the back-and-forth looks like.

I'm in the process of logging a few days worth of data while the sunstrong server is still accepting my system's data transmissions. At a glance at some of the interactions it seems the 1002 responses from the server are all just timestamps, so that would be easy to reproduce.

200 20b
Cache-Control: no-cache, no-transform, must-revalidate
Content-Type: text/plain
Date: Tue, 08 Apr 2025 21:33:33 GMT
Server: nginx
Content-Length: 20
Connection: keep-alive

1002 20250408213333


Some of the messages from the PVS2 to the server are cryptic (encoded or encrypted), as I think discussed earlier in the thread:

POST http://35.163.25.145/Command/SMS2DataCollector.aspx
Host: 35.163.25.145
Content-Type: text/plain
Content-Length: 65

100 SPMS 10 {PVS Serial Number} 20250408213240
102 6Ek0myT/Up5lqLooMrbl

No idea what the 102 message contains or what the purpose is, but it also doesn't appear to be important for my goal of capturing the production data, and the response to the 100/102 pair of messages is just another 1002 timestamp.

1002 20250408213239

[astroboy]

hmwt message 131 seems to contain the voltage on phase1 and phase2 of the main AC power, and that's all.

your post made me go look, yes, my inverter is getting SERVFAIL when trying to look up collector.sunpowermonitor.com. i guess i don't care too much anymore since at this point i can get all the same data from tesla's API.

i'm not sure i logged enough traffic to really understand what the inverter is expecting to receive back from any replacement for collector.sunpowermonitor.com. but maybe if collector.sunstrongmonitoring.com will understand the messages coming from an un-upgraded PVS2 then we can still see what the back-and-forth looks like.

[hmwt]

Is anyone still processing the data sent from PVS2 supervisors to Sunpower/SunStrong servers? If your system stopped connecting to the server on or about 3/21/25, you hopefully know that SunStrong apparently moved the old SunPower infrastructure to their own domain. PVS6 were mostly updated with a new firmware, but older PVS2 weren't and just stopped reporting because they couldn't connect anymore. That is sort of fixable by configuring your DNS such that a request for collector.sunpowermonitor.com gets mapped to collector.sunstrongmonitoring.com. Reddit has some useful discussions and info. Not clear how long this will work.

I had originally read this thread years ago, but never done anything with it, the recent changes and the upcoming switch to a paid service Sunstrong app replacing the free Sunpower app motivated me to start looking at alternative options again. I am now piping all my PVS2 traffic through a reverse proxy (mitmproxy) to see what is being sent and am trying to make sense of it.

It seems there are at least three options for people with old systems (PVS2 or otherwise) that likely aren't getting any support from SunStrong going forward:

1. Get some power monitoring hardware like Emporia Vue or Sense.

2. Access data via installer port.

3. Process data sent from PVS2 to the SunStrong servers.

My concern is what will happen if/when SunStrong changes the protocol or otherwise stops PVS2 systems from feeding their servers. Option 3 would stop working then. Will option 2 then continue forever, or will the PVS2 fill up some log file with connection failure messages or wear out its flash prematurely?

So my "brilliant' thought was, why not just build a replacement Sunpower server that behaves more or less like the Sunpower server (receives the messages from the PVS2 and stores the data, sends responses as the Sunpower/SunStrong server). That would make the system completely independent from SunStrong server infrastructure.

Thoughts?

So I have been reading through this thread again, and there is a lot of useful info it in, scattered across various discussions. I think I understand the structure and purpose of the 130 messages. There is no discussion of 131 messages -- are they new and what is their purpose? astroboy - did you figure out what the PVS2 is nowadays sending many 130 and 131 messages in one POST even when there is only one or two inverters?

[astroboy]

it looks like sunpower must have changed something, perhaps related to the bankruptcy. my script was designed to reject duplicate samples based on the time given in the message to sunpower. a couple of days ago the times started showing up with the minutes field set to 00, but messages were coming every 5 minutes as usual. so only once per hour would a message make it thru.

thinking maybe there was a firmware bug, i just rebooted the inverter (SMA 5000) and there was a brief message on the screen about an update. however, i'm not sure if that happens every boot or not. regardless now i'm seeing message 100 every 2-3 minutes - i think these are just keepalives. i haven't yet seen a message 130 or 131 but i assume that now i'll just get one per hour. i hope!

some years ago i added a tesla powerwall so i still have continuous monitoring of the solar output. but it would seem that sunpower has tried to cut server costs by reducing the amount of traffic by 12x.

edit: at 10AM i just got a 130 - so indeed it looks like monitoring is now once per hour. too bad.

edit2: hmm, it started sending 130 and 131 messages more frequently but they are coming in bursts. the minutes field coming from the inverter is still clamped at "00" each time. so something is very weird. i wonder if the sunpower server is rejecting them somehow causing the inverter to keep sending. the messages contain unique data but they all have the same timestamp. i guess i can fix the script to substitute the wall clock minutes before sending to PVOutput but it looks like i'll still be sending duplicate updates to PVO if i do this.

[intipower]

Hi Marciallapp. I have a pvs5 on my installation so the output is a bit different but I would guess (and someone correct me if I'm wrong)
This first one is the production meter
"net_ltea_3phsum_kwh": "14535.2303", --> life time net power generation
"p_3phsum_kw": "0.8852", --> current power generated

These are from the consumption meter
"neg_ltea_3phsum_kwh": "9856.6974",
"pos_ltea_3phsum_kwh": "10005.0955",
well, life time power accumulator but I don't know how neg (negative) and pos (positive) plays into it. in my system I have a CT for the consumption meter but the production meter numbers come from added up data based on the values of individual panel data because there isn't any CT to measure it on the line.

As far as scripts go, my data collection has gone through several rewrites. I started with using python to read the pvs5 data writing to mongo database but over the years I ended up with a node-red installation that does all the queries to the pvs5 and parses the data into the mongo db. I have some configuration data in the mongo db that controls what and how the data gets stored. Then I have some other endpoints in node-red which serve the data so Grafana can chart it. It all has some commented out code because I'm always playing around with it but it does the basics of what I wanted. I get the data collection and I can see the power / heat sink temp / what ever of each panel charted in Grafana. If you go way back in this thread you'll find my comments about using a raspberry pi to connect to the installers port at a time when everyone else was trying to sniff the network line and parse out data from the packets being sent back to sunpower. That was too complicated and there was too much conversion going on. I decided to store the data from the installers port in MongoDB because since I'm getting json from the pvs5 and MongoDB stores documents as json there is an advantage. There was a software update one time where the field names of the data changed and since I was just storing what I got out of the pvs5 I didn't loose any data like others did due to serialization errors when they tried to put it into their SQL like databases that required a schema. The only thing I had to fix was downstream interpretation of the data. Have you given any thought to your project beyond what you've shared here as far as what visualizations or tools you want to use to see your data ?

[marciallapp]

Not sure if anyone has decoded these yet, but could someone help with the meaning of the following fields?

{
"ISDETAIL": true,
"SERIAL": "PVS6M19180892p",
"TYPE": "PVS5-METER-P",
"STATE": "working",
"STATEDESCR": "Working",
"MODEL": "PVS6M0400p",
"DESCR": "Power Meter PVS6M19180892p",
"DEVICE_TYPE": "Power Meter",
"SWVER": "3000",
"PORT": "",
"DATATIME": "2021,02,14,19,16,43",
"ct_scl_fctr": "50",
"net_ltea_3phsum_kwh": "14535.2303",
"p_3phsum_kw": "0.8852",
"q_3phsum_kvar": "0.5067",
"s_3phsum_kva": "1.021",
"tot_pf_rto": "0.8502",
"freq_hz": "60",
"CAL0": "50",
"origin": "data_logger",
"OPERATION": "noop",
"CURTIME": "2021,02,14,19,16,44"
}, {
"ISDETAIL": true,
"SERIAL": "PVS6M19180892c",
"TYPE": "PVS5-METER-C",
"STATE": "working",
"STATEDESCR": "Working",
"MODEL": "PVS6M0400c",
"DESCR": "Power Meter PVS6M19180892c",
"DEVICE_TYPE": "Power Meter",
"SWVER": "3000",
"PORT": "",
"DATATIME": "2021,02,14,19,16,44",
"ct_scl_fctr": "100",
"net_ltea_3phsum_kwh": "148.3403",
"p_3phsum_kw": "6.9333",
"q_3phsum_kvar": "0.6461",
"s_3phsum_kva": "7.1999",
"tot_pf_rto": "0.9687",
"freq_hz": "60",
"i1_a": "25.6216",
"i2_a": "33.7147",
"v1n_v": "121.9915",
"v2n_v": "120.8465",
"v12_v": "242.8377",
"p1_kw": "2.9701",
"p2_kw": "3.9632",
"neg_ltea_3phsum_kwh": "9856.6974",
"pos_ltea_3phsum_kwh": "10005.0955",
"CAL0": "100",
"origin": "data_logger",
"OPERATION": "noop",
"CURTIME": "2021,02,14,19,16,44"

In the first device section, I am looking for:
"net_ltea_3phsum_kwh": "14535.2303",
"p_3phsum_kw": "0.8852",

In the second device section, I am looking for:
"neg_ltea_3phsum_kwh": "9856.6974",
"pos_ltea_3phsum_kwh": "10005.0955",

Thanks.

[marciallapp]

Here is the latest code that I have:

#!/usr/bin/python3

import requests
import json
import datetime
from datetime import datetime

# this is the default URL for the admin interface of SunPower PVS5
pvs5_url = "http://172.27.153.1/cgi-bin/dl_cgi?Command=DeviceList"

# pvoutput.org
pvoutput_url = "https://pvoutput.org/service/r2/addstatus.jsp"
pvoutput_key = "_your_key_"
pvoutput_systemid = "_your_id"

r = requests.get(pvs5_url)

prod = 0
net_usage = 0
total_usage = 0

for device in r.json()["devices"]:
if device["MODEL"] == "AC_Module_Type_D" and device["STATE"] != "error":
prod += float(device["p_3phsum_kw"])*1000
if device["MODEL"] == "PVS5M0400c":
net_usage = float(device["p_3phsum_kw"])*1000

total_usage = prod + net_usage

date = datetime.now()

requests.post(pvoutput_url, data={"d":date.strftime('%Y%m%d'), "t":date.strftime('%H:%M'), "v2": prod, "v4":total_usage}, headers = {'X-Pvoutput-Apikey': pvoutput_key, 'X-Pvoutput-SystemId': pvoutput_systemid})

Hi everyone. I am new to Sunpower, but have managed to hook up a RasberryPi to the admin port and I am able to connect there to get data.

Does anyone have a script, similar to the one above that essentially calls up with PV, gets the data and then stores this into a database (like mysql)? Alternatively, does anyone have a way to decode the messages that come from the PV? (i.e. what fields represent what data)?

Thanks!

[J.P.M.]

It looks like sunpower disabled my access to their installer link which showed stats per panel. Did anyone else get knocked out? I have not logged in for a few months. I liked being able to check at the panel level.

Most everyone got knocked out.

Sunpower, never a powerhouse with respect to helpful, informed customer service, dropped a lot of information access.

That was most likely done, at least in the opinion of some informed folks, because S.P. got sick of answering a lot of ignorant questions from ignorant users who thought differences of a fraction of a volt or two between panels meant ailing systems, or who were apoplectic because their panels weren't always putting out the STC rating. Such questions started popping up with annoying frequency about the time or shortly after S.P. went to microinverters.

Having been knocking around here for 7+ years, I don't doubt such things added to the S.P decision to reduce access to data, but having dealt w/ S.P. a fair amount, I'm equally sure other reasons such as cost savings as well as their disregard to customer service had equal impact in the decision.

[Crash]

It looks like sunpower disabled my access to their installer link which showed stats per panel. Did anyone else get knocked out? I have not logged in for a few months. I liked being able to check at the panel level.