Hack: Eine IP-Türsprechstelle mit FHEM verknüpfen

Im folgenden Hack beschreibt der Autor Peter A. Henning, wie man mit Hilfe der DoorPi-Software auf Basis eines Raspberry Pi eine IP-Türsprechstelle baut und in FHEM* integriert. Der Hack entstammt diesmal nicht aus seinem Buch “SmartHome Hacks”, sondern wurde bereits hier veröffentlicht. Wir danken Peter A. Henning, dass wir ihn an dieser Stelle re-bloggen dürfen. Weitere Probehacks (die dann auch wirklich aus “SmartHome Hacks” stammen) findet Ihr hier und hier und hier

*Weitere Bestandteile des Gesamtsystems sind ein Garagentoröffner und eine Hoftür mit selbstverriegelndem Panikschloss. Zur Beschreibung der beiden letztgenannten Teilprojekte verweise ich auf das Buch Smart Home Hacks.

Eine IP-Türsprechstelle mit FHEM verknüpfen

Funktion

Die Software DoorPi läuft auf einem Raspberry Pi und stellt einen IP-Phone-Client zur Verfügung, der in eine IP-Haustelefonanlage (z.B. mit der FritzBox) eingebunden werden kann. Diesen Raspberry Pi könnte man zwar über längere Audiokabel mit der notwendigen Lautsprecher-Mikrofon-Kombination verbinden, das ist allerdings etwas anfällig für Störsignale. Die meisten Anwender von DoorPi wählen deshalb den Einbau des Raspberry Pi direkt an der Türsprechstelle. Aus Sicht des Autors stellt das eine Sicherheitslücke dar – weil ein direkter Zugang ins Heimnetz außerhalb der eigenen vier Wände geschaffen würde.

Hier soll deshalb eine abgesetzte Installation beschrieben werden: Außen an der Türsprechstelle sitzen nur Sensoren, Audiohardware und ein Display, angesteuert von einem “dummen” Arduino Mikrocontroller. Ins Innere des Hauses führen drei Kabel:

  • Ein USB-Kabel zur digitalen Ankopplung der Audio-Hardware an den Raspberry Pi
  • Ein HDMI-Kabel zur digitalen Ankopplung einer Kamera an den Raspberry Pi
  • Ein 8-adriges Kabel zur Weiterleitung verschiedener Signale an den Raspberry Pi. Hierfür kann man aus Bequemlichkeitsgründen ein Netzwerk-Patchkabel verwenden – hochfrequente Signale gehen allerdings nicht über diesen Weg.
Plan einer IP-Türsprechanlage.
Bitte klicken Sie das Bild, um eine größere Darstellung zu erhalten.

 

Außenansicht der IP-Türsprechstelle
IP-Türsprechstelle, Außenansicht

Klingel und Türsprechstelle

Beim Drücken auf den Klingelknopf wird ein IP-Telefonanruf gestartet – entweder bei einer internen Nummer, oder (per Mausklick auswählbar in FHEM) bei einer beliebigen anderen Nummer. Wenn der Empfänger den Ruf annimmt, kann er mit dem Besucher sprechen und ggf. durch das Drücken einer Taste die Tür öffnen. Es ist in der DoorPi-Installation problemlos konfigurierbar, beliebige andere Aktionen zu starten – z.B. könnte man dem Paketlieferanten nur das Gartentor öffnen.

Kamerasicht der IP-TürsprechanlageWährend des Klingelvorgangs wird mit einem Weitwinkelobjektiv eine Aufnahme des Besuchers angefertigt. Während der Aufnahme wird eine Infrarot-Lichtquelle eingeschaltet. Diese soll nicht die ganze Szene ausleuchten – sondern verhindern, dass man das Gesicht des Besuchers auf Grund einer hinter ihm befindlichen Beleuchtung mit sichtbarem Licht nicht gut erkennen kann. Die Infrarotempfindlichkeit der Kamera sorgt bei Tageslicht für einen Rotstich des Bildes. Die URL dieses Schnappschusses wird ferner im DoorPi-Device als Reading snapshot angezeigt, sowie ein Event <DoorPi-Device> snapshot: URL ausgelöst, mit dem man weitere Aktionen triggern kann. Beispielsweise wird eine Push-Nachricht an ein Tablet gesendet, das den Klingelnden für eine Minute als Bild anzeigt.

Das Gespräch wird als WAV-Datei ebenfalls aufgezeichnet, diese ist ebenso wie die Bilddatei aus dem FHEM-Frontend abrufbar.

Türöffnung

Das System verfügt über einen iButton-Reader. Legt man einen iButton auf, der in der Arduino-Software codiert ist, leuchtet eine im Reader integrierte Tricolor-LED in einer entsprechenden Farbe auf (z.B. roter iButton-Halter => rote LED). Der weitere Ablauf hängt vom Schließzustand der Haustür ab.

  • Ist die Haustür nur zugezogen und nicht abgeschlossen (Zustand hardlock=off), wird sie geöffnet. Gleichzeitig wird über die Türsprechstelle die Stimmnachricht ausgegeben “Willkommen zu Hause !”, und auf einem im Haus befindlichen Tablet angesagt “Ein Bewohner betritt das Haus.”
  • Ist die Haustür abgeschlossen (Zustand hardlock=on), wird zunächst auf dem Touchscreen des Systems statt der Namen eine virtuelle Tastatur angezeigt. Hier kann ggf. noch die akustische Bitte eingebaut werden, eine fünfstellige PIN einzugeben. Der Fortschritt bei der Eingabe wird durch einen Balken angezeigt.
    • Ist die PIN falsch, geht das System wieder in den Ausgangszustand zurück, es wird eine Warnungsmeldung an das interne FHEM-System übermittelt.
    • Ist die PIN korrekt, wird zunächst der Entriegelungsvorgang der Tür eingeleitet. Je nach verwendetem System kann das eine Weile dauern – Keymatic ist hierfür ein Beispiel, das können durchaus 3-4 Sekunden werden. Danach wird die Tür geöffnet, gleichzeitig wird über die Türsprechstelle die Stimmnachricht ausgegeben “Willkommen zu Hause!”, und auf einem im Haus befindlichen Tablet angesagt “Ein Bewohner betritt das Haus.” Je nach Konfiguration kann FHEM an dieser Stelle auch weitere Aktionen auslösen – etwa weitere Entriegelungsvorgänge starten.

Verwendung des Hausschlüssels

  • Verriegelt man die Haustür mit einem gewöhnlichen mechanischen Schlüssel, teilt dies die Keymatic dem FHEM-System mit (Zustand hardlock=on), das FHEM-System informiert den DoorPi-Rechner.
  • Entriegelt man die Haustür mit einem gewöhnlichen mechanischen Schlüssel, teilt dies die Keymatic dem FHEM-System mit (Zustand hardlock=off), das FHEM-System informiert den DoorPi-Rechner.

