An Inverter-Agnostic Smart Solar Monitoring and Power Prediction System with Edge-AI and Per-Tenant Adaptive Forecasting

1. Introduction

Distributed rooftop photovoltaic (PV) deployment has expanded rapidly across South Asia; however, a substantial fraction of installed inverters in this segment are low-cost units that do not expose a communication interface, whether serial, Wi-Fi, or proprietary cloud protocol [1]. Consequently, end users and installers of these systems lack a mechanism for detecting panel-level underperformance, wiring faults, or gradual degradation until a measurable decline in delivered energy is observed. Prior IoT-based energy-monitoring work has established that ESP32-class microcontrollers combined with PZEM sensor modules and MQTT transport can provide low-cost, near-real-time visibility into electrical parameters [5,6,10,11]; however, this body of work is concentrated on AC-side household load metering and generally assumes either a communication-capable inverter or a metering point downstream of the inverter only, leaving the DC-side panel-to-inverter segment uninstrumented.

This paper addresses that instrumentation gap directly. We instrument both the DC segment between the PV array and the inverter and the AC segment between the inverter and the household load by tapping the physical conductors rather than the inverter’s data port, which makes the sensing subsystem independent of inverter brand, firmware, or communication capability. We further couple this sensing layer to a forecasting subsystem that is pretrained on a general dataset but is designed for periodic per-tenant fine-tuning, together with an edge-inference deployment intended to preserve short-horizon prediction availability during connectivity loss. Section II positions this work relative to prior IoT and LSTM-forecasting literature. Section III specifies the system architecture. Section IV specifies the security model. Section V formalizes the forecasting problem. Section VI reports hardware-level implementation results obtained through empirical testing. Section VII specifies the evaluation methodology and separates measured from planned results. Sections VIII and IX discuss limitations and conclude.

2. Related Work

LSTM-based sequence models are a widely used baseline for PV power and irradiance forecasting because they capture temporal dependence in weather-driven generation series more effectively than purely statistical autoregressive models [1,2]. Zhou et al. augmented an LSTM forecaster with an attention mechanism to improve short-horizon accuracy [3], and comparative studies report accuracy gains from architectural refinements relative to a baseline single-layer LSTM [8,9], which we use in Section VII as an external reference point for the magnitude of improvement that architectural or personalization refinements can plausibly deliver. Han et al. proposed a broader deep-learning framework for energy management embedded directly within an IoT pipeline rather than as an offline analytics step [4], which is methodologically closer to the edge-deployment approach adopted here.

On the hardware-integration side, ESP32-based smart-meter architectures using PZEM modules and MQTT transport are documented for AC-side household or three-phase monitoring, in some cases with cloud-platform integration [5] and in some cases with added fault-detection or billing logic [6]. Mobile-dashboard variants using platforms such as Blynk have also been reported for household load monitoring and remote actuation [10,11]. Table 1 compares these systems against the architecture proposed in this paper along five dimensions: AC-side sensing, DC-side sensing, independence from inverter communication capability, per-tenant forecast personalization, and on-site edge inference. None of the reviewed systems instrument the DC segment between the array and the inverter, and none combine per-tenant model personalization with edge inference; this combination constitutes the primary architectural contribution of the present work.

3. System Architecture

3.1. Hardware Layer

The acquisition layer consists of an ESP32 microcontroller interfaced to a PZEM-004T module, which measures AC-side voltage, current, real power, and power factor between the inverter output and the household load, and a PZEM-017 module, which measures DC-side voltage and current between the PV array and the inverter input. The PZEM-017 communicates over an RS-485 physical layer through a MAX485 transceiver using the Modbus RTU protocol. Both modules are connected directly to the physical conductors rather than to a data port exposed by the inverter, which decouples the acquisition layer from inverter brand, firmware version, or communication capability.

3.2. Communication Layer

Telemetry is published from the ESP32 to a backend broker using MQTT, selected for its low per-message overhead and its demonstrated suitability for constrained, intermittently connected metering nodes [5]–[7]. This minimizes the microcontroller’s networking footprint under the variable connectivity conditions typical of the target installation sites.

