jueves, 27 de octubre de 2016

Enviando órdenes a nuestro ESP8266

En entradas anteriores dejamos lista la parte web para poder interactuar contra nuestro servidor en la raspberry. Se preparó una interfaz web en django y se servía con Apache para poder interactuar con nuestras arduino.
Para hacer las pruebas posteriores, en django, en un template cualquiera de prueba simulé un botón de prueba con un link, por ahora suficiente para comprobar que el sistema base funciona bien. Debajo teneis un par de imágenes con la página y la URL que tiene añadida.










Principalmente hay que recordar dos ideas básicas muy importantes de estos pequeños módulos y es que primeramente estos módulos son capaces de albergar un pequeño servidor web, por lo que son capaces de recibir órdenes desde cualquier punto de la red local en forma de petición web, del estilo htttp://ip_wifi_esp012/parametrosAenviar

De ahí que en el href pusiera href="http://192.168.0.207/P13"
El párametro /P13 lo entenderá el Arduino Uno pues lo tendrá incluído en su código para activar y desactivar el Led de pruebas de la placa.

Es muy importante esta cuestión y lo que simplifica mucho las cosas, ya que son capaces de lo que reciben transmitirlo al puerto serie y pasárselo al arduino el cuál tomará decisiones en función del código.

Otra idea importante que sale a la luz es que al estar conectada a nuestra wifi particular es muy simple enviarle órdenes desde cualquier dispositivo, incluso pudiendo enviarlos sin estar en casa, mediante una vpn, etc. pero este capítulo por ahora no nos concierne.



La imagen anterior corresponde a un ESP07 soldado a pelo, y la imagen de debajo una pequeña mejora con una placa conversora para poder pincharla en una protoboard.



Voy a recordar las conexiones que tenemos hechas de entradas anteriores, y voy a volver a explicar un poco lo que tengo montado por si hay algún rezagado o da pereza mirar entradas anteriores. 

Lo que se ve en la imagen anterior es un conversor de 220v a 5v, y a la salida de este un regulador de tensión regulable puesto a 3,3v porque es el voltaje que deben recibir los módulos ESP012. En realidad lo he puesto a 3,4v por si oscila para que no baje de 3,3v, ya que si baja de 3,3v (lo sé por experiencia haciendo pruebas), los módulos juegan malas pasadas, se desconectan, etc, etc, etc. 
El regulador a 3,3v lo tengo conectado a la protoboard donde tengo pinchado en ESP de la siguiente manera:

GPIO015 a GND.
GPIO00, GPIO02, CH_PD a Vcc(3,3v).
TX a Tx del módulo Arduino Uno. (Lo modificaremos después por software).
RX a Rx del módulo Arduino Uno. (Lo modificaremos después por software).
GND Esp a GND protoboard.
Vcc ESP a Vcc protoboard(3,3v). 

No es necesario pero recomendable ir conectando los cables en el orden que los he descrito. Si no funciona al final de conectar todo, teneis un pin de reset en el arduino que lo debereis pinchar a masa y luego soltarlo para resetear el ESP. 

Otro detalle importante es puentear el GND de la placa de arduino con el GND del ESP. Para esto cruzar un cable como se ve en la fotografía en negro de la protoboard al arduino. Si no se hace puede ser perjudicial para la salud de los aparatos.

Como vemos el ESP y el Arduino se comunican a través del puerto serie, son las únicas conexiones que los une directamente. 

Otra opción podría ser dejar libre el puerto serie por hardware del arduino y conectar a otros pines digitales diferentes el Tx y Rx del ESP para dejar libres los hardware del arduino, que es como lo haremos. 
Tx del ESP al pin 3
Rx del ESP al pin 2

El Arduino Uno está conectado por USB al ordenador y hay un par de cosas que deberemos hacer para poder ver lo que está haciendo el ESP.

Primeramete subimos al arduino Uno el siguiente sketch:



Luego abrís la consola del puerto serie y configurarla de la siguiente manera:
Ajuste de Línea ponerlo como "Both NL & CR". IMPORTANTE! Sino no funcionará.

Baud en principio ponerlo a 11520, y si no funciona probar 9600 u otras, cada módulo es un mundo.

Si todo ha salido bien, el módulo debe devolver un "READY" tal y como muestro en la imagen de a continuación. Si hay problemas, el módulo devuelve basurilla u otra cosa diferente probar a pinchar el RST del ESP a GND durante un segundo y soltarlo para que reinicie el módulo. Si el problema persiste probad a diferentes velocidades.


Ya estamos en disposición de empezar a jugar con el módulo, conectarlo a la WIFI, mandarle comandos, ver información, etc.

