msgbartop
Iä! Iä! Cthulhu Fhtagn!
msgbarbottom

28 ago 20 Adaptación a IoT de un difusor de aceites esenciales TENSWALL con control remoto IR

Seguimos con las adaptaciones a IoT. Otra de las que he realizado recientemente es la integración en mi sistema de domótica basado en Home Assistant de un difusor de aceites esenciales controlado por infrarrojos. A principio de verano le regalamos uno de estos difusores a mis cuñados para su casa, pero como también nos gustó para la nuestra, nos decidimos a comprar uno. Elegimos un modelo en Amazon con iluminación y control remoto por infrarrojos, un Tenswall de 500 ml.

Difusor de aceites Tenswall de 500 ml y control por infrarrojos

Difusor de aceites Tenswall de 500 ml y control por infrarrojos

Por lo que he podido averiguar, es un modelo bastante estandarizado vendido bajo multitud de marcas y fabricantes: se basa en el uso de frecuencias ultrasónicas para producir una vaporización del agua y los aceites esenciales a ella añadidos, generando una niebla que esparce las esencias, pero sin calentar el agua colocada en el depósito. Existen otros modelos más avanzados que integran capacidad WiFi y controlable desde una aplicación en el teléfono móvil, basado -por lo que recuerdo- en un ESP8266, pero el modelo que nosotros adquirimos tan sólo cuenta con capacidad IR. En realidad, una ventaja para lo que estaba buscando. El modelo que nosotros adquirimos tiene las siguientes funciones:

  • Encendido/apagado
  • Funcionamiento en modo intermitente (varios segundos generando niebla, varios segundos sin generarla)
  • Funcionamiento en modo continuo
  • Temporizador de funcionamiento a 60, 120 o 180 minutos, o bien en continuo
  • Funcionamiento con mucha niebla o poca niebla
  • Encendido de luces led, en modo carrusel, o 16 posiciones posibles
  • Apagado de las luces led

Para realizar la adaptación a IoT, lo primero fue capturar los códigos IR enviados por el mando a distancia. Para ello utilicé un receptor IR y una librería arduino que ya en su momento empleé para leer códigos del aire acondicionado. Capturé cada uno de los códigos asociados a los comportamientos indicados más arriba. Los adjunto por si a alguien más le sirvieran, en formato raw, y su equivalencia en protocolo NEC:

  • uint16_t rawDataOnOff[67] = {9040, 4466, 600, 532, 604, 530, 596, 538, 598, 536, 598, 534, 602, 532, 594, 538, 596, 536, 598, 1642, 598, 1642, 598, 1644, 598, 1644, 596, 1646, 596, 1644, 594, 1646, 594, 1646, 594, 538, 596, 536, 598, 560, 576, 558, 566, 568, 568, 564, 572, 562, 574, 560, 576, 1640, 602, 1640, 600, 1640, 600, 1640, 600, 1640, 600, 1642, 600, 1640, 600, 1642, 600}; // NEC FF00FF
  • uint16_t rawDataIntermittent[67] = {9040, 4462, 592, 540, 594, 540, 596, 536, 598, 534, 602, 532, 592, 542, 594, 538, 598, 536, 600, 1640, 600, 1642, 600, 1642, 600, 1642, 598, 1644, 598, 1644, 596, 1646, 596, 1646, 594, 1646, 594, 540, 596, 538, 598, 536, 600, 534, 602, 532, 594, 540, 596, 538, 598, 536, 600, 1640, 600, 1640, 600, 1642, 600, 1640, 600, 1642, 600, 1640, 600, 1642, 598}; // NEC FF807F
  • uint16_t rawDataContinuous[67] = {9032, 4466, 600, 532, 602, 530, 594, 538, 596, 536, 600, 534, 602, 530, 594, 540, 596, 538, 598, 1642, 598, 1642, 598, 1642, 598, 1642, 598, 1642, 598, 1642, 598, 1642, 600, 1642, 598, 534, 600, 1640, 600, 534, 592, 540, 594, 538, 598, 534, 600, 532, 592, 540, 596, 1644, 594, 538, 598, 1642, 598, 1642, 598, 1642, 598, 1642, 598, 1644, 598, 1642, 598}; // NEC FF40BF
  • uint16_t rawDataTiming[67] = {9032, 4464, 602, 530, 594, 538, 598, 536, 600, 532, 602, 530, 596, 538, 598, 534, 600, 532, 602, 1638, 604, 1636, 594, 1646, 594, 1646, 594, 1644, 598, 1642, 598, 1642, 598, 1642, 598, 534, 600, 532, 604, 530, 596, 1644, 598, 534, 600, 534, 602, 532, 594, 540, 596, 1644, 596, 1642, 598, 1642, 598, 534, 602, 1638, 602, 1638, 602, 1638, 604, 1636, 604}; // NEC FF10EF
  • uint16_t rawDataBigSmall[67] = {9034, 4466, 600, 532, 602, 530, 594, 538, 596, 538, 598, 534, 602, 532, 594, 566, 570, 564, 570, 1642, 598, 1642, 598, 1642, 598, 1642, 598, 1642, 598, 1642, 598, 1642, 598, 1642, 598, 1642, 598, 536, 600, 532, 602, 1638, 604, 530, 594, 538, 598, 536, 600, 534, 602, 532, 594, 1646, 594, 1646, 594, 540, 596, 1644, 596, 1644, 596, 1644, 598, 1644, 596}; // NEC FF906F
  • uint16_t rawDataLight[67] = {9040, 4462, 594, 538, 596, 536, 598, 536, 600, 532, 602, 532, 604, 530, 596, 538, 596, 538, 598, 1644, 596, 1644, 598, 1644, 596, 1644, 596, 1646, 594, 1646, 594, 1648, 602, 1640, 602, 530, 594, 1648, 602, 532, 594, 1646, 594, 540, 596, 538, 598, 536, 600, 534, 600, 1640, 600, 532, 592, 1648, 602, 530, 594, 1648, 592, 1648, 592, 1648, 592, 1650, 602}; // NEC FF50AF
  • uint16_t rawDataLightOff[3] = {9042, 2220, 596}; // NEC (Repeat) FFFFFFFFFFFFFFFF