Fernbedienung

Alle Funktionen, z.B. die Ent- und Verriegelung und das Türöffnen sind selbstverständlich auch über FHEM (und damit über ein Funksystem, im konkreten Fall über HomeMatic) steuerbar.

Videostream

Auf dem Raspberry Pi ist auch die Software mjpeg_streamer installiert, Per Mausklick in der FHEM-Oberfläche wird mjpeg-streamer gestartet und gestoppt (das wird von der DoorPi-Software erledigt, die einen bestimmten virtuellen Tastendruck erkennt und dann lokal ein Skript startet), und stellt dann an TCP-Port 9000 einen Videostream bereit. Wer möchte, kann das System auch so konfigurieren, dass es diesen Videostream zusammen mit dem Audiostream zur Videotelefonie verwendet.

Bewegungserkennung und Helligkeitsmessung

Erkennt das System durch den eingebauten PIR-Bewegungsmelder eine Bewegung, wird

  • die Anzeigehelligkeit für mindestens eine Minute hochgefahren
  • ein Signal an FHEM gesendet.

Wenn eine Minute keine Bewegung erkannt wurde, geht die Anzeigehelligkeit (d.h. vom Display und dem LED-Ring um den Klingelknopf) wieder auf einen Wert zurück, der durch die externe Helligkeit bestimmt ist.

Der Bewegungsmelder ist so geschaltet, dass er innerhalb von ca. 1 Minute (tatsächlich sind es mit der unten geposteten Schaltung 47 Sekunden), gerechnet von der letzten erkannten Bewegung, keine neuen Bewegungsmeldungen weiterleitet – sondern die Zeitdauer einfach verlängert (retriggerbares Monoflop).

Hardware

Arbeitsaufwand und Kosten

In der Zeit von Juni – September 2016 habe ich ca. 150 Arbeitsstunden für Konzeption, Prototyp und Programmierung sowie die Endmontage aufgewandt. Auf Grund der Tatsache, dass sowohl meine 3D-Druckdateien, als auch die Programmbestandteile hier frei verfügbar sind, kann man das sicher in weniger als der halben Zeit nachbauen.

Die reinen Materialkosten betragen etwa 450 €, davon ca. 100 € für einen Raspberry Pi 3 mit Zubehör und Zusatzplatine PiFace 2, ca. 70 € für das Infrarot-Kamerasystem, ca. 40 € für das reine Audio-System, ca. 50 € für Bewegungsmelder, Helligkeitssensor und beleuchteten Klingelknopf. Der zusätzliche Controller vom Typ Arduino Micro und der angeschlossene iButton-Leser schlagen mit insgesamt 20 € zu Buche, das Nextion-Touchscreen mit ca. 30 €. Teuerstes Einzelstück war eine nach Maß gefräste und gebohrte Frontplatte mit ca. 100 €, entsprechende Wandeinbaugehäuse gibt es ab ca. 20 €. Da das Gesamtsystem modular aufgebaut ist, und Komponenten auch in ganz unterschiedlichen Qualitäten verwendet worden sind, kann man eine abgespeckte Version auch schon für ca. 200 € realisieren.

Raspberry Pi

Verwendet wird

  • ein Raspberry Pi 3, der ein integriertes WLAN-Modul besitzt. Falls man seiner eigenen WLAN-Bandbreite nicht traut: Für ca. 25 € bekommt man einen Satz Powerline-Adapter, mit denen man eine sehr stabile Verbindung zwischen dem Raspberry Pi (Innenwand nmeben der Tür) und dem Rest des Hauses aufbauen kann.
  • eine Zusatzkarte PiFace 2, mit je 8 digitalen Ein- und Ausgängen.
  • ein klares Gehäuse, das die Erweiterungskarte mit aufnehmen kann.

Das Gehäuse mit Raspberry Pi, ein Netzschalter, ein 5V Netzteil und ein Powerline-Adapter wurden in ein kompaktes Hutschienengehäude montiert, das durch einen Mauerdurchbruch (ca. 3cm Durchmesser wegen der HDMI-Stecker, siehe dort) mit der außenliegenden Türsprechstelle verbunden ist.

Kamera-Subsystem

Verwendet werden hierfür

  • eine Standard-NoIR-Kamera für den Raspberry Pi (ohne Infrarotfilter, somit IR-empfindlich, z.B. erhältlich hier)
  • ein Fisheye 180° zum Aufclippen auf Smartphones. Die untenstehenden Stereo-Litografie-Dateien sind für das Objektiv von Bresser entworfen worden, auch erhältlich hier.
  • eine Acrylglaskuppel 2 Zoll (Achtung, der Durchmesser beträgt 49,5 mm).
  • eine Kabelverlängerung Flatribbon <-> HDMI <-> Flatribbon.

Tipp: HDMI-Stecker sind ziemlich dick und passen eher schlecht durch enge Kabelkanäle. Hat man dieses Problem, kann man noch an einer Seite einen Adapter HDMI <-> Mini-HDMI einsetzen und ein entsprechendes Kabel mit deutlich dünnerem Mini-HDMI-Stecker vewenden.

  • ein Kameradom aus dem 3D-Drucker mit genauer Passung für das Fisheye vorne und die Kamera hinten, sowie Passungen für 8 LED. Die STL-Datei für diesen Kameradom findet man hier:PiCameraDome4
  • eine Rückseite des Kameradoms aus dem 3D-Drucker, wird hinten mittig aufgeklebt und hält den Deckel des Kamerasystem durch drei Nippel. Die STL-Datei dafür findet man hierPiCameraDome4addendum
  • ein Deckel des Kameradoms aus dem 3D-Drucker, wird auf die Rückseite aufgesteckt und beinhaltet zwei Halterungen für Mikrofone (die “Ohren” im Bild). Die STL-Datei dafür findet man hierPiCameraDome4back
  • 9 x IR-LED TSAL 6200 mit hoher Leistung
  • 3 Widerstände 10 Ohm 0,2 W.
Kamera-Subsystem mit Fisheye-180°-Dom.
Kamera-Subsystem mit Fisheye-180°-Dom.
Bild: (c) Prof. Dr. Peter A. Henning

Zur Montage werden vier M2-Gewindebolzen in die hintere Aussparung des Kameradoms eingeklebt, und auf diese mit entsprechenden Abstandshaltern und Muttern sowohl die Kamera, als auch die eine Hälfte der Kabelverlängerung geschraubt. Dabei empfiehlt es sich, die LED vorher an Ort und Stelle zu haben – ggf. muss bei ungünstiger Klebung der Gewindebolzen bei den Eck-LED ein Gehäusevorsprung etwas abgefeilt werden.

