Nuevo dominio trasteandoarduino.com

Tras un tiempo escribiendo en este blog, creo que ha llegado el momento: me mudo a mi propio dominio trasteandoarduino.com, espero que allí os encontréis al menos igual de cómodos que aquí y podamos llevar entre todos este blog un paso más allá.

¡Un saludo a todos!

OpenHAB en Raspberry Pi: Configurando RFXCOM (parte 4)

NOTA: Este blog se ha trasladado a trasteandoarduino.com.

En esta entrada vamos a explicar como configurar el transceptor RFXtrx433 de RFXCOM para funcionar con openHAB.

Módulo RFXtrx433

En primer lugar hay que decir que el módulo RFXtrx433 es un emisor/receptor de señales RF en la banda de 433.92Mhz con conexión USB, que es capaz de decodificar muchos protocolos usados por interruptores, enchufes, estaciones meteorológicas, medidConfigurando el dispositivoores de energía... Entre todos esos protocolos se encuentra el usado por los enchufes que analicé aquí, aquí y aquí. El protocolo usado lo identifica como Impuls.

Configurando el dispositivo

Como se trata de un dispositivo USB cuando lo conectemos al equipo lo reconocerá como /dev/ttyUSB0 unas veces, otras como /dev/ttyUSB1... dependiendo de los dispositivos USB que tengamos en ese momento conectados. Para evitar ese baile de nombres vamos a definir una regla udev para que siempre lo tengamos como /dev/rfxcom.

Lo primero que hay que hacer es identificar nuestro dispositivo univocamente, que no haya posibilidad de error. Para ello usamos el comando:

udevadm info -a -p  $(udevadm info -q path -n /dev/ttyUSBx)

cambiando la x por el número que tenga nuestro dispositivo en el momento de conectarlo. Obtendremo un listado largo que contendrá algo así:

  ...
  looking at parent device '/devices/platform/bcm2708_usb/usb1/1-1/1-1.2':
    KERNELS=="1-1.2"
    SUBSYSTEMS=="usb"
    DRIVERS=="usb"
    ATTRS{bDeviceSubClass}=="00"
    ATTRS{bDeviceProtocol}=="00"
    ATTRS{devpath}=="1.2"
    ATTRS{idVendor}=="0403"
    ATTRS{speed}=="12"
    ATTRS{bNumInterfaces}==" 1"
    ATTRS{bConfigurationValue}=="1"
    ATTRS{bMaxPacketSize0}=="8"
    ATTRS{busnum}=="1"
    ATTRS{devnum}=="4"
    ATTRS{configuration}==""
    ATTRS{bMaxPower}==" 90mA"
    ATTRS{authorized}=="1"
    ATTRS{bmAttributes}=="a0"
    ATTRS{bNumConfigurations}=="1"
    ATTRS{maxchild}=="0"
    ATTRS{bcdDevice}=="0600"
    ATTRS{avoid_reset_quirk}=="0"
    ATTRS{quirks}=="0x0"
    ATTRS{serial}=="A1WR621M"
    ATTRS{version}==" 2.00"
    ATTRS{urbnum}=="16"
    ATTRS{ltm_capable}=="no"
    ATTRS{manufacturer}=="RFXCOM"
    ATTRS{removable}=="removable"
    ATTRS{idProduct}=="6001"
    ATTRS{bDeviceClass}=="00"
    ATTRS{product}=="RFXtrx433"
  ...

De entre toda esta información del dispositivo debemos elegir algo que nos identifique al dispositivo. Se puede elegir el serial, o la combinación idVendor/idProduct... Lo más normal es elegir esto último.

Creamos el fichero /etc/udev/rules.d/10-local.rules con el siguiente contenido:

ACTION=="add",ATTRS{idVendor}=="0403",ATTRS{idProduct}=="6001",SYMLINK+="rfxcom"

Si desconectamos el dispositivo y lo volvemos a conectar nos debería aparecer el enlace /dev/rfxcom automágicamente enlazado al correspondiente /dev/ttyUSBx.

El addon RFXCom para openHAB utiliza la librería RxTx para acceder a los puertos serie del equipo, la cual no funciona demasiado bien con los dispositivos no estandares en /dev. Para solventar este inconveniente hay que decirle a openHAB que le diga a la librería RxTx que /dev/rfxcom es un dispositivo serie válido. Y ¿cómo lo hacemos? Fácil, hay que ir a los archivos start.sh y start_debug.sh para añadir en la última linea, la que inicia el programa con java... el siguiente parámetro:

-Dgnu.io.rxtx.SerialPorts=/dev/rfxcom

Tenéis mas informacion sobre la forma en que la librería RxTx detecta o lista los puertos serie del equipo aquí.

 

Primeras pruebas

Una vez que tenemos el dispositivo listo, y localizado, necesitamos hacer alguna prueba para ver si funciona correctamente. Para ello nos bajamos el software rfxcmd de aquí, y lo descomprimimos en una carpeta:

mkdir rfxcmd
cd rfxcmd
wget http://rfxcmd.googlecode.com/files/rfxcmd-v024.zip
unzip rfxcmd-v024.zip -d v024
cd v024

Al intentar ejecutarlo nos dice que falta la extensión Serial de python. La instalamos:

apt-get install python-serial

y continuamos con las pruebas poniendo el modulo en escucha continua:

./rfxcmd.py -d /dev/rfxcom

nos da la siguiente salida si todo ha ido bien:

RFXCMD version 0.24
------------------------------------------------
Received        = 0D 01 00 00 02 53 43 00 40 00 01 01 00 00
Date/Time        = 2013-10-02 12:22:50
Packet Length        = 0D
Packettype        = Interface Message
Subtype            = Interface response
Sequence nbr        = 00
Response on cmnd    = Get Status, return firmware versions and configuration of the interface.
Transceiver type    = 433.92MHz (Transceiver)
Firmware version    = 67
Display undecoded    = Off
Protocols:
Disabled        AE (433.92)
Disabled        Rubicson (433.92)
Disabled        FineOffset / Viking (433.92)
Disabled        RFU3
Disabled        RFU4
Disabled        RFU5
Disabled        RFU6
Disabled        Mertik (433.92)
Disabled        AD (433.92)
Disabled        Hideki/UPM (433.92)
Disabled        La Crosse (433.92/868.30)
Disabled        FS20 (868.35)
Disabled        ProGuard (868.35 FSK)
Enabled            BlindsT0 (433.92)
Disabled        BlindsT1/T2/T3 (433.92)
Disabled        X10 (310/433.92)
Disabled        ARC (433.92)
Disabled        AC (433.92)
Disabled        HomeEasy EU (433.92)
Disabled        Meiantech (433.92)
Disabled        Oregon Scientific (433.92)
Disabled        ATI (433.92)
Disabled        Visonic (315/868.95)

Configuración del addon RFXCom

Para que funcione el addon tenemos copiar el archivo jar en la carpeta de addons, y modificar en el fichero de configuración openhab.cfg el nombre del puerto serie que se usará para conectar con el dispositivo:

rfxcom.serialPort=/dev/rfxcom

Ahora podemos arrancar openHAB en modo depuración con start_debug.sh y ver los registros del addon, que serán algo parecido a esto:

root@raspberrypi:/opt/openhab# ./start_debug.sh
Launching the openHAB runtime in debug mode...
Listening for transport dt_socket at address: 8001
osgi> 08:49:54.236 DEBUG o.o.c.s.i.SchedulerActivator[:56] - Scheduler has been started.
08:49:54.866 INFO  o.q.impl.StdSchedulerFactory[:1175] - Using default implementation for ThreadExecutor
08:49:55.208 INFO  o.q.core.SchedulerSignalerImpl[:61] - Initialized Scheduler Signaller of type: class org.quartz.core.SchedulerSignalerImpl
08:49:55.215 INFO  o.quartz.core.QuartzScheduler[:243] - Quartz Scheduler v.2.1.7 created.
08:49:55.244 INFO  org.quartz.simpl.RAMJobStore[:154] - RAMJobStore initialized.
08:49:55.268 INFO  o.quartz.core.QuartzScheduler[:268] - Scheduler meta-data: Quartz Scheduler (v2.1.7) 'openHAB-job-scheduler' with instanceId 'NON_CLUSTERED'
  Scheduler class: 'org.quartz.core.QuartzScheduler' - running locally.
  NOT STARTED.
  Currently in standby mode.
  Number of jobs executed: 0
  Using thread pool 'org.quartz.simpl.SimpleThreadPool' - with 2 threads.
  Using job-store 'org.quartz.simpl.RAMJobStore' - which does not support persistence. and is not clustered.

