fibaro domotica razberry z-wave

Razberry: Domotica low-cost existe gracias a Z-Wave

Es curioso porque cuando compré mi placa Razberry Z-Wave tenía ciertas dudas si conseguiría que funcionase algo con todo esto de la Domotica. Como comentaba en el anterior artículo, todo mi interés surgió cuando me dispuse a investigar sobre soluciones de Smart Metering y vi que los productos completos en el mercado eran excesivamente caros para mi gusto. De pronto, me encontré con los Fibaro Wall-Plugs: Ese tipo de medidores que llaman a la vista por ser excepcionalmente pequeños, y que al parecer, cumplían el objetivo! Con eso solo faltaba el controlador Z-Wave, y por menos de 200 euros, bastante difícil bajarse del burro: Hasta que localice el Razberry Z-Wave 2 por 1: Una interfaz con una API REST y realizaba la función al milímetro. Pero como suelen decir: las gangas no existen, y necesitaba comprobarlo con mis propios ojos, así que hice el pedido (que por cierto, sorprendentemente llego en poco más de un día a través de la tienda online zwave.es y yo esperaba que esa tarjeta Razberry tardará semanas, o incluso meses por ser relativa como popular). Y con todo el material en casa, me dispuse a montar el sistema

fibaro domotica razberry z-wave

Primero el objetivo: Saber cuánto consumen los distintos dispositivos eléctricos/electrónica de mi casa. Quizá en un futuro gracias a la domotica, sería interesante tener una gráfica de consumo y tal, pero creo que es sería más interesante con un dispositivo que se coloca en el cuadro general y mide el consumo general de toda la casa. Pero para un dispositivo en concreto creo que realmente la gracia está en saber cuánto consume.

Por ejemplo: Ponemos el controlador en la lavadora, ponemos el programa clásico de lavado y podemos observar cuanto ha consumido (a pesar de las especificaciones del fabricante). Ahora mismo estoy comprobando el consumo de los emisores térmicos de mi casa, que tienen fama de “ahorro energético” pero tengo la sensación que no es cierto del todo. Esta es una de las bondades de la domotica.

Configurando la interfaz Domotica del Razberry en nuestra Raspberry Pi

Ahora manos a la obra. En primer lugar vamos a configurar el sistema. Para ello nos hace falta tener una Raspberry Pi a la que conectar la placa Razberry Z-Wave (encima de los 10-pines más pegados a la ranura de la tarjeta SD, aunque una imagen vale más que mil palabras)

raspberry pi z-wave razberry domotica

Si ya tenemos Rasbian instalado (versión wheezy en el momento de escribir este artículo más convenientemente), simplemente tendremos que ejecutar el siguiente comando:

wget -q -O - razberry.z-wave.me/install | sudo bash

Con esto quedan instalados los drivers para la Razberry, y el software al que se accede vía web. Quizá necesario reiniciar el sistema para que el sistema operativo reconozca la tarjeta una vez instalado el driver. A partir de aquí ya podemos acceder a la interfaz web:

http://ip_raspberry_pi:8083/expert/

Ahora tenemos que configurar nuestro Fibaro Wall Plug en el sistema de domotica Razberry Z-Wave. Para ello simplemente conectamos el Wall-Plug al dispositivo eléctrico y la corriente como es lógico, y debería encenderse ya el LED en un color indicando el consumo del dispositivo en cuestión (si está apagado, lo más probable es que los leds estén en un azul muy claro). Simplemente con esta acción, el Fibaro Wall-Plug estará preparado para sincronizar con nuestro Razberry. Para ello desde la interfaz web vamos a Network -> Network Management -> (Re)include device y si todo va bien, debería emparejarse sin problemas (en teoría la señal Z-Wave es de aproximadamente unos 20 metros, por eso si no detecta, es que a lo mejor está demasiado lejos, de todas formas el Fibaro Wall Plug tiene un botón en la parte inferior que permite realizar una sincronización forzada, leer el manual de uso, pero a mi siempre me lo ha detectado a la primera)

fibaro wall plug domotica

En el panel de control Web Razberry Z-Wave vamos a Devices configuration y en la parte inferior derecha pulsamos en Expert mode. En la lista de dispositivos en la parte izquierda debería aparecer nuestro Fibaro Wall-Plug, si picamos sobre el y vamos a la parte inferior de la lista de opciones deberíamos ver un menú desplegable llamado Advanced Actions. Dentro pulsamos en Show Interview Results. Si pulsamos en SensorMultiLevel podemos ver todos los datos necesarios para configurar a continuación un acceso a la API de Razberry Z-Wave fundamental para montar nuestro pequeño programa casero para extraer información del sensor. Esto es aplicable a todos los dispositivos que emparejemos con nuestro dispositivo

