msgbartop
Deme diez hombres como Clouseau y podría destruir el mundo
msgbarbottom

25 jul 21 Codificación y envío de imágenes por MQTT, y uso de las mismas en HomeAssistant

En fechas recientes he realizado un aprovechamiento interesante de las capacidades de comunicación que proporciona el servidor MQTT que tengo instalado para diversos temas: el envío de imágenes a través del mismo. en principio no es algo para lo que esté pensado un servidor MQTT, que actúa como servidor de mensajería, mediante la suscripción a una serie de topics, mediante los cuales clientes del servidor MQTT pueden intercambiar información en formato texto. Pero como al fin y al cabo, las imágenes no dejan de transmitirse como información codificada, es posible ponerse algo creativo para conseguir su procesamiento correcto.

En mi escenario, se trataba de compartir información proveniente de una webcam, para integrarla en mi sistema de domótica. En otras circunstancias, consumiría la información directamente de la webcam, pero el servidor de domótica y la webcam se encuentran en ubicaciones geográficas distintas, y la red de la webcam se encuentra tras un CG-NAT, por lo que no es posible establecer una publicación directa de puertos. Existe la posibilidad de establecer una VPN, pero esta opción me parecía bastante más interesante. La webcam se trata de una ESP32-CAM, con capacidad para publicar imágenes tanto en formato streaming como imágenes individuales, y acceder a ellas a través de una URL concreta. Mi idea era aprovechar la capacidad de Python de convertir imágenes a arrays de bytes, y volcar la información a un topic MQTT específico, para su posterior consumo. Consumo que en una primera instancia sería una publicación directa en Home Assistant, pero que posteriormente se vio complementado con una idea adicional interesante.

Esquema general del envío de imágenes por MQTT

Esquema general del envío de imágenes por MQTT

Codificación y envío de la imagen por MQTT

La primera parte de este proyecto consiste en el volcado de la información de la imagen en un topic MQTT. En mi caso, aprovechando que dispongo de un servidor Orange Pi Zero instalada en Forcarey para controlar diversos dispositivos Zigbee, creé un pequeño script en Python que toma una captura de imagen de la ESP32-CAM, la vuelca en un fichero temporal, y posteriormente la codifica como un bytearray, para enviarla a un topic MQTT concreto. El código sería el siguiente:

mport paho.mqtt.publish as publish
from PIL import Image
import requests
from io import BytesIO

MQTT_SERVER = “xxx.xxx.xxx.xxx” #Write Server IP Address, or your server FQDN
MQTT_PATH = “path” #Write your MQTT topic path