3.3. Backend and Data Alignment

The backend aligns incoming telemetry with weather-API data by timestamp and substitutes a hyperlocal physical weather sensor reading for the API estimate whenever such a sensor is present at the installation site for the corresponding time window. This is intended to reduce the forecasting error contributed by weather-API estimates that do not capture site-specific microclimate effects such as localized cloud cover or shading.

3.4. Edge Inference Layer

A Raspberry Pi deployed at each installation performs on-device inference using the tenant’s current model parameters, allowing short-horizon predictions to continue during degraded connectivity. Updated parameters produced by the fine-tuning procedure in Section V are transmitted to the Raspberry Pi as a JSON payload and loaded without a full model redeployment.

4. Security Architecture

Authentication is enforced across two independent domains. At the hardware-to-backend boundary, each ESP32 node authenticates using a JSON Web Token issued during provisioning, which prevents unauthorized devices from injecting telemetry into a tenant’s data stream. At the backend-to-dashboard boundary, the web dashboard uses JWT-based session authentication to scope a tenant’s access to their own historical data, live readings, and forecast output. The two domains are deliberately decoupled so that compromise of a single hardware node does not, by itself, grant access to the dashboard authentication layer, and conversely.

5. Problem Formulation and Forecasting Model

Let x_t denote the feature vector observed at discrete time step t, comprising DC and AC power readings and aligned weather variables as described in Section III-C, and let y_(t+h) denote the target PV power output at forecast horizon h beyond t. The task is to learn a function f_θ such that ŷ_(t+h) = f_θ(x_(t−k):t), where k is the input window length and θ denotes the trainable parameters of an LSTM network, updated at each step through the standard gating equations:

f_t = σ(W_f·[h_t−1, x_t] + b_f)

(1)

i_t = σ(W_i·[h_t−1, x_t] + b_i)

(2)

C̃_t = tanh(W_C·[h_t−1, x_t] + b_C)

(3)

C_t = f_t ⊙ C_t−1 + i_t ⊙ C̃_t

(4)

h_t = σ(W_o·[h_t−1, x_t] + b_o) ⊙ tanh(C_t)

(5)

where σ is the logistic sigmoid, ⊙ denotes elementwise multiplication, and W(·), b(·) are the weight matrices and bias vectors associated with the forget, input, candidate, and output gates. A single parameter set θ_pretrain is first fit on a pooled multi-site dataset. For each tenant j, a personalized parameter set θ_j is obtained by fine-tuning θ_pretrain on that tenant’s own accumulated history D_j = {(x_i, y_i)}, i = 1…N_j, on a fixed three-month cycle, subject to a proximity penalty that discourages large departures from the pretrained parameters when tenant-specific data are limited:

θ_j = argmin_θ (1/N_j) Σᵢ (y_i − ŷ_i(θ))² + λ‖θ − θ_pretrain‖²

(6)

where λ ≥ 0 controls the strength of regularization toward the pretrained parameters. The resulting θ_j is serialized as JSON and deployed to the tenant’s Raspberry Pi as described in Section III-D.

6. Implementation and Hardware-Level Results

The following results were obtained empirically during hardware bring-up and are reported as measured outcomes rather than projections.

6.1. Sequential Blocking Sensor Reads

An initial implementation issued sensor reads sequentially within a single blocking call path, such that a delayed or non-responsive sensor stalled acquisition from all sensors on the bus. Wrapping each sensor read in an independent function with its own retry-and-timeout logic eliminated this cross-sensor stalling, confirmed by repeated fault-injection trials in which one sensor’s response was deliberately delayed without affecting the read cycle of the others.

6.2. MAX485 Direction-Switching Timing

The MAX485 transceiver requires explicit transmit/receive direction switching around each Modbus transaction. Incorrect direction-pin timing relative to the UART write produced intermittent read failures during initial integration; correcting the transmit-enable sequencing removed the intermittent failures across repeated test cycles.

