What we shipped in Q1 2026: Solis parity, mobile sign-off, push alerts

We promised to keep the changelog honest. This is the longer-form version of what’s been landing in SolarFleet through the first four months of 2026, and the bits that didn’t quite make it but are close.

Solis Cloud parity with SolarEdge

The big one. As of mid-March, Solis sites in SolarFleet have feature parity with SolarEdge sites — same detection rules, same alerts, same case workflow, same reporting.

When we launched, Solis was listed as supported. That was true but understated the gap. SolarEdge had the optimiser-derived diagnostics, the partial-MPPT detection, and the storm-pattern recognition. Solis had basic native alerts plus our own current-comparison detections — useful, but not at parity.

What changed:

• Per-MPPT history and trend is now pulled from Solis on the same cadence as SolarEdge. Our adapter now handles the Solis timestamp format properly (a story unto itself — the API returns time-only strings under certain conditions, which we had to normalise before the trend data lined up with SolarEdge’s).
• Six derived detections — relative drop, persistent zero, partial offline, comms stale, inverter offline, optimiser drop — now run identically on both brands. The optimiser-drop rule is naturally a no-op on Solis (it has no optimisers); the other five are live.
• Solis polling cadence is faster than SolarEdge. Solis Cloud’s rate limits permit a 5-minute polling interval; SolarEdge’s standard API permits 15 minutes. We use the maximum the upstream allows on each. So in practice, a Solis site sees fault detection at three times the temporal resolution of a SolarEdge site — which is one of the reasons we wrote about the economics of detection latency.
• Storm-pattern detection — when wind speed exceeds a configurable threshold from the Open-Meteo feed for the site, we automatically open a case for an inspection within seven days. The case carries the storm timestamps as evidence. This came out of a real fault on our own fleet — the storm trigger is exactly the workflow change we made internally, now available on every account.

The net is that Solis sites no longer feel like the second-class brand on the platform. They are functionally equivalent to SolarEdge for monitoring and detection. The 62446-1 inspection workflow doesn’t depend on brand and works the same on both.

Offline mobile sign-off for 62446-1 inspections

Shipped in February. The 62446-1 inspection flow on mobile is now fully offline-first.

The use case: an engineer is on a site with no signal — a rural commercial roof, a basement plant room, a roof with thick concrete that defeats 4G. They open the 62446 inspection on their phone, work through the test points, take photos, record values, and sign. When they get back to signal, the inspection syncs and the PDF generates.

Three engineering pieces had to come together:

• Local storage for the in-progress inspection. Test values, photos, and signatures live in IndexedDB on the device until they sync.
• Photo capture without round-tripping. Each photo is processed locally and queued; the GPS tag is captured at the moment of taking the photo, not at the moment of upload, so the photo provenance (which auditors care about) is preserved correctly.
• Conflict-free sync. If the engineer’s connection comes and goes during the inspection — typical on a rooftop where signal is intermittent — the partial sync handles that without losing data.

There’s still one limitation: the actual PDF rendering happens server-side, so the engineer can’t preview the final report until they’re back in signal. We’ll close that in Q3.

Push notifications

The other Q1 lander. As of April, SolarFleet can push critical alerts directly to engineers’ phones via Web Push.

The trigger: a CRITICAL severity case opens, or an existing case crosses its SLA threshold without acknowledgement. The alert reaches the on-call engineer’s phone within seconds of the detection firing.

The bit we’d been deferring on push notifications was reliability. Browser push has a reputation for being flaky, and an unreliable alert system is worse than no alert system — it creates a false sense of coverage. We built it on top of Web Push (W3C standard, works on iOS Safari and Android Chrome) with a delivery audit trail: every push attempt logs whether the device acknowledged receipt, so a missed push is visible to the operator.

The opt-in is per-engineer. Each user in your organisation decides which severities they want push for, and on which sites. The defaults are “CRITICAL only, all sites you’re assigned to”, which is the sensible starting point. SLA breaches always push, regardless of severity preference.

There is no charge for push notifications. They’re part of every plan including the free tier.

