In development · pilot conversations open

See underperformance before it becomes lost generation.

HelioWatch is a solar performance monitoring platform for teams responsible for more than one site. It is being built to bring compatible inverter and meter data into one workspace, compare output against expectations, and help you decide which issues deserve a truck roll first.

Discuss a pilot Explore the platform

For commercial solar operators, installers, O&M providers, and businesses managing multiple sites.

Product preview

A fleet view built around one question: what needs attention?

This is an illustrative concept of the HelioWatch workspace. Every site, value, and alert below is sample data created for this preview — it does not represent a real customer, installation, or measurement.

Illustrative product preview · Sample data only · Not live

Fleet overview

Sample portfolio · 6 sites

Period: last 14 days (sample) Sample data

Site status

Sample

Select a site to update the charts.

Site Status Perf. index

Generation trend · —

Sample

Expected vs actual · 14-day total

Sample

    Maintenance alert queue

    Sample
      Illustrative dashboard concept for HelioWatch. All site names, capacities, generation figures, and alerts are fictional sample data. The final product may differ.

      The problem

      Multi-site solar is easy to install and hard to watch.

      As portfolios grow, performance data spreads across vendor portals and spreadsheets. Small losses go unnoticed, and maintenance teams spend time deciding where to go rather than fixing things.

      Fragmented monitoring

      Different inverter brands and meters often come with their own portals, logins, and data formats. Comparing sites side by side usually means exporting and stitching data by hand.

      Delayed fault discovery

      A string fault, soiling, or a tripped breaker can lower output without triggering a hard alarm. When nobody is comparing actual output to what the weather should have produced, the gap can persist for weeks.

      Inefficient maintenance prioritisation

      Without a consistent view of which issues cost the most generation, crews are dispatched by whichever alert arrived last or whichever customer called — not by impact.

      Planned capabilities

      What HelioWatch is being built to do

      These capabilities are in design and development. Scope and timing will be shaped with pilot participants.

      Multi-site visibility

      One workspace for every connected site, with a consistent status model so you can scan a portfolio instead of logging into each vendor portal.

      Generation trend analysis

      Daily, weekly, and seasonal generation trends per site and per inverter, so gradual degradation is visible alongside sudden drops.

      Weather-informed comparisons

      Compare actual output with an expected value adjusted for irradiance and temperature, so a cloudy week is not mistaken for a fault.

      Anomaly detection

      Models that flag output patterns deviating from a site's established baseline — designed to surface issues that fixed thresholds miss.

      Maintenance prioritisation

      An alert queue ranked by estimated generation impact and persistence, helping teams decide which sites deserve attention first.

      Operational reports

      Scheduled summaries of performance, open issues, and resolved actions for internal teams, asset owners, or site customers.

      How it works

      From raw telemetry to a ranked maintenance list

      1. Connect compatible data sources

        Link supported inverter APIs, meters, or gateways for each site. Compatibility is confirmed per site before onboarding.

      2. Establish performance baselines

        Use historical output, system characteristics, and weather data to model what each site should be producing.

      3. Identify deviations

        Continuously compare actual with expected output and flag persistent or unusual gaps, rather than one-off dips.

      4. Review maintenance actions

        Work through a prioritised queue, record what was found on site, and track whether performance recovers.

      Architecture

      Designed for AWS from day one

      HelioWatch is architected entirely on AWS managed and serverless services, so a small team can run a secure, scalable monitoring platform without operating servers. The design below is our target architecture; pilot environments will be provisioned from it as partners onboard.

      • Serverless-first
      • Infrastructure as code (AWS CDK)
      • Encrypted in transit and at rest
      • Per-customer data isolation
      • Pay-per-use cost model

      1. 1 Connect

        • Site gateways & data loggersMQTT over TLS
        • Inverter vendor APIsAuthorised API access
        • Weather & irradiance dataFor expected-output models

      2. 2 Ingest

        • AWS IoT CorePer-device X.509 certificates, rules engine
        • AWS LambdaScheduled vendor-API collectors & normalisation
        • Amazon EventBridge SchedulerPolling schedules per site
        • AWS Secrets ManagerVendor API credentials

      3. 3 Store

        • Amazon S3Raw & curated data lake, lifecycle to S3 Glacier
        • Amazon Data FirehoseBatched delivery to S3 as Parquet
        • Amazon DynamoDBLive site status & alert queue
        • AWS Glue Data CatalogSchema for analytics

      4. 4 Analyse

        • Amazon SageMaker AIPer-site baselines & anomaly detection models
        • Amazon AthenaTrend queries & operational reports

      5. 5 Act

        • Amazon SNSEmail, SMS & webhook alerts
        • Amazon API GatewayWorkspace API, backed by Lambda
        • Amazon CloudFrontWeb workspace delivery

      Security & operations foundation

      • AWS IAM least-privilege roles
      • AWS KMS encryption keys
      • Amazon Cognito user sign-in & MFA
      • AWS WAF edge protection
      • AWS CloudTrail audit logging
      • Amazon CloudWatch metrics & alarms
      • AWS Organizations separate dev / prod accounts
      HelioWatch target architecture. Telemetry from compatible gateways reaches AWS IoT Core, and vendor APIs are polled by AWS Lambda on Amazon EventBridge schedules. Data is stored in an Amazon S3 data lake, with live state in Amazon DynamoDB. Anomaly detection models run in Amazon SageMaker AI. Alerts are delivered through Amazon SNS and the workspace is served through Amazon API Gateway and Amazon CloudFront. IAM, KMS, Cognito, WAF, CloudTrail, CloudWatch and AWS Organizations provide security and operations.

      Core services

      Ingestion

      AWS IoT Core

      • Each gateway authenticates with its own X.509 certificate; no shared credentials.
      • The rules engine validates and routes messages to storage and processing.
      • Scales with the number of connected sites without capacity planning.

      Historical data

      Amazon S3

      • Raw readings are kept unchanged so analysis can always be re-run.
      • Curated, partitioned Parquet data supports fast queries with Athena.
      • Lifecycle rules move older data to lower-cost storage classes.

      Anomaly detection

      Amazon SageMaker AI

      • Models learn each site's expected output from history and weather.
      • Scheduled batch scoring flags persistent deviations, without always-on endpoints.
      • Model versions are tracked so every alert is traceable to the model that raised it.

      Notifications

      Amazon SNS

      • Prioritised alerts reach operators by email, SMS or webhook.
      • Per-customer topics keep each organisation's alerts separate.
      • Webhooks let alerts flow into existing ticketing and work-order tools.

      Aligned with the AWS Well-Architected Framework

      • SecurityDevice certificates, least-privilege IAM, KMS encryption, Cognito MFA, and CloudTrail auditing.
      • ReliabilityMulti-AZ managed services, retries with dead-letter queues, and replayable raw data in S3.
      • Performance efficiencyEvent-driven processing that scales automatically with site count and reporting frequency.
      • Cost optimisationPay-per-use serverless services, Arm-based Lambda, batch ML scoring, and S3 lifecycle tiers.
      • Operational excellenceEverything defined in AWS CDK, deployed through CI/CD, and monitored with CloudWatch alarms.
      • SustainabilityNo idle servers; compute runs only when data arrives or a scheduled job runs.

      Rollout plan

      1. Phase 1 · Pilot foundation

        Secure multi-account setup, IoT Core and vendor-API ingestion, S3 data lake, live site status, and SNS alerts with rule-based thresholds.

      2. Phase 2 · Intelligence

        Weather-adjusted baselines and SageMaker AI anomaly detection trained on pilot data, plus Athena-powered operational reports.

      3. Phase 3 · Scale

        Self-service onboarding, maintenance prioritisation scoring, ticketing integrations, and hardened per-customer isolation for production use.

      Status: target architecture. Pilot infrastructure will be provisioned as partners onboard; service choices may be refined based on pilot findings.

      Integration requirements

      HelioWatch works with the data your equipment can share

      HelioWatch does not support every device. Access to a site's data depends on the equipment installed and how it can be reached. During a pilot we review each site to confirm what is possible before committing.

      No universal device support. If a site's inverter, meter, or gateway does not expose data through a compatible interface, HelioWatch may not be able to monitor it without additional hardware.

      Inverter APIs

      Manufacturer or monitoring-portal APIs that allow authorised access to production data. Availability, data resolution, and rate limits vary by vendor and account type.

      Revenue or production meters

      Meters that can report interval data through a readable protocol or an existing data logger.

      Gateways and data loggers

      On-site gateways that can forward telemetry securely to a cloud endpoint. Some sites may need a compatible gateway installed.

      Site metadata

      System size, orientation, tilt, and location are needed to build a meaningful expected-output baseline.

      Permissions

      Written authorisation from the site owner or operator to access its data, plus any credentials or API keys the vendor requires.

      About

      An early-stage product, built with operators

      HelioWatch is a solar performance monitoring platform currently in development. Our goal is simple: help teams responsible for several solar installations spend less time hunting for problems and more time fixing the ones that matter.

      We would rather build a narrow tool that works well for real maintenance workflows than a broad one that looks good in a demo. That is why we are looking for a small number of pilot partners to shape what we build first.

      Team

      • Osas Osagiede

        Founder & CEO

      • Ridwan Sanusi

        Co-Founder & COO

      FAQ

      Common questions

      Is HelioWatch available today?

      Not yet. HelioWatch is in development. We are speaking with operators interested in a pilot to help shape the first release.

      Which inverters and meters do you support?

      We don't claim universal support. Compatibility depends on whether your equipment exposes data through an accessible API, meter interface, or gateway. We assess this site by site before any pilot begins.

      Is the dashboard on this page real?

      No. It is an illustrative preview using fictional sample data to show the intended workflow. It does not reflect any real site or measurement.

      How much generation will HelioWatch recover?

      We can't say, and we won't guess. Outcomes depend on each portfolio's equipment, condition, and existing processes. Measuring real impact is one of the goals of a pilot.

      Does HelioWatch replace my existing vendor portals?

      It is designed to sit alongside them, bringing compatible data into one view. Vendor portals may still be needed for device configuration and warranty processes.

      Where will data be stored?

      The planned architecture uses AWS services, with historical data stored in Amazon S3. Specific regions, retention, and access controls will be agreed with pilot participants.

      What does a pilot involve?

      Typically a short discovery call, a compatibility review of a few representative sites, and an agreed period of monitoring and feedback. Terms are discussed individually.

      Pilot interest

      Discuss a pilot

      Tell us a little about your sites and the monitoring challenges you face. We'll follow up to talk through fit and equipment compatibility. Registering interest does not commit you to anything.

      • Commercial solar operators
      • Solar installers and EPCs
      • Operations & maintenance providers
      • Businesses with multiple solar sites

      Fields marked are required.

      Helps us check compatibility early.