zwave web razberry domotica

En mi ejemplo si nos damos cuenta, el acceso al Sensor Multi Nivel de la Razberry, se realiza desde devices[2].instances[0].commandClasses[49].data[4].val (en caso de data hay para elegir el 0 y el 4, como quiero sacar el dato en val que es el consumo en Vatios (W) en el momento concreto, pues elijo el 4 y la propiedad “val”).

Para confirmar que todo va bien, podemos acceder a este valor a través de la API de Razberry a través de la dirección (con la propiedad value al final para que nos devuelva el valor)

http://ip_raspberry_pi:8083/ZWaveAPI/Run/devices[2].instances[0].commandClasses[49].data[4].val.value

Si vemos un valor significa que todo va bien (es posible que los valores cambien de dispositivo a dispositivo, por eso he indicado como yo he llegado a estos valores específicamente)

Programación utilizando la API de Razberry y el Fibaro Wall Plug

Ahora mi objetivo es crear un script en PHP que vaya metiendo en una base de datos cada 5 minutos este valor a través de la librería cURL. Dado que la Raspberry Pi no está para trotes, he decidido usar la base de datos SQLite. Creamos la base de datos con el nombre que queramos que es un fichero al final de cuentas, si ya tenemos SQLite instalado y un servidor web con la extensión de PHP (en mi caso puse apache2 como servidor web que aunque es pesado lo conozco mejor, aunque quizá sería más recomendable lighthttp) podemos crear la base de datos con el comando:

# sqlite3 razberry.db

Luego desde la interfaz sqlite3 podemos crear la tabla por ejemplo “plug” con los comandos clásicos de SQL. Nos van a hacer falta unos 4 campos:

  • Un identificador único INTEGER llamado id con autoincremento (no es fundamental, pero nunca está de mas)
  • Un parámetro tipo DATETIME llamémosle fecha
  • Un parámetro tipo REAL llamado valor
  • Un parámetro tipo INTEGER llamado disp. (tampoco es fundamental, pero es práctico para llevar un control de sucesivos dispositivos específicos y no mezclar datos, aparte que me va a servir para simplificar la programación al máximo a efectos explicativos)

El script en PHP es el siguiente, llamémosle /home/pi/consumo.php

#!/usr/bin/php
<?php
if (!function_exists('curl_init')){
die('Sorry cURL is not installed!');
}
$url = "http://ip_raspberry_pi:8083/ZWaveAPI/Run/devices[2].instances[0].commandClasses[49].data[4].val.value";
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
class MiBD extends SQLite3{
function __construct()
{ $this->open('/var/www/razberry.db'); }
}
$bd = new MiBD();
$watios = curl_exec($ch);
$bd->exec("INSERT INTO plug (fecha,valor,disp) VALUES (datetime('now'),$watios,1)");
curl_close($ch);
?>

De aquí solo ver, que hacemos una llamada a la API con cURL para sacar el dato de consumo, y luego insertamos el datos en la tabla junto a la fecha del momento y marcamos el dispositivo número 1 (en este caso el primer dispositivo electrónico que vayamos a medir, luego si cambiamos de sitio el enchufe para domotica Fibaro Wall-plug podemos poner el número 2, 3 y así sucesivamente)

Ahora necesitamos un script para que corra este script en PHP cada 5 segundos, por ejemplo /home/pi/consumo.sh:

#!/bin/sh
(sleep 5 && /home/pi/consumo.php) &
(sleep 10 && /home/pi/consumo.php) &
(sleep 15 && /home/pi/consumo.php) &
(sleep 20 && /home/pi/consumo.php) &
(sleep 25 && /home/pi/consumo.php) &
(sleep 30 && /home/pi/consumo.php) &
(sleep 35 && /home/pi/consumo.php) &
(sleep 40 && /home/pi/consumo.php) &
(sleep 45 && /home/pi/consumo.php) &
(sleep 50 && /home/pi/consumo.php) &
(sleep 55 && /home/pi/consumo.php) &
(sleep 60 && /home/pi/consumo.php)

Lo admito: La elegancia programando no es lo mío, no me acordaba muy bien cómo eran los parámetros en Bash y prefería invertir el tiempo en esta entrada, que en dejarlo todo óptimo J

Finalmente vamos a poner este script con una línea en /etc/crontab:

* * * * * root /home/pi/plug.sh

Y ya debería funcionar cada 5 segundos, almacenando los datos de consumo en esos intervalos de tiempo.