Die Schaltung der LED für dem Betrieb an einer Spannung von 5V ausgelegt – damit fließen durch drei in Reihe geschaltete LED und einen 10 Ohm-Widerstand ziemlich genau 100mA. Bei der Schaltung über einen MOSFET ist das etwas weniger, wegen des Drain-Source-Widerstandes des MOSFET, reicht aber für die notwendige Helligkeit aus. Aus Symmetriegründen werden drei solche Stränge (insgesamt 9 LED) montiert – aber nur 8 davon sind bei dem angegebenen Kameradom nach außen gerichtet (wer möchte, kann gerne ein 3D-Design mit 9 Löchern erstellen), eine LED zeigt also nutzlos nach innen (erkennbar im 3. Bild der obigen Reihe).

Das Fischaugenobjektiv wird mit wenig (!) klarem Silikon in die vordere Öffnung des Kameradoms geklebt, der rückwärtige Aufsatz mit den 3 Nippeln mit Zweikomponentenkleber auf der Rückseite des Kameradoms befestigt. Dabei zur Ausrichtung den Mikrofonhalter (rechtes Bild, mit den “Ohren”) probeweise aufstecken.

Die Acrylglaskuppel wird mit Silikon oder einem äquivalenten Dichtmaterial wasserdicht in die Frontplatte eingesetzt, auf diese dann von hinten der Kameradom. Eine staubdichte Verbindung erfordert auch hier die Abdichtung mit Silikon. Für den Fall einer möglichen Demontage empfiehlt es sich, diese Abdichtung nicht als Klebung zu verwenden, sondern als umlaufenden Rand nachträglich aufzubringen – der ist dann einfach mit einem Cutter zu entfernen.

Audio-Subsystem

  • Als Sound”karte” wird mit dem BIGtec 7.1 USB Adapter ein preiswertes Produkt verwendet, dessen Gehäuse sich probemlos entfernen lässt. Weitere Modelle werden im oben zitierten DoorPi-Forum empfohlen.
  • Der Audioverstärker ist ein Modell von Foxnovo mit einer Ausgangsleistung von 2×3 W. Auch hierfür können nahezu beliebige andere Modelle vewendet werden
  • Als Lautsprecher kommen zwei VISATON Kleinlautsprecher VIS K28.40-8 mit den Maßen 2,8 x 4 cm und einer Impedanz von 8 Ohm zum Einsatz. Zwischen Lautsprecher und Frontlatte ist ein Lautsprechervlies angebracht – damit ergibt sich ein effektiver Spritzwasserschutz, allerdings keine vollständige Abdichtung gegen Feuchtigkeit. Betriebserfahrungen liegen noch nicht vor !
  • Als Mikrofon können nahezu beliebige preiswerte Mikrofonkapseln für Sprachqualität verwendet werden. Bei diesen handelt es in der Regel um Kristallmikrofone, die einen ausreichenden Spannungspegel für den Audioverstärker erzeugen. Wichtig ist die gute akustische Entkopplung von Lautsprechern und Mikrofonen – darum werden die Lautsprecher fest auf die Frontplatte geschraubt, die Mikrofone aber in den Halter am Kameradom von hinten eingeschoben. Eine Fixierung der Mikrofone mit dem bereits vorher verwendeten Silikon ist empfehlenswert, ebenso eine Vliesschicht zwischen Mikrofon und Frontplatte.

Steckkontakte aller Art sind bei Installationen im Außenbereich immer ein Risiko. Für das gegenwärtige Projekt wurden deshalb das Gehäuse der Sound”karte” und die enthaltenen 3,5 mm Klinkenbuchsen entfernt. Zwei Mikrofonkabel wurden direkt angelötet, die Ausgänge per Draht mit der Verstärkerplatine verbunden, deren Ausgänge wiederum mit Schraubklemmen versehen. Etwas Zweikomponentenkleber macht daraus eine kompakte Einheit, die oberhalb des Displays auf einer Lochrasterplatte befestigt und per USB-Kabel mit dem Raspberry Pi verbunden wird.

Der verwendete Verstärker hat einen Schalteingang (weißes Kabel im Bild) – wird dieser auf Low=GND gesetzt, ist der Verstärker ausgeschaltet und verbraucht keinen Strom. Dieser Schalteingang wird auf den Ausgang DLA der Arduino-Platine geführt.

Audio-Subsystem
Das Audio-Subsystem. Bild: (c) Prof. Dr. Peter A. Henning

Sensoren

  • Der PIR-Bewegungsmelder ist ein sehr kleines Modul, das einfach von hinten in eine Bohrung der Frontplatte gesteckt wird. Sein Open-Collector-Ausgang muss noch mit einem retriggerbaren Monoflop = Timer versehen werden. Damit ist sichergestellt, dass erneute Triggervorgänge nicht neue Events in Doorpi bzw. FHEM auslösen. Hierfür gibt es zwei Möglichkeiten:
    • Bausatz PIR13TM, seit kurzem erhältlich bei ELV. Kleine Zusatzplatine, die auf das Bewegungsmeldermodul aufgesteckt wird.
    • Eigenbau auf Basis des LM555, siehe Schaltplan unten. Innerhalb einer Zeit von ca. 50 Sekunden (bestimmt durch R8 und C2) wird kein neuer Impuls ausgelöst. Der Ausgang des LM555 wird durch einen MOSFET invertiert und dann über eine der unbenutzten Adern (blau im Bild) des HDMI-Kabels an den Raspberry Pi weitergeleitet. Achtung: Dieses Monoflop sitzt auf einer kleinen Zusatzplatine, die im rechten unteren Bild noch nicht aufgesteckt ist.
  • Ein Fototransistor wird mit zwei festen und einem einstellbaren Widerstand als Helligkeitssensor verwendet. Seine Ausgangsspannung wird an den Arduino weitergeleitet, der auf Grund dieses Wertes das Display und den LED-Ring des Klingelknopfes dimmt.
  • Als Klingelknopf wird ein Modell aus Edelstahl mit umlaufendem LED-Ring verwendet.
  • Ein Mikroschalter dient als Sabotagekontakt, der so in die Rückwandinstallation geklebt wird, dass er bei der Abnahme der Frontplatte geschlossen wird. Dieses Signal wird über eine der unbenutzten Adern des HDMI-Kabels (orange im Bild) an den Raspberry Pi weitergeleitet.
Schaltplan Audiosystem
Schaltplan. Bitte klickt auf das Bild, um eine vergrößerte Darstellung zu sehen. Bild: (c) Prof. Dr. Peter A. Henning

 

Bild: (c) Prof. Dr. Peter A. Henning
Bild: (c) Prof. Dr. Peter A. Henning

Arduino

Verwendet wird ein Arduino Micro mit dem Programm (Sketch in der Arduino-Terminologie), das weiter unten veröffentlicht ist. Der Arduino sitzt in einer Fassung auf einer Lochrasterplatte, die hinter dem Nextion-Display befestigt ist.