08:49:55.281 INFO  o.q.impl.StdSchedulerFactory[:1324] - Quartz scheduler 'openHAB-job-scheduler' initialized from specified file: './etc/quartz.properties'
08:49:55.287 INFO  o.q.impl.StdSchedulerFactory[:1328] - Quartz scheduler version: 2.1.7
08:49:55.297 INFO  o.quartz.core.QuartzScheduler[:534] - Scheduler openHAB-job-scheduler_$_NON_CLUSTERED started.
08:49:55.342 DEBUG o.o.c.core.ConfigDispatcher[:166] - Processing openHAB default configuration file '/opt/openhab/configurations/openhab_default.cfg'.
08:49:55.979 DEBUG o.o.c.core.ConfigDispatcher[:188] - Processing openHAB main configuration file '/opt/openhab/configurations/openhab.cfg'.
08:49:56.262 DEBUG o.o.c.internal.CoreActivator[:124] - UUID file already exists at '/opt/openhab/webapps/static/uuid' with content '0e3715df-824e-475d-8b46-539284ae5210'
08:49:59.126 DEBUG o.o.c.internal.CoreActivator[:146] - Created file '/opt/openhab/webapps/static/version' with content '1.3.1'
08:49:59.132 INFO  o.o.c.internal.CoreActivator[:92] - openHAB runtime has been started (v1.3.1).
08:49:59.521 DEBUG o.o.c.a.i.AutoUpdateActivator[:51] - AutoUpdate binding has been started.
08:50:20.086 DEBUG o.o.m.p.i.PersistenceModelActivator[:43] - Registered 'persistence' configuration parser
08:50:20.279 DEBUG o.o.c.t.i.TransformationActivator[:58] - Transformation Service has been started.
08:50:20.904 DEBUG o.o.i.g.internal.GCalActivator[:54] - Google Calendar IO has been started.
08:50:21.213 DEBUG o.o.i.m.i.MultimediaActivator[:54] - Multimedia I/O bundle has been started.
08:50:21.553 DEBUG o.o.i.s.i.DiscoveryServiceActivator[:47] - Discovery service has been started.
08:50:21.694 DEBUG o.o.i.t.mqtt.MqttService[:138] - Starting MQTT Service...
08:50:24.361 DEBUG o.o.m.i.i.ItemModelActivator[:44] - Registered 'item' configuration parser
08:50:26.163 DEBUG o.o.c.i.items.ItemRegistryImpl[:157] - Item provider 'GenericItemProvider' has been added.
08:50:35.668 INFO  o.o.m.c.i.ModelRepositoryImpl[:99] - Loading model 'casa.items'
08:50:39.939 DEBUG o.o.m.i.i.GenericItemProvider[:154] - Read items from model 'casa.items'
08:50:42.213 DEBUG o.o.m.s.i.SitemapModelActivator[:43] - Registered 'sitemap' configuration parser
08:50:43.127 DEBUG o.o.i.r.internal.RESTActivator[:53] - REST API has been started.
08:50:43.681 INFO  o.o.i.s.i.DiscoveryServiceImpl[:92] - mDNS service has been started
08:50:46.249 INFO  o.a.cpr.AtmosphereFramework[:742] - Installing BroadcastFilter class(es) org.atmosphere.client.FormParamFilter
08:50:46.531 INFO  o.a.cpr.AtmosphereFramework[:1118] - Auto detecting atmosphere handlers /WEB-INF/classes/
08:50:46.668 WARN  o.a.cpr.AtmosphereFramework[:814] - Missing META-INF/atmosphere.xml but found the Jersey runtime. Starting Jersey
08:50:47.025 INFO  o.a.cpr.AtmosphereFramework[:364] - Installed AtmosphereHandler org.atmosphere.handler.ReflectorServletProcessor mapped to context-path: /*
08:50:47.033 INFO  o.a.cpr.AtmosphereFramework[:1173] - Auto detecting WebSocketHandler in /WEB-INF/classes/
08:50:47.314 INFO  o.a.cpr.AtmosphereFramework[:1099] - Atmosphere is using async support: org.atmosphere.container.JettyAsyncSupportWithWebSocket running under container: jetty/8.1.3.v20120522 with WebSocket enabled.
08:50:47.324 INFO  o.a.cpr.AtmosphereFramework[:902] - Installed WebSocketProtocol org.atmosphere.websocket.protocol.SimpleHttpProtocol 
08:50:47.494 INFO  o.a.h.ReflectorServletProcessor[:126] - Installing Servlet com.sun.jersey.spi.container.servlet.ServletContainer
08:50:49.212 INFO  c.s.j.s.i.a.WebApplicationImpl[:791] - Initiating Jersey application, version 'Jersey: 1.11 12/09/2011 11:05 AM'
08:50:49.234 INFO  c.s.j.s.i.a.WebApplicationImpl[:802] - Adding the following classes declared in META-INF/services/jersey-server-components to the resource configuration:
  class org.atmosphere.jersey.AtmosphereResourceConfigurator
08:50:50.061 INFO  c.s.j.s.i.a.DeferredResourceConfig[:97] - Instantiated the Application class org.openhab.io.rest.internal.RESTApplication
08:50:52.236 INFO  o.o.m.c.i.ModelRepositoryImpl[:99] - Loading model 'casa.sitemap'
08:51:06.022 INFO  o.a.cpr.AtmosphereFramework[:589] - Installed Default AtmosphereInterceptor [Android Interceptor Support, SSE Interceptor Support, JSONP Interceptor Support]. Set org.atmosphere.cpr.AtmosphereInterceptor.disableDefaults in your xml to disable them.
08:51:06.029 WARN  o.a.cpr.AtmosphereFramework[:509] - No BroadcasterCache configured. Broadcasted message between client reconnection will be LOST. It is recommended to configure the HeaderBroadcasterCache.
08:51:06.043 WARN  o.a.cpr.AtmosphereFramework[:533] - Neither TrackMessageSizeInterceptor or TrackMessageSizeFilter are installed. atmosphere.js may receive glued and incomplete message.
08:51:06.049 INFO  o.a.cpr.AtmosphereFramework[:537] - HttpSession supported: false
08:51:06.055 INFO  o.a.cpr.AtmosphereFramework[:538] - Using BroadcasterFactory: org.atmosphere.cpr.DefaultBroadcasterFactory
08:51:06.061 INFO  o.a.cpr.AtmosphereFramework[:539] - Using WebSocketProcessor: org.atmosphere.websocket.DefaultWebSocketProcessor
08:51:06.066 INFO  o.a.cpr.AtmosphereFramework[:540] - Using Broadcaster: org.atmosphere.jersey.JerseyBroadcaster
08:51:06.085 INFO  o.a.cpr.AtmosphereFramework[:541] - Atmosphere Framework 1.0.4 started.
08:51:06.091 INFO  o.o.i.r.i.RESTApplication[:158] - Started REST API at /rest
08:51:06.106 DEBUG o.o.i.s.i.DiscoveryServiceImpl[:63] - Registering new service _openhab-server._tcp.local. at port 8080
08:51:08.742 DEBUG o.o.i.s.i.DiscoveryServiceImpl[:63] - Registering new service _openhab-server-ssl._tcp.local. at port 8443
08:51:11.929 INFO  o.o.u.w.i.s.WebAppServlet[:99] - Started Classic UI at /openhab.app
08:51:18.037 DEBUG o.o.m.r.i.RuleModelActivator[:62] - Registered 'rules' configuration parser
08:51:18.151 DEBUG o.o.m.r.i.engine.RuleEngine[:98] - Started rule engine
08:51:22.341 DEBUG o.o.b.r.i.RFXComActivator[:54] - RFXCOM binding has been started.
08:51:22.538 DEBUG o.o.b.r.i.RFXComConnection[:68] - Activate
08:51:22.551 DEBUG o.o.b.r.i.RFXComConnection[:94] - Configuration updated, config true
08:51:22.562 INFO  o.o.b.r.i.RFXComConnection[:127] - Connecting to RFXCOM [serialPort='/dev/rfxcom' ].08:51:22.690 DEBUG o.o.m.i.i.GenericItemProvider[:312] - Start processing binding configuration of Item 'Salon_Lampara (Type=SwitchItem, State=Uninitialized)' with 'RFXComGenericBindingProvider' reader.
08:51:22.769 DEBUG o.o.m.i.i.GenericItemProvider[:312] - Start processing binding configuration of Item 'Cargador_Aspiradora (Type=SwitchItem, State=Uninitialized)' with 'RFXComGenericBindingProvider' reader.
08:51:22.782 DEBUG o.o.m.i.i.GenericItemProvider[:312] - Start processing binding configuration of Item 'Dormitorio_TV (Type=SwitchItem, State=Uninitialized)' with 'RFXComGenericBindingProvider' reader.
08:51:22.796 DEBUG o.o.m.i.i.GenericItemProvider[:312] - Start processing binding configuration of Item 'Cocina_Cafetera (Type=SwitchItem, State=Uninitialized)' with 'RFXComGenericBindingProvider' reader.
08:51:22.813 DEBUG o.o.m.i.i.GenericItemProvider[:312] - Start processing binding configuration of Item 'Salon_TV (Type=SwitchItem, State=Uninitialized)' with 'RFXComGenericBindingProvider' reader.
RXTX Warning:  Removing stale lock file. /var/lock/LCK..rfxcom
08:51:22.897 DEBUG o.o.b.r.internal.RFXComBinding[:78] - Activate
08:51:22.998 DEBUG o.o.b.r.i.RFXComConnection[:133] - Reset controller
08:51:23.013 DEBUG o.o.b.r.i.c.RFXComSerialConnector[:172] - Data listener started
08:51:24.129 DEBUG o.o.b.r.i.RFXComConnection[:161] - Data received:
Raw data = 0D0100010253431F8FFD01010000
 - Packet type = INTERFACE_MESSAGE
 - Seq number = 1
 - Sub type = INTERFACE_RESPONSE
 - Command = GET_STATUS
 - Transceiver type = _443_92MHZ_TRANSCEIVER
 - Firmware version = 67
 - Hardware version = 1.1
 - Undecoded packets = false
 - RFU6 packets = false
 - RFU5 packets = false
 - RFU4 packets = true
 - RFU3 packets = true
 - FineOffset / Viking (433.92) packets = true
 - Rubicson (433.92) packets = true
 - AE (433.92) packets = true
 - BlindsT1/T2/T3 (433.92) packets = true
 - BlindsT0 (433.92) packets = false
 - ProGuard (868.35 FSK) packets = false
 - FS20 (868.35) packets = false
 - La Crosse (433.92/868.30) packets = true
 - Hideki/UPM (433.92) packets = true
 - AD (433.92) packets = true
 - Mertik (433.92) packets = true
 - Visonic (315/868.95) packets = true
 - ATI (433.92) packets = true
 - Oregon Scientific (433.92) packets = true
 - Meiantech (433.92) packets = true
 - HomeEasy EU (433.92) packets = true
 - ARC (433.92) packets = false
 - X10 (310/433.92) packets = true
08:51:27.282 DEBUG o.o.b.r.i.RFXComConnection[:161] - Data received: - AC (433.92) packets = true
Raw data = 0A520700320E00FE300140
 - Packet type = TEMPERATURE_HUMIDITY
 - Seq number = 0
 - Sub type = WT260_WT260H_WT440H_WT450_WT450H
 - Id = 12814
 - Temperature = 25.400000000000002
 - Humidity = 48
 - Humidity status = COMFORT
 - Signal level = 4
 - Battery level = 0

De momento esto es todo por hoy... En la siguiente entrada iremos un poco mas allá: configuraremos los enchufes RF y crearemos un pequeño sitemap con unos cuantos items para gestionarlo todo por web o con el teléfono móvil. Espero que os guste :)

¡Un saludo a todos!

PUEDE COMENTAR ESTA ENTRADA AQUÍ

OpenHAB en la Raspberry Pi (parte 3): Inicio automático

NOTA: Este blog se ha trasladado a trasteandoarduino.com.

En la anterior entrada dejamos el sistema openHAB configurado con el sitemap demo funcionando. En esta entrada vamos a ver como podemos hacer para que se inicie automáticamente con el sistema, como un servicio más.

En Raspbian, como en los derivados de Debian, los servicios que se inician durante el arranque del sistema lo hacen mediante unos ficheros que se guardan en la carpeta /etc/init.d. Necesitaremos crear uno para que nos inicie openHAB. Como no somos los primeros a los que se nos presenta esta necesidad, si buscamos en la página del proyecto openHAB, vemos que hay una sección dedicada a ejemplos de configuración, y entre ellos hay uno para hacer justo lo que queremos (aquí).

Tan solo deberemos copiar el código que nos muestra, guardarlo en /etc/init.d/openhab, darle permisos de ejecución con sudo chmod a+x /etc/init.d/openhab, y finalmente añadirlo a la lista de servicios que se deben arrancar en el inicio con sudo update-rc.d openhab defaults (tened cuidado si estáis siguiendo la guía oficial porque hay una errata en este comando, no es sudo update-rc.d /etc/init.d/openhab defaults).

¿Tan fácil? Bueno, no. Como siempre que reusamos cualquier código hay que echarle un vistazo por si hay algo incorrecto, o algo que modificar como es nuestro caso. Al principio del fichero que acabamos de crear tenemos unas variables de configuración, la que nos interesa es ECLIPSEHOME, que especifica dónde tenemos la instalación de openHAB. Podemos cambiarla a /root/openhab, o podemos mover los archivos a esa ubicación.  En nuestro caso, optamos por mover todos los ficheros a /opt/openhab como nos sugiere el valor de la variable. Para ello ejecutamos el siguiente comando:

mv /root/openhab/runtime /opt/openhab

Además vemos que hay una variable RUN_AS que nos dice el nombre del usuario con el que se ejecutará openHAB. Como no tenemos ningún usuario ben en el sistema vamos a crear uno nuevo:

useradd openhab
chown -R openhab:openhab /opt/openhab

Con estos simples pasos ya podemos reiniciar nuestra Raspberry Pi y comprobar como se inicia openHAB automáticamente, conectando con un navegador a http://192.168.1.216:8080/openhab.app?sitemap=demo.

Como openHAB está desarrollado en Java y es bastante pesado, es posible que cuando intentéis acceder a la URL anterior, obtengáis un error 404. No os preocupéis, ese error significa que openHAB aun no ha terminado de cargar. En mi Raspberry tarda casi dos minutos en iniciarse... De todas formas si existiese algún error podéis ver los logs en /opt/openhab/logs.

 
PUEDE COMENTAR ESTA ENTRADA AQUÍ

Instalación de Raspbian y OpenHAB en la Raspberry Pi (de 0 a OpenHAB en un post)

NOTA: Este blog se ha trasladado a trasteandoarduino.com.

Hola de nuevo. Hoy vamos a empezar por la instalación del sistema desde 0, para poder ir montando todo el sistema domótico sobre Raspbian.

Instalación de Rasbian

Lo primero que hacemos es bajar la imagen del sistema para grabarlo en una tarjeta SD. Como el sistema irá ubicado en una caja estanca en la que, como habéis visto en las entradas anteriores del blog, se generará bastante calor,  yo recomendaría una tarjeta de unos 16Gb, rápida, y que tolere bien las altas temperaturas: una Sandisk Ultra 16GB (SDSDU-016G-U46) no parece mala opción, soporta un rango de temperaturas de -25C a +85C, con unas velocidades teóricas de 30MB, y vale unos 14€ en Amazon.

Para bajar la imagen, vamos a la web oficial de descargas de la Raspberry Pi, y la descargamos haciendo clic en el enlace de fichero zip. Lo descomprimos, y una vez que tenemos el fichero de la imagen listo, lo grabamos en la tarjeta SD, en mi caso esta en /dev/mmcblk0 con el comando:

sudo dd if=2013-09-10-wheezy-raspbian.img of=/dev/mmcblk0

Unos 8 minutos después ya tenemos la imagen grabada en la tarjeta. Expulsamos la tarjeta, la volvemos a meter para que se recargue el sistema recargue la tabla de particiones de la misma y abrimos el programa gparted para redimensionarlas:

sudo gparted

Seleccionamos el dispositivo correspondiente a la tarjeta, en mi caso /dev/mmcblk0, y desmontamos las particiones que haya  montadas. Si no lo hacemos no nos dejará redimensionarlas. Hacemos clic con el botón derecho sobre la partición mas grande, seleccionamos 'redimensionar/mover', y en el cuadro 'tamaño nuevo' introducimos 4096 o 8192 (4Gb u 8Gb). Después creamos una nueva partición con el espacio restante haciendo clic en dicho espacio con el botón derecho, seleccionamos 'nueva' y sistema de archivos 'ext4' (en etiqueta podeis poner 'Data' o lo que mas os guste, ya que sera una partición para datos y logs, que más tarde usaremos). Pulsamos 'añadir' y después sobre el botón verde para aplicar todos los cambios. Esperamos unos 30s y listo, ya podemos salir de GParted.

Extraemos la tarjeta nuevamente y la volvemos a meter para que nos monte automágicamente  las particiones. 

Ahora vamos a configurar el sistema para que cuando metamos la tarjeta en la Raspberry Pi ya tenga su IP fija. Para ello abrimos el fichero /etc/network/interfaces de la tarjeta (como usuario root), que contendrá algo como:

auto lo

iface lo inet loopback
iface eth0 inet dhcp
allow-hotplug wlan0
iface wlan0 inet manual
wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf
iface default inet dhcp

y cambiamos las linea de eth0 por estas:

auto eth0
iface eth0 inet static
       address 192.168.1.216
       netmask 255.255.255.0
       network 192.168.1.0
       broadcast 192.168.1.255
       gateway 192.168.1.1
       dns-nameservers 8.8.8.8

Deberéis cambiar las direcciones por las que sean validas para vuestra red, en mi caso esas nos irán bien. El resultado será algo parecido a esto:

auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
       address 192.168.1.216
       netmask 255.255.255.0
       network 192.168.1.0
       broadcast 192.168.1.255
       gateway 192.168.1.1
       dns-nameservers 8.8.8.8

allow-hotplug wlan0
iface wlan0 inet manual
wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf
iface default inet dhcp

Desmontamos las particiones de la tarjeta, si están montadas, con:

umount /dev/mmcblk0*

Y ya podemos ponerle la tarjeta a la Raspberry Pi, iniciarla y acceder por ssh con el comando ssh pi@192.168.1.216 y poniendo de contraseña: raspberry. Lo primero que hay que hacer es cambiar las contraseñas de los usuarios pi y root:

pi@raspberrypi ~ $ passwd
Changing password for pi.
(current) UNIX password: raspberry
Enter new UNIX password: 
Retype new UNIX password: 
passwd: password updated successfully

pi@raspberrypi ~ $ sudo passwd
Enter new UNIX password: 
Retype new UNIX password: 
passwd: password updated successfully

Y acto seguido actualizamos el sistema:

sudo apt-get update
sudo apt-get upgrade

Como parte opcional, si tenemos IP dinámica, podemos instalar  un software como el de No-IP para tener acceso desde Internet a nuestra RPi, lo instalamos siguiendo las estas instrucciones, y ya tenemos el sistema casi listo para empezar a trabajar con él.

Lo único que nos falta es montar la partición que usaremos para datos en /mnt/Data, para ello creamos la carpeta:

mkdir /mnt/Data

Y para automontarla cada vez que se inicie el equipo, añadimos la siguiente linea al fichero /etc/fstab:

/dev/mmcblk0p3  /mnt/Data       ext4    defaults       0       2

De momento podemos montarla con mount -a sin tener que reiniciar.

Utilidades básicas

Si necesitáis instalar alguna utilidad con la que os manejéis bien, ahora es el momento. A mi me gusta instalar el Midnight Commander (sí, soy de la generación del Comandante Norton de MSDOS, que le voy a hacer...):

apt-get install mc arduino p7zip-full dos2unix

Instalación de Java

Descargamos la ultima version de Java disponible, desde otro equipo con Firefox por ejemplo, con soporte headless/server/hardfp/ARMv6/7 y lo transferimos a la RPi con el comando:

scp jdk-7u40-linux-arm-vfp-hflt.tar.gz root@192.168.1.216:/root

Volvemos a la Raspberry y ejecutamos:

sudo mkdir -p -v /opt/java 
sudo tar xvzf ~/jdk-7u40-linux-arm-vfp-hflt.tar.gz -C /opt/java
rm ~/jdk-7u40-linux-arm-vfp-hflt.tar.gz
sudo update-alternatives --install "/usr/bin/java" "java" "/opt/java/jdk1.7.0_40/bin/java" 1
update-alternatives --set "java" "/opt/java/jdk1.7.0_40/bin/java"
java -version

La salida del último comando nos debe decir que estamos usando el JDK 1.7 de Oracle si todo ha ido bien.

Editado (8/10/2013): Ahora basta con un simple apt-get install oracle-java7-jdk y luego update-alternatives --set java /usr/lib/jvm/jdk-7-oracle-armhf/jre/bin/java

 

Instalación de INO

Como no tenemos entorno de programación gráfica para Arduino, a tratarse de un equipo sin monitor, necesitamos una herramienta que nos facilite la programación desde la linea de comandos. Podéis ver como se instala y como funciona en una entrada anterior que dediqué a este programa.

Instalación de OpenHAB

OpenHAB esta formado por varios paquetes:

• El runtime. Es el sistema en sí, el nucleo, que deberemos instalar en la Raspberry Pi.
• Los addons. Son los módulos que permiten la interconexión de openHAB con KNX, X10, HTTP, etc... Al menos hay que bajarlo y tenerlo disponible para ir copiando a mano los módulos que vayamos necesitando.
• Designer. Es es interfaz para configurar el sistema. No es necesario instalarlo en la Raspberry, solo en el equipo en el que vayamos a desarrollar.
• Demo configuration. Es una configuración de ejemplo que podemos bajar para echarle un vistazo y trastear sobre ella.
• Greent. Es una interfaz de la web que nos proporciona el runtime. Opcional.

Para empezar bajamos todos los paquetes de esta web:

mkdir openhab
cd openhab 
wget https://openhab.googlecode.com/files/openhab-runtime-1.3.1.zip
wget https://openhab.googlecode.com/files/openhab-addons-1.3.1.zip
wget https://openhab.googlecode.com/files/openhab-demo-configuration-1.3.1.zip
wget https://openhab.googlecode.com/files/openhab-greent-1.3.1.zip
unzip openhab-runtime-1.3.1.zip -d runtime
unzip openhab-addons-1.3.1.zip -d addons
unzip openhab-demo-configuration-1.3.1.zip -d demo
unzip unzip openhab-greent-1.3.1.zip -d greent 

Ya podemos empezar a trastear...

Para probar hasta la próxima entrada podéis copiar el contenido de la carpeta demo/configurations a runtime/configurations y arrancar el sistema openHAB ejecutando el script start.sh. Cuando haya terminado de iniciarse (puede tardar un minuto y algo) os conectáis con un navegador a la siguiente web:

http://192.168.1.216:8080/openhab.app?sitemap=demo

y si os instaláis en el móvil la aplicación HABdroid ya ni os cuento... :)

EDITADO 1/10/2013:
Además de copiar el contenido de demo/configurations, hay que copiar el contenido de demo/addons a runtime/addons para que funcione correctamente el sitemap demo.

PUEDE COMENTAR ESTA ENTRADA AQUÍ

OpenHAB, domótica abierta (parte 1).

NOTA: Este blog se ha trasladado a trasteandoarduino.com.

Estos últimos días he estado buscando un sistema que me permitiera controlar el sistema de riego por goteo que estoy desarrollando (con Arduino y unas electroválvulas) para no tener que 'reinventar la rueda'. Hay varias posibilidades, entre ellas las dos que parecen mas viables son OpenSprinkler y OpenHAB.

OpenSprinkler es, como su nombre indica, un controlador de riego por goteo de código y hardware abierto, conectable a Internet. Por su lado OpenHAB es algo más general, es un sistema Java que permite interoperar con sistemas más concretos como pueden ser KNX, X10, correo electrónico, sistemas de videovigilancia, MQTT, RFXCom, 1wire, Somfy, Google Services, SNMP, incluso con el propio OpenSprinkler... Vamos, que OpenHAB es un monstruo.

¿Dónde queríamos llegar? A controlar un sistema casero de riego por goteo.

¿A donde podemos llegar? A controlar desde la misma plataforma, desde cualquier lugar, con el móvil, integrado con Google Calendar el sistema de riego por goteo y la domótica de la casa.

La elección es obvia: OpenHAB, aunque sabemos que nos costará algo más que comprar un simple aparato, pero la cosa promete, y mucho. 

Vamos allá. En primer lugar vamos a definir como está el proyecto para domotizar la casa y dónde nos puede ayudar OpenHAB: Tenemos una Raspberry Pi con una serie de sensores, y unas farolas controladas mediante unos relés y un Arduino Ethernet. Esto se puede integrar muy fácilmente en OpenHAB. Muy por encima, OpenHAB es un sistema basado en una serie de elementos (un sistema de video, unos sensores remotos, un calendario de Google, un sistema domotico KNX, ...) conectados a un bus de eventos que nos permite reaccionar ante ellos. Por ejemplo: podriamos tener un sensor de temperatura 1wire conectado al bus, y que cuando el sistema detecte cierta temperatura, nos active el aire acondicionado de la casa, o podriamos definir un evento a las 7:00am todos los dias en un calendario de google conectado al bus, y que cuando suceda, el sistema nos active el calentador de agua que tenemos en casa conectado a un enchufe controlado por radiofrecuencia. ¿Qué os parece? Pues sí, ¡una pasada! 

Esquema OpenHAB

En los próximos posts iré desarrollando los siguientes puntos para hacer una guía...

1. Instalación de OpenHAB en una Raspberry Pi,

2. Configurando y Arrancando el sistema,

3. Añadir nuevos módulos: RFXCOM, Google Calendar, GMail...

y lo que me vayáis comentando que os pueda ser de utilidad también lo iré investigado. Espero que os guste tanto como a mi :)

PUEDE COMENTAR ESTA ENTRADA AQUÍ

Enchufes radiocontrolados (parte 3), esquemas

NOTA: Este blog se ha trasladado a trasteandoarduino.com.

Aquí os dejo los esquemas que he usado para hacer las pruebas con los módulos de radiofrecuencia y los enchufes, que parece que con la foto no quedaban demasiado claros. En el esquema del sistema emisor, hay que tener en cuenta que tenéis que poner un cable a modo de antena en el pin marcado como ANT para aumentar el alcance de la señal...

Módulo receptor

Módulo emisor

PUEDE COMENTAR ESTA ENTRADA AQUÍ

JDomo, sensores de temperatura DS18B20

NOTA: Este blog se ha trasladado a trasteandoarduino.com.

Ayer estuve añadiendo un nuevo sensor de temperatura al nodo central del sistema JDomo. Ahora, además del sensor interno de la caja y el sensor interno de la Raspberry Pi, tenemos un sensor externo (fuera de la caja), que he colocado usando un prensaestopas y un DS18B20 para exteriores.

El montaje seria algo parecido al siguiente esquema:

Si no me he equivocado en el esquema, los terminales de VCC y GND de los DS18B20 van conectados (los dos) al terminal GND de la placa Arduino, y los de datos a 5v a través de una resistencia de 4700 Ohmios.

Aunque en el esquema se vean los sensores directamente conectados a la placa de prototipos, en realidad tienen un cable a prueba de agua de un metro para poder colocarlos donde mas nos interese, en este caso: uno dentro de la caja estanca, y otro fuera, a través de un prensaestopas que nos asegura que la caja sigue siendo estanca.

Durante el montaje y las pruebas me topé con un inconveniente que hasta ahora no había sufrido. Durante las pruebas en casa con otra placa Arduino lo tenía todo conectado tal y como veis en el esquema pero al llegar al campo, donde tengo el sistema JDomo funcionando, lo conecté al pin 10 (y en el código también especifique que el pin usado era el 10). Hasta aquí todo parece correcto, salvo que cuando le colocamos un shield ethernet a nuestra placa Arduino, hay ciertos pins que ya no podemos usar, y... ¿lo adivináis? el 10 está entre ellos... del pin 10 al 13 se usa para la comunicación SPI con el chip Wiznet de la shield. Hasta que me di cuenta, pasó casi una hora y media de pruebas... Uff... 

En casa en el pin 9 funcionaba. En el campo en el pin 10 usando solo un programa de ejemplo que se limitaba a leer los sensores funcionaba, pero en cuando le cargaba el software JDomo que hace uso de la shield ethernet, dejaba de funcionar... 

Moraleja: siempre que uses una shield o varias, ¡comprueba la compatibilidad entre ellas! ya que si usan algún pin en común seguramente el montaje os dará errores extraños, aleatorios o incluso no funcionará nada en absoluto...

Para finalizar os dejo una imagen para que veais que tal funciona el sistema:

En azul, las lecturas del nuevo sensor DS18B20

PUEDE COMENTAR ESTA ENTRADA AQUÍ

JDomo, un mes funcionando

NOTA: Este blog se ha trasladado a trasteandoarduino.com.
 
Hola de nuevo.

¡Qué rápido pasa el tiempo! Ya hace un mes que monté el nodo principal del sistema domótico y tengo unas gráficas que os podrían interesar, así como algunas modificaciones y curiosidades.

Ya me pensaba yo que al empeorar la situación meteorológica la señal 3G mejoraba. Pues sí, y aquí va la prueba. Nada menos que un 10% de mejora de la señal nada mas empezar a empeorar el tiempo... ¿casualidad? ya lo iremos viendo...

Mejora de la señal al empeorar el tiempo.

Otras gráficas interesantes son las de temperatura, dentro de la caja (temperatura ambiente del sistema), y la del micro de la Raspberry Pi. Según las especificaciones se consideran temperaturas normales aunque no estaría de más bajarlas unos 10 grados para intentar alargar al máximo la vida de todos los componentes.

Temperatura dentro de la caja.

Temperatura de la Raspberry Pi.

En este punto he de decir que he detectado picos de 85 grados en las lecturas de la sonda DS18B20 que instalé dentro de la caja. Estaba algo extrañado pero leyendo el datasheet de la DS18B20 vi que cuando se inicia, la temperatura por defecto que almacena en su memoria son esos 85 grados, cosa curiosa...

Más gráficas. Uso de memoria. Cuando programamos un sistema, creamos scripts, los tuneamos... lo más normal es que de vez en cuando algo falle y se queden procesos pendientes de alguna entrada, o que fallen y se queden zombis en memoria, que se repliquen hasta el infinito, etc, etc... Algo así me paso con los scripts que analizaban los datos enviados por la placa Arduino. Una vez que te das cuenta del problema, reprogramas los scripts y además añades un sysctl -w vm.drop_caches=3 para que se ejecute diariamente como una tarea más del cron, y se libere la máxima memoria posible, obtenemos esta gráfica:

Solucionados los problemas de gestión de memoria.

De momento esto es lo que he ido viendo, si tenéis alguna pregunta o recomendación, será bienvenida :)

PUEDE COMENTAR ESTA ENTRADA AQUÍ

Programar Arduino desde la linea de comandos, fácil y rápido

NOTA: Este blog se ha trasladado a trasteandoarduino.com.

Esta vez os voy a contar como programar un Arduino sin todas las molestias que nos causa el tener que usar el entorno gráfico del IDE oficial. Bueno, para mi es una molestia el tener que cargar un entorno gráfico, y un entorno de programación que no aporta nada a una simple linea de comandos de toda la vida. Además si tienes que programar por SSH, a través de una linea lenta, es todavía peor.

Vamos allá.

La herramienta que vamos a usar se llama INO, se trata de unos scripts que nos permitirán inicializar un proyecto, compilarlo, subirlo al Arduino y mostrar una consola serial si la necesitamos.

En el sitio web del proyecto podéis encontrar la información más detallada. En mi caso la instalación bajo Ubuntu es bastante sencilla:

apt-get install git python-setuptools python-configobj python-jinja2 python-serial picocom
git clone git://github.com/amperka/ino.git
cd ino
make install

Con la primera linea instalamos los prerrequisitos de INO y el programa picocom, que es el que usará para conectar de forma serial con Arduino para mostrar la consola. Con la segunda nos bajamos la última versión disponible en el repositorio. Con las dos siguientes lo compilamos e instalamos.

Es posible que necesitéis instalar el paquete build-essential si no tenéis instaladas las herramientas de desarrollo.

Una vez que lo tenemos todo ejecutamos el script:

jose@titanio:~$ ino -h
usage: ino [-h] {build,clean,init,list-models,preproc,serial,upload} ...

Ino is a command-line toolkit for working with Arduino hardware.

It is intended to replace Arduino IDE UI for those who prefer to work in
terminal or want to integrate Arduino development in a 3rd party IDE.

Ino can build sketches, libraries, upload firmwares, establish
serial-communication. For this it is split in a bunch of subcommands, like git
or mercurial do. The full list is provided below. You may run any of them with
--help to get further help. E.g.:

    ino build --help

positional arguments:
  {build,clean,init,list-models,preproc,serial,upload}
    build               Build firmware from the current directory project
    clean               Remove intermediate compilation files completely
    init                Setup a new project in the current directory
    list-models         List supported Arduino board models
    preproc             Transform a sketch file into valid C++ source
    serial              Open a serial monitor
    upload              Upload built firmware to the device

optional arguments:
  -h, --help            show this help message and exit

Para crear un proyecto, creamos una carpeta vacía con mkdir proyecto1, y dentro de ella ejecutamos ino init para crear la estructura básica del proyecto, modificamos el fichero sketch.ino de la carpeta src, añadimos las librerías que consideremos oportunas a la carpeta lib y compilamos con ino build. Si todo ha ido bien podremos subir el programa con ino upload y ver la consola con ino serial.

Fácil ¿verdad?

PUEDE COMENTAR ESTA ENTRADA AQUÍ

JDomo, montando en nodo principal

NOTA: Este blog se ha trasladado a trasteandoarduino.com.
 
Vamos avanzando en el proyecto de control domótico y ya tengo montado y funcionando (en pruebas) el nodo principal de los que será lo que he bautizado como JDomo (de José y Domótica). 

El sistema está formado por una Raspberry Pi conectada a:

• un Arduino para control eléctrico de los componentes, control de consumo eléctrico, y sensores de temperatura (por Ethernet),
• un router Tp-Link MR3420 que nos dará la cobertura Wifi, y la conexión con internet mediante un modem 3G Huawei E220 (por Ethernet),
• un hub USB con alimentación de 3A al que conectaremos todos los periféricos de la Raspberry,
• otro modem 3G Huawei E220, para envío de SMS (por USB).
• un módulo PLC Tp-Link PA411-Kit (por Ethernet)

 Todo el sistema se alimenta desde una regleta estabilizadora APC Essential SurgeArrest 5, y está montado en una caja de PVC estanca.

JDomo (hacer clic para agrandar)

El proceso de montaje fue bastante entretenido: cortando el metacrilato con la sierra de calar y viendo que a medida que lo cortaba se quedaba soldado por donde ya lo había cortado (hasta que probé con la radial y todo fue como la seda), intentando colocar bien los cables eléctricos por debajo de la plancha de metacrilato que sirve de soporte a todo, o aprovechar los agujeros de la carcasa del router para anclarlo al meta... jajajaja, se aprende bastante haciendo bricolaje casero... Ahí van algunas fotos del proceso aunque hay alguna que ha salido algo borrosa:

Caja con el soporte base de metacrilato.

Añadimos la regleta de corriente.

Desmontando el router.

Tornillos para anclar la base del router.

Router y soporte base en una pieza :)

Soporte secundario para la Raspberry, el Arduino, los relés, ...

Electrónica para el control del sistema domótico.

Finalmente, y tras un buen rato de sufrir para colocar la caja en su lugar:

JDomo, nodo central en su lugar.

Tras la instalación llega el momento de más nervios, de comprobar si la cobertura 3G es lo suficientemente fuerte en una casa de campo y dentro de la caja estanca, y de comprobar los datos del sensor de temperatura.

Aprovechando que los datos de la señal 3G nos los da el router desde su página de status, con un pequeño script y el sistema de monitorización Cacti 0.8.8a obtenemos la siguiente gŕafica:

La primera mitad de la gráfica corresponde a la calidad de la señal en las pruebas hechas en casa, mientras montaba todos los componentes (antes de Thu). A partir de ese día se instaló la caja en su ubicación definitiva y se puede ver que la calidad de la señal es bastante estable en torno al 50%. No está mal. ¡Prueba superadaaaa!

Prueba de temperatura. Ya os imagináis el resultado, ¿no?. Yo también me lo imaginaba. Una caja estanca, con componentes electrónicos, a pleno sol, en la zona de Alicante, agosto, ola de calor... mala combinación. El sensor de temperatura que monté dentro de la caja es un DS18B20, que por cierto, no se ve en las imágenes porque lo puse en el último momento:

Como en la gráfica anterior, la primera mita corresponde con las pruebas durante el montaje. El primer pico no muy alto se debe a que por un olvido mio me deje la caja sin cerrar del todo y se abrió a media mañana del día siguiente al que la instalé. ¡51 grados de temperatura ambiente dentro de la caja! Veamoslo con más detalle...

Ni que decir tiene que al ver esto, tuve que reaccionar y el día 30 hice una prueba. ¿Que pasaría si pusiese algo para evitar que le diese directamente el sol a la caja? La temperatura debería bajar, pero ¿cuanto? Veamos los últimos días con más detalle:

El martes a media tarde, cuando más fuerte era el sol, y aprovechando que tenía que ir a por unas cosas al campo, se me ocurrió una prueba rápida, y ya veis que en una hora bajó 10 grados la temperatura, y al día siguiente (hoy), parece que la máxima se ha mantenido 5 o 6 grados por debajo de las máximas anteriores. Todo un logro para esta solución/prueba:

Maravilla de la ciencia moderna...

Sí, un simple cartón enganchado por la parte de arriba a la caja y por la parte de abajo con unas rasillas para que no se vuele, y da ese excelente resultado. Ahora falta buscar una implementación mejor esta solución (algo que no se lleve de bichos, avisperos, y demás...). Se aceptan sugerencias...

Al ver que aumentaba tanto la temperatura ambiente dentro de la caja, activé la monitorización de la temperatura interna de la Raspberry Pi para ver si trabajaba dentro de los parámetros razonables, y esto es lo que obtuve:

Picos de más de 66 grados, con la Raspberry Pi en reposo, porque de uso de CPU no llega ni al 10%:

Con la solución del cartón pasamos a picos de 62 grados de máxima, 4 grados menos. No es mucho, pero algo es algo. El próximo paso será añadirle unos disipadores como a mi otra Raspberry Pi, y comprobar los resultados. O incluso ponerle un pequeño ventilador que haga que no se concentre el calor sobre el procesador y que se reparta mejor por toda la caja... Lo probaré...

Bueno, y como ya es hora de irse a dormir, como decimos por aquí: ¡bona nit!

PUEDE COMENTAR ESTA ENTRADA AQUÍ

Enchufes radiocontrolados (parte 2)

NOTA: Este blog se ha trasladado a trasteandoarduino.com.
 
Hace ya un tiempo que tenía pendiente profundizar en el tema de los enchufes radiocontrolados, y ahí va. 

Para hacer las pruebas he usado una pequeña placa con una pareja de módulos de recepción y emisión RF en la banda de 433Mhz que es la que usan los enchufes que os mostré anteriormente. Se pueden conseguir directamente en Ebay por menos de un euro la pareja si los compráis directamente a China. 

En la foto siguiente veis que están montados los dos módulos, a la derecha el de recepción, con el pin de datos conectado al pin 2 de Arduino, y a la izquierda el de emisión con el pin de datos conectado al pin 7 de Arduino. El resto son las conexiones a Vcc y Gnd, excepto el cable naranja que hace las funciones de antena en la parte de emisión.

Esquema del montaje para pruebas

La librería que he usado en los ejemplos es la de Randy Simons, RemoteSwitch, que os podéis descargar desde aquí. Antes de poder usarla tendréis que cambiar las referencias a WProgram.h por Arduino.h en los ficheros RemoteReceiver.h y RemoteSwitch.h.

Vamos entrando en materia. ¿Cómo podemos saber los códigos que envía nuestro mando al pulsar uno de los botones? Pues dentro de la librería viene un ejemplo, show_received_code.pde que algo retocado y en castellano queda de la siguiente forma:

 #include <RemoteReceiver.h>  
   
 /*  
 * Este programa lee los codigos recibidos por el modulo de RF  
 * y los muestra por pantalla.  
 * El pin de datos del receptor va al pin 2 de Arduino  
 * (este codigo esta basado en el original de Randy Simons show_received_code.pde)  
 */  
   
   
 void setup()  
 {  
  Serial.begin(9600);  
   
  // Indicamos que cuando se active la interrupcion 0 (pin 2 de Arduino) se llame a la  
  //funcion de callback "mostrarCodigo" al recibir 3 veces el mismo codigo (que es lo  
  //mismo que pulsar una tecla en el mando por un instante)  
  //                   interrupcion  
  //                   |  repeticiones  
  //                   |  |  funcion callback  
  //                   |  |  |  
  RemoteReceiver::init(0, 3, mostrarCodigo);  
 }  
   
 void loop()  
 {  
  // no se hace nada, ya que cada vez que se reciba un codigo se ejecutara la funcion  
  //mostrarCodigo  
 }  
   
   
 void mostrarCodigo(unsigned long receivedCode, unsigned int period)  
 {  
  //Note: interrupts are disabled. You can re-enable them if needed.  
   
  Serial.print("Codigo: ");  
  Serial.print(receivedCode);  
  Serial.print(", periodo: ");  
  Serial.print(period);  
  Serial.println("us.");  
 }

