Proyecto de Domótica. Encendiendo y apagando luces de casa desde el celular

Buenas noches colegas

Hace un tiempo que he desarrollado este proyecto de "control de cosas" por internet (IOT) y tengo claro que hay mucha info en la red, y gran variedad de aplicaciones que transforman cualquier cosa doméstica, hasta un inodoro en inteligente(?) y accesible desde la nube.
Esto es por que la llamada Domótica o IoT está muy de moda en estos días y claramente se impondrá globalmente tarde o temprano.
Yo arranco aquí desde un desarrollo simple y básico, usando el hardware que tengo disponible en el cajón, que luego se puede ampliar y sofisticar como se quiera, .

Los pasos a seguir en mi caso serán:

1) Armar un plaqueta con uC (microcontrolador) que maneje unos relés para encender y apagar luces u otros dispositivos, en principio 4.
Y además el uC correrá un código que como veremos será una especie de servidor de pagina web en lenguaje HTML muy básico

2) El uC manejará el encendido y apagado de los relés por medio de comandos (strings) seriales simples recibidos en su USART, por ejemplo "ONN1" (encender luz 1), "OFF3" (apagar luz 3), embebidos estos en lenguaje HTML, y también contestará el estado de los relés en lenguaje HTML para que el cliente remoto se entere del éxito del comando enviado a través de la nube.

3) El uC recibirá dichos comandos seriales desde una placa conversora ethernet _ serial, en mi caso será una WIZ108SR, que como dije la ya tenía en algún cajón de mi humilde laboratorio y la aprovecho para esto, pero con otros modelos similares de interfaces también podrá funcionar el proyecto.

Las características de esta placa WIZNET pueden verse aquí:
Esta placa que uso porque la tengo disponible tiene dos problemitas perfectamente salvables, tiene que ser alimentada con 3,3V y sus señales seriales serán de 3,3V siendo el uC de 5V, y además su interface serial es norma RS422/RS485 3,3V mientras que en el uC, su USART es norma RS232 de 5V . Una circuitería adaptadora muy simple que luego veremos salvará este problema.
Como veremos luego en detalle en su configuración, la WIZ108SR es muy versátil y puede configurarse en su lado ethernet TCP/IP como Servidor, Cliente o Mixta, y en su lado serial con distintas velocidades y formatos de datos que se adaptarán a la USART del uC.
Como ya adelanté, este proyecto usará la modalidad Cliente-Servidor, donde el conjunto WIZ-uC actuará como Servidor y la aplicación remota desde PC o teléfono móvil que nos permitirá finalmente prender u apagar luces en casa, será el cliente.
A la WIZ en su lado TCP/IP le asignaremos un número IP fijo dentro de nuestra red hogareña (LAN), por ejemplo si el modem/router de casa tiene número de red 192.168.1.1, a la WIZ le pondremos por ejemplo 192.168.1.108

4) Abriendo puertos y configurando DNS dinámica en nuestro router
Nuestro router doméstico nos protege de ingresos no deseados a nuestra red doméstica, pero en algunos casos es necesario que aplicaciones clientes externas alcancen algunos dispositivos en dentro de nuestra LAN con conexiones TCP/IP entrantes, como es el caso de cámaras de vigilancia, dispositivos IoT, servidores de página, etc.
Y como ya vamos viendo, la placa WIZ y el uC en este proyecto actuarán como un simple conjunto servidor de página con la función física Ppal. de manejar relés y los dispositivos cableados a estos.
Entonces para que la conexión entrante de nuestra App cliente remota alcance la WIZ y el uC deberemos abrir los puertos correspondientes en nuestro router doméstico.
Como ya dijimos los mensajes de comando y respuesta estarán embebidos en lenguaje HTML, por lo cual el puerto a abrir para que estos circulen será el 80 (HTML), y esto también asegurará que los comandos viajen sin tropiezos en la nube pues los mensajes HTML son los más comunes de paginas Web y todo enrutador o enlace en la red los dejará pasar.
Esta configuración que veremos luego en detalle en mi router Encore se llama Virtual Server, en otros LAN Routing, etc. dependiendo de marcas y modelos.

