Instalación en planta¶
Responde: ¿qué hace falta para poner una Raspberry Pi a entregar datos, y en qué orden?
Esta página no es el runbook
El procedimiento paso a paso —comandos, variables, verificación— vive en el repositorio del
empaquetado, en docs/pi.md,
y es la fuente de verdad. No se copia acá: un runbook duplicado se desincroniza, y este
repositorio existe porque eso ya pasó.
Lo que va acá es lo que ese runbook no puede contener: lo que hay que conseguir antes de tocar la Pi, de quién, y qué tiene que ser verdad en la nube para que la instalación funcione. Son los dos lados de una frontera que ningún repositorio ve completa.
Antes de ir a la planta¶
Cuatro cosas, y dos vienen de otra persona.
| Qué | De dónde sale |
|---|---|
| Dispositivo registrado en el Cloud, con su identificador de máquina | Lo hace quien administre el tenant: alta de un dispositivo Edge |
| Clave de API del dispositivo | Misma alta. Se muestra una sola vez |
| URL del Cloud | El operador del Cloud |
| Los tres repositorios clonados en la Pi, lado a lado | Ver abajo |
El identificador de máquina tiene que ser idéntico en los dos lados
Es el error más costoso de una instalación y el más difícil de detectar, porque todo parece funcionar: el Edge reporta sano, el outbox drena, y el dashboard nunca muestra un dato. Los datos de ese período se pierden definitivamente.
El valor que se configura en la Pi tiene que coincidir carácter por carácter con el registrado en el Cloud. Copiar y pegar, no transcribir.
El detalle de por qué falla así está en alta de un dispositivo Edge, y cómo diagnosticarlo en troubleshooting.
Los tres repositorios, lado a lado¶
El empaquetado construye las imágenes desde el código fuente y usa rutas relativas, así que la disposición en disco no es una preferencia: es un requisito.
~/embolsadora/
├── proyecto-embolsadora/ # historian + el catálogo de variables
├── embolsadora-edge/
└── embolsadora-bundle/ # desde acá se corre todo
Dos consecuencias que conviene saber antes y no durante:
- El primer build es lento en una Pi: compila el Edge en Go y el historian con herramientas de compilación.
- No hay versión desplegada identificable. Lo que queda corriendo es "lo que había en esas ramas el día que se hizo el clon". Ver despliegues.
Las decisiones que hay que tomar al configurar¶
El runbook explica cada variable. Lo que no puede decir es cuál conviene, porque depende del despliegue. Las cuatro que importan:
| Decisión | Recomendación |
|---|---|
| ¿PLC real o simulado? | El valor por defecto del empaquetado es simulado. Una instalación real tiene que apuntar a la IP del PLC, y conviene arrancar con el simulado para validar el resto de la cadena primero |
| ¿En qué interfaces se publica? | Por defecto, en todas. Si nada fuera de la Pi necesita esos puertos, restringirlo a la interfaz local. Ver la advertencia de abajo |
| ¿Secreto de cabecera entrante? | Opcional y vacío por defecto. Hoy el Cloud no lo envía, así que activarlo rompe los chequeos de estado: ver SYS-ADR-005 |
| ¿Se activa el servidor AAS? | No, en una instalación de planta. Ver la advertencia de abajo |
Dos advertencias de configuración con consecuencia real
Sobre la exposición en red. Con la configuración por defecto, los servicios de la Pi quedan publicados en todas sus interfaces, y el endpoint de métricas del Edge no exige credencial ni siquiera cuando se activa el secreto de cabecera. El modelo asume una red privada que no está configurada en ningún repositorio: ver seguridad. Si la red de la planta no aísla la Pi, nadie lo hace.
Sobre el servidor AAS. Activar ese complemento hace que el historian reescriba el
archivo completo del modelo en cada ciclo de lectura: del orden de 47 GB de escrituras por
día sobre la tarjeta de memoria de la Pi. Es un problema de vida útil del hardware, no de
rendimiento. Ver SYS-ADR-008.
Qué tiene que ser verdad para decir que funcionó¶
El runbook tiene su propio checklist de aceptación, y hay que pasarlo. Pero el checklist del runbook solo ve la Pi. La instalación está completa cuando se cumple también lo que se ve del otro lado:
| Dónde se mira | Qué tiene que pasar |
|---|---|
| En la Pi | El script de verificación del runbook termina bien |
| En la Pi | El estado del Edge reporta que alcanza al Cloud, y el tamaño del outbox baja |
| En el Cloud | El dispositivo registra actividad reciente |
| En el dashboard | Un widget de los que consumen una métrica real muestra datos |
Los dos últimos son los que importan, y son los que ningún repositorio verifica. Que el outbox baje no alcanza: también baja cuando el Cloud está descartando todo.
Dejar andando el PLC simulado primero
Validar la cadena completa —hasta ver un dato en el dashboard— con el PLC simulado, y recién después apuntar al PLC real. Así, si al cambiar deja de haber datos, el problema está acotado al tramo Modbus y no a los otros seis de la cadena.
Qué esperar en la primera instalación¶
El stack nunca corrió en una Raspberry Pi
Se probó en amd64, en una máquina de escritorio: no en arm64, ni en una Raspberry Pi, ni contra un Cloud real. La primera instalación en planta es también la primera prueba de la plataforma sobre el hardware definitivo.
El checklist de aceptación de más arriba existe para cubrir ese hueco. Conviene hacer la instalación con tiempo, y no el día de la puesta en marcha en el cliente.
Lo que este runbook todavía no cubre: qué pasa si se corta la energía a mitad de una escritura, cuánto dura la tarjeta de memoria con el volumen de escritura normal, y cómo recuperar una Pi que no arranca. Además, el bucket de la base local no tiene retención configurada, así que crece hasta llenar el disco.
Relacionado¶
- Alta de un dispositivo Edge — el paso previo
- Troubleshooting — qué hacer cuando no aparecen datos
- Flujo de datos — qué pasa entre el PLC y el widget