Monitor de conectividad IOT — Guía operativa

Qué es y para qué sirve 

Cada periférico de un hotel no habla directamente con el SAAS. La señal atraviesa cuatro tramos: el servicio web en la nube, la Raspberry del hotel, y por fin el aparato. Si algo no funciona, hasta ahora había que adivinar en cuál de esos tramos estaba el problema. El Monitor IOT comprueba cada tramo por separado y te dice, con un semáforo, en cuál falla — sin desplazarte al hotel y sin tocar el aparato.

La cadena de conexión

El panel de control

IoT ▸ Monitor ▸ Panel de control 

Una columna por estado. De un vistazo se ve qué Raspberries están En línea (verde), Degradadas (ámbar: llega pero algo va justo, p. ej. disco lleno o CPU caliente) o Caídas (rojo). Cada tarjeta muestra el estado del Web Service, la versión del agente y CPU/disco, con un botón Comprobar para relanzar la comprobación al momento.

Probar un periférico de punta a punta

Abre la ficha del periférico (lector, cerradura…). En la cabecera hay tres botones: 

• Probar de punta a punta — recorre toda la cadena A→B→C y dice dónde falla. 
• Probar periférico — solo el último tramo (asume que la nube y la Pi van). 
• Escanear red — busca la IP del aparato en la red del hotel (capa D). 

El badge verde Responde indica que el aparato saludó correctamente.

Cómo decide el test punta a punta 

Para no hacerte esperar, se detiene en el primer tramo que falla y marca los siguientes como No alcanzado (no tiene sentido probar el aparato si la nube ya está caída):

El resultado sale como una escalera (estilo traceroute): una fila por tramo, con semáforo, latencia y motivo. En el ejemplo, la nube no responde, así que la cadena aparece ROTA y los tramos de abajo quedan No alcanzado — señal clara de que el problema está en el Web Service, no en el aparato

El gráfico de red (histórico de latencias)

IoT ▸ Monitor ▸ Histórico y gráfico 

Cada comprobación queda registrada. El gráfico de líneas muestra la latencia en el tiempo, una línea por capa (Web Service, Raspberry, Periférico) — el clásico "gráfico de red". Sirve para ver tendencias: si una capa se va degradando poco a poco, se nota antes de que caiga del todo. Con los filtros Última hora / Últimas 24 h y el agrupado por capa o dispositivo se acota lo que quieras mirar.

Cómo interpretar un fallo

Avisos automáticos

No hace falta tener el monitor abierto. Cuando una operación real contra un periférico falla (un check-in que no lee el documento, una cerradura que no graba…), el sistema avisa solo: 

• Campana (notificación fija) a los usuarios del grupo de alertas IOT. 
• Actividad "to-do" en la ficha de la Raspberry afectada. 

Además marca la Pi como Caída al instante. Para no saturar, agrupa: un aviso por dispositivo y tramo cada N minutos (configurable, 10 por defecto).

¿Las comprobaciones son genéricas o específicas por fabricante?

Las capas A, B y D son genéricas — funcionan igual para todo el parque, sin saber qué fabricante hay detrás. La especialización por fabricante está solo en la capa C, y solo en el "saludo profundo":

¿Y si instalamos un fabricante o tipo de periférico nuevo?

Aparece solo, sin configurar nada. El monitor descubre automáticamente cualquier periférico nuevo (cerraduras, TPV, fichaje, etc.) en cuanto se instala su módulo: los botones de diagnóstico y el seguimiento salen sin tocar el monitor. Si ese fabricante necesita un "saludo profundo" propio, se añade en su sitio; si no, funciona igual con la comprobación genérica de puerto.

Leyenda de estados