{"id":"a6745e69-8e2e-4c1c-8f01-e6bec0a19ab6","arxiv_id":"2509.10713","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":3.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":3,"one_line_summary":"A low-cost Raspberry-Pi-based prototype with threshold-based grid/battery switching is described and tested, but demand-charge reduction is only shown in a self-referential simulation.","lead":"This paper describes a low-cost home energy management prototype that switches between the electric grid and a battery based on load, battery charge, and time of day. It is one of many similar senior-design projects; its value is as a teaching platform rather than as a new control method.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Reported 5.4 kWh discharge exceeds the stated 4.608 kWh usable battery capacity, and Algorithm 1 lacks SoC-aware peak-shaving logic.","rationale":"The reader's weakest assumption correctly flagged the fixed 700 W threshold and lack of sizing/forecasting, which is a real and load-bearing issue for real-world demand-charge reduction. My stress-test confirms that concern but sharpens it with a concrete internal inconsistency: the simulation's reported 5.4 kWh discharge exceeds the stated usable capacity of 4.608 kWh. This makes the key validation evidence physically impossible, strengthening the case that the central claim is unsupported. The reader did not explicitly mention this discrepancy, hence 'partial' agreement. A corrected simulation with proper energy limits and a SoC-aware control policy is necessary before claiming validated cost savings. The paper still has merit as a hardware/educational prototype, so a conditional verdict is appropriate rather than outright rejection.","tokens_in":9514,"tokens_out":4493,"duration_ms":56512,"concrete_test":"Re-run the Section IV.A simulation with the battery model capped at the stated 4.608 kWh usable capacity and a realistic afternoon load profile (e.g., 1300 W for 5 consecutive hours). Verify (i) that the state-of-charge trace conserves energy (total discharge ≤ 4.608 kWh plus permitted charge) and (ii) that grid demand remains below the 700 W threshold for the entire peak window. If either condition fails, the claimed demand-charge reduction is not established and the manuscript must be revised.","verdict_should_be":"CONDITIONAL","load_bearing_attack":"The central claim of validated demand-charge reduction rests on the simulation in Section IV.A, which reports discharging 5.4 kWh during peak windows. This is physically impossible for the described battery: Section III.A states a 5120 Wh total and 4608 Wh usable capacity, and 5400 Wh exceeds both. Either the simulation assumes a different battery or the energy accounting is wrong, so Figure 6's load-flattening result is not credible as evidence. Independently, even a corrected simulation would not save the claim: Algorithm 1's high-load branch (lines 13–14) switches to battery whenever the load exceeds 700 W with no check on SoC or available energy. The paper's own backup test (1300 W, 3.9 h) shows the battery would exhaust well before a typical 5-hour afternoon peak; once SoC collapses, the system returns to grid and grid demand can exceed 700 W, defeating demand-charge reduction. No forecasting, battery sizing, or peak-window analysis is provided to rule this out. Therefore the validation does not support the abstract's assertion that real-world testing confirmed cost reduction.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper reports an undergraduate senior-design project: a low-cost Demand Charge Management (DCM) and Energy Management System (EMS) prototype built from a Raspberry Pi 5, PZEM-016 sensors, a LiFePO4 battery, relays, and IoT visualization. The controller switches between grid and battery based on a 700 W power threshold, time of day, and battery state of charge, with an additional emergency-stop and manual-override mode. The paper describes the three-layer hardware/software architecture, presents component-level tests of sensor accuracy, relay switching, SoC tracking, and power factor, and reports a MATLAB simulation that allegedly flattens a household load curve and reduces demand charges. The authors claim the prototype was validated by real-world testing and can reduce electricity costs through peak shaving and energy arbitrage.","tokens_in":9773,"tokens_out":2903,"duration_ms":39420,"significance":"If the validation were sound, a roughly $1,800 open-source EMS/DCM prototype with measured component behavior could be a useful educational and low-cost demonstration platform. The paper gives a clear hardware bill of materials and a plausible control architecture, and the component tests (7 W bulb reading, relay transitions, SoC tracking) are consistent with the described hardware. However, the central economic claim—demand-charge reduction and cost savings—is not supported by the evidence as presented. The simulation is built from the controller's own rule set, contains an energy-accounting inconsistency (5.4 kWh discharged from a 4.608 kWh usable battery), and lacks a baseline, tariff model, or uncertainty analysis. The paper is therefore a reasonable prototype description but does not currently establish the load-bearing performance claim.","major_comments":[{"comment":"The simulation reports that the system discharged 5.4 kWh during peak windows, but Section III.A states the battery has a total capacity of 5120 Wh and a usable capacity of 4608 Wh. 5.4 kWh exceeds both values. Either the simulation uses a different battery model or the energy accounting is incorrect, and Figure 6, which shows the load curve with and without battery support, is not credible until this is resolved. Please correct the simulation or clarify the battery model and rerun the analysis.","section":"Section IV.A"},{"comment":"The high-load branch unconditionally sets relays ON (battery mode) whenever PwLoad exceeds the 700 W threshold, with no check on SoC or remaining discharge time. The paper's own backup test reports that a 1300 W load is sustained for about 3.9 hours. A typical afternoon peak window can exceed 4 hours, so the battery will be exhausted before the peak ends; the controller would then drop back to grid and grid demand would exceed 700 W, defeating the demand-charge reduction claim. The decision logic needs a SoC-aware peak-shaving rule, a charging strategy, and a simulation or experiment that covers the entire peak window.","section":"Algorithm 1, lines 13-14"},{"comment":"The demand-charge reduction claim is not validated by the presented evidence. The MATLAB simulation has no described input load profile, no baseline simulation without the controller, no electricity tariff or demand-charge rate structure, and no error bars or sensitivity analysis. Because the simulation implements the same rule-based switching logic that the paper proposes, it can at best show that the algorithm behaves as intended; it cannot independently establish cost savings. Please provide a baseline comparison, a documented load scenario, and a billing calculation, ideally with experimental data over at least one billing period.","section":"Section IV.A"},{"comment":"The abstract states that 'real-world testing' confirmed the 'capability to reduce demand charges and ensure reliable energy delivery.' The experiments reported in Section IV validate only component-level behavior (measurement accuracy, relay switching, SoC monitoring, power factor). No real-world demand charge or electricity bill reduction is measured. This statement overreaches the evidence and should be tempered unless a full-system bill comparison is added.","section":"Abstract and Conclusion"}],"minor_comments":[{"comment":"Typographical errors: 'Raspbery' in Fig. 2, 'Sate of Charge' in Fig. 4, and 'system' misspelled as 'system' in the Fig. 2 caption. Please proofread.","section":"Figures 2 and 4"},{"comment":"The variable 'PresMin' and the constant 6 in Algorithm 1 are not defined. Clarify the units and the meaning of the threshold (e.g., 6 AM?).","section":"Section III.B"},{"comment":"The figure appears to be a screenshot and lacks axis labels, units, and a legend. Please replace with a properly labeled plot that includes the baseline and battery-supported curves.","section":"Figure 6"},{"comment":"Reference [33] is an Amazon product page. If available, cite the manufacturer's datasheet for the PZEM-016 instead.","section":"Reference [33]"},{"comment":"The 37 Wh UPS backup duration of 'approximately 4 hours and 20 minutes' is inconsistent with an average draw of 8.5 W (37 Wh / 8.5 W ≈ 4.35 h, i.e., 4 h 21 min, which is internally consistent; please state the calculation explicitly for clarity).","section":"Section IV.A"}],"recommendation":"major_revision","confidential_remarks":"The manuscript reads like a senior design project report rather than a research contribution. If the venue accepts such prototype/education papers, the revision should focus on making the performance claims rigorous: fix the battery capacity inconsistency, make the simulation reproducible, add a baseline and billing model, and add SoC-aware logic. The 5.4 kWh discharge issue is the most serious technical red flag and should be resolved before any further consideration."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague,\n\nThe short version: this is a competent senior-design hardware write-up with a clear three-layer architecture and some honest component-level tests, but the abstract's claim that real-world testing confirmed demand-charge reduction is not supported by the evidence. The MATLAB simulation at the heart of that claim discharges 5.4 kWh from a battery the paper itself rates at 4.608 kWh usable. That's physically impossible, and it means Figure 6's load-flattening result cannot be taken as a validated outcome.\n\nWhat's actually new here is the specific low-cost integration: Raspberry Pi 5, PZEM-016 sensors, LiFePO4 battery, relay board, MQTT and Blynk, all at roughly $1,800 versus commercial systems. That's a useful educational template, and the wiring/safety documentation is unusually detailed for a student project. The component tests—7 W bulb reading, relay transition behavior, SoC tracking, standby draw—are consistent with what you'd expect, and the power-factor observations (0.45 grid-side in battery mode) are a nice practical detail.\n\nThe soft spots are real. Algorithm 1's high-load branch switches to battery whenever load exceeds 700 W, with no SoC check; the paper's own backup test (1300 W for 3.9 h) shows the battery exhausts well before a typical afternoon peak. Once SoC collapses, the system returns to grid and the demand charge reappears. The 700 W threshold and time-of-day parameters appear hand-chosen, with no sensitivity analysis or sizing argument. And the simulation is self-referential: it uses the controller's own rules, with no baseline or billing data, and the 5.4/3.6 kWh numbers are internally inconsistent with the stated capacity. The paper would need a comparative field test over a full billing period, with measured grid demand and actual tariff data, before any cost-saving claim is credible.\n\nThat said, the paper is not a waste of time. As a documentation of a low-cost EMS prototype for teaching labs, it has value, and the open-source Python logic is a concrete artifact. But as a peer-reviewed work claiming validated demand-charge reduction, it needs major revision. I'd send it out—a referee should catch the energy imbalance and the missing SoC logic quickly—but with the expectation that the central claim will be substantially downgraded or re-validated.\n\nRecommendation: engage with it as a build/educational contribution, not as a result-bearing paper. A serious referee could help the authors fix the accounting and reframe the contribution honestly.\n\nBest,\n[Your name]","headline":"A well-documented low-cost EMS build with a modest threshold controller, but the validation is undermined by an energy-accounting error that makes the headline savings claim unsupported.","tokens_in":10226,"tokens_out":3815,"would_cite":false,"duration_ms":43923,"reading_group":"maybe","serious_thinker":"no","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"The paper claims a $1,800 prototype cuts electricity costs by switching to battery during peak loads and recharging off-peak, with real-world tests confirming the approach.","keywords":["Demand Charge Management","Energy Management System","Peak Shaving","LiFePO4 battery","Raspberry Pi","Time-of-Use pricing","Real-time control","Internet of Things"],"falsifier":"Run the system for one billing cycle on a household with an afternoon peak longer than the battery's ~3.9-hour endurance at 1300W and read the utility meter: if the controller reverts to grid during that peak, the billed demand will exceed 700W and the demand charge savings are lost.","tokens_in":9416,"feed_emoji":"🔋","tokens_out":4699,"duration_ms":48487,"temperature":0.7,"pith_summary":"The paper sets out to prove that a low-cost, three-layer Energy Management System can reduce residential electricity bills by automatically shifting loads to a battery during peak demand. The controller switches to battery when load exceeds 700W, and charges when off-peak and state of charge is low, achieving peak shaving and energy arbitrage. Real-world component tests validate measurement accuracy, relay response, and state-of-charge tracking; a MATLAB simulation suggests the battery flattens a household load curve. If the claims hold, the system offers a fraction-of-the-cost alternative to commercial systems and a teaching platform.","feed_headline":"This $1,800 prototype switches home loads to battery when demand peaks","feed_subtitle":"The controller cuts demand charges and supplies backup power at about one-tenth the cost of commercial units.","key_machinery":"The load-bearing mechanism is the software control loop encapsulated in Algorithm 1: given load power, battery SoC, current time, and relay mode, it toggles relays to select grid or battery. The fixed 700W threshold is the peak-shaving trigger; the algorithm also uses SoC cutoffs (20% minimum, 100% full) and the 6 a.m. boundary to decide charging versus discharging. This logic, running as Python scripts on a Raspberry Pi 5 with MQTT communication to sensors and the Blynk interface, is what the paper argues can deliver demand-charge reduction at low cost.","core_discovery":"The central claim is that the prototype's threshold-based control logic—executing on a Raspberry Pi with real-time data from PZEM-016 sensors and a BMS—can manage grid and battery sources to reduce demand charges and provide reliable backup. Algorithm 1 formalizes the switching: battery mode whenever load exceeds 700W, grid charging before 6 a.m. when SoC is below 100%, and emergency shutdown on demand. The experimental validation confirms accurate power measurement (±0.1 W), smooth relay transitions with a 0.25-second delay, and SoC tracking; the MATLAB simulation reports 5.4 kWh discharged during peak tariffs and 3.6 kWh recharged off-peak, flattening the load curve.","pith_inferences":["A fixed 700W threshold without load forecasting means the battery can be depleted before the peak window ends; at 1300W the battery lasts about 3.9 hours, so a 4-6 hour afternoon peak would force a return to grid and re-set the demand peak.","The claimed cost reduction could be tested by comparing a full month of utility bills with and without the system, not just component-level tests and a simulated load curve.","The same hardware could support adaptive control by replacing the threshold with a predictive algorithm that anticipates the peak window and adjusts the cutoff based on SoC and forecast load.","The $1,800 vs $16,000 comparison likely excludes installation, inverter, and battery replacement; a lifecycle cost comparison would be a fairer test of the affordability claim."],"forward_implications":["If the threshold logic holds, a residential user can cap grid demand at 700W during peak hours, avoiding demand charges on the most expensive intervals.","The 5120 Wh battery sustains about 3.9 hours at 1300W, providing backup for short outages and time for graceful shutdown.","The MATLAB simulation implies that coordinated scheduling can reduce peak grid draw and shift consumption to off-peak tariffs.","The open-source, $1,800 design makes the system feasible as a laboratory teaching platform and a low-cost deployment option for small commercial users."],"fun_headline_variants":["DIY $1,800 EMS cuts demand charges by battery switching","Peak shaving prototype switches home to battery for less","Low-cost demand charge manager: switch to battery at peaks","Raspberry Pi EMS reduces demand charges with smart switching"],"cache_read_input_tokens":2304,"weakest_assumption_plain":"The system assumes the battery will hold enough charge to cover every period when load exceeds 700W, but the paper includes no sizing analysis or forecast to guarantee that.","fun_headline_variants_meta":{"raw":{"variants":["DIY $1,800 EMS cuts demand charges by battery switching","Peak shaving prototype switches home to battery for less","Low-cost demand charge manager: switch to battery at peaks","Raspberry Pi EMS reduces demand charges with smart switching"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000279,"raw_usage":{"total_tokens":1535,"prompt_tokens":829,"completion_tokens":706,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":573,"completion_tokens_details":{"reasoning_tokens":638}},"tokens_in":573,"tokens_out":706,"duration_ms":8697,"temperature":1.0,"reasoning_tokens":638,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-04T17:34:54.431216+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the system for one billing cycle on a household with an afternoon peak longer than the battery's ~3.9-hour endurance at 1300W and read the utility meter: if the controller reverts to grid during that peak, the billed demand will exceed 700W and the demand charge savings are lost.","supporting_citations":[],"review_version":1}