Al ejecutarlo nos da una salida como la siguiente:

Codigo: 334554, periodo: 150us.
Codigo: 334554, periodo: 153us.
Codigo: 334554, periodo: 152us.
Codigo: 334550, periodo: 150us.
Codigo: 334606, periodo: 153us.
Codigo: 334554, periodo: 150us.
Codigo: 334606, periodo: 152us.
Codigo: 334550, periodo: 150us.
Codigo: 334550, periodo: 153us.
Codigo: 334550, periodo: 150us.
Codigo: 334550, periodo: 152us.
Codigo: 334550, periodo: 152us.
Codigo: 334606, periodo: 152us.
Codigo: 334550, periodo: 150us.
Codigo: 334550, periodo: 153us.
Codigo: 334550, periodo: 150us.
Codigo: 334550, periodo: 152us.

Donde podemos ver que el código 334554 corresponde a 'D On' y 334550 a 'D Off'. El código 334606 es un código erróneo, que nos devuelve la librería debido seguramente a interferencias (o no...). El periodo de la señal es de 150 microsegundos (este dato nos sera útil a la hora de enviar los códigos en el siguiente ejemplo).

NOTA: Como habréis visto, aunque en la placa esté conectado el módulo de envío por RF, en este ejemplo no se ha usado para nada. Está montado, más que nada, por comodidad, y por no tener que estar montando y desmontando los módulos cuando cambio de ejemplo.