Posteriormente pasé a crear un código arduino que se suscribe a un topic MQTT específico con el que se interactúa con el difusor. La idea es crear en Home Assistant un objeto que implemente las funciones del mando a distancia, y mapear los comandos enviados desde Home Assistant a los códigos IR anteriores. En Home Assistant, basta con crear un objeto de tipo luz, que implemente las funciones anteriormente descritas:


light:
- platform: mqtt
schema: json
name: Oil Diffuser & Light
state_topic: "<topic>"
command_topic: "<topic>/set"
brightness: true
rgb: false
effect: true
effect_list: [intermittent,continuous,timing,big/small,stopLight,lightOff]

…lo que genera una entidad con el siguiente aspecto:

Entidad generada en Home Assistant

Entidad generada en Home Assistant

Posteriormente, es necesario crear en Arduino un código que sea capaz de suscribirse al topic definido en Home Assistant, y reacciones a la información JSON enviada por éste. En realidad, todos los casos posibles son bastante sencillos. El caso que más complejidad tiene es el correspondiente a la luz, ya que el mismo botón/código sirve para encender la luz LED (que siempre empieza en carrusel de colores) y para rotar entre los 16 colores disponibles. En mi caso opté por mapear el deslizador de brillo definido (sin hacer uso de la paleta cromática) para escoger entre las 16 opciones de iluminación, más el modo continuo. En mi caso, opté por lo siguiente:

  • En el caso de recibir “1″ como valor de brillo (valor mínimo): Apagar la luz LED
  • En el caso de recibir “255″ como valor de brillo (valor máximo): Encender en el primer modo, correspondiente a la rotación de colores
  • Para el resto de valores: Calcular en cuál de los 16 tramos de luz se encuentra el deslizador (dividiendo el valor por 16), enviar el código de apagado (que consiste en simular una pulsación continua del botón de control de la luz durante 2 segundos), enviar el código de luz para entrar en el modo de rotación de colores, enviar de nuevo el código para detener la rotación de colores, y posteriormente tantas veces el código de luz como el tramo en el que nos hallemos (ya que este es el funcionamiento del dispositivo).

Por último, es necesario cargar el código en un ESP8266, equipado con un emisor IR. Dado que el difusor de aceites que yo escogí dispone de abundante espacio, es bastante sencillo colocarlo. En mi caso, el difusor se alimenta con un transformador de 24v en continua, que no se puede utilizar directamente para alimentar al ESP8266. En mi caso, opté por utilizar un buck converter DC-DC de 24v a 3.3v, con lo que queda solventado el problema de la diferencia de voltaje. ¡Y listo! Con todo esto es posible controlar un difusor de aceites simple desde la domótica de la casa.

VN:F [1.9.20_1166]
Rating: 10.0/10 (2 votes cast)

Etiquetas: , , , , , , ,

25 ago 20 Adaptación a IoT de un robot de limpieza Dirt Devil e integración en Home Assistant

Estos días he estado juegueteando un poco con un viejo robot de limpieza doméstico del Lidl, un Dirt Devil. Es un robot de limpieza bastante básico, con algo ya de tiempo a sus espaldas. No dispone de ninguna capacidad de integración con sistemas de domótica, ni nada que se le parezca. Es más, ni siquiera tiene WiFi. Pero tiene algo interesante: su funcionamiento se basa en el uso de un chip etiquetado como RV285R, que controla toda una placa de circuitos integrados para realizar las funciones del robot: movimiento de los cepillos, ventilador de succión, detección de golpes, sensores de vacío para que no se caiga por escaleras… El caso es que buscando un poco por Internet, encontré un par de páginas sumamente interesantes sobre cómo reemplazar este chip por un sistema Arduino. Así que aprovechando que sigo de vacaciones, no podía menos que dedicar algo de tiempo al asunto.