Por último y para poner la guinda del pastel, si instalamos el servidor web Apache o LightHTTP como indicaba antes, podríamos tener un básico panel de control en PHP para saber la información que nos reporta esta base de datos (por ejemplo en /var/www/reportes.php)

<?php
class MiBD extends SQLite3
{
function __construct() { $this->open('/var/www/razberry.db'); }
}
$bd = new MiBD();
$resultado = $bd->query("SELECT AVG(valor),COUNT(valor) FROM plug WHERE (fecha > datetime('now','-24 hours')) AND (fecha < datetime('now')) AND (disp = 1)");
$res = $resultado->fetchArray();
$kwh = 0.162; // El coste el KWH de vuestra compañía de Luz
echo "Potencia Media en las ultimas 24 horas: ".$res[0]." W";
echo "<br/> Numero Registros: ".$res[1];
$coste = $res[0]/1000 * $kwh * 24 * 30;
echo "<br/> Coste Mensual: ".$coste." euros";
if (!function_exists('curl_init')){
die('Sorry cURL is not installed!');
}
$url = "http://ip_de_raspberry:8083/ZWaveAPI/Run/devices[2].instances[0].commandClasses[49].data[4].val.value";
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
$watios = curl_exec($ch);
echo "<br/> Consumo Actual: ".$watios." W";
?>

Y ahora me entero que mi emisor térmico efectivamente, no gasta tanto como creía:

Potencia Media en las últimas 24 horas: 150.13031858033 W
Numero Registros: 17273
Coste Mensual: 17.51120035921 euros
Consumo Actual: 282.6000128 W

Espero que os sirva de provecho esta guía para tener un pequeño Z-Wave casero. En un futuro, intentare adquirir algún producto adicional Z-Wave (un sensor de movimiento y una alarma por ejemplo), y planteare “fusionar” el mundo de la Domotica con Asterisk

 

El Terror a las Pantallas Negras

Hoy tenia ganas de escribir sobre algo relacionado a este mundo pero que no demasiado tiene que ver con el mundo Asterisk en particular.

Como bien dice el titulo de este mensaje, hoy estuve reflexionando sobre el terror a las pantallas negras. Es decir, el miedo a las shells, consolas, etc. Desde tiempos inmemoriables, trabajar con sistemas tipo Windows, las pantallas negras se han asociado a problemas en el sistema, o momentos de arranque. Pero… y si durante el arranque nunca se llegaba a pasar de esa pantalla negra? En el mundo de la administracion de sistemas, para el usuario comun seria asi como “Mi ordenador no enciende, se me queda en la pantalla negra”.

Pero ahora este mensaje lo percibo desde el punto de vista del administrador de sistemas, especialmente el administrador Linux, que debe lidiar diariamente con pantallas negras por todas partes. Pero personalmente sigo sufriendo un poco del momento “Windows” y el estress de ¿ahora que hacer sin mi gestor de ventanas?.

Por un lado creo que es motivacion de que se pierde la puerta a la informacion absoluta: Internet (aunque existan alternativas tipo Lynx, son demasiado odiosas para ser ciertas).

Hoy por ejemplo, en en una de mis estaciones de trabajo, he querido actualizar el Kernel para obtener una nueva funcionalidad (OpenVZ funcionando sobre un kernel 2.6.32) y tras la actualizacion, al reiniciar, mil errores varios (faltaban las nuevas cabeceras del Kernel en el area de compilacion) y tras una carga de mas del triple de lo normal, el sistema de ventanas no arrancaba.

Pero pensando en frio, la solucion llego rauda:

1. Arrancar la shell, editar el fichero xorg.conf para utilizar un driver sencillo, el “Vesa” por ejemplo es infalible. Ademas en la Sub Seccion del Driver de Pantalla, colocar una resolucion fiable, “1280×1024” para tener las cosas mas claras (Mode “1280×1024”)

2. Iniciar las X, “startx”

3. Ahora si arrancan, es momento de acceder al navegador para descargar algo que pueda solucionar la vida. En mi caso, analizando el error del arranque del gestor anterior, observe que daba un problema al intentar cargar el driver fglrx de la grafica ATI. Esto probablemente fuera, porque aun no estaba “cargado” en el nuevo Kernel.

4. Aprovecho y me bajo el ultimo driver propietario de ATI y lo instalo. Una de las instalaciones mas sencillas del sistema. Una cosa curiosa es que he observado que debo ejecutarlo en modo shell con un superusuario. Algo asi como:
# sudo su –
# sh driver_ati_utlimo.run
He probado en otras ocasiones a instalar con la GUI integrada en el propio sistema de ventanas y parece que no ejecuta por alguna razon, exactamente la misma operacion.

