Pith. sign in

REVIEW 5 major objections 6 minor 6 references

On-Device Training of PV Power Forecasting Models in a Smart Meter for Grid Edge Intelligence

T0 review · 5 major / 6 minor · reviewed 2026-08-06 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read This paper claims that a mass-produced smart meter can run the complete training loop of machine learning models, not just inference, and demonstrates it by training XGBoost and LSTM photovoltaic forecasting models on the meter itself…

desk verdict A useful feasibility study that shows on-device PV model training works on one commercial smart meter, but the paper overreaches from one hardware profile to 'existing AMI'. read the letter →

arxiv 2507.07016 v1 pith:YARFUD2B submitted 2025-07-09 cs.LG eess.SP

Jian Huang , Yongli Zhu , Linna Xu , Zhe Zheng , Wenpeng Cui , Mingyang Sun This is my paper · ORCID
classification cs.LGeess.SP
keywords on-devicetrainingedgeintelligencesmartmeterphotovoltaicpowerforecastingXGBoostLSTMmixed-precisionembeddedmachinelearning
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper asks whether machine learning models can be trained, not just run, on the smart meters already installed at the grid edge, and answers yes on the hardware it tests. The authors train an XGBoost gradient-boosting model and an LSTM recurrent network for 24-hour-ahead photovoltaic power forecasting directly on a mass-produced smart meter with an ARM quad-core CPU, 984 MB of RAM, and 977 MB of disk. Forecast accuracy on the meter matches desktop-PC accuracy to within a few hundredths of a percentage point of MAPE, while training takes roughly 200 seconds for XGBoost and up to about 7000 seconds for the full-precision LSTM on the largest dataset. To make LSTM training tractable, they convert variables to float32 and recover a roughly 2x speedup with accuracy essentially unchanged. If the result generalizes, existing advanced metering infrastructure could host local model retraining, cutting communication and latency for microgrid control.

What carries the argument

The technical machinery is a do-it-yourself on-device training stack built for the meter's limited resources. For XGBoost, the authors cross-compile Python and its dependencies (zlib, openssl, libffi, bz2) to aarch64, then install the XGBoost Python interface; for LSTM, they implement the network and its back-propagation training loop from scratch in C++ using the header-only Eigen linear-algebra library, because PyTorch and TensorFlow cannot fit in the meter's storage. To make LSTM training practical, they devise 'mixed' (50% float32) and 'float' (100% float32) precision schemes that convert variables from double to float, exploiting the meter's float32 support. This stack is what carries the claim: it turns an ordinary meter into a device that can run both training and inference locally.

What would settle it

Run the same XGBoost and LSTM training procedure on a different mass-produced smart meter with, say, 256 MB RAM, a 32-bit OS, or no writable user partition, and check whether training completes within the model-update interval (e.g., one hour) and retains MAPE close to PC training; failure on any one of these would narrow or overturn the general feasibility claim. Alternatively, measure the training loss curve of the LSTM under float32 and show it diverges from double precision on a longer dataset, which would undermine the precision-reduction claim.

Watch

Extended reading notes

Core claim

The paper's central claim is that economically feasible grid-edge intelligence does not require dedicated edge-AI hardware: a commercially mass-produced smart meter can carry out the full training loop of representative forecasting models. The evidence is a case study in which XGBoost and LSTM models for PV power forecasting are trained on the meter itself, yielding MAPE values (e.g., 9.36% vs 9.34% on-PC for PV 1 with XGBoost; 9.38% vs 9.40% for LSTM on the 12192-sample dataset) that are statistically indistinguishable from PC-trained models. The authors also show that dropping from double to float32 precision more than halves LSTM training time without degrading accuracy, and that convergence patterns remain similar. They frame the result as demonstrating the feasibility of achieving grid-edge intelligence via existing advanced metering infrastructures.

Load-bearing premise

The whole argument rests on the assumption that the particular smart meter tested (ARM Cortex-A53, 984 MB RAM, 977 MB disk, 64-bit Linux) is representative of 'existing advanced metering infrastructures'; if typical deployed meters are weaker or lack a 64-bit OS, the measured training times and feasibility do not transfer.

Editorial extensions