De acuerdo a la información compartida por Paijmans, el chip RV285R trabaja a 5 voltios, por lo que es posible hacerlo funcionar directamente en dispositivos Arduino. Con un trabajo de ingeniería inversa, fue capaz de obtener la información de a qué se dedican los pines del chip:

rv285r-pinout

Yo he podido refinarlo un poco más, distinguiendo las funcionalidades de los pines:

  • P50: Led azul, o de encendido
  • P67: Detector de colisión (bumper)
  • P66: Zumbador interno
  • VDD: 5 voltios
  • P65: Nada
  • P64: Ventilador
  • P63: Nada (Etiquetado como Reset por el fabricante)
  • P51: Led rojo, o de indicación de batería baja
  • P52: Motor de rueda izquierda, funcionamiento hacia delante
  • P63: Motor de rueda izquierda, funcionamiento hacia atrás
  • VSS: Tierra
  • P60: Nada (aunque sospecho que es detector de depósito lleno del robot)
  • P61: Motor de rueda derecha, funcionamiento hacia delante
  • P62: Motor de rueda derecha, funcionamiento hacia atrás

Una vez identificados los elementos del chip, era hora de abrir el robot. Se puede apreciar el chip en la parte central de la placa:

IMG_20200824_103439438

Aunque en Paijmans indican que es posible puentear cada una de las patas del chip y conectarlas directamente al arduino (ya que éste tiene más fuerza en las señales que las que pasa el chip), en mi caso he optado por desoldarlo, y conectarle cables de prototipado. Aunque en un principio parecía una buena idea, al poner de nuevo las carcasas del robot, en mi caso saltaron un par de soldaduras de sus pistas, por lo que tuve que hacer trabajo extra de soldadura. Recomiendo soldar directamente al cable:

IMG_20200824_185905184

Una vez soldados los cables, el siguiente paso es el dispositivo Arduino. He optado por hacer uso de un Wemos D1 Mini Pro, de la familia de los ESP8266, ya que proporciona capacidades WiFi, y viene sin los bornes para los cables de prototipado, por lo que podía soldar directamente los cables para ahorrar espacio. Para la lógica del mismo me he basado en la creada por Conrad Vassallo (Converting a cheap Vacuum Robot into IoT) en su proyecto de domotización, ya que está preparado para integrar directamente en un sistema de domótica Home Assistant.

IMG_20200824_185913934_HDR

Algunos comentarios:

  • He tenido que hacer algunas modificaciones al trabajo de Conrad, ya que en el código que comparte faltaba la parte de conectar a la red WiFi el ESP8266. También he eliminado algunas librerías de las que no se hacía uso (EEPROM, Wire). Además he tenido que adaptar los valores de detección de batería baja (más en el siguiente punto) para que se amoldara a mi caso.
  • Conrad ha añadido al proyecto base una idea interesante: un detector de voltaje de la batería de 16v del robot. Usa para ello el pin A0 del ESP8266, que tiene capacidad para medir voltajes. Sin embargo, es necesario utilizar un conversor de voltaje para no quemar el disposito. Un simple divisor de voltaje con dos resistencias funcionará bien, y esta información estará disponible para Home Assistant.
  • Carga el código antes de soldar los pines provenientes de la placa. Una vez soldados, ya no es posible cargar código al Wemos a través del puerto microUSB, ya que el pin D4 mete ruido. En mi caso, tuve que desoldar. Para evitar este problema sería interesante añadir actualización OTA, pero me temo que eso quedará para una nueva versión.
pinout-wemos-mini-d1

Esquema de conexiones del D1 Mini Pro. Atención al uso del pin D4 para el envío de datos como puerto serie desde el Arduino IDE

Por último, queda la parte de Home Assistant. Con añadir el siguiente código a la configuración, el sistema estará preparado para interactuar con el robot:

vacuum:
- platform: mqtt
command_topic: "vacuum/command"
battery_level_topic: "vacuum/state"
battery_level_template: "{{ value_json.battery_level }}"
charging_topic: "vacuum/state"
charging_template: "{{ value_json.charging }}"
cleaning_topic: "vacuum/state"
cleaning_template: "{{ value_json.cleaning }}"
docked_topic: "vacuum/state"
docked_template: "{{ value_json.docked }}"
error_topic: "vacuum/state"
error_template: "{{ value_json.error }}"

El intercambio de información entre el robot y Home Assistant se realiza mediante MQTT. A continuación se puede ver una captura de los datos intercambiados:

mqtt-capture