5. Finalmente volver a reeditar el fichero xorg.conf para que apunte al nuevo recien cargado driver fglrx y reiniciar el Equipo para comprobar…

Que arrancan las X en Alta Definicion. Vaya por dios.

Escribo esto un poco como auto-reflexion, para recordarme a mi mismo que en esos momentos que llega la pantalla negra y pienso “ha llegado el momento de formatear”, realmente no es tan critico y existe una salida no muy compleja a apenas unos pocos golpes de teclado.

Tambien escribo esto para no olvidar que este Blog esta diseñado para empezar desde 0, y mejorar la curva de aprendizaje concretamente del sistema Asterisk, pero sinergicamente del sistema base: Linux. Esto no es un tutorial, pero si una aproximacion de una idea de como saber actuar en estos momentos de Terror. Aunque la verdad que estos casos trabajando con Asterisk no deberian de ocurrir demasiado, a no ser que tengamos una Estacion de Trabajo y de Pruebas con Asterisk en Debian, y requiramos la interfaz grafica por ejemplo, como comente en uno de los primer mensajes, para correr un SIP Phone tipo Ekiga.

Una Nueva Maquina para el Sistema

Por razones de la vida, he encontrado una maquina HP Proliant ML 110 de Cuarta Generacion (G4), abandonada en una de las instalaciones. Realmente no estaba abandonada, pero estaba siendo infrautilizada, asi que he decidido tomarla prestada, para cambiarla por el servidor que actualmente estoy utilizando, que es parecido, pero no es HP.

Realmente este servidor no trae nada especial, ya que en realidad la serie ML110 vienen a ser Workstations con procesadores de Servidor, y en este caso una placa que soporta hasta 8GB de memoria ECC DDR2. De igual forma como de momento no estoy llevando el servidor a niveles de produccion, he preferido instalarle buena cantidad de memoria no-ECC para que resulten las cosas como corresponden, ya que originalmente solo traia un modulo de 512Mb DDR2 PC5300 ECC que aunque sea Linux, ya no me convence esta cantidad demasiado para ninguna labor de hoy en dia. He montado 2 memorias de 2Gb DDR2 PC6400 no-ECC en Doble Canal. El resto por defecto de fabrica. Llegado el momento, aqui tambien montare la Tarjeta Digium que envie el otro dia en Garantia ya que posee varios slots  PCI, mas que el PC-Workstation que estaba utilizando con anterioridad (y quiza en un futuro tambien poder montar alegremente la tarjeta de Primario para las pruebas correspondientes)

Este mensaje realmente lo escribo como una primera aproximacion de lo que seria una rapida migracion de sistema, para demostrarme a mi mismo, que aun bajo una caida de mi centralita, la reposicion seria cuestion de minutos/horas desde mi atencion.

En primer lugar, instalo Ubuntu Server, monto el sistema RAID con mdadm y LVM2 encima en tres particiones tal y como se explico en el mensaje:
http://www.10000horas.com/2010/08/08/primer-sistema-base-ubuntu-server-y-md-raid/

En segundo lugar, la instalacion del Sistema Asterisk, paso facil y bastante “automatizado” de momento:
http://www.10000horas.com/2010/08/09/manos-a-la-obra-con-asterisk/

En tercer lugar, en el servidor antiguo simplemente copio los directorios que han incurrido en posibles modificaciones (realmente son unos pocos ficheros, pero me gustaria conservar todos los pequeños cambios y no quiero que se me olvide nada). En modo super usuario en el servidor antiguo:

# cd etc
# tar -cf asterisk.tar asterisk/
# scp asterisk.tar ipdelnuevoservidor:/tmp/
# tar -cf dahdi.tar dahdi/
# scp dahdi.tar ipdelnuevoservidor:/tmp/

NOTA (26/10/2010): Tras ampliar mi abanico de conocimientos he observado que se requieren mas carpetas para migrar el sistema completo. La verdad es que no me lei a fondo la documentacion con respecto a los directorios que utiliza el sistema Asterisk por defecto.

El comando “magico” (agradecimientos a Elio Riojano) para conseguir un backup completo de asterisk: tar cvfj asterisk-backup-`date +%Y%m%d-%H%M%S`.tgz /etc/asterisk /var/lib/asterisk /var/spool/asterisk /etc/dahdi
Seguramente se pueda completar aun mas, pero para mis propositos actuales, me sobra y me basta.

Finalmente, copiamos estos ficheros de nuevo a nuestro directorio /etc del nuevo servidor Asterisk. Aqui voy a dar algunos pasos innecesarios realmente, pero que podrian ser utiles y no son dañinos realmente