If this is right

  • Smart meters could retrain PV forecasting models hourly or daily on-site, keeping models fresh as weather and degradation change.
  • Privacy improves because household generation data need not leave the meter for training, and communication load to the control center drops.
  • On-device training makes grid-edge autonomy possible in microgrids with poor or intermittent communication links.
  • Reduced-precision training schemes offer a template for squeezing deep models into similarly constrained meters.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • One implicit consequence is that the same cross-compilation plus custom C++ recipe could be ported to other ARM-based meters with similar capabilities, so the result may generalize to other vendor hardware if the operating system and memory allow.
  • The paper does not test federated or continual learning; a natural next step is to combine on-device training with model aggregation across many meters, which the reported per-meter training times make plausible.
  • Because only historical power measurements are used as features, the accuracy ceiling is set by weather variability; adding low-cost local sensors such as irradiation or temperature could widen the useful gap between on-device and PC training, since such data would be available only at the edge.
  • The reported MAPE near 9% suggests the limiting factor is data and features rather than hardware precision; a reader could test this by training the same models on the same data with float32 on a PC and comparing the results.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

5 major / 6 minor

Summary. The paper reports a feasibility study of on-device model training on a mass-produced smart meter (quad-core ARM Cortex-A53, 984 MB RAM, 977 MB disk, 64-bit Linux) for PV power forecasting. Two models are trained on the meter and on a desktop PC: XGBoost, using a cross-compiled Python stack, and LSTM, implemented from scratch in C++ with Eigen. For LSTM, the authors propose "mixed-" and "reduced-"precision training schemes (partial or full conversion from double to float32). The reported results show that on-device XGBoost training takes about 200–270 seconds with MAPE values within about 0.1 percentage points of PC training, and LSTM training takes 421–7043 seconds in double precision, reduced by about half with full float32 conversion, with similar accuracy. The paper concludes that grid-edge intelligence via existing advanced metering infrastructures is economically feasible.

Significance. If the central claim holds, this is a useful engineering demonstration: a commercially deployed smart meter can run not only inference but also training of gradient-boosted trees and LSTMs on real microgrid data, with training times ranging from minutes to a couple of hours. The strength of the paper is that it is grounded in a concrete hardware/software stack rather than a simulation: the cross-compilation steps, package versions, and C++/Eigen LSTM implementation are described in enough detail to be reproduced, and all comparisons are performed against an independent PC training baseline on the same real dataset. The mixed-/reduced-precision results provide a practical speedup with negligible accuracy degradation in the reported cases. However, the significance is limited by the single-device evaluation and by the problematic metric definition, which the authors must address before the broad generalization to "existing advanced metering infrastructures" can be accepted.

major comments (5)
  1. [Section II-A, Abstract, Conclusion] The paper generalizes from one specific meter model (quad-core Cortex-A53, 984 MB RAM, 977 MB disk, 64-bit ARM-Linux 4.9) to "the existing advanced metering infrastructures" without any evidence that this hardware profile is representative. Many deployed smart meters use 8/16/32-bit MCUs with orders of magnitude less RAM and no 64-bit Linux or writable filesystem; the cross-compiled Python/numpy/scipy/pandas/XGBoost stack and the C++/Eigen trainer would not fit or would violate operational training-time budgets. This is load-bearing because the abstract and conclusion make the feasibility claim about the existing AMI fleet, not just about this one device. Please add either a second-device experiment, a minimum-hardware analysis, or an explicit fleet-representativeness argument based on deployment statistics, or rephrase the claim to be specific to this class of Linux-based meters.
  2. [Eq. (2), Section IV] The metric defined in Eq. (2) is not MAPE (Mean Absolute Percentage Error). The formula computes 1 minus the square root of the mean squared error normalized by capacity, i.e., 1 - RMSE/Cap, expressed as a percentage. This is an accuracy-type metric, not a mean absolute percentage error. Since the same formula is used for PC and on-device results, the internal comparison remains meaningful, but the label "MAPE" is misleading and the values cannot be compared with standard MAPE numbers in the literature. Please rename the metric (e.g., "normalized RMSE accuracy") or replace it with a true MAPE definition, and update the text and tables accordingly.
  3. [Section IV, Tables IV-VI] No train/validation/test split is described. The text states that the training set contains data from January 2024 to May 2024 and that the goal is to forecast 24 hours ahead, but it does not specify which portion was used for training, which for validation, and which for testing, nor whether the split is chronological. Without this information, the reported MAPE values and the PC-versus-device comparison cannot be independently reproduced or assessed for data leakage. Please provide the split rule, the sample counts, and, ideally, the forecast horizon alignment (e.g., rolling window evaluation).
  4. [Section IV-B, IV-C, Tables V-VI] The LSTM experiments are conducted only on PV household 2, while the XGBoost experiments cover all six households. Given that the central claim is about the feasibility of on-device LSTM training, the absence of results for the other households leaves the LSTM section anecdotal. Differences across households could affect the feasibility conclusion (e.g., data length 2976 vs 12192 already causes a large time difference). Please extend the LSTM evaluation to at least the remaining five PV households or clearly justify why household 2 is representative.
  5. [Section IV-C, Table VI] The "Mixed" precision scheme is underspecified. The text says "Convert 50% variables to float32," but it does not state which 50% of variables (e.g., input data, weights, activations, gradients, or optimizer states) are converted, nor how the selection was made. Since the claimed speedup and accuracy of the mixed scheme depend on this choice, the experiment is not reproducible. Please provide the exact conversion policy, or if the selection was arbitrary, state that and test at least one alternative selection to show robustness.
