Administración básica del sai Salicru SPSOne 900VA con NUT

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


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)

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

Share Button

5 comentarios

  1. 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

  2. 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

  3. 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.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.