InfluxDB 3 en cooperativas: medidores, tokens y copia
Caso anonimizado para ordenar lecturas de medidores con InfluxDB 3, tokens, consultas, retención, copia y prueba de restauración en internet rural.
Antes, la guardia copiaba lecturas de medidores en una planilla; después, cada dato tuvo origen, token y copia probada. En una cooperativa eléctrica con internet rural, el cambio empezó por una pregunta chica: qué lectura sirve para facturar, reclamar o revisar una caída. InfluxDB 3 permite guardar series temporales y consultar mediciones por tiempo. Este caso muestra el flujo mínimo y la prueba de salida. ## Dónde aparece la lectura sin dueño InfluxDB publicó v3.11.4 el 8 de septiembre de 2026. La nota de versión menciona correcciones sobre escrituras repetidas con la misma serie y timestamp, para que el último valor confirmado gane en consultas y archivos persistidos. En medidores, esa diferencia define qué lectura se mira cuando un equipo reenvía datos. La cifra que ubica el caso viene de Stack Overflow 2026: PostgreSQL registra 57,9 % de uso entre quienes respondieron sobre bases de datos en el reporte de tecnología. En este tipo de proyecto, PostgreSQL puede guardar clientes, activos y órdenes; InfluxDB guarda mediciones. Separar esos mundos evita mezclar una serie de amperaje con el padrón comercial. El antagonista es el CSV de madrugada: llega por correo, se copia a mano y nadie prueba si perdió filas. El detalle concreto es un medidor con tapa rayada y número legible a medias. Si ese número no coincide con el id del dispositivo, la serie queda huérfana.
Cómo funciona por dentro
El flujo sano tiene seis pasos. Primero, el medidor o gateway envía lectura, timestamp, id y unidad. Segundo, una API valida formato, rango y permiso de escritura. Tercero, InfluxDB 3 guarda la medición en una base de series temporales. Cuarto, PostgreSQL 17 guarda activo, ubicación, cliente, responsable y auditoría de cambios. Quinto, Grafana o una consulta SQL muestra lectura, huecos y máximos por período. Sexto, el backup copia metadatos, base administrativa y almacenamiento de InfluxDB, y una restauración abre una semana real. La documentación de write data ubica la entrada: mediciones con tiempo, etiquetas y campos. La guía de query data explica cómo leer series por consulta. La página de tokens separa credenciales para escribir, consultar y administrar. El permiso de un gateway debe escribir solo su base y nada más. La sección de databases ordena dónde viven las bases. La guía de backup y restore fija la prueba que muchas organizaciones saltean: copiar, restaurar y consultar. El límite aparece cuando una medición sirve para dos cosas distintas. Operaciones necesita saber si un enlace cayó; administración necesita defender un período de facturación. La serie temporal responde tiempo y valor. El registro administrativo responde activo, domicilio, reclamo y responsable. Mezclarlos vuelve lenta la consulta y débil la prueba.
Qué se instala o configura primero
El primer entregable verificable es una semana de lecturas de diez medidores: id, ubicación, timestamp, tensión, corriente, energía, estado de comunicación y origen. El tablero muestra medidores mudos, lecturas fuera de rango y último dato recibido. La pila mínima usa InfluxDB 3.11.4, PostgreSQL 17, un colector MQTT o HTTP, Grafana, tokens por gateway, copia externa y un script de restauración. El costo mensual de un piloto ronda USD 50 a USD 120 para servidor, disco, copia y monitoreo. Con dólar oficial vendedor a ARS 1535 informado por DolarAPI, queda entre ARS 76.750 y ARS 184.200, sin medidores ni enlaces de campo. UMSA puede entrar cuando la cooperativa ya listó activos, ubicaciones y responsables. El primer valor no está en graficar todo; está en demostrar que una lectura tiene dueño, permiso, rango y copia. La implementación útil empieza con una ruta: gateway escribe, API valida, InfluxDB guarda serie, PostgreSQL guarda activo y Grafana muestra hueco. Si esa ruta se restaura, recién conviene sumar más medidores. La retención se define por uso. Lecturas de diagnóstico pueden vivir semanas; cierres de facturación necesitan meses o años según política interna y obligación contractual. Esa decisión debe quedar escrita antes de borrar datos viejos.
Dónde se rompe y cómo probarlo
El primer riesgo aparece en timestamps duplicados. La señal es un medidor que manda dos valores para el mismo instante. La prueba reenvía una lectura corregida y confirma qué valor queda al consultar. El segundo riesgo vive en tokens compartidos. La señal es que un gateway puede escribir datos de otro. La prueba crea dos tokens, cruza escrituras y exige rechazo. El tercer riesgo aparece en retención mal escrita. La señal es una consulta mensual que devuelve huecos donde había datos diarios. La prueba carga treinta días, ejecuta consulta de cierre y compara conteo esperado. El cuarto riesgo es restaurar series sin activos. La señal es una medición válida con id desconocido. La prueba restaura InfluxDB y PostgreSQL juntos, abre diez medidores y revisa ubicación, responsable y última lectura. La pregunta que cierra el caso no mira el gráfico: ¿qué lectura puede defender la cooperativa cuando llega un reclamo?
