Eintrag
Bei der Auswahl von Lösungen für ein Smart Home versuche ich, Boxed-Lösungen zu umgehen, die die Kommunikation mit externen Clouds erfordern oder über eigene Anwendungen verfügen, insbesondere Lösungen, die keine direkte Verbindung zum Gerät herstellen können. Alle verfügbaren Metriken werden auf eine Schnittstelle reduziert - zabbix, wo ein Stakeholder-Warnsystem organisiert ist. Steuerknöpfe sind in einer lokal lokalisierten Weboberfläche implementiert.
Vorherige Artikel:
Teil eins (1Drahttemperatur, Ups, Wasserzähler ...)
Teil zwei (Netping, Gidrolock, Drucksensoren ...)
Gelöste Aufgaben in diesem Artikel
- Skalierbarer, flexibler Wasserleckschutz mit Zabbix-Alarm
- Andere Geräte bei 433 MHz: Klingel, Tür offen usw.
- Wir drücken 1wire in MQTT
Auslaufschutzsystem
Systemanforderungen:
- viele Sensoren im ganzen Haus verteilt (in meinem Fall - 6 Stück an verschiedenen Orten)
- Keine Kabel an den Sensoren
- schnelles Herunterfahren bei Lecksuche
- Alle aktuellen Statusinformationen in zabbix. Es gibt eine Warnung
Systemzusammensetzung
- Himbeer PI
- RTL2832U USB-Tuner
- Lecksensoren 433 MHz
- Netping + Gidrolock-Kran (siehe vorherigen Artikel) zum Abschalten des Kofferraums
Über Eisen
In einem früheren Artikel habe ich die Lösung zum Absperren der Wasserversorgung mithilfe von Netping beschrieben. Ich habe einen verdrahteten Sensor für diese Lösung. Dies ist praktisch, wenn sich alle Stellen, an denen Leckagen auftreten können, ungefähr an derselben Stelle befinden. In meinem Fall wird Netping direkt am Eingang der Autobahn installiert und steuert den elektromechanischen Gidrolock-Kran an derselben Stelle (siehe vorherigen Artikel). Das Streuen von Netping + Gidrolock + verdrahtetem Sensor an allen Stellen ist teuer und umständlich. Außerdem habe ich keine Möglichkeit mehr, neue Drähte um das Haus zu ziehen. Das Besetzen von Steckdosen und das Einatmen von Elektrokränen ist eine mittelmäßige Lösung. Die erwartete Lösung - wir verwenden die Überlappung der gemeinsamen Autobahn basierend auf Signalen von Funksensoren, die über die Standorte verteilt sind.
Nach dem, was im Internet gefunden wurde - eine Reihe verschiedener Funksensoren aus vorgefertigten Systemen. Einige können separat gekauft werden, ich habe keine Controller für Sensoren gekauft, um keine zusätzlichen Elemente in der Schaltung zu produzieren.
Wie kann ich 433 MHz fangen? Es stellt sich heraus - ein TV-Tuner auf einem bestimmten Chipsatz. Und jetzt ist er einen Cent wert (ich habe Avito für 300r übernommen) wie folgt:
Ich habe eine separate Antenne für 12dbi bestellt, da die aktuelle nicht das ganze Haus abdeckte.
Da ich versuchte, die Steuerungskomponenten der Schaltung zu minimieren, bestand der Wunsch, den Tuner mit Openwrt, das bis dahin der Kern der Smart-Home-Lösung für 1wire-, Modbus- und WLAN-Sensoren / -Protokolle war, in meinem Heimrouter festzuziehen, aber leider habe ich einige seiner Ressourcen erschöpft ( Der Speicherplatz auf dem eingebauten Flash-Laufwerk für die erforderliche Software endet, der Prozessor lädt mit etwas - es wird bereits Probleme mit dem Netzwerk geben, und wir müssen noch 4k online suchen :), + es hängen bereits zu viele Dinge an USB, was die Stabilität der Datenerfassung beeinträchtigt. Es wurde beschlossen, die Funktionalität des Smart Home schrittweise auf ein externes Gerät zu übertragen - rarpberry pi (eine der ersten Versionen war verfügbar).
Über Software
Nachdem ich mit einem sdr-scharfen TV-Tuner auf einem Desktop-Computer mit Fenstern gespielt hatte (nachdem ich versucht hatte, die Radios und Flugzeugverhandlungen anderer Leute zu erfassen), begann ich zu sehen, ob die Sensoren selbst das „Pfeifen“ sahen. Ja, es sieht perfekt aus:
Himbeereinstellung
Ich entschied mich für einheimische Raspbian. Ich habe das letzte Bild auf dem USB-Stick unter Mac / Linux geschrieben:
sudo dd if=2019-07-10-raspbian-buster-lite.img of=/dev/disk2 bs=1048576 conv=sync
Booten Sie, konfigurieren Sie das Netzwerk und ssh.
Weiter - setzen Sie die Himbeer-Pakete 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 verfügt über integrierte Protokolle, die Daten von verschiedenen Geräten im Bereich von 433 MHz entschlüsseln.
Wir starten rtl_433
rtl_433 -f 433.9e6
Wir senken die Sensoren ins Wasser und bekommen die geschätzten:
time : 2019-09-17 15:04:39 model : Smoke detector GS 558 id : 16919 unit : 1 learn : 0 Raw Code : c842e1
Rauchmelder? Ok, lassen Sie uns das Lied "Smoke on the water" von diesen Sensoren alarmieren ... :)
Aber im Ernst - wir haben die ID jedes Sensors, nach der wir in Zukunft verstehen werden, wo genau wir ein Leck haben (und wir werden auf jeden Fall abschalten).
Über Lecksensoren
Nach dem Einrichten des Softwareteils bemerkte ich, dass die Sensoren mit aliexpress (linkes Foto) ein einzelnes Signal senden, wenn Wasser in die Kontakte gelangt. Plus ein einzelnes Signal, wenn das Wasser die Kontakte nicht mehr schließt. Dies passt in keiner Weise zu mir (erwartetes Verhalten: Senden Sie ständig ein Alarmsignal, wenn der Sensor Wasser erkennt, da ein einzelnes Signal verloren gehen kann). Ein ähnliches Verhalten wird beobachtet, wenn Sie die Kontakte mit einem Draht schließen. Aber was seltsam ist - Alarm tritt alle 2-3 Sekunden auf, wenn Sie die Kontakte mit Ihren Händen (Haut) schließen. Hier habe ich noch zwei Annahmen: Entweder haben die Chinesen Widerstandsmessungen vermasselt, oder die Sensoren haben eine andere Betriebsart, in der sie sich irgendwie anders verhalten (zum Beispiel gepaart mit einem Controller), oder es gibt andere Frequenzen (bis ich sie gefunden habe) )
Übrigens, schreiben Sie in die Kommentare, vielleicht hat jemand mit diesen Sensoren gearbeitet. Kann man ihnen irgendwie "beibringen", ständig ein Signal über ein Leck zu senden?Ich legte diese Sensoren beiseite, im Arsenal befand sich ein weiterer von Rubetek (rechtes Foto) und kaufte in Leroy: GAL SHW-1005 (mittleres Foto).
Das Verhalten des Rubetek-Sensors schien völlig unvorhersehbar (die unvorhersehbare Reaktion „sieht Wasser / sieht nicht“).
Aber der Sensor von Leroy in Bewegung zeigte genau das, was ich brauchte: Es gibt Wasser - ich spamme es in der Luft, es gibt kein Wasser - ich schweige. Das einzige Minus ist ein kleinerer Aktionsradius als bei anderen Sensoren. Das Problem wurde jedoch durch den Kauf einer empfindlicheren Antenne für den Empfänger gelöst.
MQTT
Wie sende ich eine rtl_433-Ausgabe an zabbix? Den Agenten füttern? An zabbix_sender senden und den Prozess analysieren? Vielleicht durch Syslog?
Hier müssen Sie sich daran erinnern, dass mein Zabbix irgendwo in den Wolken ist. Und sicherlich ist es nicht notwendig, das Wasser mit Hilfe seiner Auslöser zu blockieren. Der Boden des Hauses wird überflutet, bis er eine Entscheidung trifft (falls überhaupt verfügbar).
Die gute Nachricht ist, dass rtl_433 Informationen über MQTT senden kann. Out of the Box. Gleichzeitig werden Daten im JSON-Format an den Broker gesendet.
Sie brauchen also:
- Platzieren Sie einen lokalen Mückenmakler (tun Sie es auf der Himbeere).
- Führen Sie die Informationen mit dem gewünschten Thema in den Broker ein, damit sie später analysiert werden können.
- Stellen Sie eine lokale Verbindung zum Broker auf der Himbeere her und senden Sie Befehle an netping
- Stellen Sie von dem Ort aus, an dem die Umleitung zu zabbix erfolgen soll, eine Verbindung zum Broker her (der zabbix-Server ist in meinem Fall auch ein MQTT-Client).
Installations-Setup-Mücke MQTT:
apt-get install mosquitto mosquitto-clients systemctl enable mosquitto systemctl start mosquitto
Wir senden dem Broker Informationen mit der Geräte-ID:
rtl_433 -f 433.88e6 -F mqtt://127.0.0.1,events=/433/[id]
Im mqtt-Client erhalten wir ungefähr Folgendes:
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"}
Skript zum Herstellen einer Verbindung zum Broker und zum Senden des Befehls an netping
Ich habe einen einfachen MQTT-Skriptclient entworfen, mit dem Sie das dem Thema zugeordnete Skript ausführen können, wenn das in der Konfiguration angegebene Thema angezeigt wird. Wenn also ein bestimmter Sensor ausgelöst wird und Informationen darüber in der Luft angezeigt werden (z. B. / 433/16919), können Sie eine Aktion ausführen (im Falle eines Netzes senden Sie eine Curl-Anforderung zum Schließen des Krans, siehe vorherigen Artikel). Ein Link zum Skript befindet sich am Ende des Artikels.
Umleitung in zabbix
Ich habe die fertige mqtt-zabbix-Lösung verwendet. Auf seiner Ebene verstehen wir, in welchem Element der Wert gesendet werden soll (anhand der ID).
Geben Sie in keys.cfg Folgendes an:
/433/16919,mqtt.ventilation.waterleak::hostname
Dabei ist Hostname der Hostname mit dem Elementtramp-Typ in Zabbix.
Wichtig !!! Der Hostname in den Einstellungen sollte dem Namen entsprechen, der im Skript gesendet werden soll. Der Elementtyp (Datenelement) sollte für die gesendeten Daten geeignet sein (z. B. für json - text), da sonst Fehler des Formulars auftreten:
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'}
Darüber hinaus ist es schwierig, mehr Debugging (und warum fehlgeschlagen) von zabbix zu erreichen.
Wir konfigurieren /etc/mqtt-zabbix/mqtt-zabbix.cfg (geben Sie den ip mqtt-Broker und die Adresse des zabbix-Servers an).
Was kann man noch mit 433 verbinden?
Ja, alles! :) :)Wetterstationssensoren
Beim Basteln mit drahtlosen Lecksensoren habe ich versehentlich das Signal eines externen Sensors von einer Wetterstation abgefangen. Es sah so aus:
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
Der Bonus war somit die Möglichkeit, die Temperatur der Punkte über Luft mit Anzeige in Zabbix zu überwachen. Nur in einigen Räumen kann ich das Kabel nicht dehnen.
Türklingel
Viele Funkanrufe arbeiten im gleichen Frequenzbereich von ~ 433 MHz. Auf diese Weise können wir das Drücken der Anruftaste abfangen (es ist nicht einmal erforderlich, den Anruf selbst zu tätigen, nur die Taste reicht aus). Warum? Zum Beispiel, um zusätzliche Benachrichtigungen per SMS / Telegramm / was auch immer zu konfigurieren oder das Bild von der Kamera auf dem Monitor anzuzeigen.
Ich habe einen Anruf gekauft: Evology QA-688-E RU.
Damit die Schaltfläche rtl_433 die Anruftaste anzeigt, müssen Sie die Testprotokolle aktivieren, indem Sie beispielsweise die Option „G“ ausführen oder ein bestimmtes zusätzliches Protokoll angeben. Gleichzeitig fügen wir die Ausgabe von Informationen über das Protokoll und die Häufigkeit hinzu:
rtl_433 -f 433.9e6 -G -M protocol -M level -F mqtt://127.0.0.1,events=/433/[id] &
Holen Sie sich in 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}
Hier sehen Sie id = 0. Gleichzeitig ließ ich mehrere Geräte als RF-Tech identifizieren. Alle hatten eine ID gleich 0. Daher werden alle Geräte in zabbix als ein Element angezeigt. Es ist nur anhand der Frequenz möglich, genau zu unterscheiden, welches Gerät funktioniert hat.
Wir ziehen die Frequenz in ein separates abhängiges Element: mqtt.outside.doorbell.freq mit JSON-Vorverarbeitung bei $ .freq (zabbix kann dies ab der 4. Version tun).
Machen Sie für dieses Element einen Trigger mit dem Ausdruck:
{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
Das heißt, Wenn plötzlich ein Wert im allgemeinen Element mqtt.outside.doorbell.freq (nodata) erscheint und die Häufigkeit im angegebenen Bereich zwischen 433,8 und 433,81 liegt, können wir daraus schließen, dass sie uns anrufen (und beispielsweise einen Anruf bei SMS duplizieren).
Tür- / Fenstersensoren
Ich habe einen Penetrationssensor von Rubetek. Sendet Folgendes:
{"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}
Sobald der letzte Funksensor zu zabbix hinzugefügt wurde, wollte ich alles auf MQTT wiederholen. Bequeme Katalogisierung, Sie können das Thema-ah sowie die Platzierung und Typen von Geräten bestimmen. Sie erhalten die allgemeine Übertragung aller Ereignisse.
1Wire zu MQTT
Ich möchte, dass alles in MQTT ist, zumindest für die gleiche Art der Implementierung. Ich möchte einen allgemeinen "Äther" der Ereignisse und einen allgemeinen Ansatz als Reaktion auf diese Ereignisse erhalten. Natürlich löst zabbix das Reaktionsproblem und ich hinterlasse Warnungen. Aber ich möchte das Management unbeschwerter machen, nah am System und am "Äther".
Es gibt vorgefertigte Lösungen für die Weiterleitung von Sensorzuständen von einem 1-Draht-Netzwerk an MQTT, aber sie passten nicht zu mir. Vorgefertigte Lösungen auf dem Knoten enthalten entweder eine Reihe von Abhängigkeiten oder den gesamten Himbeerprozessor. Einige der Lösungen aus den Top 10 der Google-Suche werden von den Autoren aufgegeben, andere werden nur von Temperatursensoren unterstützt. Es gibt auch eine Klasse von Gateways, die Informationen über die GPIO-Schnittstelle sammeln. Das alles passte nicht zu mir.
Ich habe ein gemountetes Pseudo-Dateisystem mit 1wire-Geräten in / mnt / 1wire. Dort möchte ich alle erforderlichen Informationen abrufen. Um dies zu tun, reicht es aus, eine einfache einzeilige Bash zu erstellen und Daten für jeden der Sensoren über mosquitto_pub zu senden. Es gibt jedoch Fragen zum Starten dieser Skripte (über die Krone, um in eine Art Dämon zu fahren?), Zur normalen Darstellung von Daten (mit demselben JSON), zum Hinzufügen eines neuen Sensors usw. Je weiter sich der Gedanke entwickelte, desto mehr Krücken wurden geboren. Es stellte sich heraus, dass es einfacher war, ein Gateway für ein weiteres Owfs zu mqtt für diese Aufgabe zu schreiben.
Es gibt eine Konfigurationsdatei, in der wir die ID der Sensoren und die Dateien von fuse.OWFS eingeben müssen, die wir in mqtt veröffentlichen möchten.
Die Ausgabe in mqtt ist die folgende 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"}
Zum Autorun hinzufügen, das Abfrageintervall festlegen. Das Problem ist gelöst.
Referenzen
github.com/merbanan/rtl_433 - ein Tool zum Dekodieren von Funkprotokollen
github.com/kylegordon/mqtt-zabbix - MQTT auf Zabbix
github.com/unlo/1wire2mqtt - 1wire in MQTT, MQTT-Client, mit dem Sie Skripts ausführen können, wenn das Thema angezeigt wird