The short answer
A 403 unauthorized from your PVS6 almost always means the endpoint you called wants a session and you haven't opened one. Newer gateway firmware authenticates locally over HTTPS with HTTP Basic credentials, then issues a session cookie that the rest of your requests have to carry.
The credentials are not a secret and never were. The username is ssm_owner, and the password is the last five characters of the gateway's serial number — printed on the label inside the door.
The actual call
This is the request our own monitor makes, unchanged. The gateway presents a self-signed certificate on its LAN interface, so certificate verification has to be off:
GET https://<gateway>/auth?login
Authorization: Basic base64("ssm_owner:<last 5 of serial>")A 200 sets a session cookie. Carry that cookie on the follow-up read:
GET https://<gateway>/cgi-bin/dl_cgi/devices/listThat returns every device the gateway knows about — the supervisor, the meters, and one entry per microinverter with its serial and its output. It is slow: a full poll cycle measured about 11 seconds on our hardware, so give it a generous read timeout and poll gently.
If that read comes back 403, your session expired. Log in once more and retry — once. A second 403 is a real credential problem, and the usual cause is the wrong five characters.
There are two firmware generations, and a 403 doesn't tell you which
This is the part most write-ups have backwards, ours included until we measured it. The common account is that a September 2025 firmware update added authentication and that 403s are the symptom. What we actually observed on two of our own gateways, probed the same day in August 2026:
| Request | 2025 build (61846) | 2023 build (61410) |
|---|---|---|
| <code>/auth?login</code> | 200 | <strong>404 — no such route</strong> |
| <code>dl_cgi/supervisor/info</code> | 200, full payload | <strong>403</strong>, empty <code>{}</code> |
| <code>dl_cgi/devices/list</code> | works | works |
Read that table twice, because it inverts the usual story. The older gateway is the one returning 403. The newer one authenticates and then answers everything. And neither has ever returned 403 on the device list — the endpoint that actually carries your production data.
So don't work out your firmware generation from a 403. Ask whether /auth exists. A 404 there means an older, pre-authentication build, and it is not an error — those gateways have no login route and their endpoints are open. Read them straight.
That distinction is not academic. We got it wrong once, and raise_for_status() turned a perfectly normal 404 into an exception that stopped us asking for readings at all. A customer lost his entire first day of data while the gateway sat there holding it, and the app told him to check a cable that was already fine.
What that gets you, and what it doesn't
Everything above is roughly an afternoon's work, and it genuinely does get you a live reading. Then the real work starts, and it is the part nobody writes a blog post about. Here is what we hit after the door opened:
- The gateway refreshes each microinverter about every 15 minutes. Poll it every two minutes and roughly seven readings in eight are duplicates of a value that hasn't moved. One of our gateways logs over 20,000 inverter rows a day across 31 panels, and most of them say nothing new.
- At dusk a microinverter stops reporting and the gateway re-serves its last frame unchanged until dawn. Take it at face value and your dashboard shows a panel producing 17.9 volts at 11pm, every night, forever.
- Some gateways reboot themselves. One of our four does it two to three times a day; the other three never have. On reboot the clock can snap back to a stored date, so timestamps run backwards and readings collide.
- Your monitor will lose its connection. Home internet drops, gateways restart. Anything not spooled locally and backfilled afterwards is a permanent hole in your own production history.
- The DC and AC figures aren't from the same moment. DC volts and amps are instantaneous at broadcast; AC power is an average across the interval. Put them side by side unaligned and they don't reconcile, and they never will.
- The interface has already moved twice. Whatever you build, someone has to keep watching it.
None of that is a reason not to build it. Plenty of people have, and the maintained projects are good. It is just the honest shape of the job: the auth header is the beginning, not the end.
Or skip to the part after all that
That list is a fair summary of what the WattHacker monitor already handles, because we hit every item on it. It spools through outages and backfills, collapses the duplicate readings, keeps one offset per gateway reboot session, describes the day instead of showing you a frozen dusk frame, and puts the DC and AC figures on the same basis before showing them together.
On top of that it does the things the raw feed can't: measured monthly shade analysis from your own clear-day production, per-panel history kept for as long as you're a subscriber, and a formal production record you can hand an installer, an insurer, or a buyer.
It's a box you plug in — $50 — and it reads the gateway on your own network. If you'd rather build it, build it. This page is the same information we work from, and we'd rather you got there either way than sat on a 403 for another ten weeks.
The bigger point: this will happen again
The lesson from the last two years isn't "here is the workaround for the current build". It is that the local interface is a moving target, controlled by a company with no obligation to keep your setup working, and it has already shifted more than once.
Whatever route you pick, pick one that someone is actively maintaining — a project with recent commits, or a product whose job it is to track the changes. A setup that works today and is nobody's responsibility to fix is a setup with an expiry date.
Where WattHacker fits
The WattHacker monitor is a small box that plugs into your existing SunPower PVS6 gateway on your own home network and reads it directly. It doesn't rely on SunPower's or SunStrong's servers, because for owners like you those are either gone or behind a paywall. No technician, no electrician, no rewiring — you plug it in yourself.
- The monitor is $50 once, with a 30-day money-back guarantee.
- Free to see your panel data, forever — every panel, live, no subscription, and no card on file.
- An optional premium plan at $6/mo (billed annually) adds the memory: full history kept for good, year-over-year comparison, and alerts told to you in dollars.
- Built by an electrification superfan who wants to help others use their solar smarter, lower their utility bills, and clean up the planet. Who's behind it.
Still have questions about your own system? I'll go through it with you — your panels, your bill, and what's worth doing about it.
Book an energy reviewOwn a SunPower PVS6? See it for SunPower.
Real panels, real production.
Common questions
Why does my PVS6 return 403 unauthorized?
Usually because the endpoint you're calling needs a session and you don't have one. The local interface on newer gateway firmware authenticates with HTTP Basic credentials — the username ssm_owner and the last five characters of the gateway's serial number — and hands back a session cookie. Without that cookie, protected endpoints answer 403. Nothing is wrong with your gateway or your network.
Does a 403 tell me which firmware my gateway is on?
No, and this is where most guides get it wrong. We probed two of our own gateways in August 2026: the OLDER one, on a 2023 build, is the one that returns 403 on the supervisor/info endpoint, while the newer 2025 build serves it normally. Neither has ever returned 403 on the device list. Don't classify your firmware generation from a 403 — check whether /auth exists instead.
What does it mean if /auth returns 404?
That you're on an older, pre-authentication build, and it is not a failure. Those gateways have no /auth route at all and their local endpoints are open — no cookie, no credentials, just data. Treating that 404 as an error is a real bug: it cost one of our own customers a full day of readings that were sitting on the gateway the whole time.
Can I stop my gateway updating its firmware?
Not reliably, and it is not a good idea to try. The gateway pulls firmware as part of normal operation, and blocking it can leave you on an old build with its own problems. Plan for the interface changing again instead of trying to freeze it.
Which local monitoring tools still work?
The actively maintained open-source projects have adapted — smcneece/ha-esunpower and krbaker/hass-sunpower are the two most commonly used with Home Assistant, and pypvs is the library to build on. Check each project's recent commits before you invest an evening: the maintained ones track firmware changes, and the ones that are not have stopped working.
See your own panels, live.
See plans Try the demo Back to home