Product · Detection engine

Solar fault detection that finds the leak, not just the outage.

A green status light tells you an inverter is online. It doesn't tell you the site has been underperforming for three weeks. SolarFleet runs six detections across your whole portfolio — weather-normalised where it matters, down to the inverter, with optimiser counts on SolarEdge — and every fault opens a case with a clock on it.

Why latency matters

A dark inverter doesn't always trip an alarm. It just stops earning.

Lose one inverter on a multi-inverter commercial site — or a few strings behind one — and the site keeps generating, and the daily total dips by a few percent: small enough to blame on cloud. Left alone, that's weeks of lost generation before anyone reading a status dashboard notices.

Fault detection is only worth what it saves, and what it saves is a function of how fast you find it. SolarFleet checks every site on each polling cycle — Solis Cloud every 5 minutes — so a tripped site or a dark inverter surfaces the same day, and sustained underperformance once it has held for a couple of days. Not at the next quarterly site visit. SolarEdge is polled regularly through your own SolarEdge App API key, but every call counts against your SolarEdge API plan's per-minute and monthly limits, which are shared across every site on the key — so a small plan can't refresh a large fleet as often as a bigger one. Alerts on SolarEdge sites can only be as current as the readings behind them.

Read: the economics of fault-detection latency

PEN-Y-BONT WORKS · INVERTERS INVERTER OFFLINE
×
11 inverters producing 1 dark

INV-08 has stopped producing while its eleven peers run. The site total barely moves — but the inverter view makes it obvious at a glance, and a case is already open. Illustrative view; site name is fictional.

The detection engine

Six derived detections, run every polling cycle.

These run on top of whatever native alarms your inverter brand reports — they don't replace them, they fill the gaps brands leave. Each reads only from the telemetry, equipment and weather data we already hold. Four work the same way on SolarEdge and Solis; inverter-offline and optimiser-drop need per-inverter data that today only our SolarEdge integration provides (Solis inverter faults come through Solis's own alarms).

comms-stale Warning

Comms stale

No telemetry from a site for more than 4 hours in daylight, or 12 hours at any time. Catches a dead logger or a broken cloud link before it hides a real fault.

zero-production Critical

Zero production

It's daylight, the site has produced nothing all day and is at zero now. The classic tripped-site signature — and the one that quietly costs the most.

low-power Warning

Low power

The site was generating earlier today but has dropped to zero during peak hours. Catches a mid-day trip the same day, before the daily total hides it.

inverter-offline Critical

Inverter offline

A specific inverter has dropped off a multi-inverter site while its siblings keep reporting. Pinpointed to the unit, not the postcode.

optimiser-drop Warning

Optimiser drop

On SolarEdge, the number of optimisers connected to an inverter falls below the number it should have. Counts refresh from SolarEdge's inventory daily — the per-optimiser output data itself needs a higher SolarEdge API tier.

partial-offline Warning

Partial offline

Output has sat well below weather-normalised expected across peak hours for two days or more, and today confirms it. Soiling, shading, a dark string, a derated inverter — the slow leaks a status-only view never shows you.

Optimiser-level granularity depends on what your inverter brand exposes over its API. We gate each detection on real capability rather than promising data we can't get — read more on how the data flows in portfolio & site monitoring.

Weather normalisation

"Low" only means low once you've accounted for the weather.

A flat threshold like "alert if output drops 20%" buries you in false alarms on cloudy mornings and stays silent on bright days when a real fault is masked by good irradiance. So we don't use one.

SolarFleet pulls hourly irradiance, temperature and cloud cover from Open-Meteo for each site's exact coordinates, then compares actual generation against what the weather says you should have made. The low-power detection fires on the gap, not the raw number — so a dull day doesn't cry wolf and a clipping day doesn't hide a problem.

How Open-Meteo stops false alarms on clipping days

From detection to fixed

A detection isn't an email. It's a case with a clock on it.

A fault that lands in an inbox gets triaged, forwarded, and forgotten. When a SolarFleet detection fires it opens a case automatically, attaches the evidence, and starts an SLA timer — so the slow leak becomes a tracked, assignable job instead of a notification someone might read.

01

Detect

A detection fires on a polling cycle, scoped to the site or to the specific inverter.

02

Open a case

A case opens automatically with the telemetry, expected-vs-actual gap and timestamp attached.

03

Start the SLA

An SLA clock starts on the case so response and resolution times are measured, not guessed.

04

Assign & close

Assign an engineer, log the fix on mobile, and the resolution lands in the client's monthly report.

This is the same engine running today on InspireGreen's own ~10-site fleet — the Cardiff solar installer that builds SolarFleet. We dogfood it before we ship it. Why string-level detection matters more than you think →

See your faults before your client does.

Connect a SolarEdge or Solis Cloud account, import one real site, and watch the detection engine run against live data in under an hour. Two sites are free forever — no card, no lock-in.