Cuando falla la red, ¿qué trabajo debe continuar?
Un invernadero remoto recoge medidas ambientales y las envía a un servicio que señala condiciones anómalas. Si Internet desaparece durante doce horas, el problema no es solo mostrar un error: hay que decidir si seguir midiendo, guardar el historial y ofrecer una indicación local. Lo mismo ocurre con equipos de conectividad intermitente. Este análisis ayuda a elegir entre servicio remoto, dispositivo local y arquitectura híbrida: qué dependencias quitar del trabajo esencial, cuánto almacenamiento reservar y cómo recuperar datos sin confundir pasado y presente.
La respuesta no es «mover toda la IA a la placa». Hay que separar funciones inmediatas, archivo y análisis aplazable. Una simulación ejecutada muestra que doce horas de datos pueden necesitar poco espacio y aun así perderse parcialmente si se dimensiona mal; recuperar la red tampoco vacía de inmediato el atraso. No probamos sensores, firmware, modelos, flash ni protocolos reales. El caso es hipotético, los cálculos reproducibles y el rendimiento de cualquier dispositivo queda por medir. No es un diseño de control automático del invernadero ni una prueba agronómica.
Separar una decisión útil de una conexión disponible
El recorrido mínimo adquiere una medida, valida formato y calidad, aplica la función local elegida e informa claramente del estado. Un umbral explícito puede bastar para una alerta sencilla; un modelo necesita requisitos adicionales y evidencia de beneficio. La IA local también requiere preprocesamiento, parámetros, datos auxiliares y entorno de ejecución: descargar pesos no elimina llamadas remotas ocultas. Una comprobación concreta desconecta la red en pruebas y registra qué dependencias bloquean la función, sin inferir éxito solo del diagrama.
La función local no debe fingir normalidad si falla el sensor o faltan actualizaciones necesarias. Distinguir medida válida, datos insuficientes, modelo no disponible y conexión ausente permite entender el límite. La salida local hipotética es una indicación, no una orden a una bomba: los actuadores necesitan restricciones y verificaciones propias. Análisis aplazables, como comparar históricos de varios invernaderos, pueden quedarse en el servidor. El límite depende del trabajo que debe continuar, no de preferir nube o embedded.
¿Cuánta memoria hace falta para doce horas sin red?
Antes de elegir placa, definir el contrato del dato. Suponemos un registro cada diez segundos y 64 bytes serializados por registro, incluidos identificador, tiempo, valor y estado. Es un tamaño hipotético, no el de un objeto Python, paquete de red o página de base de datos. Integridad y metadatos adicionales deben contarse en la serialización real. Diez segundos no es una recomendación de muestreo agronómico: explicita la relación entre frecuencia y espacio.
La fórmula responde «¿cuántos registros llegan durante la interrupción?». lambda son registros por segundo, D segundos de interrupción y b bytes por registro. B son registros que conservar y S su almacenamiento. El intervalo incluye el inicio y excluye el final: muestras en 0, 10, …, 43190 segundos. Hay que distinguir unidades decimales y binarias: un KiB equivale a 1024 bytes.
Un área de 256 KiB solo contiene 4096 registros de 64 bytes. Es menor que los 270 KiB necesarios, aunque parezcan próximos. Conservar lo reciente eliminando lo antiguo implica que al acabar doce horas ya faltan 224 registros. Protege el presente y pierde historia; no es automáticamente mejor que rechazar datos nuevos. Si interesa reconstruir un suceso inicial, esos registros pueden importar más. La política de desbordamiento debe depender del uso del historial.
270 KiB es solo el contenido del atraso, no el requisito completo de la plataforma. Separar pesos del modelo, activaciones y pico RAM, buffers del protocolo, índice y almacenamiento persistente. La memoria libre nominal también puede contener áreas reservadas o exigir borrado por bloques. El cálculo no demuestra que una placa concreta ejecute la aplicación. Primero se reserva un presupuesto explícito y luego se verifica con formato, firmware y soporte reales.
Vuelve la red: por qué el historial sigue sin sincronizarse
Supongamos que el servidor acepta establemente dos registros útiles por segundo. Es capacidad hipotética, no rendimiento medido de radio ni bits por segundo del enlace. Debe incluir el cuello de botella hasta el resultado útil; reintentos y esperas pueden reducirla. La adquisición sigue produciendo 0,1 registros por segundo. El atraso baja a la diferencia entre salida y entrada, no solo a la salida. Es como vaciar un recipiente mientras un grifo lo llena: la analogía explica el balance, no fallos ni paquetes.
El cálculo continuo da unos 37,9 minutos, no los 36 de dividir por dos. Requiere mu mayor que lambda: si son iguales el atraso previo no baja; si la salida es menor sigue creciendo. Supone tasas constantes, servicio disponible de inmediato y ninguna nueva interrupción. Ráfagas o pausas de reconexión requieren un modelo temporal más rico. Hay que reservar capacidad para recuperar historial además del flujo normal: una conexión apenas suficiente en operación normal puede no recuperarse nunca de un fallo.
La simulación: tres capacidades, los mismos eventos
Para comprobar la fórmula usamos eventos discretos: llegadas y salidas en instantes definidos. Cada paso vale medio segundo. Se crea un registro numerado al inicio y cada veinte pasos. La red no retira nada hasta el paso 86400, doce horas; la primera finalización ocurre medio segundo después. Luego finaliza un envío por paso hasta que la cola se vacía por primera vez. Si coinciden llegada y salida, insertamos primero. Con buffer lleno eliminamos el más antiguo. No hay azar ni semilla.
Con 8192 plazas la cola alcanza 4321 registros, no 4320: llega otra muestra al volver la red, antes del primer envío. Se vacía por primera vez 2274 segundos después, 37 minutos y 54 segundos, coherente con la aproximación continua. Se han generado y subido 4548 registros: 4320 del corte y 228 nuevos. Subir más que el atraso inicial no es duplicación: la adquisición continuó durante la recuperación. El modelo termina ahí, no al final de la jornada.
| Plazas | Espacio (KiB) | Perdidos | Generados | Subidos | Recuperación (s) |
|---|---|---|---|---|---|
| 1024 | 64.0 | 3297 | 4374 | 1077 | 538.5 |
| 4096 | 256.0 | 225 | 4536 | 4311 | 2155.5 |
| 8192 | 512.0 | 0 | 4548 | 4548 | 2274.0 |
Con 4096 plazas se pierden 225 registros: 224 durante el corte y uno expulsado al reconectar antes de la primera finalización. Recuperar lleva 2155,5 segundos, menos que sin pérdidas. Con 1024 plazas termina antes aún, en 538,5 segundos, pero faltan 3297 registros. «Sincronización más rápida» puede ocultar datos eliminados. La tabla incluye generados y subidos: cada ejecución dura distinto porque termina al vaciarse por primera vez; no son ventanas iguales para comparar producción total.
Los tramos planos de las colas pequeñas no significan que el sensor deje de producir: cada llegada expulsa datos antiguos. Tras doce horas las curvas bajan; solo la mayor capacidad conserva todo con este protocolo. Los ejes son tiempo simulado y número de registros, no RAM ni red medidas. La capacidad serializada no es memoria del proceso Python: deque contiene objetos y metadatos extra, que no representan medidas de una placa.
Datos guardados y mensajes recibidos son garantías distintas
OASIS MQTT 5.0, estándar del 7 de marzo de 2019, distingue niveles de entrega. QoS 1 puede generar duplicados; una confirmación de protocolo no implica que la aplicación final termine su trabajo. Son propiedades del protocolo, no resultados de una prueba MQTT propia.
Proponemos una identidad aplicativa estable por registro: dispositivo, época de arranque y contador persistido coherentemente. El servidor puede guardarla con unicidad, evitando una segunda fila al reintentar. Hay que probar la pérdida de respuesta después de escribir. Un contador que vuelve a cero puede identificar dos muestras distintas como iguales. La eliminación local debe indicar qué confirmación permite liberar espacio; «el paquete salió» no confirma su archivo.
La documentación de atomic commit de SQLite explica que, ante cortes eléctricos, también importan las hipótesis del soporte y del flush. Rollback y WAL usan mecanismos distintos. No probamos SQLite ni interrupciones eléctricas.
La cola solo vive en el proceso simulado. No prueba supervivencia a reinicios, integridad flash ni escritura atómica. El diseño real debe distinguir adquirido, persistido, enviado y confirmado; reiniciar debe reconstruir estado sin borrar datos pendientes. Bases de datos y logs son alternativas según recursos, no eslóganes intercambiables. Microcontrolador y embedded Linux pueden necesitar estrategias distintas. La comprobación decisiva corta alimentación y comunicación en puntos controlados, con datos no operativos y protocolo apropiado.
El historial no debe mandar sobre el presente
Reconectar lleva al servidor medidas antiguas. Cada registro debe conservar tiempo de adquisición separado del de recepción, calidad y versión de función local. De lo contrario, doce horas subidas en minutos pueden parecer un fenómeno reciente. Separar recuperación histórica y decisiones actuales. No repetir comandos antiguos como solicitudes nuevas: alertas y acciones pueden caducar. No diseñamos control seguro de actuadores; separamos usos con requisitos diferentes.
Qué verificar antes de elegir plataforma
Las alternativas ya son concretas. Solo nube facilita actualizar análisis central, pero depende de la red; una cola remota no conserva lo nunca enviado. Solo local puede ser autónomo, pero quedan actualizaciones, recursos y mantenimiento. Híbrido: una función mínima usa datos locales y archiva registros; el servidor añade análisis aplazable. Una regla sin IA puede bastar. La simulación compara colas, no calidad diagnóstica ni conveniencia económica de las arquitecturas.
La decisión requiere probar el dispositivo elegido con formato y versiones declarados: pico RAM separado de pesos, espacio disponible y sobrecarga de archivo; latencia media, percentiles y plazo de función local durante sincronización; potencia en vatios y energía por inferencia o decisión útil en julios, separando adquisición y radio. Un corte mayor que el presupuesto prueba saturación. Repetir tras actualizar y reiniciar prueba continuidad. Son experimentos propuestos sin resultados, no medidas implícitas de la placa fotografiada.
Leer el código y responder la pregunta inicial
simulate usa deque como contenedor ordenado, genera identificadores crecientes y elimina el más antiguo al llenarse. Retirar significa finalización supuesta, no paquete MQTT ni confirmación de base de datos. Las aserciones imponen conservación de cantidades y conjuntos perdidos/subidos disjuntos; verifican 225 pérdidas y 2274 segundos de recuperación sin pérdidas. No duplicar es propiedad de la simulación, no garantía de red. Los pasos determinan el trabajo computacional; memoria Python y duración no son benchmarks embedded.
La conclusión operativa es dejar en el dispositivo lo necesario para una indicación local válida y declarar límites; presupuestar datos y estado; prever recuperación superior al flujo normal. Aquí 256 KiB no cubren doce horas, y una cola pequeña se vacía antes porque perdió datos. Capacidad de 8192 evita pérdidas en el modelo, pero no demuestra resistencia eléctrica ni idoneidad de producto. La arquitectura tiene justificación; elegir placa y modelo requiere pruebas pendientes. No anunciamos productos ni instalaciones embedded EL-AI.
Fuentes y código reproducible
OASIS — MQTT 5.0, 7 March 2019; sections 4.3–4.6.
SQLite — Atomic Commit; storage assumptions and sections 8–9.
import json,sys
from collections import deque
from pathlib import Path
# One tick is 0.5 seconds. New sample precedes completion at coincident events.
OUTAGE_TICKS=86400
RECORD_BYTES=64
def simulate(capacity):
q=deque();lost=[];uploaded=[];maxq=0;trace=[];generated=0;end=None
for tick in range(120001):
if tick%20==0:
if len(q)>=capacity:lost.append(q.popleft())
q.append(generated);generated+=1;maxq=max(maxq,len(q))
if tick>OUTAGE_TICKS and q:uploaded.append(q.popleft())
if tick%120==0:trace.append([tick/2,len(q)])
if tick>OUTAGE_TICKS and not q:end=tick/2;break
trace.append([end,0])
assert generated==len(lost)+len(uploaded)+len(q)
assert not(set(lost)&set(uploaded)) and len(uploaded)==len(set(uploaded))
return dict(capacityRecords=capacity,capacityBytes=capacity*RECORD_BYTES,lost=len(lost),uploaded=len(uploaded),generated=generated,maxQueue=maxq,drainSeconds=end-OUTAGE_TICKS/2,trace=trace)
runs=[simulate(c) for c in [1024,4096,8192]]
assert runs[2]['lost']==0 and runs[2]['drainSeconds']==2274 and runs[2]['maxQueue']==4321
assert runs[1]['lost']==225
assert abs(4320/(2-.1)-2273.684210526316)<1e-9
assert 4096*64==262144 and 4320*64==276480
result=dict(python=sys.version.split()[0],seed=None,scope='Discrete deterministic buffer simulation only; no sensor, model, MQTT client, flash or device tested',samplePeriodSeconds=10,assumedRecordBytes=64,outageSeconds=43200,assumedServiceRecordsPerSecond=2,fluidApproxDrainSeconds=4320/(2-.1),runs=runs)
Path(__file__).with_name('results.json').write_text(json.dumps(result,indent=2),encoding='utf8')
print(json.dumps([{k:v for k,v in x.items() if k!='trace'} for x in runs]))
Código, datos e instrucciones · JSON. Cálculos didácticos ejecutados con Python 3.14.0; figuras con Matplotlib 3.11.2. Análisis asistido por IA, sin afirmar revisión por pares ni humana. Portada original ImageGen ilustrativa: no documenta personas, sedes ni instalaciones de EL-AI. Fuentes consultadas el 27 de octubre de 2026.