DISEÑO E IMPLEMENTACIÓN DE UN SISTEMA DE MEDICIÓN DE

CONSUMO DE ENERGÍA ELÉCTRICA Y AGUA POTABLE REMOTO CON

INTERACCIÓN AL USUARIO BASADO EN EL CONCEPTO “INTERNET DE
LAS COSAS”

GERARDO GUACANEME VALBUENA.

9920553.
DIDIER ALEXIS PARDO AGUDELO.
20042005070.

UNIVERSIDAD DISTRITAL
FRANCISO JOSÉ DE CALDAS
FACULTAD DE INGENIERÍA ELECTRÓNICA
2016.
 CONTENIDO

I. INTRODUCCION……………………………………………………………………………… 1
II. PLANTEAMIENTO DEL PROBLEMA………………………………………………………. 2
III. ANTECEDENTES……………………………………………………………………………… 2
IV. OBJETIVO GENERAL………………………………………………………………………… 4
V. OBJETIVOS ESPECÍFICOS…………………………………………………………………… 4
VI. JUSTIFICACIÓN………………………………………………………………………………. 5
VII. ALCANCES Y LIMITACIONES……………………………………………………………… 6

1. INTERNET DE LAS COSAS………………………………………………………………….. 7

1.1 COMPONENTES DE UNA IoT………………………………………………………... 8
1.2 MODOS DE COMUNICACIÓN E INTERACCIÓN………………………………….. 9

2. MÉTODO DE MEDICIÓN DE CONSUMO DE AGUA……………………………………… 13

2.1 CLASIFICACIÓN GENERAL DE LOS MEDIDORES DE FLUJO………………….. 13
2.2 CRITERIOS PARA LA SELECCIÓN…………………………………………………. 14
2.3 SELECCIÓN DEL TIPO DE DISPOSITIVO………………………………………….. 17
2.4 MEDIDOR DE FLUJO VOLUMÉTRICO…………………………………………….. 17
2.5 SENSOR SELECCIONADO…………………………………………………………... 20
2.6 CONCLUSIONES……………………………………………………………………... 24

3. MÉTODO DE MEDICIÓN DE CONSUMO DE ENERGÍA ELÉCTRICA…………………… 26

3.1 CLASIFICACIÓN GENERAL DE LOS MEDIDORES DE ENERGÍA ELÉCTRICA… 26
3.2 CRITERIOS PARA LA SELECCIÓN…………………………………………………… 28
3.3 SELECCIÓN DEL TIPO DE DISPOSITIVO……………………………………………. 31
3.4 MEDICIÓN DE CORRIENTE…………………………………………………………... 31
3.5 MEDICIÓN DE VOLTAJE……………………………………………………………… 33
3.6 SENSOR SELECCIONADO…………………………………………………………….. 33
3.7 CONCLUSIONES………………………………………………………………………... 41

4. MÉTODO DE COMUNICACIÓN DE DISPOSITIVOS……………………………………….. 42

4.1 PROTOCOLOS DE COMUNICACIÓN ENTRE DISPOSITIVOS…………………….. 42
4.2 SELECCIÓN DEL MÓDULO DE COMUNICACIÓN INALÁMBRICO……………… 43
4.3 DISPOSITIVO WIFI ESP8266EX……………………………………………………….. 44
4.4 CONCLUSIONES………………………………………………………………………… 54

5. INTEGRACIÓN DE ELEMENTOS Y ELABORACIÓN DE OBJETOS IoT…………………. 55

5.1 ESQUEMA GENERAL…………………………………………………………………... 55
5.2 CARACTERÍSTICAS DEL MICROCONTROLADOR………………………………… 57
5.3 CARACTERÍSTICAS DE LA MEMORIA………………………………………………. 58
5.4 INTEGRACIÓN DE ELEMENTOS DEL HARDWARE………………………………... 59
5.5 PROGRAMACION: MODOS DE OPERACIÓN………………………………………... 63
5.6 ESTRUCTURA DE DATOS ENVIADOS POR EL OBJETO IOT……………………… 75
5.7 ENSAMBLE DE OBJETOS IoT…………………………………………………………. 79

6. CONEXIÓN DE LOS OBJETOS IoT A LA WEB……………………………………………… 80

6.1 BASE DE DATOS………………………………………………………………………... 81
 6.2 WEBSOCKET…………………………………………………………………………….. 83
6.3 DISEÑO BACK-END (NODE.JS)……………………………………………………….. 87
6.4 DISEÑO FRONT-END…………………………………………………………………… 89
6.5 FUNCIONAMIENTO DEL SERVIDOR………………………………………………… 92
6.6 PRUEBAS DEL SERVIDOR WEB……………………………………………………… 98
6.7 CONCLUSIONES………………………………………………………………………… 108

7. ETIQUETADO E INTERACCIÓN DE OBJETOS IoT………………………………………… 109

7.1 GENERACIÓN DE CÓDIGOS QR……………………………………………………… 111
7.2 PASOS PARA EL ACCESO AL OBJETO IoT MEDIANTE CÓDIGOS QR…………... 112
7.3 PERFIL PÚBLICO DEL OBJETO IoT DE CONSUMO DE AGUA……………………. 113
7.4 PERFIL PÚBLICO DEL OBJETO IoT DE CONSUMO DE ENERGÍA………………... 115

8. CONCLUSIONES Y CONSIDERACIONES FUTURAS………………………………………. 117

8.1 CONCLUSIONES………………………………………………………………………… 117
8.2 CONSIDERACIONES FUTURAS………………………………………………………. 118

9. MANUALES DE OPERACIÓN………………………………………………………………… 120

9.1 INSTALACION Y CONFIGURACION DE LOS DISPOSITIVOS WIFI………………. 120
9.2 MANUAL DE USUARIO DE LA INTERFAZ WEB…………………………………… 126
9.3 ESPECIFICACIONES TÉCNICAS………………………………………………………. 130
9.4 COSTOS…………………………………………………………………………………… 131

10. BIBLIOGRAFÍA…………………………………………………………………………………. 133

 I. INTRODUCCION

El presente proyecto aplica las características generales de la denominada “Internet de las

Cosas” (Internet of Things, IoT abreviadamente, como se usará en adelante) en un sistema
orientado a la medición de variable propias de un ambiente domótico. IoT ha madurado
como consecuencia del desarrollo de nuevos dispositivos de comunicación que permiten un
fácil acceso a redes conectadas a Internet, así como la aparición de sistemas de
identificación electrónicos capaces de compartir información sobre los objetos a los cuales
se encuentran asociados. Este concepto brinda nuevas posibilidades de interacción, ya sea
en el hogar, en ambientes industriales o comunitarios diversos generando un aumento no
sólo en la información disponible del entorno, sino también en las acciones que se pueden
ejecutar a partir del conocimiento de variables y estados seleccionados. IoT se encuentra
inmerso dentro del marco de los denominados sistemas ubicuos cuya pretensión es
transformar la computación actual en una donde los sistemas informáticos en general se
encuentran inmersos de forma natural en los entornos humanos e interconectados a través
de redes inteligentes.

Las secciones II a VII describen los requisitos propios del proyecto (alcance y limitaciones,
objetivos, justificación y antecedentes). En el capítulo 1 se mencionan las generalidades de
la IoT y sus elementos componentes, para pasar a la selección de los sensores de medición
de consumo de agua portable (capítulo 2) y energía eléctrica (capítulo 3), en estos se ha
seguido una metodología de exploración de las diferentes técnicas de medición y la
selección de la más conveniente de acuerdo a la naturaleza del proyecto. En el capítulo 4 se
selecciona el método de comunicación y el módulo inalámbrico que se incluirá en los
objetos IoT y que dotará de interactividad a los dispositivos, se explican los detalles de
operación necesarios para efectuar la integración de los componentes en los objetos
propiamente dichos. En el capítulo 5 se detalla el desarrollo de firmware del objeto IoT, sus
modos de operación y configuración, así como una serie de conceptos asociados a la
medición. En el capítulo 6 se detalla la selección de herramientas de software y de red
necesarias para la conexión y la elaboración de las aplicaciones cliente (front-end) y
servidor (back-end) haciendo énfasis en el uso de Websocket como método de
comunicación en el nivel de aplicación, igualmente se detallan diferentes pruebas del
sistema completo efectuadas usando diferentes servicios en la nube. En el capítulo 7 se
explica el uso de las etiquetas QR como método para establecer el vínculo entre los objetos
IoT y su identidad virtual. Finalmente se exponen las conclusiones del presente trabajo y
las consideraciones a futuro en el capítulo 8 y un manual de operación de los dispositivos y
las interfaces en el capítulo 9.

1
 II. PLANTEAMIENTO DEL PROBLEMA.

En la actualidad el denominado Internet de las cosas aún se encuentra en un proceso de

estructuración, donde apenas existen algunas primeras soluciones con algunas aplicaciones
a nivel comercial, esto debido a los múltiples desafíos que se deben afrontar a fin de hacer
que la IoT sea comercialmente viable, segura, eficiente, y atractiva para los de diferentes
actores involucrados en el mercado de los sistemas de información y comunicación
(Compañías de electrónica, proveedores de servicios de Internet, empresas dedicadas a la
infraestructura de los servicios públicos, entre otros).

Se desarrollará una aplicación orientada al “Internet de las cosas” donde se pueda observar
el consumo de recursos de energía eléctrica y agua potable en un ambiente doméstico con
cinco dispositivos previamente instalados, tres para terminales eléctricas (monofásicas) y
dos para medir el consumo de agua de un grifo de uso domestico. La observación de estos
datos se puede efectuar interactuando con los dispositivos a través de un dispositivo móvil
inteligente conectado a Internet. Con este ejercicio se espera poder mostrar los diferentes
actores que intervienen en una arquitectura de Internet de las cosas así como tratar con
soluciones particulares para cada una de las características del sistema.

III. ANTECEDENTES

En 1990 El ingeniero informático Estadounidense Mark Weiser del grupo de investigación

del Computer Science Laboratory de Xerox PARC publicó un artículo titulado “The
Computer for the Twenty-First Century” [1] en el cual sentó las bases de lo que hoy se
denomina “computación ubicua”. En este describe el estado del arte de la computación al
final del siglo XX, indicando que el uso de computadores crea una ruptura con el entorno
pues estas exigen un conocimiento técnico distinto al propósito para el cual fueron
diseñadas, además de ser costosas y requerir de un espacio donde ser ubicadas y
manipuladas. Haciendo un paralelo de la conversión de la escritura en una tecnología
ubicua (que se encuentra inmersa en el ambiente humano y con la cual se interactúa sin ser
conscientes de ello) argumenta que las computadoras personales de su momento sólo son
un paso para que la computación se introduzca completamente en el ambiente humano.
Considera que se ha de pasar del procesamiento y análisis centralizados en un sólo
dispositivo, al desarrollo de sistemas interactivos y multimedia (múltiples sensores de
entrada y sistemas de salida) que conllevarán a la “desaparición del dispositivo” en el
sentido de que se reemplazará por pequeños sistemas que estarán acoplados a los elementos

2
del ambiente con los cuales se interactúa de forma natural. Weiser esboza la necesidad de
que una vez estos dispositivos estén presentes en el ambiente estos sean capaces de
comunicarse a través de redes ubicuas de dispositivos lográndose una integración a nivel de
hardware, de software y de red en lo que denomina “virtualidad incorporada” en
contraposición al concepto de “realidad virtual” donde el humano se sumerge en un
ambiente ficticio creado a partir de un programa de computador.

En el año 2001 Sun Microsystems inició el desarrollo del proyecto JXTA (acrónimo de
Juxtapose), el cual tenía como uno de sus propósitos “especificar un conjunto estándar de
protocolos omnipresentes de tipo peer-to-peer (P2P - de igual a igual) como base de la
futura Web de las Cosas” [2] Este se centra en la elaboración de una plataforma de código
abierto capaz de funcionar en una amplia gama de dispositivos, dado el inicio de la
masificación de estos (teléfonos móviles, beepers, PDA, computadoras portátiles, sensores
de telemetría y sistemas de seguimiento, entre otros). El proyecto se fija en la necesidad de
crear una red virtual (independiente de la ubicación de los objetos o de la red de transporte)
para el adecuado intercambio de información entre dispositivos con características de
máquina dispares mediante el uso de documentos XML. Su enfoque de comunicación P2P
pugnaba por una arquitectura sencilla donde los servidores centralizados y los DNS son
reemplazados por comunicaciones entre nodos con información redundante. Oracle
adquirió Sun Microsystems en 2010 y en Noviembre de ese mismo año anunció que no
continuaría el apoyo a los proyectos JXTA.

En el año 2006 se usa el término “Internet of Things (IoT)” para hacer referencia a los
intentos de efectuar de forma práctica comunicación del tipo M2M (máquina a máquina)
En ese mismo año, Echelon Corporation publicó un artículo titulado Deploying the
“Internet of Things” [3] en el cual indica los desafíos que se deben superar a fin de obtener
una IoT operativa, entre éstos se encuentran la eficiencia energética, los costos y las
demoras en la implementación, los modelos de negocio basados en beneficios de largo
plazo, los tiempos de vida de los proyectos y de las implementaciones que deben rondar
sobre los 10 años, la solución de los problemas de conexión a red ya que la IoT aún es poco
atractiva para los proveedores de servicios de red (ISP), los problemas de seguridad
consistentes en la difícil implementación en los dispositivos embebidos de los actuales
protocolos de seguridad, la interoperabilidad para dar a dispositivos diversos la capacidad
de entender y procesar información entre ellos. El proyecto CASAGRAS (Acción de apoyo
y coordinación de actividades relacionadas con la RFID y la normalización) dio inicio en el
año 2008 y en 2010 presentó un informe de gran detalle sobre los avances en la
estructuración de una IoT el cual se centra en los sistemas de RFID como mecanismo
central de comunicación e interacción [4].

3
 IV. OBJETIVO GENERAL.

Diseñar e implementar un sistema de medición de consumo de energía eléctrica y agua

potable remoto con interacción al usuario basado en el concepto "Internet de las cosas"

V. OBJETIVOS ESPECÍFICOS.

- Establecer un método de medición de energía eléctrica y agua potable que permita

la lectura de los datos a fin de ser capturados y enviados por un dispositivo de
comunicación inalámbrico.

- Establecer el método de comunicación entre los dispositivos sensores y el colector

de datos.

- Diseñar e implementar un sistema de medición de agua potable.

- Diseñar e implementar un sistema de medición de energía eléctrica.

- Diseñar e implementar una plataforma de software de comunicación y

almacenamiento de datos dentro del marco del Internet de las cosas.

- Diseñar e implementar una plataforma de software de interfaz al usuario dentro del

marco del Internet de las cosas.

4
 VI. JUSTIFICACIÓN.

El estado actual de la electrónica y la informática ha alcanzado una gran capacidad en

cuanto a la recepción y análisis de datos gracias a la conectividad de Internet y el uso
masivo de redes inalámbricas, así como la aparición de dispositivos móviles inteligentes
capaces de efectuar procesos computacionales complejos. El denominado “Internet de las
cosas” es un concepto nacido dentro de esta tendencia. La idea general que hay detrás de
IoT postula que “cualquier objeto convenientemente etiquetado, podrá ser capaz de
comunicarse con otros objetos y sistemas, ya sea utilizando Internet, redes privadas u otros
mecanismos de comunicación” [5]. Este enfoque es mucho más amplio que el actual
concepto de domótica, pues implica la posibilidad de tener, de una parte, objetos con algún
tipo de inteligencia indistintamente si son parte del hogar o de otros entornos, y por el otro
una interacción mucho más abierta, donde se puede intercambiar información más allá de
las funciones hasta ahora previstas para el hogar. La conectividad se logra mediante
sistemas de redes inteligentes o similares que se caracterizan por ser aplicaciones de la
denominada web semántica, igualmente se hace uso de los conceptos de los sistemas
ubicuos, tales como tareas específicas, reconocimiento del entorno, proactividad, entre
otros.

Aunque en la actualidad existen algunos desarrollos tendientes a mejorar las condiciones

del uso de recursos dentro y fuera del hogar, dichas herramientas poseen un impacto menor
al esperado en el ahorro y la concientización del uso de los mismos, como en el caso de la
energía eléctrica y el agua potable. Esto se debe principalmente a que la introducción de
instrumentos de medición y control al interior de viviendas y otros entornos se enfoca
principalmente a conseguir espacios más confortables con un menor esfuerzo por parte del
usuario. Por otra parte, las aplicaciones de domótica se dirigen principalmente al hogar, que
es un entorno donde la interacción suele ser con unas pocas personas: Encender
automáticamente una luz o conocer el estado de temperatura y humedad de un recinto están
restringidos a los dueños de la vivienda. Al tratar de aplicar estos elementos de confort a
sitios con una presencia de personas mucho mayor (espacios públicos) la interacción se
vuelve muy compleja; en estos casos resulta más atractivo tener aplicaciones en la nube
desde las cuales efectuar dichas interacciones.

El diseño de entornos orientados al Internet de las cosas pretende abrir nuevas

posibilidades de interacción con las personas y entre los dispositivos para mejorar el
confort, pero también para hacer un uso más eficiente de los recursos, preocupación que
tiene una gran importancia en la actualidad dados fenómenos como el cambio climático y la
creciente escasez de recursos naturales. Introduciendo algún grado de inteligencia a
elementos cotidianos como un grifo de agua, se puede lograr un mayor control en cuanto al
consumo del recurso así como una pronta detección de problemas como fugas, que suelen
verse reflejados en altos costos en las facturas de consumo amén del evidente desperdicio
de agua.

5
 VII. ALCANCES Y LIMITACIONES.

A fin de mostrar la efectividad de la propuesta realizada se utilizaron un total de cinco

dispositivos repartidos de la siguiente manera: Tres dispositivos de medición de consumo
de energía eléctrica monofásica enviando estos datos de forma inalámbrica. Igualmente se
utilizaron dos dispositivos de medición de consumo de agua para aplicación residencial
capaces de enviar estos datos de forma inalámbrica. Mediante un dispositivo móvil
inteligente tipo Smartphone, tableta o PC es posible la interacción con los objetos y el
vínculo inicial se establece mediante la lectura de etiquetas QR. Finalmente, un servidor
web con capacidad de interpretar un protocolo a nivel de aplicación de las Cosas sobre IP
versión 4 (Websocket) soporta la estructura de datos.

No se han establecido nuevos protocolos o arquitecturas adicionales a las que se han estado
experimentando en los últimos años, en cambio se amoldaron las características de estas
arquitecturas en los circuitos que se encuentran actualmente a disposición como lo son los
dispositivos de comunicación inalámbricos embebidos así como las redes 810.11 Wi-Fi que
están en su momento de mayor difusión. Al hacer uso de los elementos disponibles
actualmente se ha logrado una implementación que muestra los conceptos principales de
una IoT. Para una implementación completa y óptima, sin embargo, es necesario la
modificación o el desarrollo de nuevos protocolos y sistemas de conexión en red para los
objetos. Igualmente, no se efectúa un control estricto sobre el consumo de energía eléctrica
o el de agua potable, simplemente se efectúan las mediciones a fin de que sean los usuarios
quienes tomen las acciones pertinentes de control y optimización.

La plataforma web propuesta es sólo demostrativa de los requerimientos tecnológicos de

una IoT funcional, por ende, se han omitido estructuras necesarias para mejorar la
seguridad de los datos y de los elementos de la red como el servidor, la base de datos, el
encriptamiento de paquetes, entre otros. Existen igualmente limitaciones en el tamaño y el
consumo de potencia de los dispositivos ya que, aunque se ha pretendido hacer un diseño lo
más pequeño posible, la selección de componentes ha dependido igualmente del costo,
tratando de usar módulos de bajo valor para demostrar su usabilidad en el entorno de una
IoT.

6
 1. INTERNET DE LAS COSAS

El Internet de las Cosas es un concepto que hace referencia a la interconexión de objetos

cotidianos en una red, “los objetos adquieren una identidad propia, detectando el entorno
en el que se encuentran e intercambiando información” [6]. Dispositivos y personas están
conectados y pueden comunicarse entre sí en lo que se ha denominado un entorno ubicuo.
Puede definirse como una infraestructura de red global dinámica con capacidades auto
configurables basadas en estándares y protocolos de comunicación donde los “objetos”
físicos y virtuales llevan asociados una identidad así como atributos físicos y
personalidades virtuales que se integran perfectamente en la red de información.

IoT nace como una evolución de la tecnología actual de Internet y la rápida masificación de
dispositivos inteligentes. A diferencia de otros procesos tecnológicos, este no es
consecuencia de una teoría científica sino más bien de una sinergia entre conceptos de
carácter comercial, experimental y técnico, siendo su principal impulsor el desarrollo de las
etiquetas RFID. IoT es la forma de describir dos esquemas estrechamente relacionados.
Uno es la “Internet de la información de productos” [7] el cual se centra en el fácil acceso a
través de la web de información útil sobre un producto (fecha de fabricación, caducidad,
detalles técnicos de fabricación, distribución al consumidor, etc.) en este caso los objetos se
comportan como una fuente de información cuyo contenido no depende de ellos de forma
directa pues los datos son manipulados y permanecen en la web. El otro esquema es el
“Internet de los sensores y actuadores” en el cual se busca tener no sólo la posibilidad de
conocer información de un entorno, sino la capacidad de interactuar con él ya sea de forma
local o remota mediante el uso de redes; en este caso la información proviene de las cosas
propiamente dichas y se hace uso de diversos recursos tecnológicos a fin de logar la
comunicación e interacción [8]. De forma general se podría hablar entonces de Internet de
las cosas como la “Internet de información de objetos” sean estos artículos de consumo o
redes de sensores-actuadores como los que se encuentran en los ambientes domóticos
actuales.

La gran mayoría de las conexiones a Internet se establecen entre los dispositivos utilizados
directamente por los seres humanos, tales como computadoras y teléfonos móviles, la
interacción principal es entre personas. La tendencia actual es que también los objetos se
puedan conectar a la red. Las cosas, comprendidas estas como elementos cotidianos a los
cuales se les ha añadido algún grado de inteligencia, tienen cada vez mayor capacidad para
intercambiar información por sí mismas y entre ellas. Se estima que en algún momento la
cantidad de "cosas" conectadas a Internet será mucho más grande que el número de
"personas" y los seres humanos nos convertiremos en la minoría de los generadores y
receptores de tráfico [33]. Anthony Furness del proyecto CASAGRAS nos da una

7
propuesta sobre la arquitectura básica del Internet de de las cosas el cual se aprecia en la
Figura 1 [34].

Figura 1. Esquema básico de un Internet de las cosas (tomado de los documentos de trabajo del proyecto
CASAGRAS y traducido al español).

1.1. COMPONENTES DE UNA IOT.

El esquema general del internet de las cosas consiste en un conjunto que posee los
siguientes componentes:

 Cosas: Son los distintos objetos que poseen alguna inteligencia, estos se deben
considerar como los emisores-receptores de la información. Según sea su nivel de
inteligencia pueden comportarse como “productos” o como sistemas de “sensores-
actuadores”. Idealmente todas las cosas deben poseer una etiqueta que les
identifique de forma única.

 Identificadores: Son las entradas a la información contenida en una cosa, estas

pueden ser soportes pasivos, como códigos QR o códigos de barras, o poseer
capacidad de conexión como las etiquetas RFID, también podrían considerarse
como etiquetas otras formas de identificación de dispositivos como solicitudes o ID
de conexión a través de una red de dispositivos, en estos casos la identificación se
da por la ubicación (proximidad) entre los objetos.

 Zona de interfaz física: Corresponde a la ubicación física real de los dispositivos

(cosas) que poseen algún grado de inteligencia e interacción con el entorno y son

8
 capaces de comunicarse a través de una red, dicha zona de interfaz física cumple
con las condiciones generales de un sistema ubicuo.

 Red de cosas: Los distintos objetos “inteligentes” pueden comunicarse al exterior o

entre ellos a través de una red. Dada la gran cantidad de tecnologías de
comunicación existentes, que en muchos casos son incompatibles entre sí, una red
de cosas debe garantizar ante todo la posibilidad de conectar una cosa con otra a
través de una pasarela adecuada.

 Pasarelas: Son los dispositivos encargados de conectar la red de cosas con Internet.
Como en el caso de las pasarelas Web, el hardware también podría ejecutar tareas
de seguimiento y control e incluso comportarse como servidor local a fin de
efectuar una gestión de la información.

 Internet: Se convierte en el medio a través del cual se establece interacción remota

entre cosas así como el ente que almacena y gestiona la información. IoT puede
hacer uso, o poseer recursos paralelos a los de la Internet de las personas:
Servidores Web, DNS, protocolos específicos para la localización y la
comunicación, etc. En este aspecto el desarrollo apenas se encuentra en una fase
experimental y la estandarización de conceptos y métodos se encuentra incompleta
o aun sin establecer.

1.2. MODOS DE COMUNICACIÓN E INTERACCIÓN.

Existen dos modos básicos de comunicación en Internet de las cosas: cosa-persona y cosa-
cosa [5].

Cosa – persona: Las comunicaciones de este tipo abarcan una serie tecnologías y
aplicaciones en las cuales las personas interactúan con cosas y viceversa. Las más comunes
son el acceso a distancia, control remoto y monitorización. También existen cosas que
informan a las personas de cambios en su estado, datos recogidos, etc.

Cosa – Cosa: Abarca tecnologías y aplicaciones en donde objetos interactúan sin que
ningún humano haya iniciado la interacción ni sea receptor o intermediario. Los objetos
pueden controlar otros objetos, tomar medidas correctivas y realizar notificaciones a las
personas según sea necesario (Suelen denominarse aplicaciones M2M - Machine-to-
Machine).

En este contexto, una cosa se considera “Inteligente” si es capaz de entregar algún tipo de
información a otra. Diversos niveles de inteligencia se pueden inferir a partir de esta

9
definición, siendo la interacción más elemental aquella entre una cosa T cuyo recurso
inteligente es una etiqueta que puede ser leída por la cosa S, quien a su vez es capaz de usar
los datos contenidos en la etiqueta para obtener una información adicional de contexto, la
cual se hace disponible a través de una red. Como se observa en la figura 2, S tiene una
inteligencia “superior” a T ya que este es capaz de leer códigos (se denomina agente de
lectura) e interactúa con una red. A este nivel pertenecen la mayoría de los dispositivos
“Smart” disponibles comercialmente como teléfonos inteligentes, Tablets y demás PDA.

Figura 2. Interacción básica entre un objeto etiquetado (T) y un dispositivo inteligente (S) este es el tipo de
esquema utilizado en la Internet de información de productos.

Este tipo de interacción es el que se presenta sobre todo en la llamada “Internet de la

información de productos” en un supermercado para poder conocer información adicional
de un producto, en un cinema para poder obtener información sobre la cartelera de películas
e incluso hacer reservaciones. Dicha interacción también es casi siempre de tipo cosa-
persona.

Otra interacción básica es la que se establece entre una cosa T, la cual posee una de
etiqueta de identificación y adicionalmente es capaz de capturar algún tipo de información
del entorno y almacenar este contenido. En este caso S es capaz de acceder a la información
mediante la identificación de la etiqueta la cual se usa para establecer una comunicación
con T. En este caso tanto S como T tienen la capacidad de acceder a una red a través de
pasarelas. G es la pasarela entre T y la web, la comunicación se efectúa a través de internet
haciendo uso de los recursos de esta. Como se observa en la figura 2, para esta interacción
se involucran múltiples elementos que hacen más compleja la comunicación y esbozan de
forma general las partes componentes de una IoT.

10
Figura 3. Esquema de interacción de un Internet de las cosas con dispositivos incluyen sensores (T)
conectados a Internet a través de pasarelas (G).

1.2.1. CONEXIÓN LOCAL MÁQUINA A MÁQUINA (M2M).

Una de las críticas válidas que se hace a los esquemas del internet de las cosas es que
requieren del uso de una gran cantidad de componentes a fin de lograr una interacción tanto
local como remota; sin embargo en muchos casos la interactividad entre cosas se da
únicamente en entornos locales en los cuales los objetos se encuentran muy cerca entre sí y
la información que se comparte entre ellos sólo tiene importancia y validez en breves
intercambios que se suceden entre estos. Es por esta razón que el establecimiento de las
interacciones del tipo M2M locales revisten una gran importancia al momento de efectuar
el diseño de una red de objetos, así mismo representan un desafío ya que la gran mayoría de
dispositivos que se encuentran actualmente en el mercado (PDA, Tablet, PC portátil, entre
otros) aun cuando incluyen diversos sistemas de comunicación (infrarrojos, Bluethoot, Wi-
fi, entre otros) que no permiten de una forma fácil el intercambio entre métodos de
comunicación para una misma interacción.
En esta interacción dos dispositivos “T” en la misma zona de interfaz física son capaces de
detectar uno la presencia del otro, autentificarse entre sí y establecer un intercambio de
información. Según los requerimientos esta información podría registrarse externamente en
Internet a través de las pasarelas correspondientes (Figura 4).

11
 Figura 4. Esquema general de una interacción del tipo M2M local.

1.2.2. MODELO DE CAPAS.

No existe un modelo de capas estándar para la Internet de las cosas, sin embargo, los
esquemas elaborados se han preocupado por el funcionamiento multiplataforma dada la
diversidad de componentes y de protocolos existentes para las diferentes conexiones; de esa
manera se suele seguir la estructura de capas existente para las conexiones a Internet. En
general se diseña una capa de coordinación adicional para procesar la estructura de
paquetes de diferentes sistemas de aplicación y volverlos a ensamblar en una estructura que
puede ser identificada y procesada por el sistema de aplicación de cada objeto [33]. Por
supuesto, si se completan y unifican las normas de la Internet de las cosas entonces los
sistemas que se basen en estas normas no tendrán ningún problema en la interoperabilidad.
Por lo pronto existen incompatibilidades entre esquemas ya comercializados como el EPC
Global (etiquetas RFID). Nuevamente el proyecto CASAGRAS nos brinda un esquema
general de capas para Internet de de las cosas el cual se aprecia en la Figura 5. [34]

Figura 5. Modelo general de capas para el Internet de las Cosas (tomado de los documentos de trabajo del
proyecto CASAGRAS y traducido al español).

12
 2. MÉTODO DE MEDICIÓN DE CONSUMO DE AGUA.

2.1. CLASIFICACIÓN GENERAL DE LOS MEDIDORES DE FLUJO.

Los elementos primarios de medición de flujo que se usan en la industria, y que se han
tomado como referente para la selección se clasifican según su principio de funcionamiento
como se muestra en la figura 1. [9]

Figura 6. Clasificación de los medidores de flujo según su principio de funcionamiento (Tomado del libro
Instrumentación industrial Séptima edición, Editorial Alfaomega-Marcombo y adaptado al presente trabajo)
las flechas verdes indican las características del medidor seleccionado.

La diversidad de técnicas y dispositivos de medición se debe a la diversidad de fluidos que

son objeto de las mediciones, así como de sus características físicas y los volúmenes de
caudal. Análisis detallados de cada uno de estos tipos se encuentran en [9], [10] y [11]. Para
este trabajo se ha efectuado un proceso de selección teniendo en cuenta una serie de
criterios que se describen en los apartados siguientes, de donde se ha concluido que por las
características generales el tipo de sensor más adecuado es un sensor de flujo volumétrico
rotativo con sensor de efecto hall.

13
 2.2. CRITERIOS PARA LA SELECCIÓN.

Los criterios que se han tenido en cuenta para la selección de dispositivo de medición son
los siguientes:

Tipo de fluido a medir: El tipo de fluido a medir es agua potable de uso doméstico. El agua
es el fluido a monitorear por antonomasia dada su importancia en diversidad de procesos y
brinda además un amplio abanico de posibilidades para efectuar la medición. De este modo
son descartables aquellos medidores especializados (y muchos de ellos de alto costo)
pensados para fluidos de alta viscosidad, que contengan una importante cantidad de
residuos o generen un elevado nivel de corrosión.

Rango de caudales a cubrir: Dado que se busca medir el flujo de agua pasante en los
denominados aparatos consumidores de agua (sanitarios, lavamanos, duchas, lavaderos,
entre otros) en este trabajo no es relevante conocer el flujo total por unidad (vivienda,
establecimiento grupo de establecimientos) que normalmente si es primordial para
determinar el tipo de contador que se instalará por parte del proveedor del servicio [12],
sino centrarse en el consumo máximo de estos aparatos.

En la tabla 1 se muestran los valores de consumo de dispositivos de agua domésticos, el

mayor valor de flujo instantáneo para estos no supera 1.25 Litros/Segundo siendo los
últimos casos poco comunes. Se considera el valor máximo de flujo cercano a 250 mL/S.
De este modo es factible efectuar medición del consumo de todos los dispositivos marcados
en color verde en la tabla.

Precisión requerida: La precisión de la medición no es un factor crítico para la elaboración

de este trabajo. Es deseable que el valor de la medición se encuentre dentro de una
precisión aceptable, típicamente de un error no mayor al 5%. Instrumentos de alta
precisión por lo general tienen un gran tamaño y alto costo, por lo que precisiones
superiores implican una desviación en el propósito principal de este proyecto.

Repetitividad requerida: Los aparatos consumidores de agua de uso casero suelen tener
diversos grados de repetitividad en cuanto su uso, los más comunes (lavamanos, inodoros,
grifos) por lo general tienen una repetición de uso de media a alta, por lo tanto la
repetitividad de las mediciones debe oscilar en un rango aceptable de error (no mayor al
5%).

Ambiente en que se realizará la medición: El entorno corresponde a ubicaciones de

carácter doméstico (mobiliarios propios de baños, cocinas, entre otros) los cuales tienen
niveles de humedad y temperatura estables. Se descartan medidores de alto costo que
soportan grandes variaciones de temperatura así como fuerte exposición a humedad y
corrosión en el ambiente.
14
Tabla 7.Caudales instantáneos típicos por aparato en litros/segundo según la Norma Española Canaria 119 de
2007. (Tomada del documento Criterios para definir el diámetro de la acometida y el medidor a instalar en
urbanizaciones y edificios, de EPM [12])
Caudal (L/s)
Caudal (L/s)
Caudal aparato Agua
Agua Fría
Caliente
Urinarios con cisterna (c/u) (Urinarios con tanque) 0,04
Lavamanos 0,05 0,03
Lavabo 0,1 0,065
Bidé (lavamanos) 0,1
Inodoro con cisterna (Inodoros con tanque) 0,1
Urinarios con grifo temporizado 0,15
Lava vajillas doméstico 0,15
Grifo aislado 0,15
Ducha 0,2 0,1
Bañera L< 1,40 m 0,2 0,2
Fregadero doméstico 0,2 0,1
Lavadero 0,2 0,1
Lavadora doméstica 0,2 0,15
Grifo garaje 0,2
Vertedero 0,2
Lavavajillas industrial (20 servicios) 0,25 0,2
Bañera L>= 1,40 m 0,3 0,15
Fregadero no doméstico 0,3 0,2
Lavadora industrial (8 Kq) 0,6 0,4
Inodoro con fluxómetro 1,25

Tipo de salida eléctrica requerida: La salida necesaria para efectuar la medición puede ser
tan sencilla como un valor analógico correspondiente al flujo pasante, o un tren de pulsos
equivalente a un indicador de velocidad o flujo pasante.

Linealidad y velocidad de respuesta: Una alta linealidad no es crítica para el proyecto. Es

deseable que el porcentaje de desviación sea pequeño dentro del los rangos de flujo más
comunes de consumo y que la velocidad de respuesta esté por debajo que los intervalos de
medición que se han establecido que no serán menores de 1 segundo.

Tipo de caudal: La medición se efectuará en una tubería cerrada en la cual todo el flujo se
halla confinado. Se descartan las técnicas y dispositivos propios para la medición de flujo
en caudales abiertos (vertedero en canal, rotámetros de área variable, entre otros).

Costo de la instalación: El dispositivo debe ser muy sencillo de instalar y mantener, y no

debería generar complicaciones dentro del sistema de tuberías. Se ha dado prelación a la
relación sencillez-costo del dispositivo donde los sistemas de medición no invasivos
(sensores magnéticos y ultrasónicos) no cumplen este requerimiento.

Accesibilidad y costo del dispositivo: El instrumento de medición seleccionado debe tener

un costo que se ajuste al presupuesto del actual proyecto (bajo costo) igualmente debe ser

15
de fácil adquisición, por lo que se deben descartar medidores de alta gama o demasiado
novedosos y de escasa disponibilidad en el mercado.

Existen otros criterios de selección como el costo del mantenimiento, de la mano de obra
calificada necesaria para mantenimiento e instalación, perdidas de carga, entre otros, que
revisten una menor importancia dada la naturaleza y extensión de esta propuesta.

Tabla 2. Características y comparación de los instrumentos medidores de caudal (Tomado del libro
Instrumentación industrial Séptima edición, Editorial Alfaomega-Marcombo y adaptado al presente trabajo).
El tipo seleccionado en verde corresponde al tipo de medidor que se utilizará. *dP hace referencia a la
diferencia de presión. **La pérdida de carga se puede medir en metros cúbicos de área (m) o en bares (b).
Relación Precisión Presión Pérdida
Temperatura Costo
Tipo de en toda Escala Máxima de Servicio materiales Ventajas desventajas
máxima °C relativo
Caudal la escala (bar) carga**
No Alta dP, fluidos
Placa 3:1 1-2 % 400 500 20 m Líq/Vapor/Gas Metal/plástico Bajo Simple, económico
lineal limpios
0.9-1.5 No Alta dP, fluidos
Tobera 3:1 400 500 16 m Líq/Vapor/Gas Metal/plástico Medio Simple, preciso
% lineal limpios, caro
Alta dP, fluidos
No Muy
Tubo Ventury 3:1 0.75 % 400 500 4m Líq/Vapor/Gas Metal/plástico Preciso, poca dP* limpios, muy
lineal alto
caro
No
Tuvo Pitot 3:1 1.5-4 % 400 500 - Líq/Vapor/Gas Metal/plástico Bajo Simple, económico Poca precisión
lineal
Tubo No
3:1 1% 400 500 - Líq/Vapor/Gas Metal/plástico Bajo Simple, económico Poca precisión
Annubar lineal
Golpe de ariete
Rotámetro 10:1 1-2 % Lineal 400 250 5m Líq/Vapor/Gas Vidrio/Cerámica Bajo Mayor precisión
puede dañarlo
Voluminoso,
Vertedero 3:1 1-2 % Especial Atmósfera 60 - Líquidos Metal Bajo coste medio
caro
Difícil de
Preciso, margen
Turbina 15:1 0.3 % Lineal 200 250 0.7 b Líquidos/Gas Metal Alto calibrar, fluidos
amplio
limpios
Caro, difícil de
cualquier líquido, calibrar,
Sónico 20:1 2% Lineal 100 250 nula Líquidos Metal/plástico Alto
poca dP sensible a la
densidad
Placa de No
10:1 1% 100 400 0.5 b Líquidos Metal Medio Fluidos viscosos Poca capacidad
impacto lineal
Caro, sólo para
Magnético 100:1 0.5-1 % Lineal 20-200 150 nula Líquidos Teflón/Vidrio Alto poca dP líquidos
conductores
Disco
5:1 1-2 % Lineal 10-150 120 0.3 m Líquidos Metal Bajo barato Par pequeño
oscilante
Pistón 0.2-0.5 Líquidos Viscosos,
5:1 Lineal 25 150 10 b Líquidos Metal Medio Alta dP
oscilante % corrosivos
Pistón Voluminoso,
5:1 0,20% Lineal 25 100 0.2 m Líquidos Metal Alto Preciso
alternativo caro, alta dP
Poca precisión
Cicloidal 10:1 1% Lineal 100 150 0.3 b Líquidos/Gas Metal/plástico Medio poca dP en caudales
bajos
Margen
Birrotor 5:1 0.2% Lineal 100 60-200 0,4 b Líquidos Metal/plástico Medio Preciso
pequeño
No afecta la
Oval 10:1 0.5% Lineal 100 180 1b Líquidos Metal/plástico Medio Alta dP
viscosidad
Paredes Voluminoso,
10:1 0.3% Lineal - - - Gas Metal/plástico Medio Preciso
deformables alta dP
margen amplio,
Torbellino 100:1 0.2% Lineal 50 100 0.4 b Líquidos/Gas Metal/plástico Medio Caro
poca dP
soprota Insensible a
Vórtex 10:1 1% Lineal 50 400 - Líquidos/Gas Metal/plástico Medio
vibraciones bajo caudal
Caro, solo
Ideal para
Oscilante 10:1 0.5% Lineal 100 65 - Líquidos/Gas Metal/plástico Medio gases, bajo
propano/butano
caudal
Caro, Margen
Térmico 10:1 1% Lineal 100 65 5m Líquidos/Gas Metal/plástico Alto poca dP
pequeño
Caro, Margen
Axial 5:1 1% Lineal 100 120 0.2 b Líquidos/Gas Metal/plástico Alto poca dP
pequeño

16
 2.3. SELECCIÓN DEL TIPO DE DISPOSITIVO.

Del listado global de sistemas de medición disponibles se descartan aquellos que no

cumplen con los requerimientos mínimos de interés para el proyecto. En la tabla 2 se
muestra un resumen de las características según los tipos de medidor en donde se ha
resaltado a los medidores de flujo volumétrico de tipo cicloidal (o de turbina), pues estos
son los más comunes dentro de los sistemas de medición de consumo de agua de uso
doméstico y son los que en general tienen las características más adecuadas para las
mediciones de bajos caudales de agua potable en instalaciones de tipo residencial.

Una de las principales desventajas que poseen los medidores cicloidales es su poca
precisión ante bajos caudales, esto se solventa diseñando un medidor apto para rangos de
caudal más bien pequeños (por debajo de la relación 10:1) por lo que se presenta un
compromiso entre el caudal máximo y la precisión mínima. Dado que los valores máximos
de caudal son relativamente bajos, un sensor para diámetros de tuberías pequeños posee
unas características suficientemente aceptables en bajos caudales.

2.4. MEDIDOR DE FLUJO VOLUMÉTRICO.

La mayoría de los medidores de flujo determinan el volumen que pasa a través de una
tubería por unidad de tiempo, a este tipo de medidores se les denomina medidores
de flujo volumétrico [10]. Entre ellos encontramos: Medidor tipo turbina, medidor
magnético y medidor de área variable. De estos tipos detallamos el de tipo turbina.

2.4.1. MEDIDOR TIPO TURBINA.

Los medidores cicloidales (también llamados de turbina o de paletas deslizantes) consisten

en un rotor que gira al paso del fluido con una velocidad directamente proporcional al
caudal [9]. La velocidad del fluido ejerce una fuerza de arrastre en el rotor generando una
diferencia de presiones debida al cambio de área entre el rotor y el cono posterior, quien
ejerce una fuerza igual y opuesta. La medición del caudal en este tipo de aparatos se logra
con base en la proporcionalidad que existe entre el número de revoluciones o vueltas que
dan las aspas del dispositivo, y la velocidad del flujo que es transportada a través del
conducto. La velocidad que adquieren las aspas al contacto con el flujo, se transmite a un
sistema de relojería o se transduce en pulsos o niveles eléctricos, y de este modo se obtiene
información referente a volúmenes y registro del caudal. En la figura 2 se describe la

17
operación general de este tipo de medidor. Los transductores que típicamente se aplican
para obtener una señal eléctrica son:

De reluctancia: La velocidad viene determinada por el paso de las palas de la turbina a

través del campo magnético creado por un imán permanente montado en una bobina
captadora exterior. El paso de cada pala varía la reluctancia del circuito magnético. Esta
variación cambia el flujo induciendo en la bobina captadora una corriente alterna que es
proporcional al giro de la turbina.

Inductivo: El rotor lleva incorporado un imán permanente y el campo magnético giratorio

que se origina induce una corriente alterna en la bobina captadora exterior.

De efecto hall: El rotor lleva incorporado un imán permanente que se acerca a un sensor de
estado sólido de efecto hall, el aumento de la intensidad del campo magnético por la
cercanía del imán genera un pulso en el sensor de modo que la cantidad de pulsos
generados en un intervalo de tiempo son proporcionales al flujo a medir.

El instrumento debe instalarse de tal modo que no se vacíe cuando cesa el caudal ya que el
choque del agua a alta velocidad contra el medidor vacío causa deterioro. Normalmente, la
frecuencia que genera el rotor de turbina es proporcional al caudal siendo del orden de 250
a 1200 ciclos por segundo para el caudal máximo. El número de impulsos por unidad de
caudal es constante. Entre las ventajas de este medidor se encuentra su baja incertidumbre
para fluidos de baja a media viscosidad, igualmente ofrece un buen rango de flujo y es
adecuado para un rango presiones diverso y temperaturas extremas altas y bajas
(dependiendo de los materiales de construcción), son fáciles de instalar, tienen poco peso y
tamaño en relación al diámetro de la tubería. La exactitud es elevada (del orden de ±0.3%
en la región de mayor linealidad). La menor incertidumbre se consigue con un flujo
totalmente desarrollado (laminar), instalando el instrumento en una tubería recta de
longitudes mínimas de 10 diámetros corriente arriba y 5 diámetros corriente abajo. Las
desventajas principales son la incompatibilidad con líquidos altamente viscosos, posibles
daños en caso de que se presente cavitación1 y la necesidad de equipo adicional (relojería o
electrónica) para obtener la medición.

2.4.2. FLUJO EN TUBERÍAS.

En la figura 3 se muestran algunos de los componentes básicos de un sistema de tuberías.

Los componentes incluyen tubos y accesorios usados para conectar a los primeros a fin de
formar el sistema deseado, los dispositivos de control de flujo (válvulas) y las bombas o
turbinas que agregan o retiran energía del fluido respectivamente. Si las trayectorias de
todas las partículas del fluido en un conducto son paralelas al eje del mismo y si las
velocidades de estas partículas son bajas y difieren muy poco en sus valores, se dice que el
flujo es laminar o viscoso. Cuando las trayectorias de las partículas que están fluyendo

1
Formación de cavidades llenas de vapor o de gas en el seno de un líquido en movimiento.

18
continuamente difieren una de otra, o cuando las trayectorias no son paralelas aleje de la
tubería el flujo es turbulento [9]. Para el flujo en tuberías, el parámetro adimensional más
importante es el número de Reynolds (Re), el cual se define como la relación de los efectos
inerciales y los efectos viscosos en el flujo, este permite conocer el régimen del fluido. El
flujo en una tubería es laminar si Re ≤ 2100, el flujo en una tubería es turbulento si Re
≥4000. Para números de Reynolds entre estos límites, el flujo puede cambiar entre
condiciones laminares o turbulentas de manera aparentemente aleatoria.

Figura 2. Dibujo de turbinas y diagrama de bloques de una turbina usada como sensor de flujo (Tomado del
libro Instrumentación y control en instalaciones de proceso, energía y servicios auxiliares y adaptado al
presente trabajo).

Figura 3. Elementos típicos que componen un sistema de tuberías.

19
 2.4.3. ERROR DE MEDICIÓN.

Los medidores de desplazamiento presentan resistencia a la fricción, la cual tiene

que ser vencida por el fluido circulante. Para caudales muy bajos, el fluido no tiene
energía cinética suficiente para hacer girar el rotor frente a esta fricción, que además
incluye la resistencia ofrecida por el mecanismo articulado del contador, por lo que el
fluido se desliza lentamente entre los componentes del medidor y la cámara, sin producir
movimiento del rotor, de forma que para estos caudales bajos, el error es grande y negativo.
Sin embargo, cuando el caudal aumenta este error negativo desaparece rápidamente,
ya que la energía cinética del fluido aumenta con el cuadrado de su velocidad. Una
condición cercana al equilibrio se alcanza cuando la fuerza directriz del fluido se equilibra
por las diversas fuerzas de resistencia, y esto se mantiene para el margen de
funcionamiento para un medidor bien diseñado, en la figura 4 se muestra la evolución del
error de un contador rotativo de acuerdo al caudal a medir. El error del medidor, E, se
define como:

𝑄𝑖𝑛𝑑𝑖𝑐𝑎𝑑𝑜 − 𝑄𝑟𝑒𝑎𝑙
𝐸= 100% (1)
𝑄𝑟𝑒𝑎𝑙

0,2
Error medida (%)

0,1

0
0 20 40 60 80 100
Porcentaje de Escala (%)

Figura 4. Curva del comportamiento típico del error de un medidor de paletas deslizantes.

2.5. SENSOR SELECCIONADO.

El sensor seleccionado para este proyecto es un medidor de flujo volumétrico de agua de

paletas deslizantes diseñado para una tubería de ½ pulgada y prestaciones domésticas. Este
se compone de una válvula de plástico, un rotor (parte giratoria), y un sensor de efecto Hall.
Cuando el agua fluye a través de las paletas del rotor, este comienza a girar con mayor o
menor velocidad dependiendo del caudal de líquido que fluye a través de él (figura 5).
20
Efecto hall: Descubiertoen1879, el efecto Hall, llamado así en honor al físico
estadounidense Edwin Herbert Hall, consiste en la aparición de un campo eléctrico en un
conductor cuando es atravesado por una corriente estando dentro de un campo magnético, a
este campo eléctrico se le llamo campo Hall. En la actualidad, dispositivos de estado sólido
aprovechan este principio para transducir señales físicas diversas en señales eléctricas
(sensores de proximidad, de corriente, detectores, entre otros).

2.5.1. CARACTERÍSTICAS TÉCNICAS DEL MEDIDOR.

Entre las características más importantes del medidor se tiene2:

• Modelo: SEN_0394
• Fabricante: Adafruit.
• Compacto, de fácil instalación.
• Enroscado hermético.
• Sensor de efecto Hall de alta calidad.
• Cumple con la norma RoHS.
• Voltaje de operación: 5 a 24V
• Máximo consumo de corriente: 15mA a 5V
• Caudal de trabajo: 1 a 30 Litros/Minuto (cubre todos los aparatos consumidores de agua
seleccionados en la tabla 1).
• Rango de temperatura de trabajo: -25 a 80ºC
• Rango de humedad de trabajo: 35%-80% HR
• Presión de agua máxima: 2.0 MPa
• Ciclo útil de salida: 50% +- 10%
• Tiempo de subida: 0.04 µs
• Tiempo de bajada: 0.18 µs
• Características del pulso: Frecuencia (Hz) = 7.5 * Caudal (L/min)
• Pulsos por litro: 450
• Durabilidad: mínimo 300.000 ciclos
• Conexión de 1/2" nominal, 0.75" de diámetro externo y rosca de 1/2"
• Tamaño: 63.5 mm x 35mm x 35mm.

2.5.2. CALIBRACION.

De acuerdo a las recomendaciones típicas de calibración [10], Los instrumentos y el equipo

que se requieren en general para la misma son:

•Medida volumétrica cuya capacidad debe ser igual o mayor al volumen colectado al flujo
máximo del medidor en un minuto.

2
Información tomada de la pagina del fabricante y traducida al español, disponible en
https://www.adafruit.com/products/828

21
•Sensores de temperatura instalados en la medida volumétrica y en la línea, lo más cercano
al medidor de flujo con resolución de 0.1 ºC o mejor.
•Incertidumbre en la medición de temperatura ± 0.2 ºC o mejor.
•Sensor de presión con una incertidumbre en la medición de ± 0.05 MPa o mejor.
•Cronómetro con resolución de 0.01 s.

En la práctica se consideraron la presión y temperatura homogéneas, dado que tienen una

variación insignificante y una incidencia menor en la calidad de la medición para este tipo
de sensor, por lo que únicamente se usaron medidas volumétricas en centilitros. Para la
medición de la señal obtenida se utilizó un microcontrolador quien detectó los cambios del
voltaje de la señal de tren de pulsos generada por el sensor de efecto hall, entregando el
número de pulsos por segundo (frecuencia). La hoja de datos del fabricante suministra una
curva con la frecuencia de pulsos de salida relacionada con el flujo de agua en unidades de
litros/hora. En la figura 6 se muestra el esquema del sistema elaborado para la calibración.

Figura 5. Vistas del sensor de flujo de efecto Hall seleccionado (tomado de la página del
fabricantehttps://www.adafruit.com/products/828).

Figura 6. Esquema del sistema diseñado para la calibración del sensor de flujo de agua.

22
Para realizar la calibración de forma correcta y confiable se han tenido en cuenta las
siguientes consideraciones:

•El medidor de flujo fue calibrado con el líquido a emplear (agua potable).
•El medidor de flujo fue instalado de acuerdo a las instrucciones del fabricante.
•Se evitaron vibraciones o pulsaciones que pudieran afectar el comportamiento del medidor
de flujo.
•El número de valores de flujo seleccionados está entre 2 y 5 flujos diferentes dentro del
alcance del medidor.

Los datos tomados se muestran en la tabla 3. El microcontrolador entrega el tiempo en

segundos y la cantidad de pulsos que se han utilizado en cada prueba para llenar la medida
volumétrica; a partir de estos tres datos es posible aproximar el valor de volumen por pulso
(que es constante en la región más lineal del sensor), el valor de la frecuencia en pulsos por
segundo y el flujo en diferentes unidades (centímetros cúbicos por segundo, litros por
minuto y litros por hora). En la figura 7 se comparan los datos de la curva característica del
fabricante contra los valores de la dispersión de las muestras efectuadas; se observa una
pequeña diferencia en buena parte de los valores donde la medida real está por encima del
valor esperado según los datos del fabricante para flujos entre los 250 L/h y 450 L/h por
hora.

Se determinó que la forma más conveniente para hacer la calibración de este sensor es
efectuar una linealización por tramos. Se han considerado cuatro regiones diferentes de
acuerdo a los datos obtenidos y donde a cada una corresponde a una recta del tipo 𝑦 =
𝐴𝑥 + 𝐵 Para los valores superiores e inferiores de la escala del sensor estas rectas
prácticamente coinciden con los datos del fabricante, en la parte intermedia de la medición
las rectas difieren ligeramente de la curva característica entregada.

Una vez efectuado el cálculo matemático de la regresión, las ecuaciones que corresponden
al comportamiento del sensor son las siguientes:

7.592𝑝 𝑠𝑖 0 ≤ 𝑝 < 27
8.6𝑝 − 27.2 𝑠𝑖 27 ≤ 𝑝 < 52
𝐹 𝑝 = 3.1𝑝 + 258,8 𝑠𝑖 52 ≤ 𝑝 < 62 (2)
7.111𝑝 + 10.11 𝑠𝑖 𝑝 ≥ 62

Donde 𝑝 es la cantidad de pulsos por segundo en Hertz (frecuencia) y 𝐹 es el flujo medido

en Litros/hora. En la figura 8 se muestra el resultado de la linealización respecto a la
dispersión medida.

23
Tabla 3.Datos tomados en el ejercicio de calibración, la mayor parte de los datos se tomó utilizando una
medida volumétrica de referencia de 2 litros modificando la velocidad del flujo regulando la misma con la
válvula (llave de lavaplatos).
Tiempo
Medida
de Total vol/pulso pulsos/seg
Volumétrica CC/seg litros/min litros/hora
llenado Pulsos (CC) (Hz)
(L)
(seg)
2 124 860 2,33 6,94 16,13 0,97 58,06
1 49 472 2,12 9,63 20,41 1,22 73,47
2 65 928 2,16 14,28 30,77 1,85 110,77
2 42 949 2,11 22,60 47,62 2,86 171,43
2 33 949 2,11 28,76 60,61 3,64 218,18
2 32 925 2,16 28,91 62,50 3,75 225,00
2 31 925 2,16 29,84 64,52 3,87 232,26
2 24 836 2,39 34,83 83,33 5,00 300,00
0,745 10 358 2,08 35,80 74,50 4,47 268,20
2 24 916 2,18 38,17 83,33 5,00 300,00
2 22 920 2,17 41,82 90,91 5,45 327,27
2 21 922 2,17 43,90 95,24 5,71 342,86
2 19 893 2,24 47,00 105,26 6,32 378,95
2 18 881 2,27 48,94 111,11 6,67 400,00
2 18 895 2,23 49,72 111,11 6,67 400,00
2 18 918 2,18 51,00 111,11 6,67 400,00
4 33 1813 2,21 54,94 121,21 7,27 436,36
4 33 1993 2,01 60,39 121,21 7,27 436,36
2,06 16 983 2,10 61,44 128,75 7,73 463,50

2.6. CONCLUSIONES.

Se ha efectuado la selección del medidor de flujo de agua de acuerdo a los parámetros que
habitualmente se utilizan para hacer este tipo de procedimientos, ajustándolos a las
necesidades particulares de este proyecto. El sensor de flujo volumétrico de efecto Hall
seleccionado es adecuado tanto para el tipo de tubería del entorno doméstico, hacia el cual
se centra el presente trabajo, como por sus características tales como tamaño reducido y
bajo costo.

Al efectuar la linealización del dispositivo se encuentra, sin embargo, que este presenta una
desviación importante en buena parte de la región de medición (llegando incluso a ser de un
10%) por lo que ha sido necesario efectuar una separación por regiones a fin de minimizar
el error de la medición. Afortunadamente este problema no es tan relevante dado que estas
correcciones se pueden hacer posteriormente utilizando software ya sea en el
microcontrolador o en la aplicación que se dedique a la captura y análisis de los datos.

24
 500

400

300
Flujo L/h
200

100

0
0 10
30 20 40 50 60 70
Frecuencia (Hz)
Figura 7. Comparación entre la respuesta del sensor dada por el fabricante (línea azul) y los datos obtenidos
en la medición de calibración (puntos rojos).

500

400

Calibración
Flujo L/h

300
Lineal 1
200 Lineal 2
Lineal 3
100
Lineal 4

0
0 10 20 30 40 50 60 70 80
Frecuencia (Hz)

Figura 8. Linealización por tramos de la respuesta característica del sensor.

25
 3. MÉTODO DE MEDICIÓN DE CONSUMO DE ENERGÍA ELÉCTRICA.

3.1. CLASIFICACIÓN GENERAL DE LOS MEDIDORES DE ENERGÍA

ELÉCTRICA.

Los medidores eléctricos poseen distintos tipos de clasificación de acuerdo a su

construcción, capacidad de medida, tipo de energía a medir, exactitud, tipo de conexión,
cantidad de elementos necesarios para la medición, y clase. Una explicación muy detallada
de los tipos se puede encontrar en [13] y [14] de donde nos hemos basado para la siguiente
selección:

Tipo de construcción: Se pueden clasificar como medidores de inducción o estáticos. En

los medidores de inducción la corriente que circula por una o varias bobinas fijas, reacciona
con aquellas que se inducen en un elemento móvil, por lo general un disco, cuyo
movimiento está relacionado con la cantidad de corriente circulante; generalmente se
adiciona un mecanismo de relojería con el cual se recupera la medición. Se pueden utilizar
para efectuar desde mediciones de bajo consumo (domésticas) hasta aquellas propias de las
líneas de transmisión de alto voltaje. Para este proyecto este tipo de medidor está
descartado dado su volumen.

Los contadores estáticos (también llamados de estado sólido) están elaborados a partir de
dispositivos semiconductores, logrando un tamaño reducido y práctico para instrumentos de
medición como el que se pretende elaborar, tienen un buen grado de precisión lo cual es
beneficioso ya que se pretende medir el consumo de cargas de baja potencia como lo son la
mayor parte de electrodomésticos. Por lo general esos dispositivos generan un pulso de
salida proporcional a la energía en vatios-hora.

Tipo de energía: Los medidores se pueden clasificar como medidores de energía activa o
reactiva. Los medidores de energía activa son los más comunes y miden la energía que
consumen los dispositivos con carga real (resistiva) típicamente en kilovatios hora (KW/h).
Los medidores de energía reactiva adicionalmente tienen la capacidad de censar la energía
debida a cargas reactivas, como son motores industriales, bancos de capacitores, entre
otros. Para este proyecto no se medirán los valores reactivos de las cargas.

Exactitud: Los medidores de energía se dividen en tres clases de acuerdo a la exactitud y la

capacidad de carga que es capaz de medir el dispositivo de la siguiente manera (para el
escenario colombiano están definidos por la norma NTC 2288 y 2148):

26
 - Clase 0.5: Utilizada para medir energía activa suministrada en bloque, ya sea en
puntos de frontera entre empresas de electrificadoras o grandes consumidores. Por
lo general trabajan con voltajes de 115 KV.
- Clase 1: Incluye los medidores trifásicos destinados a medir energía activa y
reactiva de grandes consumidores (usuarios que usan cargas mayores a 55 KW).
- Clase 2: Es la clasificación más general, en estos se incluyen los medidores
monofásicos para medir energía activa a nivel comercial y residencial, así como
industrias con cargas menores a 55 KW. El medidor propuesto para este proyecto
hace parte de esta clase.

Conexión con la red: según la forma como el medidor se encuentra conectado a la red esto
se pueden clasificar en:

- Medidor monofásico bifilar: Son utilizados para registrar la energía consumida en

una acometida que tiene un solo conductor activo (fase) y un neutro. Este es el tipo
de medidor que se utilizará en el presente proyecto.
- Medidor monofásico trifilar: Se usan para el consumo de energía en una
acometida monofásica de fase partida donde se tienen dos conductores activos y un
neutro.
- Medidor bifásico trifilar: Registra el consumo de una acometida en B.T de dos
fases y tres hilos.
- Medidor trifásico tetrafilar: se usa para el consumo energía de una acometida
trifásica en B.T de tres fases y cuatro hilos.
- Medidor trifásico trifilar: Se usa para la medición de consumo de energía de una
acometida de tres fases sin neutro.

Número de elementos: Hace referencia la cantidad de bobinas necesarias para efectuar la

medición, para los medidores de Estado sólido esta clasificación no es aplicable:

- De un elemento: Conformado por una bobina de corriente y una de tensión.

- De elemento y medio: Conformado por dos bobinas de corriente que comparten
una bobina de tensión, son medidores para ser conectados a 240 V.
- De dos elementos: Conformado por dos bobinas de corriente y dos de tensión.

De acuerdo con el tipo de medición: Según la norma Colombiana NTC 5019 se efectúan
tres tipos de medición:

- Directa: Es aquella en la que se conectan directamente al medidor los conductores

de la acometida, en este caso la corriente de la carga pasa totalmente a través de las
bobinas del medidor. Se usa para corrientes no mayores de 100 A.
- Semi-directa o semi-indirecta: Es aquella en la que las señales de corriente se
toman a través de transformadores de corriente y las señales de tensión se toman
directamente de las líneas de alimentación a la carga.
- Indirecta: Aquella en donde el medidor de energía no está conectado directamente
a los conductores de la acometida sino a bornes de instrumentos auxiliares de
medición.

27
El medidor propuesto requiere la medición directa del voltaje desde la línea de carga, y la
medición de corriente a través del dispositivo sensor (se ha reemplazado el transformador
de corriente por un sensor de efecto Hall), por lo que podría considerarse del tipo semi-
directo.Existen otras clasificaciones de medidores que dependen de propósitos específicos
dentro del sistema de suministro de la red eléctrica (medidor totalizador, prepago, entre
otros).

3.2. CRITERIOS PARA LA SELECCIÓN.

Rango de potencia: En este caso es de interés la medición de los aparatos consumidores de

energía eléctrica, mejor denominados electrodomésticos. Para el dimensionamiento del
dispositivo de medición no es necesario conocer el consumo total por unidad (vivienda,
establecimiento grupo de establecimientos) que normalmente si es primordial para
determinar el tipo de contador que se instalará por parte del proveedor del servicio, sino
centrarse en el consumo máximo de los electrodomésticos.

En la tabla 1 se muestran los valores típicos de consumo de dispositivos eléctricos y

electrónicos domésticos. El mayor valor de potencia para estos no supera 4500 W. Los
mayores valores de consumo corresponden a dispositivos que se caracterizan por contener
principalmente elementos resistivos, muchos de ellos se encuentran empotrados, por lo cual
la medición permanente de la corriente circulante requiere de instrumentos de medición de
dimensiones importantes, los cuales están descartados para este proyecto ya que se busca
elaborar dispositivos de dimensiones reducidas. El valor máximo de potencia que será
posible medir estará dado por las características del sensor de corriente (rango y
sensibilidad) sin embargo es deseable que abarque buena cantidad de electrodomésticos sin
comprometer el tamaño ni las características del sensor, por lo que se estima que opere en
un rango máximo cercano a 750 W donde se encuentran la mayor parte de aparatos listados.

Rango de voltaje: El rango de voltaje a medir debe ser comparable con el rango del voltaje
de línea nominal para la red eléctrica del país. El valor aceptable dentro del margen de
calidad de servicio para las líneas de tensión (según se deduce de la norma ANSI C84.1)
está en un rango deseable del ± 5% y un rango aceptable entre 5.8% y -8.3%La resolución
CREG 024 de 2005 establece que en Colombia los límites para variaciones de tensión de
larga duración (superior a 1 minuto) están en un rango del ±10% del voltaje nominal. De
esta manera el dispositivo de medición debe cubrir un rango máximo que sea al menos un
10% superior al valor nominal de 120 V (132 V RMS o 186.6 V pico) para garantizar su
funcionamiento normal ante variaciones de voltaje de larga duración.

Rango de corriente: Se observa que la corriente máxima a medir no sobrepasa los 18

Amperios (tabla 3), sin embargo, dada las características de reducidas dimensiones que se
necesitan en el sensor de corriente este no será capaz de alcanzar dicho valor máximo, por
lo que teniendo en cuenta que se pretenden medir cargas no mayores a 750 W la corriente
en este caso estaría cercana a los 6.25 A que sería el valor máximo de medición del
dispositivo.
28
Tabla 8.Lista de electrodomésticos típicos con sus rangos de potencia en vatios, la corriente se deriva de la
potencia promedio para una línea monofásica con voltaje de 110 V (datos extraídos de la página
http://www.electrocalculator.com/ y adaptados al presente trabajo).
Potencia (W) Corriente
Aparato Tipo o marca
Mín Promedio Máximo (A)

Afeitadora Genérica, antigua 0,7 2 15 0,017

Reloj Genérico 2 3,5 5 0,029
Cargador teléfono móvil Genérico 3 4 4,8 0,033
Altavoces PC / bocinas / parlantes Pequeños, laterales 3,4 10 23 0,083
Timbre de pared Genérico 8 10 15 0,083
Radio Genérico 0,1 13,4 40 0,112
Lector-reproductor DVD Grabador DVD sin nombre 8,7 13,8 25,3 0,115
Router ADSL (Internet) Genérico 10,1 20 30 0,167
Lámpara Fluorescente Fluorescente, genérico 6 24 40 0,200
Teléfono inalámbrico (base) Genérico 20 25 35 0,208
PC portátil Acer, EME725-452G64MIKK T4500 (2011) 35 46 65 0,383
Abrelatas eléctrico Genérico 50 60 80 0,500
Lámpara Bombilla filamento Bombilla filamento 40 60 120 0,500
Videoconsola HD cable box (disco duro externo) 30 80 194 0,667
Ventilador Cata 60 94 288 0,783
TV (LCD-DLP diferentes tamaños) DLP, 50-56 pulgadas 35 105 322 0,875
Reproductor DVD Genérico 25 106 200 0,883
TV (CRT) CRT Blanco y negro – Color 53 113 180 0,942
PC sobremesa (sólo la torre) Acer, AX3950 3.2GHZ/4GB 51 170 365 1,417
Impresora Laser Brother HL2240D monocromo (2011) 11 180 495 1,500
Batidora Genérico 140 210 250 1,750
Escáner HP Scanjet G2410 150 212 280 1,767
Extractor de aire (campana) Genérico 25 215 500 1,792
Exprimidora Genérico 35 245 450 2,042
Licuadora 5 velocidades 350 400 450 3,333
Nevera 21 ft3 90 408 1020 3,400
Rizador/alisador pelo aire caliente Revlon R420E 45 415 800 3,458
TV (plasma) Plasma, 42 pulgadas 450 465 470 3,875
Nevera Congelador grande OEM,JNS, 166 X 67,5 X 81,5 cm (2011) 100 517 890 4,308
Tostadora 1 uso, Philips 24 618 1051 5,150
Taladro (600 W) Genérico 600 670 750 5,583
Cafetera Genérico 600 680 730 5,667
Sandwichera Genérico 650 720 800 6,000
Aspiradora Genérica 670 1000 1300 8,333
Calentador de agua / terma eléctrica Genérico 20 1000 1500 8,333
Estufa cuarzo Genérico 350 1000 1200 8,333
Fotocopiadora Genérico 900 1000 1100 8,333
Olla arrocera Genérico 800 1000 1100 8,333
Hornillo eléctrico/Anafe Genérico 790 1050 1500 8,750
Plancha Genérico 1000 1067 1200 8,892
Lavadora 6 Kg 330 1100 2850 9,167
Secador pelo Braum silencio 1200 522 1100 2000 9,167
Horno microondas 1.2 ft3 1000 1250 1520 10,417
Microondas Genérico 640 1280 2000 10,667
Aire acondicionado Genérico, 2200 frigorías, 8800 BTU 560 1380 2950 11,500
Fogones eléctricos Genérico, 4 fogones 1200 2200 4500 18,333

29
Potencia consumida: La potencia del dispositivo debe ser la mínima posible, ésta resulta
de sumar el consumo de todos los componentes involucrados en el objeto IoT donde los
más importantes son el microcontrolador, el dispositivo de conexión a la red y el sensor de
parámetros eléctricos. Los valores máximos estimados están aproximadamente 450 mW
para el sensor de parámetros eléctricos, 500mW para el microcontrolador y hasta 650 mW
en el momento de envío de paquetes de datos grandes a través del dispositivo inalámbrico,
por lo que el valor de potencia podría llegar a alcanzar 1.6 W como máximo dependiendo
de las condiciones de operación y el envío de los datos. Típicamente los valores están muy
por debajo de este rango, estimándose para el sensor de parámetros eléctricos un valor de
25 mW, 25 mW para el microcontrolador y alrededor de 3 mW para el dispositivo
inalámbrico de red en reposo (siendo este el que presenta las mayores variaciones de
consumo de potencia en todo el proceso normal de operación del dispositivo) por lo que la
potencia en condiciones normales debería estar en un valor cercano a 53 mW.

Precisión de la medición: dado que el objetivo del proyecto es la implementación de

objetos IoT, la precisión de la medición de los parámetros eléctricos no es un factor crítico.
Es deseable, sin embargo, que el valor de la medición se encuentre dentro de un error no
mayor al 5%. Instrumentos de mejor precisión por exigen gran tamaño y elevado costo, lo
que implica una desviación en el propósito principal del trabajo.

Ambiente en el que se realizará la medición: El entorno de medición corresponde a

ubicaciones de carácter doméstico (habitaciones, sala, cocina, entre otros) los cuales tienen
unos niveles de humedad y temperatura estables. Se descartan medidores de alto costo
diseñados para ambientes con grandes variaciones de temperatura así como exposición a
humedad y corrosión.

Tipo de salida requerida: Los datos entregados por el dispositivo sensor deben contener la
medición de los parámetros eléctricos elegidos (voltaje y corriente como mínimo) estos
pueden ir representados de diferentes maneras como niveles de voltaje, trenes de pulsos o
secuencias de datos a través de un puerto de comunicaciones. Se pretende sencillez en el
diseño por tanto se busca que la captura de la información ocupe la menor cantidad de
componentes posible.

Linealidad y velocidad de respuesta: Una alta linealidad no es crítica para el proyecto, es

deseable sin embargo que la desviación de las mediciones sea pequeña, especialmente en
los rangos más bajos de la medición de potencia y corriente. La velocidad de respuesta del
sistema de medición debe ser no superior a un segundo que es el tiempo establecido para
hacer el envío de datos a través del dispositivo de red.

Costos: El costo del dispositivo debe ajustarse al presupuesto sin llegar a ser demasiado
excesivo. Como ya se ha visto, los dispositivos de estado sólido que efectúan las
mediciones de parámetros eléctricos son los que presentan la mejor relación entre el costo,
tamaño, capacidad de medición, entre otras características, por lo cual un dispositivo de
este tipo es el elegido y cuyos detalles se mencionan seguidamente.

30
 3.3. SELECCIÓN DEL TIPO DE DISPOSITIVO.

Para la medición se seleccionó un dispositivo de estado sólido. En la actualidad existen

varias series de circuitos integrados dedicados para la medición de energía eléctrica, una de
las más completas y conocidas es la serie ADE77xx de Analog Devices la cual se ajusta a
los requerimientos para efectuar todo tipo de mediciones eléctricas en diferentes tipos de
líneas de tensión. De esta serie los circuitos integrados que entregan los parámetros
deseados para una línea monofásica que tiene mayor interés dado su costo y confiabilidad
son el ADE7753 y ADE7763. Básicamente se trata del mismo circuito donde las
principales diferencias radican en su capacidad para soportar transitorios de voltaje y
corriente, y descargas electrostáticas.

3.4. MEDICIÓN DE CORRIENTE.

Las técnicas para efectuar la medición de corriente buscan transducir la corriente eléctrica
en una señal de voltaje que sea posible medir en un dispositivo de estado sólido. Se usan
cuatro tipos de transductores para efectuar la medición, siendo el más sencillo una
resistencia (o un divisor resistivo)de un valor muy bajo y preciso, conectada en serie con la
carga, y medir la caída de potencial sobre dicha resistencia la cual es equivalente a la
corriente circulante a través del dispositivo. Este tipo de medidor tiene la desventaja de que
la corriente circulante que se va a medir pasa completamente a través del sensor; para
efectuar la medición de altas corrientes se requiere que el elemento resistivo tenga grandes
dimensiones y disipe una importante cantidad de potencia que se pierde en el proceso de
medición. También tiene la desventaja de que no se genera aislamiento eléctrico de la línea
hacia el medidor con lo cual el circuito de medición está expuesto a las características no
deseadas de la línea AC, como sobre-tensiones. Por su parte, tiene la ventaja de ser
sumamente sencillo y económico. Otra manera de hacer la medición de corriente es a través
del denominado transformador de corriente, este hace uso de un circuito magnético que
transduce el valor de la corriente desde el devanado de una bobina a otra acoplada mediante
un núcleo. La bobina Rogowski es una versión más simple del transformador de corriente
donde un inductor toroidal (normalmente con núcleo de aire) se enrolla alrededor del
conductor a través del cual circula la corriente a medir, la señal obtenida corresponde a la
derivada de la corriente por lo que es necesario añadir un integrador para recuperar el valor
transducido de la corriente.

Para este proyecto se han descartado los sensores de transformador de corriente y la bobina
Rogowski, que aunque son sistemas de medición muy confiables, por lo general ocupan un
volumen mucho mayor en comparación con los dispositivos de medición de corriente de
estado sólido (figura 1). Igualmente se han descartado los divisores resistivos dados los
inconvenientes que presentan en altas corrientes. El dispositivo de medición de corriente de
estado sólido posee un sensor lineal de efecto Hall alineado a un conductor por el que
circula la corriente a medir, esta genera un campo magnético que el sensor convierte en una

31
tensión proporcional. La exactitud del dispositivo se optimiza a gracias a la cercanía de de
la señal magnética al transductor al estar todo construido en un mismo encapsulado.

Figura 1. Comparación de tamaños de los tipos de sensores de corriente: A) Resistivo, B) Transformador de