Por otro lado, normalmente nuestro router doméstico tendrá asignada una dirección TCP/IP pública dinámica (variable) del lado WAN en la WEB, que es asignada por nuestro ISP (Internet Service Provider) dentro de un rango de direcciones públicas, a no ser que algún usuario pudiente pueda pagar por un número de IP público fijo (no es mi caso ni mi interés)

Este problemita de tener un número de IP público variable que no nos permite acceder libremente como un nombre o dominio de Internet, desde la Web a nuestro router de casa, lo vienen a salvar los servidores de sistema dinámico de nombres de dominio ó servidores DDNS
Los servicios DDNS mas difundidos son DynDNS, NO-IP y otros, y la mayoría por suerte proveen uno o dos nombres de dominio gratuitos.
Entonces simplemente abrimos y registramos una cuenta con usuario y password en uno de estos servicios que vienen en nuestro auxilio, seleccionamos un nombre de dominio de nuestro gusto, por ejemplo "laslucesdemicasa.ddns.net", claramente con un dominio así cualquier jacker interesado podrá intuir para que sirve el sitio, pero para que quede claro en principio usaremos este , luego se puede elegir alguno no tan explícito.
Entonces una vez que tenemos esta cuenta activada en el DDNS, configuraremos sus datos en la parte WAN/DDNS de nuestro router doméstico, luego mostraré como es esto en mi ENCORE.

5) Enviando comandos desde nuestro cliente remoto.
Una vez logrados estos pasos con éxito, y con el código correspondiente corriendo en el uC, simplemente escribiremos en cualquier navegador de PC en cualquier parte del mundo con acceso a Internet, nuestro nombre de dominio seguido del comando deseado, por ejemplo:
www.laslucesdemicasa.ddns.net/ONN1, y la luz, reflector de patio trasero, u otro dispositivo manejado por el relé número 1 en la placa uC (casi mágicamente) se encenderá , y recibiremos a vuelta de mensaje la confirmación correspondiente de su encendido, y si tenemos alguna cámara de vigilancia doméstica por allí lo verificaremos.
Luego con el comando www.laslucesdemicasa.ddns.net/OFF1 , dicha luz (nuevamente casi mágicamente) se apagará, y recibiremos a vuelta de mensaje nuevamente la confirmación correspondiente.

Como pueden ver está será una manera muy simple y también muy vulnerable de manejar dispositivos eléctricos en nuestra casa u otro sitio, pero que luego podremos complicar o proteger en distintas formas, paswords, comandos codificados, etc.

6) Por último desarrollaremos una App en Android para móvil específica para este proyecto para ya no usar un navegador Web, utilizando para esto la plataforma para principiantes (yo soy uno de ellos) del MIT App Inventor, muy amigable y sencilla de usar.

Bueno, como introducción se ha hecho larga, luego en siguientes posteos veremos cada punto en detalle.

Espero sea un tema de vuestro interés, cualquier comentario o sugerencia como siempre bienvenido.

Saludos
 
Última edición:
Continuando, este simple diagrama en bloques muestra como operará este proyecto y luego haremos referencia a cada una de las líneas

wiznet.jpg

Veremos ahora la configuración de la interface WIZNET que enlazará nuestra red doméstica LAN con el uC
Para esto conectamos la WIZnet a nuestra LAN y abrimos la Wiznet Configuration Tool que con Search realiza una búsqueda automática por MAC address de las placas.

La primera solapa será la de Network donde como dijimos colocamos los parámetros correspondientes de la placa, como TCP Server en nuestra LAN:

wiz1.jpg

En la solapa Serial configuramos los parámetros de interface con la USART del uC, lo típico 9600bps, n 8, 1

wiz2.jpg

Y por último en la solapa Options configuramos el Inactivity Timer , que es el tiempo que tardará el Server en desconectar el enlace TCP si no hay actividad de datos (desconexión por time out), y también podemos configurar una password si requerimos seguridad de ingreso