¿Y el resultado? Espectacularmente bueno. Dejo un par de vídeos. El primero, con el robot aún abierto, y con una Victorinox haciendo de contrapeso, ya que si no, los sensores de vacío entran en funcionamiento:

…y el segundo, ya con las carcasas colocadas, y probando algunas funcionalidades adicionales, como la limpieza específica en un punto concreto:

Fuentes:

VN:F [1.9.20_1166]
Rating: 10.0/10 (1 vote cast)

Etiquetas: , , , , , , , , ,

23 ago 20 Pruebas de comunicación LoRaWAN: conseguido enlace de 7,2 km

Estos días he estado de vacaciones en Galicia, donde he podido seguir con las pruebas de alcance con tecnología LoRa. Estas pruebas consistieron en la repetición de la efectuada en Santiponce el pasado mes de mayo, pero sustituyendo la orografía prácticamente plana de Sevilla por una zona montañosa de las cercanías de Pontevedra.

IMG_20200812_174934627_HDR

Vehículo y entorno de pruebas. Nótese la antena LoRa en la parte frontal del techo del vehículo

En realidad, se realizaron dos pruebas distintas: una de corto alcance, y una de largo alcance. En ambos casos se utilizaron los siguientes elementos y escenario:

  • Escenario de pruebas: La prueba consistió en la transmisión de datos de un pulsómetro Bluetooth LE a un servidor MQTT, donde se volcarían las pulsaciones registradas, junto con el RSSI de la transmisión, para su posterior consumo por terceros sistemas. Para ello, se hacía uso de un emisor Heltec Lora 32, con capacidad BLE y LoRa, que sería el encargado de recibir la información del pulsómetro, cifrarla y transmitirla vía LoRa al gateway LoRaWAN. Éste último recibiría la señal del emisor, la decodificaría, calcularía el RSSI e inyectaría la información resultante en formato JSON en un servidor MQTT. Por último, se preparó un servidor Grafana para representar gráficamente la información de las pulsaciones recibidas.
  • Dispositivo emisor: Como se ha comentado, consiste en un conjunto de sensor de pulsaciones BLE, que envía la información al dispositivo Heltec Lora 32 a 433 MHz. Para mejorar el alcance del dispositivo, se le ha dotado de una antena de 7 dBi, ubicada en el techo de un coche para poder realizar pruebas en movilidad. La información se envía codificada en hexadecimal para necesitar menos bytes a la hora de poner los datos en el aire.
    IMG_20200812_174537088
  • Dispositivo receptor: El dispositivo receptor consiste en un segundo Heltec Lora 32, que recibe la información enviada por el emisor, decodifica la información, calcula el RSSI -que nos da información sobre la calidad del enlace realizado- compone un JSON con ambos parámetros, e inyectar el mismo en un servidor MQTT. Como en el caso del emisor, se ha reemplazado la antena de fábrica por una antena de 7 dBi, emplazada para las pruebas en una ubicación en altura.
    20200812_162258
  • Cliente MQTT: Para obtener una primera verificación de los datos obtenidos, se utiliza un cliente MQTT en un teléfono Android, suscrito al topic en el que se vuelcan los datos por parte del gateway. Un ejemplo de la visualización de los datos se puede observar en la siguiente imagen:
    Screenshot_20200812-184803
  • Visualización de datos en Grafana: Además de la primera visualización de datos en el cliente MQTT, se preparó un servidor Grafana para visualizar los datos volcados en el MQTT, y representar una gráfica con los datos de las pulsaciones. Esta representación, además de proporcionar de una manera gráfica en un solo vistazo el histórico de datos recibidos, permitió también dilucidar -a posteriori- si algunos problemas de falta de recepción de datos en el cliente MQTT se debían a carencia de enlace LoRa o a falta de conexión de datos desde el cliente MQTT. Para nuestra sorpresa, estos problemas se debieron a lo segundo, y no a lo primero. Una muestra de la visualización de datos obtenida:
    Screenshot_20200812-194236

Éste sería un esquema de los dispositivos implicados y las comunicaciones entre ellos:

diagrama-comunicaciones

Una vez definido el escenario y elementos de prueba, pasé a definir las pruebas propiamente dichas. Estimé conveniente realizar una primera prueba de corto alcance en las cercanías, y en caso de obtener éxito en la misma, pasar a una segunda de largo alcance.

Prueba de corto alcance. 3,08 km

La prueba de corto alcance consistió en un enlace de una distancia estimada de unos 3 kms, desde una casa situada en la aldea de Vilarchán -Puente Caldelas- hasta el monte de La Fracha, donde se encuentran una serie de antenas y repetidores de radio y televisión. La idea era observar cómo de fiable era la transmisión en este entorno de montaña, con visibilidad directa desde el emisor al receptor, pero con obstáculos consistentes en otras viviendas, zonas arboladas y, en determinados tramos, la propia mole rocosa de la montaña.