# cd /etc
# mv /tmp/asterisk.tar /etc/
# mv /tmp/dahdi.tar /etc/
# mv asterisk/ asterisk.old/ (opcional)
# mv dahdi/ dahdi.old/  (opcional)
# tar -xf dahdi.tar
# tar -xf asterisk.tar

Ahora ya tenemos configurado el sistema tal y como lo teníamos antes. Probamos si funciona y si esta todo correcto, podriamos borrar esos directorios .old o mantenerlos por si necesitamos mirar algo (aunque en teoria para eso esta el directorios de ejemplos (samples) que creamos durante la compilacion, asi que estos datos dejarlos ahi seria innecesario realmente).

Finalmente y opcional hasta este punto, copiar las grabaciones que hicimos (si son de calidad, no es mi caso en este momento)

# tar -cf sounds.tar /var/lib/asterisk/sounds/
# scp sounds.tar ipdelnuevoservidor:/tmp/

Y luego justo al reves, copiamos de tmp a sounds en nuestro nuevo servidor, exactamente igual que hicimos antes con las configuraciones

Hacemos algunas llamadas de pruebas, tanteamos nuestro servidor SIP externo, y en teoria ya deberia estar todo funcionando.

Tiempo estimado total: 2 horas, de las cuales 1 hora y media son desatendidas entre instalaciones y compilaciones.

La verdad que con esta gestion he conseguido autodesmitificarme que la migracion ante una posible incidencia grave, resulta verdaderamente sencilla. Y en este caso ya hemos identificado tres directorios que seriainteresante tenerlos en una rutina de backup eventual para poder reestablecer el sistema en caso de tener problemas, quiza con cron. Ya veremos resumidamente algunas rutinas basicas con cron, para establecer entre otras cosas, actualizaciones de sincronizacion de hora efectivas, y como aqui planteado, backups automaticos.

El dia del Protocolo SIP: Parte 2

Tras el pasado dia haciendo las configuraciones en el archivo de configuracion sip.conf del SIP CHAN ahora procedemos a conectar al sevidor Asterisk los 4 elementos que comentabamos.

En primer lugar, el gran telefono IP Polycom SoundPoint 331, segun el documento de TFOT comenta que la configuracion via administrador web resulta compleja, pero a mi no me lo parecio tanto.

Realmente solo tenemos que configurar con la interfaz del propio telefono, la direccion IP, y los parametros basicos de conexion TCP/IP. Acto seguido conectamos al telefono a traves de su interfaz web con la IP que le hayamos asignado (es conveniente que fuera estatica por si en un futuro necesitamos gestionarlo, o en otro caso asignarle un hostname y poder gestionarlo con nuestro DNS).

Los parametros de acceso por defecto en este tipo de telefonos Polycom son: Usuario “Polycom” y contraseña “456”. Es un poco innecesario que cuente como configure el telefono puesto que hay muchos telefonos diferentes SIP. Voy a comentar la idea en general, y luego nos servira para configurar los otros terminales disponibles.

Primero hay que configurar los parametros SIP. En este caso suelen ser el Outbound Proxy y el Dominio de conexion que son la direccion Ip de nuestro servidor Asterisk, asi mismo como el Puerto que suele ser el 5060 a no ser que por motivos de seguridad hayamos decidido cambiarlo.

Tambien en este caso en el telefono Polycom hay que configurarle las lineas que ofrece, se podrian configurar dos servidores diferentes, con los datos de conexion SIP, es decir el nombre de usuario y contraseña que especificamos antes en el fichero sip.conf y el servidor Asterisk con su puerto correspondiente. Tambien existe una opcion en el Polycom de intercambiar la tecla del segundo servidor (linea 2) para prepararlo como acceso directo al buzon de voz, o incluso otras funciones (Aunque la tecla auxiliar pone “Messages” esta pensado para esto).

En segundo lugar voy adelante con la configuración de un cliente SIP para Linux. En este caso el cliente por defecto que trae el sistema Gnome es Ekiga. Tampoco posee grandes funcionalidades, pero es suficiente como para establecer una conexion SIP a nuestro servidor Asterisk, y su configuracion resulta a priori, extremadamente sencilla. Una nota curiosa que nos comentaron durante el curso en relacion al Ekiga utilizandolo (caso extraño), en el propio servidor donde esta instalada la maquina Asterisk, es que por defecto, realiza la escucha en el Puerto 5060, justamente el mismo puerto SIP que utiliza Asterisk como escucha. Esto provoca una pequeña incompatibilidad que es necesario cambiar, forzando el cambio sea al sistema Asterisk (en el contexto general del sip.conf que comentamos el otro dia, el atributo port=), o cambiandolo en las configuraciones de gnome (comando: gconftool-2 -t integer -s /apps/ekiga/protocols/sip/listen_port 5070).

