Buenas tardes, queridos Khabrovites! Hace unos años, compré un anuncio colorido de zWave e instalé sensores de ventana basados en este protocolo. Se conectó un zWave-Stick USB al servidor doméstico, que desempeñaba el papel de un controlador, se escribió un pequeño módulo Java que recibió datos de este controlador y se escribió una pequeña aplicación para Android que mostraba maravillosamente el estado de todos los sensores. Las baterías están insertadas, los sensores están registrados en el controlador, todo funcionó. Pero después de un par de meses hubo una terrible decepción. En primer lugar, estos sensores zWave funcionan según el principio de "enviar un mensaje y quedarse dormido sin esperar la confirmación". En mi caso, esto condujo al hecho de que la señal de los sensores más lejanos del controlador simplemente no llegó al controlador. Incluso la instalación de un repetidor zWave adicional no ayudó. En segundo lugar, agotaron la batería tan rápido que después de unos seis meses, todos los sensores dejaron de funcionar. La razón es que se despertaban cada hora para informar al controlador de su condición. Desactivar o cambiar esta opción no funcionó, ya que el software estándar categóricamente no lo permitió. Después de dos años de tormento con esta tecnología cruda, poco confiable y poco amigable, decidí que tenía suficiente. Pero en lugar de guardar todo y tirarlo a la basura, tuve la idea de dejar los estuches, pero cambiar la electrónica en ellos. La elección recayó en un transceptor RFM69 bastante simple (433 MHz), sobre la base de lo cual fue posible hacer una placa para el sensor y un controlador conectado a través de USB al servidor. El nuevo sistema ya ha estado en funcionamiento durante 5 meses, la fiabilidad es cercana al 100% (pero todavía hubo algunas fallas), las baterías aún no parecen estar agotadas. Es decir, ya es visible que se han eliminado todas las deficiencias del sistema antiguo basado en zWave, y quiero compartir los detalles técnicos de este artículo, vea la imagen.
A quién le importa, por favor, debajo del gato.
Me parece que zWave en mi caso resultó inoperante por dos razones: la casa tiene dos pisos con pisos de concreto reforzado y un área grande (es decir, una eliminación significativa de algunos sensores del controlador). Bueno, fallas en el software propietario, que no permitieron desactivar el despertar periódico de los sensores, lo que condujo a una descarga rápida de la batería. Cuando se hizo evidente que no estaba en camino con zWave, comencé a buscar otras opciones que pudieran introducirse en las mismas carcasas de sensores.
Mi primer prototipo de sensores se basó en el ESP8266. El controlador: sobre la base de mi pago sobre el que ya
escribí en Habré . El sistema incluso funcionó como un prototipo, pero tuve que abandonarlo por dos razones. La primera razón es la misma: en la casa había rincones con un nivel muy bajo de señal WiFi, lo que condujo a un tiempo de activación muy largo del ESP8266 al despertar y, como resultado, a una fuerte descarga de la batería. Aunque admito que simplemente no sé cómo cocinar esto ESP8266 (artículos
como este confirman esta tesis). Pero la segunda razón fue más seria. Como decidí dejar no solo la carcasa, sino también el compartimento de la batería, me limité a una batería CR123A, que es de 3.0 voltios. Es decir, el precio y la complejidad del sensor aumentaron debido al aumento del convertidor CC / CC. Aunque
hay un artículo maravilloso sobre este tema en Habré. Pero, de todos modos, estas dos razones han superado y rechacé ESP8266.
El segundo prototipo fue conectado. Hice un prototipo tanto del sensor como del controlador USB, agregué un módulo de servidor para que entendiera este controlador además del zWave-Stick. Hubo una idea de tirar gradualmente los cables y el sensor tras sensor para cambiar la placa zWave a una cableada. Pero al final, no eligió paredes y este prototipo también se descartó.
Luego decidió mirar hacia los módulos de radio a 433 y 868 MHz y ordenó varios módulos para experimentos:
RFM69HCW ,
A110LR09A y
MRF89XAM8A . En términos de tamaño del módulo, precio y también debido a la disponibilidad de ambas bibliotecas y
buenos ejemplos, me decidí por RFM69HCW, que formó la base del sistema.
El sistema tiene solo cuatro componentes:
- sensores inalámbricos (433 MHz, batería CR123A 3.0V),
- controlador de red (433 MHz, alimentado por USB desde el servidor)
- el servidor (sobre el cual ya escribí sobre Habré en este artículo ) y el módulo del programa del servidor
- cliente móvil (aplicación de Android)
A continuación describiré cada módulo en detalle, y al final daré estadísticas sobre el funcionamiento del sistema durante los últimos meses de funcionamiento.
Sensores
Los sensores utilizan el
módulo de radio
RFM69HCW . Tiene un amplio rango de voltaje de funcionamiento (1.8V-2.4V 17dBm, 2.4V-3.6V 20dBm) y se controla a través de SPI. Es decir, necesitas un microcontrolador. Hace algún tiempo, me familiaricé con la serie STM32L y pedí el STM32L051 para experimentos. Me sobornó como una pequeña corriente en modo de suspensión (0.27 μA), y el voltaje de funcionamiento, casi idéntico al voltaje del módulo de radio (1.65V-3.6V). Más bajo precio.
Resultó el siguiente esquema:
La tensión de alimentación tanto del microcontrolador como del módulo de radio es tal que pueden alimentarse directamente desde el elemento CR123A. STM32L051 tiene una referencia de voltaje interno conectada al canal 17 del ADC, así como el valor de calibración de esta fuente, que le permite medir el valor actual del voltaje de suministro VDD. El módulo de radio está conectado a la alimentación a través del dispositivo de campo Q1, que le permite controlar su alimentación desde el microcontrolador.
El modo de suspensión se implementa transfiriendo el microcontrolador a "En espera". En este modo, el STM32L051 tiene un núcleo deshabilitado, casi todos los periféricos y un regulador de voltaje interno, que asegura el consumo al nivel de 0.29 μA (con el reloj en tiempo real deshabilitado). Pero en este modo hay una característica: el microcontrolador se activa solo a lo largo del borde ascendente de la señal en el pin WKUP (A0). Como se usa un interruptor magnético, que está activado / desactivado (cerrado o abierto), necesita un pequeño bloque que genere un pulso de corta duración tanto al cerrar como al abrir un contacto magnético. Este pulso se alimenta a la entrada A0 del microcontrolador y lo despierta. Tal convertidor se implementa en el chip exclusivo IC3 de la serie 74AUP de eficiencia energética (74AUP1G86), que opera en el rango de voltaje de 0.8V-3.6V y consume 0.2 μA. Por lo tanto, el consumo total en el modo de reposo debe ser de alrededor de 0,5 μA, lo que se confirma mediante mediciones en un sensor completamente ensamblado.
Cuando el microcontrolador se despierta, primero mide el voltaje de suministro y, si es inferior a 1,8 voltios, entonces no es el destino: el transmisor no se puede encender y el microcontrolador se queda dormido.
Si el voltaje de la batería es superior a 1,8 voltios, el microcontrolador se enciende e inicializa el módulo de radio, transfiere el estado al controlador de red y espera la confirmación. El paquete de datos incluye un número único de paquete de 32 bits (evento), voltaje de la batería, temperatura, estado de contacto magnético, byte de control (CRC7). En caso de confirmación exitosa, el microcontrolador se duerme nuevamente. Si no, envía el estado nuevamente, pero un máximo de 10 veces. Establecí este límite para que el sensor no intente esperar indefinidamente una respuesta en una situación en la que el controlador de red simplemente está apagado. El último número de evento único transmitido se almacena en la EEPROM interna del microcontrolador.
Durante la transferencia de datos, el microcontrolador parpadea un LED (sin él). El LED se enciende mediante PWM, donde el ciclo de trabajo depende del valor de voltaje actual, lo que le permite tener casi el mismo brillo en casi todo el rango de voltaje de funcionamiento.
Los tableros están diseñados en EagleCAD, el diseño del tablero
está disponible aquí . Los tableros son de doble cara: el microcontrolador y su arnés se encuentran en la parte superior hacia el marco de la ventana, y el módulo de radio y el LED están en la parte inferior hacia la habitación. Pedí en China, me solde en un horno de cocina convencional (capa superior) y un secador de pelo (capa inferior).
El módulo de radio necesita una antena. Esto es solo un trozo de alambre de 164 mm de largo.
Después de la instalación, cada sensor debe ser programado, para lo cual se proporciona un conector SWD. Dejé los contactos restantes en el tablero para posibles experimentos en el futuro.
El firmware está escrito en C ++, parte del código se lleva a cabo en clases básicas bastante universales que encapsulan las llamadas a la biblioteca ST HAL. El código fuente
está aquí . Para el desarrollo, se utilizó System Workbench para STM32. El tamaño del archivo de firmware binario final es de 22 kB.
Y aquí está el sensor en el caso:
Dependiendo de la posición del sensor, para algunos sensores dejé la antena afuera (contra el fondo del marco blanco, sin embargo, no es visible), y para algunos sensores doblé el cable dentro del marco y lo metí completamente dentro de la carcasa.
En aras del interés, calculé el costo de los componentes para un sensor (a los precios del catálogo de Mouser, el precio y el precio total en euros)
| Artículo | Descripción | Valor | Número de MOUSER | Cantidad | Costo |
| IC3 | O exclusivo | 1G86 | 771-74AUP1G86GW-G | 1 | 0.254 |
| IC1 | Microcontrolador | STM32L051 | 511-STM32L051K6T6 | 1 | 2,14 |
| SV1 | Conector | Swd | 68602-406HLF | 1 | 0,157 |
| LED1 | LED 3 mm | 3mm | 630-HLMP-K155 | 1 | 0.351 |
| Q1 | P-mosfet | BSH205 | 771-BSH205G2R | 1 | 0.276 |
| S1 | Contacto magnético | ORD211-0810 | 876-ORD211-0810 | 1 | 0.625 |
| IC2 | Módulo de radio RFM69HCW | RFM69HCW | 474-COM-13910 | 1 | 5.36 |
| C1, C2, C3, C6 | Condensador SMD | 0.1uF | 80-C0805C104J5RAC | 4 4 | 0.1 |
| C5 | Condensador SMD | 0.4nF | C0805C471K8HACTU | 1 | 0,021 |
| C4 | Condensador SMD (tantalio) | 47uF | 581-TAJR225K016RNJ | 1 | 0,333 |
| R1 | Resistencia SMD | 10K | 660-RK73H2ATTDD1002F | 1 | 0,01 |
| R10 | Resistencia SMD | 330 | 660-RK73H2ATTDD3300F | 1 | 0,01 |
| R3, R4, R6, R7, R8, R11 | Resistencia SMD | 47K | 660-RK73H2ATTDD4702F | 6 6 | 0,06 |
| R5 | Resistencia SMD | 56 | 660-RK73H2ATTD56R0F | 1 | 0,013 |
| R9 | Resistencia SMD | 56 millones | 603-RC0805JR-0756ML | 1 | 0,037 |
| | | | | 9,748 |
Por cierto, resultó exactamente tres veces más barato que el sensor zWave original. Aunque esto es solo el costo de las piezas, excluyendo el caso. Pero, en mi opinión, en el comercio minorista, los sensores zWave son excesivamente caros.
Controlador de red
Para el controlador, se utilizaron el mismo módulo de radio y el mismo microcontrolador que para los sensores. Esto permitió reutilizar la mayor parte del código de firmware. Para el controlador, elegí este factor de forma de la placa para usar el estuche ya preparado de Raspberry Pi. En comparación con el sensor, se agregaron un conector de antena externa y un circuito USB basado en el aislador FT232RL y SI-8621. Por supuesto, en cambio, uno podría tomar un STM32 con USB a bordo. Pero luego, en primer lugar, sería necesario separar el código del firmware y, en segundo lugar, realizar la implementación del software del propio USB. La opción con un FT232RL externo, aunque es más costosa, es más confiable y más rápida de implementar. El resultado es el
siguiente esquema :
Y en forma ensamblada resultó así:
El microcontrolador no se pone en suspensión aquí, el módulo de radio funciona para la recepción, pero después de recibir con éxito un paquete de cualquiera de los sensores, el módulo pasa al modo de transmisión y envía un acuse de recibo. Además, cualquier paquete recibido con éxito se transmite a través de USB al servidor. El formato del paquete es una cadena de valores separados por el símbolo ";":
GW; 3; 12; -57; 0; 146; 30; 18
donde:
- La primera posición es la etiqueta del paquete (siempre "GW")
- segunda posición - tipo de datos (estado del sensor o código de error)
- tercera posición - número de sensor
- cuarta posición: calidad de la señal en el lateral del controlador de red (RFM69HCW conserva la calidad de la señal durante la recepción y le permite interrogarla cuando finaliza la recepción)
- quinta posición - estado de la ventana (0 abierto, 1 cerrado)
- sexta posición: un número único del paquete (evento) del sensor. Este número le permite controlar en el lado del servidor si todos los eventos fueron recibidos por el servidor o si uno o más eventos se perdieron.
- séptima posición - voltaje actual de la batería (30 corresponde a 3.0V)
- la última, octava posición es la temperatura del sensor interno del microcontrolador. Todavía no he descubierto cómo usarlo
El código fuente para el firmware está
en el mismo lugar que para el sensor . Tienen un archivo principal común y una biblioteca común de clases base. La opción de firmware (sensor o controlador) se selecciona utilizando la directiva define en el archivo main.cpp.
El costo del controlador de red es mayor debido al circuito USB, la antena y los conectores adicionales. Pero este aditivo se puede descuidar, ya que solo hay un controlador. Pero incluso con este suplemento, también resultó ser tres veces más barato que el zWave-Stick, que antes estaba en su lugar.
Módulo de servidor
El controlador de red está conectado a un servidor que ejecuta CentOS 7. El servidor ejecuta un programa escrito en Java. Y en su estructura, implementación y tareas, el programa es bastante simple:
- Utilizando una biblioteca RxTx muy antigua y que aparentemente ya no es compatible, se supervisa el puerto USB especificado en la configuración (en mi caso / dev / ttyUSB0). Por el momento, esta es la parte menos optimizada de todo el sistema, ya que la biblioteca carga mucho el procesador del servidor.
- Si se reciben datos del puerto USB, se registran en un archivo de registro y se almacenan en la clase de estado del sensor. Cuando reinicia el servidor, se pierde el estado. Para restaurarlo, debe recorrer la casa y abrir y cerrar manualmente todas las ventanas. Este es probablemente el mayor inconveniente de mi sistema, pero conscientemente me negué a sondear periódicamente los sensores para ahorrar baterías.
- La aplicación también es un pequeño servidor TCP / IP y escucha en el puerto TCP / IP especificado en la configuración. En este puerto, puede aceptar conexiones desde un cliente móvil.
- Si el cliente móvil se conecta al servidor, envía el estado actual de todos los sensores. Usando mensajes periódicos de heartbit, el servidor también monitorea la actividad de la conexión.
- El servidor y el cliente móvil intercambian mensajes en formato XML. Estos mensajes se implementan en forma de una pequeña biblioteca Java , que se comparte tanto en el lado del servidor como en el lado de la aplicación móvil de Android.
- Aunque esto no tiene mucho sentido, por razones de interés, agregué la función de autorizar un cliente móvil a través de IMEI, así como el cifrado AES de mensajes entre el servidor y el cliente utilizando una clave cosida en el código fuente (paquete javax.crypto Java). Pero esto es solo para el experimento, ya que el puerto TCP / IP de este módulo de servidor solo es accesible desde la red interna y no es visible desde el exterior. Aunque, si quiero abrir este puerto al gran mundo, ahora no será tan aterrador hacerlo.
A quién le importa, el código fuente del módulo del servidor está
aquí .
Cliente móvil (aplicación de Android)
No escribirá mucho aquí, a pesar de que esta aplicación es el resultado final de todo el proyecto. Esta es una aplicación Java estándar y muy simple con tres pestañas: el estado de las ventanas del primer piso, el estado del segundo piso y una pequeña telemetría del servidor (vea el
código fuente aquí ):
Los gráficos se basan en un conjunto de archivos SVG, que se apilan uno encima del otro según el estado de los sensores. Se admite una pulsación larga en el área de cada ventana, de acuerdo con la cual se muestra una pista con la hora a la que se abrió esta ventana:
En principio, nada le impide agregar un icono de batería a esta información sobre herramientas, pero sus manos aún no lo han alcanzado.
Experiencia operativa
"Cada estornudo" se registra en un archivo de registro en el lado del servidor. El análisis de estos archivos en los últimos 5 meses nos permite comprender con un poco más de detalle cómo se siente este sistema.
El análisis es muy simple: simplemente grep en la carpeta de archivos de registro en el servidor.
¿Cuántos errores hubo en la transmisión de datos en el canal de radio? Durante 5 meses, se registraron 8 errores cuando el mensaje se recibió en el tamaño incorrecto y 25 errores en el CRC incorrecto. En ambos casos, no puede decir directamente qué sensor tuvo problemas, ya que el paquete de datos en este caso está completamente dañado. Dado que el controlador de red no confirma la recepción de datos en todos estos casos, el sensor debe enviar los datos de una manera nueva, que en la mayoría de los casos corrige estos errores.
Y aquí hay una tabla resumen sobre el funcionamiento de los sensores durante 5 meses.
| Piso | Sensor | Cantidad
De eventos | De los perdidos
De eventos | Voltaje
Las pilas | Mediana
Poder
Señal |
| 1 | 10 | 105 | 0 0 | 3.1 | -66 |
| 1 | 11 | 52 | 0 0 | 3,3 | -70 |
| 1 | 12 | 122 | 0 0 | 3,3 | -61 |
| 1 | 13 | 89 | 0 0 | 3,3 | -74 |
| 1 | 14 | 2573 | 0 0 | 3,3 | -68 |
| 1 | 15 | 261 | 0 0 | 3,3 | -60 |
| 1 | 16 | 543 | 2 | 3,3 | -70 |
| 1 | 17 | 156 | 2 | 3,3 | -74 |
| 1 | 18 años | 177 | 2 | 3.2 | -68 |
| 1 | 19 | 384 | 3 | 3,3 | -56 |
| 2 | 3 | 368 | 2 | 3,3 | -62 |
| 2 | 4 4 | 86 | 0 0 | 3,3 | -71 |
| 2 | 5 5 | 521 | 2 | 3,3 | -59 |
| 2 | 6 6 | 115 | 0 0 | 3,3 | -62 |
| 2 | 7 7 | 316 | 2 | 3,3 | -63 |
| 2 | 8 | 419 | 1 | 3,3 | -60 |
| 2 | 9 9 | 89 | 0 0 | 3,3 | -68 |
El sensor n. ° 10 se congela una vez. Esto aparentemente condujo a una disminución significativa en el voltaje de la batería. La razón de la congelación aún no está clara. Se cuelga de nuevo, tienes que resolverlo.
El sensor n. ° 14 está instalado en la puerta frontal, por lo que tiene una gran cantidad de respuestas. Pero una cantidad tan grande de viajes aún no ha afectado el voltaje de la batería.
Un evento perdido es cuando el sensor intentó enviar un estado, pero el servidor no lo confirmó. Todos los eventos perdidos se deben al hecho de que apagué el servidor durante aproximadamente medio día para la limpieza.
La columna Median Strength Signal Strength muestra el valor medio de RSSI (en dBm), donde se obtiene cada valor individual después de recibir cada paquete. El sensor con la mejor señal (No. 19, -56 dBm) se encuentra a una distancia de 2 metros en visibilidad directa desde el controlador de red, pero la antena en este sensor está plegada con un marco dentro de la carcasa. El controlador de red en sí está ubicado en la planta baja. Sin embargo, la señal de los sensores del segundo piso es muy buena. Esto se debe al hecho de que en todos los sensores del segundo piso, la antena se retira de la carcasa del sensor.
En lugar de un epílogo
Por un lado, me alegro de que por mi cuenta, como hobby, haya resultado desde cero diseñar, ensamblar y ejecutar un sistema de este nivel. Y aún más contento de que funcione mejor que el sistema "patentado" basado en la tecnología zWave hype. También hay espacio para desarrollar y mejorar este sistema. Solo me corroen las pequeñas dudas. Es decir, que una persona sin una educación eléctrica especializada recolecta en su rodilla algo que funciona de manera más confiable que los productos de marca conocidos en los círculos estrechos de las marcas IOT. Probablemente, el progreso giró en alguna dirección equivocada.