la-fracha

Lúa saíndo polo monte da Fracha (Pontevedra), cortesía de Pintafontes

EL objetivo de esta prueba era calibrar el impacto esperable de la diferencia de orografía entre Santiponce y Vilarchán, para determinar el impacto de la misma en la transmisión. Hay que tener en cuenta que en el caso de Santiponce se había observado que se podía obtener, con el mismo equipo de pruebas, un enlace confiable de 4,5 km, y hasta 5,3 km de manera esporádica.

gmaps1-fracha

Recorrido en Google Earth de la prueba efectuada

Salimos de Vilarchán con el emisor funcionando, y pronto se perdió la señal, apenas al llegar a la carretera de Pontevedra a Puente Caldelas. Durante todo el trayecto, pasando por el polígono de La Reigosa y la subida a la Fracha, hasta las cercanías del polvorín, no se recibió señal alguna. Una primera decepción. Bajamos del coche y empezamos a andar, camino de las antenas, por la parte de la montaña contraria a la casa. Y ahí, sorpresa, empezamos a recibir datos, si bien con un RSSI muy débil, de -131. Una primera medición de distancia nos dio 3,01 km de distancia en línea recta al emisor, pero con toda la ladera del monte obstaculizando la señal. Proseguimos el ascenso hasta las antenas, sin perder recepción de datos en ningún momento, y con la calidad de la señal mejorando a medida que salíamos de la sombra de la montaña, y ganábamos en línea de visión directa hacia el emisor.

20200812_171838-editada

Vista desde las antenas de la zona de pruebas, con la zona aproximada del receptor marcada

Realizamos el ascenso a las antenas por la ladera que daba hacia la zona de la casa. Al llegar a las mismas, siempre sin perder la señal, obtuvimos un enlace de 3,08 km, con un mejor RSSI de -111. Como valor comparativo, en la misma casa y a unos 5 metros de distancia, el RSSI rondaba los -85. En cuanto a la visibilidad, se puede considerar casi directa, y el casi es porque hay algunas edificaciones que se interponen entre el punto donde estaba ubicado el receptor, y el punto donde nos encontrábamos.

Screenshot_20200812-171110_OruxMaps-1

Captura de pantalla de la distancia observada con Oruxmaps entre nuestra posición a la ubicación del receptor

Tras verificar durante un rato de la estabilidad de la conexión, y disfrutar un poco de las vistas, emprendimos el descenso hasta el vehículo, si bien esta vez por la ladera opuesta, que dispone de un camino que facilitaba la bajada, y que además nos permitía determinar en qué punto la mole del monte obstaculizaba la señal hasta que ésta se perdiera.

20200812_172055

Vistas de la Ría de Pontevedra desde La Fracha

Durante un buen rato de descenso se mantuvo la recepción de la señal, si bien con deterioros del RSSI paulatinos. Perdimos la señal a una distancia de 2,81 km del receptor, si bien con toda la ladera interpuesta entre nosotros y el gateway receptor. Sin embargo, al llegar al coche, volvimos a recuperar la señal, que ya no volvimos a perder en todo el trayecto de vuelta hasta la casa, en gran contraste con la observación realizada a la ida, donde pronto se perdió la señal. Posteriormente, y tras analizar los datos reflejados en Grafana, pudimos ver que en realidad el en trayecto de ida nunca se llegó a perder la señal LoRa entre emisor y receptor, sino que habíamos tenido un problema de falta de datos en el teléfono con el cliente MQTT, que había provocado una desconexión con el servidor MQTT -y una aparente pérdida de datos-. Es decir: que salvo en un punto muy localizado de La Fracha, habíamos tenido enlace LoRa casi de manera constante y sin pérdida de datos, pese a las dificultades del terreno, zonas boscosas y construcciones interpuestas. Una primera prueba sumamente satisfactoria.

Prueba de largo alcance. 7,2 km

La segunda prueba era la verdaderamente significativa: intentar un enlace directo con un grupo de antenas de radio, ubicadas a una distancia aproximada de 7 kilómetros, con línea directa de visión, en torno a un 60% más de distancia que las pruebas efectuadas en Santiponce.

IMG_20200812_194815559_1

Vista desde la antena del receptor, con la zona prevista del emisor marcada

Si bien la distancia en línea recta entre ambas ubicaciones ronda los 7 km, es preciso realizar unos 13 km de recorrido para poder llegar de la una a la otra, debido a orografía del terreno y las vías de comunicación existentes, como se puede apreciar en el recorrido de etapa trazado en Google Earth:

gmaps1-penarada