La cuenta SIP se configura desde Edit > Accounts >> Add.
En nombre ponemos lo que queramos
Protocolo: SIP
Registrar: IP del servidor Asterisk
User: Usuario que hayamos asignado a la extension que deseamos configurar
Password: La contraseña que asignamos

Asimismo resulta sencillo configurar otros softphone para otros sistemas como Windows, el elegido SJ-Phone. Se puede descargar desde la web: http://www.sjlabs.com/sjp.html

Tambien existe un completo manual para Windows: http://www.sjphone.org/doc/SJphone_User_Guide.pdf

Considerar que este softphone tambien sirve para otros sistemas tipo Windows Mobile (Windows CE) y la configuracion resulta igual de sencilla.

En la opciones del programa, la pestaña Profiles (Perfiles), Agregamos uno nuevo del tipo Calls through SIP Proxy. Ahi realmente hace falta configurar poco para que funcione. En Initialization, es interesante picar todas las tres cajas de las dos primeras opciones (Account y PassworD). En la pestaña SIP Proxy solo hace falta rellenar en la mayoria de los casos Domain/Realm con nuestro servidor Asterisk, y opcionalmente el puerto con el formato IP:Puerto. Acto seguido, al guardar la configuracion, e intentar conectar, un cuadro de dialogo aparecera solicitando usuario y contraseña. Aqui es cuando nos validamos con el usuario y la contraseña de la extension configurada en el sip.conf a la que pretendemos acceder.

Finalmente el ejemplo de configuracion de un softphone para Android, el elegido, el famoso SIPDroid que tampoco tiene gran misterio. En el programa, accedermos a Settings > SIP Account Settings.
En Authorization Username, el usuario de la extension y en Password mas de lo mismo
En Server or Proxy, la direccion IP del servidor Asterisk.

El resto probablemente dejandolo como esta sera suficiente, quiza cambiar el puerto SIP del servidor Asterisk si es que es diferente.

Una vez configuradas todas las extensiones, voy a poner aqui un fichero extensions.conf de ejemplo con el que podriamos realizar las primeras llamadas entre extensiones. Proximamente me adentrare mas en el fichero extensions.conf que es el lugar donde se configura el Plan de Marcacion, o DialPlan como comunmente suele llamarse. Este podria considerarse, el cerebro del Asterisk. Es importante manejarse bien en este fichero porque lo aqui puesto, dependera del 90% del exito de nuestro sistema y las posibilidades que a este podramos otorgarle.

El ejemplo sencillo para nuestras nuevas extensiones, ext1000 (Polycom), 1001 (Ekiga), 1002 (SJPhone) y 1003 (SIPDroid). Todavia no me centrare en los contextos, y atributos especificos

[general]
static=yes
writeprotect=no
clearglobals=no
[globals]
POLYCOM => SIP/ext1000
EKIGA => SIP/ext1001
SJPHONE => SIP/ext1002
SIPDROID => SIP/ext1003
[extensiones]
exten => s,1,NoOp()
exten => s,n,WaitExten(8)
exten => 1000,1,NoOp()
exten => 1000,n,Answer
exten => 1000,n,Dial(${POLYCOM})
exten => 1000,n,Hangup
exten => 1001,1,NoOp()
exten => 1001,n,Answer
exten => 1001,n,Dial(${EKIGA})
exten => 1001,n,Hangup
exten => 1002,1,NoOp()
exten => 1002,n,Answer
exten => 1002,n,Dial(${SJPHONE})
exten => 1002,n,Hangup
exten => 1003,1,NoOp()
exten => 1003,n,Answer
exten => 1003,n,Dial(${SIPDROID})
exten => 1003,n,Hangup
Con esto podremos realizar llamadas sencillas marcando una u otra extension, desde una hacia otra sin problemas. Esto es todo por hoy. Estoy dudando cual sera el proximo paso, configuracion de extensiones analogicas con el canal DAHDI o si empezar las primeras andanzas y pruebas con el mundo de los DialPlan. Cualquiera de las dos igual de importante y prioritaria, sera cuanto antes!

Primer Sistema Base: Ubuntu Server y Md Raid

Despues de haber comentado hace unas semanas acerca de la seleccion de Servidor, ahora tocaba la eleccion del Sistema… en este sentido solo habia una cosa clara: El sistema base iria sobre GNU/Linux, el tema a tocar, seria: ¿sobre que distribucion?

Realmente hoy en dia todas las distribuciones son validas, incluso distribuciones basadas en UNIX, desde Open Solaris, incluso distribuciones para dispositivos con un sistema operativo embebido, y cualquier otra distribucion Linux tipo RedHat, OpenSuse y demas.

