Diagrama de clases (clase ObjetoConectado, PlacaHW)

Seguimos con el diagrama de clases, ahora con los actuadores y los sensores y placas auxiliares que nos servirán al sistema:

Es fácil ver cómo de nuevo la clase ObjetoConectado herede de ObjetoGeneral, que era la clase que encapsula algunos de los métodos de gestión, la clase ObjetoConectado añade un atributo que el un puntero a un objeto Conexion.

Conviene mencionar también la clase ObjetoControl, que no es sino un contenedor de sensores y actuadores. Esta clase nos va a dar posibilidades de agrupamiento. Por ejemplo, si tuviéramos que controlar una piscina, un jardín y un edificio, se podrían dar de alta 3 ObjetoControl, si el control es independiente. Es decir, los Actuadores y Sensores colgarán de los ObjetosControl.

La clase Actuador de momento no la desarrollaremos mucho, podrá ser un Contactor o un Telerruptor (es importante porque el modo de activación cambia) y todavía no entraremos en control de velocidad de motores o incluso de servos.

La clase PlacaHW nos va a servir para gestionar HW externo a la placa Arduino Mega. Esto es, he decidido introducir ademas de la ATMega de Arduino (aprox unos 11€ en amazon):

• Placa DS3231: funcionalidad RTC con sensor de temperatura interno en un bus I2C): nos da el control de hora con una batería y funciona de maravilla (unos 2€ en amazon).

• Placa SD para tarjeta microSD: bus SPI, nos va a permitir acceder a una tarjeta microSIM, en mi caso he metido una de 16GB, lo que nos da una versatilidad en almacenamiento de datos muy relevante. A su vez, esta tarjeta va a almacenar datos de configuración, ficheros log, eventualmente podríamos meter el código html de un servidor, ... lo que necesitemos (unos 2€ + tarjeta microSIM aparte que pueden ser otros 6€ una EVO Samsung de 16GB).

• Placa ESP8266: implementa WLAN, interfaz serie. Esta es un poco más cara, unos 7-9€ en amazon.

• Placa HC-05: implementa Bluetooth, interfaz serie. Unos 5€, ojo, no confundir con la HC-06, que algo más barata, pero solo nos vale como esclavo, no como master:

Finalmente conviene tener un modulo de alimentación MB102, son unos 5€ y te soluciona la vida con los 5V y los 3,3V, evitando inestabilidades en los módulos ESP sobre todo (esta placa no la vamos a gestionar de momento, ya veremos cómo aseguramos alimentación al sistema y la medimos, habrá que hacer algo de HW externo y conectar una sensor analógico para medir tensión en la entrada):

Entrando en la clase Sensor, vemos una especialización progresiva. Lo más importante es que debemos entender la naturaleza de los sensores que a priori pueden ser Binarios o de Rango, es decir, ON/OFF o que nos de un float como valor. La idea es que cada vez que invoquemos un método (actualiza_valor) nos devuelva el valor del sensor sin saber qué hay debajo o cómo se gestiona.

Conviene ver que para los sensores de Dallas, aprovechamos la libreria de Dallas, que implementa muchas de las funciones necesarias para escanear las direcciones, inicializar o leer las temperaturas, recordemos que estos sensores de temperatura pueden estar en el mismo bus 1-wire y lo mejor de todo, por un precio muy bajo (poco más de 2€), los tenemos hasta sumergibles (ds18b20 -  http://datasheets.maximintegrated.com/en/ds/DS18B20.pdf).

Todo esto nos configura una arquitectura HW como la siguiente:

Con la arquitectura SW que propongo, podemos también la posibilidad de tener actuadores y sensores vía WIFI o BT, lo que nos dará una flexibilidad importante, habida cuenta de que los pines son finitos. En este caso, también tendremos que diseñar los protocolos entre ellos.

Veremos cómo al final la limitación importante será la de la memoria del micro.

En resumidas cuentas, el sistema son unos 40€, equipandolo con RTC, un primer sensor de temperatura interno, WLAN, BT y alimentación estabilizada.

Bueno, hasta aquí esta parte, va tocando ponerse a codificar ...

Diagrama de Clases (clase Conexion)

A continuación vamos con el diagrama de clases (por aquello de programar en C++ y C#). Esta es la parte más espesa, pero qué le vamos a hacer, creedme que luego nos ahorrará mucho tiempo si lo hacemos bien.

Es necesario introducir que un sistema de estas características básicamente tiene dos tipos de objetos:

1. Sensores: toman medidas del mundo exterior (temperatura, activaciones de pulsadores o interruptores, humedad, ...).
2. Actuadores: realizan acciones sobre cosas del mundo exterior (contactores, telerruptores, accionadores de persianas, controladores de motores, ...)

Bueno, habíamos comentado que queríamos varias cosas:

• Gestionar la plataforma
• Englobar diferentes tipos de conexión 
• Englobar diferentes tipos de actuadores y diferentes tipos de sensores
• Acceder de forma remota

En este sentido, lo que haremos es intentar aislar las capas más bajas de los protocolos de comunicación de las más altas. Esto es, que desde las funcionalidades que demos a los sensores, quede encapsulado (no tengamos que preocuparnos) si se conectan por buses SPI o I2C o incluso directamente. En este sentido he dividido los objetos en dos, uno que describe su funcionalidad, y otro que describe como se conecta, uno será un ObjetoConectado, que tendrá como atributo o campo una Conexión.

A continuación se puede ver el cómo la clase Conexion se especializa en diferentes tipos de conexión:

Acudiendo a la parte inferior de las herencias, vemos los diferentes tipos de conexion que implementaremos. Según vamos bajando, se ve cómo se especializan las clases:

1. Digital: es una conexión física a un pin digital.
2. Digital_ext: es una conexión física a un pin digital, pero que además tiene otro pin asociado que permite activaciones directas.
3. Analógica: es una conexión física a un pin analógico, meramente será utilizada por sensores analógicos.
4. DHT: es una coenxión que implementa lecturas de los sensores DHT-11 y DHT-12. Es específica para estos.
5. USB: conexión serie.
6. Bluetooth: conexión serie pero a una placa HC-06 que implementa de forma quasi transparente la comunicación inhalambrica.
7. WLAN: conexión serie pero a una placa ESP8266, que implementará las comunicaciones 802.11.
8. CONEX_I2C: implementa las comunicaciones serie a través de 2 pines configurables. En el caso de la Mega, vienen ya dos pines a tal efecto.
9. CONEX_SPI: igual pero para el bus SPI, en este caso solo configuraremos los pines comunes del bus, cuando demos de alta algún objeto conectado, habrá que proporcionar el SS respectivo. A priori lo utilizaremos para la placa controladora de la microSD, pero se podría conectar un display i2c o cualquier otro elemento con dirección distinta.
10. CONEX_ONEWIRE: implementa el protocolo 1-wire. Nos vendrá muy bien para algunos sensores de Dallas, por ejemplo.
11. ETHERNET: comunicaciones 802.3.

Conviene comentar la clase ObjetoGeneral, que es la clase de la que heredarán todas las demás clases de la plataforma. Esta clase nos va a dar algunas funciones pseudoadminsitrativas para la gestión, impresión y demás de los obejtos que luego creemos en el sistema. Con eso conseguimos una reutilización de código (esto es puro C++) y el encapsulado del mismo. Podéis ver la clase definida a la derecha.