La verdadera magia de NUT (Network UPS Tools) reside en su arquitectura Maestro-Esclavo. En esta guía, vamos a configurar nuestra infraestructura para que la Raspberry Pi Zero actúe como el «cerebro» central (Master). Ella será la encargada de monitorizar el USB del SAI y, en caso de batería baja, enviará una orden de apagado por red a todos los demás equipos (Slaves) de tu hogar.

Al finalizar esta configuración, habrás creado una red de seguridad inteligente donde:

• La comunicación es total: Tus PCs con Windows y Linux «escucharán» a la pequeña Pi Zero.
• El apagado es elegante: Cada equipo cerrará sus procesos y protegerá sus discos antes de que el SAI corte la energía.
• Tú mantienes el control: Seguirás recibiendo los reportes detallados en Telegram mientras tus equipos se ponen a salvo automáticamente.

Prepárate para convertir tu modesta Raspberry Pi Zero en el guardián de toda la electrónica de tu despacho. ¡Vamos a ello!

1. Configuración en la Raspberry Pi Zero (El Maestro)

Para expandir tu red de protección y que tu Raspberry Pi 5 y tus otros PCs (i7, i5) se apaguen de forma coordinada, vamos a configurar una arquitectura Maestro-Esclavo (o Primario-Secundario).

Tu Pi Zero seguirá siendo el «Cerebro» (Master) porque tiene el cable USB, y los demás serán «Clientes» (Slaves) que escuchan por red.

Primero debemos autorizar a la Pi Zero a hablar con el resto de la casa.

A. Abrir la escucha de red

Edita el archivo de configuración del servidor:

sudo nano /etc/nut/upsd.conf

Sustituye tus líneas LISTEN por esta (es la más compatible):

LISTEN 0.0.0.0 3493

Esto permite que la Pi Zero responda tanto a su propio script de Telegram como a los PCs externos.

B. Crear el usuario para los esclavos

Edita el archivo de usuarios:

sudo nano /etc/nut/upsd.users

Añade este perfil al final (usa una contraseña distinta a la de admin):

[remotemon]
    password = clave_red_segura
    upsmon slave

Reinicia los servicios para aplicar los cambios:

sudo systemctl restart nut-server nut-monitor

2. Configuración en la Raspberry Pi 5 y PCs con Linux (Esclavos)

En cada equipo Linux que quieras proteger (Pi 5, i7 con Ubuntu/Debian, etc.), sigue estos pasos:

A. Instalación mínima

Solo necesitas el cliente, no el servidor completo:

sudo apt update && sudo apt install nut-client -y

B. Configurar el modo red

Edita el archivo de modo:

sudo nano /etc/nut/nut.conf

Cambia la línea a:

MODE=netclient

C. Vincularse al Maestro

Edita el monitor:

sudo nano /etc/nut/upsmon.conf

Añade esta línea al final (sustituye 192.168.1.14 por la IP real de tu Pi Zero):

MONITOR salicru@192.168.1.14 1 remotemon clave_red_segura slave

Reinicia el monitor en el esclavo:

sudo systemctl restart nut-monitor

3. Configuración en PCs con Windows (i7 / i5)

Si alguno de tus PCs usa Windows, no necesitas scripts complejos:

1. Descarga e instala WinNUT-Client.
2. Configura la conexión:
   • UPS Name: salicru
   • UPS Host: 192.168.1.14 (IP de la Pi Zero)
   • Port: 3493
   • Username: esclavo
   • Password: clave_red_segura
3. Calibración: En la pestaña «Shutdown», elige cuánto tiempo quieres que pase desde que se corta la luz hasta que el PC se apague.

¿Cómo funcionará el apagado en cadena?

Es importante entender la jerarquía para que nadie pierda datos:

1. Corte de luz: La Pi Zero avisa por Telegram al instante.
2. Batería Baja: Cuando la Pi Zero detecta que queda poca energía, envía la señal de «Pánico» por red a los demás equipos
3. Apagado de Esclavos: El resto de equipos reciben la orden y se apagan de inmediato para proteger sus discos.
4. Apagado del Maestro: La Pi Zero espera a que los esclavos se desconecten. Una vez sola, inicia su propio apagado.
5. Corte Total: En el último segundo, la Pi Zero le dice al Salicru: «Apágate en 30 segundos».

Recuerda poner una IP fija a tu Raspberry pi zero

En este artículo, vamos a configurar un sistema de alertas avanzado utilizando una Raspberry Pi y el software NUT (Network UPS Tools) para convertir un SAI Salicru convencional en un dispositivo inteligente y conectado.

El objetivo es automatizar el control total de nuestra energía mediante un Bot de Telegram que nos mantendrá informados con mensajes detallados y visuales. Al finalizar este tutorial, tu sistema será capaz de:

• Notificar cortes y restablecimientos de corriente de forma instantánea.
• Enviar reportes detallados con voltajes de entrada, salida y estado de la batería.
• Gestionar estados críticos como el nivel de batería bajo o la necesidad de sustitución de celdas (REPLBATT).
• Proteger tu hardware, avisándote justo antes de que la Raspberry Pi realice un apagado controlado para evitar daños en la tarjeta SD.

Todo esto mediante un script optimizado que garantiza que la información que recibes en tu móvil es veraz y estable, permitiéndote tomar decisiones informadas estés donde estés.

Sistema

Como sistema operativo voy utilizar Rasbperry Pi OS lite 64bits, basado en Debian 13. El usuario del sistema será nut y el host será zero.

Materiales necesarios

• RASPBERRY PI ZERO 2W – 2WH (Versión: W (WiFi))
• Un SAI Salicru con puerto USB (Serie SOHO+ o similar).
• CABLE OTG MICROUSB/M USB-A/H NEGRO
• ALIMENTADOR OFICIAL RASPBERRY PI MICRO-USB 5,1V 2,5A 12,75W
• CAJA OFICIAL RASPBERRY PI ZERO
• CABLE USB-A A USB-B M/M AZUL 30CM

Instalación de NUT

Actualizamos la lista de repositorios e instalamos los paquetes oportunos.

sudo apt update && sudo apt install nut nut-client nut-server curl bc -y

Configuración del hardware.

Según el modelo de SAI, nut puede manejar distintos tipos de driver. Antes de configurar el archivo ups.conf conecta el cable USB de la PI al SAI y ejecuta este comando:

sudo nut-scanner -U

Este comando escaneará los buses USB y te dirá exactamente qué driver recomienda NUT para tu dispositivo específico.

nut@zero:~ $ sudo nut-scanner -U
Cannot load SNMP library (libnetsnmp.so.40) : file not found. SNMP search disabled.
Cannot load XML library (libneon.so.27) : file not found. XML search disabled.
Cannot load AVAHI library (libavahi-client.so.3) : file not found. AVAHI search disabled.
Cannot load IPMI library (libfreeipmi.so.17) : file not found. IPMI search disabled.
Scanning USB bus.
[nutdev1]
	driver = "nutdrv_qx"
	port = "auto"
	vendorid = "0665"
	productid = "5161"
	product = "USB to Serial"
	vendor = "Cypress Semiconductor"
	bus = "001"
	device = "002"
	busport = "001"
	###NOTMATCHED-YET###bcdDevice = "0002"

Observa que el driver recomendado es «nutdrv_qx«.

Archivos de configuración de NUT

Define el driver, editando el siguiente archivo.

sudo nano /etc/nut/ups.conf

Al comienzo del archivo, pega lo siguiente.

[salicru]
    driver = nutdrv_qx
    port = auto
    vendorid = 0665
    productid = 5161
    vendor = "Cypress Semiconductor"
    product = "USB to Serial"
    desc = "Salicru SOHO 2000"

En ese mismo archivo busca la línea maxretry = 3 comentala y déjala así.

#maxretry = 3

Guarda con Crtl + o y cierra con Crtl + x

Configura el modo editando el siguiente archivo.

sudo nano /etc/nut/nut.conf 

Busca la línea MODE, cambia la línea a standalone.

MODE=standalone

Configurar el acceso (upsd.conf)

Una vez que el driver está leyendo los datos del USB, necesitamos que el «servidor de NUT» (upsd) recoja esa información y la deje disponible para resto de equipos y otros programas (como nuestro script de Telegram o el comando upsc) puedan consultarla.

Para ello, editamos el archivo de configuración del demonio:

sudo nano /etc/nut/upsd.conf

Este archivo suele tener lineas que apuntan al localhost como las que vemos a continuación.

LISTEN 127.0.0.1 3493
LISTEN ::1 3493