Pero en el mundo Asterisk tras varias indagaciones y lo aprendido hasta la fecha, las distribuciones mas reconocidas son CentOS y Debian por igual. De todas formas esto no resulta nada nuevo ya que hoy en dia, Centos y Debian se reparten el pastel de los servidores, incluso por encima de Fedora y RedHat Enterprise (se ve que eso de tener casi todo lo de RedHat Enterprisa gratuitamente tira mas que dos carretas… ¿o era otra cosa lo que tiraba mas que dos carretas?).

Debian es para mi personalmente, la distribución que mas he rozado desde mis inicios en el mundo Linux. Coincido con mucha gente decidiendome para todas mis inicios en cualquier sistema basado en Linux por decantarme siempre por Debian. En el ejemplo de la Virtualizacion que puse la semana pasada, KVM alojado en Linux, y adoptado por RedHat, yo lo utilizo personalmente sobre maquinas Debian, concretamente una distribucion basada en esta ultima llamada Proxmox que agrega multiples funcionalidades especificas de la virtualizacion con KVM en si.

Pero realmente, existe una distribución dentro del mundo Debian que simplifica masivamente la vida de configuracion a nivel Hardware. Esta es Ubuntu Server como indica el titulo. Es cierto que a dia de hoy no es una personoficacion de la optimizacion de los recursos del sistema ya que de por si añade un consumo “cabecera” (overhead) a la CPU que no es nada positivo para un sistema especifico con una funcion especifica, como cumplira en este caso lo que aqui estamos tratando, un sistema PBX.

Pero ahora volviendo atras al momento de la decision de configuracion de Hardware me encontraba con una simple cuestion: nuestra maquina de pruebas, tampoco iba a servir como un sistema de proposito especifico y de alto rendimiento. No es mi intencion de servir como Call Center para cubrir 500 llamadas simultaneas. Ademas Asterisk infraescalado, ni aun con un sistema como Ubuntu, seria capaz de soportar esto. Es por esto quiza, por lo que la facilidad de “auto”-configuracion del Hardware en el sistema fue por ultimo mi decision final de utilizar Ubuntu Server como sistema.