El siguiente paso natural es sustituir nuestro mando por un Arduino. Imaginemos que queremos hacer que cuando con nuestro mando enviemos una señal D On, nuestro Arduino lo detecte y envíe una señal E On. No tiene mucho sentido pero puede servirnos de punto de partida para otras implementaciones mas complejas (en el ejemplo vemos como se puede recibir y enviar con el mismo programa).

Configuramos el enchufe como 10100 00001 (Aparato E) para que podamos comprobar que al pulsar el botón D ON el Arduino envía el código E ON y se activa el enchufe.

Configuración 10100 aparato E.

Cargamos el siguiente código en nuestro Arduino y lo probamos:

#include <RemoteReceiver.h>
#include <RemoteTransmitter.h>

// Codigo de Casa: 10100
// Aparato A: XXXXX10000
// Aparato B: XXXXX01000
// Aparato C: XXXXX00100
// Aparato D: XXXXX00010
// Aparato E: XXXXX00001

unsigned long A_on  = 333150;
unsigned long A_off = 333146;
unsigned long B_on  = 334122;
unsigned long B_off = 334118;
unsigned long C_on  = 334446;
unsigned long C_off = 334442;
unsigned long D_on  = 334554;
unsigned long D_off = 334550;
unsigned long E_on  = 334590;
unsigned long E_off = 334586;

