Monitoring solar plants with IoT: the architecture behind Force-V

The requirement

The operator had several solar plants reporting into separate inverter portals and spreadsheets. They needed one view of energy production across all sites, the ability to drill from a year down to a five-minute interval, automatic calculation of environmental benefits, and a clear picture of electricity exported to the grid and what it earned. Different users needed different views: owners across everything, site operators on their own plants.

Ingestion: MQTT with EMQX

Devices at each plant publish readings to an MQTT broker. We chose EMQX because it handles many concurrent device connections, supports TLS and client authentication, and lets us route topics per plant. Each plant and device has its own credentials, so a compromised device cannot publish as another, and topics follow a consistent scheme such as plants/<plant-id>/inverters/<device-id>/readings.

A subscriber service consumes the topics, validates payloads, de-duplicates late or repeated messages and writes them to the database. Keeping this service small and stateless makes it easy to scale and restart.

Storage: a time-series friendly schema

Readings land in MySQL in a narrow table keyed by device and timestamp. Raw five-minute data is kept, and aggregate tables are maintained for hourly, daily and monthly totals. Aggregation on write keeps dashboards fast without a separate analytics database, which matters when the budget favours simplicity. Partitioning by month keeps the raw table manageable, and backups run daily.

APIs and the dashboard

A set of REST APIs exposes production, impact and revenue metrics per plant and per portfolio, with the time grain as a parameter. The React front end lets users switch between five-minute, hourly, daily, monthly and yearly views and compare plants. Everything the dashboard shows is available through the same APIs, so the operator can integrate the data into other reporting.

Environmental impact and grid economics

Impact metrics are derived from production using published emission factors: CO2 avoided, equivalent coal not burned and tree equivalents. They appear beside production so sustainability reporting does not require a separate exercise. Grid export is tracked from meter data and multiplied by tariff schedules to show the revenue from surplus energy, which turned out to be the metric owners looked at most.

Access control

Users are assigned to plants. The API enforces this on every request, not only in the interface, so a user cannot query another plant by changing an identifier. Roles distinguish owners, operators and read-only stakeholders such as investors.

Lessons worth passing on

• Device authentication is not optional. An open broker is an invitation for junk data or worse. Issue credentials per device from day one and rotate them when hardware changes hands.
• Expect gaps and duplicates. Connectivity at remote plants drops. Design ingestion to accept late data and recompute aggregates rather than assuming a clean stream.
• Decide the finest grain early. Five minutes was right for solar. Changing it later means re-processing history.
• Show money, not just kilowatt-hours. Revenue and savings are what owners act on.
• Keep the database boring. A well-indexed relational schema with pre-aggregation served this workload comfortably and kept operations simple.

Beyond solar

The same pipeline now handles fuel monitoring telemetry and can serve generators, meters and industrial sensors. If you operate distributed assets that report data, Force-V or a system built on its architecture may fit. Our data analytics team can also review an existing setup.