Mirroring/intercepting SunPower Monitoring Traffic?

[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.

[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]

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]

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]

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]

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]

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

[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:

[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]

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 .