{"id":"9d46481d-e450-43df-8a1c-da9ed81e3fa3","arxiv_id":"2507.07016","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":7,"one_line_summary":"On-device training of XGBoost and LSTM PV forecasting models on a commercial smart meter is feasible, with accuracy close to PC training and about 2x speedup from float32 precision conversion.","lead":"This paper tests whether machine learning models can be trained directly on a commercial smart meter, using a PV power forecasting task on real microgrid data. It reports that XGBoost and LSTM models train on the meter with accuracy close to a PC, and that float32 precision roughly halves LSTM training time.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The conclusion generalizes from one meter model (Section II-A) to all 'existing advanced metering infrastructures' without evidence that its compute/storage/OS profile is representative; the feasibility claim is hardware-bound and needs cross-device support.","rationale":"The paper is a credible feasibility demonstration for one specific commercial meter: XGBoost training matches PC accuracy across six households, LSTM matches on one household, and reduced precision gives roughly 2x speedup with similar loss curves. The internal comparisons are self-consistent, and the resource measurements are plausible for a Cortex-A53 board. The load-bearing weakness is the generalization from this single hardware sample to 'existing advanced metering infrastructures' as a whole. The reader's weakest assumption identifies exactly this gap, and I agree. Additional flaws—Eq. (2) defines a normalized-RMSE-based accuracy rather than MAPE, no code/data/error bars, LSTM tested on one household—are real but secondary: they weaken precision and reproducibility, not the relative PC-vs-meter comparison that forms the core feasibility evidence. Because the central feasibility claim is plausible for the tested device but unproven for the fleet, the Conditional verdict remains appropriate; the concern would move the verdict only if the cross-device test failed, in which case the conclusion should be narrowed to 'this meter class' or Rejected as stated.","tokens_in":4681,"tokens_out":5234,"duration_ms":57676,"concrete_test":"Obtain the lowest-resource smart meter model actually deployed in a utility AMI fleet (or a representative 64 MB RAM / 32-bit RTOS meter without Linux) and run the same ported training stack—cross-compiled Python, XGBoost, and the C++/Eigen LSTM—on one PV household with the Table V settings. If installation fails, memory is exceeded, or on-device training time exceeds the stated hourly retraining window, the 'existing advanced metering infrastructures' claim fails for that segment; if it trains with similar MAPE and acceptable time, the generalization is supported.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's central claim is that on-device training is feasible 'via the existing advanced metering infrastructures' (Abstract, Conclusion). The supporting experiment uses a single mass-production meter: quad-core Cortex-A53, 984 MB RAM, 977 MB disk, 478 MB writable after system reservation, 64-bit ARM-Linux 4.9 (Section II-A). Every measured result—XGBoost in ~200 s, LSTM in 421–7043 s, reduced-precision LSTM in 184–3074 s—is specific to that configuration. The leap to 'existing AMI' assumes this hardware profile is typical, but no fleet survey, minimum-spec analysis, or second-device test is provided. Many deployed smart meters use 8/16/32-bit MCUs with KBs to low MBs of RAM and no 64-bit Linux or writable filesystem; the cross-compiled Python + numpy/scipy/pandas/XGBoost stack and the C++/Eigen LSTM trainer would not fit or would exceed operational training-time budgets. This is not an internal inconsistency, but it is an unsupported empirical extrapolation, and it is load-bearing: if the meter tested is an outlier, the headline contribution does not transfer. The mislabeled 'MAPE' in Eq. (2) is secondary because the same metric is used for PC and meter comparisons.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":4938,"tokens_out":3124,"duration_ms":37679,"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":[{"comment":"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.","section":"Section II-A, Abstract, Conclusion"},{"comment":"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.","section":"Eq. (2), Section IV"},{"comment":"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).","section":"Section IV, Tables IV-VI"},{"comment":"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.","section":"Section IV-B, IV-C, Tables V-VI"},{"comment":"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.","section":"Section IV-C, Table VI"}],"minor_comments":[{"comment":"The phrase \"the the remote\" in the first paragraph should be corrected to \"the remote.\"","section":"Section I, Introduction"},{"comment":"Reference [5] (TinyTL) is incomplete: it lacks the publication venue and year. Reference [4] also lacks a venue. Please complete the bibliography.","section":"Section I, Introduction"},{"comment":"The sentence \"Hence. the forecasting task\" contains a period instead of a comma after \"Hence.\" Please correct the punctuation.","section":"Section II-B"},{"comment":"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.","section":"Section IV-A, Table IV"},{"comment":"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.","section":"Section IV-C"},{"comment":"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.","section":"Section IV"}],"recommendation":"major_revision","confidential_remarks":"This is a practical engineering paper with a real hardware deployment, which gives it a useful contribution if the evaluation is tightened. My main concern is the gap between the narrow single-device experiment and the broad \"existing AMI\" conclusion; the authors can close that gap either by adding a minimal cross-device or specification-bound analysis or by softening the claim. The mislabeled MAPE metric is another issue that must be fixed before publication. The paper would be a better fit for an application-oriented venue that values deployment case studies; for a top ML venue, the evaluation depth is currently below the bar, but the message is likely worth publishing after revision."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague—\n\nQuick take: this is a solid engineering feasibility study, not a research breakthrough. The authors actually ran XGBoost and LSTM training on a commercial smart meter (Cortex-A53, 984 MB RAM) for PV power forecasting, and got accuracy close to a desktop PC: XGBoost in about 200 seconds, LSTM in 7 minutes to under 2 hours for the smaller dataset, with a 2x speedup from float32 conversion. That is a real data point for the grid-edge AI community, and the paper gives enough detail on cross-compiling Python/numpy/scipy/XGBoost and writing a custom C++/Eigen LSTM trainer that a competent engineer could reproduce the setup.\n\nWhat's new: applying on-device training to a commercial smart meter is new, and the mixed/reduced-precision LSTM speedup is a useful engineering contribution. The paper is honest about the resource constraints and the fact that no off-the-shelf library fits.\n\nThe soft spots are mostly reporting and scope. First, Eq. (2) is not MAPE; it's a normalized RMSE expressed as an accuracy percentage. That's sloppy but not harmful because the same metric is used for PC and meter, so the comparison still holds. Second, the paper gives no train/test split description, no error bars, and the LSTM experiments cover only PV household 2, so we don't know if the LSTM accuracy results are stable across households. Third, there is no independent baseline like persistence or an ARIMA; the MAPE values are only meaningful relative to the PC, not in an absolute sense. Fourth, the 'economically feasible' claim in the abstract is not backed by any cost or energy measurement. Finally, and most importantly, the leap from one meter model to 'existing advanced metering infrastructures' is unsupported. Many deployed meters have far less RAM, no 64-bit Linux, and might not even have a writable filesystem. The authors should either survey hardware specs or soften the conclusion.\n\nThese issues are fixable and none of them sink the central feasibility claim, which is well supported by the tables. The paper deserves peer review, but a serious referee should ask for the metric fix, a split description, error bars, an extra LSTM household, and either a hardware generalizability argument or a careful rewording of the abstract.\n\nWho it's for: practitioners in power systems edge intelligence and anyone working on on-device training in resource-limited embedded devices. I'd send it to a second round of review rather than desk reject, but it needs a substantive revision before acceptance.","headline":"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'.","tokens_in":5498,"tokens_out":3227,"would_cite":false,"duration_ms":33769,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"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…","keywords":["on-device training","edge intelligence","smart meter","photovoltaic power forecasting","XGBoost","LSTM","mixed-precision training","embedded machine learning"],"falsifier":"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.","tokens_in":4453,"feed_emoji":"⚡","tokens_out":4487,"duration_ms":40981,"temperature":0.7,"pith_summary":"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.","feed_headline":"Mass-produced smart meter can train PV forecasting models on its own","feed_subtitle":"LSTM and XGBoost train on-meter in minutes to hours with accuracy matching a desktop PC.","key_machinery":"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.","core_discovery":"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.","pith_inferences":["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."],"forward_implications":["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."],"supporting_citations":[{"why":"Shows a smart meter can already run trained ML models for PV voltage control, establishing the meter as a viable inference platform that training can extend.","marker":"[2]"},{"why":"Demonstrates on-device training under extreme memory constraints, providing the motivating precedent that training on resource-limited devices is possible.","marker":"[3]"},{"why":"Uses low-precision (FP8) arithmetic for on-device training in federated learning, supporting the paper's choice of reduced-precision training schemes.","marker":"[4]"},{"why":"Introduces a memory-reduction technique for on-device learning, reinforcing the need for memory-efficient training methods on constrained hardware.","marker":"[5]"},{"why":"Supplies the Eigen C++ template library that the paper uses to implement the LSTM and its training loop from scratch on the meter.","marker":"[6]"}],"fun_headline_variants":["Smart meter trains PV forecasting models with PC-level accuracy","No dedicated AI hardware: smart meter trains its own PV models","On-device training on smart meters matches desktop for solar forecasting","Commodity smart meter trains LSTM and XGBoost for PV forecasting","Mass-market meter achieves grid-edge intelligence via on-device training"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["Smart meter trains PV forecasting models with PC-level accuracy","No dedicated AI hardware: smart meter trains its own PV models","On-device training on smart meters matches desktop for solar forecasting","Commodity smart meter trains LSTM and XGBoost for PV forecasting","Mass-market meter achieves grid-edge intelligence via on-device training"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000886,"raw_usage":{"total_tokens":3765,"prompt_tokens":823,"completion_tokens":2942,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":439,"completion_tokens_details":{"reasoning_tokens":2854}},"tokens_in":439,"tokens_out":2942,"duration_ms":24480,"temperature":1.0,"reasoning_tokens":2854,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-06T18:49:16.769436+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[{"cited_title":"On-Device Training Under 256KB Memory,","cited_arxiv_id":null,"evidence_quote":"Demonstrates on-device training under extreme memory constraints, providing the motivating precedent that training on resource-limited devices is possible."},{"cited_title":"Towards Federated Learning with On-device Training and Communication in 8-bit Floating Point,","cited_arxiv_id":null,"evidence_quote":"Uses low-precision (FP8) arithmetic for on-device training in federated learning, supporting the paper's choice of reduced-precision training schemes."},{"cited_title":"TinyTL: Reduce Memory, Not Parameters for Efficient On-Device Learning","cited_arxiv_id":null,"evidence_quote":"Introduces a memory-reduction technique for on-device learning, reinforcing the need for memory-efficient training methods on constrained hardware."},{"cited_title":"Available: https://eigen.tuxfamily.org","cited_arxiv_id":null,"evidence_quote":"Supplies the Eigen C++ template library that the paper uses to implement the LSTM and its training loop from scratch on the meter."}],"review_version":1}