6.3. Modbus Illegal Data Address Exception

Initial Modbus RTU queries to the PZEM-017 requested a register count exceeding what the device accepts in a single transaction, producing an Illegal Data Address exception response defined in the Modbus specification. Reducing the requested register count per transaction eliminated the exception.

6.4. PZEM-017 Register-Width Discrepancy

The PZEM-017 datasheet specifies several measured quantities as spanning 32-bit register pairs; however, empirical testing showed coherent, physically plausible values only when the same registers were addressed as independent 16-bit values. This was verified by cross-checking returned voltage V and current I against the corresponding reported power P using the identity

P ≈ V × I

(7)

across repeated trials under multiple load conditions; agreement with this identity held consistently only under the 16-bit interpretation, which we report here as a practical correction to the vendor documentation.

7. Evaluation

7.1. Measured Results

Table 2 summarizes the hardware-level results obtained through empirical testing, corresponding to the four issues described in Section VI. Each result was verified through repeated trials under controlled fault-injection or load-variation conditions rather than a single observation.

7.2. Planned Evaluation of the Forecasting Subsystem

The per-tenant fine-tuning procedure in Eq. (6) and the associated edge-inference deployment had not, at the time of writing, been exercised over a deployment period sufficient to compute tenant-personalized forecasting accuracy. We specify here the evaluation methodology to be applied once such data are available, so that the reported metrics are comparable to prior work. Forecasting accuracy will be assessed using root-mean-square error, mean absolute error, and mean absolute percentage error, defined as

RMSE = √[(1/N) Σᵢ (yᵢ − ŷᵢ)²]

(8)

MAE = (1/N) Σᵢ |yᵢ − ŷᵢ|

(9)

MAPE = (100/N) Σᵢ |(yᵢ − ŷᵢ)/yᵢ|

(10)

computed separately for the pretrained model θ_pretrain and the personalized model θ_j on held-out data from tenant j, so that the difference between the two conditions isolates the contribution of per-tenant fine-tuning from the contribution of the base architecture. Published results for comparable LSTM-based PV forecasters report RMSE and MAE improvements from architectural and feature refinements on the order of the improvements summarized in [3,8,9]; these figures are cited here only as an external reference point for plausible effect sizes and are not results of the present system.

8. Discussion and Limitations

The principal limitation of the present work is the asymmetry between the hardware layer, which has been validated empirically, and the forecasting layer, whose per-tenant personalization gain (Eq. 6) requires a full three-month cycle of field data before RMSE/MAE/MAPE figures (Eqs. 8–10) can be computed rather than projected. A second limitation concerns installation safety and consistency: direct conductor tapping, while enabling inverter independence, requires more careful installer training than a communication-port integration would, and inter-installer variance in tap quality has not been characterized. A third limitation is that the proximity-regularized fine-tuning objective in Eq. (6) introduces a hyperparameter λ whose appropriate value likely depends on the volume of tenant-specific data accumulated by the three-month mark and has not yet been tuned empirically. Future work will (i) deploy the system across multiple tenant sites for a complete fine-tuning cycle to obtain measured values for Eqs. (8)–(10), (ii) characterize sensitivity to λ, and (iii) conduct a formal security assessment of the JWT provisioning flow described in Section IV.

9. Conclusion

This paper formulated and partially validated an inverter-agnostic PV monitoring and forecasting architecture combining direct AC/DC conductor instrumentation, MQTT telemetry, weather-aligned backend processing, a formally specified per-tenant LSTM fine-tuning procedure, Raspberry Pi edge inference, and a two-domain JWT authentication model. Register-level and communication-layer results were obtained empirically and are reported in Section VI and Table 2. The forecasting subsystem’s personalization gain is formalized in Eq. (6) and its evaluation methodology in Eqs. (8)–(10), but its quantitative performance remains to be measured through extended multi-tenant field deployment. Relative to prior IoT PV/energy-monitoring systems summarized in Table 1, the combination of DC-side inverter-independent sensing with per-tenant model personalization constitutes the principal contribution of this work.