Guten Tag, liebe Chabrowiter! Vor einigen Jahren habe ich eine bunte zWave-Anzeige gekauft und Fenstersensoren installiert, die auf diesem Protokoll basieren. Ein USB-zWave-Stick wurde an den Heimserver angeschlossen, der die Rolle eines Controllers spielte, ein kleines Java-Modul wurde geschrieben, das Daten von diesem Controller empfing, und eine kleine Anwendung für Android wurde geschrieben, die den Status aller Sensoren auf wunderbare Weise anzeigt. Batterien eingelegt, Sensoren am Controller angemeldet, alles funktioniert. Aber nach ein paar Monaten gab es eine schreckliche Enttäuschung. Erstens funktionieren diese zWave-Sensoren nach dem Prinzip "Senden Sie eine Nachricht und schlafen Sie ein, ohne auf die Bestätigung zu warten". In meinem Fall führte dies dazu, dass das Signal der am weitesten vom Controller entfernten Sensoren einfach nicht zum Controller gelangte. Auch die Installation eines zusätzlichen zWave-Repeaters hat nicht geholfen. Zum anderen wurde der Akku so schnell entladen, dass nach etwa sechs Monaten alle Sensoren nicht mehr funktionierten. Der Grund ist, dass sie jede Stunde aufwachten, um den Controller über ihren Zustand zu informieren. Deaktivieren oder Ändern dieser Option funktionierte nicht, da Standardsoftware dies kategorisch nicht zuließ. Nach zwei Jahren der Qual mit dieser rohen, unzuverlässigen und unfreundlichen Technologie entschied ich, dass ich genug hatte. Aber anstatt alles wegzulegen und wegzuwerfen, kam mir die Idee, die Koffer zu verlassen, aber die Elektronik darin zu ändern. Die Wahl fiel auf einen relativ einfachen RFM69-Transceiver (433 MHz), auf dessen Grundlage sowohl eine Platine für den Sensor als auch eine über USB mit dem Server verbundene Steuerung hergestellt werden konnten. Das neue System ist bereits seit 5 Monaten in Betrieb, die Zuverlässigkeit liegt nahe bei 100% (es gab jedoch noch einige Ausfälle), die Batterien scheinen noch nicht leer zu sein. Das heißt, es ist bereits sichtbar, dass alle Mängel des alten Systems, das auf zWave basiert, beseitigt wurden, und ich möchte die technischen Details dieses Artikels teilen, siehe das Bild.
Wen kümmert es, bitte, unter der Katze.
Es scheint mir, dass sich zWave in meinem Fall aus zwei Gründen als nicht funktionsfähig herausgestellt hat: Das Haus hat zwei Etagen mit Stahlbetonböden und eine große Fläche (das heißt, eine erhebliche Entfernung einiger Sensoren von der Steuerung). Nun, Fehler in der proprietären Software, die es nicht ermöglichten, das periodische Aufwecken der Sensoren zu deaktivieren, was zu einer schnellen Batterieentladung führte. Als sich herausstellte, dass ich nicht mit zWave unterwegs war, suchte ich nach anderen Optionen, die in dasselbe Sensorgehäuse gesteckt werden konnten.
Mein erster Prototyp von Sensoren basierte auf dem ESP8266. Der Controller - auf der Grundlage meiner Zahlung, über die ich bereits
auf Habré geschrieben habe . Das System hat sogar als Prototyp funktioniert, aber ich musste es aus zwei Gründen aufgeben. Der erste Grund ist der gleiche: Im Haus gab es Ecken mit einem sehr niedrigen WLAN-Signalpegel, was beim Aufwachen zu einer sehr langen Aktivierungszeit des ESP8266 und damit zu einer starken Batterieentladung führte. Obwohl ich zugebe, dass ich gerade nicht weiß, wie man diesen ESP8266 kocht (Artikel
wie dieser bestätigen diese These). Aber der zweite Grund war ernster. Da ich mich entschlossen habe, nicht nur das Gehäuse, sondern auch das Batteriefach zu belassen, war ich auf eine CR123A-Batterie beschränkt, die 3,0 Volt beträgt. Das heißt, der Preis und die Komplexität des Sensors nahmen aufgrund des zunehmenden DC / DC-Wandlers zu. Obwohl
es zu diesem Thema
einen wunderbaren Artikel über Habré gibt. Aber diese beiden Gründe überwogen und ich lehnte ESP8266 ab.
Der zweite Prototyp wurde verkabelt. Ich habe einen Prototyp sowohl des Sensors als auch des USB-Controllers erstellt und ein Servermodul hinzugefügt, damit er diesen Controller zusätzlich zum zWave-Stick versteht. Es gab die Idee, die Drähte und den Sensor nach und nach zu ziehen, um die zWave-Platine in eine verkabelte zu verwandeln. Aber am Ende hat er keine Wände ausgesucht und diesen Prototyp auch weggeworfen.
Dann entschied er sich für die Funkmodule mit 433 und 868 MHz und bestellte mehrere Module für Experimente:
RFM69HCW ,
A110LR09A und
MRF89XAM8A . In Bezug auf Modulgröße, Preis und auch aufgrund der Verfügbarkeit von Bibliotheken und
guten Beispielen habe ich mich für RFM69HCW entschieden, das die Basis des Systems bildete.
Das System besteht nur aus vier Komponenten:
- drahtlose Sensoren (433 MHz, CR123A 3.0V Batterie),
- Netzwerkcontroller (433 MHz, Stromversorgung über USB vom Server)
- den Server (über den ich in diesem Artikel bereits über Habré geschrieben habe ) und das Server-Programm-Modul
- Mobiler Client (Android-Anwendung)
Im Folgenden werde ich jedes Modul detailliert beschreiben und am Ende Statistiken über den Betrieb des Systems in den letzten Betriebsmonaten geben.
Sensoren
Die Sensoren verwenden das
Funkmodul RFM69HCW . Es hat einen weiten Betriebsspannungsbereich (1,8 V - 2,4 V, 17 dBm, 2,4 V - 3,6 V, 20 dBm) und wird über SPI gesteuert. Das heißt, Sie benötigen einen Mikrocontroller. Vor einiger Zeit habe ich die STM32L-Serie kennengelernt und den STM32L051 für Experimente bestellt. Es bestach mich als kleinen Strom im Schlafmodus (0,27 μA) und die Betriebsspannung, fast identisch mit der Spannung des Funkmoduls (1,65 V - 3,6 V). Plus niedriger Preis.
Es stellte sich folgendes Schema heraus:
Die Versorgungsspannung des Mikrocontrollers und des Funkmoduls ist so bemessen, dass sie direkt vom CR123A-Element gespeist werden können. STM32L051 verfügt über eine interne Spannungsreferenz, die an ADC-Kanal 17 angeschlossen ist, sowie den Kalibrierungswert dieser Quelle, mit dem Sie den aktuellen Wert der Versorgungsspannung VDD messen können. Das Funkmodul wird über das Q1-Feldgerät mit Strom versorgt, sodass Sie die Stromversorgung über den Mikrocontroller steuern können.
Der Schlafmodus wird durch Versetzen des Mikrocontrollers in "Standby" implementiert. In diesem Modus verfügt der STM32L051 über einen deaktivierten Kern, fast alle Peripheriegeräte und einen internen Spannungsregler, der einen Verbrauch von 0,29 μA (bei deaktivierter Echtzeituhr) gewährleistet. In diesem Modus gibt es jedoch eine Besonderheit: Der Mikrocontroller wird nur mit der ansteigenden Flanke des Signals am WKUP-Pin (A0) aktiviert. Da ein Magnetschalter verwendet wird, der ein- und ausgeschaltet ist (geschlossen oder geöffnet), benötigen Sie einen kleinen Block, der sowohl beim Schließen als auch beim Öffnen eines Magnetkontakts einen Impuls von kurzer Dauer erzeugt. Dieser Impuls wird dem Eingang A0 des Mikrocontrollers zugeführt und weckt diesen. Ein solcher Wandler ist auf dem Exklusiv-ODER-Chip IC3 der energieeffizienten 74AUP-Serie (74AUP1G86) implementiert, der im Spannungsbereich von 0,8 V - 3,6 V arbeitet und 0,2 μA verbraucht. Daher sollte der Gesamtverbrauch im Schlafmodus bei etwa 0,5 μA liegen, was durch Messungen an einem vollständig montierten Sensor bestätigt wird.
Wenn der Mikrocontroller aufwacht, misst er zuerst die Versorgungsspannung und wenn sie weniger als 1,8 Volt beträgt, ist es kein Schicksal - der Sender kann nicht gestartet werden und der Mikrocontroller schläft zurück.
Ist die Batteriespannung größer als 1,8 Volt, schaltet der Mikrocontroller ein und initialisiert das Funkmodul, überträgt den Status an den Netzwerkcontroller und wartet auf Bestätigung. Das Datenpaket enthält eine eindeutige 32-Bit-Paket- (Ereignis-) Nummer, Batteriespannung, Temperatur, Magnetkontaktstatus und Steuerbyte (CRC7). Bei erfolgreicher Bestätigung schläft der Mikrocontroller wieder ein. Wenn nicht, wird der Status erneut gesendet, jedoch maximal 10 Mal. Ich habe diese Grenze so festgelegt, dass der Sensor in einer Situation, in der der Netzwerkcontroller einfach ausgeschaltet ist, nicht auf unbestimmte Zeit auf eine Antwort wartet. Die zuletzt übertragene eindeutige Ereignisnummer wird im internen EEPROM des Mikrocontrollers gespeichert.
Während der Datenübertragung blinkt auf dem Mikrocontroller eine LED (wo ohne). Das Einschalten der LED erfolgt über PWM, wobei das Tastverhältnis vom aktuellen Spannungswert abhängt. Dadurch können Sie in nahezu allen Betriebsspannungsbereichen nahezu die gleiche Helligkeit erzielen.
Die Boards sind in EagleCAD gestaltet, das Board-Design finden Sie
hier . Die Platinen sind doppelseitig: Der Mikrocontroller und sein Kabelbaum befinden sich auf der dem Fensterrahmen zugewandten Oberseite und das Funkmodul und die LED auf der dem Raum zugewandten Unterseite. Ich habe in China bestellt, mich in einem herkömmlichen Küchenofen (oberste Schicht) und einem Haartrockner (unterste Schicht) verlötet.
Das Funkmodul benötigt eine Antenne. Dies ist nur ein 164 mm langes Stück Draht.
Nach der Installation muss jeder Sensor programmiert werden, für den ein SWD-Anschluss bereitgestellt wird. Die verbleibenden Kontakte habe ich für mögliche zukünftige Experimente an der Tafel gelassen.
Die Firmware ist in C ++ geschrieben, ein Teil des Codes wird in ziemlich universellen Basisklassen ausgeführt, die Aufrufe an die ST HAL-Bibliothek kapseln. Der Quellcode
ist hier . Für die Entwicklung wurde die System Workbench für STM32 verwendet. Die Größe der endgültigen binären Firmwaredatei beträgt 22 kB.
Und hier ist der Sensor im Fall:
Abhängig von der Position des Sensors habe ich bei einigen Sensoren die Antenne draußen gelassen (vor dem Hintergrund des weißen Rahmens ist sie jedoch nicht sichtbar), und bei einigen Sensoren habe ich den Draht in den Rahmen gebogen und ihn vollständig in das Gehäuse gepfercht.
Aus Gründen des Interesses habe ich die Kosten der Komponenten für einen Sensor berechnet (zu den Preisen des Mouser-Katalogs, Preis und Gesamtpreis in Euro)
| Artikel | Beschreibung | Wert | MOUSER-Nummer | Menge | Kosten |
| IC3 | Exklusives ODER | 1G86 | 771-74AUP1G86GW-G | 1 | 0,254 |
| IC1 | Mikrocontroller | STM32L051 | 511-STM32L051K6T6 | 1 | 2.14 |
| SV1 | Stecker | 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 | Magnetischer Kontakt | ORD211-0810 | 876-ORD211-0810 | 1 | 0,625 |
| IC2 | RFM69HCW Funkmodul | RFM69HCW | 474-COM-13910 | 1 | 5,36 |
| C1, C2, C3, C6 | SMD-Kondensator | 0,1 uF | 80-C0805C104J5RAC | 4 | 0,1 |
| C5 | SMD-Kondensator | 0,4 nF | C0805C471K8HACTU | 1 | 0,021 |
| C4 | SMD-Kondensator (Tantal) | 47uF | 581-TAJR225K016RNJ | 1 | 0,334 |
| R1 | SMD-Widerstand | 10K | 660-RK73H2ATTDD1002F | 1 | 0,01 |
| R10 | SMD-Widerstand | 330 | 660-RK73H2ATTDD3300F | 1 | 0,01 |
| R3, R4, R6, R7, R8, R11 | SMD-Widerstand | 47K | 660-RK73H2ATTDD4702F | 6 | 0,06 |
| R5 | SMD-Widerstand | 56 | 660-RK73H2ATTD56R0F | 1 | 0,013 |
| R9 | SMD-Widerstand | 56M | 603-RC0805JR-0756ML | 1 | 0,037 |
| | | | | 9.748 |
Übrigens ist es genau dreimal billiger als der ursprüngliche zWave-Sensor. Dies ist zwar nur die Kosten für Teile ohne den Fall. Aber meiner Meinung nach sind zWave-Sensoren im Einzelhandel zu teuer.
Netzwerkcontroller
Für den Controller wurden das gleiche Funkmodul und der gleiche Mikrocontroller wie für die Sensoren verwendet. Dadurch konnte der größte Teil des Firmware-Codes wiederverwendet werden. Für den Controller habe ich diesen Formfaktor des Boards gewählt, um das fertige Gehäuse von Raspberry Pi zu verwenden. Im Vergleich zum Sensor wurden ein externer Antennenanschluss und eine USB-Schleife basierend auf dem FT232RL und dem SI-8621-Isolator hinzugefügt. Stattdessen könnte man natürlich STM32 mit USB an Bord nehmen. Aber dann müsste man erstens den Firmware-Code trennen und zweitens die Software-Implementierung von USB selbst durchführen. Die Option mit einem externen FT232RL ist zwar teurer, aber zuverlässiger und schneller zu implementieren. Das Ergebnis ist das
folgende Schema :
Und in zusammengesetzter Form stellte sich Folgendes heraus:
Der Mikrocontroller geht hier nicht in den Ruhezustand, das Funkmodul arbeitet für den Empfang, aber nachdem ein Paket von einem der Sensoren erfolgreich empfangen wurde, wechselt das Modul in den Sendemodus und sendet eine Bestätigung. Darüber hinaus wird jedes erfolgreich empfangene Paket über USB an den Server übertragen. Das Paketformat ist eine Folge von Werten, die durch das Symbol „;“ getrennt sind:
GW; 3; 12; -57; 0; 146; 30; 18
wo:
- erste Stelle ist der Paketaufkleber (immer "GW")
- zweite Position - Datentyp (Sensorstatus oder Fehlercode)
- dritte Position - Sensornummer
- vierte Position - Signalqualität auf der Seite des Netzwerkcontrollers (RFM69HCW erhält die Signalqualität während des Empfangs und ermöglicht es Ihnen, sie abzufragen, wenn der Empfang beendet ist)
- fünfte Position - Fensterzustand (0 offen, 1 geschlossen)
- sechste Position - eine eindeutige Nummer des Pakets (Ereignisses) vom Sensor. Mit dieser Nummer können Sie serverseitig steuern, ob alle Ereignisse vom Server empfangen wurden oder ein oder mehrere Ereignisse verloren gingen.
- siebte Position - aktuelle Batteriespannung (30 entspricht 3,0 V)
- Die letzte, achte Position ist die Temperatur vom internen Sensor des Mikrocontrollers. Ich habe noch nicht herausgefunden, wie man es benutzt
Der Quellcode für die Firmware befindet sich
an derselben Stelle wie für den Sensor . Sie haben eine gemeinsame Hauptdatei und eine gemeinsame Bibliothek von Basisklassen. Die Firmware-Option (Sensor oder Controller) wird mithilfe der Direktive define in der Datei main.cpp ausgewählt.
Die Kosten für den Netzwerkcontroller sind aufgrund der USB-Schaltung, der Antenne und zusätzlicher Anschlüsse höher. Dieser Zusatz kann aber vernachlässigt werden, da es nur einen Regler gibt. Aber auch mit dieser Ergänzung stellte sich heraus, dass es dreimal billiger ist als der zWave-Stick, der zuvor an seiner Stelle stand.
Servermodul
Der Netzwerkcontroller ist mit einem Server verbunden, auf dem CentOS 7 ausgeführt wird. Auf dem Server wird ein in Java geschriebenes Programm ausgeführt. Und in seiner Struktur, in seiner Implementierung und in seinen Aufgaben ist das Programm recht einfach:
- Mit einer sehr alten und anscheinend nicht mehr unterstützten RxTx- Bibliothek wird der in der Konfiguration angegebene USB-Port überwacht (in meinem Fall / dev / ttyUSB0). Derzeit ist dies der am schlechtesten optimierte Teil des Gesamtsystems, da die Bibliothek den Serverprozessor stark belastet.
- Wenn Daten vom USB-Anschluss empfangen werden, werden sie in einer Protokolldatei aufgezeichnet und in der Sensorstatusklasse gespeichert. Wenn Sie den Server neu starten, geht der Status verloren. Um es wiederherzustellen, müssen Sie um das Haus herumgehen und alle Fenster manuell öffnen und schließen. Dies ist wahrscheinlich der größte Nachteil meines Systems, aber ich habe mich ganz bewusst geweigert, regelmäßig Sensoren abzufragen, um die Batterien zu schonen.
- Die Anwendung ist auch ein kleiner TCP / IP-Server und überwacht den in der Konfiguration angegebenen TCP / IP-Port. An diesem Port können Verbindungen von einem mobilen Client akzeptiert werden.
- Wenn der mobile Client eine Verbindung zum Server herstellt, sendet er den aktuellen Status aller Sensoren. Mit Hilfe von periodischen Heartbit-Nachrichten überwacht der Server auch die Aktivität der Verbindung.
- Der Server und der mobile Client tauschen Nachrichten im XML-Format aus. Diese Nachrichten werden in Form einer kleinen Java-Bibliothek implementiert, die sowohl auf der Serverseite als auch auf der Seite der mobilen Android-Anwendung gemeinsam genutzt wird.
- Obwohl dies aus Gründen des Interesses nicht sehr sinnvoll ist, habe ich die Funktion der Autorisierung eines mobilen Clients über IMEI sowie die AES-Verschlüsselung von Nachrichten zwischen dem Server und dem Client mithilfe eines im Quellcode eingenähten Schlüssels (Java-Paket javax.crypto) hinzugefügt. Dies ist jedoch rein experimentell, da der TCP / IP-Port dieses Servermoduls nur vom internen Netzwerk aus zugänglich und von außen nicht sichtbar ist. Obwohl, wenn ich diesen Hafen für die große Welt öffnen möchte, wird es jetzt nicht mehr so beängstigend sein, es zu tun.
Wen kümmert es, der Quellcode des Servermoduls ist
hier .
Mobiler Client (Android-Anwendung)
Sie werden hier nicht viel schreiben, obwohl diese Anwendung das Endergebnis des gesamten Projekts ist. Dies ist eine standardmäßige und sehr einfache Java-Anwendung mit drei Registerkarten: dem Zustand der Fenster im ersten Stock, dem Zustand im zweiten Stock und einer kleinen Telemetrie des Servers (siehe den
Quellcode hier ):
Die Grafiken basieren auf einer Reihe von SVG-Dateien, die je nach Zustand der Sensoren übereinander gestapelt sind. Ein langes Drücken wird im Bereich jedes Fensters unterstützt. Danach wird ein Hinweis mit der Uhrzeit angezeigt, zu der dieses Fenster geöffnet war:
Grundsätzlich hindert Sie nichts daran, diesem Tooltipp ein Batteriesymbol hinzuzufügen, aber Ihre Hände haben es noch nicht erreicht.
Betriebserfahrung
"Jedes Niesen" wird in einer Protokolldatei auf der Serverseite aufgezeichnet. Die Analyse dieser Dateien in den letzten 5 Monaten ermöglicht es uns, die Funktionsweise dieses Systems etwas detaillierter zu verstehen.
Die Analyse ist sehr einfach - sehen Sie sich einfach den Ordner mit den Protokolldateien auf dem Server an.
Wie viele Fehler gab es bei der Datenübertragung auf dem Funkkanal? Innerhalb von 5 Monaten wurden 8 Fehler aufgezeichnet, wenn die Nachricht in der falschen Größe und 25 Fehler in der falschen CRC empfangen wurden. In beiden Fällen können Sie nicht direkt sagen, welcher Sensor Probleme hatte, da das Datenpaket in diesem Fall vollständig beschädigt ist. Da der Netzwerkcontroller in all diesen Fällen den Datenempfang nicht bestätigt, sollte der Sensor die Daten auf eine neue Weise senden, wodurch diese Fehler in den meisten Fällen behoben werden.
Und hier ist eine Übersichtstabelle über den Betrieb von Sensoren für 5 Monate.
| Boden | Sensor | Menge
Von Ereignissen | Von den Verlorenen
Von Ereignissen | Spannung
Batterien | Median
Macht
Signal |
| 1 | 10 | 105 | 0 | 3.1 | -66 |
| 1 | 11 | 52 | 0 | 3.3 | -70 |
| 1 | 12 | 122 | 0 | 3.3 | -61 |
| 1 | 13 | 89 | 0 | 3.3 | -74 |
| 1 | 14 | 2573 | 0 | 3.3 | -68 |
| 1 | 15 | 261 | 0 | 3.3 | -60 |
| 1 | 16 | 543 | 2 | 3.3 | -70 |
| 1 | 17 | 156 | 2 | 3.3 | -74 |
| 1 | 18 | 177 | 2 | 3.2 | -68 |
| 1 | 19 | 384 | 3 | 3.3 | -56 |
| 2 | 3 | 368 | 2 | 3.3 | -62 |
| 2 | 4 | 86 | 0 | 3.3 | -71 |
| 2 | 5 | 521 | 2 | 3.3 | -59 |
| 2 | 6 | 115 | 0 | 3.3 | -62 |
| 2 | 7 | 316 | 2 | 3.3 | -63 |
| 2 | 8 | 419 | 1 | 3.3 | -60 |
| 2 | 9 | 89 | 0 | 3.3 | -68 |
Sensor Nr. 10 friert einmal ein. Dies führte anscheinend zu einer signifikanten Abnahme der Batteriespannung. Der Grund für das Einfrieren ist noch nicht klar. Es hängt wieder, du musst es herausfinden.
Der Sensor Nr. 14 ist an der Vordertür installiert, weshalb er so viele Reaktionen hat. Eine derart große Anzahl von Fahrten hat die Batteriespannung jedoch noch nicht beeinflusst.
Ein verlorenes Ereignis liegt vor, wenn der Sensor versucht hat, einen Status zu senden, der Server dies jedoch nicht bestätigt hat. Alle verlorenen Ereignisse sind darauf zurückzuführen, dass ich den Server für etwa einen halben Tag zum Reinigen ausgeschaltet habe.
In der Spalte Median Signal Strength Median wird der Median-RSSI-Wert (in dBm) angezeigt, bei dem jeder einzelne Wert nach dem Empfang jedes Pakets ermittelt wird. Der Sensor mit dem besten Signal (Nr. 19, -56 dBm) befindet sich in einer Entfernung von 2 Metern in direkter Sichtweite zum Netzwerkcontroller. Die Antenne in diesem Sensor ist jedoch mit einem Rahmen im Inneren des Gehäuses gefaltet. Der Netzwerkcontroller selbst befindet sich im Erdgeschoss. Das Signal von den Sensoren im zweiten Stock ist jedoch sehr gut. Dies ist darauf zurückzuführen, dass bei allen Sensoren der zweiten Etage die Antenne aus dem Sensorgehäuse entfernt ist.
Anstelle eines Nachwortes
Einerseits bin ich froh, dass ich als Hobby von Grund auf ein System dieses Niveaus entwerfen, zusammenbauen und betreiben konnte. Und umso mehr freut es mich, dass es besser funktioniert als das "proprietäre" System, das auf der zWave-Hype-Technologie basiert. Es gibt auch Raum für die Entwicklung und Verbesserung dieses Systems. Ich nage nur einen kleinen Zweifel. Das heißt, dass ein Mensch ohne spezielle elektrische Ausbildung etwas auf seinem Knie sammelt, das zuverlässiger funktioniert als Markenprodukte, die in engen Kreisen von IOT-Marken bekannt sind. Wahrscheinlich hat sich der Fortschritt in die falsche Richtung gedreht.