Inspiration
For approximately seven years, I have been actively building, testing and experimenting with solar systems, electrical configurations and different combinations of inverters, batteries and control equipment.
Early in that process, I became frustrated with the limitations of many manufacturer-provided monitoring platforms. Important measurements or charts were often unavailable, historical access was restricted, and some systems recorded data only once every five minutes—far too slowly to reveal short-lived behaviour in a dynamic electrical system. In one case, I discovered during a historical review that records older than approximately eighteen months were no longer available.
At the same time, small solar installations are becoming increasingly diverse. Equipment prices, availability and installer choices often lead owners, DIY builders and small companies to combine components from different manufacturers. Although standards such as Modbus exist, vendors do not provide one consistently implemented, interoperable and fully documented interface across all equipment.
The result is a growing number of mixed-vendor systems that cannot be monitored properly as one system. Each application may show only its own device, while relationships between inverter behaviour, battery behaviour, temperatures, power flow and communication quality remain hidden.
Many developing problems produce early symptoms before a complete failure. Those symptoms may be too brief, too distributed across devices, or simply absent from conventional dashboards. For installations located in or near homes, late discovery can mean more than loss of power—it can also increase the consequences of an electrical or thermal problem that was not investigated in time.
That is why I started building HelioVerity Pilot.
The project began as my personal side project before I knew about OpenAI Build Week. I am a solo builder, and I learned about the competition less than 48 hours before the submission deadline. During Build Week, I used Codex and GPT-5.6 to meaningfully extend the existing prototype into a tested, documented and judge-ready system.
What it does
HelioVerity Pilot is an evidence-driven monitoring and early-prevention prototype for small and medium mixed-vendor solar systems.
It supports two complementary operating modes:
Permanent monitoring and early prevention — continuously collecting synchronized operational evidence, checking data quality, comparing related measurements, and identifying patterns that deserve attention.
Pre-service diagnostic recording — producing a bounded, high-detail technical record before a service visit, so a technician can inspect the system remotely, arrive better prepared, and determine whether an on-site visit is actually necessary.
This second mode addresses a practical service problem. A technician normally sees only the current state of the system after arriving on site. HelioVerity can provide a detailed record of how the installation behaved before the visit, including intermittent symptoms that may no longer be present.
The collected data supports four analysis paths:
- direct export and independent inspection;
- deterministic algorithmic analysis;
- traceable AI-assisted analysis;
- independent analysis by a service engineer.
With reliable evidence, AI-assisted triage may eventually help owners understand minor configuration or operating issues remotely, recommend safe checks, and distinguish them from conditions that genuinely require a qualified technician. The current prototype does not autonomously control equipment or replace professional electrical judgement.
The current pilot is configured for a Growatt SPF 6000 ES inverter and two JK BMS battery origins. Its architecture is designed so that additional supported equipment can be added through replaceable, device-specific adapters for understood protocols.
How it works
The system uses three architectural layers:
- Device layer: safe, device-specific communication and decoding. JK acquisition is passive RX-only. Growatt communication is restricted to Modbus FC04 reads, slave 1, and a fixed register allowlist.
- Semantic layer: vendor-specific values are converted into normalized battery and inverter observations with units, quality and provenance.
- Core and analytics layer: observations are stored as append-only JSONL records with atomic latest-state and health files, then used for evidence packaging, deterministic analysis, reporting and AI-assisted review.
The strongest capability of the current prototype is not autonomous AI diagnosis. It is the creation of reliable, structured and traceable evidence without which trustworthy AI diagnosis is impossible.
Real hardware proof
The pilot was deployed on a Raspberry Pi 4 connected to a real operating solar installation through two independent RS485 interfaces.
A controlled 15-minute session produced:
- 282 valid JK observations;
- 38 complete Growatt polling records;
- two distinct JK SID/address origins;
- synchronized battery and inverter voltage, current, power, SOC, cell and temperature evidence;
- manifests and SHA-256 checksums;
- no Growatt CRC failures or timeouts during the recorded session.
The analysis identified persistent peer voltage and temperature ordering while correctly avoiding unsupported conclusions about overheating, root cause, state of health or remaining life.
A separate deterministic judge demo uses committed synthetic data, runs offline with one command, produces findings, a Markdown report, a run manifest and checksums, and verifies its own output.
How I used Codex and GPT-5.6
Codex and GPT-5.6 became development partners throughout the Build Week extension.
They helped me:
- audit the existing prototype and identify submission blockers;
- design strict read-only safety boundaries;
- implement and test the Growatt acquisition path;
- preserve the passive JK acquisition contract;
- separate device decoding from vendor-neutral semantics;
- identify installer and systemd permission defects before final deployment;
- create deterministic tests and reproducible evidence packages;
- analyse real hardware evidence while separating observed facts, inference and unknowns;
- build the preventive comparative analytics demo;
- prepare judge-facing documentation, claims/evidence mapping and the one-command test;
- review privacy, provenance and publication boundaries.
I made the product, electrical-safety, scope and deployment decisions. Codex accelerated implementation, challenged assumptions and repeatedly tested whether the available evidence actually supported each claim.
Challenges
The most difficult part was not reading individual values. It was preserving meaning and safety across heterogeneous devices.
Battery and inverter measurements can differ because of timing, calibration, measurement location and aggregation scope. Two battery origins can also behave differently without proving that either one is faulty. The system therefore records provenance, quality and uncertainty instead of forcing premature conclusions.
Deployment exposed additional real-world problems involving service permissions, runtime directories and systemd unit installation. These were reproduced, fixed and covered by tests before the final controlled deployment.
What I learned
Reliable preventive analytics begins with evidence quality, not with a dramatic diagnosis.
A useful system must know what it observed, where it came from, whether it is fresh, what can be compared, and what remains unknown. I think AI becomes more useful when it receives normalized history and explicit uncertainty rather than isolated dashboard values.
What is next
The next major step is to develop the current preventive analytics into a topology-aware comparative engine.
Instead of checking isolated thresholds, the algorithm will compare every useful measurement with:
- its own recent and long-term history;
- equivalent measurements from peer devices;
- electrically related components;
- similar operating and loading conditions;
- previous weeks, monthly baselines and annual baselines when sufficient history exists;
- expected energy, voltage, current, temperature and communication relationships.
Temperature analysis will remain a first-class part of this model, including sensor consistency, peer offsets, thermal trends, rate of change and correlations with load and ambient conditions.
The analytical model will improve with every validated device integration. New adapters will add not only more brands, but also new relationships, measurement semantics and tested diagnostic patterns. These improvements will be curated, versioned and tested rather than treated as uncontrolled self-learning.
Above this deterministic foundation, HelioVerity is intended to support an optional AI interpretation layer. A smaller local or open-source model could receive structured findings, evidence references, confidence levels and explicitly identified unknowns instead of attempting to interpret uncontrolled raw telemetry directly.
This approach may allow a comparatively lightweight AI model to produce useful explanations and service triage because the difficult electrical comparisons, data-quality checks and evidence reduction have already been performed by HelioVerity’s specialized algorithm. More capable remote models could remain an optional, consent-based path for complex investigations.
AI outputs will remain traceable to the underlying observations and will not be permitted to silently change device configuration or replace professional judgement.
Additional development stages include:
- broader device-adapter coverage;
- secure guided commissioning for supported equipment;
- multi-period and peer-system comparative analytics;
- improved electrical, thermal and communication-quality models;
- remote evidence retrieval and service-company workflows;
- a simple owner-facing interface with alerts and scheduled reports;
- optional local and remote AI-analysis providers;
- human-reviewed feedback for improving diagnostic rules and explanations;
- measured field validation of early-intervention and avoided-visit outcomes.
HelioVerity Pilot is not a certified diagnostic instrument and does not replace professional electrical judgement. It is a working engineering prototype demonstrating how reliable evidence, specialized comparative algorithms and traceable AI assistance can make owners and service professionals significantly better informed.
Log in or sign up for Devpost to join the conversation.