Regador para césped con Netduino y servicios en nube

La nueva moda de Domótica es utilizar la tecnología para ser ecológico refiriéndose al manejo de los recursos de manera más eficiente. En este contexto  existen muchos aficionados  construyendo proyectos que gestionan la cantidad de electricidad o de gas que utilizan dentro de su casa. En este proyecto   Mike Linnen va a manejar la cantidad de agua que se  usa para regar su césped. En la parte primera a cubre el panorama general del proyecto de hace, después la demo  del sistema  y al  final   el flujo de datos

Requerimientos
Por supuesto se  necesitaban algunos requisitos para definir el alcance de lo que Mike Linnen  estaba tratando de hacer.

• Soporte para hasta 4 zonas
• Ser capaz de activar manualmente 1 o más zonas (máximo 4) y hacer que se ejecuten durante un período de tiempo
• Ser capaz de programar 1 o más zonas (máximo 4) para llegar a todos los días a una hora específica del día varias veces al día.
• Ser capaz de programar 1 o más zonas (máximo 4) para llegar a todos los lunes, miércoles y viernes a una hora específica del día varias veces al día.
• Ser capaz de programar 1 o más zonas (máximo 4) para llegar a todos los martes y jueves en un momento específico de los días varias veces al día.
• Ser capaz de apagar el sistema de modo que las zonas programadas o manuales se apague inmediatamente o no encenderá a su hora programada.
• Ser capaz de hacer cualquiera de los requisitos anteriores de forma remota.
• No encienda el rociador si la lluvia es en el pronóstico (Go Green)
• No encienda el aspersor si el suelo ya está lo suficientemente húmedo (Go Green)
• Ser capaz de ajustar automáticamente el reloj cuando cambia el horario de verano.

Al principio Mike Linnen  iba a hacer que el sistema de rociadores un dispositivo completamente autónomo en el que podría fijar el calendario utilizando un teclado y una pantalla LCD. Esto  permitiría controlar completamente el dispositivo sin conectarse remotamente a ella. Pero el autor quería controlar el dispositivo de forma remota todos modos y el costo de los esfuerzos de desarrollo de hardware y sería más alto para un dispositivo independiente, decidío abandonar las “únicas” capacidades.  El autor  quería que la posibilidad de desactivar el sistema de rociadores sin conectarse remotamente a ella y también quería una forma rápida de saber si el dispositivo estaba apagado o no. Un interruptor de botón pulsador puede utilizarse para encender el rociador inmediatamente. Un par de LEDs se pueden utilizar para hacerle saber lo que el modo de aspersor está encendido o no.

El rociador
El autor utiliza un  Netduino Plus como el microcontrolador que opera las cabezas de los aspersores. Elijió este dispositivo, ya que utiliza  .Net Micro y también tiene un controlador Ethernet incorporado, lo que hace que la conecta a la red una tarea muy fácil. Se puede usar muy fácilmente otro dispositivo para controlar los aspersores siempre que pueda manejar los mensajes HTTP y tenga suficiente I / O para interactuar con el resto del hardware necesario.

Este dispositivo es responsable de lo siguiente:

• Supervisar la programación y encender losaspersores si es elmomento de hacerlo:
  •  4 salidas digitales
  • A bordo de reloj para saber cuándo ejecutar la hora programada
• Esté atento a las peticionesJSONHTTP que se originan en elWindowsPhone
  • El etherent bordo funciona bien para esto
• Esté atento a las peticionesJSONHTTP que se originan en el servicio meteorológico diciendo elaspersor la probabilidad de lluvia
  • El etherent bordo funciona bien para esto
• Esté atento a las peticionesJSONHTTP que se originan en el servicio de tiempo contando elaspersor para cambiar su reloj a bordo
  • El etherent bordo funciona bien para esto
• Al encenderse pedir el servicio de hora de la hora correcta
  • El etherent bordo funciona bien para esto
• Supervisar el botónOff y el ciclo de la modalidad delaspersor a través de los 3 estados:Off / Manual / Programada
  • 1 entrada digital
• LED amarillo se enciende cuando en el estado Manual
  • 1 Salida Digital
• ElLED verde se enciende cuando en el estado Lista
  • 1 Salida Digital
• Vigilar la humedad del suelo (Nota: No he hecho mucha investigación sobre cómo estos sensores funcionan por lo que este podría cambiar)
  • 1 entrada analógica
• Persisten los programas manuales y programadas para que un ciclo de alimentaciónWont estos valores
  • La tarjeta SD de a bordo

