{"id":11740,"date":"2026-04-04T22:40:14","date_gmt":"2026-04-04T20:40:14","guid":{"rendered":"https:\/\/bitacora.eniac2000.com\/?p=11740"},"modified":"2026-04-04T22:40:16","modified_gmt":"2026-04-04T20:40:16","slug":"sistema-de-telemetria-2-1-desarrollo-asistido-por-ia","status":"publish","type":"post","link":"https:\/\/bitacora.eniac2000.com\/?p=11740","title":{"rendered":"Sistema de telemetr\u00eda 2.1. Desarrollo asistido por IA"},"content":{"rendered":"\n

All\u00e1 por finales de 2016, cuando a\u00fan viv\u00edamos por Irlanda, me dio por montar un sistema casero de telemetr\u00eda para el coche<\/a>. La idea original era razonablemente sencilla: leer algunos datos de la centralita, combinarlos con la posici\u00f3n GPS y enviarlo todo a un servidor para ver, con un poco m\u00e1s de detalle de lo habitual, qu\u00e9 ocurr\u00eda durante un viaje. Como suele pasar con estas cosas, aquello acab\u00f3 creciendo bastante m\u00e1s de la cuenta.<\/p>\n\n\n\n

\"\"
Evoluci\u00f3n de mi sistema de telemetr\u00eda. Desde Irlanda hasta ahora. Generado por IA<\/figcaption><\/figure>\n\n\n\n

Primero lleg\u00f3 la versi\u00f3n basada en Raspberry Pi, de la que habl\u00e9 en aquellas entradas de 2017, as\u00ed como sus mejoras<\/a>. Despu\u00e9s vino la versi\u00f3n 2.0 sobre ESP32 y placa LilyGO T-A7670G<\/a>, que cont\u00e9 a comienzos de 2024. Y ahora le ha tocado el turno a una nueva evoluci\u00f3n que, aunque por fuera pueda parecer continuista, por dentro cambia bastante la pel\u00edcula: mismo objetivo general, mismo esp\u00edritu de cacharreo, pero un firmware bastante m\u00e1s serio en t\u00e9rminos de arquitectura, tolerancia a fallos y gesti\u00f3n del tiempo.<\/p>\n\n\n\n

Adem\u00e1s, esta iteraci\u00f3n ha tenido un ingrediente nuevo: Claude Code<\/strong> como asistente de codificaci\u00f3n basado en IA. Y aqu\u00ed conviene aclarar algo desde el principio. Lo interesante no es que una IA \u201cescriba c\u00f3digo\u201d sin m\u00e1s, sino que sirva de apoyo para ordenar un firmware embebido, detectar puntos fr\u00e1giles, proponer refactorizaciones y documentar el proyecto sin perder de vista el contexto del hardware real. Que, como siempre, es donde terminan apareciendo las sorpresas.<\/p>\n\n\n\n

De d\u00f3nde venimos: la etapa Raspberry Pi<\/h2>\n\n\n\n

La primera encarnaci\u00f3n de este invento era, vista con perspectiva, bastante representativa de la \u00e9poca y tambi\u00e9n de mis querencias. La sonda de captura estaba basada en una Raspberry Pi, conectada por Bluetooth a un adaptador OBD-II para leer la centralita, y acompa\u00f1ada de un m\u00f3dulo GPS para a\u00f1adir geoposicionamiento. Sobre ella corr\u00eda un programa en Python que recog\u00eda los datos, los almacenaba localmente en CSV con marca temporal y los preparaba para su env\u00edo.<\/p>\n\n\n\n

La parte interesante no estaba s\u00f3lo en la captura, sino en toda la arquitectura alrededor. En aquella etapa usaba un broker MQTT local<\/strong> en la propia sonda, que actuaba como capa de desacople y adem\u00e1s como buffer<\/em> persistente. La conectividad hacia fuera se resolv\u00eda mediante tethering<\/em> Bluetooth con un tel\u00e9fono m\u00f3vil, y en el servidor remoto ten\u00eda ya montada una peque\u00f1a plataforma bastante decente: broker MQTT, Graphite, Grafana y un sistema de geoposicionamiento en tiempo real basado en Node-RED. No era precisamente un simple \u201ctracker<\/em>\u201d; era ya una plataforma IoT en peque\u00f1o.<\/p>\n\n\n\n

De hecho, en febrero de 2017 la cosa ya hab\u00eda crecido en ambici\u00f3n: pas\u00e9 de recoger tres par\u00e1metros de la centralita a catorce, reduje la frecuencia de captura para no estrangular el canal Bluetooth, a\u00f1ad\u00ed c\u00e1lculo de distancia recorrida a partir del GPS, y me plante\u00e9 incluso meter aceler\u00f3metros, lo que acab\u00e9 haciendo. El proyecto ten\u00eda bastante de laboratorio port\u00e1til, y esa era precisamente su gracia.<\/p>\n\n\n\n

Mirado con calma, aquella primera versi\u00f3n era robusta por arquitectura<\/em>. La Raspberry Pi jugaba con ventaja: hab\u00eda Linux por debajo, procesos independientes, almacenamiento local relativamente c\u00f3modo, y un broker MQTT en la propia sonda que absorb\u00eda bastante bien los problemas de conectividad. Era m\u00e1s voluminoso, m\u00e1s aparatoso y bastante menos elegante desde el punto de vista f\u00edsico, pero resolv\u00eda muy bien el problema de \u201cseguir capturando y ya sincronizar\u00e9 luego\u201d.<\/p>\n\n\n\n

2017\nRaspberry Pi 2 + GPS + OBD-II Bluetooth + tethering Bluetooth con el m\u00f3vil\n        \u2193\nprograma en Python + CSV local + broker MQTT local persistente\n        \u2193\nbroker MQTT remoto + Graphite\/Grafana + Node-RED<\/pre>\n\n\n\n
La versi\u00f3n 2.0: menos cacharrer\u00eda, m\u00e1s integraci\u00f3n<\/h2>\n\n\n\n
Tras unos a\u00f1os en barbecho, decid\u00ed resucitar el sistema, pero con un objetivo bastante claro: quer\u00eda que la parte embarcada dejase de depender del tel\u00e9fono m\u00f3vil para tener salida al exterior. Ah\u00ed es donde entr\u00f3 en juego la LilyGO TTGO T-A7670G<\/strong>, una de esas placas que a uno le hacen pensar que hoy en d\u00eda montar prototipos es casi hacer trampas: ESP32, Bluetooth, m\u00f3dem celular, GPS y z\u00f3calo para bater\u00eda 18650, todo junto en una sola placa.<\/p>\n\n\n\n
La mejora era evidente. Se reduc\u00eda el volumen del conjunto, desaparec\u00eda el tethering Bluetooth, y la conectividad pasaba a ser propia gracias a una MicroSIM 4G. El sistema pod\u00eda publicar directamente en el broker MQTT remoto sin necesidad de montar un broker intermedio en local, y con una cadencia de env\u00edo de un mensaje cada diez segundos el consumo de datos resultaba casi rid\u00edculo. Mucho m\u00e1s limpio, mucho m\u00e1s aut\u00f3nomo, y bastante m\u00e1s f\u00e1cil de dejar permanentemente en el coche.<\/p>\n\n\n\n
Claro que tambi\u00e9n aparecieron los detalles que suelen quedar fuera de las hojas comerciales. La placa tiene variantes, el GPS no se comporta exactamente igual en todas ellas, y la antena pasiva ven\u00eda a ser un chiste de mal gusto dentro del coche. La soluci\u00f3n pas\u00f3 por una antena GPS activa con su correspondiente pigtail<\/em>, y en cuanto la mont\u00e9, la diferencia fue brutal. Con estas cosas siempre pasa igual: uno compra una placa \u201cintegrada\u201d y luego descubre que la integraci\u00f3n, como concepto, tiene bastante letra peque\u00f1a.<\/p>\n\n\n\n
La otra asignatura pendiente fue, una vez m\u00e1s, el OBD-II<\/strong>. La placa enlazaba por Bluetooth con el ELM327, pero la extracci\u00f3n de datos segu\u00eda sin ser todo lo fiable que yo quer\u00eda. Curiosamente, la evoluci\u00f3n del proyecto no ha sido lineal en este punto: la etapa Raspberry Pi era m\u00e1s aparatosa, s\u00ed, pero en la parte OBD llegu\u00e9 a estar m\u00e1s cerca de una telemetr\u00eda rica. En la etapa ESP32 la gran victoria estaba en la integraci\u00f3n f\u00edsica y la autonom\u00eda de comunicaciones.<\/p>\n\n\n\n
2024\/2026\nLilyGO TTGO T-A7670G + MicroSIM 4G + GPS + Bluetooth\n        \u2193\nfirmware Arduino\/ESP32\n        \u2193\nMQTT remoto directo + plataforma de visualizaci\u00f3n y anal\u00edtica<\/pre>\n\n\n\n
Lo que no me convenc\u00eda del firmware anterior<\/h2>\n\n\n\n
El firmware que acompa\u00f1aba a esa versi\u00f3n 2.0 funcionaba razonablemente bien cuando todo iba como deb\u00eda. El problema es que llevaba dentro varias decisiones que, con el tiempo, me apetec\u00eda corregir. La principal era su car\u00e1cter bloqueante<\/strong>. Gran parte de la l\u00f3gica de inicializaci\u00f3n y reconexi\u00f3n se apoyaba en esperas largas, reintentos con delay()<\/code> y funciones que pod\u00edan quedarse un buen rato ocupadas intentando recuperar la red.<\/p>\n\n\n\n
En un PC o en una Raspberry Pi este tipo de cosas son molestas, pero soportables. En un microcontrolador que tiene que leer continuamente una trama NMEA por un puerto serie, mantener una sesi\u00f3n GPRS y no perder el hilo de MQTT, son directamente una mala idea. Si el m\u00f3dem se queda varios segundos \u2014o minutos\u2014 intentando volver a registrarse, el GPS sigue mandando datos igualmente. Si el firmware no est\u00e1 leyendo ese puerto en todo ese tiempo, esas frases NMEA se van perdiendo por el camino. Y ah\u00ed empieza el dolor de cabeza.<\/p>\n\n\n\n
La gesti\u00f3n de la hora tampoco me terminaba de convencer. En la versi\u00f3n anterior se obten\u00eda mediante una consulta NTP hecha \u201ca pelo\u201d, levantando una sesi\u00f3n UDP con comandos AT, construyendo el paquete manualmente y parseando luego la respuesta. Funcionar, funcionaba. Pero era una soluci\u00f3n bastante m\u00e1s artesanal y fr\u00e1gil de lo que realmente necesitaba el proyecto. Si el m\u00f3dem ya es capaz de devolver hora de red, tiene poco sentido reinventar medio cliente NTP dentro del sketch.<\/p>\n\n\n\n
Otro detalle mejorable era el propio modelo de datos publicado. El mensaje de telemetr\u00eda llevaba lo b\u00e1sico \u2014posici\u00f3n, velocidad y un RPM que en la pr\u00e1ctica estaba a\u00fan por cerrar\u2014 y la marca temporal se publicaba aparte, de forma peri\u00f3dica. Eso serv\u00eda, pero dejaba un payload menos autocontenido de lo ideal. Si quiero que cada muestra sea analizable por s\u00ed misma, tiene mucho m\u00e1s sentido que viaje ya con su timestamp<\/em>, su origen temporal y algo m\u00e1s de contexto.<\/p>\n\n\n\n
Antes:\nsetup() -> inicializar modem -> esperar red -> conectar GPRS\nloop()  -> si cae la red, esperar\/reintentar\n           pedir hora por NTP v\u00eda comandos AT\n           leer GPS\n           publicar\n\nAhora:\nloop()  -> readGPS()\n           updateTime()\n           switch(systemState) {\n             MODEM_INIT, WAIT_NETWORK, GPRS_CONNECT,\n             RUNNING, RECONNECTING\n           }<\/pre>\n\n\n\n
Dicho de otra manera: el firmware antiguo ten\u00eda todav\u00eda bastante de \u201cscript que ha ido creciendo\u201d, mientras que lo que yo buscaba ahora era algo m\u00e1s parecido a un peque\u00f1o sistema embebido con reglas claras. Mismo hardware, mismo prop\u00f3sito, pero otra disciplina.<\/p>\n\n\n\n
La nueva iteraci\u00f3n: robustez por firmware<\/h2>\n\n\n\n
El coraz\u00f3n de la nueva versi\u00f3n es una m\u00e1quina de estados no bloqueante<\/strong>. No es una idea especialmente ex\u00f3tica, pero s\u00ed muy eficaz. En vez de tener un flujo lineal que se detiene durante segundos cuando algo falla, el firmware pasa a organizarse en estados bien definidos: inicializaci\u00f3n del m\u00f3dem, espera de red, conexi\u00f3n GPRS, funcionamiento normal y reconexi\u00f3n. Cada estado hace s\u00f3lo lo que le toca, durante el tiempo imprescindible, y deja al loop()<\/code> volver a iterar enseguida.<\/p>\n\n\n\n
MODEM_INIT \u2192 WAIT_NETWORK \u2192 GPRS_CONNECT \u2192 RUNNING \u2194 RECONNECTING<\/pre>\n\n\n\n
La consecuencia m\u00e1s importante de esta decisi\u00f3n no es est\u00e9tica, sino funcional: el GPS se lee siempre<\/strong>. En la nueva versi\u00f3n, el loop()<\/code> ejecuta primero la lectura del GPS y la actualizaci\u00f3n de la hora, y s\u00f3lo despu\u00e9s entra en la l\u00f3gica de conectividad. Esto significa que incluso cuando el m\u00f3dem est\u00e1 en fase de reconexi\u00f3n o la red m\u00f3vil anda dando guerra, el flujo de datos NMEA sigue siendo atendido. Para un sistema de telemetr\u00eda, esto es casi m\u00e1s importante que cualquier otra cosa.<\/p>\n\n\n\n
Tambi\u00e9n hay una separaci\u00f3n mucho m\u00e1s limpia entre setup()<\/code> y operaci\u00f3n normal. El setup()<\/code> se limita a encender el hardware, inicializar los puertos serie, preparar el Bluetooth para el OBD-II y dejar al sistema en el estado inicial de la m\u00e1quina. Ya no se pone a esperar red ni GPRS ah\u00ed dentro. Parece un detalle menor, pero hace que el arranque sea mucho m\u00e1s determinista y que la l\u00f3gica de recuperaci\u00f3n viva exactamente donde debe vivir: en tiempo de ejecuci\u00f3n.<\/p>\n\n\n\n
La gesti\u00f3n de red gana adem\u00e1s varios mecanismos de autoprotecci\u00f3n. La inicializaci\u00f3n del m\u00f3dem tiene un n\u00famero m\u00e1ximo de reintentos, y si se supera se lanza un hard reset<\/em> f\u00edsico del m\u00f3dulo. La conectividad de red y GPRS se revisa de forma peri\u00f3dica con intervalos separados, MQTT se reconecta con su propia cadencia, y los distintos fallos hacen transicionar el sistema de un estado a otro sin bloquear el resto del funcionamiento. No es exactamente un RTOS, pero para el tipo de problema que tengo entre manos se le parece bastante en esp\u00edritu.<\/p>\n\n\n\n
Hay otro cambio muy importante: la gesti\u00f3n del tiempo<\/strong>. Ahora la prioridad es clara. Si el GPS tiene fecha y hora v\u00e1lidas, se usa esa. Si a\u00fan no hay fix<\/em> temporal, el firmware intenta obtener hora del m\u00f3dem a trav\u00e9s de la red m\u00f3vil. Y si ninguna de las dos fuentes est\u00e1 disponible, el sistema lo deja expl\u00edcitamente indicado. Ese detalle me gusta especialmente porque obliga a tratar la hora no como una certeza binaria, sino como un dato con procedencia: GPS, GSM o ninguna. Para correlacionar muestras, detectar problemas o depurar comportamientos raros, eso vale oro.<\/p>\n\n\n\n
El payload<\/em> MQTT tambi\u00e9n mejora bastante. Ahora cada mensaje puede llevar latitud, longitud, velocidad, altitud, rumbo, RPM, marca temporal y un campo timeSource<\/code> que indica de d\u00f3nde procede la hora. El campo rpm<\/code> sigue ah\u00ed como promesa de futuro \u2014hoy por hoy el OBD-II sigue siendo la pieza d\u00edscola del conjunto\u2014, pero el resto del mensaje es mucho m\u00e1s autocontenido. Adem\u00e1s, la publicaci\u00f3n se limita a una cadencia m\u00e1xima de una muestra cada diez segundos, lo que deja el consumo de datos bajo control y evita ruido innecesario.<\/p>\n\n\n\n
Otro cambio menos vistoso, pero muy agradecido a futuro, es la extracci\u00f3n de la configuraci\u00f3n de hardware a un fichero espec\u00edfico, utilities.h<\/code>. Ah\u00ed quedan definidos pines, niveles de reset y variantes soportadas de placa mediante compilaci\u00f3n condicional. En mi caso la configuraci\u00f3n activa corresponde a la T-A7670<\/strong>, con el m\u00f3dem colgando de Serial1<\/code> y el GPS en Serial2<\/code> por los pines 22 y 21. No es el tipo de mejora que luce en una captura de pantalla, pero s\u00ed de las que evitan sufrimiento futuro cuando uno retoma el proyecto meses despu\u00e9s.<\/p>\n\n\n\n
En cuanto al stack<\/em> software, he seguido una filosof\u00eda bastante espartana: TinyGSM para el m\u00f3dem, PubSubClient para MQTT, TinyGPS++ para parsear NMEA, ArduinoJson para construir el payload y TimeLib para el manejo de tiempo y horario de verano. Nada particularmente ex\u00f3tico. Y esa sencillez, en este contexto, es una virtud.<\/p>\n\n\n\n
Qu\u00e9 mejora realmente frente al c\u00f3digo anterior<\/h2>\n\n\n\n
    \n
  • El GPS no deja de leerse cuando la red m\u00f3vil falla o MQTT se cae.<\/li>\n\n\n\n
  • La l\u00f3gica de conexi\u00f3n queda dividida en estados peque\u00f1os, entendibles y depurables.<\/li>\n\n\n\n
  • La hora deja de depender de un mecanismo NTP artesanal y pasa a tener prioridad GPS con respaldo GSM.<\/li>\n\n\n\n
  • Cada mensaje de telemetr\u00eda viaja con m\u00e1s contexto: altitud, rumbo, timestamp y procedencia temporal.<\/li>\n\n\n\n
  • La reconexi\u00f3n es m\u00e1s resiliente y contempla incluso hard reset<\/em> del m\u00f3dem tras fallos consecutivos.<\/li>\n\n\n\n
  • La configuraci\u00f3n de hardware queda separada del sketch principal y preparada para variantes de placa.<\/li>\n\n\n\n
  • La estructura del proyecto es m\u00e1s mantenible y m\u00e1s amable para futuras iteraciones.<\/li>\n<\/ul>\n\n\n\n
    Lo interesante es que esta mejora no es tanto una cuesti\u00f3n de \u201ctener m\u00e1s cosas\u201d como de hacer mejor las cosas que ya hab\u00eda<\/strong>. Y eso me parece bastante representativo de la madurez de un proyecto. Al principio uno a\u00f1ade sensores, gr\u00e1ficas y par\u00e1metros. M\u00e1s adelante descubre que el verdadero salto de calidad consiste en reducir acoplamientos, quitar bloqueos y dejar de depender del caso feliz.<\/p>\n\n\n\n
    De hecho, la comparaci\u00f3n m\u00e1s justa quiz\u00e1 no sea decir que esta versi\u00f3n es \u201cmejor en todo\u201d, porque no ser\u00eda exacto. La etapa Raspberry Pi era m\u00e1s rica en almacenamiento local y buffering de conectividad gracias al broker MQTT en la propia sonda. La etapa actual, en cambio, gana por goleada en integraci\u00f3n f\u00edsica, autonom\u00eda de comunicaciones y calidad del firmware embebido. Son robusteces distintas: antes la robustez era principalmente de arquitectura distribuida; ahora es, sobre todo, de firmware.<\/p>\n\n\n\n
    Claude Code como asistente de codificaci\u00f3n<\/h2>\n\n\n\n
    Y aqu\u00ed entra la parte novedosa de esta vuelta de tuerca. En esta iteraci\u00f3n he trabajado con Claude Code<\/strong> como asistente de codificaci\u00f3n, y la experiencia me ha resultado bastante m\u00e1s interesante de lo que esperaba. No tanto por la generaci\u00f3n de l\u00edneas de c\u00f3digo en s\u00ed, sino por su utilidad como compa\u00f1ero de refactorizaci\u00f3n: revisar la estructura del sketch, detectar qu\u00e9 partes eran bloqueantes, sugerir una m\u00e1quina de estados m\u00e1s limpia, extraer constantes, ordenar funciones y ayudar a documentar el proyecto de una manera coherente.<\/p>\n\n\n\n
    Dicho de forma menos grandilocuente: no ha venido a descubrirme que el GPS tiene un RX y un TX, ni a hacer magia con un ELM327 caprichoso. Lo que s\u00ed hace bien es acelerar tareas en las que antes uno gastaba bastante tiempo mental: comparar versiones, razonar sobre dependencias, proponer reorganizaciones, encontrar inconsistencias y convertir una mara\u00f1a creciente de c\u00f3digo en algo con m\u00e1s forma de sistema. En proyectos embebidos, eso es much\u00edsimo.<\/p>\n\n\n\n
    Tambi\u00e9n me ha parecido especialmente \u00fatil para el trabajo que casi nunca sale en la foto: la documentaci\u00f3n<\/strong>. Tener un README decente, un fichero de contexto para el asistente, una estructura m\u00e1s clara del proyecto y una descripci\u00f3n formal de la arquitectura no hace el sistema \u201cm\u00e1s r\u00e1pido\u201d, pero s\u00ed hace que sea bastante m\u00e1s f\u00e1cil retomarlo semanas despu\u00e9s sin necesidad de volver a excavarlo todo desde cero.<\/p>\n\n\n\n
    \n
    La IA acelera muy bien la refactorizaci\u00f3n. El hardware, en cambio, sigue teniendo la mala costumbre de exigir pruebas reales.<\/p>\n<\/blockquote>\n\n\n\n
    Porque \u00e9sa es, en realidad, la frontera importante. Un asistente basado en IA puede ayudar much\u00edsimo a reorganizar un firmware, a limpiar la l\u00f3gica y a proponer mejoras razonables. Pero la validaci\u00f3n final sigue estando donde siempre ha estado: en la antena que no coge se\u00f1al, en la SIM que no registra, en el m\u00f3dem que necesita un reset f\u00edsico, en el GPS que tarda en fijar, o en el adaptador OBD-II que decide responder mal precisamente el d\u00eda que uno tiene menos paciencia. Ese mundo sigue siendo muy poco generativo y bastante m\u00e1s obstinado.<\/p>\n\n\n\n
    En cualquier caso, como experiencia de trabajo me ha parecido muy valiosa. Bien utilizado, un asistente de este tipo no sustituye criterio t\u00e9cnico, pero s\u00ed reduce much\u00edsimo la fricci\u00f3n entre \u201cs\u00e9 lo que quiero conseguir\u201d y \u201ctengo el c\u00f3digo organizado para conseguirlo sin pegarme con \u00e9l\u201d.<\/p>\n\n\n\n
    Lo que sigue pendiente<\/h2>\n\n\n\n
    Por supuesto, el proyecto no est\u00e1 cerrado. La gran cuenta pendiente sigue siendo la misma de etapas anteriores: conseguir una integraci\u00f3n OBD-II realmente fiable con el ELM327 y recuperar una telemetr\u00eda de motor m\u00e1s rica. Ah\u00ed es donde me gustar\u00eda volver a acercarme al nivel de detalle que ten\u00eda ya en mente en la \u00e9poca de la Raspberry Pi.<\/p>\n\n\n\n
    M\u00e1s all\u00e1 de eso, el refactor actual deja una base bastante m\u00e1s s\u00f3lida para seguir creciendo. A partir de aqu\u00ed tendr\u00eda sentido explorar almacenamiento local ligero para escenarios de p\u00e9rdida prolongada de cobertura, volver sobre la vieja idea de sensores adicionales, o aprovechar mejor la instrumentaci\u00f3n que ya ofrece la placa. Pero, honestamente, antes de a\u00f1adir m\u00e1s capas prefiero consolidar \u00e9sta. La experiencia me dice que un sistema de telemetr\u00eda vale bastante m\u00e1s por la fiabilidad de sus datos que por la longitud de su lista de campos.<\/p>\n\n\n\n
    Lo aprendido<\/h2>\n\n\n\n
    En el fondo, lo que m\u00e1s me gusta de este proyecto es que lleva casi una d\u00e9cada ense\u00f1\u00e1ndome cosas distintas sin dejar de ser, esencialmente, el mismo juguete. Primero me ense\u00f1\u00f3 MQTT, persistencia y visualizaci\u00f3n de m\u00e9tricas. Despu\u00e9s me llev\u00f3 a integrar GPS, telefon\u00eda m\u00f3vil y electr\u00f3nica en una sola placa. Ahora me ha obligado a pensar mejor el firmware, y de paso me ha servido para comprobar hasta qu\u00e9 punto un asistente basado en IA puede aportar valor real en un desarrollo t\u00e9cnico de este tipo.<\/p>\n\n\n\n
    Si algo deja claro esta nueva evoluci\u00f3n es que avanzar no siempre significa a\u00f1adir m\u00e1s sensores, m\u00e1s gr\u00e1ficos o m\u00e1s siglas. A veces avanzar consiste en quitar bloqueos, separar responsabilidades, dejar clara la procedencia de la hora y asumir que un sistema embebido serio se parece menos a un script apa\u00f1ado y m\u00e1s a una peque\u00f1a m\u00e1quina de estados con muy pocas excusas para hacer las cosas mal.<\/p>\n\n\n\n
    Mucho menos vistoso, probablemente. Pero bastante m\u00e1s \u00fatil.<\/p>\n\n\n\n
    Y s\u00ed: el OBD-II sigue tocando las narices. Pero, bien mirado, eso ya forma parte de la tradici\u00f3n.<\/p>\n","protected":false},"excerpt":{"rendered":"
    All\u00e1 por finales de 2016, cuando a\u00fan viv\u00edamos por Irlanda,<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"advanced_seo_description":"","jetpack_seo_html_title":"","jetpack_seo_noindex":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[1845,13],"tags":[133,1959,1963,745,1962,1134,1184,1361,1381,1606],"series":[],"class_list":["post-11740","post","type-post","status-publish","format-standard","hentry","category-generado-con-ia","category-informatica","tag-arduino","tag-claude-code","tag-elm327","tag-gps","tag-gsm","tag-mqtt","tag-obd-ii","tag-python","tag-raspberry-pi","tag-telemetria"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/bitacora.eniac2000.com\/index.php?rest_route=\/wp\/v2\/posts\/11740","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/bitacora.eniac2000.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/bitacora.eniac2000.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/bitacora.eniac2000.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/bitacora.eniac2000.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=11740"}],"version-history":[{"count":1,"href":"https:\/\/bitacora.eniac2000.com\/index.php?rest_route=\/wp\/v2\/posts\/11740\/revisions"}],"predecessor-version":[{"id":11742,"href":"https:\/\/bitacora.eniac2000.com\/index.php?rest_route=\/wp\/v2\/posts\/11740\/revisions\/11742"}],"wp:attachment":[{"href":"https:\/\/bitacora.eniac2000.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=11740"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/bitacora.eniac2000.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=11740"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/bitacora.eniac2000.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=11740"},{"taxonomy":"series","embeddable":true,"href":"https:\/\/bitacora.eniac2000.com\/index.php?rest_route=%2Fwp%2Fv2%2Fseries&post=11740"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}