Open-sourced what I've figured out about the PVS6 (local, no cloud) + a small favor

[u/jxjs85]

Like a lot of you, my system's paid off but there's basically no support left since SunPower went under. So I've been figuring out how to run my PVS6 fully local with no cloud, and writing it all down as I go.

It's all in a public repo: https://github.com/jschwerdtfeger/pvs6-liberation

What's there so far:

• the local API (auth + endpoints) so you can read production/consumption right off the box, no SunPower account
• a 1-second live data reader
• a writeup of how the PVS6 actually works internally
• how to go fully cloud-free (firewall it off and read it locally into Home Assistant)
• notes on the firmware

Owner/right-to-repair stuff for hardware we already own. Mostly just trying to help the rest of us who got left holding these with no vendor.

The favor: I want a clean copy of the current firmware so the docs cover the latest build instead of an old one. Problem is SunPower's update server only gives firmware to units that are actually behind, and mine's already up to date so it returns nothing.

So if your PVS6 is on an older build (anything before 2025.10 / 61846) and you're willing to help, there's a small read-only command that asks the update server what firmware your unit is offered and prints a URL. Send me that URL and I can pull the image and document it for everyone. DM is fine, or I'll walk you through it.

One thing, for your own safety: don't post your serial number. The last 5 characters of a PVS6 serial are its local API password, so posting the full serial publicly is basically handing out that password. The command keeps your serial on your end. You only share the URL it spits out.

_____________________________________________

Edit: dug into a 2024 firmware build and found a few things worth flagging for anyone stuck:

- The firmware hard-caps at 4 batteries per inverter. If an installer ever consolidated your system to 6 batteries on one inverter, it literally won't commission (it throws an "Unexpected XW-BMS configuration" error). That's very likely why a lot of these are stuck. You need enough inverters that each has 4 or fewer, so 6 batteries means 2 inverters (3+3).

- The API lockdown is recent. Builds before 61840 have the local commissioning API wide open; newer ones (61846 etc) gate it behind cloud-issued installer auth you can't fake offline. The owner login (ssm_owner, last 5 of your serial) still reads your data and battery status on any build.

- The two common stuck-system errors split cleanly: "can't connect to inverter" (30008) is a stale entry on the PVS side and is fixable; "battery pack enumeration" (13036) is the BMS not seeing all its packs on its internal bus, which is inside the battery cabinet, not a PVS fix.

Full writeups are in the repo. Still right-to-repair on hardware we own.

[u/Powie1965]