Haré una breve lista ordenada de los comandos que nos interesan a nosotros para nuestra tarea.
  • Reiniciar el módulo: AT+RST
  • Confirmar que el módulo está operativo: AT
  • Modo trabajo como cliente: AT+CWMODE=1
  • Escanear redes al alcance: AT+CWLAP
  • Acceder a una red inalámbrica: AT+CWJAP="SSID","Password"
  • Consultar la IP del módulo: AT+CIFSR
  • Permitir múltiples conexiones: AT+CIPMUX=1
  • Arrancar el servidor web en el puerto 80: AT+CIPSERVER=1,80
Sabiendo estos comandos ya podemos trabajar. Podeis consultar más en la página del módulo.

 El servidor web de cada módulo, recordemos que tiene sentido para enviarle las peticiones desde nuestro proyecto web y que se las pase al arduino por puerto serie, con el fin de que arduino interactúe con diferentes sensores o actuadores. 

En este momento, si abrimos un navegador o desde nuestro proyecto de django presionamos en el botón ON/OFF, vemos como se ilumina el led del Arduino Uno y se apaga.




Si lo queremos hacer desde el navegador.

Y esta es la respuesta que obtenemos en la consola serie del arduino. Cada vez que se produce una petición el códido del arduino identifica el parámetro "P13" que le enviamos y lo enciende o lo apaga, sacando por la consola el mensaje "Invirtiendo pin 13".
Mientras no se cierra la conexión, no aparece el mensaje de CLOSED, pero si se pasa el timeout o se detiene la conexión en el navegador lanza el mensaje de CLOSED.



Si quisiéramos manejar más señales que P13 bastaría con añadir al código del arduino fragmentos de este estilo:


martes, 11 de octubre de 2016

Nginx trabajando con Apache2 y Mod_WSGI

Hola a todos,

Estos días he estado leyendo documentación sobre alternativas al Apache para mejorar el rendimiento de nuestro servidor en la raspberry y he visto soluciones interesantes.

Apache funciona perfectamente sirviendo ficheros estáticos de nuestro proyecto en Django, pero consume más recursos que otros servidores web. Buscando alternativas por internet me topé con un servidor web el cual desconocía su existencia hasta ahora: nginx.

Antes de nada decir que no voy a implantar nginx (por ahora), quedaría para una futura mejora, pero si voy a mencionarlo y la posibilidad de trabajar conjuntamente con Apache para repartirse el trabajo. 

Tanto Nginx como Apache son dos servidores web potentes y eficaces. Apache es el servidor que más usado actualmente, Nginx, desde su lanzamiento público en 2006, es ahora el segundo servidor web más usado. Las razones de la popularidad de cada respectivo servidor son claras: el poder de Apache y velocidad de nginx son bien conocidos. Sin embargo, ambos servidores tienen inconvenientes: Apache es consume demasiada memoria del servidor, mientras que Nginx necesita la ayuda de php-FPM o módulos similares para servir contenido dinámico.
Sin embargo, podemos combinar los dos servidores para conseguir el máximo rendimiento, con Nginx como servidor de ficheros estáticos en el front-end y Apache se encargará del procesamiento dinámico en backend.

Este sería el escenario tradicional de un servidor web:





Solemos utilizar Apache para servir cualquier tipo de contenido a través de una petición HTTP, pero en Apache cargamos habitualmente muchos módulos necesarios para que nuestras aplicaciones funcionen correctamente, empezando por el mismísimo PHP, pero que no necesitamos para servir contenidos estáticos (imágenes, archivos css o javascript, archivos comprimidos…).

Lo que se pretende hacer es separar de una manera sencilla las peticiones esta´ticas de las dinámicas con el fin de redirigirlas a distintos servicios y conseguir qeu las peticiones estáticas consumiesen muchos menos recursos ya que las podríamos hacer con un servidor mucho más ligero que Apache: Nginx

Este sería el esquema de red al que se pretende llegar





Todas las peticiones HTTP son recibidas en el puerto 80 por un servidor mucho más ligero que Apache (nginx, lighttpd) que se encarga de servir directamente los contenidos estáticos desde el disco y de redirigir las solicitudes dinámicas al Apache de siempre que ahora escucha en el puerto 8080, es decir, el servidor ligero actúa como proxy para las peticiones de contenidos dinámicos.

 El primer paso, por tanto, es instalar y configurar Nginx para que actúe como proxy completo.

Pondremos a Nginx para que escuche en el puerto 80 y redirigirá las peticiones dinámicas a Apache en el puerto 8080.

Si se ha entendido la idea, es precisamente lo que buscaba. En caso de darme tiempo o en el futuro lo desarrollaré para que mi servidor de domótica vaya más fluído.

Un saludo.