Business Problem
Solar operators were dependent on bundled hardware-and-software ecosystems. A vendor-agnostic dashboard would reduce lock-in and centralize plant visibility.
What this was
A field-validated technical proof.
The solar monitoring engagement validated a vendor-agnostic telemetry path from field hardware into a cloud dashboard. The work clarified the integration, data, and deployment challenges behind industrial monitoring software.
Its value came from practical systems exposure: hardware, site conditions, sparse device documentation, cloud ingestion, payload parsing, database structure, dashboards, and the gap between documented exports and live device behavior.
How it began
Field first, dashboard later
Internship
Field exposure
The first work was practical: hardware installation, DG meters, IoT sensors, and connectivity testing in industrial environments.
Rohtak
Client-site installation
Salil visited K Automatic factory in Rohtak, installed DG meters, and tested whether the deployed hardware could communicate reliably from a real industrial site.
Sriharikota
Live plant study
A five-day site visit exposed the work to a full solar plant environment, including generation data, inverter behavior, reporting needs, and practical plant operations.
Discovery
The operating problem emerged
The existing monitoring product exposed a dependency problem: the software was tied to the hardware provider. The desired platform was a centralized, vendor-agnostic login and dashboard for monitoring live power generation.
Discovery
Wattmon payload discovery
The primary obstacle was the data logger. Documentation was limited and outdated. The expected CSV stream turned out not to be the real integration format; after weeks of log reading and parsing, the actual payload was found to be form-urlencoded request data.
POC
Cloud pipeline built
The working proof used AWS API Gateway, Lambda, a payload transformation layer, MongoDB cloud storage, and a live-data dashboard. It showed that plant data could be captured and visualized outside the vendor's locked stack.
The engagement connected field hardware, limited documentation, payload discovery, cloud functions, databases, and live industrial telemetry.
Technical Problem
The data logger integration was poorly documented. The assumed CSV export did not match the live request format, forcing manual discovery and payload parsing.
Architecture Lesson
The proof connected API Gateway, Lambda, transformation templates, MongoDB, and dashboard visualization into a working telemetry path.
What was proven
POC outcome
- Live solar telemetry could be routed outside the vendor-provided SaaS stack.
- Wattmon logger payloads could be interpreted despite weak public documentation.
- A cloud ingestion path could receive and store plant readings.
- MongoDB could store structured telemetry readings for dashboard use.
- A dashboard could visualize live plant data from the field context.
Engagement status
Scope boundary
- The work remained a proof of concept rather than a packaged SaaS rollout.
- The focus was feasibility, telemetry flow, and integration discovery.
- The dashboard validated live data visibility outside the vendor stack.
- The engagement informed later work in operations software and field data systems.
- The case is presented as technical validation with a clearly bounded deployment scope.
Outcome
Why this case matters
The Solar Monitoring POC shows Codeforge's exposure to hardware, factories, field installation, solar plant operations, cloud ingestion, and real-world telemetry data. It adds useful context to the firm's later work in field systems, operations dashboards, and ERP-adjacent infrastructure.