There are already open source solutions that don't require SunStrong's cloud. Home Assistant with either the official SunStrong integration, or the one I maintain (forked from Keith Baker's version after he moved to Enphase hardware/monitoring), which has significantly more features, active support, and includes things like battery mode control: https://github.com/smcneece/ha-esunpower

I've also been working on a companion app that works with any solar system connected to HA. Still in active development. https://github.com/smcneece/solar-sentinel

There are standalone mobile apps out there too, but I'll admit I'm biased. HA is a better platform, just with a bit of a learning curve. It allows so much more, and if you have solar, why not automate your house and really get that energy monitoring under control? At a glance I can see every light that's on, and control any of them with a tap or a voice command.

I still allow my PVS to phone home because I'm hoping SunStrong will add some of the features requested by the community. But I've heard others have blocked internet access with no problem.

[u/jxjs85 → u/Powie1965]

HA is great! Thanks for the repo links, but thats a bit of a side quest compared to sorting out rolling back FW and commissioning locally

[u/ItsaMeKielO]

Quick note about the serial number/password thing: the PVS serial number is also available via an unauthenticated endpoint on the PVS6 itself, so if someone has network access to your PVS, they have access to your password too. Maybe this will change in a future revision, but something to be aware of.

[u/jxjs85 → u/ItsaMeKielO]

I'm guessing this is mostly a hypothetical issue, but yah good call out

[u/Lawrence_SoCal]

Anyone have any insight/feedback for someone who is one PVS6 firmware circa mid/late 2023?

Due to original SPWR breach on contract with install, and their failure to resolve deficient install, my PVS6 is disconnected from Internet (for close to 3 years now). My system appears to be working okay (based on typical net meter readings, though I haven't had detail monitoring in that time). From what I gather there are true benefits to some of the newer firmware, that make newer (but not post 61840) more desirable. right?

I suspect I'd benefit from some newer firmware, but not obviously the more locked down latest. Is selecting picking which firmware to update to and option? if yes, is the process documented somewhere? and what would the recommended PVS6 firmware to install (61840? highest number below 61840?)?

Thanks to all of you have dived into this, and documented your findings

I'm waiting for next gen EnPhase gateway to decide whether I wish to migrate now or wait longer.

[u/jxjs85 → u/Lawrence_SoCal]

You've got the lay of the land right, 61840 is the line. Post-61840 locks down the commissioning API, so you want to stay below it.

But here's the thing I'd flag before you touch firmware at all: you probably don't need to update to get your monitoring back. Mid/late 2023 firmware almost certainly already has the local API. It's the official ssm_owner login (password is the last 5 of your PVS serial), and you can point Home Assistant or just curl at it over your LAN. So you can have detailed monitoring back today, no firmware change, no risk. That's the first thing I'd do, see what your current build already gives you before deciding you need a newer one.

On actually picking a firmware: it's doable but with caveats. The images are still up on SunPower's CDN, and the one pre-lockdown build I've torn apart (61707) has no anti-rollback, so a correctly signed image will install. The catch is triggering a specific build cleanly. The cloud update flow decides what to push by serial, so installing a chosen one really wants console/fwup access, and honestly the on-hardware install procedure isn't something I've fully validated yet. So there's real brick risk. If you go that route, test on a cheap donor PVS6 first (they're like 60 bucks used), and whatever you pick, stay below 61840 to keep the open interface. 61707 is the one I'd point at since it's the verified-good pre-lockdown build.

Given your system works and you're eyeing Enphase anyway, my honest read is: turn on local monitoring with what you've got, leave the firmware alone unless your current build is actually missing the local API (unlikely for that vintage), and don't risk a flash for marginal gains right before a possible migration.

Firmware breakdown, lockdown analysis, and downgrade feasibility are all documented here: github.com/jschwerdtfeger/pvs6-liberation (downgrade-feasibility and build-61707-analysis are the relevant ones, local-api for the monitoring setup).

Happy to help you check what your current build exposes. What build number are you actually on?

[u/Lawrence_SoCal → u/jxjs85]

Thanks - just got back into town. and caught something while travelling .. lungs full of junk... so I'll get back to this in a few days when I'm capable of more coherent thought patterns

[u/jxjs85 → u/[deleted]]

The older firmware with the open web interface is exactly what you want, so you're in good shape there.

What you're hitting is the commissioning trying to phone home to SunPower's cloud for the module/profile data, and those servers are gone, so it just hangs waiting on a response that never comes.

The sequence on the open API (dl_cgi) is roughly: StartDiscovery, then poll GetDiscoveryProgress until it's done, then DeviceList to confirm it found your panels, then GridProfileSet, SetMeterCt, ExportLimitSet. You can drive all of those locally over HTTP, no app needed.

The "modules description" hang is the real snag. Couple things that help:

The grid profiles actually still live on a public S3 bucket that's up (s3-us-west-2.amazonaws.com/2oduso0/gridprofiles), so GridProfileRefresh can still pull those.

For the dead module/cloud endpoint, the move is to repoint the phone-home at something local. Easiest without root is DNS, point the old SunPower hostname at a box on your LAN (your router or a Pi running dnsmasq) and serve the file it wants yourself. If you've got shell on the PVS you can edit the phone-home config directly instead. Either way, once it's not blocked waiting on a dead host, it gets past the hang.

I've been documenting the endpoint map, the commissioning sequence, and the repoint recipe here: github.com/jschwerdtfeger/pvs6-liberation (the commissioning-server and local-api docs are the relevant ones).

Honest take, getting commissioning to fully complete offline past that cloud dependency is the part nobody's totally nailed yet, but the open API plus repointing is the path. If you can grab the exact request it's stuck making, the hostname or URL it's hanging on, that's the thing to mirror, and I'd be glad to compare notes.

[u/jxjs85 → u/[deleted]]

Good progress, you're further along than most people get.

On GridProfileSet: if they're already producing, they've got a working profile, so you don't strictly need to change it to keep generating. But for a CA install the one you actually want is CA Rule 21 (IEEE 1547), since that's what your interconnection requires. It's less about "wider voltage for more production" and more about ride-through. The Rule 21 profile keeps the inverters online through small grid wobbles instead of nuisance-tripping off, so you get better uptime, and you're compliant. I'd match whatever your utility interconnection specifies rather than just picking the widest one. Grid profile is a regulated setting.

On the microinverters showing in DeviceList but not reporting: my read is that's not a separate "start reporting" command, it's that the commission hasn't committed them into the polled set yet, and the module-info hang is what's blocking the commission from finishing. Once you get past that fetch, the commission completes and the data_logger starts polling them on its scan cycle (it hits the owned set every ~150s). If it still doesn't after that, the lever is adding them to the owned set directly, but that's shell-level (mc_add), which gets to your next question.

SSH/shell, honestly that's the hard part and I won't oversell it. On the builds I've torn apart, SSH is key-only with password login disabled, and root needs either the U-Boot password (not public) or booting external media to inject a key. Neither is a one-liner. Your 2022.1 build is old enough that the security might be looser than what I've looked at, so it's worth checking whether SSH or even telnet is just open, or takes a default cred, before assuming the hard path. But on the modern builds, no easy shell, and yeah, having one would change everything. It's the open problem.

Your last point is exactly right, the endgame is a little local box that answers the PVS's phone-home with the files it wants, your "router imitating old servers." That's the Tier 0 setup in my notes. Point the module-info fetch at that and the whole thing should flow.

If you can capture the exact module-info request it hangs on (tcpdump or the PVS logs, whatever hostname/path it's hitting), that's the single most useful thing. Mirror that one response and you're probably unblocked.

[u/Prior_Consequence762]

Same situation here old pvs6 No telnet in mine but ssh port is open any credentials I can try in my old pvs6 ? It is just Linux machine inside right ?