Los modos de rociadores necesitan un poco de discusión más. Cuando está en el modo de apagado las cabezas de los aspersores no se enciende pero la placa  estará encendido y escuchará cualquier petición HTTP y supervisara el pulsador. Al ir  al modo de apagado de cualquier otro modo los aspersores se apagarán si fueran sucesivamente. Cuando un ciclo en el modo Manual de cualquier otro modo el aspersor se ejecutará inmediatamente el programa manual de encender las zonas apropiadas para la longitud de tiempo apropiado. Si no hay ningún programa Manual existe entonces el aspersor no hace nada. En el modo programado las esperas de rociadores para el día y la hora programada para encender las zonas apropiadas para el período de tiempo apropiado a menos que el suelo ya está húmedo o lluvia está en el pronóstico.

El mando a distancia
El mando a distancia es la única manera de programar el aspersor, ya que no tiene ninguna interfaz de usuario para esta tarea. No puede haber muchos dispositivos diferentes que sirven de control remoto, pero Mike Linnen  tiene la intención de utilizar un   Samsung Focus Windows Phone 7 para este propósito.

La aplicación de este dispositivo sólo tiene que enviar HTTP GET y peticiones de correos. Dependiendo del tipo de solicitud de un mensaje JSON puede ser necesario en el cuerpo de la solicitud (es decir, el envío de datos al aspersor). También dependiendo del tipo de solicitud de la respuesta puede contener JSON (es decir, la devolución de datos desde el aspersor).

Mike Linnen  opto  por usar HTTP y JSON como el mecanismo de comunicación entre el control remoto y el aspersor para que  pudiera seguir siendo independiente de la plataforma.

Conexión de la distancia para el rociador
El aspersor con Netduino se sienta detrás del cortafuegos. Si se quiere comunicar  con el rociador con un dispositivo que no está detrás del firewall entonces las cosas empiezan a ponerse un poco malass básicamente, se tienen las siguientes opciones:

• No exponga el aspersor con el mundo exterior (tipo de limitación).
• El microcontrolador rociadores tendría que sondear algún servidor en Internet para que cualquier nuevo mensaje que debe procesar (un montón de trabajo pesado para el controlador).
• Haz un agujero en mi servidor de seguridad para que pueda obtener a través de ella a través de Internet (puede usted por favor me hackear).
• Utilice Windows Azure Service Bus (pan comido).

El servicio de bús permite hacer conexiones de salida a la infraestructura de nube de Windows Azure y la mantiene abierta para que cualquier dispositivo externo puede hacer llamadas a procedimiento remoto al punto final detrás del firewall. Mike Linnen decidió utilizar la v 1.0 liberación de bus de servicio por ahora, pero en el futuro  podía ver este cambio donde le gustaría utilizar más de una infraestructura de publicación / suscripción de mensajería (que está en una futura versión de Service Bus) en lugar de una llamada a procedimiento remoto.

Para aprovechar el servicio de bús debe tener un host que se encuentre detrás del cortafuegos y hace que la conexión a la plataforma en la nube Azure. Para el propósito de este post esta llamando este servicio el conector principal. La responsabilidad de este servicio es para conectar con el servicio de bús como un host para que pueda aceptar llamadas a procedimiento remoto desde un cliente. El cliente en este caso  llamá al conector remoto.

El Conector de Inicio
El Conector Home es un servicio de Windows que se ejecuta en una de las máquinas de las ventanas detrás del  firewall. Cuando una llamada a procedimiento remoto viene en que se convierte en un HTTP Get o demanda Publicar JSON que se envía al aspersor Netdunio. La respuesta de  Netduino es luego analizada y regresa  de nuevo a la persona que llama RPC. Este enrutamiento de mensajes de Service Bus para dispositivos detrás de  un  firewall está construido con la mentalidad de que más de un microcontrolador Netduino estará dando servicio a las llamadas RPC desde un dispositivo remoto a través de internet. Así que esta arquitectura no se limita a sólo el sistema de rociadores. Mike Linnen  tiene la intención de añadir más microcontroladores en la misma mansión y registrarlos con el conector de casa para que ellos también puedan atender las solicitudes RPC.

El Conector remoto
Mike Linnen  podría haber elegido esta capa entre el teléfono y el aspersor. Dado que el teléfono no sería capaz de utilizar el servicio de autobús DLL directamente podría haber utilizado el bús Servicio WebHttpRelayBinding que le permitiera enviar mensajes al bus a través de una API REST estilo directamente desde el teléfono. Pero  quería otra capa entre el teléfono y el de riego para que  pudiera almacenar en caché algunas de las peticiones para evitar que mi aspersor de conseguir bombardeado con mensajes. Necesitaba un marco web ligero que haría que la creación de mensajes HTTP GET / POST JSON fácil.