response = requests.get(“http://xxx.xxx.xxx.xxx/capture”) #Write your ESP32-CAM IP address
f=open(“/tmp/image_test.jpg”,”wb”)
f.write(response.content)
f.close

f=open(“/tmp/image_test.jpg”, “rb”)
fileContent = f.read()
byteArr = bytearray(fileContent)
publish.single(MQTT_PATH, byteArr, hostname=MQTT_SERVER)
f.close

Bastante sencillo. Para no andarme loco con servicios en linux, me limito a invocarlo desde /etc/crontab una vez cada 5 minutos, aunque se puede programar la frecuencia que se desee.

Captura y publicación en Home Assistant

Una vez tenemos nuestra imagen siendo volcada en el topic MQTT correspondiente, se trata de explotarla de manera adecuada. Y en este caso, Home Assistant nos lo pone bastante sencillo, ya que existe una integración de tipo cámara MQTT directamente incorporada a Home Assistant. Su uso es tan sencillo como indicar el topic del que tendremos que recoger la imagen:

camera:
– platform: mqtt
name: MQTT Cam
topic: MQTT_TOPIC_PATH

El resultado es el que sigue:

Captura de cámara MQTT en Home Assistant

Captura de cámara MQTT en Home Assistant

En mi caso, una topa del recibidor del piso de Forcarey.

Otros usos: sistema de alarma mediante correo electrónico con Node-Red

Pero estando ya este sistema montado, y merced a algunos detectores de apertura de puertas y ventanas Zigbee que ya tenía previamente instalados, es posible dar una vuelta de tuerca, y hacer algo más interesante: un sistema que detecte aperturas no deseadas de la puerta de la entrada, que tome varias imágenes, y las envíe por correo electrónico a un buzón previamente definido. El proceso es el siguiente: tengo instalado en la puerta un sensor de apertura Zigbee. La información de este sensor es procesada por un servidor Zigbee2MQTT, que vuelca en un topic MQTT la información de cuándo se activa este sensor. Este topic es procesado mediante una automatización en Home Assistant que, cuando se encuentra activada, envía una señal de alarma mediante un segundo topic MQTT. A su vez, tengo un script en Python en la Orange Pi Zero de Forcarey que se encuentra suscrito a este topic, y que cuando detecta una activación del mismo, toma tres imágenes a intervalos regulares, y las envía codificadas como bytearray por un tercer topic MQTT. Y por último, tengo creado en Node-Red un flujo que está suscrito a este último topic, descodifica las imágenes, y las envía a una cuenta de correo como un adjunto.

Flujo de Node Red de envío de correo

Flujo de Node Red de envío de correo

Admito que tiene que haber maneras más sencillas de hacerlo, pero esta resulta bastante instructiva. :mrgreen:

VN:F [1.9.20_1166]
Rating: 0.0/10 (0 votes cast)

Etiquetas: , , , , , , ,

31 ene 21 Concentrador Zigbee basado en software libre: zigbee2mqtt

Llevo ya unos cuantos artículos hablando sobre mi sistema de domótica, y hasta ahora he omitido uno de los puntos centrales del mismo: el concentrador zigbee. Mi sistema de domótica es algo sui generis, ya que es un compendio de distintas piezas que he ido amalgamando con el paso del tiempo. El punto central del mismo es el estupendo software Home Assistant, junto con un servidor MQTT. Sobre este núcleo he ido añadiendo diversos dispositivos, empezando por hardware basado en NodeMCU programados por mí mismo. Empecé con ello en 2016, en Irlanda, pero realicé algunos proyectos preliminares aún antes, pero completamente desacoplados. Pero todo lo hecho ha tenido como hilo común el experimentar con diversas tecnologías.

Como parte de ese proceso de experimentación acabé introduciendo dispositivos Zigbee. Son unos elementos interesantes, y la tecnología en la que se basan ha tenido gran difusión en el ámbito de la domótica doméstica. Para transmitir la señal se basan el frecuencia de 2’4GHz, lo que provoca que en entornos saturados de redes WiFi y Bluetooth estemos añadiendo más elementos que pueden provocar perturbaciones. Sin embargo, no es ese su gran problema. El gran problema que tienen es que estos dispositivos necesitan de un aparato que realice las veces de concentrador de señales, actuando como pasarela entre los dispositivos en sí y el software de control que nos permite interactuar con ellos. Y si este concentrador fuera genérico, no sería demasiado malo, pero cada fabricante requiere que uses el suyo y nada más que el suyo, lo que implica que no es posible mezclar, por ejemplo, luces del sistema TRÅDFRI de Ikea con sensores de temperatura Xiaomi, o interruptores Silvercrest de Lidl, a menos que quieras tener que usar tres concentradores y tres aplicaciones distintas para cada componente. Un verdadero rollo.

Y es aquí donde entra nuestro amigo el software libre. Existe un magnífico proyecto de desarrollo de un concentrador multifabricante que permite precisamente eso: utilizar un solo concentrador abierto para gestionar dispositivos de diversos fabricantes. Ese es el proyecto zigbee2mqtt. La idea de partida es sencilla: escuchar las señales Zigbee de los diversos dispositivos, procesarlas, e inyectarlas en un servidor MQTT para poder ser utilizadas posteriormente como mejor convenga a tus intereses. Sencilla, pero brillante. Y en mi caso, dado que ya disponía de un Home Assistant configurado y mi servidor MQTT, algo que me venía como anillo al dedo.

Arquitectura de zigbee2mqtt

Arquitectura de zigbee2mqtt

Sin embargo, hasta ahora he hablado sólo de sofware, y para construir un concentrador que reciba señales físicas es preciso de algo de hierro. El hardware esencial es el adaptador Zigbee que recibe las señales de los dispositivos. En mi caso hago uso de un adaptador CC2531, que se conecta por USB. Es preciso programarlo con un firmware que en la propia página de zigbee2mqtt se encargan de proporcionar. Y además de eso, hace falta un dispositivo linux donde instalarlo. La respuesta más obvia es una Raspberry Pi, pero hay otras alternativas:

  • En mi caso, allá por 2016, empecé utilizando una Asus Tinker Board, que por aquel entonces ofrecía mucha más potencia que la Raspberry Pi 2 que había disponible. Una placa estupenda, con mucha potencia, y con una versión de linux, Linaro OS, basada en Debian, por lo que ofrecía todo lo que necesitaba. Sin embargo, tenía una cierta pasión por devorar tarjetas microSD, por lo que hace algunos meses acabé migrando el sistema y desconectándola.
  • Otra opción interesante, dado que las necesidades de potencia de zigbee2mqtt son ciertamente reducidas (y ni de lejos requieren hacer uso de algo como una Raspberry Pi 4), es hacer uso de una placa más modesta. En mi caso, estoy teniendo estupendos resultados con una humilde Orange Pi Zero. Eso sí, siempre que cuides de ponerle un sistema de disipación y ventilación, ya el talón de Aquiles de esta placa es su disparatado problema de sobrecalentamiento del micro. Este sistema lo tengo en uso a día de hoy en Forcarey.
  • Y otra opción, perfectamente viable, es hacer uso de una máquina virtual. Este es el caso del entorno que tengo actualmente en Santiponce. Después de desechar la Tinker Board, moví el sistema a una pequeña máquina virtual en un servidor de virtualización basado en Proxmox que tengo en casa. El punto clave en este caso era verificar que el adaptador Zigbee funcionara presentándolo desde el servidor de virtualización a la máquina virtual (ya que, claro, no es posible conectar un hardware físico a una máquina virtual sin conectar el hardware al servidor de virtualización), cosa que hasta el momento ha ido como la seda. Y en cuanto a los recursos de la máquina virtual, no se necesita nada espectacular: con 512 MB de RAM y 1 vCPU hay de sobra para mover Home Assistant, zigbee2mqtt, el servidor MQTT y alguna que otra cosa más que tengo por ahí.
Home Assistant y zigbee2mqtt en Proxmox

Home Assistant y zigbee2mqtt en Proxmox

Una vez determinada qué opción para componer el concentrador, el resto es sencillo: ya hemos hablado del primer paso, que es cargar el firmware en el CC2531. El segundo es desplegar el software zigbee2mqtt en el concentrador. El proceso es bastante sencillo, ya que se trada de una aplicación Node.jsm y se instala tan sólo haciendo uso de un comando npm, una vez preparado el entorno para que pueda ejecutar este tipo de aplicaciones.

Procesos de zigbee2mqtt en Orange Pi Zero

Procesos de zigbee2mqtt en Orange Pi Zero

Por último, para tener el concentrador listo, hay que integrarlo con un servidor MQTT, que se hace mediante un fichero de configuración. Y a partir de ahí, tan sólo es cuestión de sacarle partido. Y es aquí donde entra de nuevo Home Assistant: zigbee2mqtt tiene una integración excelente con este sistema de domótica, siendo posible integrarlo con Home Assistant, y hacer que el proceso de descubrimiento en éste de los dispositivos registrados en zigbee2mqtt sea automático.

Pero he dejado lo mejor de todo para el final. Comentaba que el problema de utilizar concentradores de fabricante es que cada uno soporta solo y exclusivamente sus propios dispositivos. ¿Cuántos dispositivos soporta zigbee2mqtt? Literalmente cientos. A día de hoy, 1217 dispositivos de 189 fabricantes distintos. Y es una lista que no para de crecer. Hace algunas semanas han sido añadidos los Silvercrest de Lidl de los que escribí recientemente, solucionando el problema de que el botón físico de los interruptores no era reconocido dentro de las acciones: ahora sí lo reconoce.

¿Qué cuál es mi configuración? Bueno, a día de hoy es pelín compleja, pero tiene su gracia. Estrictamente hablando, hago uso de dos concentradores zigbee2mqtt, uno en Santiponce, y otro en Forcarey, que reportan a mi servidor MQTT, ubicado en Santiponce. Y manejo los dispositivos desde un único Home Assistant, también ubicado en Sevilla. Cada zigbee2mqtt escribe en el servidor MQTT bajo un topic diferenciado, ya que la cantidad de dispositivos es pelín larga ya. En Santiponce hago uso de:

  • Una luz Ikea TRÅDFRI, que fue la que lo empezó todo, ubicada en el salón. Es la luz que permite variar la calidez de la luz y la intensidad de la misma.
  • Su correspondiente mando, que no está integrado directamente con la luz, sino que se comunica con ella de manera independiente a través de zigbee2mqtt. Esto permite reconocer las acciones del mando en Home Assistant, y llegado el caso permitiría que el mando administrara dispositivos de terceros.
  • Una luz Müller Licht Tint de Aldi, de varios colores.
  • …y su mando a distancia. En este caso la integración no es tan limpia como en el del mando de Ikea, pero funciona bien.
  • Un cubo Aqara, que utilizo no sólo para controlar la luz Ikea del salón, sino para realizar acciones sobre la pérgola del patio. Y esto nos lleva a otra ventaja de utilizar zigbee2mqtt: que se puede interactuar sobre dispositivos que no son Zigbee. En mi caso, sobre un NodeMCU programado por mí mismo, a través de topic MQTT.
  • Tres sensores de apertura de puertas y ventanas Aqara MCCGQ11LM, que reportar la apertura de las mismas mediantes mensajes de Telegran y WhatsApp.
  • Un router CC2530 para mejorar la comunicación de los dispositivos Zigbee con el controlador. Y es que, aunque los dispositivos Zigbee pueden construir una red de tipo Mesh para llegar al concentrador, las comunicación con éste se veía perjudicada por la cantidad de señales en la banda de 2’4GHz y las distancias existentes en el caso de la casa de Santiponce. El uso de este concentrador mejoró de manera ostensible el comportamiento del sistema.
Diagrama de dispositivos de Santiponce

Diagrama de dispositivos de Santiponce

…y en el caso de Forcarey:

  • Los mismos sensores de apertura de puertas y ventanas Aqara MCCGQ11LM que comentaba antes.
  • Varios interruptores Lidl HG06337 para controlar los radiadores eléctricos del piso.
  • Otro Aqara Cube para controlar las luces del salón, que he domotizado mediante unos Sonoff Mini con software Tasmota.
  • Sensores de temperatura, humedad y presión atmosférica Aqara WSDCGQ11LM, que permitirán automatizar el encendido de los radiadores en función de las condiciones de las habitaciones.
Diagrama de dispositivos de Forcarey

Diagrama de dispositivos de Forcarey

No está mal, ¿no?

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

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

20 dic 20 Dispositivos zigbee del Lidl (Silvercrest) con Zigbee2MQTT

Hace algunas semanas el supermercado Lidl sacó una gama de dispositivos de control domótico bajo su marca Silvercrest. . El esquema de conexión es el habitual de estos dispositivos: constan de un gateway zigbee que permite interactuar con él desde el teléfono móvil, a través de una plataforma propietaria, y controlar los distintos dispositivos desplegados en el hogar.

Esquema de conexiones del sistema de domótica

Esquema de conexiones del sistema de domótica

Lo interesante de este sistema es que, aparte de los dispositivos normales como control de enchufes y luces, dispone de algunos añadidos no tan comunes un calefactor cerámico. Así que no podía dejar de probar si podrían funcionar en mi sistema de domótica basado en zigbee2mqtt. Y, en efecto, funcionan, aunque hay que pelearse un poco con ellos. En mi caso estoy haciendo uso de ellos en el sistema de domótica delegado que tengo montado en Forcarey. Estoy utilizando mi misma plataforma Home Assistant desplegada en Santiponce, pero tengo un receptor zigbee separado, montado con una Orange Pi Zero que tenía sin usar, ubicada en Forcarey. Este receptor separado vuelca los datos en mi servidor MQTT bajo un topic distinto, y a correr.

Dispositivos Silvercrest reconocidos como TuYa

Dispositivos Silvercrest reconocidos como TuYa

Bueno, en realidad no ha sido tan sencillo. El primer problema es que estos dispositivos, en la fecha en que escribo esto, aún no están incorporados como dispositivos propios en la lista de dispositivos reconocidos por zigbee2mqtt. No es demasiado problemático, porque al parecer Lidl está vendiendo bajo su marca dispositivos TuYa, que sí son reconocidos. Eso sí, para que los reconozca es imprescindible tener zigbee2mqtt actualizado a su última versión. Otro punto ha sido que los dispositivos dan algo de guerra al negociar la conexión a la red, incluso ya reconocidos. En mi caso, para que terminaran la fase de interview correctamente, tuve que añadir un cable extensor USB para separar el receptor de la Orange Pi Zero. Y el tercer punto complicado es que estos dispositivos son Zigbee 3.0, y para que el sistema sea estable, es necesario utilizar el firmware del receptor zigbee con capacidades de enrutado, en vez del normal.

Con todo esto en pie, los dispositivos funcionan correctamente, tanto la luz de colores regulable como los interruptores de pared, que son con los que he experimentado. El único punto ligeramente molesto en que con estos últimos el pulsador manual no genera eventos, por lo que el uso del mismo no se registra en el sistema de domótica. Pero es algo con lo que puedo vivir. :mrgreen:

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

Etiquetas: , , , , , ,

07 nov 20 Control de apertura de puertas y ventanas con Zigbee y sensores Aqara MCCGQ11LM

Seguimos con proyectos de IoT y domótica. En este caso, y para el piso de Forcarey, estoy preparando un sistema de control de apertura de puertas y ventanas con dispositivos Zigbee. Para ello, he escogido los sensores Aqara MCCGQ11LM. Son unos dispositivos fiables, razonablemente baratos, y -lo más importante- están perfectamente soportados en Zigbee2MQTT.

Sensor de puertas y ventanas Aqara MCCGQ11LM

Sensor de puertas y ventanas Aqara MCCGQ11LM

Y es que la gracia de todo este asunto es que no voy a hacer uso del gateway propietario de Aqara/Xiaomi. Desde hace ya algún tiempo tengo experiencia haciendo uso de Zigbee2MQTT como gateway de código abierto para algunos dispositivos Zigbee que tengo instalados en Santiponce, y la idea -como no podía ser menos- era hacer uso de la misma tecnología en Forcarey. Para ello estoy diseñando un pequeño dispositivo, basado en una placa Orange Pi Zero, que actúe como gateway de los dispositivos que voy a desplegar en el nuevo piso.

Orange Pi Zero con módem USB. El otro dispositivo es un receptor Zigbee

Orange Pi Zero con módem USB. El otro dispositivo es un receptor Zigbee

Sí, el dispositivo con conectividad HSDPA que comentábamos en el artículo anterior.

En lo referente a la instalación de Zigbee2MQTT, en líneas generales basta con seguir las instrucciones de instalación que proporciona la web oficial, con una salvedad: en la versión de Armbian que manejo (Buster 20.08.1 con versión de kernel 5.8.5) a la hora de compilar Zigbee2MQTT daba algunos errores con serialport y node-gyp, que están reportados. En mi caso ninguna de las soluciones propuestas funcionaba. Lo único con lo que conseguí hacerlo funcionar fue ignorando la parte de usar el repositorio de Node.js que se indica en las instrucciones en el apartado 2 de las mismas, e instalar tanto Node.js como específicamente node-gyp desde los repositorios oficiales de Debian. De esta manera todo el proceso de instalación concluyó correctamente.

Una vez concluida la instalación, creé el servicio para iniciar automáticamente Zigbee2MQTT al inicio del sistema, asocié los dispositivos, que fueron reconocidos sin mayor inconveniente, con lo que el proceso de configuración del hardware ha quedado concluido. En cuanto al software, el sistema de notificación de actividad de los sensores, en base a recepción de eventos de los dispositivos y su volcado a un servidor MQTT, está concluido. Los eventos se muestran de la siguiente manera:

Eventos registrados en servidor MQTT

Eventos registrados en servidor MQTT

…lo que nos permite, a partir de aquí, crear el sistema de notificaciones. ¿Cómo lo voy a hacer en mi caso? Con el estupendo software Home Assistant, que constituye la base de mi sistema de domótica. Pero eso ya quedará para otro artículo.

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

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

19 sep 20 El gateway LoRa*. Hardware y software

Esta entrada es la parte 3 de 7 de la serie Gateway LoRaWAN

Seguimos haciendo progresos con mi gateway LoRaWAN. En este caso, en el ámbito del gateway en sí. El lector avispado habrá notado que he encabezado este artículo con Lora* en vez de con LoRaWAN. Y es que en este punto lo que tengo implementado es más bien un gateway LoRa que actúa de pasarela a un servidor MQTT, y no un gateway LoRaWAN propiamente dicho. ¿Cuál es la diferencia? Es sutil, pero importante. A estas alturas lo que he implementado es un gateway, sí, entre dispositivos, y terceros servidores, pero no realizo aún control de acceso, identificadores de equipos en la red, ni nada por el estilo. Así que no puedo -en realidad- considerarlo un gateway LoRaWAN completo. Pero de momento, para el propósito que manejo, basta y sobra.

20200805_094600

Ya he hablado con anterioridad del dispositivo que estoy utilizando para construir el gateway: se trata de una placa Heltec Lora 32, que proporciona capacidad de conexión LoRa, WiFi y Bluetooth, incluyendo la variante Low Energy. Con anterioridad he estado haciendo pruebas con la variante de 433 MHz, pero para este proyecto en cuestión he optado por respetar la normativa radioeléctrica europea, y desplegarlo con la variante de 868 MHz, de la que disponía de un dispositivo que hasta ahora no había hecho un gran uso (en parte porque vino con la pantalla OLED quebrada, y ésta funciona bastante mal). Otro elemento de la configuración es la antena de recepción y el adaptador eléctrico, pero estos elementos quedarán para otro artículo.

En lo referente al software, he desarrollado un software con las siguientes características:

  • La base del sistema son las librerías de Heltec que permiten implementar comunicaciones LoRa. Los aspectos principales de la configuración ha sido establecer los parámetros de conexión adecuados para comunicarse adecuadamente con los dispositivos cliente, en este caso unos Heltec CubeCell. En concreto, los siguientes aspectos son los que hay que configurar:
    LoRa.setSpreadingFactor(8);
    LoRa.setSignalBandwidth(125E3);
    LoRa.setCodingRate4(4);
    LoRa.setPreambleLength(8);
    LoRa.setSyncWord(0×12);
  • El siguiente punto de importancia es la implementación de un sistema de configuración de la conexión del cliente WiFi mediante un AP provisional: IotWebConf. Con esta librería, válida para dispositivos ESP8266 y ESP32, se puede levantar un portal web y un AP para realizar la configuración de la WiFi en el dispositivo. La idea es sencilla: cuando el dispositivo no tiene configurada una conexión WiFi, levanta un punto de acceso con un portal web de configuración, al que se puede conectar para establecer los parámetros de la WiFi (así como otro tipo de parámetros configurables, como el servidor MQTT, por ejemplo). Una vez establecidos, el sistema almacena estos parámetros en la EEPROM de la placa, reinicia, y conecta a la WiFi proporcionada. También permite introducir una nueva configuración WiFi en caso de que se mueva el dispositivo a una ubicación en la que la WiFi configurada no tenga alcance. La principal ventaja es que no hay que preconfigurar en código los parámetros de conexión, pudiendo hacerlo en tiempo de ejecución. A continuación se puede ver una captura de la interfaz web que se levanta:
  • portal-wifi
  • Otro aspecto adicional de esta librería es que permite realizar la actualización de firmware On-The-Air: la interfaz web proporciona una vía para cargar el software precompilado de Arduino en la placa, sin tener que conectar la misma a un PC mediante cable, además de incluir un sistema de seguimiento de versiones de firmware. Sumamente útil, teniendo en cuenta que el gateway va a estar ubicado, en mi caso, en lo alto del tejado.
  • Por último, he realizado algunos ajustes adicionales en optimización de la transmisión de datos entre dispositivo y gateway. La principal (en el caso de transmisión de valores numéricos) es la utilización de codificación hexadecimal, para transmitir menos bytes y optimizar el tiempo de vuelo de los datos.

En cuanto a la recepción de datos, ha sido sumamente exitosa. En el código de ejemplo utilizado en el cliente, se envía una trama compuesta de dos valores en hexadecimal, que son inyectados en un topic MQTT, junto con el valor del RSSI de la transmisión, a fin de controlar la calidad de la misma. El servidor MQTT se encuentra completamente ajeno al sistema, siendo un servidor multifunción que utilizo para diversos proyectos.

trafico-mqtt

El resultado es, hasta ahora, bastante bueno. En próximos capítulos hablaré de otros elementos del sistema.

VN:F [1.9.20_1166]
Rating: 0.0/10 (0 votes cast)

Etiquetas: , , , , , , , , ,