corriente, C) Bobina Rogowski, D) Sensor de estado sólido de efecto Hall.

Una de las series de IC de sensores de corriente más usada en la medición de tensiones de

red domésticas es la serie ACS7xx de Allegro Microsystems, de esta se ha seleccionado el
IC ACS714 el cual tiene una capacidad de medición hasta 20 A, el cual cubre todo el rango
de electrodomésticos de la tabla 1. En la figura 2 se observa la conexión típica del
dispositivo, requiriendo únicamente un par de condensadores que fijan la tensión de
alimentación y un filtro pasabajas externo para eliminar ruidos de la línea [15].

Figura 2. Diagrama típico de conexión del IC ACS714 (tomado de la hoja de datos del fabricante).

32
 3.5. MEDICIÓN DE VOLTAJE.

La medición de voltaje, como en el caso anterior, puede hacerse directamente desde la línea
a medir usando un divisor resistivo o un transformador convencional de voltaje, otros
métodos como el uso de optoacopladores lineales permiten el aislamiento eléctrico entre el
voltaje a medir y el instrumento, empero exigen el uso de una mayor cantidad de
componentes a parte de fuentes de alimentación en ambos lados de la medición, motivo por
el que se han descartado buscando una mayor sencillez, de modo que la medición se tomará
usando un divisor resistivo. Un aspecto muy importante a tener en cuenta al hacer la
medición de esta manera será el acople entre la tierra digital y en neutro de la línea AC tal
como se describe en la sección 5.4.1.1.

3.6. SENSOR SELECCIONADO

3.6.1. CARACTERÍSTICAS TÉCNICAS DEL ADE7753.

EL ADE7753 es un medidor de potencia eléctrica monofásica basado en un sistema de

registros, con interfaz serial y salida de pulsos. El mismo ofrece entre otras las siguientes
características [16]:

- Salida de tren de pulsos cuya frecuencia es proporcional a la potencia activa.

- Interfaz serial de cuatro hilos compatible con SPI, que permite la comunicación entre
Microcontroladores.
Alta exactitud (menos del 0,1% de error sobre un rango de 1000 a 1).
- Detección de baja tensión o ausencias de la misma durante lapsos predefinidos, con
umbrales de tensión de línea programables.
- Muestras digitales de las formas de onda de tensión y corriente.
- Calibración digital de la potencia, la fase y la deriva (offset de entrada).
- Sensor de temperatura incorporado.
- Referencia de tensión de 2,5 ± 8% y temperatura de 30ppm/ºC incorporada.
- Salida de pulsos sincronizada con los cruces por cero de la tensión de línea, que puede ser
utilizada para extraer información de tiempo o frecuencia y sincronizar dispositivos
externos.
- Disponibilidad de 18 registros de datos (6 de sólo lectura y 12 de lectura y escritura),
accesible a través de la interfaz serial desde un registro maestro de comunicaciones.
- Ancho de banda nominal de 14KHz.
- Variación típica en la frecuencia de salida del orden de 0,2%.
- Entradas analógicas de alta impedancia (390KW mínima), capaces de aceptar señales
hasta de ±1V.
33
- Frecuencias de reloj de opresión en el intervalo de 1MHz hasta 10MHz. (El valor nominal
es de 3,579545MHz)
- Entradas y salidas lógicas compatibles con TTL y CMOS.
-Alimentación a partir de una fuente sencilla de +5V con bajo consumo de potencia
(15mW, típico).

Figura 3. Esquema de bloques del IC ADE7753 (tomado de la hoja de datos del fabricante).

El ADE7753 cuenta con conversores ADC y procesamiento DSP propios para lograr una
alta precisión con grandes variaciones en las condiciones ambientales y en el tiempo
(Figura 3). Incorpora dos ADC de 16 bits de segundo orden tipo sigma delta (Σ-Δ), un
integrador digital (en CH1- medición de corriente), circuitos de referencia, sensor de
temperatura, y todo el procesamiento de señales requerido para realizar mediciones de
energía activa, reactiva, y aparente, medición del período del voltaje de línea, medición y
cálculo del valor RMS de voltaje y corriente. Proporciona una interfaz de serie sincrónica
para leer datos, y una frecuencia de salida de impulsos (CF), que es proporcional a la
potencia activa. Posee también características de calibración del sistema que garantizan una
alta precisión. También detecta variaciones de corta duración, de bajo o de alto voltaje. El
modo de acumulación único positivo brinda la opción de acumular energía sólo cuando se
detecta energía positiva. Un umbral de no-carga interna asegura que el componente no
presenta ninguna influencia cuando no hay carga. La salida de cruce por cero (ZX) produce
un pulso que está sincronizado con el punto de la tensión de línea de cruce por cero. Esta
señal se utiliza internamente en los modos de acumulación de energía activa y aparente por
ciclo de línea, lo que permite una calibración más rápida.

34
 3.6.2. MONTAJE DEL CIRCUITO ADE7753.

EL montaje del ADE7753 se realizó de acuerdo a la documentación técnica de la hoja de

datos de fabricante. Se requiere de pocos componentes para poner en funcionamiento este
IC. En la figura 4 se muestra el circuito elaborado para efectuar las pruebas de medición y
calibración, para estas pruebas la alimentación de voltaje DC se realizó usando una fuente
regulada con transformador, por lo que se garantizó el aislamiento eléctrico a fin de que el
acople de la tierra digital con el neutro de le línea AC no generara cortocircuitos que
pudieran destruir el circuito, Así mismo, se realizaron pruebas usando aislamiento con
transformador en el divisor resistivo encargado de la medición de voltaje para poder
conectar el microcontrolador al PC y hacer pruebas del comportamiento de los registros del
ADE7553.

Figura 4. Circuito propuesto para la calibración del circuito ADE7753.

3.6.2.1 Conexión del sensor de voltaje.

De acuerdo a la documentación del ADE7753 [16], la medición de voltaje se efectúa a

través de un canal de entrada de voltaje diferencial marcado como V2P/V2N cuyo valor
nominal máximo es de ± 0,5 V con respecto a la tierra análoga (AGND), soportando
transitorios de hasta 5 V en un intervalo menor de 1 segundo. Este canal tiene un
amplificador de ganancia programable (PGA) como se observa en la figura 3, con posibles
selecciones de ganancia de 1, 2, 4, 8, y 16. La selección de la ganancia se hace escribiendo
el registro de ganancia (GAIN). La documentación del IC indica que en este lazo se debe
incluir un filtro anti-aliasing RC que genere una atenuación cercana a 40 dB al doble de la
frecuencia de muestreo (447 KHz con un reloj de 3.58 MHz). El circuito recomendado es
un desacople con un resistor de 1 KΩ en paralelo con un capacitor de 33 nF (C7, C8, R10 y
R18 en la figura 3). Por lo que para calcular el valor del divisor de voltaje se tiene en cuenta
que el valor máximo de voltaje a la entrada del conversor es de ± 0,5 V y que los límites
para variaciones de tensión de larga duración (superior a 1 minuto) están en un rango del

35
±10% del voltaje nominal como se describió en la sección 3.2, y que la caída de voltaje a
medir se hará sobre un resistor de 1 KΩ como se muestra en la figura 5, siendo así sólo
queda calcular el valor requerido de R1.

Figura 5. Divisor de voltaje para la medición de voltaje en el ADC del ADE7753.

De la caída de potencial sobre R2:

𝑅2 𝑉𝑝 𝑉𝑝
𝑉𝑚 = 𝑅1 = 𝑅2 −1
𝑅1 + 𝑅2 𝑉𝑚
Reemplazando valores:
187
𝑅1 = 1000 − 1 = 373 𝐾Ω
0.5

Por lo que el valor mínimo recomendado para R2 es de 373 KΩ. En la práctica se han
variado estos valores ligeramente estableciendo este valor en 364 KΩ ya que este era el
valor más cercano que se alcanzó con el menor número de resistencias de precisión (el
divisor debe tener una precisión del 1% o mejor).

3.6.2.2. Conexión del sensor de corriente.

El sensor de corriente ACS714-20A tiene una sensibilidad de 100mV/A [15], por lo que
este entregará una señal AC con un valor pico de 2 V como valor con su carga máxima, sin
embargo es necesario hacer una serie de consideraciones, la principal es que el circuito
propuesto para la medición de energía eléctrica también tendrá la capacidad de controlar el
encendido del electrodoméstico. Se incluye un circuito simple de conmutación con un triac
que soporta hasta 16 A (tal como el BTA16). En operación normal se limitará la corriente a
un máximo de 6.25 A, por lo que las cargas que se pueden conectar al circuito propuesto no
deben superar los 750 W. Esta restricción limita la cantidad de electrodomésticos que se
pueden conectar, sin embargo, cubre la mayoría de los descritos en la tabla 1. Establecida la
carga máxima el valor máximo de voltaje de salida del sensor será de 0.6 Voltios, por lo
que en todo caso es necesario efectuar un divisor de voltaje para no superar el umbral de
0.5 V del ADC. Adicionalmente, el valor que entrega el sensor está montado sobre la mitad
del voltaje de polarización DC del sensor (2.5 V) por lo que es necesario eliminar esta
componente, para ello la solución más simple es agregar un capacitor en serie con el
circuito resistivo que se usará como divisor de voltaje. Inicialmente consideremos un
divisor resistivo como el del figura6, si fijamos R1=1 KΩ:
36
 𝑅1 1000
𝑅2 = 𝑉𝑝 = 0.6 = 5000
−1 − 1
𝑉𝑚 0.5

El valor comercial más cercano es de 5.1 KΩ que es el que se ha seleccionado. Para

calcular el capacitor se tendrá en cuenta que la frecuencia de línea es de 60 Hz, por lo que
es deseable que a esta frecuencia la impedancia del capacitor sea insignificante, igualmente
se colocará un capacitor como filtro pasabajas para limitar el ruido de alta frecuencia como
recomienda la hoja de datos. Se obtiene un filtro pasabanda como el de la figura 4, la
función de transferencia:

Figura 6. Circuito para el acople del Sensor ACS714 con en el ADC del ADE7753.

1
𝑉0 𝑠 𝑅𝐶 1
= 2 1 2
2 𝑑𝑜𝑛𝑑𝑒 𝜔02 =
𝑉𝑖 𝑠 + 𝑠𝜔𝐵 + 𝜔0 𝐶1 𝐶2 𝑅1 𝑅2

La frecuencia central debe ser cercana al valor de 60 Hz de la línea AC. Para establecer el
valor de los capacitores se tendrá en cuenta que el ancho de banda que se requiere debe
garantizar una atenuación de al menos -40 dB a 894 KHz, dado que la caída en potencia es
de -20 dB/década en la parte pasabajas, se requiere que la frecuencia de corte de alta sea de
8.9 KHz o menor. Es posible escoger arbitrariamente un capacitor y calcular el otro, por
facilidad de cálculo se establece C2 en 0.1 µF y determinamos el valor de C1:

1 1
𝐶1 = = = 13,79 µ𝐹
𝜔02 𝐶2 𝑅1 𝑅2 120𝜋 0.51

El valor comercial más cercano es de 10 µF, por lo que podemos seleccionar este y calcular
nuevamente la frecuencia central y el ancho de banda:

1 1
𝜔02 = = ∗ 106 𝑑𝑒 𝑑𝑜𝑛𝑑𝑒 𝜔0 = 70.475 𝐻𝑧
𝐶1 𝐶2 𝑅1 𝑅2 5.1

Que es un valor cercano a los 60 Hz de la línea, el ancho de banda queda entonces como:
𝑅2 𝑅 𝑅
+ 2+ 1 6.151 ∗ 1010
𝐶2 𝐶1 𝐶2
𝜔𝐵 = = = 12060.8, 𝑑𝑒 𝑑𝑜𝑛𝑑𝑒 𝑓𝐵 = 1919.5 𝐻𝑧
𝑅1 𝑅2 5.1 ∗ 106
37
Se establece entonces el ancho de banda cercano a 2 KHz, lo cual es mucho menor que el
máximo estipulado de 8.9 KHz

3.6.3. CALIBRACIÓN.

3.6.3.1 Ajuste de registros.

Una vez elaborado el montaje del circuito de prueba, diferentes cargas con valores
conocidos de resistencia y/o consumo de potencia activa fueron colocados en el mismo a
fin de conocer los valores medidos almacenados en los registros del ADE7753. Para
realizar la calibración de forma correcta y confiable se han tenido en cuenta las siguientes
consideraciones:

•El ADE7753 fue calibrado con las cargas a emplear (electrodomésticos).

•El ADE7753 fue montado de acuerdo a la hoja de datos del fabricante.
•Se realizaron pruebas dentro de todo el rango a medir, teniendo en cuenta la posterior
inclusión del circuito de control ON/OFF.

Adicionalmente para esta prueba se siguieron los siguientes parámetros:

1. El circuito digital se encuentra completamente aislado de la línea AC mediante un

