Proyecto: Análisis de los datos

Con los datos obtenidos, y a modo de conclusión, se puede realizar un análisis, que es el objetivo principal de una aplicación IoT como esta. Por lo tanto, se ha elegido la realización de un control difuso para determinar la sensación térmica empleando las dos variables de las que se dispone: humedad y temperatura.

Un controlador difuso de estas características dispone de una serie de reglas que se van a evaluar para cada punto. De cada uno de ellos, se pretende extraer un estado como el se la siguiente tabla:

Pero antes de seleccionar uno de los estados resultado de esta tabla, se debe conocer a qué clase pertenecen la temperatura y humedad, y para ello se va a realizar una evaluación con funciones trapezoidales de cada uno de los puntos.
Para ello, se va a dividir en dos puntos:

Temperatura

La temperatura puede variar desde valores negativos pequeños hasta valores no por encima de los 40, debido a que la zona en la que residimos no tiene picos extremos, los datos tenderán a estar muy agrupados. Esto va a dificultar la calidad de la medida, ya que va a ser mas complicado establecer la diferencia entre un grupo y otro. La distinción que se ha realizado es la siguiente:

Para valores muy bajos se considera frío, las temperaturas medias estarán entre fresco y templado y las extremas por encima se situaran en caluroso. La manera de evaluar donde se sitúa el punto es la siguiente:
Cuando se analiza una temperatura, por ejemplo 17 grados, esta cruza varias rectas, en concreto la de fresco y templado. La clase que se le va a aplicar a esta temperatura, sera el valor más alto obtenido al cruzar por ellas, es decir, unos 0,7 en templado y unos 0,3 en fresco. Por lo tanto, el valor más alto indica que 17 grados es una temperatura templada mayoritariamente. 
Para el análisis de los puntos, se ha creado una estructura condicional en MatLAB:


Esta estructura devuelve siempre 4 valores, que corresponden a las clases. El valor más alto define la clase de temperatura.

Humedad

Para la humedad se va a realizar un análisis idéntico. Sin embargo, en este caso, se ha decidido realizar una división en tres clases de la zona de la gráfica, que oscila entre el 0 y el 100%:

Esto deja tres rangos situados entre baja, suave y alta. La función de evaluación va a ser idéntica a la anterior, devolviendo tres funciones con valor entre cero y la unidad:

Evaluación

Entonces, una vez analizadas ambas variables, toca a continuación realizar una serie de condiciones que encajen con la primera tabla expuesta:

• Si la temperatura es fría y la humedad baja, entonces la sensación es soportable.
• Si la temperatura es fría y la humedad suave, entonces la sensación es mala.
• Si la temperatura es fría y la humedad alta, entonces la sensación es inclemente.
• Si la temperatura es fresca y la humedad baja, entonces la sensación es agradable.
• Si la temperatura es fresca y la humedad suave, entonces la sensación es soportable.
• Si la temperatura es fresca y la humedad alta, entonces la sensación es mala.

Y así con todas las condiciones que dan como resultado un único valor dentro de la tabla de resultados.

Sin embargo, la forma de programar estas funciones, difiere de las anteriores. Entre otros métodos, se ha elegido la funciona mínima como método de evaluación, que consiste en buscar el valor mínimo de las funciones cruzadas que se han visto previamente. Por ejemplo:

• Estado 1: La temperatura es fría y la humedad es baja. Las funciones previas darían como resultado 1 en temperatura y 1 en humedad, por lo que el valor mínimo de ambos es 1. Al ser el valor máximo, con toda probabilidad la sensación térmica es soportable.

Todas estas funciones se programan de esta manera:

Esta función entonces devuelve la probabilidad de que la temperatura pertenezca a uno de los estados de la tabla de sensaciones térmicas. Sin embargo, siguiendo con la programación, se puede depurar un programa que devuelva exactamente la sensación térmica:

La ejecución de esta función devuelve un caso como este:

Con esto se puede analizar del lote de datos, por ejemplo una muestra cada tiempo configurable:


Se ha realizado una división exacta cada 60 muestras, lo que equivale a 10 minutos. Esto devuelve la siguiente ejecución:

Tema 03 - Sesion 06 (31/01/19)

En esta practica se va a realizar una subida y lectura de datos mediante otro protocolo: MQTT

Este protocolo se basa en el modelo publicista-subscriptor, en el que el que produce los datos, los sube a la red, y el subscriptor dispone de ellos cuando quiera. Por lo tanto, no existe un dialogo constante entre ambos, en el que cada cierto tiempo definido se consultan dichos datos.

Para esta práctica se va a definir un broker, que es el que produce los datos. A su vez, se va a crear un tema. Como subscriptor, te puedes inscribir en distintos temas de tu interés. En este ejemplo, hemos creado a un canal en el que se va a subir la información del consumo de CPU y RAM, mediante el protocolo MQTT:

Tema 03 - Sesion 03 y 04 (24/01/19)

En la clase de hoy se ha hecho uso de la herramienta de programación Python para la realización de peticiones HTTP en ThingSpeak similar a lo realizado previamente. La sesión de hoy se va a dividir en dos ejercicios.

EJERCICIO 1: Visualización del uso de RAM y CPU del pc y envío de datos a ThingSpeak  

En este ejercicio, se va a realizar un programa en la herramienta Python que lea el consumo de CPU y RAM del ordenador para después subirlo a la red mediante la API REST que hemos visto con anterioridad, con un previo borrado del canal.

Lo primero de todo va a ser abrir Python y descargar la librería Psutil, que se realiza escribiendo en el terminal de la aplicación: pip install psutil. Este comando ejecuta la instalación directamente, sin necesidad de pasos adicionales. Una vez que esté instalada, estamos listos para la realización del ejercicio.  

En cualquier programa de Python, el primer paso es añadir las librerías:

import psutil
import httplib
import urllib

Estas tres librerías son las que van a permitir realizar, tanto la lectura del consumo, como las peticiones HTTP necesarias para subir los datos a la red.

A continuación, se debe realizar una conexión TCP al servidor deseado, por lo que se añade tanto la dirección del servidor como la definición de la conexión:

server = 'api.thingspeak.com'
connTCP = httplib.HTTPSConnection(server)
Write_apkey = 'GTXNVDI95SFSUDRQ'
Delete_apkey = 'KEJU9WAA6A7VQS2C'

Se pueden poner visualizaciones con print a modo de depuración, es decir, a la hora de ejecutar el código, se se ejecuta la linea print, significa que el programa hasta esa linea es correcto. Se realiza la conexión:

print("Estableciendo conexion TCP..."),
connTCP.connect()
print("Conexion TCP establecida")

Una vez realizada la conexión, debemos establecer las reglas del diálogo con el servidor. Empleando la información obtenida del REST API, se incluyen aquellos campos necesarios, que son el formato y la llave de escritura de la que disponemos en nuestra pagina de ThingSpeak.

En este código se puede ver el recurso DELETE, la URI relativa a la que apunta el programa, las cabeceras y el contenido del mensaje. Debido a que el contenido del mensaje es una librería Python que el servidor web puede no reconocer, se decodifica a json para realizar una petición que sí entienda.

La última línea sirve para añadir la longitud del mensaje en la librería de la cabecera.

methodC1 = "DELETE"
relative_uriC1 = "/channels/680589/feeds.json"
headersC1 = {'Host': server,
           'Content-Type': 'application/x-www-form-urlencoded'}
payloadC1 = {'api_key': Delete_apkey}
payload_encodedC1 = urllib.urlencode(payloadC1)
headersC1['Content-Length'] = len(payload_encodedC1)

Para realizar la conexión y el envío de la petición, se emplea el código a continuación:

connTCP.request(methodC1, relative_uriC1, body=payload_encodedC1, 

headers=headersC1)
respuestaC1 = connTCP.getresponse()
statusC1 = respuestaC1.status
print(str(statusC1))

El comando STATUS nos va a devolver el resultado de la conexión, siendo 200 una petición correcta.

Con esta petición, se ha solicitado el borrado del canal previo a la subida de los datos.

Una vez estén los datos borrados, se va a realizar una subida de nuevos datos, para lo cual se va a realizar una estructura WHILE que va a ejecutar indefinidamente el segmento siguiente:

try:
    while(True):
        cpuPercent = psutil.cpu_percent(interval=15)
        ramPercent = psutil.virtual_memory().percent

        print("%CPU: " + str(cpuPercent)),
        print("\t%RAM: " + str(ramPercent))

        method = "POST"
        relative_uri = "/update.json"
        headers = {'Host' : server,
                   'Content-Type' : 

                      'application/x-www-form-urlencoded'}
        payload ={'api_key' : Write_apkey,
                  'field1': cpuPercent,
                  'field2': ramPercent}

        payload_encoded = urllib.urlencode(payload)
        headers['Content-Length'] = len(payload_encoded)

        print("Enviando peticion HTTP..."),
        connTCP.request(method, relative_uri, body=payload_encoded, 

                        headers=headers)
        print("Peticion enviada")
        print("Esperando respuesta HTTP...")

        respuesta = connTCP.getresponse()
        status = respuesta.status
        print(str(status))