int period=150;
const int pinEMISOR=7;

void setup()
{
  Serial.begin(9600);

  RemoteReceiver::init(0, 3, procesaCodigoRecibido);
}

// --------------------------------------------------------------------
// Procesamiento de los codigos recibidos
// --------------------------------------------------------------------
void procesaCodigoRecibido(unsigned long receivedCode, unsigned int period) 
{
  // Leemos el codigo recibido y ejecutamos la accion que corresponda

  Serial.print("Codigo: ");
  Serial.print(receivedCode);
  Serial.print(", periodo: ");
  Serial.print(period);
  Serial.println("us.");

  // Si recibimos un D-ON, enviamos un E-ON
  if(receivedCode==D_on)
  {
     Serial.println("Recibido D_ON");
     cli();
     sei();
     delay(2*period);
     Serial.println("Enviado E_ON");
     RemoteTransmitter::sendCode(pinEMISOR,E_on,period,3);
  }

  delay(350);
}


void loop()
{
   //el codigo se ejecuta cuando se activa la interrupcion
}

Y a partir de ahí ya podeis adaptar el código para hacer lo que querais.

Bueno, un último apunte: existe una versión más moderna de la librería aquí, que soluciona algún problema como el de tener que activar y desactivar manualmente las interrupciones (cli/sei) para que se pueda usar la recepción y el envío simultáneamente en el mismo programa.