transformador de voltaje.
2. Se adicionó un fusible de 10 A en caso de que accidentalmente se presentara un
cortocircuito, o se conectara una carga por encima de los valores a medir.
3. Se realizaron mediciones modificando el valor de los registros de configuración del
ADE, principalmente el registro MODE (#000009 de la memoria del ADE), este registro
de 16 bits es donde la mayor parte de la funcionalidad del ADE7753 es accedida: La tasa de
muestreo, el habilitador del filtro, y los modos de calibración son seleccionados escribiendo
en este registro. El otro registro de vital importancia para las pruebas el es IRQEN
(#00000A de la memoria del ADE), este es el registro habilitador de interrupciones. Las
interrupciones del ADE7753 pueden ser desactivadas en cualquier momento poniendo el
correspondiente BIT en cero en este registro.

Los datos tomados se muestran en la tabla 2. El microcontrolador efectúa la lectura de los

registros cada segundo y los envía hacia el PC mediante una interfaz serie, allí una sencilla
aplicación de terminal los recibe y almacena en un archivo de texto plano. Los registros que
se leen, y que contienen los datos relevantes para la prueba son:

AENERGY (#000002) Registro de potencia activa. La potencia activa es acumulada sobre

un periodo de tiempo en un registro de 24 bits de solo lectura.
IRMS (#000016) Registro que acumula el valor RMS del canal 1 (canal de corriente).
VRMS (#000017) Registro que acumula el valor RMS del canal 2 (canal de voltaje).

38
El ADE7753 tiene un total de 43 registros que se usan para la calibración, modificación de
parámetros y puesta a punto del IC. En la Figura 5 se muestra el ajuste inicial de registros
necesario para la correcta toma de datos de los registros de medición. Inicialmente se
habilita el IC colocando en ALTO el pin CS (Chip Select), se espera mientras se inicializan
todos los registros a su estado por defecto, en seguida se habilitan las interrupciones
(establecer en 1 el bit 7 del registro IRQEN, registro habilitador de interrupciones), y la
detección de cruce por cero para que genere eventos (bit 5 a ALTO en registro IRQEN). Se
establece el registro MODE en 140, con este valor la Frecuencia de salida CF se desactiva
(no es usada en esta implementación).La detección de huecos de tensión de línea se
desactiva igualmente. Finalmente también se coloca el chip en modo de acumulación de
energía ciclo de línea [16].

Figura 7. Ajuste inicial de registros del ADE7753 para las mediciones de parámetros eléctricos.

El registro VAGAIN (#00001A) es un multiplicador que se agrega al cálculo de la potencia

(La ganancia se ajusta al escribir un número de 12 bits en complemento a 2 en el registro),
este se establece en cero ya que se trabajará con el valor de potencia tal como se desprende
de la medición de voltaje y corriente a partir de los ADC. El registro LINECYC
(#00001C)es un registro de 16 bits usado durante el modo de acumulación de energía de
ciclo de línea para establecer el número de medios ciclos de línea para la acumulación de
energía, este cuanta cada uno de los cruces por cero (medio ciclo) Dado que se desea hacer
una medición cada segundo, el calor se establece en 120 o un número menor de ciclos.

Tabla 2.Pruebas y colecta de datos de medición del ADE7753 con diferentes cargas.
Carga A (RMS) V (RMS) W IRMS VRMS LAENERGY
0W 0 120 0 8600 1410000 5
8W 0,064 121 7,744 57700 1401400 362
14 W 0,133 120,8 16,0664 112000 1383000 668
22 W 0,194 120,3 23,3382 154700 1370000 993
40 W 0,328 120,8 39,6224 181800 1404000 1938
60 W 0,5 120,8 60,4 274100 1403000 2898
68 W 0,555 120,3 66,7665 313400 1397229 3238
74 W 0,605 119,9 72,5395 348400 1370000 3464
100 W 0,8 120 96 451100 1392000 4738
170 W 1,62 118,8 192,456 939700 1357400 8498
720 W 8,62 115,1 992,162 3596892 1306038 34935

39
3.6.3.2. Equivalencia de valores obtenidos.

En la tabla 2 se muestran los valores obtenidos de los registros VRMS, IRMS y

LAENERGY, correspondientes a la medición de voltaje, corriente y potencia para cada una
de las cargas que se han usado, a partir de estos valores se puede establecer el valor
equivalente de cada valor de registro respecto al valor medido, de forma que se obtiene una
ecuación para recuperar los valores de estos parámetros. Estos valores de calibración serán
parte de las funciones encargadas de gestionar los datos en el servidor como se verá en el
capítulo 6, es decir, el dispositivo propuesto en el capítulo 5 no efectuará conversiones sino
que únicamente hará lectura de datos y envío de los mismos a la web.

A (RMS) W
1,8 250
y = 0,0000017774x - 0,0251367404 y = 0,0221137745x - 1,7760384888
1,6
1,4 200
1,2
150
1
0,8
100
0,6
0,4 50
0,2
0 0
0 300000 600000 900000 0 3000 6000 9000

V (RMS)
122
y = 0,0000577011x + 40,1217936204
121
120
119
118
117
116
115
1300000 1330000 1360000 1390000

Figura 8. Obtención de la ecuación lineal para los valores de voltaje, corriente y potencia medidos con el
ADE7753.

Los registros poseen un valor de offset que puede ser reducido mediante la calibración de
los registros de offset (IRMSOS y VRMSOS), sin embargo, por simplicidad se ha dejado
esta corrección para la función de conversión de servidor, a partir de la regresión efectuada
(figura 8) se estimaron los siguientes valores de conversión:

40
Conversión de corriente: El valor del offset oscila ligeramente sobre un valor de 8600, por
lo que para recuperar el valor inicialmente se resta dicho valor del obtenido en el registro,
al recalcular la linealización se obtiene que:

𝑰𝑹𝑴𝑺 − 𝟖𝟔𝟎𝟎
𝑪𝒐𝒓𝒓𝒊𝒆𝒏𝒕𝒆 𝒎𝒆𝒅𝒊𝒅𝒂 =
𝟓𝟒𝟏𝟎𝟎

Conversión de voltaje: Para efectuar la conversión del voltaje se han realizado varias
pruebas usando diferentes valores AC de salidas de transformador, en la práctica rara vez
existirán oscilaciones mayores a unos cuantos voltios respecto al valor nominal de la línea
AC. El valor aproximado de voltaje se obtiene mediante:

𝑽𝑹𝑴𝑺
𝑽𝒐𝒍𝒕𝒂𝒋𝒆 𝒎𝒆𝒅𝒊𝒅𝒐 =
𝟏𝟏𝟕𝟓𝟎

Conversión de potencia: La potencia presenta igualmente un offset que varía entre valores
negativos hasta 17 aproximadamente estando la mayor parte del tiempo en 5, por lo que
para valores menores a 17 se tiene en cuenta el comportamiento de la corriente para
establecer si hay o no consumo de potencia, para labores por encima de este umbral se usa
la siguiente expresión:

𝑳𝑨𝑬𝑵𝑬𝑹𝑮𝒀 − 𝟏𝟕
𝑷𝒐𝒕𝒆𝒏𝒄𝒊𝒂 𝒎𝒆𝒅𝒊𝒅𝒂 =
𝟒𝟓. 𝟐𝟐𝟎𝟕

3.7. CONCLUSIONES.
.

Se seleccionó y probó el dispositivo de medición de parámetros eléctricos que hará parte

del dispositivo de medición eléctrico, este es el IC ADE7753, el cual tiene unas
prestaciones aceptables de medición a un bajo costo, aprovechando el sensor de corriente
ACS174 el cual reduce considerablemente el tamaño de la circuitería pensado en
desarrollar un objeto IoT pequeño y fácil de usar. No se realizó una calibración de precisión
del medidor ya que no es el propósito de este proyecto, para ello se requiere, entre otros
elementos, de un banco de cargas bien definidas así como un variac o circuito equivalente
para modificar la amplitud de la señal AC en la medición de voltaje. Desarrollos detallados
de diversas calibraciones y puestas a punto se encuentran en [35], [36] y [37], por lo que se
remite al lector a dichas referencias.

En las pruebas efectuadas se encontró que el ADE genera un reset, cuando se presentan
picos de corriente por la conexión de una carga en el circuito, en la hoja de datos se
recomienda el uso de bobinas de choke en los acoples de tierras y en los nodos de las
mediciones. En cualquier caso se implementó en el microcontrolador una rutina que detecta
el estado de reset del ADE7753 y restablece los registros al estado requerido como los
dados en la figura 7.

41
 4. MÉTODO DE COMUNICACIÓN DE DISPOSITIVOS

4.1. PROTOCOLOS DE COMUNICACIÓN ENTRE DISPOSITIVOS.

En la actualidad existen varios protocolos inalámbricos de comunicación, así como

dispositivos y tecnologías que se ajustan a estos. Dentro de la selección se han tenido en
cuenta, entre otros factores, la fiabilidad de la red, la capacidad de itinerancia, los
mecanismos de recuperación, el precio conjunto de chips y la capacidad instalada. Los
estándares Bluetooth (norma IEEE 802.15.1), ultra-wideband (UWB - ultra banda ancha,
norma IEEE 802.15.3), ZigBee (IEEE 802.15.4), y Wi-Fi (IEEE 802.1) son cuatro de las
normas de protocolos de comunicación inalámbrica de corto alcance con bajo consumo de
energía [17], siendo estos las más extendidos. Desde el punto de vista de aplicación,
Bluetooth está destinado a periféricos como ratones inalámbricos, teclados, auriculares,
manos libres, controles para consolas de videojuegos, entre otros. UWB está orientado a
enlaces multimedia de banda ancha, ZigBee está diseñado para el monitoreo y control de
redes inalámbricas confiables, mientras que Wi-Fi está dirigido a conexiones de equipo a
equipo como una extensión o sustitución de las redes cableadas.

En la Tabla 2 se muestra una comparación entre las diferentes características de los

estándares de comunicación mencionados. Aunque el protocolo de comunicación ZigBee es
popularmente adoptado en redes de sensores inalámbricos (WSN), es más bien inmaduro en
comparación con el Protocolo de Internet (IP) que ha tenido gran difusión y desarrollo
durante los últimos 40 años [18]. Las Redes ZigBee no pueden comunicarse directamente
con el Internet actual. Siempre necesitan una puerta de entrada (gateway) para recoger los
datos necesarios de una red ZigBee y convertir el protocolo ZigBee en IP. Por el contrario,
el Protocolo de Internet, especialmente la versión 6 (IPv6), es una alternativa más
prometedora en lo que se refiere a la escalabilidad. Si una red de sensores inalámbricos se
desarrolla basada en el protocolo IP, se elimina la necesidad de un traductor de capa de
aplicación que es obligatorio para las redes ZigBee. Muchos servicios basados en IP
existentes pueden por lo tanto ser reutilizados para monitorear redes inalámbricas de
sensores en tiempo real.

Wi-Fi es el estándar con mayor capacidad instalada, sus módulos para desarrollo, que hasta
hace poco eran escasos, se encuentran hoy a precios similares a los de otras normas. Entre
otras ventajas, permite el uso de menos infraestructura al no requerir de puertas de entrada
adicionales para acceder a Internet, alcances de señal adecuados para su uso en ambientes
interiores (hogares con múltiples habitaciones y pisos). Por otra parte tiene la desventaja de
requerir un importante consumo de energía en comparación con otros estándares, lo cual

42
afecta el tiempo de vida útil de las baterías para los dispositivos, así como de requerir
fuentes de alimentación un tanto más robustas que sus equivalentes [17].

Tabla 1. Comparación entre las diferentes características de los estándares de comunicación inalámbrica más
usados.
Estándar Bluetooth UWB ZigBee Wi-Fi
Norma IEEE 802.15.1 802.15.3a * 802.15.4 802.1 1a/b/g
868/915 MHz; 2.4
Bandas de frecuencia 2.4 GHz 3.1-10.6 GHz 2.4 GHz; 5 GHz
GHz
Tasa máxima de la señal 1 Mb/s 110 Mb/s 250 Kb/s 54 Mb/s
Alcance nominal 10m 10 m 10 - 100 m 100 m
Potencia 0 - 10 dBm -41.3 dBm/MHz (-25) - 0 dBm 15 - 20 dBm
Número de canales de RF 79 (1-15) 1/10; 16 14 (2.4 GHz)
500 MHz - 7.5
Ancho de banda del canal 1 MHz 0.3/0.6 MHz; 2 MHz 22 MHz
GHz
BPSK, QPSK,
Tipo de modulación GFSK BPSK, QPSK BPSK (+ ASK), O-QPSK COFDM, CCK, M-
QAM
DS-UWB, MB-
Extensión de modulación FHSS DSSS DSSS, CCK, OFDM
OFDM
Selección dinámica
Saltos
de frecuencia,
adaptables Saltos adaptables Selección dinámica de
Mecanismo de coexistencia control de potencia
de de frecuencia Frecuencia
de transmisión
frecuencia
(802.1 1 h)
Celda básica Piconet Piconet Estrella BSS
Ampliación de la celda Árbol de clúster,
Scatternet Igual a Igual (P2P) ESS
básica Mesh
Número de nodos de la
8 8 > 65000 2007
celda
Cifrado de clave Cifrado de flujo RC4
Cifrado de Cifrado de clave AES
Encriptación AES (CTR, modo (WEP), Cifrado de
flujo EQ (CTR, modo contador)
contador) clave AES
Secreto CBC-MAC (ext. of
Autentificación CBC-MAC (CCM) WPA2 (802.11i)
compartido CCM)
Protección de datos 16-bit CRC 32-bit CRC 16-bit CRC 32-bit CRC

4.2. SELECCIÓN DEL MÓDULO DE COMUNICACIÓN INALÁMBRICO.

Para elegir de módulo de comunicación, basado en Wi-Fi, se han explorado las

características técnicas, las dimensiones físicas y el costo, siendo este último el factor
determinante en la selección. En la Tabla 3 se listan los módulos comerciales más comunes.
Para el proyecto la tasa de transferencia de datos es muy inferior a las máximas capacidades
de cada módulo por lo que no resulta ser un factor relevante en la selección, igualmente
43
sucede con la comunicación con el microcontrolador, donde todos los módulos posen
protocolos comunes en estos IC. En cuanto a la encriptación de los datos todos comparten
las más usadas en el estándar IEEE 802.11. Las dimensiones físicas varían bastante según
los propósitos específicos del diseño de los módulos, siendo el Wifi Shield de Arduino el
más grande al estar pensado para conectarse a una placa Arduino, los más pequeños y
adecuados para el propósito del trabajo son el RN-XV WiFly y el ESP8266. De estos
últimos, el ESP8266 destaca por sus reducidas dimensiones y especialmente por su bajo
costo, razones por las cuales se ha elegido como el módulo de comunicación de los
dispositivos IoT propuestos.

Tabla 2. Comparativa entre diferentes módulos de comunicación inalámbrica Wi-Fi.

comunicación Costo
Velocidad Encriptación
Dispositivo Fabricante Estándar con aprox
de conexión de red
microcontrolador U$

DigiConnect 802.11 hasta WEP, WPA, RS-232/422/485

DigiConnect 109
ME b/g/n 11Mbps WPA2 hasta 230 Kbps

802.11 hasta 10
Wifi Shield Arduino WEP, WPA2 SPI hasta 25MHZ 77
b/g Mbps
WEP, WPA,
WiFiShield - 802.11 hasta 11
SparkFun WPA2, AES, SPI hasta 16MHZ 40
CC3000 b/g Mbps
TKIP
hasta 54
RN-XV 802.11 WEP, WPA, UART hasta 464
SparkFun Mbps en 35
WiFly b/g WPA2, PSK Kbps
802.11g
hasta 54
802.11 SPI, UART, I2C
ESP8266 Espressif Mbps en WPA,WPA2 7
b/g/n hasta 100 KHz
802.11g

4.3. DISPOSITIVO WIFI ESP8266EX

El ESP8266EX es un IC del fabricante chino Espressif el cual cuenta con un

chipTensilicaL106 que integra un microcontrolador RISC de 32 bits como MCU (Figura
1). La velocidad de reloj de CPU es de 80MHz llegando a un valor máximo de 160MHz. La
versión actual del kit de desarrollo de software (SDK) ocupa sólo el 20% de la pila de
memoria del MIPS3para la operación de Wi-Fi, el resto se puede usar para el desarrollo de
aplicaciones de usuario. A finales de octubre de 2014 Espressif dio a conocer un SDK que
permite al chip ser programado directamente, eliminando la necesidad de un
microcontrolador externo, por lo que hay disponibles dos firmware para instalación; uno

3
Se denomina MIPS (siglas de Microprocessor without Interlocked Pipeline Stages) a toda una familia de
microprocesadores de arquitectura RISC desarrollados por MIPS Technologies.

44
por comandos AT si se quiere controlar con un MCU externo, y otro que permite el uso del
MCU interno del ESP. La placa trae integrada la antena, un balun RF, un amplificador de
potencia, un amplificador bajo en ruido, filtros y un módulo de gestión de energía. Requiere
un mínimo de circuitos externos y está diseñado para ocupar un área mínima de PCB.

En el mercado existen gran variedad de placas con el chip ESP8266EX [19] (figura 2) la
diferencia radica en los diferentes tamaños, pines disponibles y memoria flash que los
ensambladores ponen a disposición. Para el proyecto se ha seleccionado la versión 1del
ESP8266 (figura 3) el cual es el más común dado que tiene el menor precio, en
contrapartida es el que posee la menor cantidad de pines disponibles para conexión externa.

Figura 1. Encapsulado del IC ESP8266EX y diagrama de bloques [20].

4.3.1 CARACTERÍSTICAS.

Las principales características del módulo seleccionado son:

• CPU tipo RISC de 32 bits Tensilica Xtensa LX106 a 80 MHz

• RAM de 45 Kbytes
• Flash externa de 512 Kb hasta 4 Mb (soporta hasta 16 Mb)
• IEEE 802.11 b/g/n Wi-Fi
• Integrado TR switch, balun, LNA, amplificador de potencia
• Autentificación WEP o WPA/WPA2
• SPI, I²C, I²S
• UART
• 1 ADC de 10-bit
• Voltaje de operación 3 v -3.6 v
• Protocolos de red IPv4, TCP/UDP/HTTP/FTP
• Tamaño (14.3 x 24.8)mm

45
 Figura 2. Diferentes presentaciones del módulo ESP8266

Figura 3. ESP8266-01 con memoria flash y chip ESP8266EX(tomado de

http://www.esp8266.com/wiki/doku.php?id=esp8266-module-family)

4.3.2 CONSUMO DE CORRIENTE.

La tabla 3indica el consumo de corriente con un suministro de 3,3 V a 25 ° C de

temperatura. Las mediciones se llevan a cabo en el puerto de la antena sin filtro SAW. Las
mediciones se basan en un ciclo de trabajo del 90% y modo de transmisión continua [20].

4.3.3. MEMORIA.

Según el actual SDK, la memoria RAM disponible es menor que 45 Kb cuando el

ESP8266EX está trabajando en el modo de estación y se encuentra conectado al router.
Este espacio, aunque limitado, suele ser suficiente para la operación del módulo en todos
los protocolos que soporta. No hay una ROM programable en el IC, por lo tanto, el
programa de usuario debe ser almacenado en una memoria Flash externa por SPI la cual va
integrada al módulo. El tamaño final depende de la Flash instalada, sin embargo, el
direccionamiento no soporta memorias mayores de 16 Mb.

46
 Tabla 3. Entrada de corriente al módulo ESP8266-01 de acuerdo a los modos de operación.
Modo Típico Unidades
4
Transmitir 802.11b, DSSS 1 Mbps, POUT=+19.5 dbm 215 mA
Transmitir 802.11b, CCK511Mbps,POUT=+18.5 dbm 197 mA
Transmitir 802.11b, OFDM6 54 Mbps, POUT=+16 dbm 145 mA
Transmitir 802.11n, MCS77 POUT=+14 dbm 135 mA
Recibir 802.11 b, Tamaño de paquete =1024 byte, -80 dbm 60 mA
Recibir 802.11 g, Tamaño de paquete=1024 byte, -70 dbm 60 mA
Recibir 802.11n, Tamaño de paquete=1024 byte, -65 dbm 62 mA
Modem Dormido 15 mA
Sueño ligero 0.5 mA
Modo de ahorro de energía DTIM8 1 1.2 mA
Modo de ahorro de energía DTIM 2 0.9 mA
Sueño profundo (RTC) 10 uA
Apagado total 0.5 uA

4.3.4. PUERTOS DE COMUNICACIÓN.

Los puertos de comunicación que vienen integrados en el chip ESP8266EX para su uso son
los siguientes:

UART9:Las transferencias de datos desde y hacia las dos interfaces UART se pueden
implementar a través de hardware. La velocidad de transmisión de datos a través de UART

4
DSSS: Espectro ensanchado por secuencia directa (Direct Sequence Spread Spectrum), conocido en
comunicaciones móviles como DS-CDMA (acceso múltiple por división de código en secuencia directa), es
uno de los métodos de codificación de canal (previa a la modulación) en espectro ensanchado para
transmisión de señales digitales sobre ondas electromagnéticas que más se utiliza.
5
CCK: Código complementario Keyinges una modulación utilizada con redes inalámbricas (WLAN) que se
emplean en el IEEE 802.11b. En 1999, se adoptó la CCK para complementar el código Barker en las redes
digitales inalámbricas para lograr mayor velocidad de datos de 2 Mbit/s,a expensas de distancias más cortas.
6
OFDM: Multiplexación por División de Frecuencias Ortogonales (Orthogonal Frequency Division
Multiplexing), es una técnica de transmisión que consiste en la multiplexación de un conjunto de ondas
portadoras de diferentes frecuencias, donde cada una transporta información, la cual es modulada en QAM o
en PSK.
7
MCS: Esquema de Modulación y Codificación (Modulation and Coding Scheme). El estándar 802.11n
define un total de 77 MCS. Cada MCS es una combinación de una modulación determinada (por ejemplo,
BPSK, QPSK, 64-QAM), la tasa de codificación (por ejemplo, 1/2, 3/4), el intervalo de guarda (800ns o
400ns) y el número de secuencias espaciales. Todos los puntos de acceso 802.11n deben soportar (como
mínimo) desde MCS0 hasta MCS15 y los clientes 802.11n desde MCS0 hasta MCS7.
8
DTIM: Delivery Traffic Indication Message, es una indicación del tráfico de mensajes que informa a los
clientes sobre la presencia de buffer y/o datos del multicanal en el punto de acceso. Se genera dentro de la
almenara periódica (paquetes enviados por un punto de acceso para sincronizar la red inalámbrica) a una
frecuencia especificada por el DTIM.

47
puede alcanzar 115200 baudios (4.5Mbps). El puerto UART0 puede ser usado para
comunicación de otros dispositivos, este es compatible con el control de flujo. UART1
cuenta con una única señal de transmisión de datos (Tx), que se utiliza generalmente para la
grabación del registro. Por defecto, UART0 mostrará información almacenada en el buffer
cuando el dispositivo está encendido y se está iniciando. La velocidad de transmisión de la
información grabada está estrechamente relacionada con la frecuencia del oscilador de
cristal externo. Si la frecuencia del oscilador de cristal es de 40 MHz, entonces la velocidad
de transmisión es de 115.200 baudios; si la frecuencia del oscilador de cristal es de 26MHz,
entonces la velocidad de transmisión es de 74880 baudios. Si la información almacenada no
ejerce ninguna influencia en la funcionalidad del dispositivo, es mejor bloquear el
almacenamiento durante el periodo de cambio de encendido de los pines U0TXD, U0RXD
a MTDO, MTCK.

I2S10: Hay disponible una interfaz de entrada y una de salida de datos I2S, esta se usa
principalmente en aplicaciones como la recopilación de datos, procesamiento y transmisión
de datos de audio, así como la entrada y salida de datos en serie. La funcionalidad I2S se
puede aprovechar mediante programación de software, los GPIOs que se utilizarán se
multiplexan.

I2C11:ElESP8266EX posee 3 puertos I2C:Un maestro/esclavo de propósito general, un

esclavo SDIO/SPI, y un maestro/esclavo de propósito general HSPI. Las funciones de los
pines correspondientes se pueden implementar a través de hardware. Los puertos SPI
pueden ser activados a través de la programación de software. La frecuencia de reloj puede
alcanzar hasta un valor máximo de 80MHz, sin embargo, no existe una lista DMA (Direct
Memory Access) vinculada al SPI de propósito general y al HSPI, por lo que los gastos de
software son más grandes, y en consecuencia, la velocidad de transmisión de datos se verá
limitada por la velocidad de procesamiento de software.

4.3.5. MODO DE FUNCIONAMIENTO.

En la figura 4 se muestra la asignación de pines del módulo ESP8266-01. La configuración

es muy simple, siendo únicamente necesarios los pines de polarización y de comunicación
con el puerto UART.
9
UART: Transmisor-Receptor Asíncrono Universal (Universal Asynchronous Receiver-Transmitter), es el
dispositivo que controla los puertos y dispositivos serie. Comúnmente se encuentra integrado en la placa base
o en la tarjeta adaptadora del dispositivo. Las señales externas pueden ser de variada índole. Ejemplos de
estándares para señalización por voltaje son RS-232, RS-422 y RS-485.
10
I2S: Sound, Integrated Interchip Sound (también llamado Inter-IC o IIS) Es un estándar eléctrico de bus
serial usado para interconectar circuitos de audio digital.1 El bus I2S separa las señales de datos y de reloj, lo
que resulta en menores fluctuaciones de la señal que en sistemas que recuperan el reloj de la señal de datos.
11
I2C: Inter-Integrated Circuit, es un bus de datos serial desarrollado en 1982 por Philips Semiconductors
(hoy NXP). Se utiliza principalmente internamente para la comunicación entre diferentes partes de un
circuito, por ejemplo, entre un controlador y circuitos periféricos integrados. El sistema original fue
desarrollado por Philips a principios de 1980 con el fin de controlar varios chips en televisores de manera
sencilla.

48
El ESP8266-01 posee dos modos de operación principal determinados por el estado del pin
GPIO0:

Modo de operación normal: Inicia la ejecución ordinaria del Firmware que tiene
almacenada la Flash (GPIO0 en ALTO).
Modo de grabación de firmware: Dispone al módulo para recibir un nuevo Firmware que
se almacena en la memoria Flash (GPIO0 en BAJO).

Figura 4. Asignación de pines del ESP8266-01.

El cualquiera de los dos casos el pin CH_PD deberá estar en ALTO para mantener el chip
activo. CH_PD en BAJO coloca al módulo en modo de bajo consumo de energía.

4.3.6. ACTUALIZACIÓN DEL FIRMWARE

El firmware se carga desde el chip FLASH del módulo y la SRAM inicia las instrucciones
durante el arranque, a través de la interfaz SDIO12. El firmware implementa la pila TCP/IP,
las funciones requeridas para cumplir el estándar 802.11 b/g/n/e/i, el protocolo MAC de
WLAN y la especificación directa de Wi-Fi. Admite operaciones de un conjunto de
servicios básicos (BSS) en virtud de la función de control distribuido (DCF), al igual que el
funcionamiento de servicios P2P compatible el protocolo WiFi P2P. Otras funciones de
protocolo de bajo nivel son manejadas automáticamente por el chip ESP8266EX como son:

• RTS/CTS
• Acuse de recibo (acknowledgement).
• Fragmentación y desfragmentación.
• Agregación.
• Marco de encapsulación (802.11h/RFC 1042)
• monitoreo/escaneo automático de baliza
• Wi-Fi directa P2P

12
SDIO: Interfaz de tarjeta Secure Digital, formato definido para tarjetas de memoria no volátil elaborado por
la Asociación de Tarjetas SD (SDA) para su uso en dispositivos portátiles.

49
La exploración pasiva o activa, así como el procedimiento de descubrimiento P2P se lleva a
cabo de forma autónoma una vez iniciados por el comando apropiado. La administración de
energía se maneja con interacción mínima del firmware para minimizar el período de
servicio activo.

Figura 5. ESP8266-01 en modo flash (GPIO0 en GND) conectado a un PC mediante un conversor USB a
serial.

La actualización del firmware es un paso previo necesario para lograr un mejor provecho de
las capacidades del módulo. Comercialmente los módulos vienen cargados con una versión
beta de capacidades muy limitadas, por lo que es necesario subir a la FLASH una versión
más reciente. Para este proyecto hemos trabajado con la versión 0.9.5 liberada el 25 de
diciembre de 2014.

Para actualizar el firmware del ESP8266-01 se realiza en los siguientes pasos:

1. Descargar del software ESP8266-Flasher13 .

2. Se descarga la versión del firmware para comandos AT (versión 0.9.5).
3. Colocar el esp8266 en modo flash con el GPIO0 en BAJO (figura 5).
4. Abrir el software ESP8266-Flasher, hacer clic en Bin y seleccionar el archivo del
firmware descargado, seleccionar luego el número de puerto COM utilizado por la
PC. (figura 6 a).
5. Pulsar el botón Download. El software primeramente borra el antiguo firmware y
después escribirá el nuevo (figura 6 b).

Figura 6. Escritura del nuevo firmware del ESP8266-01. a) Selección del archivo y el puerto de
comunicación.

13
Se usó el flasher disponible en http://esp8266.ru/downloads/esp8266-firmware/#wpfb-cat-2

50
Figura 6. Escritura del nuevo firmware del ESP8266-01. b) Proceso de grabación concluido.

4.3.7 COMANDOS AT PARA EL ESP8266.

Los comandos AT14 son una serie de instrucciones codificadas que conforman un lenguaje
de comunicación entre un usuario y un terminal modem. El método de comunicación que
suministra el firmware del ESP8266 consiste en un set de comandos AT específico para
poder acceder a las funcionalidades propias del módulo. Esta comunicación se basa en un
procedimiento de petición-respuesta/error donde toda petición se antecede con la
combinación “AT” (en mayúsculas) de la siguiente manera:

AT+COMANDO<CR>

El símbolo más (+) separa el encabezado de la petición del comando específico. En la

actualidad casi la totalidad de comandos para módems y otras terminales se escriben en
Mayúsculas. Al final se pone una etiqueta de terminación que corresponde a un retorno de
carro (CR, ASCII número 13). Una vez la terminal ha interpretado la petición, esta
responderá de acuerdo al comando suministrado:

<CR><LF>RESPUESTA AL COMANDO<CR><LF>

La respuesta viene enmarcada entre dos caracteres que indican el inicio y fin de la
secuencia, un retorno de carro y un salto de línea (LF, ASCII número 10). En caso que la
petición no se encuentre en el set de comandos o presente algún problema en la sintaxis, la
terminal responderá con la palabra ERROR:
14
El conjunto de comandos Hayes es un lenguaje desarrollado originalmente en 1977 por la compañía Hayes
Communications que prácticamente se convirtió en estándar abierto de comandos para configurar y
parametrizar módems. Los caracteres «AT», que preceden a todos los comandos, significan «Atención», e
hicieron que se conociera también a este conjunto de comandos como comandos AT.

51
 <CR><LF>ERROR<CR><LF>

Espressif publica periódicamente actualizaciones del set de comandos AT conforme a las

nuevas versiones de firmware disponibles. Para ver el listado completo de comandos se
puede consultar en la página del fabricante15.

4.3.7.1. COMANDOS UTILIZADOS.

A continuación se listan y explican las funciones que se han usado para la implementación
específica de este proyecto:

4.3.7.1.1. Comandos básicos:

AT+RST: Reinicio del módulo. Al ejecutarse este comando la rutina principal del firmware
se reinicia restableciendo todos los procedimientos a su estado inicial. Es equivalente a
efectuar un RESET por hardware (llevando el pin RST del ESP8266-01 a un nivel BAJO).
Al iniciar el procedimiento de reinicio retorna "OK" por la terminal. Para la versión 0.9.5,
el fin del cargue del firmware se indica con la palabra "ready" (minúscula) momento en el
cual la terminal está en espera de nuevos comandos AT.

AT+GSLP=<tiempo>: Coloca al módulo en el modo de sueño profundo (consumo de

corriente de 10 µA). <tiempo> es el periodo de espera en milisegundos antes de iniciar el
procedimiento de apagado. Retorna el valor de tiempo establecido seguido de un "OK."
Para despertar el módulo es necesario efectuar un RESET por hardware.

4.3.7.1.2. Comandos de Wi-Fi.

AT+CWMODE=<modo>: Establece la operación Wi-Fi del módulo en alguno de los

siguientes modos (establecidos en <modo>):1: modo estación,2: modo AP, 3:modo
Estación y AP combinados. Retorna "OK" por la terminal luego de establecido el modo.

AT+CWJAP=<ssid>,<pwd>: Establece el punto de acceso (AP) al que se conectará el

dispositivo. Parámetros:

<ssid>: Cadena de caracteres correspondiente al SSID al cual se conecta.

<pwd>: Cadena de máximo 64 bytes correspondiente a la contraseña de la red.

Una vez ejecutado retorna "OK" si la conexión es exitosa o "ERROR" en caso de que
fallase la conexión.

AT+CWLAP: Lista los puntos de acceso disponibles en el entorno del dispositivo. La

respuesta posee la siguiente estructura:

15
Listado disponible en http://www.espressif.com/sites/default/files/4b-
esp8266_at_command_examples_en_v1.3.pdf

52
 +CWLAP: <ecn>,<ssid>,<rssi>,<mac>
donde:

<ecn>: Corresponde al tipo de encriptación de red.

0 OPEN, 1 WEP, 2 WPA_PSK, 3 WPA2_PSK,4 WPA_WPA2_PSK

<SSID>: Cadena de caracteres correspondiente al nombre de la red

<RSSI>: Cadena de caracteres correspondiente a la Intensidad de la señal
<MAC>: Cadena de caracteres correspondiente a la dirección MAC del AP

Al final del listado muestra "OK" o "ERROR" en caso de presentarse algún problema en la
búsqueda.

4.3.7.1.3. Comandos TCP IP.

AT+CIPMUX=<modo>: Establece múltiples conexiones. <modo> determina el tipo de

conexión ( 0 Conexión simple,1 Múltiples conexiones). El comando devuelve "OK" si el
parámetro se ha establecido, retorna "Link is builded" si ya se encuentra conectado. Este
modo sólo se puede cambiar después de que todas las conexiones están desconectadas. Si
ya se ha iniciado el servidor, será necesario reiniciar el sistema.

AT+CIPMODE=<modo>: Establece el modo de transferencia de datos. <modo> indica:

0: Modo normal, se debe establecer siempre la longitud del tamaño de los paquetes
enviados.
1: Modo de transmisión inconcluso, no se establece el tamaño de los paquetes
enviados

AT+CIPSEND: Configura la longitud de los datos que serán enviados por el puerto TCP o
UDP.
1) Para la conexión individual (previo AT+CIPMUX=0): AT+CIPSEND=<longitud>
2) Para la conexión múltiple (previo (AT+CIPMUX=1)):
AT+CIPSEND=<id>,<longitud>
3) para la conexión con envío de datos de longitud inconclusa (o permanente):
AT+CIPSEND

Donde:
<id>: Es el número de Id de la conexión por la cual se hace la transmisión
<longitud>: Número de caracteres que se enviarán, el ESP8266 soporta un envío
simultáneo máximo de 2048 bytes por paquete.

Tras la ejecución del comando, la terminal retorna el caracter de envoltura (wrap) ">" a
continuación se escriben los datos de la serie. Cuando se cumpla la longitud de los datos
establecida, se inicia la transmisión. Si se ha establecido en envío inconcluso, después de
ejecutar el comando entra en la transmisión permanente, se efectuará el envío de cada
paquete en un intervalo de 20ms a un tamaño máximo de 2048 bytes por paquete. Cuando
se coloca en la terminal un paquete que contiene únicamente la combinación "+++", se
53
vuelve al modo de comando. Este comando sólo se puede utilizar en el modo de
transmisión inconclusa donde se requiere que sea el único modo de conexión. Si no se
puede establecer conexión o se desconecta durante el envío, devuelve "ERROR" Si los
datos se transmiten con éxito, devuelve ""SEND OK"

AT+CIPCLOSE: Cierra una conexión de tipo TCP o UDP. Cuando existen múltiples
conexiones esta se debe establecer como AT+CIPCLOSE=<id>, donde <id> es el número
de la conexión a cerrar. Cuando id=5, se cierran todas las conexiones (El ESP8266 sólo
puede manejar 4 conexiones simultaneas en modo AP).

AT+CIFSR: Obtiene la dirección IP local. La respuesta posee la siguiente estructura:

+CIFSR:<dirección IP 1>: donde dirección IP 1 corresponde a la IP en modo AP.
+CIFSR:<dirección IP 2>: donde dirección IP 2 corresponde a la IP en modo
estación.

Al final de la respuesta devuelve "OK" o "ERROR" de presentarse alguna inconsistencia.

AT+CIPSERVER=<modo>,[<puerto>]: Configura un servidor TCP.

<modo>: Acción a efectuar en el servidor.
0 Eliminar el servidor (a continuación se debe reiniciar el módulo).
1 Crear servidor.
<puerto>: Número de puerto. Si no se establece, por defecto será el puerto 333.

Retorna "OK" una vez se ha efectuado la operación.

4.4. CONCLUSIONES.

Al utilizar el ESP8266-01 se encuentran ventajas como su fácil uso, gran cantidad de

información y material de ayuda en la web, pero especialmente el ser muy económico.
Entre las desventajas del ESP8266-01 se encuentran que en modo AP, para asociar el
dispositivo con el router, se presentan inconvenientes de conexión al tratar de comunicarse
desde la página web al dispositivo dado el tratamiento limitado que tiene de los paquetes
enviados hacia el usuario. La versión del firmware instalada es la 0.9.5 que permite el
control mediante comandos AT conectando un MCU externo. El consumo de energía en
transmisión del ESP8266 es importante por lo que es necesaria una fuente que proporcione
unos 250mA como mínimo. Además si se le agregan los componentes pasivos y activos
de los dispositivos externos como MCU, chips de medición, sensores la fuente tendría que
proporcionar unos 400mA con un voltaje de alimentación que no exceda los 3.6 v.

54
 5. INTEGRACIÓN DE ELEMENTOS Y ELABORACIÓN DE OBJETOS IoT.

5.1. ESQUEMA GENERAL.

En la figura 1 se muestra el esquema general de los objetos IoT propuestos. Los bloques
identifican cada uno de los componentes principales del dispositivo (sea para medición de
consumo de energía eléctrica o de agua). Los componentes principales de los dispositivos
de medición son los siguientes:

Dispositivo de conexión de red: Es el módulo encargado establecer las conexiones de red

inalámbricas a través de Wi-Fi, así como de hacer el envío y recepción de datos.
Corresponde al módulo ESP8266-01 el cual se ha detallado en el capítulo 4. La
comunicación a la terminal se efectúa a través de un puerto compatible con UART
configurado a una velocidad de 115200 baudios (la más alta soportada por el ESP8266).

Dispositivo sensor de variables: Es el encargado de hacer las mediciones de las variables

de interés en cada uno de los dispositivos. Para el caso del dispositivo de medición de agua
corresponde a un contador con sensor de efecto Hall de media pulgada para tuberías de uso
doméstico, este genera un tren de pulsos equivalente al flujo pasante de agua en un
intervalo de tiempo (Sección 2.1). Los pulsos son contabilizados determinando las
variaciones de voltaje en una entrada del microcontrolador conectada a la salida del sensor
de efecto hall, internamente un timer evalúa el estado de dicha entrada cada milisegundo.

Figura 1. Esquema de bloques del dispositivo de medición.

Para el caso de la medición de parámetros eléctricos, el dispositivo sensor de variables es el

circuito integrado ADE7753 el cual tiene la capacidad de hacer la medición de los

55
parámetros eléctricos de una línea monofásica. En el diseño efectuado se miden únicamente
los parámetros de voltaje RMS, corriente RMS y potencia real. A partir de estos datos se
obtiene una medición básica de la energía eléctrica que es consumida por la carga
conectada al objeto IoT. La conexión entre el ADE7753 y el microcontrolador se efectúa
mediante un puerto de comunicaciones SPI, los datos que se envían y se reciben dependen
de la estructura definida por el fabricante en la hoja de datos del dispositivo como se
encuentra descrita en el capítulo 3.

Microcontrolador: El componente central es el microcontrolador, quien efectúa todos los

procesos de control de la medición así como la transmisión y recepción de datos a través
del dispositivo de conexión inalámbrica. Para este proyecto se ha trabajado con dos
microcontroladores de la familia Coldfire V1 de Freescale (hoy NXP), el MCF51JM128-
VLH para el dispositivo de medición de parámetros eléctricos y el MCF51JM128-VLH
para el dispositivo de medición de consumo de agua.

Memoria: Se ha utilizado una pequeña memoria EEPROM 24LC512 la cual se comunica

con el microcontrolador a través de un puerto I2C. La memoria integrada a cada uno de los
objetos IoT cumple tres propósitos:

- Es la encargada de almacenar el código HTML que el servidor web local que utiliza
en el modo de configuración (AP).
- Almacena los parámetros de configuración necesarios para realizar la conexión a la
red.
- Guarda aquellos datos que son recopilados por los sensores pero que no pueden ser
enviados debido a algún evento de desconexión con lo cual se garantiza que la
medición no se pierde si el dispositivo no se encuentra conectado a la red o al
servidor por diversas circunstancias.

Pines de I/O: Cada uno de los dispositivos de medición cuenta con una serie de pines de
entrada y salida destinados a diversos propósitos, entre ellos efectuar la programación del
microcontrolador y de la memoria EEPROM, hacer monitoreo del comportamiento de la
comunicación entre los dispositivos en los modos de desarrollo, efectuar reset por hardware
al microcontrolador y al dispositivo de conexión de red, entre otros. El detalle de estas
conexiones depende de cada uno de los tipos de dispositivo (agua o eléctrico).

Fuente de energía: El sistema de obtención de energía para el funcionamiento del objeto

IoT es el que tiene más variaciones entre el dispositivo de medición de consumo de agua y
el energía eléctrica. Mientras que en el dispositivo de medición de agua la fuente de energía
es una batería de litio de 3.7 V, el dispositivo de medición eléctrico utiliza una pequeña
fuente conmutada, completamente aislada, con una salida de voltaje de 9 voltios capaz de
suministrar una corriente de hasta 450 mA (el consumo máximo del ESP8266 es de 250
mA). Dicha fuente se ha adquirido específicamente para este proyecto.

56
 5.2. CARACTERÍSTICAS DEL MICROCONTROLADOR.

Los Microcontroladores seleccionados se han elegido por ser estos los que se conocían con
más detalle por ser usados en aplicaciones anteriores. Ambos Microcontroladores poseen en
un núcleo ColdFire V1 el cual está diseñado para aplicaciones de 32 bits, el núcleo V1 es
una versión simplificada del núcleo ColdFire V2. La familia MFC51 está pensada como un
“eslabón” entre los Microcontroladores de 8 bits y 32 bits de Freescale. El manejo de las
operaciones de byte (8 bits) y de palabra (16 bits) mantiene los modos de direccionamiento
y las definiciones de instrucciones de la arquitectura ColdFire. Al realizar las funciones de
multiplicar-acumular (MAC), incremento de acumulado (EMAC) y dividir (DIV), se
minimizar los costos en aplicaciones que no requieren un rendimiento de procesamiento
mejorado.

Los detalles de ambos Microcontroladores se encuentran detallados en la amplia

documentación que existe al respecto y en las hojas de datos de los mismos [38][39]. En la
tabla 1 se muestran los datos más relevantes de estos dispositivos para el presente proyecto.
Ambos Microcontroladores poseen, entre otras características, suficientes puertos de
comunicación para realizar las diversas conexiones a los periféricos propios del objeto IoT,
bajo consumo de energía, velocidad de reloj de hasta 51 MHz. La programación se realizó
usando CodeWarrior que es la herramienta que brinda NXP para el desarrollo medio y
profesional de aplicaciones sobre sus Microcontroladores.

Tabla 1. Características generales de los Microcontroladores usados en el proyecto

Características MCF51JM128 MCF51QE128
Núcleo V1 ColdFire V1 ColdFire
Voltaje 5v 3,3v
Corriente (máx) 100 mA 100 mA
Memoria Flash 128 KB 128 KB
RAM 16 KB 8 KB
I²C 2 2
SPI 2 2
canales ADC 12 20
SCI 2 2
PIN I/O 54 54
RGPIO 16 6
Encapsulado LQFP 64 LQFP 64

57
 5.3. CARACTERÍSTICAS DE LA MEMORIA.

La memoria EEPROM usada en los objetos IoT propuestos es la conocida 24LC512 de

Microchip. Esta memoria usa un puerto I2C para la comunicación con el dispositivo y 4
pines de direccionamiento que permiten conectar hasta ocho dispositivos en el mismo bus.
Es capaz de operar a través de un rango de voltaje de 1,7 V a 5,5 V. Se caracteriza por su
bajo consumo (1 µA en reposo) ideal para aplicaciones en comunicaciones y adquisición de
datos. El paginado tiene una de capacidad de escritura de hasta 128 bytes de datos. Se
pueden almacenar datos de formar secuencial o aleatoria hasta alcanzar su máxima
capacidad de 512 Kb. La velocidad de bus se puede establecer en diferentes velocidades de
reloj hasta un máximo de 400 KHz la cual es la usada en este proyecto. Los detalles de las
tramas de datos para la lectura/escritura se pueden ver en la hoja de datos del fabricante
[40].

Figura 2. Mapa de asignación de memoria de la EEPROM para los objetos IoT propuestos.

En la figura 2 se muestra el mapa de memoria de la EEPROM, esta segmentación es

necesaria para mantener ordenada la ubicación de los datos necesarios para la conexión a la
red y el almacenamiento de mediciones no enviadas. Cinco bloques completan las
funciones de la memoria de la siguiente manera:

58
Inicio: Es la dirección 0x0000 de la memoria que es usada como un check-point para la
lectura escritura de le EEPROM.
Configuración de dispositivo: Almacena los datos necesarios para la conexión a la red Wi-
Fi y el servidor de datos.
Almacenamiento local de medición: Los datos de la medición actual se almacenan
temporalmente en esta sección de la EEPROM. En caso de que los datos no puedan ser
enviados hacía el servidor, si la pérdida de conexión es definitiva, se crea un registro de
evento acumulado a partir de estos datos que se almacena en el bloque de memoria
designado para ello.
HTML local de Access Point: Este bloque está destinado para almacenar el código que se
ejecuta cuando el objeto IoT se encuentra en el modo de configuración de red. El ESP8266
se comparta como un punto de acceso de red con un servidor local en escucha del puerto
80. El código que se envía desde HTTP al recibir solicitudes de cliente está almacenado en
este segmento.
Almacenamiento de eventos: Este segmento de memoria está destinado a almacenar los
eventos de consumo que no se puedan enviar al servidor en caso de presentarse algún fallo
en la cadena de conexión al servidor (fallo del Websocket, del servidor, del acceso de red,
entre otros). Estos se denominarán en adelante registros sin indexar a la base de datos o
abreviadamente RSI

5.4. INTEGRACIÓN DE ELEMENTOS DEL HARDWARE.

5.4.1 DISPOSITIVO DE MEDICIÓN DE CONSUMO DE AGUA.

El objeto IoT propuesto para la medición consumo de agua es un módulo de dimensiones

6x5.5x4 cms (Este espacio comprende el tamaño del sensor 6x3.5x3.5 cms y la caja
protectora de la electrónica 6x2x4 cms), este se debe acoplar a la tubería de la llave o
dispositivo a censar (tubería de ½ pulgada), El dispositivo contiene cada uno de los
componentes descritos en la sección 5.1. La figura 3 corresponde al plano de circuito del
dispositivo sin incluir la batería. Los elementos que completan el circuito incluyen los
jumpers de configuración, el interruptor para establecer el modo normal/AP, el puerto
BDM para la programación del microcontrolador, el socket para las conexión del sensor de
efecto Hall, capacitores para filtrar espurios de alta frecuencia y divisores resistivos para los
acoples de los puertos I2C y Serie necesarios para las configuraciones previas a la
operación normal.

59
 Figura 3. Plano del circuito del dispositivo de medición de consumo de agua.

5.4.2 DISPOSITIVO DE MEDICIÓN DE CONSUMO DE ENERGÍA ELÉCTRICA.

El objeto IoT propuesto para la medición de parámetros de consumo eléctrico es un módulo

de dimensiones 10x4.5x4.5 cms, este se conectará en una terminal eléctrica monofásica
haciendo un “puente” entre la toma y el electrodoméstico a conectar, semejante a cómo se
conectan dispositivos como los protectores de voltaje, de los cuales se ha tomado la carcasa
protectora de un modelo para poder efectuar las pruebas y evitar el contacto con la
electrónica. El dispositivo contiene cada uno de los componentes descritos en la sección
5.1. La figura 4 corresponde al plano de circuito del dispositivo sin incluir la fuente
conmutada. Los valores resistivos para la medición de voltaje y corriente se definieron en
las secciones 3.6.2.1 y 3.6.2.2 Los elementos que completan el circuito incluyen los
jumpers de configuración, el interruptor para establecer el modo normal/AP, el puerto
BDM para la programación del microcontrolador, los socket para las conexiones de las
terminales AC, un par de LEDs para indicar el estado de la operación, un pulsador para
activar/ desactivar la carga (ON/OFF), capacitores para filtrar espurios de alta frecuencia y
divisores resistivos para los acoples de los puertos I2C y UART.

60
61
 5.4.2.1. Acople de tierras del circuito de medición eléctrico.

Uno de los puntos más relevantes en la elaboración del circuito de medición de energía
eléctrica es el acople de la tierra digital del circuito de control y medición con la tierra de la
línea AC (neutro, de verde en la figura 5). Dado que la medición de voltaje se efectúa a
través de un divisor resistivo directamente conectado a la línea AC (R1 y R2) existe un
punto de referencia común entre la línea AC y el circuito en DC. En necesario hacer
consideraciones en varias etapas del circuito para efectuar este acople de manera correcta.
La fuente de alimentación usa un circuito conmutado para hacer la transmisión de energía
desde la parte caliente (AC) hacía la parte fría de la misma (bloque 1), comúnmente un
circuito de realimentación existe entre ambas partes, integrando algunos elementos con
impedancias relativamente altas (optoacopladores, capacitores), sin embargo el diseño no
soporta una realimentación directa pues altera el conmutador. Al estar completamente
aisladas ambas etapas se evita dicho problema, a cambio el voltaje de salida puede tener
fluctuaciones mayores a las de un circuito conmutado con realimentación completa por lo
que es necesario incluir reguladores de voltaje (bloques 2 y 3) para estabilizar los valores
de voltaje DC requeridos para la alimentación del circuito digital.

El sensor de corriente ACS714 (bloque 6) posee una alimentación DC y se encuentra

acoplado a la línea AC a través de los pines para la circulación del campo eléctrico para el
sensor de efecto hall, la tierra digital debe presentar un potencial cero respecto a los pines
de medición de AC ya que de otro modo el circuito podría destruirse (el circuito está
diseñado para aislar voltajes DC de hasta 5000 V pero no voltajes en AC) de modo que el
sensor debe ubicarse en serie con el neutro del sistema AC. Una condición semejante se
presenta con el circuito de disparo de la carga (bloque 7) el cual debe igualmente estar
referenciado al mismo nodo neutro. El ADE7753 y el microcontrolador reciben las señales
analógicas de la medición de voltaje y corriente (nodo azul y rojo), por lo que el nodo que
conecta ambas referencias (bloque 9) debe estar correctamente conectado al nodo neutro de
AC. Esta conexión implica que no existe aislamiento eléctrico entre las etapas digitales y le
línea, por lo que es fundamental que toda la electrónica esté debidamente protegida dentro
de una coraza de materia aislante a fin de evitar descargas eléctricas peligrosas para las
personas y el circuito en sí.

Figura 5. Esquema en bloques del circuito de medición de parámetros eléctricos (1: Circuito de conmutación
de la fuente, 2: Regulador de 3.3 V, 3: Regulador de 5V, 4: ESP8266, 5: Circuito digital de medición y
control, 6: Sensor de corriente ACS714, 7: Circuito de disparo de la carga, 8: Carga AC, 9: Acople de tierras).

62
 5.5. PROGRAMACION: MODOS DE OPERACIÓN.

Los modos de operación son el resultado de la ejecución del firmware propio del objeto IoT
el cual se ha diseñado para dar utilidad al dispositivo, y que se encuentra segmentado de
acuerdo a los bloques componentes en: Programación del microcontrolador, programación
firmware del dispositivo ESP8266, y el código HTML del servidor local en el modo AP.

Figura 6. Flujo que establece el modo de operación del dispositivo.

Cada objeto IoT posee cuatro modos de operación de acuerdo a los procedimientos que se
deben efectuar para la configuración y la puesta a punto (figura 6). Al encenderse el
dispositivo lo primero que hace es evaluar los pines de entrada y salida que determinan el
modo de operación (jumpers de las figuras 3 y 4), una vez determinado se inicia la rutina
dedicada a cada función particular:

Grabar firmware: Este modo se establece mediante un jumper incluido en la placa PCB. El
ESP8266 contiene internamente un firmware el cual debe ser actualizado a una versión
posterior a la que viene de fábrica (sección 4.3.6) por lo que este proceso es indispensable
para poner a punto la operación de los comandos AT que se han usado en esta
implementación. Existen versiones posteriores del firmware del fabricante, así como
versiones desarrolladas de forma independiente por grupos de aficionados e ingenieros en
la plataforma LUA16, por lo cual se deja abierta la posibilidad de hacer implementaciones
basadas en estos desarrollos aprovechando el mismo hardware que se ha diseñado para este
proyecto. En este modo, el puerto serial del microcontrolador que se encuentra conectado al
ESP8266 se deshabilita, mediante un jumper se conectan el Rx y el Tx del ESP8266 a un
Tx y Rx externos conectados a un circuito que convierta las señales UART al estándar
RS232 o USB (por ejemplo el FT232) para comunicarlas de este modo a un PC quien
enviará los datos del nuevo firmware que se alojará en la EEPROM que trae la placa
ESP8266-01.

Grabar memoria EEPROM: Otra tarea indispensable para la puesta a punto del dispositivo
es almacenar en la memoria EEPROM los datos del código HTML para el servidor local,
así como los parámetros iniciales para la configuración de red. Para grabar un nuevo bloque
16
Lua es un lenguaje de programación ligero multi-plataforma para sistemas embebidos, está escrito en ANSI
C y tiene una API simple igualmente escrita en lenguaje C.

63
de código HTML en la memoria es necesario colocar el dispositivo en este modo mediante
un jumper. Al reiniciar el dispositivo y encontrar que el jumper se encuentra establecido, el
microcontrolador inicia una rutina en la cual espera un saludo inicial proveniente desde el
puerto serial destinado específicamente para este propósito. Como antes, a este puerto se
debe conectar de forma externa a un circuito que convierta la señal serial en RS232 o USB
para conectarlas seguidamente a un PC como se muestra en la figura 7. El saludo inicial y
la posterior transmisión de datos se efectúan a través de la aplicación llamada “quemador
de memorias EEPROM” que se ha diseñado específicamente para esta tarea y de la cual se
muestran detalles en la sección 9.4.

Figura 7. Esquema de conexión para el quemador de EEPROM.

Modo AP (Access Point): Este modo se usa para realizar la configuración necesaria para
conectar un nuevo objeto IoT a la red Wi-Fi del lugar en el cual se va instalar el mismo. El
ESP8266 brinda la posibilidad de acceder a éste como si fuese un punto de acceso de red
(AP). Se aprovechó esta característica para crear un mini-servidor local que brinde la
posibilidad de configurar los parámetros de operación normal de la red (SSID, contraseña,
IP de servidor, entre otras) que son indispensables para el funcionamiento del dispositivo.
El PCB posee un interruptor en el cual se puede establecer el modo AP. Al reiniciarse el
dispositivo y encontrarse en AP (con cada jumper de los estados anteriores en posición de
reposo) el microcontrolador inicia la rutina del modo de punto de acceso. Un dispositivo
cliente (teléfono celular, PDA, tablet, PC, entre otros) se conecta a la red Wi-Fi creada por
el ESP8266 y usando un navegador web se accede al servidor local digitando la dirección
IP 192.168.4.1 (que es la que trae por defecto este dispositivo) o la que haya sido
configurada previamente en el firmware. El microcontrolador lleva a cabo un análisis de los
datos que ingresan por el puerto desde el dispositivo ESP8266 y controla el flujo de los
datos. Para salir de este modo se debe mover el interruptor que trae la placa a su posición
de operación normal.

Modo normal: Es aquella en la cual se han configurado todos los parámetros de conexión,
de modo que se garantiza el envío de datos de medición así como la recepción de avisos y
alertas desde el servidor web. Una vez verificado que el interruptor se encuentran modo
normal y que los jumpers de los anteriores modos de operación se encuentran en estado de
reposo, el microcontrolador inicia la rutina de estado normal. La aplicación utiliza los datos
almacenados en la memoria EEPROM para conectarse la red Wi-Fi local y establecer
seguidamente una conexión web al servidor que tiene asociado y a quien se le efectuará el
envío los datos de medición. En caso de no existir una configuración de conexión de red (es
decir que se ha omitido la configuración en modo AP) el dispositivo iniciará

64
automáticamente el modo AP; por el contrario, si la configuración existe pero no es posible
el acceso de red o el acceso al servidor, el dispositivo almacenará las mediciones de forma
local hasta el momento en que se restablezca la conexión y pueda hacer efectivo el envío de
datos.

Estado de error: El microcontrolador efectúa una serie de verificaciones previas al inicio

de cualquiera de los modos de operación, si se diera el caso de que no es posible el inicio de
ninguno de los modos de operación, el sistema entrará en un estado de error en el cual no
efectuará ninguna acción de conexión ni tomará ninguna medida de los parámetros en
espera de recibir un reset externo desde el interruptor destinado para ello. De presentarse
este estado de error puede que estén sucediendo problemas con el hardware (la memoria
EEPROM no funcione o no esté conectada, el ESP8266 se encuentre en mal estado o no
esté conectado, existan problemas en los puertos, entre otros).

5.5.1 SECUENCIA DE ARRANQUE DEL DISPOSITIVO.

La secuencia de arranque corresponde a los pasos que siempre efectuará el IC

microcontrolador antes de colocar el dispositivo en alguno de los modos establecidos, se
busca garantizar que la memoria y el dispositivo de comunicación funcionan
adecuadamente, igualmente que las funciones del microcontrolador se sincronicen con el
estado de la operación (figura 8):

Parámetros de arranque: Se han establecido una serie de valores iniciales que son
necesarios dentro de la programación del microcontrolador para el correcto funcionamiento
de cada uno de los módulos que se conectan a los componentes externos; los valores por
defecto tienen como propósito colocar al dispositivo en un estado que no genere conflictos
previo a la determinación del modo de operación, las condiciones principales son:

- No efectúa mediciones de parámetros.

- Coloca los valores de los contadores de tiempo a cero.
- Coloca los valores de los registros actuales de acumulación de eventos en cero.
- Habilita la comunicación con la memoria EEPROM para lectura y escritura.
- Deshabilita las funciones de recepción de datos desde Websocket

Reset a ESP8266: Seguidamente se efectúa un reset físico al ESP8266 mediante la

conexión que existe entre el pin RST del dispositivo y el pin del microcontrolador dedicado
para este propósito. El microcontrolador espera la respuesta de estado "ready” posterior al
reinicio del dispositivo de comunicación (ver comandos AT en sección 4.3.7.1.1). En caso
de no presentarse esta respuesta generará un nuevo reset hasta que el dispositivo responda.
Si después de un minuto de efectuar intentos de reinicio el ESP8266 no responde
adecuadamente, el objeto IoT entra en un estado de error.

65
Escribir dirección 0 en EEPROM: Para asegurar el correcto intercambio de datos con la
memoria EEPROM se hace un primer ciclo de escritura-lectura en el cual se coloca un dato
en el primer registro de la memoria y seguidamente se lee este mismo valor; con esto se
pretende verificar el correcto funcionamiento de la memoria. Si no fuera posible grabar este
primer registro, se infiere que existe algún problema en la comunicación con la memoria y
el objeto IoT se pone en un estado de error.

Leer parámetros de EEPROM: El microcontrolador lee el bloque de la memoria

correspondiente a la configuración del dispositivo y coloca estos datos en las variables
globales de la RAM.

Pines EEPROM y AP: El microcontrolador lee el estado del pin de entrada del modo
EEPROM, si está en BAJO inicia la rutina de grabación de EEPROM y si no, confirmará si
los datos de configuración de acceso de red (SSID y contraseña) se encuentran
diligenciados, si no, ingresa en modo de punto de acceso (AP).

Modo normal: Si los datos de conexión de red están diligenciados y el jumper de AP está
inactivo, el microcontrolador inicia el ciclo de trabajo normal que depende del tipo de
objeto como se describe más adelante.

Figura 8. Flujo de selección del estado de operación de los objetos IoT diseñados.

A continuación se describen en detalle los tres modos de operación principales.

66
 5.5.2 GRABADOR EEPROM.

El modo de grabado de EEPROM tiene como fin establecer los parámetros iniciales de la
memoria necesarios para el correcto funcionamiento del objeto IoT, por lo tanto
corresponde a un “ajuste de fábrica” que se debe hacer una vez se encuentren ensamblados
todos los componentes electrónicos del dispositivo. Para efectuar la grabación de la
memoria se debe primero efectuar la grabación del programa del microcontrolador a partir
del puerto BDM del mismo, seguidamente se establece a través del jumper del proceso que
el microcontrolador debe iniciar en modo de grabador de memorias; se debe conectar un
conversor serial a RS232 o USB que conecte el objeto a un PC para poder efectuar la
grabación de los datos.

Figura 9. Flujo del proceso de grabación de EEPROM para los objetos IoT diseñados.

El grabador de memorias EEPROM diseñado permite la búsqueda de un archivo que es el

que se almacena en la memoria, para el caso corresponde al archivo HTML del servidor
local. Se selecciona el archivo correspondiente y además se establece la dirección de inicio
a partir de la cual se iniciará la escritura en la memoria. Al abrir el puerto e iniciar la
grabación (figura 9), el programa envía un paquete de datos en forma de saludo hacia el
microcontrolador, este se encontrará esperando dicho saludo (paso=1) seguidamente la
información de la dirección inicial de memoria y el tamaño del archivo a grabar son
enviados (paso=2), luego se inicia la secuencia grabación. Desde el PC se envían las tramas
correspondientes a los datos a grabar las cuales recibe el microcontrolador a través del
puerto serie y se envían como paquetes de datos por el puerto I2C hacia la memoria. Una
vez grabados, el microcontrolador envía una cadena de caracteres “OK” hacia el PC
indicando que se ha hecho la grabación y está listo para recibir el siguiente paquete.
67
Si el último paquete almacenado en la memoria corresponde al último paquete del archivo a
almacenar, el microcontrolador inicia la parte final de la grabación (paso=3), en esta se
efectúa un reset a los datos de configuración del bloque de la memoria EEPROM destinada
almacenar estos. Seguidamente envía una cadena de caracteres “FIN” hacia el PC
indicando que se ha completado el proceso de grabación. En caso de presentarse un error en
el proceso de grabación el microcontrolador envía una cadena de caracteres “ERROR”
hacia el PC, la aplicación detendrá entonces el proceso de grabación.

5.5.3 MODO AP (ACCESS POINT).

En este modo el dispositivo no se conecta a una red, sino que se comporta como un punto
de red al cual es posible conectarse mediante una conexión Wi-Fi. El ESP8266 trae
configurada una dirección IP por defecto para el modo servidor (192.168.4.1, esta puede ser
modificada alterando el firmware). Para que el dispositivo se ponga en modo AP es
necesario colocar el botón de estado en el modo servidor. El interruptor hará un reset al
dispositivo ESP8266 y al microcontrolador quien identificará que se ha iniciado en modo
AP (diagrama de flujo figura 10), se genera una consulta interna de los parámetros para
verificar que el modo AP se ha iniciado correctamente, seguidamente se habilitan las
conexiones simultáneas esto garantiza que el dispositivo responderá adecuadamente a las
peticiones que se le efectúen desde el dispositivo cliente; luego se inicia el servidor en el
puerto 80. El dispositivo ESP8266 queda en espera de la recepción de datos provenientes
desde el dispositivo cliente, que se conecta al punto de acceso del dispositivo mediante la
dirección IP preestablecida. Esta conexión es de tipo HTTP, por lo que la función del
microcontrolador que evalúa el puerto de conexión con el ESP8266 es esperar la recepción
de un encabezado HTTP, al detectarlo, interpreta la trama de datos que llega en el
encabezado y según su contenido determina el tipo de petición del cliente. El cliente puede
hacer cuatro tipos de peticiones:

Petición inicial de conexión (página de inicio): Al conectarse un cliente por primera vez al
servidor, el encabezado HTTP recibido posee únicamente la información propia del
dispositivo cliente. Al detectar el microcontrolador que no existe ninguna información
adicional, efectúa una lectura de la memoria EEPROM del bloque en el cual se encuentra el
código HTML del formulario del servidor local diseñado para el inicio de la sesión y envía
dicho código hacia el cliente a través del ESP8266 quien a su vez envía estos paquetes al
cliente web. En éste formulario el usuario debe validar un usuario y contraseña genéricos
para poder ingresar a la configuración del dispositivo de medición.

Petición de carga de datos (cargar formulario): Una vez el cliente se ha autenticado, el

encabezado HTTP incluye el valor de una cookie con dos variables correspondientes a la
autentificación de usuario y contraseña, cuando el microcontrolador encuentra dichos
valores en la petición del cliente, efectúa la lectura del bloque de la memoria EEPROM
donde se encuentra el formulario principal de los parámetros de conexión y el bloque donde
se encuentran los parámetros correspondientes a cada casilla del formulario, combina esta
68
información y genera un único código HTML el cual se envía al cliente a través del
ESP8266.

Figura 10. Flujo del modo AP para los objetos IoT diseñados.

Petición modificar datos (grabar): Cuando el encabezado HTTP del cliente incluye el
valor de una cookie que indica al microcontrolador que debe almacenar los datos que
vienen anexos dentro del encabezado, este efectúa una lectura de los datos incluidos en el
encabezado y que corresponden a los nuevos parámetros de configuración del objeto IoT.
Esta petición se lanza desde el cliente cuando en el formulario se pulsa el botón “grabar”
seguidamente el microcontrolador almacena estos parámetros en el bloque de memoria
correspondiente y carga nuevamente todo el código HTML del formulario indicando en una
de las variables que se ha efectuado la operación exitosamente, dicha variable ejecuta
código Javascript en el lado del cliente que coloca una ventana que informa que se han
almacenados los datos exitosamente (ver la sección 9.2).

Petición de redes disponibles: Cuando el encabezado HTTP del cliente incluye el valor de
una cookie que indica al microcontrolador que debe buscar el listado de las redes
disponibles, el microcontrolador envía un comando al ESP8266 para que éste haga la
búsqueda de redes disponibles quien devuelve el listado a través del puerto serie. El
microcontrolador recoge dichos datos anexándolos dentro del bloque de código HTML que
lee de la memoria EEPROM y los envía de vuelta al cliente.
Errores de petición: Es posible que se encuentren distintos errores en las peticiones,
típicamente, que el encabezado HTTP generado desde el cliente no sea compatible con la
estructura que se ha definido en el microcontrolador. Se ha elaborado una estructura lo más
sencilla posible omitiendo todos los parámetros que no sean necesarios, de forma tal de que

69
el servidor pueda responder a las peticiones de dispositivos de características disímiles; sin
embargo es posible que existan problemas en la recepción de acuerdo al tipo de dispositivo
que se está conectando. Sería necesario un desarrollo más sofisticado del servidor local para
responder adecuadamente ante una gran cantidad de dispositivos. Sin embargo, el ESP8266
no está diseñado para ser utilizado como servidor web de modo permanente y sus
prestaciones son limitadas (por ejemplo, el envío de paquetes por vez se limita a un total de
2046 bytes) lo que hace que sea poco eficiente. Para este proyecto es suficiente para
garantizar que se configuran los parámetros de conexión en el modo de operación normal,
que son los que interesan una vez el dispositivo está operativo.

5.5.4 MODO NORMAL

La operación normal se presenta una vez configurados correctamente todos los parámetros
necesarios para el inicio de los dispositivos y la conexión al servidor Node.js. En esta fase
se realizan y envían las mediciones de consumo y se reciben peticiones desde el servidor.
En adelante se hará uso de los siguientes términos para referirse a cada uno de las
características del proceso:

Aparato consumidor: Es el objeto real que se pretende medir, en el caso del consumo de
agua corresponderá al uso que se dé al final de la sección de tubería en donde se ha
instalado el sensor de efecto hall (Tabla 1 del capítulo 2), para los dispositivos de medición
de energía eléctrica será la carga que se acopla al sensor ADE7753 (Tabla 1 del capítulo 3).

Evento de consumo: Corresponde al intervalo de tiempo en el cual la medición del

consumo hecha por el objeto IoT sea distinta de cero (flujo en caso del agua, potencia en
caso de la medición eléctrica), éste corresponde al periodo en el cual permanece activo el
aparato consumidor. En los aparatos consumidores de agua el consumo se da en el
intervalo entre la apertura y el cierre de una llave o dispositivo regulador, comúnmente
durante breves periodos con múltiples repeticiones (grifos de lavaplatos, lavamanos,
cisternas, entre otros). Los electrodomésticos suelen tener eventos de consumo de periodos
mucho más prolongados (entre el encendido y el apagado del aparato), donde la duración
va desde minutos hasta llegar a ser permanentes. La medición por eventos puede resultar
útil para conocer en qué momentos o qué aparatos tienen mayor uso, además de reducir de
forma importante el tamaño de los datos a almacenar pues el consumo en tiempo real
(valores por segundo) es importante en la visualización en tiempo real, pero poco relevante
al efectuar el análisis de consumo acumulado, por lo que el elemento fundamental a
almacenar será el evento de consumo.

Evento acumulado: Corresponde al as mediciones efectuadas en el periodo en el cual el

objeto IoT no puede enviar paquetes desde el dispositivo hacia la base de datos a través de
la conexión Websocket-servidor. En dicho caso las mediciones se acumulan y se almacenan
en la EEPROM para ser envidas posteriormente.

70
Estado de reposo: Corresponde al intervalo de tiempo en el cual la medición de consumo
del aparato consumidor es cero. Comúnmente los aparatos consumidores de agua pasan la
mayor parte de su tiempo en un estado de reposo, por lo que es buena idea desconectar el
módulo de conexión de la red para ahorrar energía, máxime teniendo en cuenta que la
fuente de energía es una batería. Esta desconexión se hará cuando se complete un minuto en
estado de reposo. El sistema reiniciará la rutina de conexión al detectar un consumo mayor
que cero, es decir, el inicio de un nuevo evento de consumo.

Ciclo de medición: Es una sub-rutina dentro del modo normal que corresponde al bucle
donde permanecerá el dispositivo mientras se encuentra debidamente conectado y enviando
y recibiendo daros a través del socket (Figuras 12 y 13). En esta subrutina se hace en envío
de los datos de tiempo real (evento de consumo) y se gestionan, a parte de las
interrupciones propias de la programación del microcontrolador, las peticiones de la
operación del objeto IoT

Peticiones: El microcontrolador gestiona dos tipos de peticiones, por un lado están aquellas
que llegan desde la conexión del dispositivo inalámbrico ESP8266, en modo normal estos
corresponden a paquetes Websocket que contienen un número indicador de tramas
enviadas, este tiene como propósito controlar la ventana del flujo de datos que se envían al
servidor y determinar si se ha perdido algún paquete o incluso la conexión con el servidor,
de modo que si se llegara a perder la conexión con el servidor entraría en un estado de
medición sin envío de datos. La otra petición que es atendida es una interrupción que se
ejecuta cada segundo, momento en que se efectúa la medición de parámetros de consumo
para ser enviados al servidor. El sistema debe determinar si el consumo es mayor que cero,
en caso de ser así debe determinar si hay un evento activo o un nuevo evento, esta
identificación es importante para poder elaborar la estructura del paquete de datos que se
enviará al servidor. Por el contrario, si el consumo es cero, el sistema debe determinar si
anteriormente se encontraba en un evento activo, caso en el cual debe enviar al servidor un
paquete que indique el fin de un evento. En cualquiera de los casos la trama que se
estructura envía adjunto el valor del consumo medido.

El modo normal inicia con el reset al dispositivo ESP8266 seguido de establecimiento del
modo estación y la conexión a la red. Si no lograra la conexión el dispositivo continuará
intentando la conexión hasta que se establezca o supere un minuto intentando establecerla.
El dispositivo de medición de agua entrará en modo de bajo consumo al fracasar los
intentos de conexión y el consumo medido se convertirá en un evento acumulado(Bloque
dormir de la figura 11), el dispositivo de medición de energía continuará indefinidamente
haciendo intentos de conexión. Una vez conectado a la red intentará la conexión al servidor,
en caso de no lograrla intentará actualizar la hora del objeto IoT conectándose a uno de tres
servidores de hora que se han configurado para ello (IP: 216.228.192.69, 129.6.15.30,
131.107.13.100) estos servidores cumplen explícitamente la función de sincronismo de
hora en Internet (existe un gran número de ellos, un listado se puede hallar en la página
http://tf.nist.gov/tf-cgi/servers.cgi). Comúnmente se usa el protocolo NTP17 como método
para el sincronismo, sin embargo por simplicidad se ha optado por usar el protocolo NIST

17
NTP (Network Time Protocol): Es un protocolo para sincronizar los relojes a través del enrutamiento de
paquetes en redes con latencia variable. Utiliza UDP como capa de transporte, usando el puerto 123.

71
DAYTIME el cual usa el puerto TCP 13 y entrega un array de caracteres en formato
DATETIME que es el mismo que se usa para la configuración de hora en la programación
Javascript del servidor y en la base de datos. En caso de que la hora no lograra actualizarse
(algunos enrutadores son configurados por el ISP para bloquear los paquetes desde/hacia el
puerto 13) el tipo de dato del evento acumulado indicará que la hora del objeto IoT no está
actualizada.

Figura 11. Flujo del proceso de conexión y ajuste en el modo normal del objeto IoT.

Una vez efectuada la conexión al servidor se debe habilitar el envío permanente de datos
(comando AT+CIPSEND de la sección 4.3.7.1.3) para enviar el HTTP handshake previo al
establecimiento del Websocket (sección 6.2.1.1), si la negociación es exitosa se inicia el
Websocket, en caso de fracasar se deshabilita el envío permanente de datos a través de la
terminal del ESP8266 y se desconecta el servidor para hacer un nuevo intento de conexión.

Habilitado el Websocket lo primero que hace el objeto IoT es solicitar la hora del servidor,
en este caso ya no sincroniza con un servidor web de hora sino con el servidor de datos del
objeto, la petición se estructura como una trama Websocket como se muestra en la sección
5.6y cuya respuesta se explica en la sección 6.5.2. Si el registro RSI tiene datos sin enviar,
se estructura y envía una trama Websocket conteniendo el JSON del evento acumulado
pendiente de almacenar, en caso de no haber mediciones pendientes pasa directamente al
ciclo de medición y envío de tiempo real. Si el servidor fallase y no llegara la respuesta a la
recepción del evento acumulado esperará hasta recibir respuesta durante el intervalo
correspondiente a la ventana de tiempo del envío de datos de tiempo real, al finalizar ese
intervalo el objeto cierra el socket y se desconecta del servidor. Si se presentara un error del
servidor o de la conexión de la red (la terminal del ESP8266 devuelve un mensaje de error)
se reinicia todo el proceso de conexión del modo normal.

72
5.5.4.1 ciclo de medición de consumo de agua.

En el ciclo de medición el microcontrolador registra de forma permanente el valor del

voltaje de salida del sensor de efecto Hall (muestreo cada milisegundo), contabiliza la
cantidad de cambios del nivel que se suceden y que corresponden a los pulsos de medición
del sensor asociados a la cantidad de flujo de agua pasante como se estableció en la sección
2.5.2 (figura 12). Al completarse un segundo se genera un evento en el cual se suma ese
segundo en el reloj del objeto, si en este periodo el consumo es mayor que cero (conteo de
pulsos) se estructura una trama JSON que se envía por el socket. El tipo de dato de la trama
dependerá de si la medición previa era mayor que cero, en cuyo caso hay un evento de
consumo activo por lo que se debe indicar al servidor que agregue esa nueva medida al
último registro de eventos en la base de datos asociada al objeto IoT, en caso contrario se
está presentando un nuevo evento por lo que el tipo de dato del JSON debe indicar que se
agrega un nuevo registro de evento a la base de datos. Se debe tener presente que si el
objeto IoT no ha registrado eventos por más de un minuto el ESP8266 se encuentra en
mofo de bajo consumo, por lo que el dispositivo saldrá del ciclo de medición para iniciar la
rutuna de activación y conexión del dispositivo al servidor y la medición se enviará como
un evento acumulado.

Figura 12. Flujo del ciclo de medición de tiempo real del objeto IoT de medición de consumo de agua.

Si la medición del contador es cero y previamente el consumo era diferente de cero se debe
registrar el fin de un evento de consumo, si la medición actual y la anterior son cero se debe
verificar si el contador de tiempo de espera está activo, si es así el ESP8266 se encuentra
activo. Si no se ha registrado consumo después de un intervalo de tiempo determinado (60
segundos) se considera que el aparato consumidor de agua ha entrado en un estado de
reposo por lo que para ahorrar energía se procede a deshabilitar la conexión de red del
dispositivo ESP8266 y a ponerlo en un estado de sueño profundo. Esto implica la
desconexión de la red, por lo que los clientes web no tendrán datos de tiempo real del
objeto IoT hasta que no se genere un nuevo evento y aquel se active y conecte nuevamente
a la red.

73
5.5.4.2 ciclo de medición de parámetros eléctricos.

A diferencia de los aparatos consumidores de agua, los electrodomésticos suelen tener

eventos de consumo con periodos mucho más prolongados, un evento de consumo puede
durar desde minutos hasta llegar a ser permanente, de modo que no se presenta la
repetitividad de eventos de consumo del caso de la medición de agua. Es posible en todo
caso hacer seguimiento por eventos para la mayor parte de los electrodomésticos por lo que
el concepto se manejará del mismo modo que el caso anterior.

Figura 13. Flujo del ciclo de medición de tiempo real del objeto IoT de medición de consumo de energía
eléctrica
.
El ciclo de medición de energía eléctrica es básicamente igual anterior (figura 13). El
dispositivo de medición eléctrica gestiona cuatro tipos de peticiones: aquellas que
provienen del servidor y que corresponden a la recepción de paquetes para controlar la
ventana de mensajes enviados (igual que en el caso del agua), la petición correspondiente a
la interrupción cada segundo donde el microcontrolador consulta al CI ADE7753 las
mediciones de corriente, voltaje y potencia para ser estructuradas en la cadena datos JSON
que se enviarán al servidor a través del Websocket. La tercera petición proviene del
servidor y tiene como propósito activar o desactivar el circuito interruptor de salida del
objeto IoT. La cuarta es la del pulsador que trae el circuito para activar o desactivar la carga
en caso de que el objeto IoT no presente conexión a la red. El sistema permanece a la
espera las peticiones y al recibirlas ejecuta las tareas de acuerdo a la naturaleza de cada
evento.

74
 5.6. ESTRUCTURA DE DATOS ENVIADOS POR EL OBJETO IOT.

Cada objeto IoT enviará al servidor durante el ciclo de medición una serie de tramas
Websocket que contendrán un array de datos en formato JSON de la siguiente manera:

5.6.1 DATOS DE CONSUMO DE AGUA.

El dispositivo maneja dos tramas correspondientes a valores de consumo de evento

acumulado o de tiempo real. El array JSON de tiempo real es como el siguiente:

{"𝒊𝒅": "𝒔𝒂_𝟎𝟎𝟏", "𝒔𝒆": 𝟒𝟗, "𝒕𝒅": 𝟏, "𝒄𝒐": 𝟏𝟎𝟎, "𝒇𝒆": "𝟐𝟎𝟏𝟔 − 𝟎𝟓 − 𝟏𝟒𝑻𝟐𝟎: 𝟒𝟕: 𝟑𝟑"}

Donde:
- “fe”: Fecha de la muestra, en formato DATETIME para insertar en MySQL.
- “se”: Número de secuencia de la trama.
- “co”: Valor de medición de consumo de agua del último segundo (número de
pulsos del sensor de efecto hall).
- “id”: Identificador único del objeto IoT y de su tabla correspondiente en la BD.
- “td”:Tipo de dato, brinda información sobre el tipo de dato contenido en la trama.

El array JSON de evento acumulado es como el siguiente:

{"𝒊𝒅": "𝒔𝒂_𝟎𝟎𝟎𝟏", "𝒔𝒆": 𝟒𝟗, "𝒕𝒅": 𝟐𝟓𝟓, "𝒇𝒆": "𝟐𝟎𝟏𝟔 − 𝟎𝟓 − 𝟏𝟒𝑻𝟐𝟎: 𝟒𝟕: 𝟑𝟎",
"𝒅𝒖𝒓": "𝟎. 𝟎. 𝟎. 𝟏", "𝒕𝒑𝟏": "𝟎. 𝟎. 𝟎. 𝟏", 𝒕𝒑𝟐": "𝟎. 𝟎. 𝟎. 𝟓", 𝒕𝒑𝟑": "𝟎. 𝟎. 𝟎. 𝟏", 𝒕𝒑𝟒": "𝟎. 𝟎. 𝟎. 𝟎"}

Donde:
- “id”: Identificador único del objeto IoT y de su tabla correspondiente en la BD.
- “se”: Número de secuencia de la trama.
- “td”:Tipo de dato, brinda información sobre el tipo de dato contenido en la trama.
- “fe”: Fecha de la muestra, en formato DATETIME para insertar en MySQL.
- “dur”:Duración del evento, corresponde a 4 bytes separados por punto de mayor a
menor:
- “tp1”:Suma valores correspondientes al segmento 1 de la linealización del sensor
de flujo de agua (ecuación 2 de la sección 2.5.2).
- “tp2”:Suma de valores correspondientes al segmento 2 de la linealización del
sensor de flujo de agua
- “tp3”:Suma de valores correspondientes al segmento 3 de la linealización del
sensor de flujo de agua
- “tp4”:Suma de valores correspondientes al segmento 4 de la linealización del
sensor de flujo de agua

Para recuperar el valor de la medición de consumo acumulada se debe calcular de la

siguiente manera teniendo siempre cuidado de que los valores vayan de mayor a menor
75
 𝑣𝑎𝑙𝑜𝑟 = 𝑡𝑝0 ∗ 20 + 𝑡𝑝1 ∗ 28 + 𝑡𝑝2 ∗ 216 + 𝑡𝑝3 ∗ 224

Como ejemplo, para recuperar el valor de la trama “1.2.3.4”

5.6.2 DATOS DE CONSUMO DE ENERGÍA ELÉCTRICA.

El dispositivo maneja una trama correspondiente a valores de consumo de evento

acumulado o de tiempo real. El array JSON es como el siguiente:

{"𝒊𝒅": "𝒔𝒆_𝟎𝟎𝟐", "𝒔𝒆": 𝟒𝟗, "𝒕𝒅": 𝟑𝟐, "𝒗𝒐": "𝟎𝒙𝟎𝟎𝟏𝟔𝑨𝑭𝑩𝟖", "𝒄𝒐": "𝟎𝒙𝟎𝟎𝟎𝟏𝟓𝟏𝑪𝑫", "𝒑𝒐"
: "𝟎𝒙𝟎𝟎𝟎𝟎𝟎𝟐𝟗𝟎", "𝒔𝒘": "𝒐𝒏", "𝒇𝒆": "𝟐𝟎𝟏𝟔 − 𝟎𝟕 − 𝟐𝟖𝑻𝟎𝟔: 𝟎𝟒: 𝟒𝟖"}

Donde:
- “id”: Identificador único del objeto IoT y de su tabla correspondiente en la BD.
- “se”: Número de secuencia de la trama.
- “td”: Tipo de dato, brinda información sobre el tipo de dato contenido en la trama.
- “vo”: Valor medido de voltaje RMS en el último segundo.
- “co”: Valor medido de corriente RMS en el último segundo.
- “po”: Valor medido de la potencia real en último segundo.
- “sw”: Indica el estado de activación de la carga (ON/OFF).
- “fe”: Fecha de la muestra, en formato DATETIME para insertar en MySQL.

Los valores de medición corresponden a cadenas de caracteres que se deben convertir en el

valor hexadecimal equivalente, dichos valores son los obtenidos en la lectura de registros
de AE7753 como se describe en la sección 3.6.3.

76
 5.6.3 TIPO DE DATO.

El tipo de dato es la variable JSON que utilizan los objetos IoT propuestos para indicar al
servidor la naturaleza de la información contenida en la trama. Es un byte (valores de 0 a
255) donde cada bit cumple una función específica de configuración tal como se muestra en
la figura 14 (A, bit menos significativo). Con esta información se determina si la trama que
llega al servidor presenta:

- Hora actualizada: En caso de no estar actualizada el servidor tomará como hora

del consumo la hora de llegada del paquete al servidor.
- Hora de la trama es la del inicio de evento de la muestra actual: el servidor
ajustará la hora del evento de acuerdo a cómo la señala el objeto.
- Muestra de consumo de evento nuevo: En cuyo caso el servidor crea un nuevo
registro en la tabla de eventos de consumo del objeto IoT. En caso contrario
agregará el valor de consumo al último registro de la tabla.
- Tipo de registro: Determina si la trama JSON contiene la información de un
consumo acumulado o uno de tiempo real.

El servidor deberá leer este dato como primer paso para tomar acciones sobre la
información recibida como se describe en la sección 6.5.2.

Figura 14. Estructura de la variable “td” (tipo de dato).

77
 5.6.4. CONTROL DE PAQUETES.

La rutina del ciclo de medición mantiene una lectura permanente del puerto de conexión
serie entre microcontrolador y el ESP8266, su tarea consiste la recepción de datos
provenientes del Websocket. Los mensajes de aceptación de paquetes de datos enviados
previamente al servidor o mensajes de error en caso de que la recepción por parte del
servidor web no fuera exitosa llegan de forma asíncrona, es posible que se presenten
pérdidas de datos por errores en la conexión, problemas con el formato de los datos o de las
tablas en la base de datos al intentar hacer inserción o modificación de los mismos de modo
que es necesario un método para corroborar la correcta recepción de tramas Websocket por
parte del servidor, para ello se ha implementado una simple ventana deslizante de mensajes.

Figura 15. Ventana deslizante para el control de paquetes de los objetos IoT.

En la figura 15 se muestra el funcionamiento de la ventana deslizante, a cada trama

Websocket que contiene un JSON corresponde una respuesta por parte del servidor de
acuerdo a la naturaleza de la solicitud. El envío habitual de paquetes deberá ser respondido
con el valor de la variable “se” (número de secuencia) que es el ACK del mensaje. En caso
de presentarse una desconexión abrupta del lado del servidor, por ejemplo, el objeto IoT no
tendría forma de saber si la misma sucedió, por lo que seguiría enviando paquetes
indefinidamente. Al llenarse la ventana, el ciclo de medición termina ya que no es posible
el envío de tramas y todos los valores enviados después del último ACK se convierten en
un evento acumulado. Todos los mensajes enviados desde el servidor hacia el objeto IoT
deberán contener una cadena de caracteres conde el mensaje debe iniciar con asterisco y
finalizar con espacio así: “*MENSAJE ” La función de lectura del microcontrolador sólo
dará como válido todo mensaje que provenga con esta estructura.

78
 5.7 ENSAMBLE DE OBJETOS IOT

Para ensamblar los objetos IoT se diseñaron varios PCB en Egale correspondientes al
dispositivo de medición de agua y de energía eléctrica estos se muestran en la figura 16 y
17.

Figura 16. Montaje PCB del circuito de medición de Agua.

Figura 17. Montaje PCB del circuito de medición de energía eléctrica.

79
 6. CONEXIÓN DE LOS OBJETOS IoT A LA WEB.

Como se indicó en el capítulo 1, los objetos IoT llevan asociados una identidad así como
atributos físicos y personalidades virtuales que se integran en la red. Una serie de
tecnologías son requeridas para poder crear la llamada identidad virtual de un objeto que
tiene la capacidad de conectarse a una red y compartir información, estas deben garantizar
la adecuada conexión, el almacenamiento y procesamiento de los datos así como la
interacción con otros dispositivos y las personas. Los requerimientos guardan muchas
semejanzas con la Internet actual, por lo que es posible hacer uso de las tecnologías
existentes, algunas de ellas desarrolladas recientemente y con atributos óptimos para la
elaboración y gestión de una IoT. Dentro de los requerimientos es necesario contar
fundamentalmente con:

- Almacenamiento de datos (Base de datos MySQL).

- Servicios que gestionen las conexiones de dispositivos y garanticen la comunicación
entre los mismos (Websocket).
- Servicios que gestionen la consulta y el procesamiento de los datos (Node,js).
- Aplicaciones a nivel de usuario que guarden suficiente flexibilidad para funcionar
en condiciones razonables en dispositivos de prestaciones (hardware) dispares
(Bootstrap).

Para el desarrollo de dichas herramientas en este proyecto se han seleccionado las

tecnologías puestas entre paréntesis en el listado y que se describen a continuación, estas
presentan unas características afines con las necesidades propias de un internet de los
objetos como se verá más adelante, motivo por el cual se han elegido. La última parte de
este capítulo está dedicada a mostrar las pruebas del servidor web en diferentes servidores
(local y web) donde ya se integran todos los elementos de hardware y software propuestos.

Figura 1. Diagrama entidad-relación de la base de datos necesaria para el almacenamiento de los datos de los
objetos IoT propuestos.

80
 6.1. BASE DE DATOS.

El fundamento de la identidad virtual de un objeto IoT es la información sobre o

proveniente del mismo; las bases de datos definen la estructura para la gestión y
almacenamiento de dicha información. En la actualidad, a parte de los tradicionales
modelos relacionales, se encuentra en pleno desarrollo un grupo de sistemas de gestión de
datos basados en modelos no relacionales. Para este proyecto, dada la sencillez y extensión
de los datos almacenados, se ha optado por la elaboración de una base de datos relacional
simple como se describe a continuación. Es de tener presente que el propósito de este
trabajo no es elaborar una base de datos extensa sino demostrar la operatividad de los
objetos IoT propuestos.

6.1.1. MODELO RELACIONAL.

En la sección 5.5.4 se indicó en que el elemento fundamental de información de los datos

que entregan los objetos IoT es el evento de consumo. Cada evento se identificará con un
número único y tendrá los datos propios del consumo (fecha/hora de inicio del consumo,
duración en segundos, total de consumo [que depende del tipo de objeto], y total de
consumo acumulado [contador]). Cada evento de consumo es entregado por un único
objeto IoT (los objetos registrarán la n cantidad de eventos que se presenten a partir de su
activación). Cada objeto será identificado con un ID único el cual es almacenado en la
EEPROM y que no puede ser modificado por parte del usuario en el modo AP18.

Figura 2. Esquema del modelo relacional de la base de datos para el almacenamiento de información de los
objetos IoT.

18
En el manual se verá que la opción se encuentra disponible, sin embargo no tiene efecto sobre la
programación actual.

81
Al activarse un objeto IoT y realizar con éxito el procedimiento de conexión en modo
normal, se verificará si su ID se encuentra asociado a algún usuario. Existirán objetos que
no tengan un usuario asociado cuando estos son nuevos y se conectan por primera vez al
servidor. Al ingresar un nuevo objeto se debe agregar su ID específico, un nombre de
objeto, el tipo (agua o eléctrico), y un valor que corresponde a la relación costo/consumo
asociado a su tipo de medición. En la figura 1 se muestra el diagrama entidad-relación
correspondiente.

La participación del evento del consumo en la relación sensa es total, es decir, un evento de
consumo no puede existir sin estar asociado a un objeto IoT, de igual manera, uno a varios
eventos de consumo están asociados a un mismo objeto, por lo que de acuerdo a las
condiciones de combinación de tablas es posible combinar la tabla Sensa con la tabla
Evento Consumo del modelo relacional obtenido a partir del diagrama entidad-relación
(figura 2). De forma semejante, ninguno a varios objetos IoT están asociados a un mismo
Usuario, en este caso no se cumple la condición para la combinación de tablas de forma
completa, sin embargo, por simplicidad es posible aun combinar la tabla Posee con la tabla
Objeto IoT de modo que el esquema relacional se simplifica al mostrado en la figura 3.

Figura 3. Esquema del modelo relacional simplificado de la base de para el almacenamiento de los datos de
los objetos IoT. (El campo “Código usuario” de la tabla Objeto IoT deberá diligenciarse como NULL cuando
se ingrese un nuevo registro a la tabla, equivalente a agregar un nuevo dispositivo a la red).

6.1.2. SISTEMA DE GESTIÓN.

El sistema de gestión de bases de datos seleccionado es MySQL el cual guarda

compatibilidad con la interfaz de aplicación del servidor Node.js. En este se ha creado la
base de datos con sus tablas correspondientes en diferentes aplicaciones según las
diferentes pruebas efectuadas en el proceso de desarrollo (Wampserver, phpmyadmin.co,
entre otros). Las consultas SQL efectuadas hacen parte de la aplicación del servidor y de la
interfaz de usuario.

82
 6.2. WEBSOCKET.

HTTP es el protocolo más común y utilizado en el nivel de aplicación, por sus

características no fue diseñado para aplicaciones de tiempo real, ni para comunicación full
dúplex. A raíz de estas carencias se han elaborado varias técnicas para enviar notificaciones
en “tiempo real,” denominadas comet. Dicho término describe un modelo de aplicación
web en el que una petición HTTP que se mantiene abierta permite enviar datos a un cliente
mediante tecnología push, sin que el cliente lo solicite explícitamente [21] [22]. Estas
técnicas se agrupan en tres grupos: Ajax (Polling), Ajax Push (Long Poll) y Ajax Push
(Streaming). Estas soluciones comparten varios problemas, principalmente el exceso de
peticiones HTTP, por lo que no son aptas para aplicaciones de tiempo real de baja latencia.
En la comunicación full dúplex usan dos conexiones: una para enviar (downstream) y otra
para recibir (upstream), por lo que el mantenimiento y la coordinación de estas dos
conexiones introduce una sobrecarga significativa en términos de consumo de recursos y
añade mucha complejidad algorítmica. Otras técnicas en tiempo real implican el uso de
herramientas más sofisticadas como aplicaciones Flash, solicitudes XHR de varias partes y
los denominados html-files [21].

Websocket19se define como una tecnología que proporciona un canal de comunicación

bidireccional y full-dúplex sobre un único socket TCP entre el cliente y el servidor web
[24], donde cada parte puede, sin dependencia de la otra, enviar mensajes a voluntad sin
generar colisión. Websocket es un protocolo en la capa de aplicación que utiliza el puerto
80 para las conexiones regulares y el puerto 443 para las conexiones seguras TLS20. La API
de Websocket está siendo normalizada por el W3C [23], mientras que el protocolo
Websocket ya fue normalizado por la IETF con el RFC 6455 en la versión 13 [24].
Websocket pretende suprimir muchos de los problemas de las conexiones comet antes
mencionadas mediante un protocolo simple en el nivel de aplicación que sea compatible
con HTTP.

6.2.1. DESCRIPCIÓN GENERAL.

El protocolo Websocket se divide en dos partes principales:

-Negociación (handshake), documentada en la sección 4 de la norma RFC 6455.

-Transferencia de datos, documentada en la sección 5 de la norma RFC 6455.

19
Se ha tomado como referencia para la conceptualización un estudio del protocolo Websocket elaborado por
el grupo de trabajo de ingeniería de internet (IETF) basados en la versión 13 de la norma RFC 6455 [24].
20
TLS: Seguridad de la capa de transporte (Transport Layer Security) es un protocolo criptográfico que
proporciona comunicaciones seguras por la red, su aplicación en HTTP está definido por la norma RFC2818.

83
6.2.1.1. Negociación (handshake).

La negociación consiste de una petición HTTP, junto con una lista de parámetros
requeridos y campos de cabecera opcionales. El saludo inicial por parte del cliente se ve de
la siguiente manera:

GET /chat HTTP/1.1

Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13

La negociación desde el servidor o la respuesta de éste es la siguiente:

HTTP/1.1 101 Switching Protocols

Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: chat

Los detalles del significado de cada parámetro se pueden estudiar en la norma RFC6455.No
hay límite al número de conexiones Websocket que un cliente puede tener con un solo host
remoto. Los servidores pueden negarse a aceptar conexiones de hosts o direcciones IP con
un excesivo número de conexiones existentes o desconectarse cuando sufre de alta carga.

Una vez que la negociación de apertura del cliente ha sido enviada, el cliente debe esperar
una respuesta del servidor antes de enviar más datos. El servidor debe analizar al menos
una parte de la solicitud con el fin de obtener la información necesaria para generarla parte
del servidor de la negociación. El cliente deberá validar la respuesta del servidor de la
siguiente manera:

1. Si el código de estado recibido desde el servidor no es 101, el cliente maneja la

respuesta por procedimientos HTTP [RFC2616].
2. La respuesta deberá contener un campo de cabecera con el nombre |Upgrade| cuyo
valor debe incluir la palabra Websocket, si no tiene este campo o no tiene este valor
el cliente debe cerrar la conexión.
3. La respuesta deberá contener un campo de cabecera con el nombre |Connection|
cuyo valor debe incluir la palabra Upgrade, si no tiene este campo o no tiene este
valor el cliente debe cerrar la conexión.
4. Si la respuesta carece de un campo de cabecera |Sec-WebSocket-Accept| o el campo
|Sec-WebSocket-Accept| contiene un valor distinto del codificado en base 64 de la
concatenación de la |Sec-WebSocket-key| (como una cadena, no en base 64
decodificado), el cliente deberá cerrar la conexión Websocket.

84
6.2.1.2. Transferencia de datos.

Una vez que el cliente y el servidor han efectuado la negociación exitosamente, se inicia la
transferencia de datos. Websocket se convierte en un canal de comunicación de dos vías,
donde cada parte puede enviar los datos a voluntad, los datos se transmiten utilizando una
secuencia de marcos. De esta forma, el cliente debe enmascarar todos los marcos que envía
al servidor. Una trama de datos puede ser transmitida por el cliente o el servidor en
cualquier momento.

Tabla 1. Estructura de una trama Websocket

masking-
Nombre fin rsv1 rsv2 rsv3 opcode masked Lenght data
key
1-
Longitud(bits) 1 1 1 1 4 1 (7-16) ( 64) (127) 32
127

En la tabla 1 se muestra la estructura de una trama Websocket donde los datos enviados
deben guardar el orden establecido.

6.2.2. API WEBSOCKET.

Para poder efectuar la comunicación mediante el protocolo Websocket se requiere que en el

nivel de aplicación se ejecute el mismo tanto en el cliente como en el servidor. La interfaz
de programación de aplicaciones es la herramienta de programación con la cual es posible
la apertura, el cierre y el control de los Websocket [23]. A continuación se describen
brevemente las herramientas de la API Websocket la cual hace parte de las bibliotecas de
Node.js y HTML5 que son las herramientas usadas para el desarrollo del Back-End y el
Front-End del proyecto.
Tabla 2. Eventos principales de la API Websocket en Javascript.
Controlador De
Evento Descripción
Eventos
abierto websocket.onopen Este evento se produce cuando se establece la conexión de socket.
mensaje websocket.onmessage Este evento se produce cuando el cliente recibe los datos del servidor.
error websocket.onerror Este evento se produce cuando hay algún error en la comunicación.
cerrar websocket.onclose Este evento se produce cuando la conexión se cierra.

Para abrir una conexión Websocket (Javascript), se debe crear el constructor del objeto
Websocket:
𝑣𝑎𝑟 𝑊𝑒𝑏𝑠𝑜𝑐𝑘𝑒𝑡 = 𝑛𝑒𝑤 𝑊𝑒𝑏𝑆𝑜𝑐𝑘𝑒𝑡(𝑤𝑠: 𝑢𝑟𝑙, [𝑝𝑟𝑜𝑡𝑜𝑐𝑜𝑙𝑜]);

Donde url especifica la dirección URL a la que se conecta. El atributo protocolo es

opcional, y si está presente, especifica un sub-protocolo que el servidor debe apoyar para
que la conexión sea exitosa. ws: es el nuevo esquema de URL para las conexiones

85
Websocket. También hay wss: para conexiones Websocket seguras, de la misma forma que
se utiliza https: para las conexiones HTTP seguras.

6.2.2.1. Eventos Websocket

Después de crear el objeto Websocket, se deban controlar los eventos que genera. Hay 4
eventos principales en el API Websocket: Open, Message, Close y Error. Estas funciones
serán ejecutadas de forma asíncrona cuando se produzca una acción específica. En la tabla
2 se muestran los eventos asociados con el objeto Websocket.

6.2.2.2. Métodos Websocket.

El protocolo Websocket admite dos acciones principales: send y close.

Tabla 3. Métodos de la API Websocket en Javascript.

Método Llamada Descripción
Enviar websocket.send () El método send (datos) transmite datos utilizando la conexión.
websocket.close () El método close () se utiliza para terminar cualquier conexión
Cerrar
existente.

En la figura 4 se muestra el modelo por capas de la implementación propuesta. Es posible

usar Websocket como protocolo de comunicación ya que este es soportado por el
dispositivo ESP8266 que usan los objetos IoT para la conexión a la red así como por
diversos navegadores web que hagan uso de HTML5, El servidor Node.js está pensado para
trabajar con conexiones persistentes como las creadas por Websocket.

Figura 4. Modelo en capas para la implementación propuesta haciendo uso de Websocket.

86
 6.3 DISEÑO BACK-END (NODE.JS).

El tipo de tecnología seleccionada para elaborar el servidor (Back-end) es Node.js. Esta

permite crear un servidor eficiente en aplicaciones que utilicen conexiones persistentes con
el cliente con un mínimo consumo de recursos. Node.js es un intérprete de lenguaje
Javascript que permite manejar muchas conexiones simultáneas en una sola máquina física.
Para escalar grandes volúmenes de clientes, todas las operaciones de entrada/salida en
Node.js se llevan a cabo de forma asíncrona. Node.js crea un loop que realiza las diferentes
tareas asíncronas, dicho bucle recibe las diferentes tareas junto con un callback. Cuando
finaliza el proceso en el loop se ejecuta el callback y envía la respuesta a la aplicación. El
loop gestiona todas las operaciones asíncronas. La consecuencia de este modelo
Entrada/Salida es que se puede atender a un alto número de clientes [25].

El servidor gestiona diferentes eventos como son: Conexiones, recepción de datos, cierre de
clientes, llamados a diferentes protocolos. Javascript es un lenguaje para programación
orientado a eventos, que permite funciones y cierres anónimos, fácil de codificar y
mantener. Node.js espera por un evento y se escribe una función de devolución de llamado
[26]. Node.js también se puede utilizar en aplicaciones monopágina21

6.3.1 CARACTERÍSTICAS.

Entre otras características de Node.js se destacan las siguientes:

 El estándar ECMA Script v6 (o ES6) gestiona la compatibilidad de JavaScript y

node.js [25]
 Node.js es asíncrono
 Programación orientada a eventos
 Ejecuta Javascript en el lado del servidor.
 Puede mantener tantas conexiones como número máximo de archivos descriptores
(sockets) soportados por el sistema. En un sistema UNIX este límite puede rondar
por las 65.000 conexiones.
 Debido a su arquitectura de usar sólo un hilo sólo podrá usar una CPU. Un método
para usar múltiples núcleos sería iniciar múltiples instancias de Node.js en el
servidor y poner un balanceador de carga delante de ellos [26].
 Uno de los puntos fuertes de Node.js es su capacidad de mantener muchas
conexiones abiertas y esperando.

21
Las aplicaciones monopágina son aquellas que se presentan en una única página web, emulando a las
aplicaciones de escritorio [25].

87
  Se programa en Javascript así que la curva de aprendizaje es corta una vez se ha
familiarizado con programación web.
 Un servidor es muy fácil de realizar en comparación con otras tecnologías.
 Tiene un api sencillo de aprender y no muy grande.
 Tiene su propio repositorio de módulos y es fácil de utilizar.
 Noje.js no crea un hilo por cada conexión y duerme mientras no se utiliza.
 Tiene un intérprete en línea de comandos
 Tiene una de las mayores comunidades de github y la mayor cantidad de
repositorios a la fecha (323.938).

6.3.2APLICACIONES DE NODE.JS.

Entre otros desarrollos, Node.js se usa hoy principalmente para [26]:

 Juegos online y chats.

 Web tiempo real.
 Gestores de correo online: podríamos ver notificaciones en tiempo real de nuevos
correos recibidos.
 Herramientas de colaboración.
 Redes sociales: por ejemplo para actualizar automáticamente tu muro de novedades.
 Herramientas de traducción en tiempo real.
 Aplicaciones para línea de comandos y scripts para administración de sistemas.
 Aplicaciones web que necesiten una conexión persistente con el navegador del
cliente. Mediante una serie de técnicas llamadas Comet, se posible hacer una
aplicación que envíe datos al usuario en tiempo real; es decir, que el navegador
mantenga la conexión siempre abierta y reciba continuamente nuevos datos.

6.3.3 TIEMPO REAL Y NODE.JS.

Se define un sistema de tiempo real como “un sistema que responde a un estímulo externo
dentro de un tiempo especificado. Su eficiencia no solo depende de la exactitud de los
resultados de cómputo, sino también del momento en que los entrega. La predictibilidad es
su característica principal. Los sistemas de tiempo real deben asegurar la distribución de
recursos de tal forma que se cumplan los requerimientos de tiempo” [27]. Node.js se
aproxima a la definición de las aplicaciones en tiempo real flexible (soft real-time). Los
sistemas de tiempo real flexible son aquellos en los que las restricciones de latencia son
flexibles: se pueden perder plazos, es decir, la respuesta al estímulo no cumple las
condiciones de tiempo impuestas, y además el valor de la respuesta decrece con el tiempo
pero no acarrea un desenlace fatal [28]. Node.js es similar en su propósito a otras
aplicaciones como Twisted o Tornado de Python, Perl Object Environment de Perl, React
de PHP, libevent (también libev) de C, Event Machine de Ruby, vibe.d de D y en Java
existe Apache MINA, Netty, Akka, Vert.x, Jetty, Grizzly o Xsocket, ente otros [26].

88
 6.4 DISEÑO FRONT-END.

Para el diseño de la interfaz del usuario se ha optado por el uso del llamado diseño web
responsivo o adaptativo, este propone eliminar la necesidad de diferentes tipos de diseños
para distintas resoluciones de pantalla. Comúnmente el desarrollo de una aplicación debe
soportarse teniendo en cuenta parámetros como el tamaño de pantalla, el tipo de dispositivo
y la orientación. La idea es que un sólo diseño se adapte de manera automática a las
características de pantalla [29]. El concepto se le atribuye a Ethan Marcote, en el artículo
de la revista online “A List A part” [30] del año 2010, allí se describen las técnicas y
conceptos básicos que deben asumirse a la hora de implementar un diseño responsivo. Se
aplican cuatro conceptos claves para el Responsive Web Design [31]:

1. Media Queries que nos ofrece CSS3 el cual posibilita usar estilos teniendo presente
parámetros de la pantalla.
2. Diseño web fluido, se trata de layouts definidos en porcentajes que se ajustan a los
anchos de la pantalla.
3. Elementos fluidos dentro de estos layouts, estos son las imágenes o elementos
multimedia.
4. Fuentes tipográficas con valores relativos.

Al crear un sitio con Responsive Web Design sólo se requiere una única versión de HTML
y CSS que funcionan adecuadamente en cualquier tipo de dispositivo y resolución. Entre
los beneficios del diseño web responsivo se encuentran la reducción de costos, eficiencia en
el mantenimiento y actualización del código, mejora en la usabilidad, capacidad de
adaptación de la interfaz, utilización de imágenes, videos y otros medios, tamaño relativo,
única dirección del sitio web (URL) [31], entre otros.

6.4.1 FRAMEWORK FRONT-END.

Un framework para front-end es un conjunto de elementos y herramientas que dan un

marco de trabajo para los diseños web. El objetivo de estos frameworks es proporcionar
una estructura común para desarrolladores web, agilizando el proceso de inicialización y
aportando reutilización de elementos básicos y repetibles. [30]. Estos frameworks suelen
consistir en una estructura de archivos y directorios de código estándar divididos en
elementos HTML, CSS y Javascript. En general la mayoría de estos frameworks comparten
características comunes tales como proporcionar código CSS para diseñar layouts,
conocidos como grids o cuadriculas, que suelen contener definiciones de tipografía, que
brindan soluciones para el problema de las incompatibilidades de los distintos navegadores
(como reset css) y componentes avanzados de interfaces de usuario.
89
 6.4.2FRAMEWORK BOOTSTRAP.

Twitter Bootstrap es un framework o conjunto de herramientas de software libre para

diseño de sitios y aplicaciones web. Contiene plantillas de diseño con tipografía,
formularios, botones, cuadros, menús de navegación y otros elementos de diseño basado en
HTML y CSS, así como, extensiones de Javascript. Bootstrap está disponible en GitHub.
En agosto del 2011, Twitter liberó a Bootstrap como código abierto. El código fuente
descargado está estructurado en tres directorios con una pequeña cantidad de ficheros
fácilmente reutilizables e integrables en el proyecto. Concretamente se hace uso de los
siguientes directorios:

CSS: Esta carpeta contiene dos ficheros CSS más sus versiones minimizadas. Los ficheros
son bootstrap.css y bottstrap-responsive.css. Estos ficheros se emplean para configurar los
elementos de la web. La versión responsive incluye todos los componentes necesarios para
incluirlos en el proyecto.
JS: Esta carpeta incluye el fichero bootstrap.js además de su versión minimizada donde se
encuentra todo el código Javascript necesario para el correcto funcionamiento de los
widgets de Bootstrap.
IMG: Esta carpeta incluye los sprites empleados para emplear los iconos de Bootstrap
cedidos por Glyphicons.

El empleo del framework Bootstrap aporta facilidad de uso, agilidad de desarrollo,

reutilización del código aportando un sencillo mantenimiento y aplicaciones ejecutables en
cualquier navegador. La decisión del empleo de un framework supone un equilibrio entre
las necesidades del proyecto, la experiencia del desarrollador o desarrolladores y de la
finalidad del proyecto [31].

6.4.3. CRITERIOS DE DISEÑO PARA EL DESARROLLO DE LA INTERFAZ

WEB.

Se diseñó una interfaz que se pueda usar y visualizar correctamente en un smartphone,

tablet, PC o portátil, multiplataforma, fácil de entender y utilizar, intuitiva, fácil de
mantener y depurar. A partir de las necesidades del proyecto se definieron los siguientes
criterios para su diseño:

90
 1. Diseño que se adapte a cualquier resolución de pantalla.
2. Un menú donde se puedan visualizar tanto los objetos IoT de medición de
consumo eléctrico como de agua y poder conocer su estado (online/offline).
3. Tablas de Historial.
4. Un protocolo de comunicación rápido en la transmisión de mensajes desde/hacia
el servidor.
5. Tamaño en bytes lo más reducido posible.
Se desarrollaron cuatro interfaces HTML principales:

1. Inicio de sesión y registro de nuevo usuario: Formulario donde está el nombre,

contraseña y correo del nuevo usuario obligatorio para el ingreso a todos los datos de los
objetos IoT asociados a un usuario.
2. Asociar dispositivos con el usuario: Formulario donde se incluyen los datos de
asociación del dispositivo como:
- Key: Identificador único de cada dispositivo.
- Nombre o Apodo: Nombre de fácil recordación del dispositivo
- Valor de kw/h o m3: De acuerdo al tipo de dispositivo se coloca el valor de kw/h o
metro cubico.

3. Interfaz de consumo de agua: Se incluyen,

- Graficas de historial que varían de años a meses, días, horas y minutos ,
- Grafica de tiempo real,
- Variables de consumo y costos.

4. Interfaz de consumo de energía eléctrica: Se incluyen,

- Graficas de historial que varían de años a meses, días, horas y minutos
- Grafica de tiempo real,
- Variables de consumo y costos.
- Botón de ON/OFF para apagar o encender la carga conectada al dispositivo.

Adicional a los criterios previos de diseño se incluyeron los siguientes elementos:

1. Se realizó una sola aplicación web que permite usar dicho diseño en cualquier
sistema operativo como son Windows, IOS, Android, versiones de Linux (no
depende del SO).
2. Se hace uso de Bootstrap en su versión 3 como framework de desarrollo.
3. Se hace uso de Websocket como protocolo de comunicación cliente/servidor.
4. Los mensajes se envían y reciben estructurados en JSON. Este es un formato
óptimo para almacenar variables en lenguaje Javascript que aporta velocidad en la
transmisión de mensajes.
5. Se utiliza HTML5como lenguaje de la World Wide Web. En su última versión
contiene una gran cantidad de nuevos protocolos que facilitan el diseño y la carga
de la página.
6. Se utiliza la librería jquery en código Javascript para interacciones de la página.
Esto hace que la aplicación sea intuitiva, fácil de entender y manejar.

91
 6.5. FUNCIONAMIENTO DEL SERVIDOR.

El servidor Node.js efectúa las tareas de conexión, desconexión, gestión de solicitudes de

objetos IoT y de usuarios. Se encarga igualmente de conectarse a la base de datos, efectuar
las consultas a la misma y alimentar los datos de los eventos de consumo provenientes de
los objetos IoT. La construcción del programa se efectuó en lenguaje Javascript el cual
Node.js permite usar en el lado del servidor. Se muestran las rutinas principales de la
operación del servidor teniendo en cuenta que se maneja un objeto Websocket por cada
conexión de cliente en el mismo hilo.

6.5.1. INICIO DE SERVIDOR.

Al ejecutar el llamado del servidor este efectúa una serie de pasos de configuración antes de
quedar listo para crear y gestionar las peticiones Websocket como se muestra en la figura 5.

Figura 5. Rutina de inicio del servidor Node.js.

Primero se inicia un servidor HTTP para escuchar las solicitudes de conexión a Websocket
(negociación) tal como se estableció en la sección 6.2.1.1. Se crea seguidamente un objeto
Websocket que maneja la conexión para cada uno de los clientes del servidor. El mismo
queda en espera de solicitudes entrantes, y al llegar una, efectúa la negociación para
seguidamente hacer la conexión a la base de datos si esta no llegase a estar activa. En caso
de que la conexión a la BD falle, el servidor envía un mensaje de error y cierra el socket. Si
la conexión a la BD es exitosa, el objeto manejador del socket inicia la gestión de eventos,
que para el caso de la conexión inicial genera un evento “open” como se mencionó en la
sección 6.2.2.1. En este caso el servidor determina el tipo de cliente que se ha conectado
como se muestra en la figura 6.

92
 Figura 6. Atención de interrupción de inicio de socket (USA: matriz de objetos de medición de consumo de
agua, USE: matriz de objetos de medición de consumo de energía, USI: matriz de usuarios web).

Para determinar el tipo de cliente se hace uso del encabezado HTTP de la negociación del
Websocket. La URL asociada a la petición debe contener el nombre del dispositivo (en
adelante se denominará key), dicha key es única para cada objeto IoT y genérica para las
conexiones de usuarios de dispositivo (tablet, PC, entre otros), cada nombre debe iniciar
con una sigla así:

- "se": Usuario de dispositivo de consumo eléctrico.

- "sa": Usuario de consumo de agua.
- "in": Usuario que inicia sesión en la interfaz principal.
- "ob": Objeto IoT.

Si el encabezado de la key no coincide con las establecidas la conexión no se admite y se

devuelve un mensaje de error. Para cada tipo de cliente una matriz almacena los datos de
conexión de cliente, esta es usada por el servidor para conocer el estado de las conexiones,
así como determinar si hay conexiones duplicadas (cuando un socket se cierra del lado del
cliente y envía una nueva solicitud de conexión). Si el cliente es un usuario se determina el
tipo de usuario y se devuelve el código HTML inicial correspondiente a la petición del
cliente. Para los objetos IoT el servidor realizará una búsqueda en la BD para saber si existe
una tabla con el nombre de la key, si no existe se concluye que es la primera vez que se
conecta el dispositivo al servidor y se creará una nueva tabla con el nombre de la key donde
se incluirán unos valores iniciales por defecto (figura 7). En esta tabla se guardará en
adelante la información que enviará el objeto IoT al servidor.

Figura 7. Asociación de objetos IoT a la base de datos.

93
 6.5.2. GESTION DE PETICIONES WEBSOCKET.

Como se vio en la sección 6.2.2.1, hay cuatro peticiones principales que puede generar un
objeto Websocket. Antes se han mencionado las acciones a seguir cuando se llama al
evento “open”, para el evento message las acciones a efectuar se muestran en la figura 8.

Figura 8. Atención de evento message del objeto Websocket.

Todos los mensajes que provengan de usuarios web, así como de objetos IoT hacia el
servidor deben estar estructurados como variables JSON. Inicialmente Node.js determina si
es posible parsear22 el paquete de datos Websocket obtenido, si no es posible se genera un
mensaje de error como atención del evento. Una vez establecido el arreglo de datos se
determina el origen de la solicitud de los mensajes, se manejan tres tipos:

- Hora: El usuario web o el objeto IoT pueden solicitar la hora del servidor mediante el
JSON{"id":"id_objeto","hora":1"} El servidor responderá con un paquete Websocket
conteniendo la hora del servidor como una cadena de caracteres iniciando con asterisco
(“*”) seguido de la hora en formato DATETIME de Javascript (compatible con MySQL) y
terminado en espacio (caracteres de borde para la terminal del ESP8266 definidos en la
sección 5.6.4), por ejemplo “*2016-06-14T20:47:33 “

- Usuario: Si el JSON proviene de un usuario, se determina el tipo de objeto dentro del

código Javascript del lado del cliente que realizó la petición y se ejecuta la función que
corresponda (Ejecuta acción usuario en figura 8), las peticiones que se pueden atender son:
22
Parsear (analizar gramaticalmente) hace referencia a la extracción automática de las variables contenidas
en un objeto JSON en un array con los nombres y valores de las variables incluidas en el mismo. La función
tiene la forma (Javascript): varmi_array=JSON.parse(message);

94
 - "agregar": Asocia un sensor nuevo a un usuario ya existente.
- "grafica-barras-meses": Envía los datos necesarios para realizar la suma del
consumo acumulado y cuenta el número de eventos del ID asociado para todos los
meses del año seleccionado por el usuario en el back-end.
- "grafica-barras-meses-electrico”:Realiza una suma del acumulado y cuenta el
numero de eventos de ID asociado para el mes seleccionado
- "grafica-barras-dias": Semejante a los anteriores, calcula el consumo acumulado
de agua y cuenta el numero de eventos de ID asociado para el día seleccionado.
- "grafica-barras-dias-electrico": Calcula el consumo acumulado de energía y
cuenta el numero de eventos de ID asociado para el día seleccionado.
- "grafica-barras-horas": Calcula el consumo acumulado de agua y cuenta el
numero de eventos de ID asociado para la hora seleccionada.
- ”grafica-barras-horas-electrico": Calcula el consumo acumulado de energía y
cuenta el numero de eventos de ID asociado para la hora seleccionada.
- "grafica-barras-minutos": Calcula el consumo acumulado de agua y cuenta el
numero de eventos de ID asociado para el minuto seleccionado.
- "grafica-barras-year": Devuelve los datos para la visualización de los detalles de
consumo de los dispositivos activos.
- "cambio-valor-m3”: Modifica el valor de referencia que se usa para calcular el
valor del consumo medido de los objetos IoT.
- "estado-on-off": Envía y/o modifica el estado del interruptor de los dispositivos
conectados a los usuarios de dispositivos de medición eléctrica.
- "ping": Devuelve un pong de acuerdo a lo establecido en la norma RFC6455 de
Websocket.

- Objeto IoT: Si el JSON proviene de un dispositivo de medición, se determina el tipo de

dispositivo (“se” eléctrico, “sa” agua). En este caso se tratará siempre de una muestra de
consumo (tiempo real o acumulado) tal como se definió en la sección 5.6. Para cada caso el
servidor determinará el tipo de dato (valor “td”), generará una consulta a la BD
almacenando en la misma el valor de consumo indicado en la trama JSON.

El evento Close se produce al desconectarse algún cliente del servidor que se encontrara
conectado a través de un Websocket, el servidor gestiona este evento como se muestra en la
figura 9. Para todos los casos se identifica el tipo de cliente (objeto IoT o usuario web) y se
procede a quitar los datos del objeto Websocket asociado en la matriz del tipo de objeto
conectado al servidor.

El evento Error se presenta cuando se presenta alguna inconsistencia en los paquetes

Websocket provenientes de los clientes o cuando el servidor es incapaz de comprender o
gestionar la petición, en este caso el servidor devolverá un mensaje de error. Si el error
compromete la comunicación, el servidor enviará un paquete con el código 1002 y cerrará
la conexión según lo establecido en la norma RFC 6455.

95
 Figura 9 Atención de evento close del objeto Websocket.

6.5.3. PETICIONES HTTP DE USUARIO WEB.

Los usuarios de la plataforma acceden mediante el uso de dos tipos de perfiles: Un perfil
público que pertenecerá a cada objeto IoT y al que se puede ingresar mediante la lectura de
la etiqueta QR asociada al objeto. El otro perfil es privado y se accede mediante la
validación de credenciales en el portal como se describe seguidamente. La diferencia entre
los dos radica en la cantidad de información que se puede obtener del objeto. El perfil
público únicamente muestra los datos de consumo de tiempo real del objeto IoT mientras
que el perfil privado permite consultar los consumos históricos así como configurar los
parámetros propios del grupo de objetos asociados a la cuenta del usuario.

6.5.3.1. Inicio de sesión y registro de nuevo usuario.

Al ingresar en la plataforma desde la página principal (key inicio), el usuario tiene dos
opciones para registrarse:

1. Como nuevo usuario donde ingresa el nombre, contraseña y correo.

2. Como usuario registrado en donde sólo ingresa el nombre y la contraseña
registrada.

Como se muestra en la figura 10, en el primer caso, el sistema verifica la información en la

BD, si no hay datos repetidos de nombre y correo se guarda el nuevo usuario en la
plataforma, en caso contrario envía un mensaje de error de datos repetidos. En el caso de
ser un usuario registrado, se verifican las credenciales de acceso, si se encuentran
incorrectamente diligenciadas se genera un aviso de error de validación incorrecta. En
cualquiera de los dos casos, al lograr el ingreso con éxito, el servidor carga el HTLM
correspondiente a la pantalla principal del usuario, donde se pueden agregar los objetos así
como acceder a los detalles de los objetos IoT del usuario registrado.

96
 Figura 10. Flujo del inicio de sesión de usuario.

6.5.3.2. Asociar dispositivos al usuario.

Una vez validadas las credenciales del usuario este tiene la posibilidad de asociar nuevos
dispositivos ingresando los datos de key del objeto IoT (Figura 11). El identificador único
para cada dispositivo (key) estará impreso en la carcasa que protege de la electrónica del
objeto IoT. Los datos a diligenciar por parte del usuario son:

- Key: Identificador del objeto IoT

- Nombre o apodo: Es el nombre por el cual el usuario recordará con mayor
facilidad el dispositivo, el nombre puede ser cualquiera.
- Valor del KW/h o m3: De acuerdo al tipo de dispositivo de medición del objeto
IoT se coloca el valor en pesos (o cualquier moneda) del KW/h de energía o del m3
de Agua potable.

Figura 11. Flujo de asociación de objetos IoT al usuario

Ingresados los datos para agregar el nuevo dispositivo el sistema verifica que la key tenga la
sintaxis correcta y que no exista en la BD. Si los datos son correctos, la información se
guarda en la BD y seguido se envía un mensaje de éxito. En caso contrario se envía un
mensaje con los siguientes códigos del error:

97
 - ERROR 00: Verifique la KEY si es correcta. Tampoco se recibe señal del
dispositivo verifique que esté conectado correctamente.
- ERROR 01: El dispositivo ya existe en la tabla dispositivos verifique la KEY.
- ERROR 11: El dispositivo ya existe (con otro usuario) verifique la KEY.

6.6. PRUEBAS DEL SERVIDOR WEB.

Durante el desarrollo del software front-end y back-end se han usado diversos recursos de
software y hardware a fin de corregir los problemas en la evolución de la propuesta. En
general las características del entorno de pruebas del servidor han sido las siguientes:

- Servidor: Node.js- versión 4.2.3

- Gestor de paquetes de Javascript: NPM - versión 2.14.7
- Administrador PHP: Phpmyadmin con Wampserver- versión 4.3.11
- URL del servidor: http://localhost:3000/
- Dirección IP: 192.168.1.53
- Puerto del Servidor: 3000
- Nombre archivo del servidor: server_(número de versión).js
- Sistema operativo: Windows 7 de 64 bits
- Procesador: AMD Athlon(tm) X2 340 Dual Core Procesador (2 CPU), 3.2 GHZ
- Memoria RAM: 4GB DDR3
- Servidor de base de datos: MYSQL - versión 5.6.24
- Nombre base de datos: usuario_1
Exploradores utilizados:
Firefox - versión 42.0 a 47.0.1
Google Crome - Versión 51.0.2704.103 m

6.6.1 INSTALACIÓN DE NODE.JS

Para instalar Node.js Inicialmente se descarga de la web oficial como se describe en su web
oficial23. Se instala y verifica la versión con el comando “node –v” en cmd de Windows
como se muestra en la figura 12.

Figura 12. Comprobación de la versión instalada de Node.js

En la ruta donde se escribe el servidor se crean las siguientes carpetas y archivos:

23
https://nodejs.org/about/

98
Carpetas:
- node_modules: Carpeta que contiene las librerías que utiliza Node.js para su
funcionamiento.
- public: Carpeta donde se alojan los archivos HTML (CSS, imágenes, Javascript).
- router: Carpeta donde están los archivos de configuración de la base de datos.
Archivos:
- server.js: Archivo donde se encuentra escrito el servidor
- package.json: Este archivo contiene varios metadatos relevantes para el proyecto.
Se utiliza para dar información a la NPM que le permite identificar el proyecto, así
como manejar las dependencias, descripción y versión del proyecto en una
distribución particular y la información de licencia.

Una vez instalado el servidor y ubicados los archivos propios del proyecto en su carpeta
correspondiente se escribe el comando “node<nombre del archivo del servidor>” en la ruta
donde se encuentra el servidor como se muestra en la figura 13.

Figura 13. Inicio del servidor en Node.js

6.6.2. PRUEBAS DEL SERVIDOR LOCAL CON LA BASE DE DATOS

Inicio de interfaz eléctrica: Si un usuario abre la interfaz HTML de un dispositivo eléctrico

el servidor lo guarda temporalmente en una matriz donde le asocia la key. En este caso
como es el primer cliente aparece como Cliente Eléctrico N°1 Figura 14.

Figura 14. Asociación de interfaz de usuario al servidor

Conexión inicial de dispositivo: En la figura 15 se visualiza el proceso de conexión en un

servidor de pruebas. Una vez establecido el socket, el servidor abre la base de datos como
se describe en la sección 6.5 (recuadro azul), seguidamente el objeto IoT solicita la hora del
servidor para actualizarla en el microcontrolador, el servidor responde a la petición como se
describe en la sección 6.5.2 (recuadro violeta).El objeto IoT envía el JSON que contiene la
medición acumulada previa a su última conexión y/o al acumulado desde el momento de la
activación como se describe en la sección 5.6 (recuadro rojo). Si es la primera vez que el
objeto se conecta, el servidor crea una nueva tabla en la base de datos con el nombre de la
key (“id” en la cadena JSON). En el ejemplo se muestra el comportamiento del servidor

99
cuando se conecta por primera vez el dispositivo con key= se_002 (recuadro aguamarina),
este crea una nueva tabla en la base de datos donde se relacionarán todos los eventos de
consumo del objeto IoT se_002 (recuadro café en el listado de tablas de PHPMyAdmin).

Figura 15. Conexión de objeto IoT nuevo al servidor y creación de tabla en la base de datos. Arriba: Cmd de
Windows (consola del servidor Node.js), abajo: lista de tablas de la BD en PHPMyAdmin.

Crear un nuevo usuario: Al crear un nuevo usuario el servidor lo guarda en la tabla de

nombre de usuarios como se muestra en la figura 16, de acuerdo a lo visto en el numeral
6.5.3.1.
Asociar Dispositivo al usuario: Al asociar el dispositivo al usuario respectivo el servidor lo
incluye en la tabla “Dispositivos” (figura 15 y 16). Supongamos que se quiere asociar el
dispositivo con: key=se_003, Nombre o apodo=lámpara y Valor kw/h=250. El resultado es
el mostrado en la figura 17.
Asociar un dispositivo con key en uso: Si se quiere agregar un dispositivo con una “key”
ya registrada en la base de datos, el servidor realizara la consulta respectiva y enviara el
mensaje de error al cliente web. Por ejemplo si se quiere agregar nuevamente el dispositivo
con la key=se_003 el servidor enviara un mensaje al cliente con el respectivo código de
error (Figura 17).

100
Figura 16. Creación de usuario nuevo en la base de datos. Arriba:Consola del servidor Node.js, abajo:registro
insertado en la tabla de usuarios de la BD en PHPMyAdmin.

Figura 17. Efecto en la consola del servidor de la asociación de un nuevo objeto IoTal un usuario.

Figura 18. Mensaje de error al tratar de asociar la key de un objeto a un usuario cuando la clave ya existe.

101
 6.6.3. PRUEBAS SERVIDOR WEB.

Para la implementación y uso del servidor en la web se estudiaron tres alternativas:

1. Servidor en IBM (https://console.ng.bluemix.net/)

2. Servidor en Heroku(https://console.ng.bluemix.net/docs/starters/install_cli.html)
3. Servidor Local configurado para funcionar en internet.

6.6.3.1. Servidor en IBM.

Para hacer uso del servicio inicialmente es necesario efectuar el proceso de registro y
creación de la aplicación en IBMbluemix, para el ejercicio se creó la aplicación de Node.js
con nombre “udistrital”, seguidamente se agregó el motor de base de datos MySQL el cual
es un servicio gratuito en Cleardb y se crearon las tablas del modelo relacional.

Para el despliegue del servidor se descargó e instaló el programa Cloud Foundry CLI que
despliega el servidor y permite su interacción por línea de comandos en el PC. En el código
del servidor, se colocan las variables de entorno que necesita la plataforma de IBM para
funcionar (puerto y host) en el archivo “server.js”:

const port = (process.env.VCAP_APP_PORT || 3000);

const host = (process.env.VCAP_APP_HOST || 'http://localhost');

Se deben ajustar las variables de conexión de la base de datos local por las suministradas
por la plataforma de IBM :

host:cleardb.net',
port: '3306',
user: 'b6163fef8db87e',
password: 'uuib69fe',
database: 'tyu930711fc95aedd1',

En el PC se ingresa al Cmd de Windows, se busca la raíz de la carpeta donde está ubicado

el archivo del servidor “server.js” y se escribe lo siguiente:

cflogin: Pide el correo y la contraseña de registro en IBM Bluemix (recuadro verde en la

figura 19).
cfpushudistrital: Sube los archivos al servidor, este realiza el cargue de la aplicación que
fue creada en bluemix con el nombre “udistrital”. Una vez llamado el comando push se
empezará a subir la aplicación desde el PC hacia los servidores de IBM en la aplicación
por nombre “udistrital” (recuadro rojo en la figura 19). Al terminar aparece el mensaje “la
App empezó OK” (figura 20).

En el panel de control de la plataforma de IBM, se indica la dirección web que entrega el

sistema para conectar al servidor (http://udistrital.mybluemix.net ver figura 21).
102
 Figura 19. Proceso de despliegue del servidor en Bluemix de IBM.

Figura 20. Despliegue realizado con éxito en el servidor Bluemix de IBM.

Figura 21. Panel de control de la App udistrital en IBM Bluemix

103
6.6.3.1. Servidor en Heroku.

Como antes, se efectúa el proceso de registro y creación de la aplicación en Heroku. En

seguida se crea la aplicación de Node.js con nombre “udistrital” (Se usa la base de datos
Cleardb de IBM).

Para el despliegue del servidor se requiere instalar primeramente git24, luego la herramienta
Heroku Toolbelt que permite utilizar la línea de comandos (CLI) de heroku25. Se debe crear
igualmente un archivo llamado Procfile (sin extensión), el contenido es “web: node
server.js” Luego se verifica en el PC el archivo donde está escrito el servidor “server.js” y
se colocan las variables de entorno que necesita la plataforma de HEROKU para funcionar
(puerto y host Javascript):

const port = process.env.PORT || 3000;

const host = process.env.IP || 'http://localhost';

En el PC se ingresa al cmd de Windows y desde allí se ingresa a la raíz de la carpeta donde

está ubicado el servidor con nombre “server.js” y se escribe:

Herokulogin: Pide el correo y la contraseña de HEROKU. Figura 22

Se agrega la referencia del repositorio de heroku con los siguientes comandos:

gitinit
herokugit:remote -a udistrital

Se hace el despliegue del servidor con:

git add
git commit -am "make it better"
gitpushheroku master

Una vez realizado el despliegue se empezara a subir la aplicación desde el PC hasta los
servidores de HEROKU en la aplicación por nombre “udistrital” (figura 23). Si todo se
sube con éxito debe mostrarse un mensaje de “Verifying deploy... done” (figura 24).

En el panel de control de Heroku en la App de udistrital, en la parte superior derecha hay

un botón que dice “open App” al pulsar se abre el enlace siguiente:
http://udistrital.herokuapp.com/

24
GIT es un software de control de versiones diseñado por Linus Torvalds, pensando en la eficiencia y la
confiabilidad del mantenimiento de versiones de aplicaciones cuando éstas tienen un gran número de archivos
de código fuente (disponible en https://git-scm.com/download/win).
25
Software disponible en https://toolbelt.heroku.com/

104
 Figura 22. Login para desplegar aplicación en el servidor de Heroku.

Figura 23. Ejecución de git push heroku master para desplegar la aplicación en Heroku.

Figura 24. Despliegue realizado con éxito en los servidores de Heroku.

6.6.3.1. Servidor local configurado para funcionar en la web.

Para configurar el servidor local en internet se usan las mismas herramientas de uso local
(hardware, software, entre otros), efectuando algunas modificaciones:

- Se cambia el puerto de escucha del servidor, del puerto 3000 al puerto 80.
- Se redireccionan todas las peticiones que lleguen al puerto 80 de la dirección IP
pública del router del ISP al puerto 80 de la IP privada del servidor local, que para
el ejercicio es: 192.168.1.53.
- Se habilita el servidor MySQL del PC local.

Para probar el servidor se realizan los siguientes pasos:

105
Se inicia el servidor escribiendo en la ruta raíz donde se encuentra el archivo el comando
“node server.js” tal como se efectuó en la sección 6.6.1 (Figura 13).
Al abrir el explorador de internet y escribir la dirección IP pública: 181.130.116.47. Se
verifica que abre correctamente (figura 25).

Figura 25. Front-end de inicio de sesión mediante la IP pública del ISP

Es posible asignar un nombre de dominio de la siguiente manera:

- Se ingresa a la página NO-IP (https://www.noip.com/) y se realiza el registro.

- Una vez dentro de la aplicación de NO-IP en la casilla de host-name se agrega un
nombre. Para el ejercicio queda como: “udistrital.ddns.net” (figura 26). Dado que la
IP pública que proporciona el proveedor de servicio de internet no es fija si no
dinámica, se descarga la aplicación que proporciona la página de NO-IP con
nombre DUCv4.1.1, luego se instala en el PC. Este programa mantiene sincronizado
el dominio con la dirección IP pública en caso que el proveedor de internet cambie
dicha IP (Figura 27).

106
 Figura 26. Asignación de nombre de dominio a la dirección IP: 181.130.116.47.

Figura 27. Programa DUC v4.1.1 para mantener sincronizada IP publica con dominio de NO-IP

6.6.3.2. Resultados de las pruebas de servidores.

A partir del despliegue y la experimentación de la aplicación en estas plataformas se

obtuvieron los siguientes resultados:

Se efectuaron modificaciones en la escritura del código del servidor a fin de que funcionara
adecuadamente para las pruebas locales y en la nube modificando únicamente las variables
de entorno y el puerto utilizado.

Se realizaron pruebas del comportamiento del Front-end. El framework Bootstrap funciona

adecuadamente en los dispositivos móviles probados (celular, tablet) así como en PC de
escritorio siempre y cuando las prestaciones de los dispositivos sean adecuadas (buena
capacidad de procesamiento para ejecutar Javascript y HTML5).

Los servicios en la nube de IBM yHeroku mostraron un comportamiento muy similar, los
tiempos de respuesta y la gestión de peticiones presentaron prácticamente las mismas
prestaciones. Ambos servicios dan soporte para node.js en diferentes versiones. Una de las
limitaciones de estos servicios gratuitos radica en que al desconectarse súbitamente un
dispositivo del servidor y volver a conectarse, después de unos minutos la plataforma se
desconecta automáticamente. El problema se debe al enrutamiento interno de estos
servicios.IBM y HEROKU no son completamente gratuitos, tienen cobros por bytes
enviados por segundos. La base de datos para probar los servicios de IBM y Heroku es de
la empresa Cleardb dando solo 5 MB de capacidad y una cantidad de usuarios limitada, esto
por ser una cuenta gratuita, suficiente para unas pruebas limitas pero no para una aplicación
completa.

La plataforma NO-IP es un servicio gratuito, después de 30 días hay que registrar

nuevamente el dominio, por lo que la asignación de DNS es útil sólo para efectuar pruebas.

107
Al usar la IP publica del ISP como dirección para el servidor en internet, es recomendable
tener una IP privada fija que no cambie dinámicamente. Esto garantiza poder usar el
servidor local como servidor web de forma permanente, o al menos por un periodo
suficiente para la implementación y puesta a punto de este trabajo. Es posible dejar
cualquier puerto como puerto de escucha, por ejemplo el 2000, en este caso se debe escribir
la IP pública o el dominio seguido de dos puntos y el número de puerto ejemplo:
http://181.130.116.47:2000/ o http://udistrital.ddns.net:2000/

.
6.7. CONCLUSIONES

Aunque las tramas de los mensajes enviados por Websocket se realizaron en ASCII
también es posible hacer en envío de los datos de forma binaria. El proceso de elaboración
del servidor exigió una etapa de análisis de datos donde fue más fácil trabajar con cadenas
de caracteres y por esa razón se escogió ese tipo de envío de datos. Node.js permite crear
un servidor que utiliza conexiones persistentes con el cliente con un consumo de recursos
mínimo y con el número de clientes simultáneos bastante elevado.

Al realizar una sola aplicación web, permite realizar un solo diseño para cualquier
Sistema Operativo. Es muy importante que el navegador que se esté utilizando este
actualizado en sus últimas versiones. Los mensajes desde el servidor y el cliente web se
envían por el protocolo Websocket y los datos de intercambio se envían en formato
JSON. Es muy importante aprender la estructura del formato JSON para escribirlo en el
microcontrolador.

Una de las ventajas de JSON sobre XML como formato de intercambio de datos es que es
mucho más sencillo de escribir y en Javascript un texto JSON se puede analizar fácilmente.

108
 7. ETIQUETADO E INTERACCIÓN DE OBJETOS IoT

Para lograr la interacción objeto-persona que se plantea en el internet de las cosas es

fundamental establecer el etiquetado de los objetos tal como se mencionó en el capítulo 1.
Para este trabajo se optó por un etiquetado de soporte pasivo de los más comunes que hay
en la actualidad y es el uso de códigos en dos dimensiones (2D). Existen diferentes tipos de
códigos 2D (Microsoft Tag, AztecCode, Maxicode, Code16K, BIDI, Datamatrix, QR, entre
otros) estos representan información de forma visual para permitir su lectura automática,
rápida y sin errores por parte de un escáner. La principal diferencia entre ellos es la forma
de representar la información y la cantidad de datos que son capaces de almacenar en el
mismo espacio (densidad de información). Los códigos QR (del inglés Quick Response
code, "código de respuesta rápida") son los códigos 2D más extendidos en la actualidad,
estos pueden almacenar información alfanumérica, binaria o caracteres del japonés
(Kanji/kana). A diferencia de los códigos de barras, la codificación QR en 2D hace posible
almacenar una mayor cantidad de información en un espacio menor (figura 1).

Figura 1. Comparación entre un código de barras unidimensional (Derecha) y uno 2D (izquierda). Mientras el
código de barras almacena información en una sola dirección, un QR almacena la misma información en 2
dimensiones con un uso menor de espacio.

La codificación QR se encuentra reglamentada en dos normas: La norma QR-Code model1

(modelo original, norma ISO (ISO/IEC18004):1998), y la norma QR-Code model2
(modelo extendido, norma ISO (ISO/IEC18004):2005). La principal diferencia entre estas
es la existencia de diversos métodos de producción que permiten ubicar la simbología sobre
variados sustratos en el model2 siendo este el que se usa por defecto en la actualidad. El
conjunto de caracteres que es posible codificar en una etiqueta QR consiste en:

Numéricos (0-9): Secuencias de3 caracteres se codifican con una longitud de 10 bits. En
teoría es posible almacenar hasta 7089 caracteres numéricos en una etiqueta QR.
Alfanuméricos (0-9A-Z $% * + -. / :): En total 45 caracteres, grupos de dos caracteres se
codifican en una secuencia de 11 bits. Es posible escribir hasta 4296 caracteres en una
etiqueta QR.
Bytes de datos de 8 bits: Hasta 2953 caracteres se pueden almacenar en una etiqueta QR.

109
Caracteres KANJI26: Un único carácter de kanji se codifica en una secuencia de 13 bits,
en teoría es posible almacenar hasta 1817 en una etiqueta QR.

La codificación QR posee una función de corrección de errores de lectura basada en puntos

negros (bits) sobre un fondo blanco, se han definido cuatro niveles de corrección (también
llamados de redundancia):

Nivel L: 7% o menos errores se pueden corregir (baja).

Nivel M: 15% o menos errores se pueden corregir (media).
Nivel Q: 25% o menos errores se pueden corregir (alta).
Nivel H: 30% o menos errores se pueden corregir (muy alta).

Las partes componentes de una etiqueta QR se dividen en patrones de ajuste, información

de la versión, del formato, y corrección de errores y datos (Figura 2). Los patrones de ajuste
se dividen a su vez en tres componentes: El patrón de posición, cuyo propósito es
determinar el marco de la etiqueta en el entorno donde se encuentra. El patrón de
sincronización, que corresponde a una secuencia binaria 10101010…. y permite al escáner
dimensionar la ubicación de la cuadrícula de filas y columnas. Finalmente el patrón de
alineamiento que permite un ajuste más preciso cuando el tamaño de la etiqueta es grande.
Estos patrones pueden estar distribuidos de forma iterativa según el tamaño total de la
etiqueta.

Figura 2. Elementos componentes de una etiqueta QR.

La versión es un indicador de la cantidad de información almacenada de acuerdo al tamaño,

esta se junta con el nivel de corrección de errores para determinar la capacidad final de una
etiqueta en particular. El formato indica el modo de representación y el agrupamiento de
bits correspondiente a cada modo, los primeros 4 bits representan el conjunto de caracteres
(numérico: 0001, alfanumérico: 0010, bytes de 8 bits: 0100, KANJI: 1000), el restante, de
un total de 26 bits, se dedican a la codificación del agrupamiento, se completa con ceros en
caso de que el codificador tenga una longitud menor que el campo reservado.
Los datos se codifican mediante un código cíclico Reed-Solomon, éste se forma sobre
grupos de bits denominados símbolos. La codificación/decodificación se da entonces con
base a los grupos de símbolos definidos en el estándar, dichos símbolos corresponden a
valores numéricos que a su vez se hacen coincidir con los modos de acuerdo al
agrupamiento establecido.

26
Los kanjis (漢字kanji, literalmente «carácter han») son los caracteres utilizados en la escritura del idioma
japonés, aunque su origen es Chino. Estos se usan en para expresar conceptos, a diferencia del chino, donde
pueden emplearse también como fonemas.

110
 7.1 GENERACIÓN DE CÓDIGOS QR

En sus inicios lo códigos QR se utilizaron para registrar repuestos de automóviles e

inventarios. Actualmente los smartphone y otros dispositivos inteligentes decodifican estos
códigos de manera sencilla y económica. Fundamentalmente se usan para escribir
direcciones web donde permiten el ingreso más rápido a una página ya que los usuarios se
libran de la tarea de ingresar las direcciones de manera manual [32]. Existen entidades
dedicadas a la elaboración y distribución de las etiquetas QR de acuerdo al entorno donde
se aplican (industrial comercial, entre otros), para la mayoría de los casos una etiqueta
sencilla, donde se garantice el adecuado contraste entre el fondo y los símbolos es más que
suficiente para la lectura por parte de un dispositivo inteligente. Muchas páginas web
ofrecen el servicio de codificación de manera gratuita, por lo que ese ha sido el método
usado para la generación27.

Como se mencionó en la sección 6.5.3, la identidad virtual de cada objeto IoT estará
dividida en dos perfiles, uno público, al que cualquier usuario con un dispositivo inteligente
pueda acceder, y uno privado, reservado para el usuario que tiene asociado el objeto como
su propietario. La idea es que cualquier usuario sin registrar tenga la posibilidad de conocer
el estado del objeto IoT (de medición de energía eléctrica o agua potable). En dicho caso la
identidad virtual corresponde a una página llamada “perfil público”. La etiqueta QR
contiene entonces la codificación de la dirección web del perfil público del dispositivo. Una
vez se establece la dirección del perfil publico del dispositivo de acuerdo a su id particular
y la ubicación del servidor en la red, se tiene toda la información de la dirección web, esta
se diligencia en la página generadora de códigos QR (como ejemplo los códigos de la
figura 3); obtenido el código se imprime y coloca al objeto. En el caso de la medición de
agua resulta mucho más práctico que la etiqueta se coloque en o muy cerca del aparato
consumidor; en el caso del objeto de medición de energía, la etiqueta se ha colocado al
frente y al costado de la carcasa protectora del circuito, aunque no es descartable colocarla
en el electrodoméstico si resulta más cómoda la lectura.

Figura 3. Ejemplos de códigos QR generados para el acceso a un servidor local configurado para funcionar en
la web como se describió en la sección 6.6.3.1 (Derecha sensor agua sa_001en nivel M, izquierdo sensor
eléctrico se_002 en nivel L).

27
Existe una gran diversidad de páginas dedicadas a la elaboración de los códigos QR, para este trabajo se
usaron: www.codigos-qr.com, www.qrcode.es, www.qrcode-monkey.com y www.visualead.com

111
 7.2 PASOS PARA EL ACCESO AL OBJETO IoT MEDIANTE CÓDIGOS QR.

La secuencia que se debe seguir para que cualquier usuario tenga acceso a la identidad
virtual del objeto IoT es como sigue:

1. El dispositivo debe estar conectado a la red y enviando información al servidor. En

caso de que el dispositivo esté inactivo, será posible ver el perfil, pero este no tendrá
datos de monitoreo de tiempo real.
2. La etiqueta QR debe estar ubicada en un punto donde sea fácilmente accesible al
dispositivo smart del usuario.
3. El dispositivo smart debe tener una conexión a internet, poseer cámara y el software
necesario para leer el código QR28
4. Mediante la cámara, el software hace el escaneo del código QR del objeto IoT,
obteniendo la URL de la identidad virtual y de manera automática lo llevará a dicha
página.

Dependiendo del tipo de dispositivo se cargará uno de los dos perfiles públicos, que puede
ser el del eléctrico o el del agua potable

Los perfiles públicos no permiten observar los consumos históricos (año, mes, día), ni
tampoco el costo del evento. Se considera que esta información es de interés para el usuario
asociado al dispositivo (propietario), por lo que la misma sólo se puede acceder si
previamente se han validado las credenciales del usuario. Con este ejercicio de etiquetado y
acceso por red se ha completado el ejercicio de efectuar una medición de parámetros de
consumo de energía eléctrica y agua potable, con una interacción básica hacia al usuario
haciendo uso de los conceptos asociados a la denominada internet de las cosas.

28
Existen diversidad de aplicaciones para la lectura de códigos QR, para las pruebas efectuadas se usaron las
Apps gratuitas para Android QR Droid y QR BarcodeScaner.

112
 8. CONCLUSIONES Y CONSIDERACIONES FUTURAS.

8.1 CONCLUSIONES.

El trabajo desarrollado ha logrado el diseño e implementación de un sistema de medición

de consumo de energía eléctrica y agua potable remoto con interacción al usuario basado en
el concepto "Internet de las cosas" Se han establecido los métodos de medición de energía
eléctrica y agua potable para la lectura de los datos que son capturados y enviados por el
dispositivo de comunicación ESP8266 que ha sido seleccionado. Igualmente se ha diseñado
e implementado una plataforma de software de comunicación y almacenamiento de datos
usando tecnologías afines a las necesidades del Internet de las cosas como Websocket y
Node.js, que aprovechan una comunicación bidireccional, full dúplex y en “tiempo real”.
Finalmente se ha logrado el vínculo entre objetos reales y sus identidades virtuales
mediante etiquetado 2D. El sistema permite la interacción con la identidad virtual desde
cualquier lugar usando dispositivos inteligentes con características disímiles de hardware y
software, aprovechando los recursos de HTML5 y frameworks disponibles para interactuar
directamente desde un navegador de internet, evitando así la instalación de APPs u otros
programas informáticos.

La identidad virtual de los objetos elaborados se ha centrado en los datos colectados, estos
constituyen un registro del historial de consumo en una base de datos, almacenados por
eventos de consumo y que se pueden consultar en la interfaz en intervalos de minutos,
horas, días, meses y años. Estos datos son útiles para conocer los detalles del consumo y
eventualmente tomar decisiones sobre el comportamiento de los aparatos consumidores.
Cada objeto IoT se ha identificado con una key única que brinda acceso a sus datos
particulares en la web. La interfaz HTML es intuitiva y fácil de manejar, adaptándose a
cualquier tipo de resolución de pantalla.

El protocolo Websocket resultó ser muy adecuado para establecer y mantener la

comunicación de datos entre los objetos IoT y la red. Los mensajes estructurados en
formato ASCII podrían modificarse a tramas en binario, reduciendo el tamaño de los datos
a fin de mejorar la velocidad de respuesta en un escenario de alto volumen de conexiones.
Dado que los paquetes Websocket enviados desde el servidor al MCU no se enmascaran (el
protocolo RFC 6455 lo indica de esta manera), se elaboró un protocolo orientado a
conexión sencillo y ligero para enviar los mensajes desde el servidor al MCU de modo que
fuesen fácilmente identificados e interpretados desde la terminal del ESP8266.

Por simplicidad los mensajes que se envían desde cualquier dispositivo se envían con una
misma cabecera Sec-WebSocket-Key. El valor de este campo debe ser un valor de 16 bytes
seleccionados al azar que tiene que haber sido codificado en base 64. Lo indicado y según
el protocolo es generar una Key para cada negociación que se realice con el servidor, es
decir, con cada dispositivo o usuario conectado mediante un Websocket.

117
Los servicios en la nube (IBM, HEROKU) comparten varias características comunes, estos
servicios desconectan el Websocket “por conexión ociosa” después de 1 o 2 minutos de no
presentarse ninguna transacción de información entre el cliente y servidor. Teniendo en
cuenta esta característica los usuarios web envían un mensaje hacia el servidor (ping) para
mantener la conexión abierta.

La identidad virtual Un objeto IoT, del mismo modo que una persona, deberá tener perfiles
de acuerdo a la cantidad y la naturaleza de la información que convenga compartir con
otros dispositivos o usuarios. Se ha logrado hacer un ejercicio simple donde se demuestra la
factibilidad de que un objeto IoT posea un perfil público de fácil acceso a través de códigos
QR. El etiquetado QR en los dispositivos facilita el acceso al dispositivo pues evita que se
tenga que direccionar de forma manual la URL o dirección de la identidad virtual. Los
códigos QR crean el vínculo inicial entre los dispositivos, es deber del diseñador, de
acuerdo a la naturaleza y el propósito de los objetos inteligentes, determinar cuáles son los
alcances y límites en la durabilidad, ubicuidad y perfiles asociados a ese vínculo. Para este
ejercicio no se ha puesto ninguna restricción de tiempo o ubicación una vez establecido el
vínculo, empero, en una IoT con fines prácticos, serán necesarias dichas restricciones a fin
de mantener la adecuada ubicuidad de los sistemas inteligentes tal como se describió en la
sección 1.2.

Poder interactuar remotamente con un dispositivo, en este caso con un simple interruptor,
desde cualquier lugar y con dispositivos de muy variadas prestaciones abre un abanico de
desarrollo para nuevas aplicaciones tanto en hardware como en software, para ambientes
industriales y empresariales, peor especialmente en espacios cotidianos donde la ubicuidad
de estas tecnologías deberán bogar por brindar facilidades para el acceso y el confort de las
personas.

8.2. CONSIDERACIONES FUTURAS.

El presente trabajo ha mostrado la viabilidad del desarrollo de objetos IoT dentro del marco
teórico actual y la disponibilidad de herramientas para el desarrollo y la integración, sin
embargo, existen muchas posibilidades de mejora a fin de lograr un sistema que integre
otros aspectos que no se han tenido en cuenta en el presente trabajo entre ellos:

Calibración: La calibración de los dispositivos resulta más práctica de realizar una vez se
encuentran integrados todos los elementos componentes del objeto IoT, a diferencia del
método empleado donde primero se realizaron las calibraciones y luego integró el
dispositivo. Para la elaboración de un producto terminado a nivel industrial resulta más
conveniente la calibración una vez se encuentren montados todos los componentes.

Enfoque a la industria: Los dispositivos podrían poseer sensores más sofisticados a fin de
efectuar mediciones más precisas según las necesidades. Ambientes industriales pueden
aplicar los conceptos de un internet de los objetos de manera rápida y práctica ya que los
118
sistemas de comunicación, medición y control son fundamentales y se han desarrollado
ampliamente en la industria siendo la IoT un complemento a las herramientas existentes
capaz de minimizar costos, mejorar el flujo de información, aumentar la flexibilidad, entre
otros. Por otra parte, se requiere una mejora en la robustez de los sistemas asociados, en
especial la seguridad de la información y la capacidad de control.

Costos: Una de las mayores limitantes actuales del aprovechamiento masivo de las
tecnologías IoT son los costos asociados al desarrollo, implementación, instalación y puesta
a punto. El desarrollo de esquemas donde los objetos IoT sean muy simples (y por tano
económicos) pero capaces de suministrar información con valor relevante para un usuario o
grupo de usuarios impulsa la masificación de estas tecnologías. Recientemente los
dispositivos hardware requeridos han presentado una caída de precios significativa, y con
ello, mejora la viabilidad económica de proyectos de pequeña y mediana escala enmarcados
en el IoT.

Vínculos para la interacción: En el presente trabajo se ha hecho uso del etiquetado 2D

como elemento de vínculo para la interacción con los objetos IoT. Existen sin embargo toda
una gama de tecnologías que en la actualidad se pueden usar como vínculos, destacando la
denominada “realidad aumentada” que combina la capacidad de los sistemas de
información basados en la realidad virtual con objetos del mundo real, dicho escenario es
la confluencia de la realidad virtual con la denominada “virtualidad incorporada” esbozada
por Mark Weiser [1].

Ubicuidad: Un aspecto fundamental en la interacción entre personas y objetos IoT es

cuándo y cómo se presentan estas interacciones. De acuerdo a la naturaleza del objeto real y
de la capacidad de suministrar información en red, se requiere estructurar los límites y
alcances de estas interacciones. El estudio de la ubicuidad de los objetos debe convertirse
en parte del diseño y puesta a punto de una IoT práctica y segura, a fin de que las
interacciones se presenten cuando y donde se requieren, ya que la identidad virtual, como
un compilado de información, es ubicua en la red y teóricamente disponible en cualquier
momento y lugar.

Seguridad: De acuerdo a la naturaleza de los objetos, se requiere que existan barreras de

seguridad a fin de minimizar o evitar la intrusión de agentes externos en las interacciones y
el flujo de información, así como evitar la exposición no deseada de datos en la red. Dentro
del diseño futuro de plataformas web como la propuesta es requerido considerar la
seguridad de la misma, aprovechando recursos como el protocolo HTTPS que utiliza
canales cifrados basados en SSL/TLS y el uso de URL cifradas. La asociación entre objetos
IoT y su identidad virtual requieren de una variable con lakey de identificación única
incluida en la cabecera HTTP. Esta key debe ser de difícil predicción para evitar robos de
ID y con ello evitar el robo o la suplantación de los objetos IoT.

Escalabilidad: Para el manejo de la gran cantidad de información y volumen de datos que

se producen en la plataforma web se podría utilizar algoritmos predictivos como son las
redes neuronales.

119
 9.4. COSTOS

Tabla 2 .Costos dispositivo wifi ($)

Carcasa plug 35000
Chip wifi ESP8266 15000
ADE7753 10000
Sensor de corriente 15000
Fuente AC/DC 30000
Memoria EEPROM 7000
PCB 32000
Varios(Soldadura, 25000
resistencias,condensadores,regul)
Microcontrolador NXP JM128VLH 28000
Triac BTA16 600 2000
MOC 3021 1200
TOTAL $ 200.200
El costo para 3 dispositivos eléctricos es de $600.600

Tabla 3. Costos dispositivo Agua ($)

Chip wifi ESP8266 15000
Microcontrolador NXP QE128 35000
PCB 15000
Batería 10000
varios 5000
Sensor de Flujo 23000
Memoria EEPROM 7000
TOTAL $ 110.000
El costo para 2 dispositivos de agua es de $220.000

El costo total por los 5 dispositivos seriade $ 820.600

Tabla 4 .CostosAlojamiento servidor

Servidor Local con base de datos $ 1.100.000
(Computador)
Servidor Nube (IBM, Heroku) Gratuito (con limitaciones)
Servidor MYSQL en la nube Gratuito (con limitaciones)

131
 Costos adicionales

Costos servicios de internet 60.000 por mes

Librerías Graficas software Gratuitas para uso no comercial

9.5 COMPARACIÓN DE COSTOS CON RESPECTO A PRODUCTOS

COMERCIALES SIMILARES.

En la actualidad existen varios produciros comerciales que ofrecen características de

medición de consumo remoto semejantes a las propuestas en el presente trabajo, las
principales se listan en la tabla 5 y 6.

Tabla 5. Productos comerciales semejantes al sistema de medición de parámetros eléctricos

EMPRESA REFERENCIA PRECIO($)
BELKIN WEMO InsightSwitch 150.000
Bayit Switch Wi-Fi Socket, BH1810 105.000
TP-link HS110 Smart plug 124.000
D-Link DSP-W110 Wi-Fi Smart Plug 105.000
Ankuoo NEO PRO Wi-Fi 110.000
thinkeco TE1010 Modlet Starter Kit 145.000
Samsung SmartThings Smart Plug 170.000
Orvibo S20 Smart Wifi Smart Socket 100.000

Tabla 5. Productos comerciales semejantes al sistema de medición de consumo de agua.

MPRESA REFERENCIA PRECIO($)
Gaoxiang 15D 103.540
Jinhua Joint Optoelectronics LMSE03 120.000
Technology
ANHUI EMI INTELLIGEN LXSYYW (15E ~ 20E) 280.000
 MICROM MC100-RF 180.000
TEREN UFM315K 450.000
HIWITS HWC-SVMRV-005 80.000

Los precios varían de acuerdo a la marca y trayectoria de la empresa también de las

diferentes certificaciones y materiales que posea el dispositivo.

132
 9. BIBLIOGRAFÍA.

[1] Mark Weiser, "The Computer for the Twenty-First Century". Scientific American
Journal Sep. 1991 pp 94-104. Documento digital disponible en:
http://wiki.daimi.au.dk/pca/_files/weiser-orig.pdf.

[2]Traversat, B; Abdelaziz, M; Doolin, D; Duigou, M; Hugly, J.C; Pouyoul, E. "Project

JXTA-C: enabling a Web of things" Proceedings of the 36th Annual Hawaii International
Conference, System Sciences. 2003. IEEE Conference publications.

[3] Dolin, R.A. "Deploying the Internet of things" Applications and the Internet, 2006.
SAINT 2006. International Symposium on Digital Object Identifier:
10.1109/SAINT.2006.21, 2006, Page(s): 4 pp. – 219. IEEE Conference publications.

[4] Furness, A; Smith L; Sakamura K; “Final Report RFID and the Inclusive Model for the
Internet of Things”, CasagrasProyect - Final Report 2010.
Documento digital disponible en:
http://www.grifs-project.eu/data/File/CASAGRAS%20FinalReport%20%282%29.pdf.

[5] Jordán Pascual Espada, “Diseño de objetos virtuales colaborativos orientados a

servicios en el marco de Internet de las cosas” Tesis Doctoral, Universidad de Oviedo,
2012. Documento digital disponible en:
http://digibuo.uniovi.es/dspace/handle/10651/13140.

[6] Alejandra García Salvatierra "El Internet de las Cosas y los nuevos riesgos para la
privacidad" Tesis de Maestría, Universidad Politécnica de Madrid, Julio de 2012.
Documento digital disponible en: http://oa.upm.es/14543/.

[7]Yinghui Huang, Guanyu Li. "A Semantic Analysis for Internet of Things" Intelligent
Computation Technology and Automation (ICICTA), 2010 International Conference, pp
336-339, 2010. IEEE Conference publications.

[8]Changheng Shao "An Internet of Things Application with Location Perception Based on
IMS" Multimedia Information Networking and Security (MINES), 2011 Third International
Conference on Digital Object Identifier: 10.1109/MINES.2011.92 Publication Year: 2011,
Page(s): 163 – 166.IEEE Conference publications.

[9] CreusSole, Antonio. Instrumentación industrial Séptima edición, Alfaomega -

Marcombo, año 2005. Documento digital disponible en:
https://books.google.com.co/books?id=cV6ZOqQ0ywMC&pg=PA156&lpg=PA156&dq=L
os+medidores+de+turbina

[10] Campos López Omar, Aarón. Informe Técnico Programa de Cómputo Para
Dimensionar Medidores de Flujo por Presión Diferencial en Líquidos, Instituto Politécnico
133
Nacional Escuela Superior de Ingeniería Mecánica y Eléctrica Unidad Profesional “Adolfo
López Mateos” Documento digital disponible en:
http://tesis.ipn.mx/jspui/bitstream/123456789/30/1/Tesis%20Omar%20Campos.pdf

[11] Duque, Camilo. Medición de Caudal. Presentaciones de clase de instrumentación en

control, universidad UNEFA. Documento digital disponible en:
http://es.slideshare.net/camilorene/instrumentacin-de-control-clase-8-caudal

[12] Centro de Documentos de EPM Colombia, Criterios para definir el diámetro de la

acometida y el medidor a instalar en urbanizaciones y edificios. Versión 3, marzo de 2011.
Documento digital disponible en:
http://www.epm.com.co/site/Portals/0/centro_de_documentos/clientes_y_usuarios/personas
/aguas/vinculacion/Criterios%20para%20definir%20el%20diametro%20de%20acometida%
20y%20medidor.pdf

[13] Heredia Londoño, Diana Marcela, Desarrollo de una guíaenfocada a medidores de

energía y conexiones de medidores. Documento digital disponible en:
http://repositorio.utp.edu.co/dspace/bitstream/11059/3223/1/621374H542.pdf

[14] Codensa, “Documentos técnicos, generalidades capítulo 7”.Documento digital

disponible en:
http://www.codensa.com.co/documentos/3_17_2010_7_39_20_AM_GENERALIDADES
%207.4.pdf.

[15] Allegro Microsystems, ACS714: Automotive Grade, Fully Integrated, Hall Effect-
Based Linear Current Sensor IC. Documento digital disponible en:
https://www.pololu.com/file/download/ACS714.pdf?file_id=0J196

[16] Analog Devices, ADE7753: Single-Phase Multifunction Metering IC with di/dt Sensor
Interface. Documento digital disponible en:
http://www.analog.com/media/en/technical-documentation/data-sheets/ADE7753.pdf

[17] Jin-Shyan Lee, Yu-Wei Su, and Chung-Chou Shen “A Comparative Study of Wireless
Protocols: Bluetooth, UWB, ZigBee, and Wi-Fi” Information & Communications Research
Labs Industrial Technology Research Institute (ITRI) Hsinchu, Taiwan
jinshyan_lee@itri.org.tw. IEEE Conference Publications.

[18] Zhou Ying ; Li Hongsheng "Design of New Low Power Loss Nonmagnetic Water
Meter" Electronic Measurement and Instruments”, 2007. ICEMI '07. 8th International
Conference on Digital Object Identifier: 10.1109/ICEMI.2007.4350461. 2007, Páginas: 1-
356 - 1-359. IEEE Conference Publications.

[19] Descripción de familias del ESP8266. Documento digital disponible en:

http://www.esp8266.com/wiki/doku.php?id=esp8266-module-family

[20] Espressif, ESP8266EX: Eespecificacion, think connect.Documento digital disponible

en: http://espressif.com/products/hardware/esp8266ex/resources
134
[21] Introducción a los Websockets. Documento digital disponible en:
http://www.html5rocks.com/es/tutorials/websockets/basics/

[22] Node.js y Websockets. Documento digital disponible en:

https://manuais.iessanclemente.net/index.php/Node.js_y_Websockets

[23] Descripción de API’s de aplicaciones web con HTML5. Documento digital disponible
en:
https://html.spec.whatwg.org/multipage/comms.html#network

[24] A. Melnikov, Internet Engineering Task Force, RFC6455: The WebSocket Protocol.
2011. Documento digital disponible en:
https://www.rfc-editor.org/rfc/rfc6455.txt

[25] Arturo Muñoz de la Torre Monzón, Introducción a Node.JS a través de Koans.

Escuela Técnica Superior de Ingenieros de Telecomunicación de la Universidad Politécnica
de Madrid.

[26] IBM developer Works, Introducción a Node.js. Biblioteca técnica. Documento digital
disponible en:
http://www.ibm.com/developerworks/ssa/opensource/library/os-nodejs/

[27] Alejandro L. Veiga. Sistemas de tiempo real. Documento digital disponible en:
http://www.electro.fisica.unlp.edu.ar/temas/p7/RTS-1.html

[28] Brian Cantrill. Instrumenting the real-time web: Node.js in production. Documento
digital disponible en:
http://www.slideshare.net/bcantrill/instrumenting-the-realtime-web-nodejs-in-production

[29] E. Marcote, «Responsive Web Design,» [En línea]. Documento digital disponible en:
http://alistapart.com/article/responsive-web-design

[30] Esther Labrada Martínez y Cristina Salgado Ceballos, DISEÑO WEB ADAPTATIVO
O RESPONSIVO Revista Digital Universitaria–UNAM
http://www.revista.unam.mx/vol.14/num1/art07/art07.pdf

[31] Adrián Alonso Vega, Responsive Web Design: Interfaces Web, Adaptables al
dispositivo empleando HTML5 y CSS3, UNIVERSIDAD DE ALCALÁ Escuela
Politécnica Superior Grado en Ingeniería Informática. Documento digital disponible en:
http://dspace.uah.es/dspace/bitstream/handle/10017/19972/Memoria.pdf?sequence=1

[32] Jorge Cueva Estrada, Jaime Cevallos Herrera, Estudio del código QR para el
desarrollo de los planes de marketing y publicidad en las empresas del sector comercial de
la ciudad de Guayaquil, Universidad politécnica salesiana sede Guayaquil, Maestría de
administración de empresas.

135
[33] Lu Tan; Neng Wang "Future internet: The Internet of Things" Advanced Computer
Theory and Engineering (ICACTE), 2010 3rd International Conference on Digital Object
Identifier: 10.1109/ICACTE.2010.5579543. 2010, Páginas: V5-376 - V5-380. Future
internet: The Internet of Things

[34] Anthony Furness, "CASAGRAS and The Internet of Things" European Centre of
Excellence for AIDC, documentos de trabajo, 2008.
Documento digital disponible en: docbox.etsi.org/.../CERP20081008/CERP7%20CAS.

[35] Ferrada Bautista, Manuel y Silva Peñaloza, Mayra del pilar. Medición digital de la
potencia activa para un sistema de calentamiento eléctrico monofásico. Universidad
Industrial de Santander, 2005. Tesis de grado disponible en:
http://repositorio.uis.edu.co/jspui/bitstream/123456789/3077/2/116339.pdf

[36] Davila frias, Alex. Diseño y construcción de un prototipo para medición y transmisión
inalámbrica del consumo de energía eléctrica de un sistema monofásico bifilar. Escuela
Politécnica Nacional de Quito, 2006. Tesis de grado disponible en:
http://bibdigital.epn.edu.ec/

[37] Hernández González, Guillermo Enrique. Diseño y construcción de un sistema

integrado de medición de energía monofásico de uso residencial (S.I.M.E.M.) Versión 2.
Universidad Pontificia Bolivariana, 2013. Tesis de grado disponible en:
https://repository.upb.edu.co/handle/123456789/195

[38] Freescale Semiconductor. Data Sheet: Technical Data MCF51JM128 ColdFire

Microcontroller. Documento digital disponible en:
https://www.nxp.com/files/32bit/doc/data_sheet/MCF51JM128.pdf

[39] Freescale Semiconductor. Data Sheet: Technical Data MCF51QE128 Series.

Documento digital disponible en:
http://cache.nxp.com/files/32bit/doc/data_sheet/MCF51QE128.pdf?pspll=1

[40] Microchip, 512K I2C Serial EEPROM Datasheet. Documento digital disponible en:
http://ww1.microchip.com/downloads/en/DeviceDoc/21754M.pdf

136