Hauptaufgabe des Arduino ist, in dem iButton-Reader einen Abfragezyklus von 250 ms durchzuführen. Solche hohen Abfrageraten können in der Regel mit Busmastern, die von einer universellen 1-Wire Software wie OWX oder OWFS angesteuert werden, nicht realisiert werden. Im vorliegenden Projekt übernimmt der Arduino auch die Steuerung des Nextion-Displays über eine seiner seriellen Schnittstellen.

Nextion-Subsystem

Als interaktives Namensschild wird ein Nextion Display 3,2″ mit einer Auflösung von 400×240 Pixel verwendet (erhältlich in China oder in Deutschland).

Die Besonderheit dieses Displays ist der eingebaute Prozessor. Mit Hilfe der zugehörigen Software (erhältlich für Windows auf den Seiten des Herstellers) kann man diesem Prozessor ein regelrechtes GUI (Graphical User Interface) einprogrammieren: Bilder, Texte, Buttons, Fortschrittsbalken, aktive Regionen werden zusammengestellt und können mit Hilfe der entsprechenden Softwarebibliotheken abgerufen werden, wenn sie erst einmal im internen Flash-Memory gespeichert sind. Für diese Zusammenstellung eines Ablaufes stellt der Nextion-Editor auch einen komfortablen Emulator zur Verfügung, mit dem man den Ablauf vor dem Upload ausprobieren kann.

Der Upload auf das Nextion-Display geschieht entweder über die eingebaute serielle Schnittstelle (via USB-Seriell-Adapter für ca. 5 € auch an USB anzuschließen), oder indem mit Hilfe des Nextion Editors eine Micro-SD-Karte beschrieben und in den Kartenslot des Displays gesteckt wird (unten im Bild). Die Ansteuerung des Displays geschieht ebenfalls über die diese serielle Schnittstelle (rechts im Bild).

Zum Schutz des Nextion empfiehlt sich seine Montage an der Frontplatte mit einer entsprechenden Schutzfolie. Diese Folie kann man Rand etwas überstehen lassen und dort mit Silikon gegen die Frontplatte abdichten.

doorpi_displays
Bau des Displays der IP-Türsprechstelle.  Bild: (c) Prof. Dr. Peter A. Henning

iButton-Subsystem

iButtons sind kompakte Knöpfe aus Stahl, in denen ein Chip mit einer eindeutigen ID sitzt. Durch Auflegen des iButtons auf das Lesegerät wird diese ausgelesen und mit den einprogrammierten IDs verglichen.

Mehr über die Technik der iButtons erfährt man in der | Katgeorie 1-Wire. Achtung: iButtons sind nicht fälschungssicher. Was aber manche Hotels nicht abhält, ihren Gästen als Zimmerschlüssel einen iButton auszuhändigen…

Frontplatte

Die Frontplatte besteht aus 4 mm starken Aluminium, eloxiert und auf 1/10 mm genau mit den passenden Bohrungen und Ausschnitten sowie rückseitig angeschweißten Gewindebolzen versehen. Online bestellbar z.B. bei der Schaeffer AG, für das vorliegende Exemplar wurden ca. 115 € in Rechnung gestellt. Auf Grund ihrer Stabilität dient diese Frontplatte als Baugruppenträger für die Außeninstallation.

doorpi_front
Frontplatte. Bild: (c) Prof. Dr. Peter A. Henning

Rückwandinstallation

Die Rückwandinstallation, die in des Mauerwerk eingelassen wird, kommt ebenfalls aus dem 3D-Drucker. Sie besteht aus drei Teilen mit unterschiedlicher Tiefe, um das Loch im Mauerwerk nicht zu groß werden zu lassen. Das obere und das untere Teil enthalten jeweils zwei stabile Vorsprünge mit Aussparungen, in die eine normgerechte M4-Mutter von unten genau hineinpasst. Bemerkenswert ist, dass dieses Bauteil nicht mit einer konventionellen Methode (z.B. im Spritzgussverfahren) gefertigt werden kann. Die hineingedrückten Muttern kommen damit genau hinter den äußeren Schraubenlöchern der Frontplatte zu liegen, Die Frontplatte kann dadurch mit vier (Sicherheits-)schrauben M4 passgenau auf die im Mauerwerk sitzende Rückwandinstallation geschraubt werden. Dafür werden Edelstahlschrauben mit Senkkopf und zwei Löchern auf der Oberseite verwendet (sog. Sicherheitsschrauben).

Auf der Oberkante der drei Teile verläuft eine 1×1 mm² große Nut, in die eine Dichtung eingelegt werden kann. Zur besseren Verankerung im Putz kann das zusammengeklebte Gehäuse noch mit Ohrenversehen werden – siehe die beiden letzten Links in der nachfolgenden List.

Die Bauteile der Rückwandinstallation können aus beliebigem Material gefertigt werden, aber Achtung: Druckt man sie aus dme Material PLA (Poly-Milchsäure), ist zum Schutz gegen biologischen Abbau und Depolymerisation im Mauerwerk ein (äußerer) Überzug mit Sprühlack sinnvoll.

Bauteile der Rückwandinstallation
Bauteile der Rückwandinstallation. Bitte klickt auf das Bild für eine vergrößerte Darstellung. Bild: (c) Prof. Dr. Peter A. Henning

Hier die Links zu den betreffenden Dateien: CoverBottom4 CoverMiddle4 CoverTop4 CoverEarC4 CoverEarS4

Bauteile der Rückwandinstallation
Bild: (c) Prof. Dr. Peter A. Henning

Software

Die Software besteht aus verschiedenen Bestandteilen:

  • Auf dem Nextion-Display sind so genannte Seiten mit Bildern, Texten und aktiven Elementen (Widgets) gespeichert, diese werden mit dem zugehörigen Nextion-Editor des Herstellers erzeugt und entweder über serielle Schnittstelle oder über eine Micro-SD-Karte auf das Nextion übertragen.
  • Auf dem Arduino läuft ein kleines Programm in einer Endlosschleife. Es führt die Abfrage des iButton-Lesers durch und steuert den Seitenwechel des Nextion-Displays, verarbeitet auch dessen Bedienvorgänge. Das Programm (Sketch in der Arduino-Terminologie) wird mit Hife der Arduino-Entwicklungsumgebung übersetzt und auf diesen übertragen.
  • Auf dem Raspberry Pi wird nach einer der verfügbaren Anleitungen im DoorPi-Forum die DoorPi-Software installiert und konfiguriert
  • Auf dem FHEM-System (z.B. einem weiteren Raspberry Pi) muss eine aktuelle Version von FHEM laufen.

Nextion-Subsystem

Für das hier Projekt wurden mit dem Nextion-Editor zwei Seiten erstellt (page0 und page1 genannt), die verschiedene Widgets enthalten, also bedienbare Elemente.

  • page0 ist die Default-Seite, sie zeigt die Namen der Hausbewohner. Die gesamte Fläche ist als picture mit der ID p0 deklariert. Ein weiteres kleines picture mit der ID p1 dient der Anzeige eine kleinen Schloss-Symbols
  • page1 ist das virtuelle Keyboard. Wie man in der nachstehenden Abbildung sehen kann, wurden dabei 11 verschiedene buttons definiert, nämlich b0-b9 für Ziffern und b10 als Cancel-Button. Außerdem gibt es es einen Fortschrittsbalken j0.