Tras instalar Ubuntu Server pude comprobar como practicamente todo el Hardware fue reconocido, y autoconfigurado, desde la Controladora RAID, hasta la VGA en alta resolucion (no es gran cosa, pero personalmente me resulta muy util trabajar en 1920×1080 incluso en consola si el sistema ofrece esta posibilidad como es el caso. Solo le hubiera faltado reconocer la tarjeta Digium B410P (hubiera sido el colmo ya).

La segunda parte quiza mas significativa de la configuracion del sistema fue la del planteamiento de estabilidad del sistema a nivel de Disco Duro. Comente en su dia que disponia de dos discos duros de semejantes caracteristicas, por lo que se veia forzada la necesidad de montar un RAID. Pero tras mucho indagar me di cuenta, que las mayoria de las placas base, a pesar de traer un controlador RAID, realmente no es un controlador puro y dedicado como podrian ser los controladores PERC de Dell. Considero un controlador dedicado, a ese controlador capaz de liberar a la CPU de la carga de realizar todas las tareas para que el RAID se viera satisfecho. En este caso mi intencion era montar un RAID 1.

En general la mayoria de las placas base suelen traer controladores Silicon Image, ATI Nvidia, VIA, etc, pero realmente no dejan de ser controladores de tipo software, gestionados desde la BIOS con solo las caracteristicas basicas para poder proveer de informacion suficiente de como deberia trabajar (pero no capaces de trabajar por si mismos). Esto podria resultar interesante, excepto por una cuestion muy importante: Si esta controladora se averiase (o si la misma placa se averiase), necesitariamos para recomponer ese RAID una controladora Exactamente Igual, o de semejantes caracteristicas, capaz de recomponer eso. Hoy en dia, esto puede resultar excesivamente dificil, ya que la mayoria de las piezas quedan descatalogadas en apenas 2 años, y pese a que continua su produccion, a partir de los 4 años es practicamente imposible conseguir una a no ser que la busquemos a traves de un Broker, o la localicemos de casualidad de Segunda Mano o que la pidamos a la marca BAJO DEMANDA (con un coste 10 veces mas caro de lo que costo originalmente). Esta dependencia al Hardware, para mi me resulta inviable. Si tuvieramos la opcion de tener controladoras especificas como las PERC de Dell que siguen ciertos estandares al menos dentro de la misma marca, y que su produccion se extiende mas alla de los 5 años, ademas de ofrecer un hardware dedicado y liberando a la CPU de esta carga, entonces definitivamente si podria decidir, que merece totalmente la pena.

Entonces, si tengo dos discos duros iguales, y mi intencion es montar un RAID 1 …. ¿cual es la resolucion?

Pues volviendo al titulo, GNU/Linux provee la solucion, Md Raid, con mdadm. El RAID software por excelencia de Linux.

Vamos un poco a la practica. Para configurar esto en un sistema de “bajo calibre” la idea es muy sencilla:

Ubuntu ofrece en el propio instalador la opcion de configurar esto de manera grafica. En cualquier caso, por si a alguien le interesara configurarlo en modo Consola la idea seria la siguiente:

1. Para cada disco tenemos que crear primero una particion de tipo RAID arrancable (exactamente iguales, ocupando el disco completo, y con el flag B de bootable).
Podriamos utilizar una herramienta de particionado tipo cfdisk. Simplemente, toca, crear una nueva particion con new, en Tipo, ponerle fd (Particion Linux Raid), en flag, ponerle bootable, y finalmente “Write” para escribir las modificaciones sobre la particion. Repetir este proceso para el otro disco.

2. En segundo lugar, toca “instalar” el Raid software con mdadm. En el instalador simplemente hay que especificar algunos parametros, como el tipo de raid (1, mirror, espejado, misma informacion en los dos discos duros), el numero de discos involucrados, el numero de discos sobrantes (Spares, como en el sistema JBOD por si acaso) y seleccionar los discos involucaros. Y el sistema raid estara listo en unos segundos.
En el caso shell es quiza aun mas sencillo:
Considerando que los discos son SDA y SDB (sata disk A y sata disk B siendo ambos discos tipo sata, si fuera IDE/PATA, seria hda, y hdb)
mdadm –create /dev/md0 –level=1 –raid-devices=2 /dev/sda1 /dev/sdb1 (el 1 es la particion 1 que creamos anteriomente, una sola particion).
En este caso habremos llamado a nuestro recien creado RAID md0 a nivel de sistema.

3. Acto seguido, toca particionar nuestro recien creado RAID. En este caso, seria como si tuvieramos un solo disco duro. Podriamos directamente particionarlo con ReiserFS, Ext3 o Ext4, o podriamos elegir un formato mas avanzado como LVM2. Yo personalmente soy mas partidario de utilizar LVM a cualquier costa. ¿Porque? Por la opcion de hacer una copia de seguridad del sistema completo utilizando Snapshots.

Recuerden, un RAID1 aunque ayuda al uptime del servidor, ya que aunque haya un error de disco, el sistema seguria en pie, no asegura que la informacion se destruya en un momento determinado (o peor aun, se corrompa). La unica forma de preservar la fiabilidad de la informacion (y de echar marcha atras rapidamente en caso que un dia hagamos algo indebeido), es utilizar las copias de seguridad. Y los snapshots de LVM son la forma idonea de realizarlas sin tener que parar el sistema, y mantener el 100% de Uptime en nuestro sistema.

Eso es todo por hoy. Seguramente haya obviado algunos detalles interesantes. Cualquier sugerencia para explicacion, no dudeis en comentarla!

Extra:

Hoy 30 de Agosto 2010, escribo un pequeño Plus para este Sistema. El metodo de Particionamiento dentro del sistema LVM que yo he seguido

En primer lugar, una particion para el sistema de arranque. Esto no es estrictamente necesario pero, realmente es una buena practica poner el sistema de arranque en un tipo de particion mas sencilla como ext2 que la particion del sistema principal, que en este caso seria ext4. Yo suelo darle bastante cantidad de espacio, del orden de 10 veces mas de lo que necesita. Con 50 Mb es suficiente, pero si en un momento determinado vamos cargando multiples kernels para cualquier asunto, o actualizaciones sucesivas, y no tener la necesidad de ir borrando lo antiguo, suelo poner 512Mb. Con los discos duros de hoy en dia no supone un gasto indebido y me curo en salud

En segundo lugar el espacio Swap. Hay que considerar una cosa: Si tenemos que utilizar el sistema Swap en nuestra maquina Asterisk, vamos a tener SERIOS problemas. Yo personalmente podria 0 Mb. Pero con mi politica de reservar memoria para todo y que en un momento dado, aunque el sistema vaya mal, al menos no vaya a Pique con facilidad, me gusta reservar tanta memoria Swap como memoria RAM disponible haya.

El resto, volumen principal, en ext4 que es el mas nuevecito en estos momentos, y funciona perfectamente. Los sistemas Ubuntu lo permiten y Asterisk funciona perfectamente en este tipo de sistema.

Sabia que podia completar mas este mensaje, y asi lo he hecho.