Si las tienes, borralas y deja solo una línea LISTEN tal y como queda en la siguiente instrucción.

LISTEN 0.0.0.0 3493

El 0.0.0.0 sirve para que los demás equipos vean a la Pi Zero.

«Por seguridad, NUT viene configurado para ser ‘tímido’ (127.0.0.1) y solo hablar consigo mismo. Al cambiarlo a 0.0.0.0, convertimos a nuestra Raspberry Pi Zero en un Faro de Energía: ahora cualquier equipo de nuestra red local puede ver el estado del SAI y saber cuándo debe ponerse a salvo.»

¿Qué hace exactamente LISTEN 0.0.0.0?

Cuando configuras LISTEN 0.0.0.0 en el archivo upsd.conf de la Pi Zero, le estás diciendo al servidor NUT: «No te escondas; acepta preguntas de cualquier dirección IP que llegue a esta Raspberry».

• Sin el 0.0.0.0 (solo con 127.0.0.1): La Pi Zero está «sorda» a lo que venga de fuera. Tus equipos intentarán llamarla por red, pero ella no responderá porque solo escucha sus propios pensamientos internos (localhost).
• Con el 0.0.0.0: La Pi Zero abre sus «oídos» a toda la red local. Ahora, cuando el i7 pregunte: «¿Cómo va la batería?», la Pi Zero podrá escucharlo y responderle con los datos del Salicru.

¿Cómo «ve» la Pi Zero a los demás?

Curiosamente, la Pi Zero no necesita «ver» activamente a los demás equipos para protegerlos. Funciona al revés:

1. La Pi Zero (Maestro) simplemente publica la información del SAI en la red.
2. Los demás equipos (Esclavos como la Pi 5 o el i7) se conectan a ella constantemente para «leer» esa información.
3. En el momento en que la Pi Zero detecta batería baja, cambia su estado a FSD (Forced Shutdown).
4. Los esclavos, que están vigilando ese estado cada pocos segundos, ven el cambio y deciden apagarse por su cuenta.

Configurar 0.0.0.0 es como abrir la ventanilla de información de la Pi Zero al resto de la casa. Permite que tus PCs potentes se conviertan en «clientes» que consultan el estado del SAI a través de la red WiFi o Ethernet.

¿127.0.0.1 vs 0.0.0.0? Entendiendo la «Escucha» de Red

Para que tu estrategia de apagado coordinado funcione, es vital entender qué dirección IP debe usar el servidor NUT. Aquí tienes la comparativa de lo que sucede en tu Raspberry Pi Zero:

Configuración (LISTEN)	Alcance	Seguridad	¿Cuándo usarla?
127.0.0.1 (Localhost)	Solo Interno. La Pi Zero solo se habla a sí misma.	Máxima. Nadie fuera de la Pi puede ver los datos.	Cuando solo quieres recibir avisos por Telegram desde esa Raspberry.
0.0.0.0 (Todas las IPs)	Toda la Red. La Pi Zero se vuelve visible para el i7, la Pi 5 y el resto de PCs.	Media. Requiere usar contraseñas en upsd.users.	Obligatorio para apagar otros equipos de casa por red.

Crear la regla de permisos (udev)

La regla de udev es la forma que tiene Linux (en este caso tu Raspberry Pi con Debian) de gestionar los dispositivos que conectas físicamente a los puertos.

Para crear la regla, abre el editor nano con el siguiente comando.

sudo nano /etc/udev/rules.d/99-nut-ups.rules

Pega dentro esta línea exactamente:

SUBSYSTEM=="usb", ATTR{idVendor}=="0665", ATTR{idProduct}=="5161", MODE="0660", GROUP="nut"

(Guarda con Ctrl+O, Enter y sal con Ctrl+X).

Los valores de la regla, los vimos cuando ejecutamos el comando nut-scanner -U de donde extraemos los valores idVendor y idProduct.

Aplicamos la regla con:

sudo udevadm control --reload-rules && sudo udevadm trigger

Como Linux es un sistema multiusuario y seguro, por defecto no permite que cualquier programa (como el software de NUT) «hable» directamente con un hardware USB a menos que seas el administrador (root). La regla de udev que creamos sirve para decirle al sistema: «Cuando veas este SAI de Salicru, dáselo al grupo ‘nut’ para que pueda leer sus datos».

Anatomía de la regla

La línea que pusimos en /etc/udev/rules.d/99-nut-ups.rules se desglosa así:

SUBSYSTEM=="usb", ATTR{idVendor}=="0665", ATTR{idProduct}=="5161", MODE="0660", GROUP="nut"

• SUBSYSTEM=="usb": Le dice a Linux que solo mire en los puertos USB.
• ATTR{idVendor}=="0665": «Busca al fabricante 0665».
• ATTR{idProduct}=="5161": «Y que el producto sea el 5161».
• MODE="0660": Esto define los permisos de archivos de Linux. 0660 significa que el dueño y el grupo pueden leer y escribir, pero el resto del mundo no puede hacer nada.
• GROUP="nut": Aquí está la magia. Le asigna la propiedad del puerto al grupo nut. Como el software de monitorización corre bajo el usuario nut, ahora ya tiene «llave» para entrar al puerto USB.

¿Por qué es necesaria en la Raspberry Pi?

Sin esta regla, cuando el driver nutdrv_qx intenta preguntar al SAI «¿cuánta batería te queda?», el sistema operativo le responde: «Acceso denegado».

Si esta regla no está o está mal aplicada, te saldrá el error insufficient permissions. Al añadir la regla, el permiso se vuelve automático: cada vez que arranques la Raspberry o reconectes el USB, Linux aplicará estas instrucciones al instante.

Sincronizar los servicios

Ejecuta esto para limpiar y arrancar de forma oficial:

sudo systemctl stop nut-monitor nut-server
sudo rm -f /run/nut/*.pid
sudo systemctl start nut-server
sudo systemctl start nut-monitor

Comprobar la comunicación

Ahora, espera unos 5 segundos y lanza:

upsc salicru@localhost

El comando nos muestra en tiempo real la información detallada, el estado y las variables del Sistema de Alimentación Ininterrumpida (SAI/UPS)que está gestionado localmente mediante la herramienta NUT (Network UPS Tools)

nut@zero:~ $ upsc salicru@localhost
Init SSL without certificate database
battery.voltage: 27.4
device.type: ups
driver.debug: 0
driver.flag.allow_killpower: 0
driver.name: nutdrv_qx
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.parameter.product: USB to Serial
driver.parameter.productid: 5161
driver.parameter.synchronous: auto
driver.parameter.vendor: Cypress Semiconductor
driver.parameter.vendorid: 0665
driver.state: updateinfo
driver.version: 2.8.1
driver.version.data: Q1 0.08
driver.version.internal: 0.36
driver.version.usb: libusb-1.0.28 (API: 0x100010a)
input.frequency: 49.8
input.voltage: 235.2
input.voltage.fault: 235.2
output.voltage: 231.3
ups.beeper.status: enabled
ups.delay.shutdown: 30
ups.delay.start: 180
ups.load: 0
ups.productid: 5161
ups.status: OL
ups.temperature: 25.0
ups.type: offline / line interactive
ups.vendorid: 0665
nut@zero:~ $

Puerto de escucha

Como dato interesante, comprueba si el puerto 3493 que configuramos anteriormente, está a la escucha

nut@zero:~ $ ss -ltn | grep 3493
LISTEN 0      16           0.0.0.0:3493      0.0.0.0:*  

Las líneas LISTEN, indican que la Raspberry ya tiene la oreja puesta y está lista para informar sobre el estado del Salicru.

Procesos

Puedes escribir upsutil salicru@localhost o simplemente ver el estado del servicio:

Para verificar si el monitor (upsmon) está funcionando correctamente en tu Raspberry Pi, usa estos comandos:

nut@zero:~ $ ps aux | grep upsmon
root        6906  0.0  0.6   7304  2688 ?        Ss   10:05   0:00 /lib/nut/upsmon -F
nut         6907  0.0  1.2  10236  5120 ?        S    10:05   0:03 /lib/nut/upsmon -F
nut         9598  0.0  0.4   8804  2064 pts/0    S+   21:39   0:00 grep --color=auto upsmon
nut@zero:~ $ 

Deberías ver 3 procesos: uno que corre como root (el que tiene permiso para apagar la Pi) el otro como el usuario nut y el otro es simplemente el comando que acabamos de escribir.

Comprobar el estado del servicio.

Ejecuta el comando sudo systemctl status nut-monitor

nut@zero:~ $ sudo systemctl status nut-monitor
● nut-monitor.service - Network UPS Tools - power device monitor and shutdown controller
     Loaded: loaded (/usr/lib/systemd/system/nut-monitor.service; enabled; preset: enabled)
     Active: active (running) since Sat 2026-03-07 22:12:57 CET; 12h ago
 Invocation: 95d0260bee1c4eca9ad4a618365a8a2c
    Process: 1091 ExecStartPre=/usr/bin/systemd-tmpfiles --create /usr/lib/tmpfiles.d/nut-common-tmpfiles.conf (code=exited, status=0/SUCCESS)
   Main PID: 1093 (upsmon)
      Tasks: 2 (limit: 176)
        CPU: 3.333s
     CGroup: /system.slice/nut-monitor.service
             ├─1093 /lib/nut/upsmon -F
             └─1098 /lib/nut/upsmon -F

mar 07 22:12:57 zero systemd[1]: Starting nut-monitor.service - Network UPS Tools - power device monitor and shutdown controller...
mar 07 22:12:57 zero systemd[1]: Started nut-monitor.service - Network UPS Tools - power device monitor and shutdown controller.
mar 07 22:12:57 zero nut-monitor[1093]: fopen /run/nut/upsmon.pid: No such file or directory
mar 07 22:12:57 zero nut-monitor[1093]: Could not find PID file to see if previous upsmon instance is already running!
mar 07 22:12:57 zero nut-monitor[1093]: UPS: salicru@localhost (primary) (power value 1)
mar 07 22:12:57 zero nut-monitor[1093]: Using power down flag file /etc/killpower
mar 07 22:12:57 zero nut-monitor[1098]: Init SSL without certificate database
mar 07 22:12:57 zero nut-monitor[1098]: upsnotify: notify about state 2 with libsystemd: was requested, but not running as a service unit now, will not spam more about it
mar 07 22:12:57 zero nut-monitor[1098]: upsnotify: failed to notify about state 2: no notification tech defined, will not spam more about it
mar 07 22:12:57 zero nut-monitor[1098]: upsnotify: logged the systemd watchdog situation once, will not spam more about it
nut@zero:~ $ 

Si aparece en verde (active (running)), el vigilante está despierto.

Configurando los avisos por terminal.

sudo nano /etc/nut/upsmon.conf

Pega el siguiente texto debajo

# Banderas para ejecutar el comando (EXEC)
NOTIFYFLAG ONLINE   SYSLOG+WALL+EXEC
NOTIFYFLAG ONBATT   SYSLOG+WALL+EXEC
NOTIFYFLAG LOWBATT  SYSLOG+WALL+EXEC
NOTIFYFLAG SHUTDOWN SYSLOG+WALL+EXEC
NOTIFYFLAG REPLBATT SYSLOG+WALL+EXEC

Reinicia el servicio con:

sudo systemctl stop nut-monitor nut-server

Esto dará avisos en la terminal de tu raspberry, pero no lo hará si estas accediendo por ssh.

Cómo configurar el apagado automático (upsmon)

Como nuestra Raspberry Pi Zero 2W está conectada al Salicru, vamos a configurar el sistema para que se apague de forma segura.

Configurar el usuario

Debemos de tener un par de usuarios configurados para la gestión del SAI, que será el usurario administrador [monuser] y el usuario de los equipos remotos que será [remotemon]

Edita el archivo de usuarios de NUT:

sudo nano /etc/nut/upsd.users

Añade esto al final:

[monuser]
    password = mi_password_segura
    upsmon master

Si quieres, puedes dar a [monuser] privilegios de administrador así:

[monuser]
    password = mi_password_segura
    upsmon master
    actions = SET
    instcmds = ALL

Para dar privilegios de administrador a un usuario, tan solo agrégale las directrices actions e instcmds

Para el usuario remoto, añade este perfil al final (usa una contraseña distinta a la de admin):

[remotemon]
    password = clave_red_segura
    upsmon slave

Configurar el monitor

Edita el archivo del monitor:

sudo nano /etc/nut/upsmon.conf

Busca la sección MONITOR y asegúrate de que quede así:

MONITOR salicru@localhost 1 monuser mi_password_segura master
SHUTDOWNCMD "/sbin/shutdown -h now"
POWERDOWNFLAG /etc/killpower

Activar el servicio

Reinicia todo para que los cambios tengan efecto:

sudo systemctl restart nut-monitor

¿Qué pasará ahora cuando se corte la luz?

Si el SAI se apaga antes de que la Raspberry complete su apagado, podrías tener el mismo problema que con un corte normal de luz, archivos corruptos en la MicroSD. Este sistema está diseñado con una secuencia de retardo muy específica para evitar esto, El Retardo (Delay). Cuando la Raspberry envía la orden de «Kill Power», no le está diciendo al SAI «Apágate ya», sino «Apágate dentro de X segundos».

Si te fijas en los datos de tu upsc salicru@localhost, hay una línea clave:

ups.delay.shutdown: 30

Esto significa que cuando la Raspberry envía la orden final, el SAI Salicru inicia una cuenta atrás interna de 30 segundos.

La Secuencia Cronológica

Para que veas que es seguro, este es el orden real de los eventos:

1. Raspberry detecta Batería Baja: Inicia su propio proceso de apagado (SHUTDOWNCMD).
2. Cierre de Servicios: Debian detiene bases de datos, logs y procesos. La tarjeta SD deja de escribir datos.
3. Script Final de NUT: Justo en el último segundo del apagado (cuando el sistema ya está en modo «solo lectura»), se ejecuta la orden de «Kill Power» hacia el SAI.
4. SAI recibe la orden: El Salicru empieza su cuenta atrás de 30 segundos.
5. Raspberry muere: La Pi termina de apagarse por completo en 2 o 3 segundos más.
6. El SAI se apaga: 27 segundos después de que la Pi ya esté totalmente «muerta», el SAI corta la energía.

¿Por qué es necesario que el SAI se apague?

Imagina que no enviamos el «Kill Power»:

• La Raspberry se apaga y se queda esperando.
• El SAI se queda encendido con batería hasta que se agote al 0%.
• Vuelve la luz de la calle.
• Problema: Como el SAI nunca llegó a cortarle la corriente a la Raspberry (porque se quedó en un estado de «espera» con la batería agotada pero sin apagar el circuito), la Raspberry no detectará que ha vuelto la energía y no arrancará sola. Se quedará apagada hasta que alguien vaya físicamente a desenchufarla y enchufarla.

Resumen de seguridad

Con el valor de 30 segundos que tiene tu Salicru de fábrica:

• La Raspberry tiene tiempo de sobra (le sobran unos 25 segundos) para terminar de cerrarlo todo antes de que el SAI corte el flujo eléctrico.
• Es un método estándar y muy seguro.

Un detalle importante: En las Raspberry Pi, para que el ciclo de «vuelva la luz y se encienda sola» funcione perfecto, asegúrate de que el SAI esté configurado para rearmarse automáticamente (cosa que los Salicru SOHO+ hacen por defecto).

Para estar seguro de que la Raspberry sabe que es la jefa del apagado (modo master), ejecuta:

upsc salicru@localhost ups.delay.shutdown

Si te responde 30, significa que todo está listo para que, en caso de emergencia, la Pi le ordene al Salicru esperar 30 segundos antes de cortar la energía, dándole tiempo a la MicroSD para cerrarse a salvo.

¿Cómo saber si realmente se apagará? (Simulación segura)

Si quieres estar 100% seguro de que la configuración es correcta sin apagar la Raspberry de golpe, puedes mirar el log del sistema:

sudo journalctl -f -u nut-monitor -u nut-server

Si ahora mismo desenchufas el SAI de la pared, Verás en el log UPS salicru@localhost on battery.

nut@zero:~ $ sudo journalctl -f -u nut-monitor -u nut-server
mar 07 18:05:06 zero nut-server[7408]: Instant command: upsmon@::1 did test.battery.start.quick on salicru (tracking ID: disabled)
mar 07 18:05:06 zero upsd[7408]: Instant command: upsmon@::1 did test.battery.start.quick on salicru (tracking ID: disabled)
mar 07 19:24:09 zero nut-server[7408]: Instant command: upsmon@::1 did test.battery.start.quick on salicru (tracking ID: disabled)
mar 07 19:24:09 zero upsd[7408]: Instant command: upsmon@::1 did test.battery.start.quick on salicru (tracking ID: disabled)
mar 07 19:27:08 zero nut-server[7408]: Instant command: upsmon@::1 did test.battery.start.quick on salicru (tracking ID: disabled)
mar 07 19:27:08 zero upsd[7408]: Instant command: upsmon@::1 did test.battery.start.quick on salicru (tracking ID: disabled)
mar 07 20:05:29 zero nut-monitor[6907]: UPS salicru@localhost on battery
mar 07 20:05:45 zero nut-monitor[9348]: Network UPS Tools upsmon 2.8.1

Si miras en upsc salicru@localhost verás que cambia a status: OB.

nut@zero:~ $ upsc salicru@localhost
Init SSL without certificate database
battery.voltage: 26.9
device.type: ups
driver.debug: 0
driver.flag.allow_killpower: 0
driver.name: nutdrv_qx
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.parameter.product: USB to Serial
driver.parameter.productid: 5161
driver.parameter.synchronous: auto
driver.parameter.vendor: Cypress Semiconductor
driver.parameter.vendorid: 0665
driver.state: quiet
driver.version: 2.8.1
driver.version.data: Q1 0.08
driver.version.internal: 0.36
driver.version.usb: libusb-1.0.28 (API: 0x100010a)
input.frequency: 50.0
input.voltage: 9.6
input.voltage.fault: 9.6
output.voltage: 227.4
ups.beeper.status: enabled
ups.delay.shutdown: 30
ups.delay.start: 180
ups.load: 0
ups.productid: 5161
ups.status: OB
ups.temperature: 25.0
ups.type: offline / line interactive
ups.vendorid: 0665

Lo más importante:

Como el modelo SOHO+ 2000, tiene mucha autonomía para una Raspberry Pi Zero 2W (que consume casi nada). No esperes a que llegue a Low Battery (batería baja) de forma real porque podría tardar horas.

Si en algún momento quieres probar que el apagado funciona de verdad, el comando es:

sudo upsmon -c fsd

(Esto significa «Forced Shutdown» y simula que la batería se ha agotado, iniciando el proceso de apagado de seguridad inmediatamente).

¡Ya está todo listo y protegido! Tu Raspberry Pi ahora sobrevivirá a los cortes de luz sin corromper la tarjeta SD.

El script de alertas para Telegram

Creamos el script que enviará los mensajes:

sudo nano /usr/local/bin/nut-telegram.sh

Copia y pega el siguiente script. No olvides reemplazar «tu_token» y «tu_id» por los tuyos propios

#!/bin/bash

# Configuración del Bot de Telegram
TOKEN="tu_token"
CHAT_ID="tu_id"
export LC_ALL=C

# Función interna para leer los sensores (Lógica estable)
capturar() {
    BATERIA_V=$(upsc salicru@localhost battery.voltage 2>/dev/null || echo "0.0")
    VOLTAJE_IN=$(upsc salicru@localhost input.voltage 2>/dev/null || echo "0.0")
    VOLTAJE_OUT=$(upsc salicru@localhost output.voltage 2>/dev/null || echo "0.0")
    CARGA_SAI=$(upsc salicru@localhost ups.load 2>/dev/null || echo "0")
    ESTADO_SAI=$(upsc salicru@localhost ups.status 2>/dev/null || echo "N/A")
}

case "$1" in
    *"on battery"*)
        ICONO="🚨"
        TITULO="CORTE DE SUMINISTRO"
        
        # BUCLE DE ESPERA: No envía hasta que la entrada sea < 50V real
        intentos=0
        capturar
        while [[ "${VOLTAJE_IN%.*}" -gt 50 ]] && [[ $intentos -lt 12 ]]; do
            sleep 5
            capturar
            ((intentos++))
        done

        # --- DIAGNÓSTICO DE SALUD AL CORTE ---
        V_INT=${BATERIA_V%.*}
        if [ "$V_INT" -lt 24 ]; then
            DETALLE="¡OJO! Las baterías están muy bajas ($BATERIA_V V). Salud crítica, considera cambiarlas."
        else
            DETALLE="El SAI está operando con baterías. Salud química OK ($BATERIA_V V)."
        fi
        ;;

    *"on line power"*)
        ICONO="✅"
        TITULO="CORRIENTE RESTABLECIDA"
        DETALLE="El sistema vuelve a la red eléctrica."

        # BUCLE DE ESPERA: No envía hasta que la entrada sea > 200V real
        intentos=0
        capturar
        while [[ "${VOLTAJE_IN%.*}" -lt 200 ]] && [[ $intentos -lt 12 ]]; do
            sleep 5
            capturar
            ((intentos++))
        done
        ;;

    *"low battery"*)
        ICONO="⚠"
        TITULO="BATERIA CRITICA"
        DETALLE="Nivel muy bajo. El apagado es inminente."
        capturar
        ;;

    *"SHUTDOWN"*)
        ICONO="💀"
        TITULO="APAGADO DE EMERGENCIA"
        DETALLE="La Raspberry se apaga para proteger la SD."
        capturar
        ;;

    *"REPLBATT"*)
        ICONO="🛠"
        TITULO="FALLO DE BATERIA"
        DETALLE="Es necesario sustituir las baterías del Salicru."
        capturar
        ;;

    *)
        ICONO="ℹ"
        TITULO="NOTIFICACION SAI"
        DETALLE="$1"
        capturar
        ;;
esac

# Mensaje final con los iconos: 🔌 y ⚡
CUERPO="$ICONO *$TITULO* $ICONO
------------------------------------
📝 $DETALLE

🔋 *Bateria:* $BATERIA_V V
🔌 *Entrada:* $VOLTAJE_IN V
⚡ *Salida:* $VOLTAJE_OUT V
📊 *Carga SAI:* $CARGA_SAI%
📈 *Estado:* $ESTADO_SAI"

# Envío a Telegram
curl -s -X POST "https://api.telegram.org/bot$TOKEN/sendMessage" \
     --data-urlencode "chat_id=$CHAT_ID" \
     --data-urlencode "text=$CUERPO" \
     --data-urlencode "parse_mode=Markdown" > /dev/null 2>&1

Importante: Dale permisos de ejecución con:

sudo chmod 755 /usr/local/bin/nut-telegram.sh

y haz que el dueño sea el usuario de nut:

sudo chown nut:nut /usr/local/bin/nut-telegram.sh

Configurando los avisos por telegram

Volvemos a configurar las flags para los avisos por telegram, por lo que volvemos a entrar al archivo upsmon.conf

 sudo nano /etc/nut/upsmon.conf

Copia encima o debajo de las anteriores notificaciones

# Comando externo para notificaciones
NOTIFYCMD "/usr/local/bin/nut-telegram.sh"

# Definición de mensajes que activan el script
NOTIFYMSG ONLINE    "UPS salicru@localhost on line power"
NOTIFYMSG ONBATT    "UPS salicru@localhost on battery"
NOTIFYMSG LOWBATT   "UPS salicru@localhost low battery"
NOTIFYMSG SHUTDOWN  "SHUTDOWN"
NOTIFYMSG REPLBATT  "REPLBATT"

Reinicia el servicio

sudo systemctl restart nut-monitor

Haz una prueba manual con:

sudo -u nut /usr/local/bin/nut-telegram.sh "Prueba manual"

Test

Podemos listar los comandos que puede realizar nuestro salicru.

nut@zero:~ $ upscmd -l salicru
Instant commands supported on UPS [salicru]:

beeper.toggle - Toggle the UPS beeper
driver.killpower - Tell the driver daemon to initiate UPS shutdown; should be unlocked with driver.flag.allow_killpower option or variable setting
driver.reload - Reload running driver configuration from the file system (only works for changes in some options)
driver.reload-or-error - Reload running driver configuration from the file system (only works for changes in some options); return an error if something changed and could not be applied live (so the caller can restart it with new options)
driver.reload-or-exit - Reload running driver configuration from the file system (only works for changes in some options); exit the running driver if something changed and could not be applied live (so service management framework can restart it with new options)
load.off - Turn off the load immediately
load.on - Turn on the load immediately
shutdown.return - Turn off the load and return when power is back
shutdown.stayoff - Turn off the load and remain off
shutdown.stop - Stop a shutdown in progress
test.battery.start - Start a battery test
test.battery.start.deep - Start a deep battery test
test.battery.start.quick - Start a quick battery test
test.battery.stop - Stop the battery test

De la lista podemos ejecutar test.battery.start.quick que lo único que hace es pasar al estado OL CAL y hacer un test del sistema para el chequeo interno del SAI pero no hará como su nombre indica, ningún test de las baterías.

nut@zero:~ $ upscmd -u upsmon -p tu_contresña_segura salicru test.battery.start.quick
OK

Mientras se realiza el test, puedes comprobar el voltage de la batería en tiempo real con este comando, que se mantendrá inmutable ya que el el sistema se mantiene todo el tiempo OnLine.

while true; do upsc salicru@localhost battery.voltage; sleep 1; done

Mantenimiento Preventivo Mensual

«Investigando a fondo con la consola de NUT, descubrimos que el Salicru SOHO+ protege sus baterías. Aunque veas comandos como test.battery.start.deep, el SAI los ignora para evitar descargas innecesarias. El único comando que acepta es el quick, que activa el modo OL CAL (Calibración Online). Este modo es genial para verificar que los relés y el inversor funcionan, pero no estresa la batería.

Conclusión: Para saber la salud real de tus baterías en este modelo, el ‘Test del Tirón’ (desenchufar 10 segundos) sigue siendo el único modo. Mi script de Telegram te avisará al instante de cuánto cae el voltaje en ese momento y en que estado se encuentran las baterías.»

Si el driver nutdrv_qx solo nos permite el OL CAL, vamos a convertir ese «estiramiento» en nuestro test mensual. Aunque no descargue la batería, es vital porque obliga a los relés físicos a moverse. Un SAI que nunca hace un test puede acabar con los relés «pegados» por el calor y el desuso, y el día que se vaya la luz de verdad, no conmutará.

Script de «Mantenimiento Preventivo de Relés e Inversor».

Abre una terminal y ejecuta el siguiente comando para crear nuestro archivo de mantenimiento

sudo nano /usr/local/bin/mantenimiento-sai.sh

Pega el siguente texto, no olvides de introducir «tu_token_de_telegram» «tu_id_de_chat» y «tu_contraseña_segura»

#!/bin/bash

# --- CONFIGURACIÓN ---
TOKEN="TU_TOKEN_DE_TELEGRAM"
ID="TU_ID_DE_CHAT"
UPS="salicru"
USUARIO="upsmon"
CLAVE="tu_contraseña_segura"

# 1. Inicio del mantenimiento
curl -s -X POST "https://api.telegram.org/bot$TOKEN/sendMessage" -d "chat_id=$ID&text=⚙ *Mantenimiento Mensual:* Iniciando test de relés en $UPS..."

# 2. Lanzar el Quick Test (Modo CAL)
upscmd -u $USUARIO -p $CLAVE $UPS test.battery.start.quick > /dev/null
sleep 2

# 3. Verificamos si el SAI ha entrado en modo calibración
STATUS=$(upsc $UPS ups.status)

if [[ "$STATUS" == *"CAL"* ]]; then
    # Esperamos a que termine (vimos que dura unos 9-10 seg)
    sleep 10
    FINAL_STATUS=$(upsc $UPS ups.status)
    if [[ "$FINAL_STATUS" == "OL" ]]; then
        MSG="✅ *TEST OK*: Los relés han conmutado y el inversor ha arrancado correctamente. El sistema de emergencia está operativo."
    else
        MSG="⚠ *AVISO*: El test ha terminado pero el estado es $FINAL_STATUS. Revisar manualmente."
    fi
else
    MSG="❌ *ERROR*: El SAI ha ignorado la orden de test. Es posible que necesite un reinicio del servicio NUT."
fi

# 4. Enviar resultado
curl -s -X POST "https://api.telegram.org/bot$TOKEN/sendMessage" -d "chat_id=$ID&parse_mode=Markdown&text=$MSG"

Este script hará el test aceptado por el Salicru, verificará que el estado pase por OL CAL y te informará de que la electrónica de conmutación sigue viva.

La automatización (Cron)

Para que se haga solo una vez al mes (por ejemplo, el día 1 a las 10:00), añade esto a tu sudo crontab -e:

00 10 1 * * /usr/local/bin/mantenimiento-sai.sh

«¿Por qué automatizar un test que no descarga la batería?»

Muchos usuarios cometen el error de no tocar su SAI hasta que se va la luz. El problema es que los relés son piezas mecánicas que pueden fallar por falta de uso. Mi script mensual fuerza al Salicru a entrar en modo OL CAL. Aunque no descargue la batería, este proceso hace que los relés ‘hagan ejercicio’ y que el inversor se autochequee. Es la garantía de que, cuando llegue el apagón real, la parte mecánica del SAI no estará agarrotada.

Tabla de Salud de la Batería (Sistema de 24V)

«Una vez que recibas la notificación en tu móvil, ¿cómo saber si esos voltios son buenos o malos? He preparado esta tabla de referencia para que sepas cuándo es el momento de sacar la cartera y comprar repuestos:»

Voltaje en Batería	Estado de Salud	Significado Técnico	Acción
> 27.0 V	Excelente	Carga completa en flotación.	Ninguna.
24.5 V – 26.5 V	Normal	Funcionamiento correcto bajo carga.	Uso habitual.
23.5 V – 24.4 V	Aviso / Débil	La batería empieza a perder capacidad química.	Planificar cambio a medio plazo.
< 23.5 V	Crítico	Agotamiento inminente o celdas dañadas.	Cambio urgente. Riesgo de apagón repentino.

Nota, no recomiendo usar este hat si estás usando un disco SSD conectado a los puertos usb, si no es a través de un hub, debido a los picos de corriente que genera provocando desconexiones y problemas en los mismos.

En este tutorial, aprenderemos a configurar un sistema de alerta crítica. Si tu conexión a internet falla —ya sea por una avería de tu proveedor (ISP) o un fallo en tu propio router—, la Raspberry Pi detectará la caída de inmediato, te avisará mediante una llamada telefónica y te reportará via Telegram cuando la red sea restablecida.

Para que este sistema sea infalible, no podemos depender de la propia conexión de fibra que estamos monitorizando. Necesitamos una vía de comunicación externa. En este caso práctico, utilizaremos un módulo HAT 4G LTE CAT-1 (A7670E), junta a una tarjeta SIM M2M (machine to machine) como las que emplean Vodafone u Orange para alarmas profesionales, ascensores , etc. Estas tarjetas suelen estar limitadas a voz o SMS y no disponen de datos móviles. Aprovecharemos la robusta red 2G para garantizar que, en caso de caída de la conexión de fibra, la Raspberry Pi ejecute una llamada de voz a nuestro teléfono móvil de forma prioritaria.

¿Por qué es importante este sistema? Si confías en la domótica para la seguridad de tu hogar (alarmas, detectores de inundación o cámaras), una caída de la red, te deja «a ciegas». Saber que tu red ha caído en tiempo real te permite reaccionar antes de que sea tarde.

¿Cómo funciona el flujo de trabajo?

1. Monitorización: La Raspberry Pi realiza «pings» constantes a servidores externos (como los DNS de Google o Cloudflare).
2. Detección: Si el ping falla de forma consecutiva, el script activa el módulo A7670E.
3. Alerta: El HAT ejecuta el comando AT de llamada y marca tu número de teléfono.
4. Acción: Recibes la llamada y sabes, al instante, que algo va mal en casa.

Prepara el software de tu Raspberry.

Para entrar a las funciones del HAT necesitaremos instalar el programa minicom.

sudo apt-get install minicom

Para que nuestro script funcione, necesitas instalar la librería Python Serial:

sudo apt-get install python3-serial -y

Por alguna extraña razón, (que solo he podido observar en Raspberry Pi, ModemManager no se lleva bien con este HAT, intenta secuestrarlo constantemente, como si fuese un módem de los antiguos.

Por eso motivo, ya que no será necesario, optaré por desinstalarlo con:

sudo apt-get purge modemmanager -y

Permisos del usuario.

Tu usuario debe de tener permiso para usar el puerto serie (el módem) por defecto. Si no es así, el script intentará abrir el puerto y al no conseguirlo, se quedará esperando una respuesta que el sistema le bloqueará y no llegará a marcar.

Teclea el siguiente comando para ver los grupos a los que pertenece tu usuario.

groups

Comprueba que tu usuario pertenece al grupo «dialout», si no es así, deberás agregarlo con este comando:

sudo usermod -a -G dialout tu_usuario

Tras ejecutar este comando, reinicia tu Raspberry

sudo reboot

Forzar el modo de alta corriente (Si tu fuente es MUY buena)

En una Raspberry pi 4 es algo común, que si usas varios dispositivos conectados a los puertos USB, Pines GPIO, etc, sufras de cuelgues del sistema y se te queden tus proyectos mas tiesos que la mojama.

Si tienes la fuente oficial de 3A (o una mejor), puedes intentar decirle a la Pi que desbloquee el límite de los USB, aunque esto es automático hasta cierto punto, a veces ayuda asegurar el voltaje. Sin embargo, hay un detalle técnico importante: en la Raspberry Pi 4, el límite de corriente de los USB está fijado por hardware a 1.2A compartidos.

Pero, para «darle chicha» y asegurar que el sistema no entre en pánico cuando el SSD y el HAT 4G trabajen juntos, vamos a aplicar dos ajustes de «estabilidad máxima» que debes tener en cuenta.

1. Evitar el «ahorro de energía» del USB (El culpable del bloqueo)

Cuando el SSD y el HAT piden energía a la vez, el kernel de Linux puede intentar suspender el puerto USB para protegerse, y ahí es donde se congela la Pi. Vamos a prohibirle que lo haga.

Ejecuta este comando para editar el archivo de arranque:

sudo nano /boot/firmware/cmdline.txt

Al final de la línea de texto (sin pulsar Enter, todo en la misma línea), añade un espacio y esto:

usbcore.autosuspend=-1

2. Estabilidad de Voltaje (Config.txt)

Vamos a añadir un parámetro para que la CPU no baje su rendimiento bruscamente cuando detecte picos de consumo del USB, lo que evita que se cuelgue el sistema.

Edita el archivo de configuración:

sudo nano /boot/firmware/config.txt

Añade estas líneas al final:

# Forzar estabilidad de voltaje en puertos USB
avoid_warnings=1

El Hardware: HAT 4G LTE CAT-1 (A7670E)

El HAT 4G LTE CAT-1 para Raspberry Pi (Modelo A7670E), es un módulo compacto pero extremadamente versátil capaz de:

• Realizar y recibir llamadas de voz.
• Enviar y recibir SMS.
• Navegar por internet mediante 4G.
• Obtener datos de GPS

Nota: A partir de este momento, no es necesario tener conectado el cable USB al Módulo 4G, tan solo debe de estar conectado a los pines GPIO

Configurar la Raspberry para usar su puerto serie interno

Por defecto, la Raspberry usa sus pines de transmisión para la «consola» (donde ves letras al arrancar). Hay que liberarlo:

1. Ejecuta:
   sudo raspi-config
2. Ve a Interface Options -> Serial Port.
3. ¿Deseas que la consola sea accesible por serie? NO.
4. ¿Deseas que el hardware del puerto serie esté habilitado? SÍ.
5. Reinicia la Raspberry.

Localizar el nuevo puerto

Una vez iniciado el sistema, vuelve a ingresar a la terminal para que podamos entrar por el puerto físico de los pines de la Raspberry, que suele ser /dev/ttyS0

sudo minicom -D /dev/ttyS0 -b 115200

Si todo va bien, entrarás a la terminal de configuración del módulo. Ahora, debemos comprobar el modo de funcionamiento en el que se encuentra el HAT 4G.

La terminal del módulo 4G

Ahora que estás en la terminal de programación del módulo, escribe el siguiente comando.

AT$MYCONFIG?

Si nos devuelve "usbnetmode"2, es porque el módulo está en modo Serial(modén) que es justo lo que necesitamos.

Pero, si nos devuelve "usbnetmode",0, es porque el módulo está en modo RNDIS (Red) y deberemos desactivarlo.

Cómo desactivar RNDIS

«Muchos tutoriales te obligan a usar el modo RNDIS, pero si tu objetivo es enviar alertas mediante llamadas, el modo Serie (usbnetmode,2) es el secreto para una estabilidad del 100% en placas Raspberry Pi, evitando conflictos de red innecesarios.»

Para dejarlo en modo «serie», que es el la opción indicada para hacer solo llamadas perdidas desde la Raspberry Pi 4, ejecuta esta secuencia exacta en tu terminal:

1. Cambia al modo 2 (Modem/Serie):
   AT$MYCONFIG="usbnetmode",2
2. Desactiva el intento de marcación automática:
   AT+DIALMODE=1
3. Guarda los cambios en la memoria interna (Flash):
   AT&W
4. Reinicia el módulo para que aplique los cambios:
   AT+CRESET

Para salir del terminal del HAT 4G pulsa Ctrl + A y luego Q y volverás a la terminal de Linux.

EL Script

Tras varias pruebas, este script en su versión 4.7, es una solución de monitorización en lenguaje Python, diseñada para informar cuando tu conexión de internet principal falla.

Crea un archivo llamado netguard.py

nano netguard.py

Pega el siguiente código.

No olvides sustituir tu número de teléfono, tu Token de Telegram y tu ID de Telegram.

import os
import time
import serial
import subprocess
import requests
import sys

# --- CONFIGURACIÓN ---
TELEFONO = "600000000"
PUERTO_MODEM = "/dev/serial0"
INTERFAZ_FIBRA = "eth0"
TOKEN_TELEGRAM = "Tu_Token"
ID_CHAT = "Tu_ID"

fibra_estaba_caida = False
llamada_realizada_con_exito = False

def comprobar_fibra():
    try:
        resultado = subprocess.run(
            ["ping", "-I", INTERFAZ_FIBRA, "-c", "2", "-W", "3", "1.1.1.1"],
            stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL
        )
        return resultado.returncode == 0
    except:
        return False

def inicializar_modem(ser):
    """Configuración inicial recomendada para A7670E"""
    comandos = [
        b"AT+CMEE=2\r\n",      # Errores verbosos
        b"AT+CRC=1\r\n",       # Resultados extendidos (útil)
        b"AT+COLP=1\r\n",      # Muestra número cuando contestan (opcional)
        b"AT+CVHU=0\r\n",      # Modo hangup correcto
        b"AT+CLCC=1\r\n",      # (no siempre necesario pero no hace daño)
    ]
    for cmd in comandos:
        ser.write(cmd)
        time.sleep(0.4)
        ser.read_all()  # descartar respuesta

def realizar_llamada_perdida():
    ser = None
    try:
        print(f"\n[{time.strftime('%H:%M:%S')}] ALERTA: Sin internet → Iniciando llamada perdida...", flush=True)
        
        ser = serial.Serial(PUERTO_MODEM, 115200, timeout=1)
        inicializar_modem(ser)

        # Limpieza completa
        ser.reset_input_buffer()
        ser.reset_output_buffer()

        # Registro en red (mejor usar CEREG para LTE, pero CREG también funciona)
        print(" [+] Esperando cobertura...", flush=True)
        for i in range(30):
            ser.write(b"AT+CREG?\r\n")
            time.sleep(1)
            resp = ser.read_all().decode(errors='ignore')
            if ",1" in resp or ",5" in resp:
                print(f" [+] Registrado en red (intento {i+1})", flush=True)
                break
            print(f" [...] Buscando torre... ({i+1}/30)", flush=True)
        else:
            print(" [!] Sin cobertura. Reiniciando módulo...", flush=True)
            ser.write(b"AT+CFUN=1,1\r\n")
            return False

        # Colgar cualquier llamada residual
        ser.write(b"AT+CHUP\r\n")
        time.sleep(0.8)
        ser.read_all()

        # MARCAR
        print(f" 📞 Marcando a {TELEFONO}...", flush=True)
        ser.write(f"ATD{TELEFONO};\r\n".encode())
        time.sleep(1.5)  # esperar OK + VOICE CALL: BEGIN

        print(" [?] Llamada en curso. Esperando que cuelgues (máx 45s)...", flush=True)

        timeout = time.time() + 45
        llamada_activa = False

        while time.time() < timeout:
            # Polling CLCC + lectura de URCs
            ser.write(b"AT+CLCC\r\n")
            time.sleep(0.7)
            resp = ser.read_all().decode(errors='ignore').strip()

            # URC directo del módulo (lo más fiable)
            if "VOICE CALL: END" in resp:
                print(" ✅ Colgado detectado por URC 'VOICE CALL: END'", flush=True)
                return True

            # CLCC desapareció → colgado por receptor
            if "+CLCC:" in resp:
                llamada_activa = True
                print(" → Sonando / activa", flush=True)
            elif llamada_activa and "+CLCC:" not in resp and "OK" in resp:
                print(" ✅ Colgado detectado: CLCC desapareció", flush=True)
                return True

            # Backup: NO CARRIER
            if "NO CARRIER" in resp:
                print(" ✅ Colgado por NO CARRIER", flush=True)
                return True

        # Timeout → colgamos nosotros
        print(" ⏰ Timeout → colgando forzosamente", flush=True)
        ser.write(b"AT+CHUP\r\n")
        return False

    except Exception as e:
        print(f" [!] Error serie: {e}", flush=True)
        return False
    finally:
        if ser and ser.is_open:
            ser.close()

# --- BUCLE PRINCIPAL ---
print("--- Vigilante M2M v5.7 (A7670E optimizado) ---", flush=True)

while True:
    hay_internet = comprobar_fibra()

    if not hay_internet:
        if not fibra_estaba_caida:
            print(f"[{time.strftime('%H:%M:%S')}] Caída de fibra detectada.", flush=True)
            time.sleep(5)
            if not comprobar_fibra():  # doble chequeo
                fibra_estaba_caida = True
                if realizar_llamada_perdida():
                    llamada_realizada_con_exito = True
                else:
                    time.sleep(30)  # reintentar más lento si falló

        elif not llamada_realizada_con_exito:
            if realizar_llamada_perdida():
                llamada_realizada_con_exito = True
            else:
                time.sleep(60)

    elif hay_internet and fibra_estaba_caida:
        print(f"[{time.strftime('%H:%M:%S')}] ✅ Fibra recuperada. Avisando por Telegram...", flush=True)
        try:
            requests.post(
                f"https://api.telegram.org/bot{TOKEN_TELEGRAM}/sendMessage",
                data={"chat_id": ID_CHAT, "text": "✅ Fibra recuperada"},
                timeout=10
            )
        except:
            pass
        fibra_estaba_caida = False
        llamada_realizada_con_exito = False

    time.sleep(20)

Para guardar pulsa Ctrl + o y Ctrl + x para salir

No olvides hacerlo ejecutable con:

chmod +x netguard.py

¿Cómo funciona el script?

El programa actúa como un centinela que vigila la interfaz de fibra (eth0) cada 20 segundos mediante pings ligeros. Su inteligencia reside en cómo gestiona las alertas:

1. El script actúa como un centinela incansable que vigila la interfaz de fibra (eth0) cada 20 segundos mediante pings ligeros. Su inteligencia reside en cómo gestiona las alertas de forma robusta y eficiente, aprovechando al máximo las capacidades del módulo A7670E (según el manual oficial SIMCom A76XX v1.09):
2. Paciencia de Registro (mejorada): No marca a ciegas. Primero interroga al módem con AT+CREG? para confirmar cobertura real (registrado en red roaming o home). Realiza hasta 30 intentos (más margen que antes), con pausas de 1 segundo, dando tiempo al hardware para sincronizarse con la torre más cercana. Si falla tras los intentos, fuerza un reinicio profundo del módulo (AT+CFUN=1,1) para «despertarlo» y buscar señal de nuevo.
3. Inicialización Proactiva del Módem: Antes de cualquier operación crítica, envía comandos de configuración recomendados por SIMCom: AT+CMEE=2 (errores verbosos), AT+CRC=1 (resultados extendidos), AT+COLP=1 (muestra número al contestar, opcional), AT+CVHU=0 (modo colgado correcto). Esto evita errores comunes y mejora la fiabilidad.
4. Detección Inteligente de Colgado (el gran salto): La clave de v5.7 es la detección proactiva y prioritaria usando URCs nativos del módulo:
   • Tras ATD<numero>;, el módem envía automáticamente VOICE CALL: BEGIN cuando empieza a sonar.
   • Mientras la llamada está activa, polling frecuente con AT+CLCC para ver si sigue en lista (+CLCC: presente).
   • Cuando cuelgas desde tu móvil, llega el URC VOICE CALL: END → detección inmediata y casi infalible.
   • Fallbacks: si CLCC desaparece tras haber estado activo, o aparece NO CARRIER.
   • Timeout máximo de 45 segundos (más que suficiente para llamada perdida) → fuerza AT+CHUP si no cuelgas, evitando bloqueos eternos.
5. Flush=True, Timeouts y Limpieza de Buffers: Todas las impresiones usan flush=True para logs inmediatos en journalctl. Las lecturas/escrituras serie tienen timeout=1 y se limpian buffers (reset_input_buffer()) antes y después de comandos clave. Nada se queda «colgado».
6. Reintento Inteligente y Persistencia Educada: Si la llamada falla (sin cobertura, timeout, etc.), el script reintenta en el siguiente ciclo de vigilancia (cada ~20-60 s según estado). Pero una vez que logra que tu móvil suene con éxito (colgado detectado), marca llamada_realizada_con_exito = True y deja de llamar hasta que la fibra se recupere. Así evita saturar tu línea o gastar saldo innecesario.
7. Informe de Retorno por Telegram: Tras la alerta por voz, el script entra en modo «escucha». En cuanto detecta que la fibra ha vuelto (doble chequeo ping para evitar falsos positivos), envía mensaje por Telegram: « Fibra recuperada». Así sabes no solo la caída, sino también el momento exacto de recuperación.

Ademas:

1. Doble verificación de caída (ping + 5 s espera + segundo ping) antes de alertar.
2. Logs limpios: imprime solo lo esencial (puedes reducir aún más los «→ Sonando / activa» editando el contador).
3. Manejo de excepciones y cierre seguro del puerto serie (finally con ser.close()).

En resumen: v5.7 es más fiable, rápida en detección y respetuosa con tu móvil y saldo, gracias a los URC nativos y la configuración proactiva del módulo.

Lanza tu script a ver que ocurre.

python3 netguard.py

Crea el archivo del servicio.

«Haciéndolo Robusto: Creando un Servicio en Systemd» «Un vigilante no sirve de nada si tienes que arrancarlo a mano. Al convertir nuestro script en un servicio de Linux, garantizamos que la vigilancia sea 24/7, incluso si hay un apagón y la Raspberry se reinicia sola. El sistema se encarga de que el script esté siempre vivo.»

Para que este script sea realmente autónomo, debería arrancar al inicio del sistema y si falla o se cierra por un error inesperado, Linux lo reinicia automáticamente en pocos segundos.

Lo ideal es crear un servicio en el sistema (Systemd).

Ejecuta este comando para crear el archivo de configuración:

sudo nano /etc/systemd/system/netguard.service

Copia y pega este contenido (asegúrate de que la ruta /home/tu_usuario/netguard.py sea la correcta donde guardaste el script):

[Unit]
Description=Servicio Vigilante de Fibra por GSM
After=network.target

[Service]
# Fuerza a Python a no guardar nada en memoria intermedia
Environment=PYTHONUNBUFFERED=1
ExecStart=/usr/bin/python3 -u /home/tu_usuario/netguard.py
WorkingDirectory=/home/tu_usuario
User=tu_usuario
# El grupo dialout es clave para que el usuario tenga permiso al módem
Group=dialout
Restart=always
RestartSec=10

# Estas líneas aseguran que Systemd vuelque todo al journal al instante
StandardOutput=journal
StandardError=journal
TTYPath=/dev/ttyS0

[Install]
WantedBy=multi-user.target

Nota: Cambia tu_usuario por el tuyo propio.

Activar y arrancar el servicio

Ahora dale las órdenes a la Raspberry para que lo ponga en marcha:

# Recargar el sistema para que vea el nuevo servicio
sudo systemctl daemon-reload

# Activar para que arranque siempre al encender la Pi
sudo systemctl enable netguard.service

# Arrancar el servicio ahora mismo
sudo systemctl start netguard.service

¿Cómo saber si está funcionando?

Puedes ver el estado del vigilante en tiempo real con este comando:

sudo systemctl status netguard.service

Y si quieres ver los «logs» (lo que el script va imprimiendo):

journalctl -u netguard.service -f

Un ejemplo tras varios dias de funcionamiento del script.

tu_usurio@raspberrypi:~ $ journalctl -u netguard.service -f
mar 01 15:53:48 tu_host python3[3651558]: --- Vigilante M2M v5.7 (A7670E optimizado) ---
mar 01 15:54:13 tu_host python3[3651558]: [15:54:13] Caída de fibra detectada.
mar 01 15:54:22 tu_host python3[3651558]: [15:54:22] ALERTA: Sin internet → Iniciando llamada perdida...
mar 01 15:54:24 tu_host python3[3651558]:  [+] Esperando cobertura...
mar 01 15:54:25 tu_host python3[3651558]:  [+] Registrado en red (intento 1)
mar 01 15:54:25 tu_host python3[3651558]:  📞 Marcando a 600000000...
mar 01 15:54:27 tu_host python3[3651558]:  [?] Llamada en curso. Esperando que cuelgues (máx 45s)...
mar 01 15:54:28 tu_host python3[3651558]:  → Sonando / activa
mar 01 15:54:28 tu_host python3[3651558]:  → Sonando / activa
mar 01 15:54:29 tu_host python3[3651558]:  → Sonando / activa
mar 01 15:54:30 tu_host python3[3651558]:  → Sonando / activa
mar 01 15:54:30 tu_host python3[3651558]:  → Sonando / activa
mar 01 15:54:31 tu_host python3[3651558]:  → Sonando / activa
mar 01 15:55:00 tu_host python3[3651558]:  ✅ Colgado detectado por URC 'VOICE CALL: END'
mar 01 15:55:21 tu_host python3[3651558]: [15:55:21] ✅ Fibra recuperada. Avisando por Telegram...

Troubleshooting (solución de problemas)

Si tu sistema sigue experimentando cuelgues o hace cosas extrañas cuando intenta hacer una llamada, prueba a usar un Hub USB con alimentación propia (La más segura). Conecta el SSD a un Hub USB que tenga su propia fuente de alimentación. Así, la energía para mover el módulo la da el Hub y no la Raspberry. La Pi solo se encarga de los datos. Por lo que, lo más efectivo es separar el consumo.

Prueba final:

Una vez que esté todo funcionando.

1. Desconecta el cable Ethernet para provocar una llamada.
2. Abre abre una terminal y escribe
   ls -R /
3. Si ya no se bloquea, es que la fuente de la Pi 5 y el comando autosuspend=-1 han solucionado el conflicto de energía.

Miscelánea

Estos son los comandos clave para extraer estadísticas y gestionar tu Vigilante como un auténtico administrador de sistemas.

1. El «Resumen de Batalla» (Estadísticas rápidas)

Si quieres saber cuántas veces se ha caído la fibra o cuántas llamadas ha hecho el script sin leer miles de líneas, usa este comando. Filtrará el log y te dará solo los hitos importantes:

journalctl -u netguard.service | grep -E "Caída detectada|Llamada finalizada|Red recuperada"

Esto te mostrará una lista limpia con los días y horas exactas de cada incidente.

2. Comprobar el estado del «Motor»

Si alguna vez dudas de si el script sigue vivo (aunque ya hemos visto que es eterno), este comando te da el informe de salud de Systemd:

systemctl status netguard.service

Fíjate en la línea que dice Active: active (running) since.... Te dirá cuántos días lleva encendido sin interrupciones.

3. Reiniciar tras cambios (SIM, teléfono, etc.)

Si decides cambiar el número de teléfono o el token de Telegram en el archivo .py, no basta con guardar el archivo. Tienes que decirle a la Raspberry que cargue la nueva versión:

sudo systemctl restart netguard.service

Tanto la memoria de buffers como la de caché se consideran «disponibles» porque el kernel puede liberarla instantáneamente si un programa necesita más RAM.

• Buffers: Se usa para almacenar bloques de archivos que están en espera para ser escritos en el disco.
• Caché: Se usa para almacenar datos de archivos que se han leído recientemente del disco.

Nota: Para el kernel de Linux, la memoria libre es memoria desperdiciada.

Comando free -h

Comprobar el uso de la memoria es tan fácil como escribir lo siguiente en la terminal:

raspberry@pi5:~
$ free -h
               total       usado       libre  compartido   búf/caché   disponible
Mem:           7,9Gi       1,8Gi       323Mi        94Mi       6,2Gi       6,1Gi
Inter:         199Mi          0B       199Mi

El comando free -h te da una visión detallada y precisa de la situación. Te muestra varias categorías de memoria:

• total: La cantidad total de RAM física.
• usado: La memoria que está siendo utilizada activamente por los procesos del sistema.
• libre: La memoria que no está siendo utilizada para nada. En un sistema Linux bien optimizado, este valor suele ser muy bajo.
• buff/cache: La memoria utilizada para buffers y caché de disco.
• disponible: Este es el valor más importante para entender la memoria «realmente disponible». Es la memoria "libre" más la memoria de "buff/cache" que el sistema puede liberar rápidamente si es necesario. Es la mejor estimación de cuánta memoria hay disponible para nuevos programas sin usar la memoria de intercambio (swap).

Comando htop

htop adopta un enfoque diferente, a menudo para simplificar la visualización en su barra de progreso. Por lo general, calcula la memoria «usada» de una manera que puede ser engañosa para algunos usuarios.

raspberry@pi5:~
$ htop

Así es como htop desglosa el uso de la memoria:

• Verde: Memoria usada por procesos de usuario.
• Azul: Memoria usada para buffers (E/S de disco).
• Amarillo/Naranja: Memoria usada para caché (archivos de disco).
• Rosa/Fucsia: Memoria usada por el kernel del sistema.
• Lila/Magenta: Memoria de swap (si está activado y en uso).

Una barra de memoria llena en htop no siempre significa que tu sistema esté en problemas. De hecho, a menudo indica que Linux está utilizando la memoria RAM de manera muy eficiente.

Liberar Memoria buffer/cache

Hay algunas situaciones específicas donde liberar la caché y los búferes puede ser beneficioso:

• Entornos con recursos limitados: En sistemas con poca RAM, como una Raspberry Pi o un servidor con poca memoria, liberar la caché de forma manual puede ser una solución rápida para liberar memoria para nuevas aplicaciones o procesos que la necesiten, evitando que el sistema comience a usar el espacio de intercambio (swap) de forma prematura.
• Pruebas de rendimiento (benchmarking): Si estás realizando pruebas para medir la velocidad de entrada/salida (I/O) de un disco, es crucial que las pruebas se realicen directamente sobre el disco y no sobre los datos que ya están en la caché. Limpiar la caché asegura que cada prueba parta de las mismas condiciones iniciales.
• Problemas de rendimiento inexplicables: En raras ocasiones, un sistema puede volverse lento debido a que la caché está llena de datos obsoletos o corruptos. Liberar la caché puede ser un paso de diagnóstico para ver si el rendimiento mejora.
• Después de tareas intensivas en I/O: Si has realizado una tarea que ha consumido muchos recursos, como una copia de seguridad grande o la edición de vídeo, y has notado que el sistema se ha vuelto lento, liberar la caché puede ayudar a que el sistema vuelva a su estado normal más rápidamente.

Es importante recordar, que liberar la caché de forma manual no es una solución a largo plazo para los problemas de rendimiento. El kernel de Linux liberará la caché automáticamente cuando un proceso necesite más memoria. Liberar la caché del sistema puede causar una breve lentitud inicial mientras el sistema vuelve a cargar los datos necesarios en la memoria, sin embargo, no hay riesgo de pérdida de datos. La mayoría de los sistemas Linux gestionan la memoria de forma eficiente por sí mismos, por lo que este tipo de intervención manual solo es necesaria en las situaciones anteriormente descritas.

Recuerda: Forzar esta acción puede causar una ralentización temporal, ya que el sistema tendrá que volver a leer los datos del disco la próxima vez que los necesite, en lugar de acceder a ellos directamente desde la RAM.

Creando el Script

Una vez entendido lo anteriormente descrito, si deseas crear un script para liberar memoria de forma automática, abre una terminal y escribe:

sudo nano /usr/local/bin/liberar_memoria.sh

Pega lo siguiente en la ventana que se abre

#!/bin/bash

# Este script libera la memoria caché del sistema Linux.
# Requiere permisos de superusuario (sudo).

# Muestra el uso de la memoria antes de liberar la caché.
echo "Uso de la memoria antes de liberar la caché:"
free -h
echo "---"

# Sincroniza el sistema de archivos para asegurar que los datos en caché se esc>
sync

# Limpia los cachés de la página, los dentry y los inodos.
# El valor '3' en /proc/sys/vm/drop_caches hace esto.
echo "Liberando la memoria caché..."
sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

# Muestra el uso de la memoria después de liberar la caché.
echo "---"
echo "Uso de la memoria después de liberar la caché:"
free -h

echo "Proceso completado."

Ctrl + o para guardar y Ctrl + x para salir

sudo chmod +x /usr/local/bin/liberar_memoria.sh

En este momento puedes ejecutar desde una terminal el script así

raspberry@pi5:~
$ liberar_memoria.sh

Para hacer esto automáticamente, creamos una tarea que se ejecute a las 5.00 a.m horas todos los días y limpie la memoria.

crontab -e

Copiamos y pegamos lo siguiente al final de la línea.

0 5 * * * /usr/local/bin/liberar_memoria.sh >> /home/tu_usuario/freeMen.log 2>&1

Ctrl + o para guardar Ctrl + x para salir

Ahora una vez al dia, a las 5.00 a.m se limpiará la memoria de tu equipo 24/7/365

Ahora sabemos:

Que si tu sistema se vuelve lento, observa la memoria ocupada, (barra llena, color verde), o si la parte lila (swap) empieza a crecer, podría ser una señal de que necesitas controlar mediante un script la liberación de memoria o necesitas comprar más RAM para tu carga de trabajo actual.