En este tutorial vamos a ver cómo podemos administrar, de forma muy básica, un sai Salicru SPS One 900VA con NUT (Network UPS Tools).
Para obtener mas información a cerca de este sai, podéis consultar mi última review hecha sobre el mismo en este enlace.
Si tenéis dudas o queréis hacer alguna crítica o posible corrección, no dudéis en poneros en contacto conmigo y os atenderé lo más rápido posible.
Espero que este tutorial sea de vuestro agrado y máximo interés.
Jordi
Contents
Introducción
Como ya vimos en mi review, el Salicru SPS One 900VA es un sai de “mediana estatura”, básico pero con un gran potencial que nos dará lo que necesitamos para nuestra pequeña empresa o despacho, tanto a nivel profesional como doméstico. Es un sai que nos dará soporte para un pc, una impresora y algún dispositivo mas, con una carga de 900VA y una autonomía de unos 15/30 minutos máximo a plena carga.
En este tutorial básico veremos cómo conectar el sai a un sistema Linux, en este caso una RaspberryPi 3B+, con Raspbian, y conseguir cominicarnos con él. De este modo podremos obtener datos de su estado y eventos, así como apagar de forma segura el sistema o los sistemas que protege.
A continuación os lo detallo todo.
Vamos a ello!
Qué necesitamos
Para llevar a cabo este tutorial necesitaremos disponer del siguiente material:
- un sai Salicru SPS One 900VA
- un cable USB tipo A – B (normalmente suministrado con el sai)
- una RaspberryPi 3B+, o similar, correctamente actualizada y con un sistema operativo Raspbian o equivalente (un PC con Linux también nos sirve, presumiblemente)
- conexión a Internet
Es imprescindible disponer de los suficientes conocimientos en entornos Linux para poder llevar a cabo las siguientes pautas del tutorial. En aquellos casos que no sea tan obvio, se dará explicaciones adicionales.
Instalación
Preparar el sistema
Mi Raspi tiene como nombre de host upscontroller, y lo iréis viendo a lo larga del tutorial.
Para empezar, deberemos actualizar los paquetes de nuestra raspberry. Posteriormente instalaremos NUT mediante el comando apt install, del siguiente modo:
pi@upscontroller:~ $ sudo apt update pi@upscontroller:~ $ sudo apt upgrade pi@upscontroller:~ $ sudo apt install nut
Una vez finalice la instalación ya dispondremos en nuestro sistema de las herramientas que ofrece NUT para la gestión y el control de nuestro SAI.
Conexión del sai
Apagaremos el sistema, y es este el momento idóneo para conectar el sai con el cable USB.
Encontraréis el conector en la parte trasera del mismo, y con el cable, lo conectaremos a un puerto USB libre de nuestra raspberry.
El sai aporta dos conexiones shucko para tomas de 220V. Ahí deberemos conectar los sistemas que deseamos proteger. Podemos hacerlo de forma directa o bien mediante una regleta, si es que disponéis de mas de un sistema (raspi, router, nas, etc…).
Probando la instalación
Ahora ya podemos volver a arrancar, esta vez con el sai conectado mediante usb a nuestra raspberry pi.
Una vez iniciado, y desde la consola de comandos, haremos un pequeño test invocando el driver de monitor upsdrvctl:
pi@upscontroller:~ $ upsdrvctl Network UPS Tools - UPS driver controller 2.7.4 Starts and stops UPS drivers via ups.conf. usage: upsdrvctl [OPTIONS] (start | stop | shutdown) [<ups>] -h display this help -r <path> drivers will chroot to <path> -t testing mode - prints actions without doing them -u <user> drivers started will switch from root to <user> -D raise debugging level start start all UPS drivers in ups.conf start <ups> only start driver for UPS <ups> stop stop all UPS drivers in ups.conf stop <ups> only stop driver for UPS <ups> shutdown shutdown all UPS drivers in ups.conf shutdown <ups> only shutdown UPS <ups>
Como podemos ver el sistema ha respondido correctamente. Esto nos indica que ya lo tenemos todo listo para empezar a configurar el servicio de monitorización del SAI.
Ficheros de configuración
La configuración de NUT se encuentra en el directorio /etc/nut:
pi@upscontroller:~ $ ls -la /etc/nut/ total 52 drwxr-xr-x 2 root nut 4096 Mar 29 20:04 . drwxr-xr-x 80 root root 4096 Mar 29 19:49 .. -rw-r----- 1 root nut 1538 Jun 1 2018 nut.conf -rw-r----- 1 root nut 5522 Jun 1 2018 ups.conf -rw-r----- 1 root nut 4578 Jun 1 2018 upsd.conf -rw-r----- 1 root nut 2131 Jun 1 2018 upsd.users -rw-r----- 1 root nut 15308 Jun 1 2018 upsmon.conf -rw-r----- 1 root nut 3887 Jun 1 2018 upssched.conf
El listado anterior muestra los ficheros implicados en la configuración de todo el sistema.
A continuación vamos a detallar cada una de las configuraciones necesarias.
Para editar los ficheros de configuración os recomiendo siempre usar la consola para controlar mas lo que hacemos. Yo utilizo nano por comodidad, pero sentiros libres de usar el editor que mejor se adecue a vuestras necesidades (vi, nedit, note, etc..).
Empecemos.
nut.conf
Este fichero contiene la configuración básica de NUT, en la que le indicaremos al driver si debe ser activado o no. Por defecto vemos que el único parámetro existente es MODE=none, lo que significa que el driver está desactivado.
En nuestro caso iniciaremos el servicio en “modo único”, que nos permitirá controlar un solo SAI en modo local. Existe otro caso, en red, para un sistema servidor de SAIs pero es un caso que en estos momentos no nos ocupa.
Para iniciar el driver en modo único, debemos indicar el siguiente modo:
MODE=standalone
Guardamos y salimos.
ups.conf
Este fichero define cada uno de los SAIs que vamos a controlar de forma local. En nuestro caso solo será uno, por medio de un puerto USB.
En la siguiente configuración indicamos que disponemos un dispositivo definido por salicru, para el que definimos el driver y el puerto usados para comunicarnos con el mismo. Además, podremos indicar una breve descripción:
[salicru] driver = blazer_usb port = auto desc = "Salicru SPS One 900VA"
Con estos valores tenemos:
- driver: blazer_usb
- es el driver que acepta comunicaciones con sistemas Salicru (aunque no está indicado oficialmente, por experiencia sabemos que es el driver que mejor se adapta a estos SAIs)
- port = auto
- indicamos que haga un escaneo inteligente de todos los puertos abiertos en el sistema por el USB, de este modo no tenemos que preocuparnos por qué puerto específico usa el SAI (en las instrucciones del aparato aparece detallado)
- desc = “Salicru SPS One 900VA”
- una breve descripción, muy útil si tuviéramos más de un dispositivo
upsd.conf
Este fichero define la configuración del servicio de monitorización del sistema SAI. En él detallaremos los parámetros necesarios para el acceso al SAI.
Nosotros usaremos los siguientes valores:
LISTEN 127.0.0.1 3493
Para nuestro caso sólo es necesario indicar en qué nodo (host) corre el servicio, que en nuestro caso es localhost o 127.0.0.1, en el puerto 3493 (valores por defecto del sistema).
upsd.users
En este fichero configuraremos los usuarios que deseamos definir como administradores del sistema o explotadores de datos del SAI.
En nuestro caso definiremos todos los usuarios por defecto que indica el fichero de ejemplo:
[admin] password = 12345 actions = SET instcmds = ALL [testuser] password = 12345 instcmds = test.battery.start instcmds = test.battery.stop instcmds = calibrate.start instcmds = calibrate.stop [upsmon] password = 12345 upsmon master
Básicamente:
- admin
- usuario administrador, con password 12345, al que se le permite gestionar completamente el sistema
- testuser
- identificado con el password de test, 12345, se le permite hacer test de baterías y calibración
- upsmon
- usario de monitorización, se le asignael password 12345, y se le permite monitorizar el sistema master
Notad que los passwords son simplemente de test, en un caso real deberíamos usar unos passwords más seguros, dado que el usuario administrador puede realizar cualquier tipo de intervención en el sistema. Para nuestro tutorial esto es suficiente.
upsmon.conf
Este fichero de configuración, que es el mas extenso, es además el mas interesante, dado que es el que nos ofrece la posibilidad de configurar cómo debe comportarse el servidor y el driver, qué parámetros nos interesa obtener y algunas acciones que podremos realizar para atender a los diferentes eventos que el servicio genera.
Valores por defecto
Por defecto, dejaremos tal cuál los parámetros siguientes que ya vienen en el fichero base de ejemplo:
MINSUPPLIES 1
Este parámetro indica que, al menos, tendremos una instancia del driver corriendo.
SHUTDOWNCMD "/sbin/shutdown -h +0"
Este es el parámetro que ejecutará el servidor cuando detecte que el sistema está funcionando con baterías y haya pasado el tiempo configurado (lo veremos más abajo). Es sumamente importante que verifiquéis con vuestro SO cuál es el comando idóneo para ello, dado que es el punto y final antes del apagado controlado de todo el sistema…
POLLFREQ 5
Tiempo, en segundos, cada cuánto el servidor hará polling al sistema SAI para obtener los datos de su estado normal.
POLLFREQALERT 5
Tiempo, en segundos, cada cuánto el servidor hará polling al sistema SAI para obtener los datos de su estado de alarma por funcionamiento con baterías.
HOSTSYNC 15
Tiempo, en segundos, que esperará el sistema maestro por cada uno de los esclavos para saber si siguen activos.
DEADTIME 15
Tiempo, en segundos, que esperará el servidor para dar por “muerto” un dispositivo. Básicamente, indica cuántos segundos esperará el sistema para dar la alarma de que el servidor no da señales de funcionamiento.
POWERDOWNFLAG /etc/killpower
Este parámetro indica al servidor qué fichero se debe crear en en el proceso de apagado por funcionamiento con baterías. Es un fichero de flag, y se suele utilizar para avisar a otros sistemas que no disponen de un modo de comunicación serie o que imposibilita su sincronización. Es decir, cualquier otro servicio puede mirar la existencia de este fichero para ser avisado del inicio del proceso de apagado del SAI.
RBWARNTIME 43200
Alerta de reemplazo de baterías. Por defecto 43200 segundos, o 12h, indica cada cuánto tiempo el servicio de monitorización debe avisar sobre el reemplazo necesario de las baterías.
NOCOMMWARNTIME 300
Indicador o aviso de no comunicación con el sistema. Por defecto, un aviso cada 300 segundos, o 5 minutos.
FINALDELAY 5
Tiempo previo al envío de la notificación de apagado, una vez se ha iniciado el proceso. Es el tiempo final de espera, 5, expresado en segundos.
upssched.conf
Este fichero de configuración contiene todos los detalles relacionados con el sistema de temporización del driver del sai.
Dado que para este tutorial básico no nos es necesario modificarlo, no entraremos en detalles sobre el mismo. Basta con dejarlo tal cuál viene por defecto.
Primera puesta en marcha
Ya hemos visto de forma rápida el contenido de cada uno de los ficheros de configuración de NUT.
A continuación haré una propuesta de parametrización básica y veremos cómo aplica cada uno de los parámetros que usaremos, para personalizar, quizá completamente, nuestras necesidades.
Probando el servidor de monitorización
Lo primero que vamos a probar es la declaración del MONITOR del sistema.
Para ello debemos añadir el siguiente contenido al final del fichero upsmon.conf:
########################################################## # SALICRU SPS 900VA # ########################################################## MONITOR salicru@127.0.0.1:3493 1 upsmon 12345 master
Con esta configuración estamos indicando al driver que debe iniciar el servicio MONITOR en el sai salicru, ubicado / conectado en 127.0.0.1 (localhost), y al puerto 3493 (por defecto). Posteriormente indicamos el usuario (upsmon), su contraseña y el modo de conexión (master, ya que solo controlaremos un sai en la red de sais). No parece complicado, en este punto, poder disponer de otros sais en la red y poder comandarlos de forma paralela…
Guardamos y reiniciamos la Raspi, para que el sistema reconozca la nueva parametrización, e inicie de forma automática el servidor de monitorización.
Para verificar que todo ha ido correctamente, haremos nuestra primera prueba tras el reinicio…
Ejecutaremos el siguiente comando, y veremos los resultados básicos que ofrece el servicio NUT, con este mínimo de configuración detallado anteriormente:
pi@upscontroller:/etc/nut $ sudo upsc salicru@127.0.0.1:3493
La ejecución finaliza con el siguiente resultado:
pi@upscontroller:/etc/nut $ sudo upsc salicru@127.0.0.1:3493 Init SSL without certificate database battery.charge: 100 battery.voltage: 13.50 battery.voltage.high: 13.00 battery.voltage.low: 10.40 battery.voltage.nominal: 12.0 device.type: ups driver.name: blazer_usb driver.parameter.pollinterval: 2 driver.parameter.port: auto driver.parameter.synchronous: no driver.version: 2.7.4 driver.version.internal: 0.12 input.current.nominal: 3.0 input.frequency: 50.1 input.frequency.nominal: 50 input.voltage: 239.2 input.voltage.fault: 239.2 input.voltage.nominal: 230 output.voltage: 237.1 ups.beeper.status: enabled ups.delay.shutdown: 30 ups.delay.start: 180 ups.load: 0 ups.productid: 5161 ups.status: OL ups.type: offline / line interactive ups.vendorid: 0665
Perfecto!
No voy a entrar en detalle en cada una de las líneas de información que arroja el comando de sondeo que hemos lanzado, ya que es bastante autocontenido (en cualquier caso puedes preguntarme). Podemos ver datos como nivel de carga de las baterías y su voltaje, así como otros muchos datos relacionados con el sistema y el driver.
Así pues, ya tenemos nuestro el servidor de monitorización funcionando correctamente. Pero por ahora sólo sirve de test o para obtener datos del estado del sistema SAI.
Podemos conseguir bastante más, si dedicamos unos cuantos minutos a configurar un poco más este importante fichero.
A continuación lo vemos.
Parametrización customizada
Ahora es el momento de hacer que el driver sea “inteligente”, y no sólo ofrezca información de estado, sino que sea capaz de realizar actividades automatizadas según el estado del SAI.
Insertamos el siguiente contenido al final del fichero de configuración:
########################################################## # SALICRU SPS 900VA # ########################################################## MONITOR salicru@127.0.0.1:3493 1 upsmon 12345 master NOTIFYCMD /home/pi/ups_notify.sh NOTIFYMSG ONLINE "UPS %s on line power" NOTIFYMSG ONBATT "UPS %s on battery" NOTIFYMSG LOWBATT "UPS %s battery is low" NOTIFYMSG FSD "UPS %s: forced shutdown in progress" NOTIFYMSG COMMOK "Communications with UPS %s established" NOTIFYMSG COMMBAD "Communications with UPS %s lost" NOTIFYMSG SHUTDOWN "Auto logout and shutdown proceeding" NOTIFYMSG REPLBATT "UPS %s battery needs to be replaced" NOTIFYMSG NOCOMM "UPS %s is unavailable" NOTIFYMSG NOPARENT "upsmon parent process died - shutdown impossible" NOTIFYFLAG ONLINE SYSLOG+WALL+EXEC NOTIFYFLAG ONBATT SYSLOG+WALL+EXEC NOTIFYFLAG LOWBATT SYSLOG+WALL+EXEC NOTIFYFLAG FSD SYSLOG+WALL+EXEC NOTIFYFLAG COMMOK SYSLOG+WALL+EXEC NOTIFYFLAG COMMBAD SYSLOG+WALL+EXEC NOTIFYFLAG SHUTDOWN SYSLOG+WALL+EXEC NOTIFYFLAG REPLBATT SYSLOG+WALL+EXEC NOTIFYFLAG NOCOMM SYSLOG+WALL+EXEC NOTIFYFLAG NOPARENT SYSLOG+WALL+EXEC
A continuación, os detallo qué estamos consiguiendo con estas sentencias o flags de configuración:
- MONITOR
- es la sentencia que instancia el monitor del sai, ya comentado anteriormente
- NOTIFYCMD
- indicamos qué fichero batch ejecutaremos en cada evento
- NOTIFYMSG
- con estos flags estamos creando los mensajes que el sistema creará cuando se lancen cada uno de los eventos a los que hacen referencia
- estos mensajes aceptan parametrizaciones del tipo %s (string) o %d (number), por ejemplo
- ejemplo: NOTIFYMSG LOWBATT “UPS %s battery is low”
- indica que el evento LOWBATT (batería baja) generará un mensaje con el contenido “UPS <nombreDelSai> battery is low”, dónde <nombreDelSai> lo sustituirá por el nombre que actualmente hemos asignado al sai que lanza el evento (si tenemos mas de uno) mediante el parámetro %s
- para más datos, podéis consultar la sección NOTIFY MESSAGES de la página del manual de NUT (UPSMON)
- NOTIFYFLAG
- con estos flags estamos indicando al sistema qué tipo de evento debe generar para cada caso:
- SYSLOG: deja rastro en el log del sistema
- WALL: manda el mensaje del evento a todos los usuarios logueados en el sistema (mensaje de consola)
- EXEC: ejecuta el batch registrado en NOTIFYCMD, pasándole como parámetro el dato del evento
- por ejemplo, NOTIFYFLAG LOWBATT, enviará un mensaje de evento de baterías bajas a los sistemas definidos (en nuestro caso, los tres sistema de aviso)
- para más datos, podéis consultar la sección NOTIFY FLAGS de la página del manual de NUT (UPSMON)
- con estos flags estamos indicando al sistema qué tipo de evento debe generar para cada caso:
Para cada uno de los flags anteriores se utilizan NOTIFY EVENTS, que son los identificadores de los eventos que el sai es capaz de lanzar:
- ONLINE: el sai ha vuelto a estar conectado a la red eléctrica
- ONBATT: el sai ha entrado en modo baterías
- LOWBATT: el nivel de las baterías del sai es bajo (configurable a nivel de driver)
- FSD: se ha enviado el comando Force Shutdown Mode al sai (apagado forzado)
- COMMOK: comunicación con el sai establecida
- COMMBAD: comunicación con el sai perdida
- SHUTDOWN: el sistema local ha entrado en el proceso de apagado
- REPLBATT: es necesario reemplazar las baterías del sai
- NOCOMM: no se puede comunicar con el sai
Como veis, NUT ofrece un amplio abanico de eventos de sistema que pueden ser fácilmente explotados mediente los flags anteriores y sus configuraciones. Disponéis de más información en la página del manual de NUT (UPSMON), sección NOTIFY EVENTS.
Fichero batch de gestión de avisos
Una de las partes mas interesantes de la monitorización del sistema sai es recibir de forma automática los eventos que el sistema lanza. Para ellos debemos declarar un fichero batch que se encargue de hacer lo que sea necesario. Puede ser tan sencillo o tan complejo como necesitemos.
El fichero batch que os propongo, ups_notify.sh, lo hemos generado a mano, y es tan sencillo como esto:
#! /bin/bash echo "$*" | sendmail -F"ups@upscontroller" me@email.com
Simplemente, lo que hace es obtener de la entrada estandard (mediante $) como parámetro el evento que el sistema monitor ha lanzado, y enviarlo por correo electrónico. Notad que las variables de configuración son de test, aquí deberíais indicar vuestro correo electrónico. Además, tened en cuenta que el comando sendmail debe existir en el sistema y deberéis tener permisos de ejecución del mismo.
Lo veremos en otro tutorial, mas adelante, pero pensad que en este punto podríais usar un cliente de ifttt, twitter, telegram o cualquier otro servicio online, para poder enviar los datos a los destinatarios interesados…
Conclusión
Con esto finalizamos el tutorial “básico” para la administración de un sai Salicru SPSOne 900VA.
En futuros tutoriales explicaré qué aplicaciones podemos usar para la explotación de los datos, así como la automatización de su obtención y posterior tratamiento. Podemos tener desde gráficas y avisos hasta sistemas en la nube que nos ejecuten rutinas en caso de caída del sai.
Algunas de las tecnologías de las que hablaremos serán, por ejemplo, OpenMediaVault, que es un sistema operativo completo para gestionar un sistema NAS, y que acepta una configuración muy básica de NUT, y por otro lado, NodeRED, para la automatización de rutinas y flujos de trabajo. Éste último lo encuentro muy especialmente interesante, ya que con muy poco trabajo podremos obtener una automatización completa de la información de nuestro sai.
Espero que haya sido de vuestro agrado y utilidad.
No dudéis en dejar vuestros comentarios, dudas y críticas. Todo será bienvenido.
Gracias por leerme!
Jordi
Hola, lo primero darte las gracias por el tutorial.
He tenido algún problema con la última parte. En el tutorial tienes puesto NOTOFYCMD /home/pi/ups_notify.sh cuando tendría que ser NOTIFYCMD, y luego hasta que no he quitado los “%s” de los NOTIFYMSG no me ha empezado a llegar la información de la cadena de texto.
Gracias por el tutorial
Hola Roberto, muchas gracias a ti por el comentario y las correcciones.
En cuanto al tema de los %s, me he encontrado casos, y desconozco el motivo, que es tal y como indicas. Si bien a mi me funcionó correctamente tal cuál lo he posteado, ya que el código es extraído de mi propia experiencia, me consta que dependiendo del sistema operativo esto podría cambiar… ¿Qué sistema operativo usas?
Muchas gracias por tu tiempo y colaboración.
Saludos,
Jordi
Muy completo y me ha funcionado a la primera, salvo algunos permisos.
Sabes por qué la carga muestra 0?
A mi me pasa lo mismo y tengo carga. Mismo SAI
He mirado y remirado y no consigo encontrar como extraer el dato.
Muy buenas, Jose,
Ante todo muchas gracias por tu comentario y feedback. En cuanto a tu pregunta, no lo tengo del todo claro, pero me parece recordar que este SAI no es completamente compatible con la librería, porque no está pensado para trabajar con ella de forma nativa. Sin embargo, si que expone la gran mayoría de sus datos.
Intentaré revisarlo y ver por qué motivo no aparece este dato, pero me da la sensación de que es un tema interno de la interface del SAI, que no ofrece esta información (seguramente entre otras). Si lo logro, actualizaré esta página.
Gracias por el apunte y, sobre todo, por leerme!
Saludos,
Jordi
Hola, he seguido con atención tu magnífico tutorial, pero no he conseguido que funcione correctamente. Te detallo mi material:
– Router GL-MT3000 (GL-iNET) con USB 3.0 y OpenWRT (última versión)
– Salicru ONE 700VA
– Cable USB B (he probado varios)
Conseguí que funcionase unas horas, pero no llegó a ejecutarme el script de notificaciones desde upsmon (llegué a configurar el msmtp y funcionaban los correos), y después, no volví a conseguir que conectase el driver “blazer_usb”. Cada vez que ejecutaba “upsc salicru” me decía que no detectaba el driver. He probado otros drivers, pero no me han funcionado. Incluso he intentado bloquear algunos kernels para que no me ocupen el USB. Nada ha funcionado. El dichoso “Error driver not detected”.
He ejecutado todo tipo de comandos, como por ejemplo:
sudo /lib/nut/blazer_usb -a salicru
/etc/init.d/nut-server stop
killall blazer_usb
sudo /etc/init.d/nut-server restart
He modificado permisos e incluso he rehecho los archivos .conf dentro de /etc/nut (que en mi versión no entiendo porque me aparecen enlaces simbólicos a /var/etc/nut por lo que con cada reinicio se iba la información).
He puesto varias veces de fábrica el router, he reinstalado varias veces todo, etc.
Los logs extraídos del router no son muy concluyentes, he usado también lsusb para comprobar que esté conectado (que lo está) y he habilitado verbosidad para ver con más detalles estos logs, dicen que se conecta y desconecta, algo extraño, puesto que con el PC con el que monitorizo vía ViewPower jamás ha fallado.
Ya he tirado la toalla tras horas, ¿qué opinas, Jordi? ¿qué puede estar fallando?
Gracias de antemano.
Un saludo.