Para esta segunda prueba movimos la ubicación del receptor a una ventana con visibilidad directa de la zona de pruebas, con el objetivo en mente de dirigirnos a una zona de repetidores ubicada en el Monte Catadoiro, cerca de Rebordela. La diferencia es que esta vez podríamos ir directamente con el coche hasta la zona escogida. Dicho y hecho, salimos en dirección Puente Caldelas. Y al igual que en la primera prueba, perdimos la recepción de datos justo al llegar a la carretera. Y al igual que en el caso anterior, estuvo motivada por la pérdida de datos del teléfono Android. Al llegar a las antenas, pudimos ver que el cliente MQTT se había desconectado. Y al volver a conectar… ¡éxito! Los paquetes llegaban sin pérdida, y con un RSSI espectacularmente bueno, de -115 en el mejor de los casos. Tras las pertinentes comprobaciones, verificamos que habíamos logrado un enlace de 7,23 km con línea directa de visión.

Screenshot_20200812-183019_MyMQTT

Primeros paquetes recibidos en el cliente MQTT una vez restablecida la conexión

Screenshot_20200812-183920

Captura de Oruxmaps en la que se aprecia la distancia alcanzada

IMG_20200812_184526000

En las antenas

Estuvimos un rato en las antenas, observando el comportamiento de los datos: sin pérdidas, y con un RSSI que hace pensar que es posible mantener distancias aún mayores de manera confiable. Si no pudimos ir más lejos fue porque la montaña ya no daba para más. :D Disfrutamos un rato de las vistas, y poco después emprendimos el regreso.

IMG_20200812_183845500_HDR

Vista de la zona aproximada del gateway, a través de unos prismáticos

IMG_20200812_184346134_HDR

Vista de la ría de Vigo, con el puente de Rande y las Islas Cíes al fondo

Y de nuevo la sorpresa vino en el trayecto de vuelta. Durante todo el recorrido, de casi 14 kilómetros, por zonas boscosas, sin visibilidad directa, con laderas, bosques y pueblos entre medias, no se perdió la señal en ningún momento, como pudimos verificar consultando Grafana. Esto incluye el paso por Puente Caldelas, en la más profundo del valle del Río Verdugo, y en un entorno completamente urbano y sin visibilidad directa, a más de 5,5 km de distancia desde el gateway; y también en la central hidroeléctrica de Hidrofreixa, a 5’3 km, aunque en este caso con visibilidad directa.

20200812_190719

Estación de bombeo de Hidrofreixa

Screenshot_20200812-191026_OruxMaps

Enlace desde Hidrofreixa, de 5,48 km

En lo referente a los datos de Grafana, en esta captura se ven las gráficas de pulsaciones:

captura-grafana-pruebas

Por cierto, que en realidad mis pulsaciones no son tan altas, sino que he observado que mientras no empiezo a sudar en serio el pulsómetro muestra exceso de pulsaciones al alza. :mrgreen: En cuanto a los huecos, el correspondiente a las 16:48 a las 16:57 es una de las zonas de sombra de La Fracha, lo mismo que el de pasadas las 17:30. El de las 17:46 a las 18:03 corresponde al tiempo entre prueba y prueba (con cambios de ubicación de antenas y resto de elementos), y los dos huecos posteriores a momentos en que el pulsómetro Bluetooth salió del rango de alcance del emisor LoRa.

Y para cerrar, tenemos ya planificadas nuevas pruebas de alcance: en este caso, a dos campos de aerogeneradores, ubicados a 15 y 25 km de distancia desde Vilarchán. Pero de eso ya hablaremos en otro momento…

VN:F [1.9.20_1166]
Rating: 10.0/10 (1 vote cast)

Etiquetas: , , , , , , , , , , , ,

05 may 20 Nuevas pruebas de enlaces LoRa

Después de las pruebas de comunicación LoRa realizadas el pasado día 2, el 3 volví a salir en los ratos en los que hay autorización para salir de casa por el coronavirus, con el objeto de realizar una prueba que complementara a las realizadas el día anterior. Según había comentado, la primeras pruebas las realicé hacia el norte y el sureste de mi domicilio en Santiponce, ya que esas ubicaciones se encuentran relativamente libres de obstáculos propios de la orografía del terreno, pero que albergaba mis dudas sobre el alcance de los enlaces hacia el oeste, debido a que las colinas donde se ubican Itálica y la propia Santiponce se interponen en cualquier línea de visión directa. Es más, las edificaciones del propio casco urbano bloquean en gran manera las señales entre emisor y receptor. Teniendo en cuenta estos condicionantes, no quería que la primera de las pruebas se desvirtuara con este entorno tan desfavorable, por lo que opté por hacer las pruebas de alcance en otras ubicaciones.

