Empujados por la necesidad de incorporar la Industria 4.0 a las aulas, especialmente al curso de especialización, creemos que tenemos la oportunidad de hacerlo converger todo, así que abrimos un par de líneas que realmente se juntan con el desarrollo del medidor de CO2. Este no deja de ser un dispositivo IoT que produce datos y que pueden ser puestos en juego para una serie de aplicaciones.
Para aprovechar su potencial pretendemos adentrarnos en el uso de OPC-UA y de Node-RED. Tomamos prestada la definición de OPC-UA de esta Web: «La OPC UA es un protocolo de comunicación disponible de forma gratuita diseñado específicamente para la automatización industrial. Permite el intercambio de información y datos en dispositivos dentro de máquinas, entre máquinas y desde máquinas a sistemas. La OPC UA cierra la brecha entre la tecnología de la información y la tecnología operativa.»
OPC-UA IIoT en marcha
Lo que se pretende por tanto es poner en juego datos generados por nuestro dispositivo IoT con un protocolo abierto, pero que pueda ser usado por dispositivos industriales tales como un PLC de Siemens, Scheider o cualquier otra marca.
Tomo también prestada la definición de Node-RED de su Web oficial: «Node-RED is a programming tool for wiring together hardware devices, APIs and online services in new and interesting ways. It provides a browser-based editor that makes it easy to wire together flows using the wide range of nodes in the palette that can be deployed to its runtime in a single-click.«.
Servidor Node-RED instalado
Así, mediante el uso de esta tecnología podremos interconectar diferentes dispositivos mostrando los datos con Grafana y usando como base de datos InfluxDB, monitoreando por tanto máquinas usando protocolos industriales, no es poca cosa…
Tenemos una mención desde la cuenta de Instagram del instituto por el trabajo realizado hasta ahora, pero queremos seguir en esa línea y acabar el trabajo. Este trimestre trabajaremos en la PCB que le dará soporte a la electrónica del prototipo y en una caja para meterlo todo.
Esta caja será la que debe ir bajo la maqueta (o pegada a ella, ya veremos) y suministrará la información sobre la misma. Estamos en contacto con profesores que trabajan con la fundación ONCE para que todo este trabajo tenga un sentido y una salida. Seguiremos informando…
Uno de las tareas que se acometieron en el GGTT Industria 4.0 durante el curso pasado fue la de desarrollar una caja contenedora de todos los dispositivos necesarios para la captación de datos ambientales y su transmisión vía wifi a un servidor para presentarlos debidamente.
Ésta tarea la realizaron alumnos del Dpto. de Edificación con las indicaciones de su profesor del módulo de Representaciones de Construcción, en la que tienen que trabajar las competencias necesarias para desarrollar los resultados de aprendizaje de croquizado, dibujo en 2D mediante programas de CAD a partir de los croquis, realización de modelos tridimensionales digitales y elaboración de maquetas, bien sea mediante impresión 3D, o realizadas a mano por métodos tradicionales.
Inicialmente, y hasta no disponer de un modelo físico, comenzamos a trabajar partiendo de las dimensiones del diseño de la placa base que habían realizado los compañeros del Dpto. de Electrónica, en el cual estaban acotadas las dimensiones básicas del futuro prototipo.
Diseño básico de la placa base
Con éstos datos y las dimensiones de los componentes que se iban a insertar en la placa base se realizó el modelo 2D que permitiría su modelado posterior en 3D. hay que comentar que en ese punto se optó por una alimentación eléctrica en sustitución de una batería para el funcionamiento autónomo, lo cual permitiría una autonomía de funcionamiento más amplia.
Diseño CAD en 2D de la placa base
En ese momento, y hasta que no dispusiéramos de un prototipo físico, ya se empezaron a realizar las primeras pruebas de modelado 3D para estudiar el establecimiento de los siguientes elementos:
Determinar el sistema de sujeción de la placa base y sus componentes a la carcasa. Básicamente dos sistemas, o tornillo con tuerca inferior o atornillado directamente a la base de la carcasa
Sistema de sujeción del medidor a un soporte vertical, puesto que la normativa de INSST (Instituto Nacional de Seguridad y Salud e el Trabajo) establece que debe estar a una altura determinada, similar a la de las cabezas de los usuarios que desarrollan una actividad en la estancia destinada a realizar la medición de CO2
Valorar el sistema de ventilación que tendrá la caja, para que no se produzca acumulación de calor en el interior, lo cual falsearía la medición de temperaturas
Valorar el sistema de sujeción entre la base, y la tapa de la misma, para que sea sencillo el acceso a los componentes, en caso de reparación o sustitución
Posicionamiento virtual de los elementos que determinan las aperturas en la caja
Huecos de alojamiento de tuercas y agujero para sujeción a una alcayata en la pared
Primera propuesta de huecos de ventilación mediante matriz circular de agujeros con huecos rasgados en la parte inferior para la admisión de aire
Modelo 3D del logo del GGTT Industria 4.0
Una tras otra se fueron resolviendo algunas de las cuestiones anteriores, se realizaron las primeras impresiones con impresora 3D para seguir depurando el modelo.
Primeros prototipos de caja
Primer prototipo operativo de placa con todos sus elementos
Finalmente, realizados los últimos ajustes con primer prototipo, el diseño final quedó con los huecos de ventilación -salida del aire- realizados con el logotipo de nuestro grupo de trabajo, mientras que los huecos de admisión del aire se hicieron aumentando la altura de los rasgados en el sistema de ensamblaje con forma de bayoneta, que reduce el rozamiento, debido al poco peso de la tapa.
Tras las instalación del Arduino IDE, es necesario indicarle al entorno que se va a trabajar con placas del fabricante Espressif, en concreto con la Wemos D1 mini Lite. Para ello:
Ir a Archivo, Preferencias, Gestor de URLs adicionales de tarjetas y añadir la línea:
Luego ir a Herramientas, Gestor de tarjetas y seleccionar la D1 mini Lite.
Librerías necesarias para el medidor de CO2
Thingspeak (incluido el código fuente).
Adafruit_SSD1306 (con todas sus dependencias).
Adafruit_NeoPixel.
DHT sensor library by Adafruit (con todas sus dependencias).
Incluir como librería .ZIP: WiFiManager-master by tzapu.
En caso de usar entorno Linux
Para poder utilizar el puerto USB asignado a la placa Arduino en Linux debemos agregar a nuestro usuario el grupo especial creado para el acceso al device tty asignado al puerto USB del Arduino,el grupo es el dialout de otra manera no podremos subir el código a la placa, obteniendo errores asociados a denegación de acceso al puerto por no tener los permisos requeridos.
Conectamos la placa y desde el IDE verificamos el puerto asignado Tools > Port, en mi caso el device es el /dev/tty/ACM0
verificamos el grupo asociado al dispositivo:
$ ls -all /dev/tty/ACM0
crw-rw—- 1 root dialout 166, 0 Feb 21 19:57 /dev/ttyACM0
agregamos a nuestro usuario al grupo dialout:
$ sudo usermod -a -G dialout $USER
debemos hacer logout para que el sistema tome los cambios y así poder acceder al puerto sin tener que levantar el IDE como usuario root.
Organización del código
El código actual funcionando con el servidor de Thingspeak tira de varias librerías incluidas de diferente forma, como se comentaba anteriormente:
WiFiManager-master.zip.
ThingSpeak.cpp y ThingSpeak.h como archivos de código y cabecera de C++. Prácticamente todo el código están en el archivo de cabecera, ligeramente modificado respecto a la versión original para apuntar al servidor del Politécnico. Esto está documentado en las primeras líneas del archivo.
Además cuenta con varios archivos que completan la funcionalidad:
medidor-v4-Thingspeak.ino. Este es el archivo principal de código, con amplia documentación interna.
secrets.h. Este es el archivo que contiene las claves para abrir los canales junto con las APIKEY, algo así como el login para poder enviar los datos.
Código principal para conectar con Thingspeak
A continuación se incluye el contenido de los archivos realizados para programar los medidores comenzando por la modificación del código fuente de la librería ThingSpeak.
ThingSpeak.h
// #define PRINT_DEBUG_MESSAGES
// #define PRINT_HTTP
#ifndef ThingSpeak_h
#define ThingSpeak_h
#define TS_VER "2.0.0"
#include "Arduino.h"
#include <Client.h>
// Servidor Thingspeak por defecto: "api.thingspeak.com" || Servidor del Politécnico:"thingspeak.politecnicomalaga.com"
// Puerto Thingspeak por defecto: "80" || Puerto del Politécnico: "8080"
// Puerto HTTPS Thingspeak por defecto: "443" || Puerto HTTPS del Politécnico: "8443"
//Aquí hay que pegar lo que corresponda de los comentarios de arriba
Con comentarios dentro del propio código, esta es la fuente principal de la que tiran los medidores de CO2.
#include<SoftwareSerial.h>//Librería para crear puerto serie software en otros pines
#include<Wire.h>// Librería para comunicar la placa arduino con dispositivos que trabajan mediante el protocolo I2C/TWI
#include<Adafruit_SSD1306.h>// Librería para controlar la OLED monócroma de Adafruit basada en los drivers SSD1306 https://github.com/adafruit/Adafruit_SSD1306
#include<Adafruit_GFX.h>// Librería con para control de funciones gráficas de la OLED https://github.com/adafruit/Adafruit-GFX-Library
#include<Adafruit_NeoPixel.h>// Librería para controlar el led RGB WS2812B
#include<DHT.h>// Librería del sensor de temperatura y humedad DHT22 basado en el AM2302
#include<ESP8266WiFi.h>// Librería de control de la WiFi para el ESP
#include<DNSServer.h>// Librería para montar lo relativo al DNS en la conexión a la red
#include<WiFiManager.h>// Librería para manejar la WiFi de forma sencilla con el móvil por ejemplo y no tener hardcoded los datos de la red https://github.com/tzapu/WiFiManager
#define TS_ENABLE_SSL // Para hacer el envío seguro de datos
#include"ThingSpeak.h"// Librería para subir los datos a la nube IoT de ThingSpeak.com
#include"secrets.h"// Archivo añadido al proyecto para no tener las contraseñas en el mismo archivo de código. Con la WiFi sólo lo he usado al principio con una red fija
// Con las credenciales para subir a la nube IoT es necesario mantenerlo.
//PARÁMETROS SUSCEPTIBLES DE MODIFICARSE. Hay que tocar aquí en función de lo que hay en el archivo secrets.h y también al inicio de la librería ThingSpeak.h para escoger URL y puerto//
#define INDICE_MEDIDOR 0// Mediante este valor elijo uno de los medidores cuyos datos están almacenados en el archivo secrets.h
#define DELTA_CO2 0// Marco un offset (+16 en abril de 2021) a sumar al mínimo de CO2 medido, ya que el sensor toma 400 como base y realmente la base es superior. Datos de https://gml.noaa.gov/ccgg/trends/global.html
#define FACTOR_CORRECCION 0// Factor de offset a sumar para los medidores que se vean que difieren del valor correcto. Por ahora solo el medidor 4 tiene un offset de -90
#define MIN_CO2 400// Marco el mínimo válido del sensor para filtrar datos erróneos
#define MAX_CO2 5000// Marco el máximo válido del sensor para filtrar datos erróneos
#define NIVEL_1 500// Primer nivel de CO2 a considerar
#define NIVEL_2 600// Segundo nivel de CO2 a considerar
#define NIVEL_3 700// Tercer nivel de CO2 a considerar
#define NUMPIXELS 1// Modificamos este numero según los LEDs con los que contemos
#define UPDATE_TIME_LOCAL 5000// Intervalo en ms para pedir datos a sensores
#define UPDATE_TIME_REMOTE 60000// Intervalo en ms para enviar datos a la nube de Thingspeak
#define PINDHT D4 // Pin D4 al que conecto el sensor de temperatura y humedad (GPIO2)
#define PINLEDRGB D3 // Pin D3 al que conecto el DIN del primer led en la cadena (GPIO0)
#define PINBUZZER D8 // Pin D8 al que conecto el buzzer pasivo (GPIO15)
#define PINTXSENSOR D6 // Pin D6 al que conecto el RX del micro cruzado con el TX del sensor (GPIO12)
#define PINRXSENSOR D7 // Pin D7 al que conecto el TX del micro cruzado con el RX del sensor (GPIO13)
//El pin D1 (GPIO5) es SCL y el pin D2 (GPIO4) es SDA y van conectados a esas conexiones de la OLED. La encuentra por la dirección física I2C
unsignedlong myChannelNumber = medidoresCanales[INDICE_MEDIDOR]; //canal a usar
constchar * myWriteAPIKey = medidoresAPIKEY[INDICE_MEDIDOR]; //APIKEY del canal a usar
char ssid[] = SECRET_SSID; //mi SSID (nombre de la red)
char pass[] = SECRET_PASS; //el password de mi red
byte mac[6]; //la dirección física (MAC) del interfaz WiFi
unsignedlong tiempo = 0; // Variable para controlar el tiempo de ejecución
//WiFiClient client; // Cliente de WiFi
WiFiClientSecure client; // Cliente seguro de WiFi
DHT dht(PINDHT, DHTTYPE); // Objeto para refenciar al sensor de temperatura y humedad de la clase DHT
Adafruit_SSD1306 display(ANCHO_PANTALLA, ALTO_PANTALLA, &Wire, -1); // Objeto para refenciar a la pantalla OLED de la clase Adafruit_SSD1306
Adafruit_NeoPixel pixels(NUMPIXELS, PINLEDRGB, NEO_GRB + NEO_KHZ800); // Objeto para refenciar al RGB de la clase Adafruit_NeoPixel
SoftwareSerial sensor(PINTXSENSOR, PINRXSENSOR); // Objeto para crear un puerto serie virtual de la clase SoftwareSerial
// Usamos el pin 12 (D6) para Rx del micro y el pin 13 (D7) para Tx del micro. Están cruzados con la UART del sensor
byte readCO2[] = {0xFE, 0X44, 0X00, 0X08, 0X02, 0X9F, 0X25}; //Command packet to read Co2 (see app note)
byte response[] = {0, 0, 0, 0, 0, 0, 0}; //create an array to store the response
int valMultiplier = 1; //multiplier for value. default is 1. set to 3 for K-30 3% and 10 for K-33 ICB
int nivelAlarma = 0; // Sirve para establecer el color del led RGB y el pitido del zumbador si se superan unos ciertos umbrales
WiFiManager wm; // Creamos una instancia de la clase WiFiManager para controlar el acceso a una red cualquiera.
voidsetup()
{
Serial.begin(115200);
delay(200);
// Para conectar a la WiFi se puede hacer "a saco" con la clase WiFi o usando la librería WiFiManager (wm), que crea un portal en el que configurar el acceso
// y se puede hacer desde el móvil por ejemplo
WiFi.mode(WIFI_STA); // Establecemos el modo STATION explícitamente, ya que el ESP lo pone por defecto a STA+AP
//wm.resetSettings(); // Reseteo settings - limpiar credenciales para testeo; Si descomento esta línea habría que meter los datos de la WiFi cada vez que arranca
wm.setConfigPortalBlocking(false); // lo marcamos como no bloqueante; es decir, se puede configurar o no la WiFi, pero el resto sigue funcionando
// Automaticamente se conecta usando las credenciales salvadas por defecto (si antes se había conectado)
// Si la conexión falla arranca un AP con el nombre que se especifica
// Si no salta el inicio de sesión hay que abrir en el navegador la IP 192.168.4.1
// Si salta, estás directamente en el mismo punto. Ahí solo queda seleccionar tu red y meter tu contraseña
// Esto sólo hay que hacerlo una vez, luego se queda guardado
if (wm.autoConnect("Medidor 4.0.1")) {
Serial.println("Conectado a la red");
}
else {
Serial.println("Configportal running");
}
// Begin WiFi. Esto sería para una conexión fija y que no haya que configurarla
// WiFi.begin(ssid, pass); //Arranco WiFi
// Connecting to WiFi...
// Serial.print("Connecting to ");
// Serial.println(ssid);
client.setInsecure(); //El cliente no verifica al servidor
ThingSpeak.begin(client); //Arranco cliente de Thingspeak
Serial.println("No se encuentra la pantalla OLED");
while (true);
}
sensor.begin(9600); //Arranco sensor de CO2
dht.begin(); //Arranco DHT22
pixels.begin(); //Arranco led RGB
tiempo = millis(); //Tomo referencia inicial de tiempo
}
voidloop()
{
wm.process(); // Portal Web para gestionar la conexión a la red
sendRequest(readCO2); // Mando petición al sensor para medir CO2
int valCO2 = getValue(response); // Recojo la respuesta del sensor
valCO2 += DELTA_CO2 + FACTOR_CORRECCION; // Añado el offset necesario para tener datos más reales
float h = dht.readHumidity(); // Lectura de humedad del sensor. Toma unos 250 ms
float t = dht.readTemperature(); // Lectura de temperatura del sensor. Toma unos 250 ms
valCO2 = (valCO2 > MAX_CO2) ? MAX_CO2 : valCO2; //Saturo el máximo del valor de CO2 para filtrar posibles errores en los que se va al fondo de escala del tipo de dato
valCO2 = ((valCO2 > MIN_CO2 * 0.97) && (valCO2 < MIN_CO2)) ? MIN_CO2 : valCO2; //Saturo el mínimo del valor de CO2 para filtrar posibles errores (margen del sensor de +-50ppm / +-3%)
pixels.show(); // Mandamos todos los colores con la actualización hecha
}
/*
Función que genera un par de tonos cortos
*/
void tonoCorto() {
//generar tono de 440Hz durante 200 ms
tone(PINBUZZER, 440);
delay(200);
//detener tono durante 100ms
noTone(PINBUZZER);
delay(100);
//generar tono de 523Hz durante 300ms, y detenerlo durante 200ms.
tone(PINBUZZER, 523, 300);
delay(200);
}
/*
Función que genera un par de tonos largos
*/
void tonoLargo() {
//generar tono de 440Hz durante 1000 ms
tone(PINBUZZER, 440);
delay(1000);
//detener tono durante 500ms
noTone(PINBUZZER);
delay(500);
//generar tono de 523Hz durante 1000ms, y detenerlo durante 500ms.
tone(PINBUZZER, 523, 1000);
delay(500);
}
/*
Función que realiza la petición de datos al sensor de CO2
*/
void sendRequest(byte packet[])
{
while (!sensor.available()) //keep sending request until we start to get a response
{
sensor.write(readCO2, 7);
delay(50);
}
int timeout = 0; //set a timeoute counter
while (sensor.available() < 7 ) //Wait to get a 7 byte response
{
timeout++;
if (timeout > 10) //if it takes to long there was probably an error
{
while (sensor.available()) //flush whatever we have
sensor.read();
break; //exit and try again
}
delay(50);
}
for (int i = 0; i < 7; i++)
{
response[i] = sensor.read();
}
}
/*
Función que recibe los datos del sensor de CO2
*/
unsignedlong getValue(byte packet[])
{
int high = packet[3]; //high byte for value is 4th byte in packet in the packet
int low = packet[4]; //low byte for value is 5th byte in the packet
unsignedlong val = high * 256 + low; //Combine high byte and low byte with this formula to get value
return val * valMultiplier;
}
secrets.h
En este archivo se meten todas las claves que NO deben ser públicas. Es por ello que no es exactamente el contenido del archivo, pero sí están todas las indicaciones para ponerlo a funcionar.
Se omiten los números de canal y las APIKEY correspondientes a cada canal sustituidas por “NUMERO_DE_CANAL_XX”, que debería ser un número y por “APIKEY_XX” que debería ser un código alfanumérico.
/*Tanto los nombres de los dispositivos como los canales y las APIKEYS quedan definidas en arrays para poder añadir nuevos dispositivos fácilmente.
* Esto se configura en el archivo principal eligiendo el índice del medidor. Actualmente están definidos los siguientes:
* 0: Medidor tipo que no manda datos a la nube
* 1: Medidor usado como prototipo; más quemado que la pipa de un hippie, pero ahí está el tío
* 2-4: Medidores 001, 002, 003 conectados al servidor externo de ThingSpeak.com
* 5-10: Medidores 001-006 conectados al servidor propio del Politécnico Jesús Marín
Con todo esto, más el esquema eléctrico correspondiente y la instalación del servidor ThingSpeak (o usando el servicio gratuito de la Web) es fácil reproducir los medidores realizados.
Esquema eléctrico
Esto aún necesita una revisión, porque el diseño es muy mejorable, pero el siguiente esquema indicado con etiquetas es totalmente funcional.
Con ese diseño, un posible conexionado de la PCB es como sigue:
En este caso un video vale más que mil palabras y aquí se muestra justamente el funcionamiento que se espera de la maqueta tiflológica con un audio de ejemplo sobre Pablo Picasso.
Ya tenemos un esquema eléctrico para cubrir esta funcionalidad, que es el que se muestra a continuación, realizada por uno de los alumnos de segundo del ciclo superior de mantenimiento electrónico que ha realizado antes esta práctica. Esta firmado, así que no es difícil saber quién es el autor.
Y el código lo publicaremos cuando acaben todos la práctica, no vamos a desvelar las soluciones antes de tiempo…
En posteriores trabajos ahondaremos en el diseño de la PCB, el empleo de una batería para hacer el montaje autónomo y la carcasa sobre la que se montará la maqueta.
Durante éste segundo curso de funcionamiento del grupo de trabajo Industria 4.0, entre otros propósitos, vamos a trabajar en el enriquecimiento, o aplicación de una modalidad de Realidad Aumentada, a una maqueta materializada mediante impresora 3D. Todo ello con el propósito de ofrecer información adaptada, para que sea accesible a colectivos que tengan alguna de sus capacidades mermadas, bien sean visuales o auditivas, es lo que se conoce como maquetas tiflológicas o táctiles.
La consecución del modelo 3D comenzó en el año 2015, cuando en el dpto. de Edificación iniciamos una investigación de los recursos disponibles en ese momento para la consecución del modelado tridimensional con técnicas de fotogrametría de elementos del patrimonio público, mediante fotografías de baja resolución, utilizando recursos propios y software y plataformas gratuitas o versiones para estudiantes. Para ello, nos basamos en las imágenes tridimensionales que utiliza el MOLA (Museo de Arqueología de Londres) para presentar algunos de sus hallazgos.
El objetivo principal era incorporar al currículo de nuestros alumnos del Ciclo Superior de Proyectos de Edificación las competencias básicas para trabajar con gabinetes de arqueología en el levantamiento y conservación de elementos de patrimonio histórico, bien sean yacimientos arqueológicos, edificios o parte de un edificio considerado BIC (Bien de Interés Cultural). Todo ello con objeto de satisfacer las necesidades de una nueva oportunidad de empleo, puesto que algunos arquitectos pertenecientes a gabinetes de arqueología nos habían solicitado alumnos para hacer las prácticas.
Para la composición de los modelos 3D recurrimos a portales gratuitos para estudiantes y profesores como son Angisoft Photoscan, Autodesk Memento o Autodesk 123 Catch ahora Autodesk ReCap Pro de los cuales se pueden obtener modelos en formatos de exportación STL, OBJ o FBX.
Para el pos procesado de los modelos también se puede utilizar software con versiones educativas o libres, como Autodesk 3DS Max o Blender. Nuestros alumnos ya disponen de las versiones educativas de AutoCAD y REVIT, ambas de Autodesk, por ese motivo elegimos los programas de éste proveedor para hacer todo el procesado de las fotografías y posterior retoque de los modelos hasta la obtención de un modelo definitivo imprimible en impresora 3D.
Maqueta de 10 cm de altura
Una vez acondicionado el modelo 3D se lo puede presentar con otras tantas tecnologías como pueden ser Realidad Aumentada, Realidad Virtual, fotografías 360º o maqueta por impresora 3D. Siguiendo este procedimiento, y con 40 fotos sacadas con su teléfono móvil, nuestro alumno Ángel Ramos ha modelado la figura completa de la figura de Pablo Ruiz Picasso sentado en un banco, situada en la plaza de la Merced de la capital malagueña.
Modelo digital mallado
El modelo final, una vez practicados los huecos para alojar elementos electrónicos en su interior, está compuesto por una malla de 34.800 caras (triángulos) y más de 52.700 aristas, lo cual nos dota de un modelo que, sin ser extraordinariamente preciso, permite identificar claramente al personaje modelado.
Maqueta de 20 cm de altura
La maqueta del prodigioso pintor es la que hemos elegido para trabajar éste curso en el grupo de trabajo Industria 4.0, en el que intentaremos conectarla a internet mediante tecnología de IoT (Internet of Things).
Vemos como meses después de ponerlos en marcha siguen funcionando a la perfección (aunque no conectados al servidor), lo cual es una gran satisfacción, porque han funcionado 24h y siguen dando valores correctos. Hay uno que se queda «pillado», pero simplemente porque no le llega la señal WiFi al sitio donde está colocado.
Ahora tenemos otro reto que será resuelto rápidamente sin duda por uno de los antiguos integrantes del grupo que es el hecho de que estos dispositivos funcionen en la nueva Andared corporativa. No es la cosa tan inmediata como pueda parecer. Para ello era necesario recopilar la MAC de los equipos. En nuestro caso era muy sencillo porque ya habíamos previsto que sería útil poder ver en todo momento esta información. Y aquí está, en las pantallitas de información:
Realmente no hemos dejado de trabajar en ningún momento. Este verano algunos han seguido investigando en Grafana, otros en preparar las maquetas, otros en mejorar el diseño del medidor de CO2, en buscar nuevas ideas o aplicaciones…
Este curso nos deja por otras ocupaciones el compañero Francis Valero cuyas aportaciones echaremos mucho de menos, pero nos deja a Andrés Alcaraz en su lugar representando a Informática y se incorpora otro fichaje estrella más: José Manuel Peula. Entre todos vamos a seguir buscando las excelentes sinergias que nos proporciona el hecho de coexistir en un mismo centro especialistas en campos muy diversos.
De las primeras reuniones que hemos tenido, como siempre, han surgido muchas cosas, pero queremos intentar centrarnos en estas:
Medidor de CO2 (mejoras y visualización y tratamiento de datos).
Maquetas tiflológicas (convertir el esqueleto electrónico actual en una maqueta funcional).
Politimer (pasar del prototipo a algo más funcional).
Falta por ver el grado de desarrollo que le conseguimos dar a estos puntos en función del limitado tiempo del que disponemos todos, pero en cualquier caso, un punto importante será conseguir la máxima implicación posible del alumnado en forma de retos, proyectos, ABP o como se le quiera llamar, que es tan simple como «quiero hacer algo, y vamos a ver la mejor manera de conseguirlo aplicando los conocimientos que se necesiten».
Otro punto importante será el tema de las publicaciones de lo que realizamos, que es un tema que estamos tratando además de lo que ya se publica en este blog y buscando la manera de darle la mejor forma posible (no desvelaremos sorpresas aún).
Añadimos aún más información en tiempo real actualizada cada minuto, esta vez de la humedad relativa en las 6 aulas que estamos midiendo. Es curioso poder ver de una pasada diferencias significativas entre diferentes sitios del centro. Por ejemplo, en la primera planta hay 10 puntos más de humedad que en el resto de plantas. Estaría bien poder comparar con los datos de planta 2, donde tenemos otro medidor, pero no llegan bien los datos por culpa de la cobertura de los puntos de acceso que tenemos instalados en el centro.
Hoy es un día lluvioso, así que quizás se pueda explicar porque en el resto de aulas están más aisladas que esta, pero seguiremos observando.
Acabamos de añadir una nueva página al blog con la información en tiempo real actualizada cada minuto de la temperatura en las 6 aulas que estamos midiendo. Ahora que se acercan días más calurosos será interesante monitorizar a qué temperaturas se llegan en diferentes espacios de nuestro centro, y lo podéis ver en directo aquí:
