Énergie, chaleur et eau, troisième partie: allez à la radio

Entrée


Dans le processus de choix des solutions pour une maison intelligente, j'essaie de contourner les solutions en boîte qui nécessitent une communication avec des clouds externes ou qui ont leurs propres applications, en particulier des solutions sans possibilité de se connecter directement à l'appareil. Toutes les mesures disponibles sont réduites à une seule interface - zabbix, où un système d'alerte des parties prenantes est organisé. Les boutons de contrôle sont implémentés dans une interface Web localisée.

Articles précédents:


première partie (température 1 fil, ups, compteur d'eau ...)
deuxième partie (netping, gidrolock, capteurs de pression ...)

Tâches résolues dans cet article


  • Protection extensible et flexible contre les fuites d'eau avec alerte zabbix
  • Autres appareils à 433 MHz: sonnette, porte ouverte, etc.
  • Nous poussons 1 fil dans MQTT

Système de protection contre les fuites


Configuration requise:


  • beaucoup de capteurs dispersés dans la maison (dans mon cas - 6 pièces à différents endroits)
  • pas de fils aux capteurs
  • arrêt rapide en cas de détection de fuite
  • toutes les informations d'état actuelles dans zabbix. Il y a une alerte

Composition du système


  • Raspberry PI
  • Tuner USB RTL2832U
  • Capteurs de fuite 433 mhz
  • Grue Netping + gidrolock (voir article précédent) pour fermer le coffre

À propos du fer


Dans un article précédent, j'ai décrit la solution consistant à couper l'alimentation en eau à l'aide de netping. J'ai un capteur filaire pour cette solution. Ceci est pratique si tous les points où des fuites peuvent se produire sont approximativement au même endroit. Dans mon cas, netping est installé directement à l'entrée de l'autoroute et contrôle la grue électromécanique Gidrolock au même endroit (voir l'article précédent). La diffusion netping + gidrolock + capteur filaire en tous points est coûteuse et encombrante. De plus, je n'ai plus la possibilité de faire glisser de nouveaux fils autour de la maison. L'occupation des prises et la respiration des grues électriques est une solution médiocre. La solution est attendue - nous utilisons le chevauchement de la route commune basé sur les signaux des capteurs radio répartis sur les sites.
D'après ce qui a été trouvé sur Internet - un tas de différents capteurs radio de systèmes finis. Certains peuvent être achetés séparément, je n'ai pas acheté de contrôleurs pour capteurs, afin de ne pas produire d'éléments supplémentaires dans le circuit.

Comment puis-je attraper 433 mhz? Il s'avère - un tuner TV sur un chipset spécifique. Et maintenant, il vaut un sou (j'ai pris Avito pour 300r) comme ceci:

image

J'ai commandé une antenne séparée pour cela sur 12dbi, car l'actuelle ne couvrait pas toute la maison.

Depuis que j'ai essayé de minimiser les composants de contrôle du circuit, il y avait un désir de resserrer le tuner dans mon routeur domestique avec Openwrt, qui était jusque-là le cœur de la solution de maison intelligente pour 1 fil, modbus, capteurs / protocoles wifi, mais, malheureusement, j'ai épuisé certaines de ses ressources ( l'espace sur le lecteur flash intégré pour les logiciels nécessaires se termine, le processeur se charge de quelque chose - il y aura déjà des problèmes avec le réseau, et nous avons encore 4k pour regarder en ligne :), + il y a déjà trop de choses accrochées sur USB, ce qui affecte la stabilité de la collecte de données). Il a été décidé de transférer progressivement les fonctionnalités de la maison intelligente vers un appareil externe - rarpberry pi (l'une des premières versions était à portée de main).

À propos des logiciels


Après avoir joué avec un tuner TV en sdr-sharp sur un ordinateur de bureau avec des fenêtres (après avoir essayé d'attraper les radios et les négociations des avions d'autres personnes), j'ai commencé à regarder si les capteurs eux-mêmes voyaient le «sifflement». Oui, il voit parfaitement:

image

Réglage framboise


J'ai choisi le raspbian natif. J'ai écrit la dernière image sur la clé USB sous mac / linux:

sudo dd if=2019-07-10-raspbian-buster-lite.img of=/dev/disk2 bs=1048576 conv=sync 

Démarrez, configurez le réseau et ssh.

Ensuite - mettez les paquets de framboises 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 possède des protocoles intégrés qui déchiffrent les données de différents appareils fonctionnant dans la gamme 433 MHz.

Nous commençons rtl_433


 rtl_433 -f 433.9e6 

Nous abaissons les capteurs dans l'eau et obtenons les chéris:

 time : 2019-09-17 15:04:39 model : Smoke detector GS 558 id : 16919 unit : 1 learn : 0 Raw Code : c842e1 

Détecteur de fumée? Ok, mettons la chanson "Smoke on the water" sur l'alerte de ces capteurs ... :)
Mais sérieusement - nous avons l'identifiant de chaque capteur, selon lequel à l'avenir nous comprendrons où exactement nous avons une fuite (et nous fermerons de toute façon).

À propos des capteurs de fuite


imageimageimage

Après avoir installé la partie logicielle, j'ai remarqué que les capteurs avec aliexpress (photo de gauche) envoient un seul signal lorsque l'eau pénètre dans les contacts. Plus un seul signal si l'eau cesse de fermer les contacts. Cela ne me convient en aucune façon (comportement attendu: envoyer constamment un signal d'alarme lorsque le capteur détecte de l'eau, car un seul signal peut être perdu). Un comportement similaire est observé si vous fermez les contacts avec un fil. Mais ce qui est étrange - l'alarme se produit toutes les 2-3 secondes, si vous fermez les contacts avec vos mains (peau). Ici, j'ai encore deux hypothèses: soit les Chinois foirés avec des mesures de résistance, soit les capteurs ont un autre mode de fonctionnement dans lequel ils se comportent différemment (par exemple, couplés avec un contrôleur), ou il y a d'autres fréquences (jusqu'à ce que je trouve )

Soit dit en passant, écrivez dans les commentaires, peut-être que quelqu'un a travaillé avec ces capteurs, peut-il en quelque sorte "apprendre" à envoyer un signal sur une fuite en permanence?

J'ai mis ces capteurs de côté, dans l'arsenal était un autre de rubetek (photo de droite) et acheté à Leroy: GAL SHW-1005 (photo du milieu).

Le comportement du capteur rubetek semblait complètement imprévisible (la réaction imprévisible «voit de l'eau / ne voit pas»).

Mais le capteur de Leroy en mouvement a montré exactement ce dont j'avais besoin: il y a de l'eau - je le spamme dans l'air, il n'y a pas d'eau - je me tais. Son seul inconvénient est un rayon d'action plus petit que les autres capteurs. Mais le problème a été résolu en achetant une antenne plus sensible pour le récepteur.

MQTT


Comment envoyer la sortie rtl_433 à zabbix? Nourrir l'agent? Envoyer à zabbix_sender, analyser le processus? Peut-être via syslog?

Ici, vous devez vous rappeler que mon zabbix est quelque part dans les nuages. Et il n'est certainement pas nécessaire de bloquer l'eau à l'aide de ses déclencheurs. Le sol de la maison sera inondé jusqu'à ce qu'il prenne une décision (le cas échéant).

La bonne nouvelle est que rtl_433 peut envoyer des informations sur MQTT. Hors de la boîte. Dans le même temps, les données sont envoyées au courtier au format json.

Il vous faut donc:

  • Placez un courtier en moustiques local (faites-le sur la framboise).
  • Fusionnez les informations dans le courtier avec le sujet souhaité, afin de pouvoir les analyser ultérieurement.
  • Connectez-vous au courtier localement sur la framboise et envoyez des commandes à netping
  • Connectez-vous au courtier depuis l'endroit où la redirection vers zabbix aura lieu (le serveur zabbix dans mon cas est également un client MQTT)

Installation-setup moustique MQTT:


 apt-get install mosquitto mosquitto-clients systemctl enable mosquitto systemctl start mosquitto 

Nous envoyons des informations au courtier en indiquant l'ID de l'appareil:


 rtl_433 -f 433.88e6 -F mqtt://127.0.0.1,events=/433/[id] 

Dans le client mqtt, nous obtiendrons quelque chose comme ceci:

 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 pour se connecter au courtier et envoyer la commande à netping


J'ai esquissé un client de script MQTT simple qui vous permet d'exécuter le script associé au sujet lorsque le sujet spécifié dans la configuration apparaît. Ainsi, lorsqu'un certain capteur est déclenché et que des informations à ce sujet apparaissent sur l'Air (par exemple, / 433/16919), vous pouvez effectuer une action (dans le cas de netping, envoyer une demande de bouclage de la grue pour fermer la grue, voir l'article précédent). Un lien vers le script se trouve à la fin de l'article.

Redirection dans zabbix


J'ai utilisé la solution mqtt-zabbix prête à l'emploi. A son niveau, on comprend dans quel élément envoyer la valeur (par id).

Dans keys.cfg, spécifiez:

 /433/16919,mqtt.ventilation.waterleak::hostname 

où hostname est le nom d'hôte avec le type de clochard d'élément dans Zabbix.

Important !!! Le nom d'hôte dans les paramètres doit correspondre au nom à envoyer dans le script, le type d'élément (élément de données) doit être adapté aux données envoyées (par exemple, pour json - text), sinon vous détecterez des erreurs du formulaire:

 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'} 

De plus, il est difficile d'obtenir plus de débogage (et pourquoi échoué) à partir de zabbix.

Nous configurons /etc/mqtt-zabbix/mqtt-zabbix.cfg (spécifiez le courtier ip mqtt et l'adresse du serveur zabbix).

Quoi d'autre pour se connecter au 433?


Oui, n'importe quoi! :)

Capteurs de station météo


En bricolant avec des capteurs de fuite sans fil, j'ai accidentellement capté le signal d'un capteur externe d'une station météo. Cela ressemblait à ceci:

 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 

Ainsi, le bonus était la possibilité de surveiller la température des points sur l'air avec affichage en zabbix. Juste dans certaines pièces, je ne peux pas étirer le câble.

Sonnette


De nombreux appels radio fonctionnent dans la même gamme de fréquences ~ 433 MHz. Ainsi, nous pouvons intercepter la pression sur le bouton d'appel (il n'est même pas nécessaire d'avoir l'appel lui-même, juste le bouton suffit). Pourquoi? Par exemple, pour configurer une notification supplémentaire par SMS / télégramme / quoi que ce soit ou afficher l'image de la caméra sur le moniteur.

J'ai acheté un appel: Evology QA-688-E RU.

Pour que le bouton rtl_433 puisse voir le bouton d'appel, vous devez activer les protocoles «test», par exemple en exécutant l'option «G» ou en spécifiant un protocole supplémentaire spécifique, en même temps, nous ajouterons la sortie d'informations sur le protocole et la fréquence:

 rtl_433 -f 433.9e6 -G -M protocol -M level -F mqtt://127.0.0.1,events=/433/[id] & 

Entrez dans 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} 

Ici, vous pouvez voir id = 0. En même temps, j'avais plusieurs appareils identifiés comme RF-tech. Tous avaient un identifiant égal à 0. Par conséquent, tous les appareils dans zabbix sont affichés comme un seul élément. Il est possible de distinguer exactement quel appareil a fonctionné, uniquement par fréquence.

Nous tirons la fréquence dans un élément dépendant distinct: mqtt.outside.doorbell.freq avec un prétraitement JSON à $ .freq (zabbix peut le faire à partir de la 4ème version).

Sur cet élément, créez un déclencheur avec l'expression:

 {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 

C'est-à-dire si tout à coup une valeur apparaît dans l'élément général mqtt.outside.doorbell.freq (nodata) et que la fréquence est dans la plage spécifiée entre 433,8 et 433,81, nous pouvons conclure qu'ils nous appellent (et par exemple, pour dupliquer un appel à SMS).

Capteurs de porte / fenêtre


J'ai un capteur de pénétration de rubetek. Envoie ce qui suit:

 {"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} 

Dès que le dernier capteur radio a été ajouté à zabbix, j'ai voulu tout refaire sur MQTT. Catalogage pratique, vous pouvez déterminer le sujet-ah et l'emplacement et les types d'appareils. Vous obtenez la diffusion générale de tous les événements.

1 fil vers MQTT


Je veux que tout soit dans MQTT, au moins pour le même type d'implémentation. Je veux obtenir un "éther" général des événements et une approche générale en réaction à ces événements. Bien sûr, zabbix résout le problème de réaction et je laisse des alertes dessus. Mais je veux rendre la gestion plus légère, proche du système et de "l'éther".

Des solutions prêtes à l'emploi pour relayer les états des capteurs d'un réseau 1 fil à MQTT existent, mais elles ne me convenaient pas. Les solutions prêtes à l'emploi sur le nœud portent soit un tas de dépendances derrière elles, soit ont mangé le processeur de framboise entier. Certaines des solutions du top 10 de la recherche Google sont abandonnées par les auteurs, certaines ne sont prises en charge que par des capteurs de température. Il existe également une classe de passerelles collectant des informations via l'interface gpio. Tout cela ne me convenait pas.

J'ai un système de pseudo-fichiers monté avec des périphériques 1wire dans / mnt / 1wire, c'est là que je veux obtenir toutes les informations nécessaires. Pour ce faire, il suffit de faire une simple ligne sur bash, en envoyant des données via mosquitto_pub pour chacun des capteurs. Cependant, il y a des questions de lancement de ces scripts (par-dessus la couronne, pour conduire dans une sorte de démon?), Présentation normale des données (obtenir le même json), ajout d'un nouveau capteur, etc. Plus la pensée s'est développée, plus les béquilles sont nées. Il s'est avéré plus facile d'écrire une passerelle pour encore un autre owfs à mqtt pour cette tâche.

Il y a un fichier de configuration dans lequel nous devons entrer l'id des capteurs et ces fichiers de fuse.OWFS que nous voulons publier sur mqtt.

La sortie dans mqtt est le json suivant:

 /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"} 

Ajouter à l'exécution automatique, définissez l'intervalle d'interrogation. Le problème est résolu.

Les références


github.com/merbanan/rtl_433 - un outil pour décoder les protocoles radio
github.com/kylegordon/mqtt-zabbix - MQTT sur Zabbix
github.com/unlo/1wire2mqtt - 1 fil dans MQTT, client MQTT qui vous permet d'exécuter des scripts lorsque la rubrique apparaît

Source: https://habr.com/ru/post/fr467761/


All Articles