Espero que os sirva, y si tenéis alguna pregunta, será bienvenida.

PUEDE COMENTAR ESTA ENTRADA AQUÍ

Electroválvula Rain Bird 075-DV controlada por Arduino

NOTA: Este blog se ha trasladado a trasteandoarduino.com.
 
Una de las tareas que debía controlar el sistema domótico que estoy construyendo es la del riego por goteo. Para ello tengo dos electroválvulas Rain Bird 075-DV, un Arduino UNO y una placa con dos relés.

Lo que pretendo es que cuando al Arduino le llegue un comando '1' cambie el estado del relé numero 1 de la placa, y active/desactive la electroválvula. El esquema de conexionado es el siguiente:

Esquema del sistema de control de electroválvulas.

Usamos la placa de reles como un interruptor electrónico, controlado por nuestro Arduino, para activar y desactivar la electroválvula a voluntad.

Tenemos un transformador de 220VAc a 24VAc, que es lo que necesita la electroválvula para funcionar, uno sus cables lo hacemos pasar por el relé (contacto normalmente abierto) y el otro lo conectamos a la electroválvula. Hay que tener muy en cuenta que son 24V de corriente alterna (AC). La placa de relés tiene una peculiaridad: cuando en la entrada IN1 ponemos un estado LOW, el relé se activará, y cuando ponemos un valor HIGH, se desactivará. El condensador que veis, sirve para deshabilitar el reset que se produce en la placa Arduino cada vez que recibe un comando vía USB (más información aquí).