Con una estructura similar al borrado pero empleando el recurso POST, se envian los datos al servidor realizando la peticion HTTP.

Para detener la ejecución del programa, se presiona CTRL+C, y se adjunta una linea de comandos para la realización de una secuencia de apropiada, junto con el cierre de la conexión:

except KeyboardInterrupt:
    connTCP.close()
    print("Se ha pulsado CTRL+C. Saliendo del programa")

EJERCICIO 2: Creación de un canal, subida de datos y borrado del canal al finalizar

En este ejercicio, como indica en el título, se va a crear un código que cree un canal, obtenga la información necesaria para subir datos a ese canal, y después borrarlo a la salida de la ejecución. El código es el siguiente:

Tema 03 - Sesión 03, Preparación (24/01/19)

La tercera sesión de esta asignatura será doble y en ella se trabajará con peticiones HTTP, Thingspeak y Python. Con el objetivo de preparar la sesión, se han mandado una serie de ejercicios para terminar de afianzar lo explicado en las sesiones 1 y 2

Ejercicio 01: Envío de datos con formulario

En la URI http://august-outlet-228919.appspot.com/ hay un formulario que permite obtener la letra de un DNI. Se pide: 

a ) Ver qué es lo que ocurre cuando se solicita la URI anteriormente indicada. 

Se obtiene un código 302: redirige a https://august-outlet-228919.appspot.com/html/form.html

 
b) Introducir un DNI válido y ver a qué URI se envía la petición.
La petición se envía a https://august-outlet-228919.appspot.com/obtener Letra. Como tiene espacio, en la petición este se convertirá en un %

c) Obtener los siguientes parámetros:

• Nombre del parámetro asociado al DNI: nan
• Nombre y el valor de los parámetros ocultos adicionales: ezkutua: kalkulatu

d) Editar manualmente en Burp la petición HTTP para obtener la letra y comprobar que la respuesta HTTP contiene la letra en el cuerpo del mensaje.
La petición a enviar será de la forma:

POST /obtener%20Letra HTTP/1.1
Host: august-outlet-228919.appspot.com
Content-Type: application/x-www-form-urlencoded
Content-Length: [largura_mensaje]

nan=22725983&ezkutua=kalkulatu

Donde [largura_mensaje] deberá sustituirse por el valor adecuado en cada caso. Burp lo rellena automáticamente. El valor de nan también deberá modificarse a conveniencia.

Petición de letra

Respuesta entregada por el servidor

Ejercicio 02: Enviar datos en formato formulario a ThingSpeak y recibir una respuesta vacía

Siguiendo la documentación de Matlab para trabajar con ThingSpeak se hace la petición desde Burp Suite. El canal a actualizar es el ya creado durante la sesión número 02. El formato de la petición será:  

POST /update HTTP/1.1

Host: api.thingspeak.com

Content-Type: application/x-www-form-urlencoded

Content-Length: [largura_mensaje]

api_key=[channel_api_key]&field1=[valor_campor_1]&field2=[valor_campo_2] 

• [channel api_key] habrá que sustituirlo entero por el api_key del canal.
• [valor_campor_1] y [valor_campor_2]: se deberán sustituir por lo valores que se quieren subir al canal.
• [largura_mensaje]: se deberá sustituir por la largura del mensaje (depende de cada caso y Burp lo rellena automáticamente)

La respuesta entregada por el servidor así como los datos actualizados en el canal pueden observarse a continuación:

Respuesta del servidor: está vacia

Ejercicio 03: Enviar los datos en formato formulario y recibir una respuesta en formato JSON

De nuevo, la petición será de la forma: 

POST /update.json HTTP/1.1

Host: api.thingspeak.com

Content-Type: application/x-www-formurlencoded

Content-Length: [largura_mensaje]

api_key=[channel_api_key]&field1=[valor_campor_1]&field2=[valor_campo_2]

La respuesta entregada por el servidor así como los datos actualizados en el canal pueden observarse a continuación:

Respuesta del servidor

Ejercicio 04: Enviar los datos en formato JSON y recibir una respuesta en formato XML