minor comments (6)
  1. [Section I, Introduction] The phrase "the the remote" in the first paragraph should be corrected to "the remote."
  2. [Section I, Introduction] Reference [5] (TinyTL) is incomplete: it lacks the publication venue and year. Reference [4] also lacks a venue. Please complete the bibliography.
  3. [Section II-B] The sentence "Hence. the forecasting task" contains a period instead of a comma after "Hence." Please correct the punctuation.
  4. [Section IV-A, Table IV] The XGBoost training times are given as single values without variance or repeated-run statistics; given that runtime on a shared OS can vary, please state whether times are single runs or medians/averages over multiple runs.
  5. [Section IV-C] The text says that "the time costs drop more than half" for the Float scheme; from Table VI, the reduction from 421 to 184 seconds is indeed 56%, but the reduction from 7043 to 3074 seconds is 56.3%, so "more than half" is accurate. However, for the Mixed scheme the reduction from 421 to 265 seconds is 37%, which is still "more than 1/3" but the wording should be checked against each row to avoid overstatement.
  6. [Section IV] The figures (Fig. 1-4) would benefit from higher resolution and, in Fig. 4, from axis labels matching the text (e.g., "Loss" is present but the curves should be described in the caption). Also, the captions do not indicate that the loss curves correspond to PV ID 2 only.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity found: the paper is an empirical feasibility study whose on-device training results are benchmarked against an independent PC baseline.

full rationale

The paper contains no theoretical derivation chain that could reduce to its own inputs. The core claim is an empirical demonstration that XGBoost and LSTM models can be trained on a specific mass-production smart meter with accuracy close to that of a desktop PC. The only equations are the functional notation in Eq. (1) and the performance metric in Eq. (2); both are definitional, and Eq. (2) is applied identically to the PC and meter outputs, so the comparison is self-consistent rather than circular. The mixed- and reduced-precision training variants are engineering modifications whose speed and accuracy numbers are directly measured, not implied by the precision choices by construction. The single self-citation, reference [2] by Zhu, Xu, and Huang, is used only as a related-work example of embedding machine learning in a smart meter for voltage control; it is not load-bearing for the feasibility claim, and no uniqueness theorem or fitted parameter is imported from it. The paper's main limitation is empirical generalizability from one meter model to all advanced metering infrastructures, but that is an unsupported extrapolation, not circular reasoning. Accordingly, the correct circularity score is 0.

Assumptions & free parameters 7 free parameters · 5 assumptions · 0 invented entities

The paper is an empirical feasibility study; it introduces no new physical entities or mathematical axioms. The results rest on model hyperparameters chosen by hand, a domain assumption that PV power is forecastable from history alone, and a generalization from one meter model to 'existing AMI'. These are listed above.

free parameters (7)
  • LSTM hidden units = 32
    Chosen for the LSTM architecture in Table III; no tuning or sensitivity analysis is reported, but it directly affects model capacity and results.
  • LSTM training epochs = 50
    Set in Table III; training stops at a fixed epoch count rather than by a convergence criterion.
  • LSTM batch size = 16
    Set in Table III; affects training speed and gradient noise.
  • LSTM learning rate = 0.001
    Set in Table III; no scheduler or tuning is described.
  • LSTM number of cells (input window length) = 24 or 96
    The input feature length k in Eq. (1) is chosen by the authors; both values are tested for PV ID 2 only.
  • Mixed-precision conversion percentage = 50% (Mixed), 100% (Float)
    The 'Mixed' scheme converts a hand-chosen 50% of variables to float32; no analysis is given of which variables are converted or why 50% is used.
  • XGBoost hyperparameters = unspecified defaults
    Table IV results depend on XGBoost 2.1.1 defaults; no hyperparameters or tuning procedure are reported.
