En la anterior entrega de este tutorial describimos el proyecto de integración del controlador eedomus con HomeKit de Apple, además pudimos ver los requisitos necesarios y detallamos el proceso de instalación previo para tener un entorno lo más estable posible para HomeKit.
En esta segunda parte nos vamos a centrar en la instalación de las aplicaciones dentro de nuestra Raspberry Pi y la configuración del plugin para eedomus.
Si habéis llegado hasta aquí, es que ya tenéis la Raspberry Pi con la distribución Raspbian y Jessie como versión.
No todos los requisitos que hemos comentado y que comentaremos a continuación son extrictamente necesarios, pero como decimos, es lo que mejores resultados y más estabilidad nos ha ofrecido a la hora de ejecutar homebridge y el plugin de eedomus.
Instalación de homebridge en la Raspberry Pi
Si no lo hemos hecho antes, en los pasos del anterior artículo, es recomendable actualizar los paquetes a su última versión.
Estos pasos los vamos a realizar ya con nuestro usuario (por ejemplo, pi), así que debemos añadir el comando “sudo” antes de cada comando para disponer de permisos de “root” en la ejecución:
# sudo apt-get update # sudo apt-get upgrade
Ahora vamos a instalar las dependencias previas. Estas dependencias previas son paquetes o aplicaciones necesarias para el ecosistema que estamos instalando.
Empezamos instalando los paquetes NodeJS, npm y node-semver:
# sudo apt-get install nodejs npm node-semver
Este comando se encargará de descargarse los paquetes e instalarlos. Nos avisará en caso de que ya lo tengamos instalado, aunque con una instalación limpia no lo estarán.
Instalamos el paquete node:
# wget https://nodejs.org/dist/v4.2.2/node-v4.2.2-linux-armv7l.tar.gz # tar -xvf node-v4.2.2-linux-armv7l.tar.gz # cd node-v4.2.2-linux-armv7l # sudo cp -R * /usr/local/
Comprobamos que tenemos la versión 4.2.2 de node o posterior:
pi@raspi ~ $ node -v v4.2.2
Instalamos el paquete Avahi:
# sudo apt-get install libavahi-compat-libdnssd-dev
Este paquete lo podemos denominar como de “autodescubrimiento”. Para no entrar mucho en detalle, se trata de una especie de multicast de DNS que se utilizará dentro de HAP-NodeJS (implementación NodeJS de HomeKit Accessory Server que utiliza homebridge).
Instalación de homebridge
Homebridge lo instalaremos desde los repositorios de npmjs ejecutando:
# sudo npm install -g homebridge
Una vez instalado, ya podemos probar a ejecutarlo (como usuario pi, esta vez no haría falta utilizar sudo):
pi@raspi ~ $ homebridge *** WARNING *** The program 'node' uses the Apple Bonjour compatibility layer of Avahi. *** WARNING *** Please fix your application to use the native API of Avahi! *** WARNING *** For more information see <http://0pointer.de/avahi-compat?s=libdns_sd&e=node> *** WARNING *** The program 'node' called 'DNSServiceRegister()' which is not supported (or only supported partially) in the Apple Bonjour compatibility layer of Avahi. *** WARNING *** Please fix your application to use the native API of Avahi! *** WARNING *** For more information see <http://0pointer.de/avahi-compat?s=libdns_sd&e=node&f=DNSServiceRegister> No plugins found. See the README for information on installing plugins.
Es normal que aparezcan esos WARNING, los vamos a ver cada vez que arranquemos homebridge.
La última línea nos indica que no ha encontrado ningún plugin instalado, así que vamos al siguiente punto para instalar nuestro plugin.
Instalación del plugin para eedomus.
Los plugins para homebridge son módulos NodeJS publicados en github o en npmjs y tagueados con el texto “homebridge-plugin“. Deben tener el prefijo “homebridge-” en el nombre para poder funcionar con homebridge.
En nuestro caso, he creado un plugin para que sea posible la interacción entre nuestro controlador eedomus, la aplicación homebrige y la plataforma HomeKit de Apple: homebridge-eedomus
Para instalarlo, simplemente tenemos que ejecutar:
# sudo npm install -g homebridge-eedomus
Si todo ha ido bien, deberemos tener una salida similar a esta:
pi@raspi ~ $ npm install -g homebridge-eedomus homebridge-eedomus@0.0.1 /usr/local/lib/node_modules/homebridge-eedomus └── request@2.69.0 (aws-sign2@0.6.0, forever-agent@0.6.1, tunnel-agent@0.4.2, is-typedarray@1.0.0, caseless@0.11.0, oauth-sign@0.8.1, stringstream@0.0.5, isstream@0.1.2, json-stringify-safe@5.0.1, extend@3.0.0, tough-cookie@2.2.1, node-uuid@1.4.7, qs@6.0.2, combined-stream@1.0.5, form-data@1.0.0-rc3, aws4@1.2.1, bl@1.0.3, hawk@3.1.3, mime-types@2.1.10, har-validator@2.0.6, http-signature@1.1.1)
Más adelante, en el otra parte del tutorial, veremos cómo instalar otros plugins para controlar otros dispositivos.
Los plugins instalados y el propio homebridge, los podremos encontrar en nuestra Raspberry en el directorio:
/usr/local/lib/node_modules/
Dentro de cada plugin, podremos encontrar también sus propias dependencias, es decir, otros programas necesarios para su funcionamiento. En nuestro caso, para el plugin de eedomus, la única dependencia como podéis ver un poco más arriba es “request“, pero esto se instalará automáticamente.
Los plugins a su vez pueden contener otras dependencias dentro, pero todo esto también se habrá instalado de forma automática. En el caso de “request” son las que aparecen también arriba (forever, extend, etc).
Configuración inicial del plugin homebridge-eedomus
En este paso, crearemos el fichero “config.json” que contendrá nuestros módulos y dispositivos, por los que homebridge preguntará a eedomus.
Vamos a crear uno simple, para comprobar que homebridge arranque sin problemas.
Mucho ojo con el editor que utilicemos para crear este fichero, los editores como TextEdit de Mac o Wordpad de Windows pueden insertar caracteres que no son legibles o que impiden su correcta lectura.
Hay múltiples editores de “texto plano”. Yo, personalmente, utilizo el editor vi de linux, aunque si no tienes mucha práctica puedes utilizar el editor pico, que también viene por defecto instalado. Si tienes windows puedes utilizar algún editor tipo Ultraedit y después llevarte el fichero a la Raspberry Pi.
Al instalar el plugin homebridge-eedomus, os debería haber creado un fichero llamado “config-sample.json”. Este fichero es un buen punto de partida para añadir vuestros módulos. Incluye un módulo de cada tipo:
- Switch -> Para dispositivos tipo ON/OFF
- WindowCovering -> Para controlar los módulos de persiana
- TemperatureSensor -> Para obtener información de sensores de temperatura
- Light -> Para control de luces ON/OFF o regulables en intensidad
En un futuro espero ir añadiendo más tipos de módulos.
Pero antes de crear el fichero, necesitamos conocer los siguientes datos:
- Dirección IP (privada) de nuestro eedomus: En secure.eedomus.com -> Configuración -> Controlador: aparece como sitio local. Es importante que configuremos nuestro controlador eedomus con una dirección IP estática para que ésta no cambie. Si no tenéis claro como hacerlo, tenéis aquí toda la información.
- Código API del módulo: Cada módulo, tiene asociado un identificador único. Para la primera prueba, vamos a sacar el periph_id de uno de ellos, en mi ejemplo he utilizado el de uno de los enchufes de la regleta Greenwave: Configuración -> nuestro módulo -> Configurar -> Parámetros Experto -> Código API (busca el código de uno de tus dispositivos, que sea de tipo ON/OFF, como puede ser un módulo Fibaro 2×1)
- Usuario y contraseña para la API: Si no tenemos, o no lo conocemos, en este enlace Philippe explica como hacerlo.
Ahora, tenemos que ir al directorio oculto .homebridge de nuestro usuario, en mi caso: pi
# cd /home/pi/.homebridge/
Una vez aquí, podemos copiar el fichero de ejemplo que incluyo con la instalación del paquete homebridge-eedomus. Sería así:
# cp /usr/local/lib/node_modules/homebridge-eedomus/config-sample.json /home/pi/.homebridge/config.json
Ahora podremos editar el fichero, reemplazando los valores comentados arriba y quitando los accesorios que no vayamos a utilizar de momento.
La configuración para la primera prueba, debería quedar algo así:
{
"bridge": {
"name": "Homebridge",
"username": "CC:22:3D:E3:CE:30",
"port": 51826,
"pin": "031-45-154"
},
"description": "This is an example configuration file with one fake accessory and one fake platform. You can use this as a template for creating your own configuration file containing devices you actually own.",
"credentials": {
"ip" : "your_local_eedomus_ip",
"api_user" : "your_eedomus_api_user",
"api_secret" : "your_eedomus_api_secret"
},
"accessories": [
{
"accessory": "eedomus",
"name": "Television Salon",
"periph_id": "255356",
"service": "Switch"
}
]
}
Mi recomendación es que vayáis poco a poco, probéis a incluir un módulo y lo probéis bien.
Estos son los distintos apartados que tenemos dentro de la configuración:
- “bridge“: es la configuración que vamos a enviar de homebridge a HomeKit, con el nombre, usuario, puerto y código PIN para HomeKit.
- “description“: no hace falta cambiar nada, es una descripción por defecto.
- “credentials“: configuración eedomus: IP y usuario y contraseña de la API.
- “accessories“: dispositivos a registrar.
Son personalizables, pero es recomendable dejar puestos los arriba indicados (salvo por supuesto, los del apartado “credentials“). Veremos más adelante como sí que sería recomendable o necesario cambiar el “username” en caso de que tengamos que borrar la asociación de homebridge y crear una nueva.
El “pin” es el número que nos pedirá más adelante la aplicación iOS para registrar el dispositivo homebridge.
En el apartado “accessories” vamos a dar de alta los dispositivos que queremos integrar en homebridge. Es decir, tendremos cada módulo como un accesorio con el que interactuaremos a través de Siri. Debemos reemplazar los siguientes datos con los de nuestro módulo:
- “accessory“: aquí siempre utilizaremos “eedomus”
- “name“: nombre del primer dispositivo que queramos integrar para las pruebas
- “periph_id“: el identificador de nuestro dispositivo, es el código API del módulo.
- “service“: De momento, para esta prueba, utilizaremos solo un módulo que tenga como parámetros ON/OFF, así que lo dejaremos como “Switch“
Hasta aquí esta segunda entrega, en la siguiente arrancaremos la aplicación y realizaremos las primeras pruebas.
He instalado raspbian (la ultima versión del 9 de febrero). He seguido todos los pasos hasta llegar a instalar homebridge, en donde me suelta esto y no lo instala. Lo extraño es que estoy usando sudo
pi@raspberrypi:~ $ sudo npm install -g homebridge
> curve25519@1.1.0 install /usr/local/lib/node_modules/homebridge/node_modules/hap-nodejs/node_modules/curve25519
> node-gyp rebuild
gyp WARN EACCES user “root” does not have permission to access the dev dir “/root/.node-gyp/4.2.2”
gyp WARN EACCES attempting to reinstall using temporary dev dir “/usr/local/lib/node_modules/homebridge/node_modules/hap-nodejs/node_modules/curve25519/.node-gyp”
gyp WARN install got an error, rolling back install
gyp WARN install got an error, rolling back install
gyp ERR! configure error
gyp ERR! stack Error: ENOSPC: no space left on device, mkdir ‘/usr/local/lib/node_modules/homebridge/node_modules/hap-nodejs/node_modules/curve25519/.node-gyp’
gyp ERR! stack at Error (native)
gyp ERR! System Linux 4.1.17-v7+
gyp ERR! command “/usr/local/bin/node” “/usr/local/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js” “rebuild”
gyp ERR! cwd /usr/local/lib/node_modules/homebridge/node_modules/hap-nodejs/node_modules/curve25519
gyp ERR! node -v v4.2.2
gyp ERR! node-gyp -v v3.0.3
gyp ERR! not ok
ya lo solucioné, era por no haber expandido el sistema al instalar Raspbian >_<
Si, el error que te daba era por haberse quedado sin espacio.
El otro día instale otra raspbian y me pasó lo mismo. Con la primera no recuerdo haber tenido que expandirlo.
Por si le ocurre a alguien más, basta con ejecutar “sudo raspi-config” y elegir la primera opción (Expand Filesystem) para utilizar todo el espacio de la tarjeta SD.
No soy capaz de instalar el paquete node. Me podeis ayudar?
Enlace a la tercera parte del tutorial:
https://www.domoticadomestica.com/integracion-del-controlador-eedomus-homekit-parte-3/
Una pregunta, Carlos ¿La dirección MAC que aparece como “username” del archivo config.json es siempre la misma o es la de nuestro eedomus o Raspberry Pi o algún aparato que tengamos?
“bridge”: {
“name”: “Homebridge”,
“username”: “CC:22:3D:E3:CE:30”,
“port”: 51826,
“pin”: “031-45-154”
GRACIAS!
Hola Eduardo, no había visto tu pregunta.
Esa dirección MAC no es real, puedes cambiarla sin problema. Es más (creo que lo comenté en alguno de los artículos), cuando tienes algún problema con homebridge una de las soluciones es volver a darlo de alta, cambiando justamente esta “MAC”, por ejemplo cambiando el 30 del final por un 31.
Distintos tipos de “services”, por si a alguien le interesa:
AccessoryInformation – Provides information about the given home automation device (accessory).
AirQualitySensor – Defines an air quality sensor.
Battery – Defines the state of an accessory’s battery.
CarbonDioxideSensor – Defines a carbon Dioxide Sensor.
CarbonMonoxideSensor – Defines a Carbon Monoxide Sensor.
ContactSensor – Defines a contact sensor (such as a window being opened or closed).
Door – Defines a door state sensor (such as opened or closed).
Fan – Defines a remote controlled fan.
GarageDoorOpener – Defines a garage door opener.
HumiditySensor – Defines a humidity sensor.
LeakSensor – Defines a leak sensor (like for a hot water heater or washing machine).
LightBulb – Defines a stand alone light or a light that is part of another accessory (like a garage door opener).
LightSensor – Defines a light sensor.
LockManagement – Defines a service that manages an automated door lock.
LockMechanism – Defines a remote controlled lock (like a door lock).
MotionSensor – Defines a motion sensor.
OccupancySensor – Defines an occupancy sensor.
Outlet – Defines a remote controlled wall outlet.
SecuritySystem – Defines a home security system.
StatefulProgrammableSwitch – Defines a programmable switch that remains in a give state once triggered (like a flip switch).
StatelessProgrammableSwitch – Defines a programmable switch that returns to its initial state after being triggered (like a push button).
SmokeSensor – Defines a smoke sensor.
Switch – Defines an on/off switch like a standard wall switch.
TemperatureSensor – Defines a temperature sensor.
Thermostat – Defines a smart thermostat used to control an HVAC system.
Window – Defines an automated window that cane be remotely opened or closed.
WindowCovering – Defines a remotely controlled window covering, like blinds that can be opened or closed.
Vaya, pensé que ya estaban implementados más tipos.
¿Se pueden añadir de alguna forma toqueteando código?
Me interesan, sobre todo, los siguientes, para ir incluyendo las últimas adquisiciones:
GarageDoorOpener
MotionSensor
Thermostat
LightSensor
Door
AccessoryInformation
ContactSensor
SmokeSensor
Gracias Carlos.
Si, aparecieron al finales del año pasado. Estaba trabajando en implementarlos cuando se me ocurrió la brillante idea de comprarme un portátil nuevo y vender mis ordenadores, así que estuve una temporada sin ordenador en casa.
Ya tengo en la versión que estoy probando alguno de ellos funcionando, a ver si puedo dedicarle algo más de tiempo y os voy comentando por el foro.
Puedes confirmar si hay mas accesorios ademas de las luces, sensores temperatura, interruptores y persianas.
Si por ejemplo configuro algun dispositivo como Door ya no me carga el homebridge