Y en Arduino cargamos el siguiente programa:

// -----------------------------------------------
// Reles (Electrovalvulas)
// -----------------------------------------------
int pinElectrovalvula1=7;
int estadoEV1;


void setup()
{
  Serial.begin(9600);

  // Inicializamos el modulo de EVs
  pinMode(pinElectrovalvula1,OUTPUT);
  estadoEV1=1; //cerrada
  digitalWrite(pinElectrovalvula1,estadoEV1);
}


void loop()
{
  byte command=0;
  if(Serial.available()>=0)
  {
      command=Serial.read();

      switch(command)
      {        
        // Formato del comando: 1
        case '1':
        {
          estadoEV1=!estadoEV1;
          digitalWrite(pinElectrovalvula1,estadoEV1);
        }
      }
  }
}

Ya lo tenemos todo listo para que en cuanto arranque el programa la electroválvula se cierre (por seguridad, en casos de reinicios fortuitos del sistema por cortes de luz por ejemplo...), y se quede esperando el comando para activar/desactivar la electroválvula cuando queramos.

Más o menos el montaje real quedaría así:

Montaje real... en pruebas.

Detalle de las conexiones en la placa de relés.

Bueno, y esto es todo de momento. Si tenéis alguna pregunta, ya sabéis que son bienvenidas...

PUEDE COMENTAR ESTA ENTRADA AQUÍ