assumptions (5)
  • domain assumption PV power at time t+h is predictable from historical power measurements alone (Eq. 1).
    No weather or irradiance inputs are used; the entire forecasting task rests on autocorrelation in measured power.
  • domain assumption The January-May 2024 data for six PV households is representative and the trained models generalize to future periods.
    No train/test split, seasonality, or covariate-shift analysis is reported in Section IV.
  • domain assumption The from-scratch C++/Eigen LSTM and backpropagation implementation is correct.
    No numerical validation or formal verification is provided for the custom training code in Section III-C.
  • domain assumption The studied smart meter is representative of 'existing advanced metering infrastructures'.
    Only one meter model is tested; the abstract and conclusion generalize without a hardware survey.
  • standard math Backpropagation and LSTM mathematics as implemented are standard.
    The paper relies on standard deep learning mathematics but provides no proof or external benchmark against a reference implementation.

how reviews work

0 comments
Cite this review

Pith. "Pith review of On-Device Training of PV Power Forecasting Models in a Smart Meter for Grid Edge Intelligence." pith.science (2026). https://pith.science/paper/YARFUD2B

@misc{pith2026250707016,
  author       = {Pith},
  title        = {Pith review of: On-Device Training of PV Power Forecasting Models in a Smart Meter for Grid Edge Intelligence},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/YARFUD2B}},
  note         = {Machine review of arXiv:2507.07016}
}
read the original abstract

In this paper, an edge-side model training study is conducted on a resource-limited smart meter. The motivation of grid-edge intelligence and the concept of on-device training are introduced. Then, the technical preparation steps for on-device training are described. A case study on the task of photovoltaic power forecasting is presented, where two representative machine learning models are investigated: a gradient boosting tree model and a recurrent neural network model. To adapt to the resource-limited situation in the smart meter, "mixed"- and "reduced"-precision training schemes are also devised. Experiment results demonstrate the feasibility of economically achieving grid-edge intelligence via the existing advanced metering infrastructures.

Figures

Figures reproduced from arXiv: 2507.07016 by the authors.

Figure 1
Figure 1. The basic idea of “on-device training” for PV power forecasting [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗
Figure 2
Figure 2. The workflow for on-device training of two representative ML models [PITH_FULL_IMAGE:figures/full_fig_p002_2.png] view at source ↗
Figure 3
Figure 3. The workflow of the proposed mixed-precision training scheme [PITH_FULL_IMAGE:figures/full_fig_p003_3.png] view at source ↗
Figures from the paper (1 more)
Figure 4
Figure 4. Figure 4: The training-loss curves under different precision schemes, lengths of [PITH_FULL_IMAGE:figures/full_fig_p003_4.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

6 extracted references · 5 canonical work pages

  1. [1]

    Moosmann, H

    J. Moosmann, H. M ¨uller, N. Zimmerman, G. Rutishauser, L. Benini and M. Magno, ”Flexible and Fully Quantized Lightweight TinyissimoYOLO for Ultra-Low-Power Edge Systems,” in IEEE Access, vol. 12, pp. 75093- 75107, 2024, doi: 10.1109/ACCESS.2024.3404878

    work page arXiv 2024

  2. [2]

    Y . Zhu, L. Xu and J. Huang, ”Embedded Machine Learning for Solar PV Power Regulation in a Remote Microgrid,” 2024 7th International Conference on Power and Energy Applications (ICPEA), Taiyuan, China, 2024, pp. 756-761, doi: 10.1109/ICPEA63589.2024.10784815

    arXiv 2024

  3. [3]

    On-Device Training Under 256KB Memory,

    J. Lin, L. Zhu, W.M. Chen, W.C. Wang, C. Gan, and S. Han, “On-Device Training Under 256KB Memory,” in Advances in Neural Information Processing Systems, vol. 35, 2022, pp. 22941–22954

    work page 2022

  4. [4]

    Towards Federated Learning with On-device Training and Communication in 8-bit Floating Point,

    B. Wang, A. Berg, D. A. E. Acar, and C. Zhou, “Towards Federated Learning with On-device Training and Communication in 8-bit Floating Point,” Jul. 2024

    work page 2024

  5. [5]

    TinyTL: Reduce Memory, Not Parameters for Efficient On-Device Learning

    H. Cai, C. Gan, L. Zhu, and S. Han, “TinyTL: Reduce Memory, Not Parameters for Efficient On-Device Learning.”

    work page

  6. [6]

    Available: https://eigen.tuxfamily.org

    Eigen, a C++ template library for linear algebra.[Online]. Available: https://eigen.tuxfamily.org

    work page

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.