383px-nextion
Bild: (c) Prof. Dr. Peter A. Henning

Um die Eingabe von Ziffern über dieses Display zu verarbeiten, müssen die Button-Widgets mit Callback-Funktionen versehen werden, dies geschieht weiter unten in dem Programm des Arduino.

Die fertigen Seiten werden durch den Nextion-Editor in einer kompakten Datei zusammengefasst, die entweder per serieller Schnittstelle an das Display übertragen wird, oder auf einer Micro-SD-Karte in das Nextion gesteckt wird. Beim Einschalten des Displays wird dann diese Datei automatisch in den internen Flash-Speicher des Nextion übernommen.

Arduino

Im Projekt wurde ein Arduino Micro verwendet – nahezu jede andere Version tut es auch. Das Programm darauf ist relativ einfach und wird im Folgenden erklärt.

Zuerst gibt es ein paar Deklarationen. Insbesondere müssen die Bibliotheken für den 1-Wire Anschluss (=iButton-Reader) und das Nextion Display eingebunden werden. Achtung: in der Datei NexConfig.h muss der Wert für nexSerial auf Serial2 gesetzt werden.

[spoiler name=”Code ausklappen”]
/*----------------------------------------------------------------------------------
Haustür
Prof. Dr. Peter A. Henning, April 2016

------------------------------------------------------------------------------------*/
#include
#include
#include
#include
// Make sure that in NexConfig.h nexSerial is configured properly !
#include "Nextion.h"

[/spoiler]

Jetzt werden die Pins des Arduino ausgewählt. Außerdem wir din diesem Abschnitt die Sicherheits-PIN gesetzt, im Beispiel 12345
[spoiler name=”Code ausklappen”]
// Door Opener Subsystem
const int DoorOpen = 8; // output for door opening
const int LockState = 6; // output to indicate lock state
byte softlock = 0;
byte hardlock = 0;

// Security PIN
const int HardLock = 5; // input low = high security
String PIN = "12345";
char pin[10];
char pindigit = ' ';
byte pinctr = 0;
long pinMillis = 0;
const int WrongID = 7; // indicator for false 1-Wire ID or PIN

// process variables
const int loopLED = 13; // signal loop
byte phase = 1; // phase of test
long currentMillis = 0;

// dimming
const int Brightness = A0; // input pin for the dimming voltage
const int Movement = A1; // input for movement detection
const int DashDim = 3; // output for dimming further dashlights
const int DashlightOn = 4; // input pin for the dashlight signal
const long dimTimeout = 60000;
byte isDimmed = 0;
long dimMillis = 0; // timer
[/spoiler]

Hier folgt der Code für das iButton-System. Natürlich nicht mit meinen echten 1-Wire IDs. Wichtig ist, dass diese hier hart in den Code eingebaut werden. Das ist zwar etwas unkomfortabel, wenn man sie ändern möchte – aber sehr sicher gegen Manipulationen.

[spoiler name=”Code ausklappen”]
// 1-Wire subsystem
OneWire ds(12); // 1-Wire on pin 12 (a 4.7K resistor is necessary)
const int redLED = 11; // LED on pins 9,10,11
const int greenLED = 10;
const int blueLED = 9;

typedef struct {
char* name;
byte ROM[8];
int red;
int green;
int blue;
} iButton;

const byte iBnum = 7; // Number of defined iButtons
const iButton iButtons[] = {
{"iRed", {0x01, 0x--, 0x--, 0x--, 0x--, 0x--, 0x--, 0x--}, LOW, HIGH, HIGH},
{"iRed*", {0x01, 0x--, 0x--, 0x--, 0x--, 0x--, 0x--, 0x--}, LOW, HIGH, HIGH},
{"iGreen", {0x01, 00x--, 0x--, 0x--, 0x--, 0x--, 0x--, 0x--}, HIGH, LOW, HIGH},
{"iBlue", {0x01, 0x--, 0x--, 0x--, 0x--, 0x--, 0x--, 0x--}, HIGH, HIGH, LOW},
{"iOrange", {0x01, 0x--, 0x--, 0x--, 0x--, 0x--, 0x--, 0x--}, LOW, LOW, HIGH},
{"iPink", {0x01, 0x--, 0x--, 0x--, 0x--, 0x--, 0x--, 0x--}, LOW, HIGH, LOW},
{"iPurple", {0x01, 0x--, 0x--, 0x--, 0x--, 0x--, 0x--, 0x--}, LOW, HIGH, LOW}
};

[/spoiler]
In dieser Version des Programms gibt es auf dem Nextion-Display nur zwei Seiten, eine mit den Namen und eine mit einem Keyboard. Die Keyboard-Buttons werden hier bekannt gemacht und mit Callbacks versehen.

[spoiler name=”Code ausklappen”]
// GUI
NexPage page0 = NexPage(0, 0, "page0");
NexPage page1 = NexPage(1, 0, "page1");

NexButton p0 = NexButton(0, 1, "p0");
NexPicture p1 = NexPicture(0, 2, "p1");

NexButton num0 = NexButton(1, 11, "b0");
NexButton num1 = NexButton(1, 2, "b1");
NexButton num2 = NexButton(1, 3, "b2");
NexButton num3 = NexButton(1, 4, "b3");
NexButton num4 = NexButton(1, 5, "b4");
NexButton num5 = NexButton(1, 6, "b5");
NexButton num6 = NexButton(1, 7, "b6");
NexButton num7 = NexButton(1, 8, "b7");
NexButton num8 = NexButton(1, 9, "b8");
NexButton num9 = NexButton(1, 10, "b9");
NexButton cancel = NexButton(1, 12, "b10");
NexProgressBar progress = NexProgressBar(1, 13, "j0");

NexTouch *nex_Listen_List[] =
{
&num0, &num1, &num2, &num3, &num4,
&num5, &num6, &num7, &num8, &num9,
&cancel, &p0, NULL
};

void p0Callback(void *ptr)
{
dimLight(100);
softlock = 1;
if ( hardlock == 0) {
showLock();
}
}

void num0PushCallback(void *ptr)
{
pindigit = '0';
}

void num1PushCallback(void *ptr)
{
pindigit = '1';
}

void num2PushCallback(void *ptr)
{
pindigit = '2';
}

void num3PushCallback(void *ptr)
{
pindigit = '3';
}

void num4PushCallback(void *ptr)
{
pindigit = '4';
}

void num5PushCallback(void *ptr)
{
pindigit = '5';
}

void num6PushCallback(void *ptr)
{
pindigit = '6';
}

