Entrada
En el proceso de elegir soluciones para un hogar inteligente, trato de evitar soluciones en caja que requieren comunicación con nubes externas o tienen sus propias aplicaciones, especialmente soluciones sin la capacidad de conectarse directamente al dispositivo. Todas las métricas disponibles se reducen a una interfaz: zabbix, donde se organiza un sistema de alerta para las partes interesadas. Las perillas de control se implementan en una interfaz web localmente localizada.
Artículos anteriores:
primera parte (1 temperatura del cable, ups, medidor de agua ...)
segunda parte (redes, gidrolock, sensores de presión ...)
Tareas resueltas en este artículo
- Protección de fugas de agua flexible y escalable con alerta zabbix
- Otros dispositivos a 433 mhz: campana, puerta abierta, etc.
- Empujamos 1 cable en MQTT
Sistema de protección contra fugas
Requerimientos del sistema:
- muchos sensores dispersos por la casa (en mi caso, 6 piezas en diferentes lugares)
- sin cables en los sensores
- apagado rápido al detectar fugas
- toda la información del estado actual en zabbix. Hay una alerta
Composición del sistema
- Raspberry PI
- Sintonizador USB RTL2832U
- Sensores de fugas 433mhz
- Red + grúa gidrolock (ver artículo anterior) para apagar el maletero
Sobre el hierro
En un artículo anterior, describí la solución de cerrar el suministro de agua usando una red. Tengo un sensor con cable para esta solución. Esto es conveniente si todos los puntos donde pueden ocurrir fugas están aproximadamente en el mismo lugar. En mi caso, la red se instala directamente en la entrada de la carretera y controla la grúa electromecánica gidrolock en el mismo lugar (ver el artículo anterior). La red de dispersión + gidrolock + sensor con cable en todos los puntos es costosa y engorrosa. Además, ya no tengo la oportunidad de arrastrar nuevos cables por la casa. Ocupar enchufes y respirar grúas eléctricas es una solución regular. La solución esperada: utilizamos la superposición de la autopista común en función de las señales de los sensores de radio distribuidos por las ubicaciones.
De lo que se encontró en Internet: un montón de diferentes sensores de radio de sistemas prefabricados. Algunos se pueden comprar por separado, no compré controladores para sensores, para no producir elementos adicionales en el circuito.
¿Cómo puedo atrapar 433mhz? Resulta que un sintonizador de TV en un chipset específico. Y ahora vale un centavo (asumí Avito por 300r) así:
Pedí una antena separada para ella en 12dbi, porque la actual no cubría toda la casa.
Como intenté minimizar los componentes de control del circuito, había un deseo de apretar el sintonizador en el enrutador de mi casa con Openwrt, que hasta ahora era el núcleo de la solución de casa inteligente para 1 cable, modbus, sensores / protocolos wifi, pero, desafortunadamente, agoté algunos de sus recursos ( el espacio en la unidad flash incorporada para el software necesario termina, el procesador se carga con algo: ya habrá problemas con la red y todavía tenemos 4k para buscar en línea :), + ya hay demasiadas cosas colgadas en USB, lo que afecta la estabilidad de la recopilación de datos). Se decidió transferir gradualmente la funcionalidad de la casa inteligente a un dispositivo externo: rarpberry pi (una de las primeras versiones disponible).
Sobre el software
Después de jugar con un sintonizador de TV sdr-sharp en una computadora de escritorio con ventanas (después de haber intentado captar las negociaciones de radios y aviones de otras personas), comencé a ver si los sensores mismos vieron el "silbato". Sí, se ve perfectamente:
Ajuste de frambuesa
Elegí raspbian nativo. Escribí la última imagen en la unidad flash USB en mac / linux:
sudo dd if=2019-07-10-raspbian-buster-lite.img of=/dev/disk2 bs=1048576 conv=sync
Arranque, configure la red y ssh.
A continuación, coloque los paquetes de frambuesa rtl-sdr, rtl_433:
sudo apt-get install cmake build-essential python-pip libusb-1.0-0-dev libusb-1.0 python-numpy git git clone https://github.com/merbanan/rtl_433.git cd rtl_433/ mkdir build cd build cmake .. make make install
rtl_433 tiene protocolos incorporados que descifran datos de diferentes dispositivos que operan en el rango de 433mhz.
Comenzamos rtl_433
rtl_433 -f 433.9e6
Bajamos los sensores al agua y obtenemos lo que más apreciamos:
time : 2019-09-17 15:04:39 model : Smoke detector GS 558 id : 16919 unit : 1 learn : 0 Raw Code : c842e1
Detector de humo? Ok, pongamos la canción "Smoke on the water" en la alerta de estos sensores ... :)
Pero en serio: tenemos la identificación de cada sensor, de acuerdo con la cual en el futuro entenderemos exactamente dónde tenemos una fuga (y nos desconectaremos en cualquier caso).
Acerca de los sensores de fugas
Después de configurar la parte del software, noté que los sensores con aliexpress (foto izquierda) envían una sola señal cuando el agua entra en los contactos. Además de una sola señal si el agua deja de cerrar los contactos. Esto no me conviene de ninguna manera (comportamiento esperado: envía constantemente una señal de alarma cuando el sensor detecta agua, ya que puede perderse una sola señal). Se observa un comportamiento similar si cierra los contactos con un cable. Pero lo que es extraño: la alarma se produce cada 2-3 segundos, si cierra los contactos con las manos (piel). Aquí todavía tengo dos suposiciones: o los chinos se equivocaron con las mediciones de resistencia, o los sensores tienen algún otro modo de operación en el que se comportan de manera diferente (por ejemplo, emparejado con un controlador), o hay otras frecuencias (hasta que encontré )
Por cierto, escriba en los comentarios, tal vez alguien trabajó con estos sensores, ¿se les puede "enseñar" de alguna manera a enviar una señal sobre una fuga constantemente?Puse estos sensores a un lado, en el arsenal había otro de rubetek (foto de la derecha) y compré en Leroy: GAL SHW-1005 (foto del medio).
El comportamiento del sensor rubetek parecía completamente impredecible (la reacción impredecible "ve agua / no ve").
Pero el sensor de Leroy en movimiento mostró exactamente lo que necesitaba: hay agua, lo envío al aire, no hay agua, estoy en silencio. Su único inconveniente es un radio de acción más pequeño que otros sensores. Pero el problema se resolvió comprando una antena más sensible para el receptor.
MQTT
¿Cómo enviar la salida rtl_433 a zabbix? ¿Alimentar al agente? ¿Enviar a zabbix_sender, analizando el proceso? Tal vez a través de syslog?
Aquí debes recordar que mi zabbix está en algún lugar de las nubes. Y ciertamente no es necesario bloquear el agua con la ayuda de sus desencadenantes. El piso de la casa se inundará hasta que tome una decisión (si está disponible).
La buena noticia es que rtl_433 puede enviar información sobre MQTT. Fuera de la caja Al mismo tiempo, los datos se envían al corredor en formato json.
Entonces necesitas:
- Coloque un agente local de mosquitto (hágalo en la frambuesa).
- Combine la información en el intermediario con el tema deseado, para que luego pueda analizarse.
- Conéctese al agente localmente en la frambuesa y envíe comandos a la red
- Conéctese al agente desde el lugar donde tendrá lugar la redirección a zabbix (el servidor de zabbix en mi caso también es un cliente MQTT)
Instalación-configuración mosquitto MQTT:
apt-get install mosquitto mosquitto-clients systemctl enable mosquitto systemctl start mosquitto
Enviamos información al corredor indicando la identificación del dispositivo:
rtl_433 -f 433.88e6 -F mqtt://127.0.0.1,events=/433/[id]
En el cliente mqtt obtendremos algo como lo siguiente:
mosquitto_sub -h 127.0.0.1 -t '#' ( ) /433/16919 {"time":"2019-09-18 11:55:29","model":"Smoke detector GS 558","id":16919,"unit":1,"learn":0,"code":"c842e1"}
Script para conectarse al intermediario y enviar el comando a netping
Esbocé un simple cliente de script MQTT que le permite ejecutar el script asociado con el tema cuando aparece el tema especificado en la configuración. Por lo tanto, cuando se activa un determinado sensor y aparece información sobre él en el aire (por ejemplo, / 433/16919), puede realizar alguna acción (en el caso de una red, envíe una solicitud de rizo para cerrar la grúa, consulte el artículo anterior). Un enlace al guión se encuentra al final del artículo.
Redirección en zabbix
Usé la solución mqtt-zabbix preparada. En su nivel, entendemos en qué elemento enviar el valor (por id).
En keys.cfg, especifique:
/433/16919,mqtt.ventilation.waterleak::hostname
donde hostname es el nombre de host con el tipo de vagabundo del elemento en Zabbix.
Importante !!! El nombre de host en la configuración debe corresponder al nombre que se enviará en el script, el tipo de elemento (elemento de datos) debe ser adecuado para los datos que se envían (por ejemplo, para json - texto), de lo contrario, detectará errores de la forma:
2019-09-18 14:29:48,749 Got response from Zabbix: {u'info': u'processed: 0; failed: 1; total: 1; seconds spent: 0.000055', u'response': u'success'}
Además, es difícil lograr más depuración (y por qué falló) de zabbix.
Configuramos /etc/mqtt-zabbix/mqtt-zabbix.cfg (especifique el intermediario ip mqtt y la dirección del servidor zabbix).
¿Qué más conectar a 433?
Si, cualquier cosa! :)Sensores de estación meteorológica
Mientras jugueteaba con los sensores de fuga inalámbricos, accidentalmente capté la señal de un sensor externo de una estación meteorológica. Se veía así:
time : 2019-09-19 10:48:54 Protocol : 56 model : TFA pool temperature sensor Id : 182 Channel : 3 Temperature: 19.3 C Modulation: ASK Freq : 433.9 MHz RSSI : -0.1 dB SNR : 35.0 dB Noise : -35.2 dB time : 2019-09-20 10:57:29 Protocol : 12 brand : OS model : THN132N House Code: 4 Channel : 3 Battery : OK Celsius : 20.00 C Modulation: ASK Freq : 432.9 MHz RSSI : -0.2 dB SNR : 31.5 dB Noise : -31.7 dB
Por lo tanto, la ventaja era la capacidad de controlar la temperatura de los puntos en el aire con visualización en zabbix. Solo en algunas habitaciones no puedo estirar el cable.
Timbre
Muchas llamadas de radio funcionan en el mismo rango de frecuencia ~ 433 mhz. Por lo tanto, podemos interceptar la presión del botón de llamada (ni siquiera es necesario tener la llamada en sí, solo el botón es suficiente). Por qué Por ejemplo, para configurar una notificación adicional por SMS / telegrama / lo que sea o mostrar la imagen de la cámara en el monitor.
Compré una llamada: Evology QA-688-E RU.
Para que el botón rtl_433 vea el botón de llamada, debe activar los protocolos de "prueba", por ejemplo, ejecutando con la opción "G" o especificando un protocolo adicional específico, al mismo tiempo agregaremos la salida de información sobre el protocolo y la frecuencia:
rtl_433 -f 433.9e6 -G -M protocol -M level -F mqtt://127.0.0.1,events=/433/[id] &
Entra en MQTT:
{"time":"2019-09-30 10:57:00","protocol":72,"model":"RF-tech","id":0,"battery":"LOW","temperature_C":0,"button":0,"mod":"ASK","freq":433.84822,"rssi":-3.5981,"snr":33.77488,"noise":-37.373}
Aquí puedes ver id = 0. Al mismo tiempo, tenía varios dispositivos identificados como tecnología RF. Todos ellos tenían una identificación igual a 0. Como resultado, todos los dispositivos en zabbix se muestran como un elemento. Es posible distinguir exactamente qué dispositivo funcionó, solo por frecuencia.
Extraemos la frecuencia a un elemento dependiente separado: mqtt.outside.doorbell.freq con preprocesamiento JSON en $ .freq (zabbix puede hacer esto desde la cuarta versión).
En este elemento, active un disparador con la expresión:
{HOME_PI:mqtt.outside.doorbell.freq.last()}>433.8 and {HOME_PI:mqtt.outside.doorbell.freq.last()}<433.81 and {HOME_PI:mqtt.outside.doorbell.freq.nodata(30)}=0
Es decir si de repente aparece un valor en el elemento general mqtt.outside.doorbell.freq (nodata) y la frecuencia está en el rango especificado entre 433.8 y 433.81, podemos concluir que nos están llamando (y, por ejemplo, para duplicar una llamada a SMS).
Sensores de puerta / ventana
Tengo un sensor de penetración de rubetek. Envía lo siguiente:
{"time":"2019-09-30 14:11:28","protocol":86,"model":"Smoke detector GS 558","id":12262,"unit":16,"learn":0,"code":"e5fcd0","mod":"ASK","freq":433.85021,"rssi":-3.99241,"snr":33.38058,"noise":-37.373} : {"time":"2019-09-30 14:11:28","protocol":68,"model":"Kerui Security","id":46074,"cmd":7,"state":"close","mod":"ASK","freq":433.85021,"rssi":-3.99241,"snr":33.38058,"noise":-37.373} : {"time":"2019-09-30 14:11:21","protocol":68,"model":"Kerui Security","id":46074,"cmd":14,"state":"open","mod":"ASK","freq":433.85005,"rssi":-11.0148,"snr":25.1088,"noise":-36.1236}
Tan pronto como se agregó el último sensor de radio a zabbix, quise rehacer todo en MQTT. Catalogación conveniente, puede determinar el tema-ah y la ubicación y los tipos de dispositivos. Obtienes la transmisión general de todos los eventos.
1 cable a MQTT
Quiero que todo esté en MQTT, al menos para el mismo tipo de implementación. Quiero obtener un "éter" general de eventos y un enfoque general en reacción a estos eventos. Por supuesto, zabbix resuelve el problema de reacción, y dejo alertas sobre él. Pero quiero que la administración sea más alegre, cercana al sistema y al "éter".
Existen soluciones listas para transmitir estados de sensores desde una red de 1 cable a MQTT, pero no me convenían. Las soluciones listas para usar en el nodo llevan muchas dependencias detrás de ellas o se comen todo el procesador de frambuesa. Algunas de las soluciones de los 10 principales en la búsqueda de Google son abandonadas por los autores, algunas solo son compatibles con sensores de temperatura. También hay una clase de puertas de enlace que recopilan información a través de la interfaz de gpio. Todo esto no me convenía.
Tengo un sistema de pseudoarchivo montado con dispositivos 1wire en / mnt / 1wire, de ahí quiero obtener toda la información necesaria. Para hacer esto, es suficiente hacer una línea simple en bash, enviando datos a través de mosquitto_pub para cada uno de los sensores. Sin embargo, hay preguntas sobre el lanzamiento de estos scripts (¿sobre la corona, para conducir a algún tipo de demonio?), Presentación normal de datos (obteniendo el mismo json), agregando un nuevo sensor, etc. Mientras más se desarrollaba el pensamiento, nacían más muletas. Resultó ser más fácil escribir una puerta de enlace para otros owfs a mqtt para esta tarea.
Hay un archivo de configuración en el que necesitamos ingresar la identificación de los sensores y los archivos de fuse.OWFS que queremos publicar en mqtt.
La salida en mqtt es el siguiente json:
/1wire/28.0425260a0000 {"type": "DS18B20", "temperature": "30"} /1wire/28.bf16270a0000 {"type": "DS18B20", "temperature": "7.9375"} /1wire/26.da2f71010000 {"temperature": "25.2812", "IAD": "1", "CA": "0", "VAD": "0.91", "VDD": "4.59", "type": "DS2438"} /1wire/28.48b3010b0000 {"type": "DS18B20", "temperature": "40.5625"} /1wire/1d.6a9306000000 {"type": "DS2423", "counter.B": "9", "counter.A": "9219"} /1wire/28.61cc260a0000 {"type": "DS18B20", "temperature": "12.5"}
Agregar a ejecución automática, establecer el intervalo de sondeo. El problema está resuelto.
Referencias
github.com/merbanan/rtl_433 - una herramienta para decodificar protocolos de radio
github.com/kylegordon/mqtt-zabbix - MQTT en Zabbix
github.com/unlo/1wire2mqtt - 1wire en MQTT, cliente MQTT que le permite ejecutar scripts cuando aparece el tema