Solar Monitoring Software and Custom Dashboard Development

What does custom solar monitoring software do?

It collects production, consumption, battery and device-status data from inverters, meters and data loggers, stores it in one database and shows it in dashboards and alerts built for your team. A homeowner app answers "is my system working". An operations view answers "which of 400 systems lost output yesterday and why".

Vendor portals are good at the first question for their own hardware and weak at the second across brands.

How do you detect underperformance rather than just outages?

An inverter that reports zero is easy to catch. The costly losses are partial: a failed optimizer, a tripped string, shading from new construction, soiling or clipping. Catching them needs an expected-output model, even a simple one using site capacity, tilt, azimuth and local irradiance data, and a comparison of actual to expected per site per day.

Peer comparison also works well: sites on the same street with similar systems should produce similar kWh per kW. A system 15 percent below its neighbours across a clear week deserves a call.

• Expected versus actual energy with a configurable threshold
• No-communication detection separate from low production
• Peer and string-level comparison where data exists
• Alert routing by region, severity and contract tier

What data limits should you plan for?

Vendor APIs are metered. SolarEdge's monitoring API is documented with a limit of 300 requests per day, so polling has to be designed around that: pull energy summaries per site per day instead of frequent small calls. Enphase API v4 uses OAuth 2.0 with access tokens valid for one day and refresh tokens for one month, so token refresh and re-authorization flows must be built in. Details are on the Enphase and SolarEdge integration page.

Data granularity varies too, from 5 minute power readings to daily energy totals. A dashboard should show which resolution each chart is using.

Where do monitoring projects go wrong?

Common issues are timestamps stored in local time without a zone, daylight saving gaps, duplicate readings after retries, and customer consent for data access that was never recorded. Vascoh stores UTC, keeps raw payloads for reprocessing, and tracks authorization per customer so access can be revoked cleanly.

A second failure is dashboards no one opens. Alerts that create a ticket in the tool your service team already uses will outperform a beautiful chart page.

Residential, C&I, utility-scale and PAYGo use different shapes

Residential installers want many small systems and a customer-facing app. C&I operators need meter-level energy for billing and demand analysis. Utility-scale sites need SCADA integration and string data. PAYGo providers need device state tied to payment state, so a unit can lock or unlock when a customer pays. Each shape drives a different data model, which is why a generic dashboard builder usually falls short.

Start small when scoping. A first release that ingests one vendor, computes expected versus actual per site and sends a daily exception list already replaces a lot of portal checking. Add the second vendor and the ticket integration once the thresholds are trusted. Keep the raw data, because the first set of thresholds is always wrong and the ability to replay history against new rules is what lets you improve them. A public or customer-facing view can then be added on top of the same database, with branding and permissions, without a separate data pipeline. Plan the alert budget too: a team that receives two hundred alerts a morning will ignore them, so group alerts by site and cause, and measure how many produce a real fix.