void num7PushCallback(void *ptr)
{
pindigit = '7';
}

void num8PushCallback(void *ptr)
{
pindigit = '8';
}

void num9PushCallback(void *ptr)
{
pindigit = '9';
}

void CancelCallback(void *ptr)
{
pinctr = 0;
progress.setValue(0);
}

[/spoiler]

Es folgt die Initialisierungsroutine:

[spoiler name=”Code ausklappen”]
void setup() {

String cmd;

// set the digital pins as output:
pinMode(redLED, OUTPUT);
pinMode(greenLED, OUTPUT);
pinMode(blueLED, OUTPUT);
pinMode(loopLED, OUTPUT);
pinMode(DoorOpen, OUTPUT);
pinMode(WrongID, OUTPUT);
pinMode(LockState, OUTPUT);
pinMode(HardLock, INPUT_PULLUP);
pinMode(DashlightOn, INPUT_PULLUP);

digitalWrite(redLED, HIGH);
digitalWrite(greenLED, HIGH);
digitalWrite(blueLED, HIGH);
digitalWrite(loopLED, LOW);
digitalWrite(DoorOpen, HIGH);
digitalWrite(WrongID, HIGH);
digitalWrite(LockState, HIGH);

// initialize the GUI
nexInit();

p0.attachPush(p0Callback, &p0);
num0.attachPush(num0PushCallback, &num0);
num1.attachPush(num1PushCallback, &num1);
num2.attachPush(num2PushCallback, &num2);
num3.attachPush(num3PushCallback, &num3);
num4.attachPush(num4PushCallback, &num4);
num5.attachPush(num5PushCallback, &num5);
num6.attachPush(num6PushCallback, &num6);
num7.attachPush(num7PushCallback, &num7);
num8.attachPush(num8PushCallback, &num8);
num9.attachPush(num9PushCallback, &num9);
cancel.attachPush(CancelCallback, &cancel);

//dimming
dimLight(100);

//showlock
if ( digitalRead(HardLock) == LOW) {
showLock();
hardlock = 1;
softlock = 0;
} else {
hideLock();
hardlock = 0;
softlock = 0;
}
}

[/spoiler]

Türöffnung -> Pin mit Name DoorOpen wird für eine Sekunde auf LOW gesetzt.

[spoiler name=”Code ausklappen”]

void openDoor(int level) {
digitalWrite(DoorOpen, LOW);
delay(1000);
digitalWrite(DoorOpen, HIGH);
}

[/spoiler]
Falsche ID -> Pin mit Name WrongID wird für eine Sekunde auf LOW gesetzt.
[spoiler name=”Code ausklappen”]
void wrongID() {
digitalWrite(WrongID, LOW);
delay(1000);
digitalWrite(WrongID, HIGH);
}

[/spoiler]
[spoiler name=”Code ausklappen”]
void showLock() {
sendCommand("vis p1,1");
}
void hideLock() {
sendCommand("vis p1,0");
}

[/spoiler]
Dimmen des Dashlight auf einen durch den Helligkeitssensor vorgegebenen Wert (Parameter level=0) oder auf einen als Parameter übergebenen Wert:
[spoiler name=”Code ausklappen”]
void dimLight(int level) {
uint16_t dimVal;
String cmd = "dim=";
// zero level - determine from lighting conditions
if ( (level == 0) && (digitalRead(DashlightOn) == HIGH) ) {
dimVal = (uint32_t) analogRead(Brightness);
dimVal = map(dimVal, 0, 1023, 0, 100);
isDimmed = 1;
// nonzero level - take as it is
} else {
dimVal = 100;
isDimmed = 0;
}
cmd += dimVal;
//dbSerialPrint(cmd);
sendCommand(cmd.c_str());
dimVal = map(dimVal, 0, 100, 0, 255);
//dbSerialPrint(" -- ");
//dbSerialPrintln(dimVal);
analogWrite(DashDim,dimVal);
dimMillis = millis();
}

[/spoiler]

Hier endlich die Schleife des Hauptprogramms:

[spoiler name=”Code ausklappen”]
void loop(void) {
byte i;
byte j;
boolean equiv;
byte iBfound;
byte present = 0;
byte addr[8];
char* device;

// new for each loop
currentMillis = millis();
digitalWrite(loopLED, HIGH);

// dimming
if ( isDimmed == 1 ) {
if ( analogRead(Movement) < 10 ) { dimLight(100); } if ( digitalRead(DashlightOn) == LOW) { //dbSerialPrintln(" DashlightOn = LOW"); dimLight(100); } } if ( (currentMillis - dimMillis) > dimTimeout) {
dimLight(0);
}

// locking
if ( digitalRead(HardLock) == LOW) {
//change display only if hardlock has changed
if ( hardlock == 0 ) {
showLock();
}
hardlock = 1;
softlock = 0;

} else {
//change display only if
if ( (hardlock == 1) && (softlock == 0)) {
hideLock();
}
hardlock = 0;
}

//lockState display
if ( (hardlock == 0) && (softlock == 0)) {
digitalWrite(LockState, HIGH);
} else {
digitalWrite(LockState, LOW);
}

//1-Wire bus access only in phase 1
if ( phase == 1) {
digitalWrite(redLED, HIGH);
digitalWrite(greenLED, HIGH);
digitalWrite(blueLED, HIGH);

if ( !ds.search(addr)) {
present = 0;
ds.reset_search();
digitalWrite(loopLED, LOW);
delay(250);

} else {
digitalWrite(loopLED, LOW);
// Invalid 1-Wire ID
if (OneWire::crc8(addr, 7) != addr[7]) {
} else {
dimLight(100);

// the first ROM byte indicates which chip
switch (addr[0]) {
case 0x01:
device = "DS2401";
present++;
for (i = 0; i < iBnum; i++) {
equiv = true;
for (j = 0; j < 7; j++) { if (iButtons[i].ROM[j] != addr[j]) { equiv = false; break; } } if (equiv ) { iBfound = i; break; } } if ( equiv ) { digitalWrite(redLED, iButtons[iBfound].red); digitalWrite(greenLED, iButtons[iBfound].green); digitalWrite(blueLED, iButtons[iBfound].blue); // LowSec state => open door
if ( (hardlock == 0) && (softlock == 0)) {
openDoor(1);
delay(4000);
return;
// HiSec state => go to phase 2
} else {
phase = 2;
pinMillis = millis();
page1.show();
return;
}
//sabotage ? Unknown iButton
} else {
digitalWrite(redLED, LOW);
digitalWrite(greenLED, LOW);
digitalWrite(blueLED, LOW);
wrongID();
}
break;
default:
device = "unknown";
break;
}
ds.reset();
}
}
}
nexLoop(nex_Listen_List);
if ( phase == 2 ) {
// check for timeout
if ( (currentMillis - pinMillis) > 30000 ) {
progress.setValue(0);
phase = 1;
pinctr = 0;
page0.show();
}
}

// phase 2 and GUI input is a number
if ( (phase == 2) && ( pindigit != ' ') ) {
// push this number to the PIN buffer
pin[pinctr] = pindigit;
pindigit = ' ';
pinctr++;
progress.setValue(pinctr * 20);
// PIN is complete
if ( pinctr == 5) {
// PIN is correct => open door
if ( String(pin) == PIN ) {
openDoor(2);
// wrong PIN
} else {
wrongID();
}
// return to phase 1
progress.setValue(0);
phase = 1;
pinctr = 0;
page0.show();
}
}
}

[/spoiler]

FHEM

Aufseiten von FHEM müssen die Perl-Module JSON und Test::JSON installiert werden. Ferner muss die Datei 70_DoorPi.pm aus dem Ordner contrib/doorpi in das Hauptverzeichnis von FHEM geschoben werden. Eine beispielhafte Konfiguration in FHEM lautet dann:

[spoiler name=”Code ausklappen”]
define A.Door.Pi DoorPi 192.168.0.YY
attr A.Door.Pi alarmDevice Sensor
attr A.Door.Pi alarmSettings alarm4,alarm5,|A.Door.Pi:.*sabotage|Türstation|on
attr A.Door.Pi doorlockcmd set A.Door.T locked
attr A.Door.Pi doorunlockcmd set A.Door.T unlocked
attr A.Door.Pi target0 telefonnummer1
attr A.Door.Pi target1 telefonnummer2

[/spoiler]

  • Dabei ist natürlich die IP-Adresse des DoorPi-Rechners einzutragen.
  • Die Attribute alarmDevice/alarmSettings sind nur zu verwenden, wenn man das Modul 95_Alarm.pm benutzt.
  • Die Attribute doorlockcmd/doorunlockcmd sind die Kommandos, die von FHEM ausgeführt werden, wenn die Haustür wirklich abgeschlossen werden soll.

Notify zur Anzeige des gegenwärtigen Bildes

Ruft man im FHEM-Frontend das Kommando set A.Door.Pi snapshot auf, oder wird der Klingelknopf betätigt, gibt es in FHEM ein Event A.Door.Pi snapshot: <url>. Dieses kann man mit einem Notify abfangen, beispielsweise wird mit:

[spoiler name=”Code ausklappen”]
define A.Door.Pi.img notify A.Door.Pi:snapshot.* { fhem("set GalaxyTab tickerMessage A.Door.Pi $EVTPART1");; fhem("set Archos7Tab tickerMessage A.Door.Pi $EVTPART1")}
[/spoiler]

eine entsprechende Message an zwei Tablets gesendet.

DoorPi

Die DoorPi-Software wird laut diversen Anleitungen im DoorPi Forum auf dem Raspberry Pi installiert. Danach liegt sie im Pfad der Python-Installation – ziemlich ungünstig für weitere Arbeiten. Deshalb wird zunächst ein Verzeichnis /home/doorpi angelegt. In dieser liegen dann verschiedene Hilfsdateien und Hilfsverzeichnisse.

FHEMHelper.sh

Diese Datei ist eine Skriptdatei, mit der diverse Hilfsfunktionen ausgeführt werden. Zwar lassen sich diese in einigen Fällen auch als Einzeiler in der doorpi.ini verstecken, als separate Datei im Verzeichnis /home/doorpi ist diese Helferdatei jedoch leichter änderbar.

[spoiler name=”Code ausklappen”]

# /bin/sh

FHEMDP="A.Door.Pi"
FHEMIP="192.168.0.XX"
FHEM="http://192.168.0.XX:8083/fhem?XHR=1&cmd.$FHEMDP"
HOME="/home/doorpi"
default_target="yyyyyy"

case $1 in

init) target=`cat $HOME/calltarget`
curl "$FHEM=setreading%20$FHEMDP%20call_target%20$target" &

streampid=`pidof mjpg_streamer`
if [ -z "$streampid" ]; then
curl "$FHEM=setreading%20$FHEMDP%20stream%20off" &
else
curl "$FHEM=setreading%20$FHEMDP%20stream%20on" &
fi
;;

doorunlockandopen)
curl "$FHEM=set%20GalaxyTab%20ttsSay%20Ein%20Bewohner%20betritt%20das%20Haus" &
curl "$FHEM=set%20$FHEMDP%20door%20unlockandopen" &
;;

wrongid)
curl "$FHEM=set%20GalaxyTab%20ttsSay%20Unerlaubter%20Zutrittsversuch" &
curl "$FHEM=set%20$FHEMDP%20door%20wrong_id" &
;;

softlock)
curl "$FHEM=set%20$FHEMDP%20door%20softlock" &
;;

call)
curl "$FHEM=set%20$FHEMDP%20call%20$2" &
;;

gettarget)
echo "{ReadingsVal('$FHEMDP','call_target','$default_target')}" | socat -t50 - TCP:$FHEMIP:7072 > $HOME/calltarget
;;

purge)
find $HOME/records/ -type f -ctime 1 -delete
;;

movement)
curl "$FHEM=set%20$FHEMDP%20door%20movement" &
;;

sabotage)
curl "$FHEM=set%20$FHEMDP%20door%20sabotage" &
;;

esac
[/spoiler]

doorpi.ini

Die Konfigurationsdatei doorpi.ini liegt in der Standardinstallation von DoorPi im Verzeichnis /usr/local/etc/DoorPi/conf, sie wird deshalb per Softlink mit /home/doorpi.ini verbunden. In dieser Datei stehen diverse Konfigurationsangaben für DoorPi.

[spoiler name=”Code ausklappen”]

[DoorPi]
base_path = /usr/local/etc/DoorPi
snapshot_path = /home/doorpi/records
number_of_snapshots = 10
eventlog = /home/doorpi/log/eventlog.db
is_alive_led = blinking_led
last_snapshot =

[DoorPiWeb]
indexfile = index.html
loginfile = login.html
online_fallback = http://motom001.github.io/DoorPiWeb
port = 80
public = AREA_public
www = /home/doorpi/records

[AREA_public]
.*

[AREA_config]
/control/config_value_get
/control/config_value_set
/control/config_value_delete
/control/config_save
/control/config_get_configfile

[AREA_dashboard]
/dashboard/pages/.*html

[AREA_status]
/status
/mirror

[AREA_control]
.*

[User]
admin = admin
visitor = visitor

[Group]
administrators = admin
guests = visitor

[WritePermission]
administrators = dashboard,status,config

[ReadPermission]
guests = dashboard

[AdminNumbers]
**621 = active

[DTMF]
"#" = out:door,1,0,3