Mike Linnen  elijó  utilizar el marco NancyFX porque parecía encajar el proyecto de ley de ser rápido y fácil de poner en marcha. Eso sí que fue el caso cuando tiré de ella hacia abajo y empezó  a construir la primera HTTP Get manejador. Simplemente creado un sitio web vacío y usé nugetto instalar NancyFX en este sitio en blanco existente. Después de eso he creado una clase de módulo y definí mis rutas y manipuladores de las rutas y yo estaba corriendo con mi primera solicitud GET en unos 15 minutos. El marco NancyFX también maneja el procesamiento de mis mensajes JSON con muy poco esfuerzo de mi parte. Todo lo que realmente necesitaba que hacer es tener un modelo que representa el mensaje JSON y realiza una operación de enlace en él y la modelo terminó totalmente poblada. No he tratado de jugar con el almacenamiento en caché las respuestas todavía, pero no creo que va a ser muy difícil.

Es importante entender que este conector remoto no tiene que estar en un papel web Azure a trabajar. Yo podría implementar fácilmente este sitio web a otro proveedor de alojamiento que puede ser un poco más barato utilizar.

Conclusión
El Netduino, Servicio de Bus y framework web NanacyFX todos parecían ser bastante fácil de que me va sobre la conexión de dispositivos en la casa con un teléfono. En el momento de este post no he terminado el sistema de rociadores pero dieron un extremo a otro ejemplo del uso del teléfono de Windows para controlar un Netduino detrás del firewall sin perforar ningún agujero en el router. Pasé la mayor parte del  tiempo trabajando en los temas de análisis de JSON a través de múltiples dispositivos a continuación, en realidad conseguir la infraestructura en el lugar.

Esto abre un nuevo mundo de posibilidades para  la conexión de varios dispositivos para el hogar al teléfono y otros servicios. Antes de ir a una casa de varios dispositivos que lo más probable es alejarse de las llamadas RPC e introducir una mayor publicación / suscripción modelo de paso de mensajes alrededor. De esa manera se puede desacoplar los productores de mensajes de los consumidores de mensajes. Probablemente sea interesante esperar a que los bits Azure Service Bus nuevos antes de abordo ese problema sin embargo.

Una cosa queMike Linnen  pensó mientras se hace este proyecto es la cantidad de inteligencia (código) debía estar poniendo en el dispositivo Netduino que realiza toda la funcionalidad de programación en el Netduino. Así que una vez que el Netduino recibe su horario pre-programado que, básicamente, se puede ejecutar sin ninguna otra comunicación del mundo exterior (siempre y cuando el poder no hace ciclo). Sin embargo, la funcionalidad de programación que se construye en mi código de rociadores es un poco limitante. Si  quería añadir más características a la funcionalidad de programación que  requeriría la construcción de una gran parte de la lógica en el código de rociadores Netduino. Esto significa también que necesitaría para desplegar más bits para el dispositivo aspersor. Como se puede obtener imágenes que puede convertirse en una pesadilla si el despliegue de una gran cantidad de clientes están utilizando este producto. Hay maneras de resolver este tipo de problemas de implementación mediante la automatización del proceso de actualización, pero otra solución es eliminar la inteligencia de programación desde el propio dispositivo aspersor y el lugar que la lógica en un servicio en la nube. Básicamente el dispositivo aspersor sabría nada acerca de un horario y se dijo cuando se encienda y cuánto tiempo las zonas debe ejecutar para. Esto eliminaría una gran cantidad de código que está en el dispositivo y hacer más fácil para agregar nuevas características al servicio. Por supuesto eso significa que el dispositivo aspersor tiene que estar conectado a internet en todo momento con el fin de trabajar pero eso es factible.

Aquí hay un video que muestra cómo funciona el sistema de regadera del césped

El código para el proyecto se encuentra en bitbucket en https://bitbucket.org/mlinnen/lawnsprinkler.

Las diapositivas de Power Point para la presentación también se publican en la carpeta docs del repositorio de fuentes https://bitbucket.org/mlinnen/lawnsprinkler/src/f5cd6cda9501/Docs/.

Finalmente esta es la parte  que muestra cómo los comandos que controlan un flujo de rociadores a través de la infraestructura y llegan al destino final de la Netduino Plus. Este video cubre lo que los componentes se utilizan en el sistema para conectar un teléfono de Windows 7 a la regadera del césped basada Netduino así como la forma de un Servicio Meteorológico puede enviar datos a la Netduino. Tmbien cubre la conexión de dispositivos a los dispositivos y servicios a todos los dispositivos con el Azure AppFabric Service Bus.
Aquí está el video:

Fuente aqui