AI4Solar

AI4Solar is a monitoring and predictive-maintenance platform for solar plants: a web portal, a mobile app for field crews and a machine-learning service, all behind a login. This page draws on the public website, on the platform's code and on a walkthrough video of under three minutes. The protected portal was not opened to write it.

The video is a narrated explainer rather than a live demo. Figures quoted in it, such as accuracy rates and fewer false alarms, are not repeated here because they have not been checked independently.

Three altitudes of data

Ground, air and space each feed the same platform.

• Ground. Inverter telemetry arrives from Fronius, SMA and Huawei FusionSolar equipment, through the vendors' own interfaces. Fronius data is pushed or polled, SMA is read over Modbus, Speedwire or its portal API, and Huawei through FusionSolar.
• Air. Drone thermal imagery goes through a YOLOv8 model that detects defects at module level.
• Space. Satellite irradiance comes from CAMS, NASA POWER, Open-Meteo and ERA5.

Five models, one purpose

The platform carries five machine-learning models: an anomaly detector, a fault classifier, a failure predictor, a generation forecaster and the drone defect detector. The classifier distinguishes sixteen fault classes, from partial shading and micro-cracks to ground faults and arc faults.

Some of the engineering sits in the details. A single ten-dimension feature vector maps Huawei, Fronius and hourly data into one Isolation Forest model, with a heuristic fallback when no trained model exists. Models are versioned, and the fault classifier carries drift monitoring. In the API layer, statistical baselines (z-score, IQR and MAD) sit beside detectors for batteries, phase imbalance and grid frequency.

From finding to action

A detection that nobody sees is worth nothing, so findings become work.

• Alerts go out by email, SMS and push, with weather-aware suppression so that night-time and low-light readings do not raise false alarms.
• Faults create maintenance tasks automatically, and a de-duplication step keeps one fault from creating a pile of tasks.
• Alert settings can be set per installation, overriding the global default.

Portal and mobile

The web portal covers live monitoring, system health, DC and inverter-unit analysis, derating detection, string sizing, I-V curves, forecasting, predictive maintenance, portfolio analytics, PDF reports, an audit log and roles with permissions. The mobile app gives field crews role-based access and stays in two-way sync with the portal. The interface supports more than ten languages.

Billing and the public site

Subscription billing runs through Stripe, Paysera or bank transfer, with rate limiting on the payment webhooks and a migration that anonymises payment records for GDPR. The public marketing site is a separate React and Vite package with its own checks.

Keeping tenants apart

A platform that serves many plant owners has to be strict about whose data is whose. Inverter and plant identifiers are not unique across tenants, so the installation is the authoritative key for isolation. A test sweep walks the live routes looking for cross-tenant access, and it has been shown to fail when the guard is removed, which is what makes it worth trusting. Data pushed in by devices is guarded by per-device keys bound to one installation.

Checks on every change

Nine GitHub workflows run for the portal, the ML service and the marketing site. They include coverage sweeps, a schema-drift guard, a guard against mixed-language text in the translations and a regression smoke guard. The audit work behind them is written down as invariant matrices, one per area such as alerts, ingest and installation access, and each row names one rule the system must keep.

Fault classes the classifier distinguishes

16