wiz3.jpg

Y esto sería todo por ahora en la configuración de la interface WIZNET

A continuación vemos la configuración de mi router doméstico que como ya dijimos deberá enrutar las conexiones TCP entrantes en pórtico 80 hacia la interface WIZNET cuyo IP lo hemos configurado en 192.168.1.108. Para otros routers de otros modelos, la configuración será similar.

mo1.jpg

Y luego también en nuestro router debemos habilitar el servicio DDNS con una cuenta previamente dada de alta en algún servidor de nuestra elección. Como ya dijimos el dominio elegido será "laslucesdemicasa" y el servidor será en este caso el DynDNS

mo2.jpg

Y con esto finalizamos las configuraciones básicas de enrutamiento de mensajes del proyecto.

Continuara...
 
Última edición:
Retomando este tema, muestro aquí la placa prototipo muy básica para comenzar probar el proyecto

pic2.jpg

En esta se puede ver la interface WIZNET (lado de abajo) con el cable de red que la vincula a mi router doméstico, luego la circuiterìa (CD40106 a la derecha) para adaptar nivel de entrada y salida serial de uC, y este a su vez tiene el programador PICKit3 conectado por ICSP.
El circuito adaptador serial también provee salidas TX y RX para monitorear los datos con HiperTerminal por medio del adaptador Serial-USB que también se muestra.
Los tres reguladores de tensión que se ven proveen los 3,3 Voltios de la placa WIZNET, que consume casi 1/4 Amper, entonces estos bajan de 12 Voltios a 8 V, de 8 V a 5 V, y el ultimo de 5V a 3,3V y se calientan bastante.
Las salidas para manejar los relès y las luces serán 4 salidas del uC, por ejemplo PA0-PA3 que aun no están cableadas.
Entonces el circuito es muy simple y luego subiré su diagrama
 
Última edición:
Bueno, hemos llegado al punto de realizar las primeras pruebas
Repasemos lo básico de este proyecto, que apunta a lograr encender y apagar luces o dispositivos eléctricos en nuestra casa u otro sitio en general a través de Internet, desde PC, laptop o celular.
Digamos que si hemos hecho todo bien en los pasos anteriores para lograr el enrutamiento de nuestros mensajes, esto es definición de dominio DDNS, enrutamiento interno LAN y apertura de puertos, configuración correcta de la interface WIZ y su conexión al uC,
entonces iremos a cualquier navegador WEB en PC o movil conectado a Internet en cualquier parte del mundo, colocamos la dirección:


y damos Enter, entonces generaremos un mensaje en protocolo HTML tipo GET que viajará por la nube, llegará a nuestra casa y aparecerá en la entrada serial de nuestro uC como el texto siguiente (o algo similar dependiendo de su largo viaje):

LGSEG:CONNECTED
GET /ONN1 HTTP/1.1
User-Agent: Dalvik/2.1.0 (Linux; U; Android 10; ELE-L29 Build/HUAWEIELE-L29)
Host: laslucesdemicasa.ddns.net
Accept-Encoding: gzip

LGSEG: LISTENING

Este mensaje estará en código ASCII y puede ser monitoreado por Hiperterminal o PuTTy en la entrada serial del uC (yo lo hago como se ve en la foto con un convertidor serial-USB y la habilitaciòn del puerto COM correspondiente en la PC).
Las lineas que contienen LGSEG son mensajes de señalización de la placa WIZNET que indican cuando esta establece conexión con el cliente (CONNECTED) y cuando se pone a la escucha como servidor (LISTENING), y se pueden ver/quitar con un tilde en su configuración (ver arriba)
Lo demás que arranca con el encabezamiento GET es el verdadero mensaje que estamos enviando y recibiendo en formato HTML, y que contendrá información variada que dependerá del tipo de navegador y dispositivo que estamos usando para enviar el mensaje (Chrome, Firefox, etc)
Toda esa información en este caso puede ser descartada, pues sólo nos quedaremos con lo importante para este proyecto, que es el encabezamiento y la orden que llega desde el cliente, que en este caso es:

GET /ONN1 que será interpretado como encender LUZ 1, y también podría ser apagarla con GET /OFF1, o encender la nro 3 con GET /ONN3 etc. O sea se enviará ON o OFF y el número de luz o dispositivo debe actuar.

El código para interpretar estos mensajes y actuar en consecuencia es muy sencillo. En mi caso modifiqué el código de maquina de estados que utilicé en los proyectos anteriores para seguir estos mensajes y ejecutar las ordenes, luego colocaré ese código, pero igualmente puede haber otros métodos seguramente mejores para realizar esto.

Como dijimos el uC deberá interpretar y accionar según ordenen estos mensajes y además deberá contestar al cliente alguna confirmación de que la orden fue ejecutada, y para esta respuesta deberá respetar el formato HTML , actuando como ya dijimos como un servidor de página muy básico.
A continuación el código de programa con que el uC podría responder ante el mensaje GET /ONN1

Código:
    call send_crlf  ;enviar caracteres CR y LF (carriage return and line feed)
    movlw 0x3C  ;<   comienza el envio de la pagina html, con el código ASCII del encabezamiento
    call tx_dato     ; rutina de envió de carácter por la USART
    movlw 0x68 ;h  enviando al cliente el encabezamiento HTML de la pagina de contestación
    call tx_dato
    movlw 0x74 ;t
    call tx_dato
    movlw 0x6D ;m
    call tx_dato
    movlw 0x6C ;l
    call tx_dato
    movlw 0x3E ;>
    call tx_dato
    call send_crlf
    movlw 0x4C ;L    comienza el envio de confirmación de luz  encendida
    call tx_dato
    movlw 0x55 ;U         el mensaje serà
    call tx_dato              <LUZ_ONN_X_Z><cr><lf>
    movlw 0x5A ;Z            donde X es el nùmero de dispositivo
    call tx_dato                  y Z es un contador de 0 a 7 que avanza indicando
    movlw 0x5F ;_              la actividad de respuestas
    call tx_dato
    movlw 0x4F ;O    
    call tx_dato      
    movlw 0x4E ;N
    call tx_dato
    movlw 0x4E ;N
    call tx_dato
    movlw 0x5F ;_
    call tx_dato
    movfw LUZREG  ;en este registro esta almacenado el numero de luz encendida, en este caso será 1
    call tx_dato
    movlw 0x5F ;_
    call tx_dato
    movfw ESTAUX ;numero del 0 al 7
    call tx_dato ;se manda un contador de estado para mostrar actividad de respuesta
    movlw 0x5F ;_
    call tx_dato
    ;final del mensaje html
    movlw 0x3C  ;<
    call tx_dato
    movlw 0x2F ;/
    call tx_dato
    movlw 0x68 ;h
    call tx_dato
    movlw 0x74 ;t
    call tx_dato
    movlw 0x6D ;m
    call tx_dato
    movlw 0x6C ;l
    call tx_dato
    movlw 0x3E ;>
    call tx_dato
    call send_crlf
    call send_crlf

Como puede verse esta es una respuesta muy sencilla que será interpretada por el cliente remoto como confirmación que la orden fue ejecutada, escrita paso a paso para que quede claro que es lo que se envía.
Por supuesto el código se puede optimizar con tablas de mensajes, uso de EPROM, etc.
Entonces hasta aquí la primera parte de este proyecto estaría finalizada pues ya podemos manejar luces y dispositivos de nuestra casa u otro sitio utilizando cualquier navegador desde movil u ordenador.
Faltaría el código completo de uC que colgare luego
También faltaría el desarrollo de una App cliente especifica que actúe según lo explicado, pero del punto de vista del uC no habrá grandes cambios y el código básicamente será el mismo, interpretación de la orden, su ejecución y envío de confirmación.

Para cualquier duda hasta aquí, quedo a disposición

Un saludo
 
Última edición:
Atrás
Arriba