Sin embargo, también resultaba interesante en sí probar el alcance de la señal en entornos más adversos, y en el caso particular de Santiponce, me interesaba hacer la prueba porque hacia el oeste desde mi domicilio transcurre la Vía Verde de Itálica. Esta vía verde, antiguo ferrocarril minero entre el cargadero de mineral existente en Camas y la mina de Aznalcóllar, permite circular entre campos de labranza por la campiña sevillana, por lo que es bastante interesante para hacer pruebas de dispositivos IoT en zonas rurales y agrícolas. Ante todo esto, el domingo me dispuse a hacer una nueva prueba. Además, para llegar a la vía verde, es preciso atravesar parte del casco urbano del pueblo, lo que me daba oportunidad de probar el alcance de la señal en una zona con la visión directa completamente bloqueada por edificios.

Realicé la prueba a las 8:00h del domingo, y de nuevo, los resultados fueron mucho mejores de lo esperado. En la zona urbana no llegó a perderse la señal en ningún momento, pese a la falta de visión directa, discurrir entre edificios, y con la propia ladera de Santiponce bloqueando la señal. Una vez en campo abierto, donde existe vegetación densa en la cerca de Itálica que bloquea la visión, y donde el propio cerro de Itálica se interpone entre mi receptor y la vía verde, la señal se recibió en todo momento, salvo en dos pérdidas puntuales en la zona más alejada del recorrido, a 1300 metros del receptor. Incluso en el camino de vuelta, de nuevo con la arboleda de Itálica y un cerro bloqueando completamente la visión, la señal no se interrumpió en ningún momento. A continuación dejo una vista con Google Earth de la prueba efectuada y el recorrido realizado.

Vista en Google Earth de la prueba del 3 de mayo

Vista en Google Earth de la prueba del 3 de mayo

Como comentario adicional, me llamó la atención la gran cantidad de gente que se encontraba en esos momentos en la vía verde, aprovechando el tiempo permitido de salida por el coronavirus. Algo que he podido constatar los dos días posteriores, cuando he salido a hacer algo de bici.

VN:F [1.9.20_1166]
Rating: 10.0/10 (1 vote cast)

Etiquetas: , , , ,

29 ene 17 Sistema de telemetría y geoposicionamiento para vehículos

Escribía en mi entrada anterior que estaba trabajando en un sistema de telemetría para el Mercedes. Durante estas últimas semanas he estado realizando algunas mejoras en el sistema, y si bien aún es posible incorporar algunas más, en este momento ya empieza a tener un desarrollo bastante definido. En pocas palabras, se trata de un sistema de telemetría que recoge datos de dos fuentes, la centralita del coche y un módulo GPS, para transmitirlo a un servidor donde se almacenan los datos para su posterior tratamiento. En este momento, el tratamiento consiste en dos actividades: representación gráfica de velocidad, revoluciones por minuto y consumo del coche, y geoposicionamiento en mapas en tiempo real. Este es un esquema básico de la plataforma:

Esquema del sistema de telemetría

Esquema del sistema de telemetría