Smaller things that landed

A short list of changes that won’t get a blog post but are real improvements:

• Bulk case import. The CSV-import endpoint for cases now exists. Operations migrating from a legacy platform can carry their open case backlog across in one upload.
• Per-site tags with search. Site tags now support multi-value and filtering across the fleet view. “Show me every site with roof-access:cherry-picker-only and warranty:expired” returns the matching set instantly.
• Saved searches. A natural extension of the above. The searches you run regularly can be saved and reused; on the home dashboard they show as a configurable widget.
• Mobile responsive pass. The whole dashboard, sites view, alerts queue and cases queue got a proper mobile pass. The platform is now usable on a phone for everyday operations work, not just for inspections.
• Accessibility pass. Skip links, focus rings, ARIA landmarks, modal focus traps, every form field properly labelled. We’re not formally certified to WCAG 2.2 AA but the audit is in the work queue.
• Site transfers between organisations. If a site changes ownership — common in the secondary market — the site (with its history) can be transferred from one organisation account to another. The transfer is a two-step ritual: the sending org initiates, the receiving org accepts. The audit trail follows.
• WorkOS authentication. We migrated the sign-in flow to WorkOS AuthKit in early May. Most users won’t notice; some will see SSO options that weren’t there before. Enterprise SSO is now straightforward to configure for customers who want it.

The things that didn’t ship

In the spirit of keeping the changelog honest:

• Client portals. Still not shipped. Coming in Q3. We’ve decided what the v1 looks like and have started implementation; we want it to be useful enough that owners actually log in, which means more thought than a read-only mirror of the operator view.
• Sungrow integration. Adapter in development, not yet live. Expected before end of Q2.
• SMA, Fronius. No fixed date. Customer demand will move them up the queue.
• Per-optimiser data from SolarEdge. Still gated behind a higher API tier on the SolarEdge side. We can’t fix this from our side — it’s a SolarEdge commercial decision. We derive everything possible from the standard tier (the partial-offline detection is the centrepiece — it surfaces an under-performing section without per-optimiser telemetry) but the per-optimiser story isn’t fully closed.
• Native counter-sign workflow for 62446-1 reports. Today the engineer signs in the mobile app; the client counter-signs via email. A native counter-sign flow is drafted but not implemented.
• Performance ratio forecasting. We forecast expected kWh against weather data; we don’t yet forecast forward PR using a weather forecast feed. Q3 work.

What we’re working on next

For the next few months:

• Sungrow integration to production. The adapter exists; it needs verification against a real customer’s fleet.
• Hybrid systems (battery + PV + EMS) — the data model has been there since launch; the UI surfaces for hybrid sites need polish.
• Public client portal v1. Owner accounts, read-only view of their own sites, the monthly report on demand.
• Quote Mode for installers. A standalone product mode for installers writing O&M proposals, with the platform’s pricing knowledge as the back-end.
• Site grouping and rollup reporting. For operators with hierarchical clients (one parent organisation, multiple sub-portfolios) the rollup reporting needs work.

If any of those are blocking adoption for you, tell us — the roadmap moves on customer demand.

A note on how we ship

We deploy continuously. There is no maintenance window. There are no release notes that read like a corporate quarterly update. There’s a changelog that lists every meaningful change with a date.

The deeper point is that we treat the platform as a product that’s always being worked on, not a project with a fixed delivery date. This works because we’re a small team using continuous deployment with proper testing — it wouldn’t work if we were a larger team without the infrastructure investment.

For everyone on the platform, the practical effect is that reported bugs get fixed in days, not in the next quarterly release. The flipside is that occasionally something new will appear in the dashboard that wasn’t pre-briefed. We try to balance that with proactive communication via the in-app notice for anything user-facing, and reserved silence for the back-end changes nobody needs to know about.

Thanks for reading. As ever, hello@solarfleet.io reaches us. We answer our own emails.

---

Start free with 2 sites — Solis and SolarEdge supported on day one, with mobile inspections and push alerts built in. Or see the full changelog.