################# SIP phone #######################
[SIP-Phone]
identity = DoorPi
local_port = 5060
firewallpolicy = PolicyNoFirewall
#
sipphonetyp = linphone
sipserver_password = xxxxxxxxxxxxx
sipserver_realm = fritz.box
sipserver_server = yyyyyyyyyyyy
sipserver_username = 620
stun_server =
#
max_call_time = 300
call_timeout = 60
ua.max_calls = 2
#
capture_device = ALSA: USB PnP Sound Device
playback_device = ALSA: USB PnP Sound Device
audio_codecs = PCMA,PCMU
record_while_dialing = False
records = /home/doorpi/records/%Y-%m-%d_%H-%M-%S.wav
#
dialtone = /home/doorpi/sounds/ShortDialTone.wav
dialtone_renew_every_start = False
dialtone_volume = 35
echo_cancellation_enabled = False
#
video_codecs = VP8
video_device = StaticImage: Static picture
video_display_enabled = False
video_size = vga

[/spoiler]
Mit den nachfolgenden Events sendet DoorPi Nachrichten an FHEM:
[spoiler name=”Code ausklappen”]
####################### Events #######################
[EVENT_OnStartup]
10 = sleep:1
20 = os_execute:/home/doorpi/FHEMHelper.sh call init

[EVENT_BeforeSipPhoneMakeCall]
10 = out:irlight,1
20 = os_execute:/home/doorpi/FHEMHelper.sh call startup
30 = take_snapshot
40 = out:irlight,0

[EVENT_OnCallStateDisconnect]
10 = os_execute:/home/doorpi/FHEMHelper.sh call end

[EVENT_OnCallStateDismissed]
10 = os_execute:/home/doorpi/FHEMHelper.sh call dismissed

[EVENT_OnCallStateReject]
10 = os_execute:/home/doorpi/FHEMHelper.sh call rejected

[EVENT_OnTimeMinuteEvery5]
10=statuswatchdog:/tmp/doorpi.watchdog
[/spoiler]
Hier wird ein virtuelles Keyboard (=I/O-System) mit dem Namen ‘webservice sowie die reale I/O-Hardware, in diesem Falle das PiFace2-Board definiert.

[spoiler name=”Code ausklappen”]

################# Keyboards ##############################
[keyboards]
webservice = filesystem
onboardpins = piface

[/spoiler]
Wichtig sind die virtuellen Buttons, die von FHEM per URL-Aufruf aktiviert werden können.

  • Dabei lösen diese Aufrufe entweder eine direkte Reaktion des PiFace-Moduls aus, z.B. wird mit dem virtuellen Button doorlocked (Aufruf ‘/control/trigger_event?event_name=OnKeyPressed_webservice.doorlocked&event_source=doorpi.keyboard.from_filesystem’) der reale Output hardlock eingeschaltet (Zustand 1 => Ausgang Low).
  • Oder sie rufen dass DoorPi-seitige Hilfsprogramm FHEMHelper.sh auf.

[spoiler name=”Code ausklappen”]

####################### Virtual keyboard #######################
[webservice_keyboard]
base_path_input = /home/doorpi/keyboard/inputs/
base_path_output = /home/doorpi/keyboard/outputs/
reset_input=false

[webservice_InputPins]
dooropen = out:door,1,0,3
doorlocked = out:hardlock,1
doorunlocked = out:hardlock,0
snapshot = sleep:0
streamon = sleep:0
streamoff = sleep:0
lighton = out:light,1
#lightonfortimer = out:light,1,0,60
lightoff = out:light,0
dashlighton = out:dashlight,1
dashlightoff = out:dashlight,0
gettarget = sleep:0
purge = sleep:0
clear = sleep:0
button1 = sleep:0
button2 = sleep:0

#-- communicate to FHEM that a snapshot has been taken
[EVENT_OnKeyPressed_webservice.snapshot]
10 = out:irlight,1
20 = os_execute:/home/doorpi/FHEMHelper.sh call snapshot
30 = take_snapshot
40 = out:irlight,0

#-- start video stream
[EVENT_OnKeyPressed_webservice.streamon]
10 = os_execute:/etc/init.d/mjpg_streamer start

#-- stop video stream
[EVENT_OnKeyPressed_webservice.streamoff]
10 = os_execute:/etc/init.d/mjpg_streamer stop

#-- obtain the target call number from FHEM
[EVENT_OnKeyPressed_webservice.gettarget]
10 = os_execute:/home/doorpi/FHEMHelper.sh gettarget

#-- purge all files older than one day
[EVENT_OnKeyPressed_webservice.purge]
10 = os_execute:/home/doorpi/FHEMHelper.sh purge

[EVENT_OnKeyPressed_webservice.button1]
10 = os_execute:/home/doorpi/FHEMHelper.sh sabotage

[EVENT_OnKeyPressed_webservice.button2]
10 = file_call_value:/home/doorpi/calltarget

[/spoiler]

Es folgt die Definition der realen Buttons:

[spoiler name=”Code ausklappen”]
####################### Real keyboard #######################
[onboardpins_keyboard]
pull_up_down = PUD_UP

[onboardpins_OutputPins]
0 = door
1 = light
2 = dashlight
3 = irlight
4 = hardlock
7 = blinking_led

[onboardpins_InputPins]
0 = file_call_value:/home/doorpi/calltarget
1 = sleep:0
4 = sleep:0
5 = sleep:0
6 = sleep:0
7 = sleep:0

#-- DoorOpen pin from Arduino
[EVENT_OnKeyPressed_onboardpins.1]
10 = os_execute:/home/doorpi/FHEMHelper.sh doorunlockandopen
20 = os_execute:aplay -D plughw:1,0 /home/doorpi/sounds/067_willkommen.wav

#-- WrongID pin from Arduino
[EVENT_OnKeyPressed_onboardpins.4]
10 = out:irlight,1
20 = os_execute:/home/doorpi/FHEMHelper.sh wrongid
30 = take_snapshot
40 = out:irlight,0

#-- LockState pin from Arduino - FHEM will transform softlock into hardlock
[EVENT_OnKeyPressed_onboardpins.5]
10 = os_execute:/home/doorpi/FHEMHelper.sh softlock

#-- Movement detection
[EVENT_OnKeyPressed_onboardpins.6]
10 = out:dashlight,1,0,3
20 = os_execute:/home/doorpi/FHEMHelper.sh movement

#-- Sabotage detection
[EVENT_OnKeyPressed_onboardpins.7]
10 = os_execute:/home/doorpi/FHEMHelper.sh sabotage

[/spoiler]

mjpg_streamer

Diese Software dient dazu, einen kleinen Webserver mit MJPEG-Datenstrom aus der Raspberry Pi-Kamera zur Verfügung zu stellen. Sie wird mit Hilfes des Skriptes /etc/init.d/mjpeg_streamer gestartet und gestoppt.

Sonstige Software

Auf dem Raspberry Pi wird noch benötigt:

  • curl – zum Aufruf einer URL
  • socat – zum Aufruf einer URL und Verarbeitung der Rückgabe (könnte man auch durch curl ersetzen)

 


Fügen Sie einen Kommentar hinzu