Esta vez la petición se hace en formato json, con lo cual cambia un poco su aspecto respecto a las veces anteriores 

POST /update.xml HTTP/1.1

Host: api.thingspeak.com
Content-Type: application/json
Content-Length: [largura_mensaje] 

{"api_key":"[channel_api_key]","field1":=[valor_campo_1],"field2":=[valor_campo_2]} 

La respuesta entregada por el servidor así como los datos actualizados en el canal pueden observarse a continuación:

Respuesta del servidor

Tema 03 - Sesión 01 (15/01/19)

En la sesión del martes 15 de enero se introdujeron los conceptos de HTTP básicos.

MODELO CLIENTE SERVIDOR

HTTP se trata de un protocolo que sigue un modelo cliente-servidor: permite que un cliente indique las operaciones a realizar sobre un recurso que ya se encuentra en un servidor. Es decir, el cliente realiza peticiones, el servidor las procesa y devuelve respuestas.

Las peticiones HTTP van a ir encapsuladas en una conexión TCP, de esta forma se asegura una la entrega de los datos en secuencia y sin errores. Por otro lado, una conexión TCP viene identificada por el par (IP_Origen – Puerto_Origen)-(IP_Destino-Puerto_Destino).

Todas las aplicaciones de un ordenador tienen un puerto, que le permite al ordenador saber a dónde mandar los paquetes que llegan de Internet.

RECURSOS

La razón por la que las acciones se ejercen sobre recursos, es porque estos son la base sobre la que está montado lo que conocemos comúnmente como Internet. Así, una misma página que está formada por multitud de recursos.

Las operaciones/métodos que se pueden realizar sobre un recurso son las siguientes:

• Post: permite escribir.
• Get: Permite leer
• Put: permite actualizar
• Delete: permite borrar   

Cada uno de los recursos sobre los que se ejercen las operaciones está identificado con su propia URI dentro del servidor, que intercambia las representaciones de dichos recursos. El hecho de que se intercambien las representaciones es porque u recurso puede tener más de una representación: una página web no se ve igual en el móvil que en el ordenador, aunque esté formada por los mismos recursos en ambos casos.

TRANSACCIONES

Cada operación ejercida sobre un recurso genera transacciones. Cada transacción es independiente de las anteriores y las siguientes, y por ello en servicios que trabajan con logins se usan las cookies. Estas cookies permiten agregar cabeceras a esas transacciones, de forma que aunque siguen siendo independientes, se sigue manteniendo la sesión. 

Para cargar una página web que a simple vista puede parecer sencillas, se están realizando multitud de transacciones en unos pocos milisegundos. Por ejemplo, solo para cargar la página principal de Google se realizan 9 transacciones-. Sin embargo, para cargar la cuenta de Gmail, se realizan más de 200, que además aumentan de forma constante por estar haciendo peticiones continuas al servidor para mantener la bandeja de entrada actualizada.

PETICIÓN DE UN CLIENTE HTTP

La sintaxis de una petición HTTP es la siguiente: 

Método RequestURI HTTP/1.1
Cabeceras
CRLF*
Cuerpo del mensaje (en octetos**)

La única cabecera obligatoria siempre va a ser Host. Otras cabeceras pueden incluir información sobre preferencias de que el contenido esté comprimido o no, su idioma o formato. En general, el orden de las cabeceras no va a ser relevante para el servidor que lee la petición. Si el recurso solicitado existe en el servidor y se le pueden realizar las acciones solicitadas, a continuación el servidor va a leer las cabeceras. De esta forma podrá devolver el recurso de la manera que mejor se adapte a lo solicitado por el cliente.

RESPUESTA DE UN SERVIDOR HTTP

La sintaxis de la respuesta va a ser la siguiente:

HTTP/1.1 Status Descripción

Cabeceras

CRLF

Cuerpo del mensaje (en octetos)

Se profundizará mas en ello en la próxima sesión.

EJERCICIO BURP 

Para poner en práctica lo explicado en clase, se realiza un sencillo ejercicio en el Burp Suite. El objetivo del mismo es solicitar l página principal de Google. 

El primer paso es configurar el Target, asignando un Host y un puerto. Como es HTTP, no HTTPS, puerto 80.

A continuación, se realiza la petición. El método va a ser GET. Como se quiere la página principal, el recurso será /. El Host es el mismo que el target, y finalmente se deja la línea en blanco necesaria.

Si es correcto la respuesta devolverá un 200.

  

Sobre los códigos de respuesta también se hablará más en la próxima sesión.