El sistema está compuesto por los siguientes elementos:

  • Sonda de captura de datos: La sonda de captura de datos consiste en una Raspberry Pi que se conecta con la centralita del coche mediante un módulo bluetooth. La centralita del coche se ha equipado, a su vez, con un módulo OBD-II con bluetooth. Esta sonda, de igual manera, dispone de un módulo GPS para proporcionar datos relativos a la posición del vehículo.
  • Programa de telemetría: En la sonda de posicionamiento he desplegado un programa que recopila información de las fuentes anteriores, que he desarrollado en Python. Este programa, en líneas generales, comprueba el estado de las fuentes de datos antes mencionados, recopila la información y la prepara para su transmisión. Para ello, se apoya en un broker MQTT instalado en la propia sonda. Por último, se hace un almacenado local en ficheros csv de la información recopilada, junto con una marca de tiempo.
  • Broker MQTT local: Para realizar la transmisión de datos al servidor de almacenamiento y procesado de datos se hace uso de un broker MQTT local. MQTT es un protocolo ligero de mensajería para pequeños sensores y dispositivos móviles ideado por IBM. Está optimizado para realizar la transmisión de datos incluso en redes no confiables y en entornos de alta latencia, por lo que es ideal para delegar en él la capa de transmisión de datos del programa anterior, ya que es presumible que el vehículo pueda encontrarse en situaciones de escasa cobertura o incluso pérdida total de la misma, además de en situaciones en las que la transmisión de datos haya de efectuarse haciendo uso de redes GSM de escasa capacidad. Además, tiene la ventaja de que produce menos sobrecarga que otros protocolos como HTTP, y (en teoría) hace un menor consumo de datos. La idea es la siguiente: el programa anterior delega en el broker MQTT el establecer el envío de paquetes al servidor. El broker MQTT actúa además como buffer local de los paquetes transmitidos, en caso de pérdida o inestabilidad de las comunicaciones. Este buffer local, gracias a una pequeña base de datos interna, es persistente incluso ante reinicios inesperados de la sonda. El broker MQTT local está sincronizado con otro broker MQTT desplegado en el servidor de recepción de datos, y es capaz de garantizar la correcta sincronización, como se ha comentado, incluso en situaciones de pérdida total de conectividad y reinicios en la sonda de datos.
  • Envío de datos mediante tethering bluetooth: El broker local MQTT es dotado de conectividad a Internet mediante tethering bluetooth con un teléfono móvil. Si bien a priori sería más interesante hacer uso de tethering wifi para esto mismo, hay tres buenas razones para optar por bluetooth: La primera es que al hacer uso de MQTT el volumen de información a intercambiar es bastante reducido, por lo que es posible hacer uso de bluetooth para ello, con el consiguiente impacto positivo en el consumo de energía necesario para establecer el canal de datos. La segunda es una limitación física en la sonda. La Raspberry Pi 2 que utilizo tiene sólo dos puertos USB, uno usado con el módulo GPS y otro con el módulo bluetooth para conectar con la centralita, por lo que no queda sitio para un módulo WiFi. Y la tercera, es que todo es mejor con bluetooth. :mrgreen:
  • Servidor de recepción de datos: El segundo bloque del sistema es el servidor de recepción y análisis de datos. Consiste en líneas generales en un servidor Graphite donde se almacenan los datos proporcionados por la sonda de captura de datos, y que permite su posterior utilización, bien para la representación de gráficas de dichos datos mediante Grafana, bien para la el geoposicionamiento del vehículo en tiempo real, con información añadida del resto de parámetros proporcionados por la sonda.
  • Broker MQTT: La comunicación, como se ha comentado, se realiza mediante un broker MQTT que sincroniza con el broker MQTT de la sonda. Este broker recibe los datos proporcionados por la sonda, y los inyecta, mediante una pasarela desarrollada en Python, en el servidor Graphite. Dado que es posible que la información proporcionada por el broker MQTT de la sonda no se reciba en tiempo real debido a posibles cortes en las comunicaciones, se hace uso de la marca de tiempo incluida en cada transmisión de la sonda remota para inyectar los datos en el servidor Graphite con información de tiempo de creación correcta.
  • Servidor Graphite: El servidor Graphite consolida la información proporcionada por la sonda de captura de datos, la almacena en una sistema de base de datos buffer de corta duración (Carbon) y posteriormente la consolida en una base de datos da larga duración (whisper).
  • Servidor Grafana: Los datos consolidados en el servidor Graphite son consumidos por Grafana, software para visualización de métricas. Se han creado una serie de gráficas que permiten acceder a la información relativa a la velocidad, revoluciones por minuto, entrada de aire en el motor, consumo de combustible y altitud con respecto al mar, así como a sus valores medios en un rango de tiempo establecido. Grafana proporciona, además, la capacidad de integrar estas gráficas en una plataforma de terceros.
  • Captura de posicionamiento de vehículo con datos en tiempo real

    Captura de posicionamiento de vehículo con datos en tiempo real

  • Sistema de geoposicionamiento: El broker MQTT permite, además, el procesamiento de la información proporcionada por la sonda para representar en tiempo real la ubicación geográfica del vehículo, así como la traza de las posiciones anteriores mediante una línea de posición. Además, se proporciona información en tiempo real de los parámetros proporcionados por la sonda. Este sistema está basado en Node-RED, una herramienta desarrollada por IBM para permitir una interconexión sencilla de diversas aplicaciones y dispositivos IoT. También hace uso de OpenStreetMap, mediante la librería WorldMap.

Todo este sistema lo he compilado en la siguente web para su visualización: Telemetría (www.eniac2000.com/telemetria)

Dado que la información mostrada en esa URL proporciona datos en tiempo real, he realizado una captura de datos obtenidos en vivo:

Captura del sistema de telemetría

Captura del sistema de telemetría

…así como un vídeo en el que se aprecia la información, si bien realizando la captura de la información desde las dos fuentes de datos separadas, y no desde el mismo portal:

Como comentaba, el sistema está aún en una fase muy temprana, pero el potencial de mejora es grande. Los principales puntos en los que estoy trabajando son los siguientes:

  • Mejora en la seguridad de comunicaciones entre brokers MQTT
  • Mejora en la fiabilidad de la comunicación OBD-II
  • Reemplazo del sistema de base datos de larga duración de Graphite por un sistema NoSQL, presumiblemente un InfluxDB
  • Dotar de redundancia a los elementos de la plataforma
  • Proporcionar un sistema de persistencia de la información
  • Creación de un portal multiusuario con soporte de múltiples dispositivos
  • Otros… :)

Si bien este proyecto empezó como algo personal, con la idea de comprobar cuánto consumía mi coche en los desplazamientos, tengo el convencimiento de que puede convertirse en algo más que en un mero pasatiempo. Esperemos que así sea.

VN:F [1.9.20_1166]
Rating: 10.0/10 (2 votes cast)

Etiquetas: , , , , , , , , , , , ,