FHEMWiki - Benutzerbeiträge [de]

TelegramBot

2017-04-01T16:39:53Z

Hartenthaler: /* Versand von SVG-Plots */ Umstellung auf cmdSend statt TelegramBot_ExecuteCommand

{{Infobox Modul
|ModPurpose=Senden und Empfangen von Nachrichten (Text und Fotos) mit dem freien Messagingdienst Telegram
|ModType=d
|ModForumArea=Unterstützende Dienste
|ModFTopic=38328
|ModTechName=[https://github.com/viegener/Telegram-fhem/blob/master/50_TelegramBot.pm 50_TelegramBot.pm]
|ModOwner=[[Benutzer:Viegener|Viegener]] ({{Link2FU|12772|Forum}} / [[Benutzer Diskussion:Viegener|Wiki]])}}

Das [[TelegramBot]]-Modul ermöglicht das Senden und Empfangen von Nachrichten über den Telegram-instant messaging Dienst (https://telegram.org/).
Es entsteht eine Möglichkeit Benachrichtungen aus FHEM zu versenden, zum Beispiel Alarmmeldungen.
Ausserdem können auch Kommandos über Telegram an FHEM gesendet werden um Steuerungsbefehle in FHEM auszulösen.

Das TelegramBot-Modul benötigt keine Zusatzsoftware auf dem FHEM-Server (anders als die Variante [[Telegram]]), sondern verwendet das [https://core.telegram.org/bots/api TelegramBot-API] über https-Aufrufe. Es muss jedoch das [http://www.fhemwiki.de/wiki/Raspberry_Pi#N.C3.BCtzliche_Zusatzpakete perl JSON modul] installiert sein.

== Über Telegram Instant Messaging ==
Telegram-IDs und Versand/Empfang von Nachrichten sind kostenfrei.
Clients sind für gängige Smartphonesysteme erhältlich (iOS iPhone und Tablet, Android, Windows Phone) und
können auch aus dem WebBrowser verwendet werden.
Es gibt auch einen Kommandozeilen-Client für Linux, der die Grundlage dieses Moduls darstellt.
Mehrfachanmeldungen, auch parallel mit verschiedenen Geräten (z.B. Tablet und Smartphone), sind möglich.
Gruppenchats und Chats mit End-2-End-Verschlüsselung werden ebenfalls unterstützt.

Für die Unterstützung von ''WhatsApp'' siehe Modul [[yowsup]].

== Features ==
Unterstützt werden:

* Versand von Textnachrichten
* Versand und Empfang von Bildern/Audio/etc
* Empfang von Textnachrichten von beliebigen Kontakten
* Kommandos in FHEM über Telegram-Nachrichten von aussen auslösen
* Ergebnisse der Kommandos zusenden lassen

Eine detaillierte Beschreibung des Moduls ist im FHEM Forum und in der (englischen) Dokumentation zum Modul in der Commandref diesem {{Link2Forum|Topic=38328|LinkText=Diskussionsthread}} zu finden. Seit Oktober 2015 wird das Modul offiziell über FHEM-Update verteilt.

Die jeweils aktuellste Entwicklungs-Version des Moduls ist in Github [https://github.com/viegener/Telegram-fhem/blob/master/50_TelegramBot.pm 50_TelegramBot.pm] verfügbar.

== Hinweise zum Betrieb mit FHEM ==
{{Randnotiz|RNTyp=Info|RNText=Achtung: Dieses Authtoken ist die einzige Authentifizierung für den Bot und sollte deshalb nicht aus der Hand gegeben werden. Die verwendeten Urls sind deshalb auch in den Log-Files nicht enthalten, da diese das Authtoken in Klartext enthalten. Auch im Forum sollte dieses Token nicht aufgenommen werden.
}}

Für die Anlage eines TelegramBot Devices in FHEM ist ein Authtoken erforderlich. Dieses Token wird über Anlegen eines neuen Bots im [https://core.telegram.org/bots#botfather BotFather] erzeugt. Dort mit dem Telegram-Befehl <code>/newbot</code> einen neuen Bot anlegen und mit einem Namen versehen. Hinweis: Die Namen für Bots müssen auf "Bot" enden. 

Das Anlegen eines TelegramBot devices erfolgt durch die Angabe dieses Tokens:

<code>define <name> TelegramBot <token> </code>

Beispiel: <code>define teleBot TelegramBot 110201543:AAHdqTcvCH1vGWJxfSeofSAs0K5PALDsaw</code>

'''Das Empfangen von Nachrichten (polling) erfordert die Einstellung des Attributes'''
<code>pollingTimeout</code> '''auf einen Wert der grösser als Null ist. Beim Wert 0 oder ohne Setzen des Attributes findet kein Polling und damit auch kein Empfang statt.'''

Beispiel: <code>attr teleBot pollingTimeout 120</code>

'''Der TelegramBot kann erst dann Nachrichten an einen telegram user schicken, wenn dieser zuerst an den telegram bot eine Nachricht gesendet hat.'''

{{Randnotiz|RNTyp=Info|RNText=TelegramBot setzt eine aktuelle Version von FHEM voraus, insbesondere Versionen weit vor der Umstellung auf 5.7 (also vor Herbst 2015) können mit einem TelegramBot-Modul nicht funktionieren, da insbesondere das HTTPSRV-Modul dann veraltet ist. Am besten auch den TelegramBot über den offiziellen Update mit dem Rest von FHEM installieren/aktualisieren.
}}

== Registrierung eines neuen Bot ==
Zur Registrierung wird ein funktionierender Telegram-Client (egal ob Web, App oder Programm)benötigt. Hier wird ein Chat zum BotFather gestartet und der Befehl /newbot gesendet. Nun fragt der BotFather die benötigten Angaben ab und liefert am Ende des Dialogs die Informationen für den neuen Bot.
Hier ein Beispiel, wie so ein Chat aussehen könnte:
<pre>Client:
/newbot
----------------
BotFather:
Alright, a new bot. How are we going to call it? Please choose a name for your bot.
----------------
Client:
Mein Name
----------------
BotFather:
Good. Now let's choose a username for your bot. It must end in `bot`. Like this, for example: TetrisBot or tetris_bot.
----------------
Client:
fhem_bot
----------------
BotFather:
Sorry, this username is already taken. Think of something different.
----------------
Client:
fhem1234_bot
----------------
BotFather:
Done! Congratulations on your new bot.
You will find it at telegram.me/fhem1234_bot.
You can now add a description, about section and profile picture for your bot, see /help for a list of commands.
----------------
Use this token to access the HTTP API:
1234567890:AbCdefgHIJklmnOPQRst-uvwxyz

For a description of the Bot API, see this page: https://core.telegram.org/bots/api
</pre>
Um einen Chat an einen "Contact" versenden zu können, muss zuerst in Contacts (bei Readings) ein Kontakt auftauchen. Wenn man sich zum allerersten Mal bei Telegram angemeldet hat, gibt es noch keinen Chat mit irgendjemanden. Man muss sich zuerstmal selbst eine Nachricht im Smartphone zusenden, dann taucht unter Readings der Eintrag Contacts auf. Erst dann kann man eine Nachricht mit @msgPeerId (das ist Ziffernfolge des Contacts ) oder mit @msgPeer (das ist der Name nach dem Doppelpunkt) vom TelegramBot auf sein Smartphone senden.

== Tipps ==

=== Privacyeinstellungen ===

Damit der TelegramBot auch Meldungen in Gruppen sieht, müssen über den BotFather die Privacy-Einstellungen geändert werden. Beispielchat:<pre>Client:
/setprivacy
----------------
BotFather:
Choose a bot to change group messages settings.
----------------
Client:
@fhem1234_bot
----------------
BotFather:
'Enable' - your bot will only receive messages that either start with the '/' symbol or mention the bot by username.
'Disable' - your bot will receive all messages that people send to groups.
Current status is: ENABLED
----------------
Client:
Disable
----------------
BotFather:
Success! The new status is: DISABLED. /help</pre>

=== Kontakte ===

Der Bot merkt sich die bereits bekannten Kontakte im Reading <code>Contacts</code>. Dabei werden die einzelnen Kontakte jeweils als 3-teilige Einträge bestehend aus UserID, Vor- und Nachname des Benutzers (mit _ verbunden) und dem Username (mit vorangestelltem @).

Beispiel: <code>123456:Ralf_Mustermann:@ralf</code>

Verschiedene Einträge werden durch Leerzeichen getrennt.

Man kann die Kontakte auch manuell überschreiben (z.B. wenn das Reading fehlerhaft oder verloren sein sollte). Dazu gibt es den Set-Befehl <code>replaceContacts</code>. Dieser nimmt die Kontakte ebenfalls in der gleichen Form wie oben beschrieben entgegen.

Die Kontaktliste wird ansonsten nur durch den Empfang von Nachrichten erweitert, da es im TelegramBot-API keine Möglichkeit gibt Kontaktdaten von Telegram abzufragen (siehe auch pollingTimeout)

=== Reset ===

Es ist möglich den Bot im laufenden Betrieb zurückzusetzen (Set-Befehl <code>reset</code>). Dabei werden noch nicht abgeschlossene Übetragungen entfernt und die internen Zustände des Devices zurückgesetzt.

=== Gruppen ===

Um eine Nachricht von FHEM an eine Gruppe zu senden, muss der BOT in die Gruppe aufgenommen werden. Nach dem Senden einer Nachricht an die Gruppe kann im Modul die Gruppen-ID ermittelt werden und zum Senden von Nachrichten verwendet werden. Wenn die Privacy-Einstellungen nicht auf 'Disabled' gesetzt wurden, muss die Nachricht mit einem Slash (/) beginnen.

==== Supergroups / Supergruppen ====

Auch die neuen Supergruppen werden mit dem Bot unterstützt, es ist allerdings zu beachten, dass bei der Umwandlung einer Gruppe in eine Supergruppe eine neue ID in den Kontakten von Telegram vergeben wird. Wenn man also wie empfohlen IDs zur Identifikation von Benutzern einsetzt, muss entsprechend angepasst werden.

== Beispielszenarien ==

=== Benachrichtigungen über Ereignisse ===

Das einfachste Szenario für die Integration von Messaging-Diensten mit FHEM ist zur Benachrichtigung über Ereignisse. Diese Funktion kann zum Beispiel verwendet werden, um über einen erfolgten Neustart von FHEM zu informieren:

<code>define notify_fhem_reload notify global:INITIALIZED set telebotdevice message fhem newly started - just now !</code>

In diesem Beispiel wird der Nachrichtentext "fhem newly started - just now !" an den als default eingestellten Kontakt (Attribut: defaultPeer) gesendet, sobald FHEM neu gestartet wurde. Natürlich kann man auch beliebige andere Benachrichtigungen einführen.

=== Versand von Bildern ===

Es ist auch möglich Bilder auf dem FHEM-Server, die zum Beispiel von einer Kamera oder einem Wettermodul stammen über Telegram zu versenden. So wäre es z.B. möglich jeweils morgens die aktuelle Wetterkarte zu erhalten.

ACHTUNG: TelegramBot verwendet das HTTPUtils-Modul zur Kommunikation mit dem TelegramBot-API. Erst mit der Version, die seit 22.10.2015
([r9576] HttpUtils.pm: Async write for POST Requests {{Link2Forum|Topic=41583|LinkText=FHEM-Forum}}) verteilt wird, erlaubt auch den Transfer grösserer Bilder. Die Grenze liegt ansonsten bei ca. 14kb auf Raspberries (Plattformspezifische Grenze).

<code>define notify_fhem_reload notify wetter:report set telebotdevice sendPhoto /opt/fhem/wetter.jpg</code>

Bei Erreichen des entsprechenden Status am Wetter-Modul wird ein Image über Telegram versendet. Hier sind lokale Pfade (relativ zu fhem) oder absolute Pfade wie oben möglich.

=== Versand von SVG-Plots ===

SVG-Plots können mit dem Befehl
<code>cmdSend [ @<peer1> ... @<peerN> ] <fhem command></code>
verschickt werden.

Das angegebene FHEM-Kommando wird ausgeführt und das Ergebnis an die angegebenen Peers bzw. den Standard-Peer verschickt.

Mit dem folgenden Befehl wird der SVG-Plot SVG_FileLog_Aussen an den Standard-Peer geschickt:
<code>set mein_telegramBot cmdSend { plotAsPng('SVG_FileLog_Aussen') }</code>

Nach <code>define cmd_sendTelegramSVG cmdalias TGSVG .* AS set mein_telegramBot cmdSend { plotAsPng("$EVENT") }</code>
kann man mit einem kurzen
<code>TGSVG SVG_Garten</code>
ein beliebiges SVG über die Kommandozeile per Telegram versenden.

Um das SVG nun noch mit einem Text zu versehen, muss eine Textnachricht dazu gesendet werden, was sich am einfachsten durch das Ausführen eines FHEM-Befehls auf Perl-Ebene realisieren lässt:

<code>{fhem "set mein_telegramBot message Bildbeschreibung;; set mein_telegramBot cmdSend { plotAsPng('mein_SVG') }" }</code>

'''Hinweis:''' früher wurde zum Verschicken von Plots auch die interne Funktion TelegramBot_ExecuteCommand verwendet; mit dem Update Ende Februar 2017 hat diese Funktion einen zusätzlichen Parameter erhalten und lautet nun
<code>TelegramBot_ExecuteCommand($defs{"mein_telegramBot"}, meine_ZielID, undef, '{plotAsPng("mein_SVG")}');</code>

==== Voraussetzungen für den Versand von SVG-Plots ====
Es muss das Modul libimage-librsvg-perl installiert sein:

<code>sudo apt-get install libimage-librsvg-perl</code>

Evtl. sind weitere Module erforderlich:

<code>sudo apt-get install libgd-graph-perl

sudo apt-get install libgd-text-perl</code>

=== Empfang von Bildern oder ähnlichem ===

Beim Empfang von Bildern wird zuerst nur eine ID vom Telegram-Server empfangen, diese befindet sich im Reading <code>msgFileId</code> angelegt (<code>123456:xxxxxxxxxxxxxxxxxxxxxxx-xxxxxxxx</code>) und im Reading <code>msgText</code> steht dann so etwas wie
<code>received photo # Size: 107701</code>

Über das Get-Kommando <code>urlForFile</code> mit der ID aus dem msgFileId Reading lässt sich dann daraus ein URL ableiten, der dann zur eigentlichen Datei führt:

<code>https://api.telegram.org/file/bot123456:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/photo/file_25.jpg</code>

=== Versand von Emojis (Smileys) ===

Es ist auch möglich Emojis mit den (Text-)Nachrichten zu versenden. Die entsprechenden (Unicode-)Zeichen werden einfach direkt mit in den Text der Nachricht aufgenommen. Um das zu vereinfachen kann man das einfach per Copy und Paste von dieser Seite

http://apps.timwhitlock.info/emoji/tables/unicode (Spalte "Native")

übernehmen und mit der Nachricht verschicken.

Die Emojis können auch empfangen werden und werden so auch in FHEM / FHEMWeb angezeigt. Plattformspezifische (z.B. von iOS oder Android) Emojis werden dabei nicht unterstützt (gerade mit iOS sind viele neue farbige Emojis hinzugekommen, die wohl leider nur auf Apple-devices funktionieren).

=== Kommandos auslösen ===

Ein wichtiges Szenario ist die Möglichkeit Kommandos in FHEM ausführen zu können, ohne einen Zugang durch die Firewall einrichten zu müssen. Dazu ist die Definition eines Schlüsselwortes (Attribut: "cmdKeyword")erforderlich, mit dem man die Nachrichten beginnen muss, damit der TelegramBot die Kommandos erkennt.

<code>attr telebotdevice cmdKeyword doit</code>

Somit kann man dann durch Nachrichten die mit "doit" beginnen Kommandos an FHEM senden, die ähnlich wie im Kommandoeingabefeld von FHEMweb dann von FHEM ausgeführt werden. Das Ergebnis der Ausführung wird zurück an den Sender (und an den definierten defaultPeer) geschickt.

Somit können nicht nur Aktionen angestossen werden, sondern auch Infos abgefragt werden.

Beispiele

<code>doit set schalter on</code>

<code>doit list telegrambot</code>

{{Randnotiz|RNTyp=Warn|RNText=Achtung: Bei den Kommandos sollten man unbedingt das Attribut "cmdRestrictedPeer" setzen, damit nicht jeder Kommandos auf dem FHEM-Server ausführen kann. Dazu sollten die BenutzerIDs der erlaubten Benutzer (durch Leerzeichen getrennt angeben). Da Benutzernamen selber vergeben werden und nicht unbedingt eindeutig sind, sollten hier auch NUR BenutzerIDs verwendet werden.
}}

==== Favoriten für Kommandos anlegen ====

Grundidee bei den Favoriten ist, dass man lange Befehle, die man häufig braucht auf "Kurzwahl" legt.

Beispiel-Kommandos wie z.B. <code>set TYPE=ROLLADEN pos 100</code> und <code>set TYPE=ROLLADEN pos 0</code>, die man immer wieder braucht. Um nicht jedes mal dieses Kommando eintippen zu müssen auf dem Smartphone, kann man auch dafür Favoriten anlegen.

Dazu gibt man erst mal die beiden Kommandos getrennt durch Semikolon im Attribut favorites an:

<code>attr telegrambotdevice favorites set TYPE=ROLLADEN pos 100;set TYPE=ROLLADEN pos 0</code>

Um die Favorites jetzt ausführen zu können braucht man noch ein Schlüsselwort dafür.
Nehmen wir mal an man möchte die Favoriten mit <code>/short</code> ausführen können. Dazu muss dann das Attribut "cmdFavorites" setzen

<code>attr telegrambotdevice cmdFavorites /short</code>

Wenn man nun im Telegram Client
<code>/short 1</code> an den Bot schickt führt der Bot den ersten Favoriten aus und das Ergebnis der Ausführung wird zurückgeschickt.

Ausserdem kann man im Telegram Client
<code>/short</code> an den Bot schicken, dann antwortet der Bot mit

<pre>
Favorites

/short1 = set TYPE=ROLLADEN pos 100

/short2 = set TYPE=ROLLADEN pos 0

</pre>

Die Antworten werden als Schaltflächen dargestellt (Telegram inline Keyboard) und können am Mobile-Client direkt angeklickt werden um sie auszuführen.
Um die Beschriftung der Schaltflächen zu optimieren, können die Befehle im Attribut favorites mit Beschreibungen versehen werden:

<code>/[Rollaeden zu ]=set TYPE=ROLLADEN pos 100;/[Rollaeden auf]=set TYPE=ROLLADEN pos 0</code>

Nun antwortet der Bot auf das Schlüsselwort für die Favoriten mit:

<pre>
Favorites

/short1 = Rollaeden zu

/short2 = Rollaeden auf

</pre>

== Links ==
* Github Repository für die Telegram-FHEM Entwicklung: https://github.com/viegener/Telegram-fhem
* Infos zum Telegram BotFather: https://core.telegram.org/bots#botfather

* Source code für das 50_TelegramBot.pm-Modul: https://github.com/viegener/Telegram-fhem/blob/master/50_TelegramBot.pm

* Forum-Thread in dem das Modul vorgestellt wurde {{Link2Forum|Topic=38328|LinkText=FHEM-Forum}}
* Telegram messaging system https://telegram.org/
* TelegramBot API https://core.telegram.org/bots/api

DoorPi und FHEM

2017-02-24T22:33:48Z

Hartenthaler: /* Audio-Subsystem */ 3 x typo korrigiert

{{
Infobox Modul
|ModPurpose=Das Modul verknüpft eine IP-Türsprechstelle aus dem DoorPi-Projekt mit FHEM.
|ModType=h

|ModCmdRef=DoorPi
|ModForumArea=Automatisierung
|ModTechName=70_DoorPi.pm
|ModOwner=Prof. Dr. Peter A. Henning
}}
Auf dieser Seite wird beschrieben, wie man mit Hilfe der [https://www.doorpi.org/forum/ DoorPi-Software] auf Basis eines Raspberry Pi eine '''IP-Türsprechstelle''' baut und in FHEM integriert.

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 [https://www.dpunkt.de/buecher/12387/9783960090120-smarthome-hacks.html Smart Home Hacks].

[[File:Doorpi_all_s.png]]

=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.

[[File:Doorpi_block.png]][[File:doorpi_completes.png]][[File:doorpi_completeb.png]]

==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.

{|
| [[File:Pizzabote.jpg |200px]]
| [[File:Dhlbote.jpg |200px]]
| Während des Klingelvorgangs wird eine Infrarot-Lichtquelle eingeschaltet und mit einem Weitwinkelobjektiv eine Aufnahme des Besuchers angefertigt. Diese IR-Beleuchtung 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. Lichtbrechung durch den Kameradom sorgt dafür, dass man außen um das Bild herum einen leuchtenden Ring mit 8 Segmenten erkennt.

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-Rimng 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 [http://www.pollin.de/shop/dt/OTQxNzkyOTk-/Bauelemente_Bauteile/Entwicklerboards/Raspberry_Pi/Raspberry_Pi_3_Modell_B.html 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 [http://www.pollin.de/shop/dt/NTc1NzkyOTk-/Bauelemente_Bauteile/Entwicklerboards/Raspberry_Pi/Raspberry_Pi_B_Zusatzplatine_PIFACE_DIGITAL_2.html PiFace 2], mit je 8 digitalen Ein- und Ausgängen.
* ein klares [http://www.reichelt.de/CB-RPF-P-CLR/3/index.html?&ACTION=3&LA=446&ARTICLE=160959 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 [http://www.elv.de/raspberry-pi-noir-kamera-modul.html hier])
* ein Fisheye 180° zum Aufclippen auf Smartphones. Die untenstehenden Stereo-Litografie-Dateien sind für das [http://www.elv.de/bresser-handy-kameraaufsatz-clip-on-180-fisheye-handylinse.html Objektiv von Bresser] entworfen worden, auch erhältlich [https://www.conrad.de/de/smartphone-fish-eye-objektiv-bresser-optik-clip-on-180-fisheye-1359363.html hier].
* eine [http://www.ebay.de/itm/321915955373?_trksid=p2057872.m2749.l2649 Acrylglaskuppel] 2 Zoll (Achtung, der Durchmesser beträgt 49,5 mm).
* eine [https://www.tindie.com/products/freto/pi-camera-hdmi-cable-extension/ 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 [http://www.conrad.biz/ce/de/product/1171399/HDMI-Adapter-1x-HDMI-Stecker-1x-HDMI-Buchse-C-mini-vergoldete-Steckkontakte-Schwarz-SpeaKa-Professional 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: [https://tinkercad.com/things/jv5x6lrihbk 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 hier [https://tinkercad.com/things/cV6rkY6DWvc PiCameraDome4addendum]
* 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 hier [https://tinkercad.com/things/8X0fhiSTyXk PiCameraDome4back]
* 9 x IR-LED [http://www.conrad.biz/ce/de/product/171140/IR-Emitter-940-nm-17-5-mm-radial-bedrahtet-Vishay-TSAL-6200 TSAL 6200] mit hoher Leistung
* 3 Widerstände 10 Ohm 0,2 W.

[[File:Dome1.jpg|400x300px]][[File:Dome2.jpg|400x300px]][[File:Doorpi_dome3s.jpg|400x300px]][[File:Doorpi_dome4s.jpg|600x300px]]

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 [https://www.amazon.de/gp/product/B005BYCBO8 BIGtec 7.1 USB Adapter] ein preiswertes Produkt verwendet, dessen Gehäuse sich problemlos entfernen lässt. Weitere Modelle werden im oben zitierten DoorPi-Forum empfohlen.
*Der Audioverstärker ist ein Modell von [https://www.amazon.de/gp/product/B00UAA7NH8 Foxnovo] mit einer Ausgangsleistung von 2x3 W. Auch hierfür können nahezu beliebige andere Modelle verwendet werden
*Als Lautsprecher kommen zwei [https://www.reichelt.de/VIS-K28-40-8/3/index.html?&ACTION=3&LA=446&ARTICLE=145413&artnr=VIS+K28.40-8&SEARCH=kleinlautsprecher 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 Frontplatte 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 [https://www.amazon.de/gp/product/B000WGW96K 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.

[[File:doorpi_audios.jpg|800x300px]]

==Sensoren==
* Der [http://www.elv.de/bewegungsmeldermodul-pir-13.html 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 [https://www.amazon.de/gp/product/B01DKTHDXE 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.

[[File:DoorPi_part1.png|500x350px]][[File:DoorPi_part2a.png|500x350px]][[File:doorpi_sensorss.jpg|800x350px]]

==Arduino==
Verwendet wird ein Arduino Micro mit dem Programm (Sketch in der Arduino-Terminologie), das [[#Arduino_2|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
[http://wiki.iteadstudio.com/Nextion_HMI_Solution Nextion Display] 3,2" mit einer Auflösung von 400x240 Pixel verwendet (erhältlich in [http://www.aliexpress.com/item/3-2-TFT-480x240-resistive-touch-screen-display-Nextion-3-2-HMI-LCD-Display-Module-TFT/32443541471.html China] oder in [http://www.komputer.de/zen/index.php?main_page=product_info&cPath=30&products_id=354&zenid=like084ipplb747m4ur447p5h3 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 [http://www.conrad.biz/ce/de/product/519111/Displayschutzfolie-Passend-fuer-Universal-100-mm-x-150-mm-1-St/SHOP_AREA_19142 Schutzfolie]. Diese Folie kann man Rand etwas überstehen lassen und dort mit Silikon gegen die Frontplatte abdichten.

[[File:doorpi_displays.jpg|800x380px]]

==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.
* iButtonLesegerät, z.B.:
** [http://www.fuchs-shop.com/de/shop/16/1/13372564/ ohne LED]
** [http://www.fuchs-shop.com/de/shop/16/1/13372377/ mit LED] - Achtung evtl. nicht ausreichend Wetterfest
** [http://www.aliexpress.com/item/2PCS-TM-probe-DS9092-Zinc-Alloy-probe-iButton-probe-reader-with-LED-M98/32635390937.html aus Fernost]
Mehr über die Technik der iButtons erfährt man in der [[:Kategorie:1-Wire|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.

[[File:Doorpi_front.jpg]]

==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 1x1 mm² große Nut, in die eine Dichtung eingelegt werden kann. Zur besseren Verankerung im Putz kann das zusammengeklebte Gehäuse noch mit ''Ohren'' versehen 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.

[[File:Doorpi_coverparts.jpg]]

Hier die Links zu den betreffenden Dateien: [https://www.tinkercad.com/things/5DvvrghWe7T-coverbottom4 CoverBottom4]
[https://www.tinkercad.com/things/3oHRTA6XL1g-covermiddle4 CoverMiddle4]
[https://www.tinkercad.com/things/6BOOMGKsd9Z-covertop4 CoverTop4]
[https://www.tinkercad.com/things/kOnZEsCaQI9-coverearc4 CoverEarC4]
[https://www.tinkercad.com/things/86ovGXH3JyK-coverears4 CoverEarS4]

[[File:Doorpi_covertop.jpg]]

=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'''.

[[File:nextion.png|400x240px]]

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 Serial1 gesetzt werden.
<pre>

/*----------------------------------------------------------------------------------
Haustür

Prof. Dr. Peter A. Henning, April 2016

------------------------------------------------------------------------------------*/
#include <OneWire.h>
#include <SPI.h>
#include <SD.h>
#include <SoftwareSerial.h>
// Make sure that in NexConfig.h nexSerial is configured properly !
#include "Nextion.h"

</pre>
Jetzt werden die Pins des Arduino ausgewählt. Außerdem wir din diesem Abschnitt die Sicherheits-PIN gesetzt, im Beispiel 12345
<pre>

// 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
</pre>
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.
<pre>
// 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}
};
</pre>
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.
<pre>
// 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);
}
</pre>
Es folgt die Initialisierungsroutine
<pre>
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;
}
}
</pre>
Türöffnung -> Pin mit Name DoorOpen wird für eine Sekunde auf LOW gesetzt.
<pre>

void openDoor(int level) {
digitalWrite(DoorOpen, LOW);
delay(1000);
digitalWrite(DoorOpen, HIGH);
}
</pre>
Falsche ID -> Pin mit Name WrongID wird für eine Sekunde auf LOW gesetzt.
<pre>
void wrongID() {
digitalWrite(WrongID, LOW);
delay(1000);
digitalWrite(WrongID, HIGH);
}
</pre>
Mit den beiden nachfolgenden Kommandos wird ein Schloss-Symbol auf dem Nextion angezeigt bzw. ausgeblendet
<pre>
void showLock() {
sendCommand("vis p1,1");
}
void hideLock() {
sendCommand("vis p1,0");
}
</pre>
Dimmen des Dashlight auf einen durch den Helligkeitssensor vorgegebenen Wert (Parameter level=0) oder auf einen als Parameter übergebenen Wert
<pre>
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();
}
</pre>
Hier endlich die Schleife des Hauptprogramms
<pre>
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();
}
}
}
</pre>

==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:
<pre>
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
</pre>
*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
<pre>
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")}
</pre>
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.
<pre>
# /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
</pre>

===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.
<pre>
[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
</pre>
Mit den nachfolgenden Events sendet DoorPi Nachrichten an FHEM:
<pre style="color: blue">
####################### 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
</pre>
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.
<pre>
####################### Keyboards ##############################
[keyboards]
webservice = filesystem
onboardpins = piface
</pre>
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 '<URL des DoorPi>/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.
<pre style="color: red">
####################### 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
</pre>
Es folgt die Definition der realen Buttons:
<pre>
####################### 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
</pre>

==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)

[[Kategorie:1-Wire]]
[[Kategorie:Code_Snippets]]

SIP-Client

2017-02-22T16:18:36Z

Hartenthaler: typo korrigiert

{{Infobox Modul
|ModPurpose=SIP-Client für FHEM
|ModType=h
|ModCmdRef=SIP
|ModForumArea=Sonstiges
|ModTechName=96_SIP.pm
|ModOwner=Wzut ({{Link2FU|1172|Forum}} / [[Benutzer Diskussion:Wzut|Wiki]])}}

Das Modul '''SIP''' ermöglicht die Entgegennahme (DTMF-Töne interpretieren, kontrollierte Annahme) sowie die Durchführung (Audiofile abspielen, DTMF-Töne senden) von Anrufen.

== Voraussetzungen ==
=== FHEM-Server ===
Für den Remote-Zugang muss das Modul Net::SIP installiert sein; auf einem Raspberry Pi oder unter Ubuntu z. B. mit dem Befehl
:<code>sudo cpanm install Net::SIP</code>

oder auch

:<code>sudo apt-get install libnet-sip-perl</code>

=== SIP-Server ===
Der SIP-Client muss sich an einem SIP-Server anmelden (Fritzbox, Asterisk, VoIP-Provider).
Auf dem SIP-Server, mit dem sich der Client verbinden soll, muss ein User-Account vorhanden sein bzw. angelegt werden.
In der Fritzbox muss z.B. ein neues Telefoniegerät vom Typ LAN/WLAN angelegt und ein Passwort vergeben werden. Das erzeugt ein neues internes Device im internen Rufnummernbereich **62x, typischerweise die 620. Es sollte kontrolliert werden, ob bei den Anmeldeinformationen der Benutzername der Nebenstelle entspricht (z.B. 620) und ein Passwort eingetragen ist.

== Installation ==
=== Erste Schritte ===
Spätestens nach einem 'update all' sollte das Modul '''96_SIP.pm''' verfügbar sein.

Nun ist der SIP-Client als Device in FHEM anzulegen:

:<code>define <name> SIP</code>

Anschließend sollten alle sip_Attribute geprüft und für die eigene Umgebung gesetzt werden.

=== mögliche Fehlermeldungen ===
Sollte schon bei <code>define mySIP SIP</code> die Fehlermeldung kommen, dass dieses Modul nicht existiert, dann bitte 'update all' durchführen.

== Anwendung ==
=== Define ===

<code>define <name> SIP</code>

Anschließend sollten alle sip_Attribute geprüft und für die eigene Umgebung gesetzt werden.

Siehe auch [http://fhem.de/commandref_DE.html#SIP commandref]

=== Attribute ===

* '''sip_audiofile'''
: Audiofile das nach dem Command '''fetch''' abgespielt wird. Das Audiofile muss mit folgendem Command erzeugt werden
: '''sox <file>.wav -t raw -r 8000 -c 1 -e a-law <file>.alaw'''
: da nur das raw audio format unterstützt wird. Bitte darauf achten, dass das audiofile und der Pfad dort hin passende Permissions hat, damit FHEM das File auch lesen darf.
* '''sip_listen'''
: Das Attribut bietet folgende Optionen
: - '''none''': keine Aktion ('listen' kann auch nicht manuell gestartet werden)
: - '''dtmf''': Beim FHEM-Start geht das Device automatisch in den Status listen und wartet auf DTMF-Anrufer (listen_for_dtmf). Alternativ kann der Prozess manuell via 'listen' gestartet werden.
: - '''wfp''': Beim FHEM-Start geht das Device automatisch in den Status listen wait-fetch-play (listen_for_wfp). Alternativ kann der Prozess manuell via 'listen' gestartet werden.
* '''sip_from'''
: Meine SIP-Client-Info. Default ist <nowiki>sip:620@fritz.box</nowiki>
* '''sip_ip'''
: Die IP-Addresse meines FHEM-Servers.
* '''sip_port'''
: Port der für den SIP-Client genutzt wird. Default ist 5060 und wird automatisch um 10 erhöht wenn der Port nicht frei ist.
* '''sip_registrar'''
: Hostname oder IP-Addresse des SIP-Servers mit dem sich der Client verbindet. Default ist fritz.box.
* '''sip_ringtime'''
: Klingelzeit für ausgehende Anrufe.
* '''sip_user'''
: User Name des SIP-Clients. Default ist 620.
* '''sip_waits'''
: Interne Wartezeit in Sekunden bevor nach nicht erfolgreichem listen ein erneuter Versuch gestartet wird.
* '''sip_waittime'''
: Maximale Wartezeit bei listen_for_wfp bis das Gespräch automatisch angenommen wird.

Siehe auch [http://fhem.de/commandref_DE.html#SIP commandref]

=== Set ===

Das Modul kennt derzeit folgende Commands

* set <name> '''reset'''

: Stoppt laufende listen-Prozess und initalisiert das Device.

* set <name> '''call <nummer> [<ringtime>] [<nachricht>]'''
: Startet einen Anruf an die angegebene Nummer.
: Optional kann die ringtime angegeben werden. Wird keine angegeben zieht das Attribut sip_ringtime. Default ist 10.
: Optional kann eine Nachricht in Form eines Audiofiles angegeben werden. Das File ist mit dem vollen Pfad oder dem relativen ab dem Verzeichnis mit fhem.pl anzugeben. Bitte darauf achten, dass das audiofile und der Pfad dort hin passende Permissions hat, damit FHEM das File auch lesen darf. Die ringtime ist in dem Fall nicht optional sondern anzugeben.
: Soll statt eines Audiofiles eine DTMF-Sequenz übertragen werden, so muss diese mit einem Prefix '-' versehen werden, also z.B. '''-'''#47.

* set <name> '''listen'''
: Manueller Start des listen-Prozesses. Setzt voraus, dass die Variable sip_listen auf dtmf oder wfp gesetzt ist:
: '''dtmf''': Der SIP-Client wird in einen Status versetzt in dem er automatisch Anrufe annimmt. Bei einem Anruf wird im Reading 'caller' die Nummer bzw. Id des Anrufers angezeigt. Dem Anrufer wird der eigene Ton als Echo zurückgespielt. Über die Eingabe von '''#''' gefolgt von 2 Zahlen und anschließendem Auflegen kann eine Zahl an das Reading '''dtmf''' übergeben werden. Voraussetzung: Das anrufende Telefon ist auf Tonwahl gestellt (DTMF).
: '''wfp''': Der SIP-Client wird in einen Status versetzt in dem er auf Anrufe wartet (wfp steht für wait-fetch-play). Erfolgt ein Anruf an den Client, wechselt das Reading 'caller_state' zu 'ringing', im Reading 'caller' wird die Nummer bzw. Id des Anrufers angezeigt. Nun kann das Gespräch via set-Command 'fetch' angenommen werden. Das als sip_audiofile angegebene File wird abgespielt. Anschließend wechselt der Status wieder zu listen_for_wfp.

=== Readings ===

* '''caller''': Die Rufnummer bzw. Info des aktuellen Anrufers.
* '''caller_state''': Status für eingehende Anrufe.
* '''dtmf''': Die via Tonwahl (DTMF) eingegebenen Zahlen.
* '''state''': Der Status des Devices.

== Anwendungsbeispiele ==

=== Anruf tätigen und Sound abspielen ===
* Den Anruf initiieren
: <code>set <device> call <nummer> [<dauer>] [<audiofile>]</code>
* Die Default-Dauer beträgt 10 Sekunden.
* Wird kein Audiofile angegeben, wird nur die Verbindung hergestellt und nach der Anrufdauer wieder unterbrochen.
* Anmerkung: Das Audiofile muss das Format PCM/8000 haben.
* Der Angerufene nimmt das Gespräch entgegen, das Audiofile wird abgespielt.

=== Anruf tätigen und DTMF-Töne senden ===
* Den Anruf initiieren
: <code>set <device> call <nummer> <dauer> <-tastenkombination></code>
* Die Tastenkombination muss mit einem Minus (-) nach der Zielnummer folgen, also z.B. **1 -#23
* Der Angerufene nimmt das Gespräch entgegen, die Tonfolge wird abgespielt.

=== Auf Anruf warten und DTMF-Töne empfangen ===
* Der SIP-Client wird in den Listen-Modus versetzt.
: Das Attribut sip_listen auf '''dtmf''' setzen und
: <code>set <device> listen</code>
* Die Nebenstelle des SIP-Clients wird von einem DTMF-fähigen Telefon aus angerufen.
* Wenn der SIP-Client das Gespräch angenommen hat, betätigt man '''#''', gefolgt von zwei Ziffern und legt dann wieder auf.
* Im Reading '''dtmf''' ist diese zweistellige Zahl zu sehen und kann ggf. mit einem notify ausgewertet werden.

=== Auf Anruf warten und kontrolliert annehmen ===
* Der SIP-Client wird in den Listen-Modus versetzt.
: Das Attribut sip_listen auf '''wfp''' setzen und
: <code>set <device> listen</code>
* Die Nebenstelle des SIP-Clients wird angerufen.
* Im Reading '''caller''' ist die Nummer bzw. die Info des Callers zu sehen, im '''caller_state''' erscheint 'ringing'.
* Soll der Anruf angenommen werden setze ich den Status des Devices mittels set auf '''fetch''':
: <code>set <device> fetch</code>
* Der SIP-Client nimmt den Anruf an und spielt das im Attribut sip_audiofile angegebene File ab.
* Der SIP-Client legt auf und geht wieder in den Status '''listen_for_wfp'''.

=== Fritzbox + Doorline - Telefonklingeln beenden ===
Szenario: Als Türklingel ist eine Doorline im Einsatz die auf Direktannahme eingestellt ist. Klingelt jemand an der Tür, erfolgt ein 'Anruf' an die in der Rufgruppe definierten Telefone. Man kann den Anruf entgegennehmen, um zu hören wer an der Tür ist, bevor man die Tür öffnet. Geht man direkt zur Tür, klingeln die Telefone insgesamt 30 Sekunden lang bis sie verstummen. Hat man die Haustür mit einem Türkontakt versehen, hilft folgender Ansatz:
* Der SIP-Client wird in der Fritzbox in die Rufgruppe der Türklingel aufgenommen.
* Das Attribut 'sip_listen' wird auf 'wfp' gesetzt.
* Der SIP-Client wird in den Listen-Modus 'wait-fetch-play' versetzt (Die sip_waittime sollte größer als die Klingeldauer der Doorline sein).
: <code>set <device> listen</code>
* Klingelt jemand an der Tür, wird unter anderem die Nebenstelle des SIP-Clients angerufen.
* Über ein DOIF greift man die Kombination SIP-Client caller_state 'ringing' und Haustürkontakt closed->open ab und
* setzt den Status des Devices mittels set auf fetch:
: <code>set <device> fetch</code>
* Der SIP-Client nimmt den Anruf an und spielt das im Attribut sip_audiofile angegebene File ab.
* Die Telefone verstummen.

== Bekannte Probleme / Fehlersuche ==
=== Fehler bei der Registrierung an der Fritzbox ===
'''Fritzbox'''
* Ist das Device für den SIP-Client in der Fritzbox unter Telefonie > Telefoniegräte gelistet?
* Geräteeinstellungen ändern: Ist für das Device unter 'Anmeldedaten' die Durchwahl als Benutzername angegeben?
* Ist der in dieser Ansicht angegebene 'Registrar' mit der im Attribut sip_registrar identisch? Im Zweifelsfalle die IP-Adresse statt 'fritz.box' verwenden.
* FitzOS ab 6.80: Wurde nach Definition des Gerätes an einem anderen bekannten Gerät der Bestätigungscode eingegeben?
'''FHEM'''

Attribute des Devices prüfen:
* Ist unter sip_from <nowiki>'sip:620@fritz.box'</nowiki> die von der Fritzbox vergebene Durchwahl angegeben?
* Ist unter sip_user die von der Fritzbox vergebene Durchwahl angegeben?
* Ist unter sip_password das in der Fritzbox hinterlegte Passwort eingetragen?
* Ist unter sip_registrar die IP-Adresser der Fritzbox eingetragen?
* Ist unter sip_ip die IP-Adresse des FHEM-Servers eingetragen (z.B. 192.168.178.47 angeben, keine Adresse aus dem 127er-Segment)?

== Links ==
* {{Link2Forum|Topic=40219|LinkText=Forenthread}} alter Forum-Thread zu FB_SIP.pm und SIP.pm
* {{Link2Forum|Topic=67443|LinkText=Forenthread}} Forum-Thread zu diesem Modul SIP

[[Kategorie:Hilfsmodul]]

Diskussion:Hauptseite

2017-02-10T15:13:04Z

Hartenthaler: Neuer Abschnitt /* FHEM Icon auf der Hauptseite */

== Archivierung der "Sonderhinweise" nach Umstellung der Forums-Software ==

''Sonderaktivitäten nach Umstellung des Fhem Forums auf eine andere Software:''
* Links auf einen Forenthread können nach folgendem Schema korrigiert werden:
::<code><nowiki>http://forum.fhem.de/index.php?t=msg&th=12345&prevloaded=1&rid=0&start=0</nowiki></code>
:wird zu
::<code><nowiki>http://forum.fhem.de/index.php/topic,12345.0.html</nowiki></code>
* Die Korrektur eines Links auf einen bestimmten Beitrag ist etwas schwieriger, da beim neuen Forum die Thread-Nummer (????? im folgenden Beispiel) notwendig ist, die in den alten Links nicht zur Verfügung steht
::<code><nowiki>http://forum.fhem.de/index.php?t=msg&goto=77777&rid=111 ...</nowiki></code>
:wird zu
::<code><nowiki>http://forum.fhem.de/index.php/topic,?????.msg77777.html#msg77777</nowiki></code>

== Vorschläge zur Überarbeitung der Hauptseite ==

Vorschläge von [[Benutzer Diskussion:Krikan|Christian]] zur Überarbeitung der [[Hauptseite]] (übernommen von [[Benutzer Diskussion:Ph1959de#Inhalt Hauptseite|hier]]):
# <strike>Developers Corner: "bessere" Links</strike> (erledigt)
# <strike>"Guter Startpunkt..." stärker betonen/hervorheben -> Für Grundverständnis von Fhem zwingend zu lesen / Basislektüre</strike>(erledigt)
# Tipp der Woche / des Monats: beleben/aktiver pflegen oder einstellen
# <strike>Entfernung der Box "Weitere Informationen" auf der Hauptseite: "wichtige Fhem Links" ist veraltet/Löschkandidat und sollte daher von Hauptseite entfernt werden. Der Link zum Forum steht bereits in der Box "Was ist Fhem". Dort könnte auch der Link zur Fhem-Seite untergebracht werden. Doppelte Nennung auf der Hauptseite ist unnötig. "Glossar" gehört zur Box "Wie fange ich an?". Damit wäre die Box "Weitere Informationen" überflüssig und könnte gelöscht werden.</strike> (erledigt)
# <strike>Multimedia (Unterhaltungselektronik) und Z-Wave unter Hardware verlinken<strike> (erledigt)
# <strike>Link "Andere Komponeten" zur Forumsangleichung in "Andere Komponenten/Sonstige Systeme" umbenennen (niedrige Priorität)</strike> (erledigt)
# Modul-Orientierten Einstieg auf Hauptseite einbinden (durch Infobox-Vorlagen einfach möglich)
# Frontends auf der Haupseite einbinden <hr />Ist, wie auch der vorherige Punkt nicht ohne "Risiken": irgendwie (noch diffus) wäre es mir lieber, es werden auf der Hauptseite nicht "alle möglichen Abkürzungen" angeboten, sondern die "Leser" würden häufiger über Seiten wie "Systemübersicht", "Phasen..." etc. auf die jeweiligen Unterseiten gehen müssen. Irgendwie eine Frage der Art "zu welcher Arbeitsweise '''erziehen''' wir die Benutzer - und wie '''zwingen''' wir sie, die Konzepte und Grundlagen gelesen und verstanden zu haben, bevor sie in Details gehen". --[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 08:50, 3. Sep. 2014 (UTC) <hr /> Ja, aber dann müssten die Seiten "Systemübersicht", "Phasen..." etc. auch gut gepflegt sein, momentan machen die eher einen unfertigen (sorry) Eindruck auf mich. Und dann sind wir bei der Frage: Ist das Wiki ein Lehr- oder Nachschlagewerk? Oder wollen wir beides erreichen. Frontends finde ich wichtig, da das Wiki nach meinem Eindruck dort schmal besetzt ist und die Benutzer (ich auch) immer wieder Probleme beim WebFrontend haben. Da sind wir auch bei meiner hier irgendwo hinterlassenen Frage: Wo schreibe ich etwas über devstateIcon, webcmd usw.? Allein durch Deine heutige Umstellung der Hauptseite "Wo fange ich an", sollte bereits einiges erreicht sein. Die, die nicht lesen wollen, werden nicht lesen.--[[Benutzer:Krikan|Krikan]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 09:25, 3. Sep. 2014 (UTC)<hr />[[Systemübersicht]] sollte eigentlich relativ "in Ordnung" sein. Ansonsten (bei [[Planung]], etc.) ist das ein bisschen ein Henne/Ei Problem. Ich hatte gehofft, dass die lieben Leser "diese Wege" gehen und gleichzeitig aktiv mithelfen, sie "auszubauen". [[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 11:12, 3. Sep. 2014 (UTC) <hr />
::* 1.: Developers Corner: geändert, da keine (Gegen-)meinungen --[[Benutzer:Krikan|Krikan]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 14:29, 28. Aug. 2014 (UTC)
::* 5. teilweise: Unterhaltungselektronik verlinkt --[[Benutzer:Krikan|Krikan]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 08:38, 29. Aug. 2014 (UTC)
::* 2.: UliMs Einsteiger-PDF stärker betont--[[Benutzer:Krikan|Krikan]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 06:43, 3. Sep. 2014 (UTC)
::* 4.: Wenn es keine begründeten Gegenmeinung zur Löschung Box "Weitere Informationen" entsprechend obiger Erläuterung gibt, wird dies in den nächsten Tagen umgesetzt--[[Benutzer:Krikan|Krikan]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 09:48, 24. Sep. 2014 (UTC)
<hr>
Hallo Peter! Mit Deiner letzten Änderung auf der Hauptseite wurde -wenn ich das richtig verstehe- die rechte Spalte verbreitert. War das Absicht? Eigentlich finde ich links deutlich wichtiger. Gruß, Christian --[[Benutzer:Krikan|Krikan]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 08:38, 29. Aug. 2014 (UTC)
:Jein - ich habe von einer fixen Spaltenbreite (550px, was bei mir deutlich breiter war, als aktuell) auf 45%/55%-Aufteilung geändert. Damit sind auf jeden Fall die Spaltenlängen mal deutlich ausgewogener geworden und sind auf jeden Fall nicht mehr so stark abhängig von der Bildschirmauflösung der einzelnen Benutzer.
:Kann aber gern nochmal geändert werden - nur bitte nicht auf Fixbreite einer Spalte.
::Änderung halte ich (noch) nicht für zwingend.--[[Benutzer:Krikan|Krikan]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 08:32, 3. Sep. 2014 (UTC)

== Einbindung FLOORPLAN Einrichtungsleitfaden auf Hauptseite sinnvoll? ==
Die Einbindung des FLOORPLAN Einrichtungsleitfadens auf der Hauptseite passt meiner Meinung nach nicht in das Konzept der Hauptseite. Beim Einrichtungsleitfaden handelt es sich um ein '''modulspezifisches''' und kein übergreifendes Dokument. Zudem ist das Dokument bereits auf der FLOORPLAN-Wiki-Seite, UliMs Einsteiger-PDF und in der Commandref zu FLOORPLAN verlinkt. Wer das Dokument über diese Wege nicht gefunden/gelesen hat, wird es auch durch Aufnahme auf die Hauptseite nicht finden/lesen. Welche modulspezifischen Dokumente müssten dann nicht auch noch auf der Hauptseite verlinkt werden, weil sie in irgendeiner Form wichtig und gut sind? Ich würde daher die Einbindung wieder zurücknehmen. --[[Benutzer:Krikan|Krikan]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 18:43, 17. Okt. 2014 (UTC)
<hr />
:Hallo Christian, ich stimme Dir zu und bin auch für "wieder entfernen". Ich schreibe aber [[Benutzer Diskussion:Fiedel|Fiedel]] noch mal direkt an - möglicherweise bekommt er die Diskussion hier gar nicht mit. --[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 05:25, 22. Okt. 2014 (UTC)
:<hr />
::Hallo ihr Beiden, das wäre kein Problem für mich. Zu dem Schritt habe ich mich entschieden weil Floorplan mittlerweile viel mehr ist als nur ein beliebiges FHEM-Modul. Er ist quasi fester Bestandteil des Frontends geworden und wird entsprechend genutzt. Als langjähriges Forenmitlglied sehe ich immer häufiger Fragen die darauf hindeuten, dass die Benutzer das FP-Manual nicht gelesen und vor Allem nicht gefunden haben. Meine Hoffnung war, das Forum von solchen Fragen zu entlasten. Außerdem sind das Einsteiger-PDF und das FP-PDF die einzigen beiden "kompletten Bücher", die es zu FHEM gibt. Eine Idee wäre noch beide zu vereinen... Soviel zu meiner Motivation. Ihr hattet übrigens Recht - ich hätte ohne die Nachricht nie etwas von dieser Diskussion mitbekommen. Bin im Wiki noch nicht so fit, dass ich alle "Ecken" dort kenne. Viele Grüße --[[Benutzer:Fiedel|Fiedel]] ([[Benutzer Diskussion:Fiedel|Fiedel]]) 08:27, 24. Okt. 2014 (UTC)
::<hr />
:::Ok, dann nehme ich das wieder raus.
:::Zum Thema "Ecken des Wiki" ... sowas siehst Du vermutlich auch nur, wenn Du die Liste der Änderungen im Wiki immer mal wieder zumindest "überfliegst". --[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 06:58, 24. Okt. 2014 (UTC)

== Bereich "Wie fange ich an?" ==

Ich denke im Bereich "Wie fange ich an?" sollten noch ein paar wenige Links mit aufgenommen werden, die für den Einstieg wichtig sind. Alternativ sollten diese Links anderweitig stärker hervorgehoben werden um leichter gefunden werden zu können.

Bsp.:
* [[Konfiguration]]: Gerade für Neulinge ist die einzige direkt verfügbare Verlinkung dorthin im Fliesstext der Seite [[Systemübersicht#Konfiguration]] - und da hätte ich sie nicht gesucht, und selbst wenn übersieht man es schnell.
-- [[Benutzer:Fabian|Fabian]] ([[Benutzer Diskussion:Fabian|Diskussion]]) 10:25, 20. Mär. 2015 (CET)

== Löschung des Links auf Kategorie "Kopp Components" ==
Vor 2 Monaten wurde auf der Hauptseite ein Link auf die damals neu eingerichtete Kategorie "Kopp Components" aufgenommen. Diese Kategorie ist nur ein "Stub" und enthält keine Informationen. Der einzige dort verlinkte Artikel "Kopp Allgemein" ist auch noch nicht fertig gestellt. Bisher wurden Kategorien erst auf der Hauptseite aufgenommen, wenn allgemeine Bedeutung, Vollständigkeit der Kategorie/Artikel und auch eine gewisse Anzahl von Artikeln in der Kategorie vorhanden waren. Alle diese Kriterien kann ich derzeit nicht als erfüllt erkennen. Ich würde daher den Link auf "Kopp Components" auf der Hauptseite löschen und erst dann wieder aufnehmen, wenn die Kriterien -wie sonst auch- erfüllt sind. Meiner Meinung nach ist es nicht sinnvoll solche Kategorien im Aufbau derart prominent zu platzieren. Gibt es Gegenmeinung?
Gruß, --[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 20:21, 23. Mär. 2016 (CET)
<hr />
: Dafür. Ich würde sogar so weit gehen, die Kategorie "unter Beobachtung" zu nehmen - und wieder zu löschen, wenn sich in den nächsten Monaten keine Aktivitäten zeigen. Den einen Artikel würde ich dann in "Other components" einsortieren. --[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 20:53, 23. Mär. 2016 (CET)
<hr />
:: Erledigt. Wiederaufnahme nach Erfüllung der Kriterien möglich. Kategorienlöschung und Artikelverschiebung sehe ich genauso, wenn es in den nächsten Monaten keine Fortentwicklung gibt. --[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 21:32, 23. Mär. 2016 (CET)

== Ergänzung um allgemeine Ausführung "Was ist FHEM Wiki" ==

Gestern gab es im Forum die Anfrage, ob man in die Sidebar einen Link zur commandref aufnehmen kann. Richtig glücklich bin ich darüber nicht, aber wenn das überwiegend befürwortet wird, können wir das gerne machen.

Mein ursprünglicher Plan, der das Thema commandref-link mit abdecken sollte, war:
Zusätzlich zur Box "Was ist FHEM" eine Box "Was ist FHEM Wiki" aufzunehmen. Dort wollte ich einen Hinweis folgender Art aufnehmen: "Das FHEM Wiki ergänzt die tagesaktuelle, von den zuständigen Entwicklern gepflegte commandref (Kommando-Referenz) um weitergehende Informationen zu FHEM. Im Wiki arbeiten Nutzer und Entwickler gemeinsam an zusätzlicher Dokumentation von FHEM und damit zusammenhängenden Themen."

Was meint ihr? Gruß, --[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 10:41, 26. Jan. 2017 (CET)
<hr />
:Habe den Wunsch im Forum auch gesehen ... und denke, dass es durchaus berechtigt und sinnvoll wäre, die commandref aufzunehmen. Ist für nicht-Developer z.B. deutlich wichtiger, als der Link zum SVN. Das einzige Gegenargument, das ich im Augenblick sehe: commandref ist keine eigene Subdomain, aber ich denke, das ist auch nicht das Hauptkriterium für die Aufnahme in die Linkliste.
:Deinen Vorschlag "Was ist FHEM Wiki" finde ich auch gut. Würde in die rechte Spalte zwischen "News" und "Letzte Änderungen" passen ... dafür würde ich evtl. Teile (oder vielleicht sogar alles) aus der "Administratives zum Wiki" Box auslagern in Unterseiten. --[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 13:21, 26. Jan. 2017 (CET)
<hr>
::Platziere mal einen commandref-Link in der Sidebar. Trenne das aber erst einmal von den SubDomain-Links. Die sind entsprechend auf allen SubDomains enthalten und würde es daher gerne so beibehalten.
::Bei "Adminstratives zum Wiki" würde ich "Aktivitäten für Administratoren:" herausnehmen. Das stört mich schon länger. Die dortige Absichtserklärung "Vorschlag" sollten wir entweder umsetzen oder beerdigen. Der Rest ist mMn nicht unwichtig.
::Mit der Positionierung von "Was ist FHEM Wiki" bin ich mir selbst noch nicht sicher. Spiele mal etwas--[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 15:00, 26. Jan. 2017 (CET)
<hr>
::Meine eigene Zufriedenheit mit den Anpassungen ist nicht sehr groß, aber mir fällt keine bessere Lösung ein:
::Text in "Was ist FHEM" nimmt viel Platz ein, beschreibt aber FHEM klar und eindeutig und macht mMn auch die Möglichkeiten=Komplexität von FHEM klar.
::"Was ist FHEM Wiki" gefällt mir von der Platzierung nicht und macht die Hauptseite wegen der wechselnden Schriftgröße unruhig. Auf der anderen Seite möchte ich die Schrift nicht verkleinern.
::--[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 09:27, 1. Feb. 2017 (CET)
<hr>
:::Wie wär's, wenn "Was ist FHEM Wiki" unter "Was ist FHEM" stehen würde? Macht irgendwie vom Lesefluss her Sinn. News, Änderungen, Neue Seiten wären dann auch wieder untereinander und haben alle die selbe Schriftgröße
:::"Administratives..." könnte man auf eine eigene Seite auslagern und die als "Mitmachen" in der Navigationsleiste verlinken
:::Gruß, --[[Benutzer:Drhirn|Drhirn]] ([[Benutzer Diskussion:Drhirn|Diskussion]]) 09:55, 1. Feb. 2017 (CET)
<hr>
::::die idee 'Was ist FHEM Wiki?' nach links (vielleicht zwischen ‘Was ist FHEM?' und 'Wie fange ich an?') zu schieben finde ich gut. vielleicht könnte man 'Ideen und Lösungen' dafür nach rechts schieben unter die news schieben. dann wären links eher themen die sich mich dem einsteig, was ist was und der entwicklung und sonstigen meta informationen beschäftigen und rechts neuigkeiten und infos zum eigentlichen betrieb. lasse wäre es wenn die 'weniger wichtigen' boxen weiter unten bis auf die überschrift ein und aus zu klappen wären.
:::: --[[Benutzer:Justme|Justme]] ([[Benutzer Diskussion:Justme|Diskussion]]) 20:09, 1. Feb. 2017 (CET)
<hr>
:::::Ein-/Ausklappen geht, indem man einen HTML-Element einfach die CSS-Klasse "mw-collapsible" gibt. Soll der Abschnitt im Initial-Zustand eingeklappt sein, auch die CSS-Klasse "mw-collapsed".
:::::Beispiel auf: [[Benutzer:Drhirn]]
:::::--[[Benutzer:Drhirn|Drhirn]] ([[Benutzer Diskussion:Drhirn|Diskussion]]) 09:00, 2. Feb. 2017 (CET)
<hr>
::::::Stefan, wenn Du Lust und Zeit hast, kannst Du die hier gemachten Vorschläge mal testweise verwirklichen. Nur auf der eigenen Seite testen ist doch unschön und rückgängig können wir es immer machen :-) . Einklappen sehe ich kritisch, da das Nichtlesen fördert. Versuch schadet aber nicht. --[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 11:35, 2. Feb. 2017 (CET)
<hr>
:::::::Ich schau mir grad in meinem Test-Wiki an, ob man das eventuell überhaupt anders hin bekommt. Schlage z.B. vor, eher mit CSS-Klassen zu arbeiten, als für jeden "Abschnitt" CSS-Styles zu definieren.
:::::::Nehme an, ein zweispaltiges Layout ist gewünscht, oder?
:::::::Werde aber auf jeden Fall die bisherigen Vorschläge testweise umsetzen.
:::::::Bevor ich etwas mache noch ein Vorschlag: ''"Was ist FHEM"'' links oben, ''"Wie fange ich an"'' rechts oben, ''"Was ist FHEM-Wiki"'' links unten und ''"Ideen und Lösungen"'' rechts unten. Dann wäre alles für den Benutzer wesentliche auf der "ersten Bildschirmseite". Den Rest dann darunter.
:::::::--[[Benutzer:Drhirn|Drhirn]] ([[Benutzer Diskussion:Drhirn|Diskussion]]) 12:57, 2. Feb. 2017 (CET)
::::::::Bitte mich nicht überfordern, bin nicht mehr so flexibel ;-) Wenn Du radikale Brüche machen willst, dann präsentiere das bitte zunächst auf Deiner persönlichen Seite. Bisher haben sich die anderen Admins nicht zu Wort gemeldet und ich kann/will das bei gravierenden Umbauten nicht alleine entscheiden. Gruß, --[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 13:33, 2. Feb. 2017 (CET)
<hr>
:::::::: :D
::::::::Alles klar, melde mich wieder mit einem Entwurf --[[Benutzer:Drhirn|Drhirn]] ([[Benutzer Diskussion:Drhirn|Diskussion]]) 13:50, 2. Feb. 2017 (CET)
<hr>
::::::::Hier ein - nochmal geänderter - Vorschlag: [https://wiki.jft.at/FhemHaupt https://wiki.jft.at/FhemHaupt]
<hr>
:::::::::Ist ja gar nicht so radikal, wie ich befürchtet hatte. ;-) Habe damit kein Problem. Mal abwarten, was andere meinen. --[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 18:09, 2. Feb. 2017 (CET)
::::::::<hr>
:::::::::Sorry, habe die ganze Diskussion erst jetzt mitbekommen. Also der Vorschlag gefällt mir sehr gut. Vielleicht noch kleinere Änderungen, wenn das im "echten" Wiki umgesetzt ist - mein Ok dafür hast Du. --[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 07:45, 3. Feb. 2017 (CET)
<hr>
Ich fang mal wieder von vorne an. Schade um den Platz ;)

Irgendjemand müsste mir bitte die CSS-Klassen ''.mainpagebox'' und ''.flexbox'' von https://wiki.jft.at/MediaWiki:Common.css hier in die [[MediaWiki:Common.css]] eintragen. Ich darf leider nicht. --[[Benutzer:Drhirn|Drhirn]] ([[Benutzer Diskussion:Drhirn|Diskussion]]) 14:24, 3. Feb. 2017 (CET)
<hr>
:Ist drin. --[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 14:34, 5. Feb. 2017 (CET)
<hr>
::Und die Seite umgebaut.
::Info: Die Anordnung der Boxen kann mit ''style="order: X"'' angepasst werden. Eine Box ist jeweils die Hälfte des Platzes breit. Soll eine Box über die gesamte Breite gehen, einfach ''style="flex: 1 1 80%"'' angeben (wie bei den News z.B.).
::War dann noch die Überlegung, ob wir das "Administrative" auf eine eigene Seite auslagern sollen. Ist der Plan angenommen?
::--[[Benutzer:Drhirn|Drhirn]] ([[Benutzer Diskussion:Drhirn|Diskussion]]) 11:00, 6. Feb. 2017 (CET)
<hr>
:::Danke. Wie immer nur das Gemecker: Mich stört die Schriftart der Überschrift. Fand die alte (Arial?) besser. Bin ich da alleine?
:::"Administratives" würde ich auslagern. Eigentlich müsste das dem "Benutzerkonto beantragen" vorgesetzt werden.
:::--[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 12:11, 6. Feb. 2017 (CET)
<hr>
::::Nein, ich fand die Schrift auch nicht gut. War mir nur nicht ganz sicher, ob das nicht vorher auch so war. Wie auch immer, hab den ursprünglichen Zustand nachgebaut (hab aus Suchmaschinengründen ein ''h1'' für den Titel verwendet, da ist aber ein ganz anderer Stil hinterlegt).
::::Zum Thema "Adminstratives": Wie ich bereits geschrieben habe, würde ich einfach eine Seite "Mitmachen" erstellen. Dort die Regeln festlegen und Infos geben. Und dann am Schluss den Hinweis darauf, wie man ein Benutzerkonto beantragt. --[[Benutzer:Drhirn|Drhirn]] ([[Benutzer Diskussion:Drhirn|Diskussion]]) 12:57, 6. Feb. 2017 (CET)
<hr>
:::::Denke nur daran, dass die "alte" Wiki-Seite zum Benutzerkontenantrag von überall verlinkt ist.
:::::Im Nachhinein störe ich mich etwas am verschwendeten Platz bei "Ideen und Lösungen" und "Developers Corner". Habe aber keine Ideen.
:::::Wegen Schriftstil gehe ich insgesamt noch mal auf Suche. Ursprünglich war es mal serifenlos und ist das verlorengegangen.
:::::--[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 17:02, 6. Feb. 2017 (CET)
<hr>
::::::Hehe, der verschwendete Platz hat mich viel Zeit gekostet. Habe leider keine schöne Lösung gefunden und mir gedacht, wenn's jemand stört, dann soll er einfach mehr Text dazu schreiben ;). Aber ich kann mir auch etwas anderes einfallen lassen wenn's gewünscht ist.
::::::Die Schrift ist jetzt genau die selbe, wie in der Version vom 13. Jänner. Wie's davor war, kann ich leider nicht sagen.
::::::Für die "alte Wiki-Seite zum Benuterkontenantrag können wir einfach eine Weiterleitung erstellen
::::::Gruß, --[[Benutzer:Drhirn|Drhirn]] ([[Benutzer Diskussion:Drhirn|Diskussion]]) 17:33, 6. Feb. 2017 (CET)

== FHEM Icon auf der Hauptseite ==

... anscheinend wird FHEM überall in Großbuchstaben als FHEM geschrieben, nur das Icon hier im wiki verwendet die Schreibweise Fhem.
[[Benutzer:Hartenthaler|Hartenthaler]] ([[Benutzer Diskussion:Hartenthaler|Diskussion]]) 16:13, 10. Feb. 2017 (CET)

TRAFFIC

2016-12-23T14:00:43Z

Hartenthaler: /* Integrierte Karte */ Formulierungen überarbeitet. Die Karte wird erst erzeugt bei verbose=5 (also nicht "alternativ")

{{Infobox Modul
|ModPurpose=Verkehrsdaten zu fest definierten Routen ermitteln
|ModType=d
|ModForumArea=Unterstützende Dienste
|ModTechName=98_TRAFFIC.pm
|ModOwner=jmike ([https://forum.fhem.de/index.php/topic,56045.0.html Forum] / [[Benutzer:Jmike|Wiki]])
}}

Dieses Modul erfasst Fahrzeiten in aktueller Verkehrslage mittels Google Maps Directions API.

== Features / Funktionen ==
* Distanz einer Route
* Fahrzeit ohne Verkehr
* Fahrzeit mit Verkehr
* Verzögerung der geplanten Route
* Waypoints definieren
* Ausgabesprache festlegen
* Outputs in Sekunden / Meter (raw)
* Ausgabe als Text, in Minuten, Sekunden oder als Durchschnitt
* Device STATE frei wählbar
* einstellbares Update Interval
* update-burst für Stosszeiten
* Strecke kann zusätzlich in gegengesetzte Richtung ausgelesen werden
* Ankunfszeit bei Abfahrt zum Update-Zeitpunkt
* verschiedene Travel Modes (driving, walking, bicycling und transit)
* flexibeler Update Schedule für "Stosszeiten"
* integrierte Google Map zum visualisieren der konfigurierten Route

== Voraussetzungen ==
Erstmal muss ein eigener API Key angefordert werden.
Das geht über Googles [https://console.developers.google.com/apis/ API Manager] 
Dort "Google Maps Directions API" suchen und ein neues Projekt erstellen, anschliessend API aktivieren.

Je nach FHEM Installation zusätzlich die Perl Module LWP::Simple, JSON und MIME::Base64 nach installieren: 
<code>sudo apt-get install libwww-perl</code> 
<code>sudo apt-get install libjson-perl</code> 
oder 
<code>sudo cpan -i LWP::Simple</code> 
<code>sudo cpan -i JSON</code> 
<code>sudo cpan -i MIME::Base64</code>

== Definition ==
<code> define <devicename> TRAFFIC <API-KEY> [update-interval] </code>

'''Beispiel:''' 
<code>define muc2berlin TRAFFIC ABCDEFGHIJKLMNOPQRSTVWYZ 600</code>

Der API Key muss selbstverständlich mit dem eigenen Key aus dem API Manager ersetzt werden. 
Das Interval in Sekunden ist optional, der default beträgt es 3600 (1 Stunde). 
Attribute start_address und end_address definieren.

== Readings ==
* average_delay_min
* average_duration_in_traffic_min
* average_duration_min
* delay
* delay_min
* distance
* duration
* duration_in_traffic
* duration_in_traffic_min
* duration_in_traffic_sec
* duration_min
* duration_sec
* [error_message]
* eta
* state
* status

== Befehle ==

==== update [burst-update-count] [burst-update-interval] ====
Readings manuell aktualisieren, der optionale Burst kann wie folgt genutzt werden: 
- erster Wert gibt an wie viele Updates abgearbeitet werden 
- zweiter Wert gibt an wie viele Sekunden zwischen den Updates gewartet wird 

Beispiel um für 1 Stunde alle 5min zu aktualisieren: 
<code>set <device> update 12 300</code>

== STATE ==
* Initialized - modul initialisiert
* OK - update war erfolgreich
* incomplete configuration - Konfigurationsfehler (start_address oder end_address leer)
* <APIRETURN> - Fehlermeldung von Google Maps, falls vorhanden (siehe Reading error_message)
* <Reading> - der Wert des Readings welches mit Attribut stateReading ausgewählt wurde
* disabled - das Device wurde über das Attribut disable deaktiviert

== Attribute ==

{| class="wikitable"
!Attribut
!Default Wert
!mögliche Werte
!Beschreibung
!Beispiel
|-
!align="right" |start_address
|
|<text>
|die vollständige Startadresse (erforderlich!)
|Startstr 1, 12345 Startcity
|-
!align="right" |end_address
|
|<text>
|die vollständige Zieladresse (erforderlich!)
|Zielstr 99, 99099 Zielstadt
|-
!align="right" |raw_data
|0
|0:1
|legt Readings an mit allen unbearbeiteten Werten
|
|-
!align="right" |language
|
|de, en, etc.
|Google ermittelt die Sprache automatisch falls nicht fest definiert
|de
|-
!align="right" |waypoints
|
|lat, long<nowiki>|</nowiki>lat, long
|fixe Wegpunkte auf der Strecke, mehrere Werte per pipe <nowiki>(|)</nowiki> trennen, LAT, LONG Koordinaten angeben
|48.187918, 11.590514
|-
!align="right" |returnWaypoints
|
|lat, long<nowiki>|</nowiki>lat, long
|fixe Wegpunkte für den Rückweg, mehrere Werte per pipe <nowiki>(|)</nowiki> trennen, LAT, LONG Koordinaten angeben, wenn leer werden "waypoints" in umgekehrter Reihenfolge verwendet
|48.187918, 11.590514
|-
!align="right" |disable
|0
|0:1
|Modul deaktivieren
|1
|-
!align="right" |stateReading
|
|<beliebiges-Reading>
|Name eines Readings dessen wert in den STATE des Devices geschrieben wird.
|delay_min
|-
!align="right" |outputReadings
|text
|text,min,sec,average
|konfiguration welche Readings erstellt werden sollen, eine oder mehrere Möglich.
|text min
|-
!align="right" |includeReturn
|0
|0:1
|aktiviert/deaktiviert ob die gleiche Strecke in umgekehrter Richtung hinzugefügt werden soll. Readings werden mit return_* angegeben.
|1
|-
!align="right" |verbose
|1
|0:1:2:3:4:5
|gibt vor wie ausführlich geloggt wird.
|5
|-
!align="right" |travelMode
|driving
|driving:walking:bicycling:transit
|Fortbewegungsmethode für Kalkulation
|walking
|-
!align="right" |updateSchedule
|
|<Beginn-volle-Stunde>-<Ende-volle-Stunde> [<Tag>] <update-Intervall-in-Sekunden>
|definiert einen flexiblen Zeitraum für feinere Updates, Tag als Zahl (Sonntag 0, Montag 1 etc), mehrere Definitionen per <nowiki>(|)</nowiki> getrennt
| 6-8 1 60|6-8 2 60|6-8 3 60|6-8 4 60|6-8 5 60
|-
|}

== Integrierte Karte ==
* Zum Überprüfen der verwendeten Wegstrecke können der Hin- und Rückweg für ein TRAFFIC-Device auf einer Karte angezeigt werden.
* Diese Karte ist verfügbar unter: <nowiki>http://fhem-ip:port/fhem/TRAFFIC_debug?name=<TRAFFIC-DEVICE></nowiki>
* Um die Karte zu erzeugen, muss "verbose" auf 5 gesetzt werden. Das führt dazu, dass ein Weblink auf die jeweilige Karte im automatisch generierten Raum "TRAFFIC_debug" angelegt wird.
** <code>attr <DEVICE> verbose 5</code>
** <code>set <DEVICE> update</code>
** Raum / Link öffnen
*** grün visualisiert den Hinweg
*** rot visualisiert den Rückweg
* Der Weblink und ggf. der erzeugte Raum werden wieder entfernt, sobald verbose auf Werte unter 5 gesetzt wird.

== Bekannte Probleme ==
* STATE: "REQUEST DENIED"
* Reading error_message: "This API project is not authorized to use this API"
** => API Key ist nicht aktiviert. Google API > API Manager > Google Maps Directions API > AKTIVIEREN

* STATE: "UNKNOWN_ERROR"
** => Es liegt ein Fehler bei Google vor.
** => "UNKNOWN_ERROR indicates a directions request could not be processed due to a server error. The request may succeed if you try again." [https://developers.google.com/maps/documentation/javascript/directions?hl=de]

* STATE: "OVER_QUERY_LIMIT"
** Es wurden mehr als 2500 requests pro Tag abgesetzt, update Intervalle der TRAFFIC Devices erhöhen und "burst" zu den Stosszeiten nutzen.

* STATE: "ZERO_RESULTS"
** Die Waypoint definition kann Google nicht realisieren. Statt Städtenamen besser exakte Koordinaten verwenden.

== Tips ==
* täglicher Burst Update zum Feierabend, 1 Stunde alle 5 Minuten updaten:
** <code>define FeierabendCheck AT *17:00 set <device> update 12 300</code>

* komplette Reisezeit, also Hin- und Rückweg, im STATE anzeigen:
** <code>attr <device> stateFormat {int(ReadingsVal($name,"delay_min",0)) + int(ReadingsVal($name,"return_delay_min",0))}</code>

* updateSchedule einsetzen um default update Intervall zu verfeinern
** Montag bis Freitag von 6-8 Uhr alle 60 Sekunden
** <code>attr <device> updateSchedule 6-8 1 60|6-8 2 60|6-8 3 60|6-8 4 60|6-8 5 60</code>
** jeden Tag von 17 bis 19 Uhr alle 2 Minuten
** <code>attr <device> updateSchedule 17-19 120</code>

* Waypoints definieren (Tip von erdo_king)
** In Google-Maps die gewünschte Route auswählen. (PC)
** Auf eine signifikante Stelle der Route klicken - hierbei auf die Fahrtrichtung achten!
** Hier auf die Koordinaten klicken, diese können dann aus dem Suchfeld kopiert werden
** Im Browser zurück bis die Route wieder sichtbar ist (zum späteren Datenabgleich)
** Waypoints in FHEM deklarieren, Daten aktualisieren (set <device> update)
** distance + duration mit den Daten von Google-Maps am PC abgleichen

== to Do ==
* Reading error_message löschen wenn update erfolgreich
* deutsche Commandref

== Weblinks ==
* [https://forum.fhem.de/index.php/topic,56045.0.html Modul Vorstellung und Diskussionen]
* [http://fhem.de/commandref.html#TRAFFIC Commandref]
* [https://console.developers.google.com/apis Google API Manager]

Anwesenheitserkennung

2016-11-25T06:33:38Z

Hartenthaler: /* Batterieüberwachung (alle Devices vom Typ "MODE=lan-bluetooth") */ kleine sprachliche Anpassungen

Viele Benutzer führen bereits eine eigene '''Anwesenheitserkennung''' durch. Diese basiert in den meisten Fällen auf Ping Checks oder bei [[AVM Fritz!Box|FritzBoxen]] auf dem Befehl ''ctlmgr_ctl''. Diese Lösungen können aber je nach Aufbau und Funktion FHEM massiv beeinträchtigen. Aufgrund des Aufbaus vom FHEM kann dieses dadurch für mehrere Sekunden zum völligen Stillstand gebracht werden.

In FHEM gibt es mittlerweile mehrere Module, die eine zuverlässige Anwesenheitserkennung bieten, ohne dabei FHEM bei der Ausführung zu beeinträchtigen.

Eine erweiterte Funktion der Anwesenheitserkennung ist die Standortverfolgung, die sich nicht nur auf ein oder sehr wenige mit (eigenem) WLAN versorgte Gebiete beschränkt.

== Vorüberlegungen ==
Generell gibt es mehrere Ansätze um Anwesenheitserkennung mit Handys/Smartphones durchzuführen.

* via PING Checks im gesamten WLAN
* Aktivitätsprüfung auf einer FritzBox
* Bluetooth Checks in der gesamten Wohnung
* eigene Perl-Funktion
* aktive Benachrichtigung des Smartphones, ausgelöst z.B. über Geo-Lokation/Geofence

Dabei gilt bei der Auswahl der Art darauf zu achten wie sich das jeweilige Device verhält. Aufgrund der Vielfältigkeit kann man hier keine allgemeine Vorgehensweise empfehlen. Als einfacher Start (zumindest für Nicht-Apfel Telefone) eignet sich die Ping-Überprüfung und die FritzBox-Abfrage sehr gut.

=== Randbedingungen ===
Es gibt Geräte, die ihr WLAN/Bluetooth auch im Standby ständig aktiv haben und auf Anfragen antworten können (fast alle Android-Geräte). Gerade bei Tests über WLAN kann sich das aber signifikant auf die Akku Leistung auswirken.

Andere Geräte wiederum schalten WLAN im Standby Betrieb aus, um Akkukapazität zu sparen. Bluetooth hingegen bleibt weiterhin aktiviert und kann auf Anfragen reagieren. (iPhone)

Wenn man bei einem iPhone die Funktion "über WLAN synchronisieren" aktiviert hat, so ist dies auch im Standby jederzeit pingbar, wenn der Recher auf dem iTunes zum synchroniseren läuft auch an ist. Ansonsten ist bei iPhone Geräten nur die Aktivitätsprüfung mit einer FritzBox oder das überwachen der DHCP Lease auf einer Airport Basestation wirklich zuverlässig.

Auch wenn Bluetooth aktiviert ist, so bleiben einige Mobiltelefone erst dann empfangsbereit, wenn sie bereits zu irgend einem Bluetoothgerät gekoppelt wurden. Sind diese Geräte noch nie gekoppelt worden, deaktivieren diese ihren Bluetooth Empfänger beim verlassen des Bluetooth-Menüs im Gerät (iPhone).

Hier gilt es vor allem auszuprobieren, wie stark der Akku durch eine Anwesenheitserkennung belastet wird. Entscheidend ist hier, in welchem Abstand man eine Anwesenheitserkennung durchführt. Viele Abfragen wirken sich stärker auf den Akku aus als wenige. Wenige Abfragen bieten aber keine zuverlässige und zeitnahe Erkennung.

Als Alternative, unabhängig vom WLAN und der Erkennung, ob ein Gerät dort eingebucht ist oder nicht, bzw. unabhängig von Bluetooth kann zumindest bei einem iPhone die seit iOS 7 nochmals stark verbesserte Geo-Lokation (Geofencing) genutzt werden. Die iPhone Apps [http://geofency.com/ Geofency] oder [http://geofancy.com/ Geofancy] werden über das FHEM-Modul GEOFANCY angebunden und übertragen ihren Status immer dann, wenn ein definierter Standort betreten oder verlassen wird. Gekoppelt mit entsprechenden Notify und/oder Watchdog Kommandos ist so ebenfalls eine sehr zuverlässige Anwesenheitserkennung möglich (und das nicht nur für das eigene Zuhause).

== Das PRESENCE Modul ==
Das [[PRESENCE]] Modul bietet für die Anwesenheitserkennung mehrere Varianten an. Diese sind aktuell folgende:

* '''lan-ping''' - Das Überwachen via PING Checks, die durch den FHEM Server versandt werden.
* '''fritzbox''' - Das Überwachen von Geräten auf einer FritzBox via ctlmgr_ctl (Nur auf einer FritzBox möglich)
* '''local-bluetooth''' - Das Überwachen via Bluetooth Checks, die vom FHEM Server direkt durchgeführt werden (angeschlossener Bluetooth-Stick und die Software bluez voraussgesetzt)
* '''lan-bluetooth''' - Das Überwachen von Bluetoothgeräte, über Netzwerk. Auf einer oder mehreren Maschinen im Netzwerk (z.B. [[:Kategorie:Raspberry Pi|Raspberry Pi]]) läuft ein Presence-Daemon, der nach Bluetooth-Geräten sucht. Um mehrere Presence-Daemon mit FHEM zu verbinden, gibt es den Collector-Daemon, der sich zu allen Presence-Damons im Netzwerk verbindet und das Ergebnis von allen zusammenfasst.
* '''function''' - Das Überwachen mithilfe einer selbst geschrieben Perl-Funktion, die den Anwesenheitsstatus zurückgibt (0 oder 1)
* '''shell-script''' - Das Überwachen mithilfe eines selbst geschriebenen Shell-Programms/Skript, das eine 0 oder 1 ausgibt, um den Anwesenheitsstatus mitzuteilen.

=== Ping-Überwachung von Geräten im WLAN/LAN ===
{{Randnotiz|RNText=Um diese Methode auf einer FritzBox nutzen zu können, muss FHEM mit root-Rechten laufen. Dies ist standardmäßig nicht der Fall. Bitte dazu den Wiki Artikel [[FritzBox: fhem unter root starten]] beachten.}}
Um ein Gerät via Ping zu überwachen, muss folgende Definition durchgeführt werden:
:<code>define Handy PRESENCE lan-ping 192.168.0.30</code>

Dadurch wird die IP-Addresse 192.168.0.30 alle 30 Sekunden geprüft, ob sie erreichbar ist. Wenn sie erreichbar ist, ist der Status "present" (anwesend), ansonsten "absent" (abwesend).

Der Timeout kann verändert werden, indem ein Wert (in Sekunden) an das Define anhängt wird:
:<code>define Handy PRESENCE lan-ping 192.168.0.30 '''60'''</code>

Nun würde das Handy alle 60 Sekunden geprüft werden.

Nur wenn bei einem iPhone/iPad die Funktion "über WLAN synchronisieren" aktiviert ist, ist es auch im Standby zuverlässig pingbar. Standardmäßig deaktivieren Apple-Geräte ihr WLAN im Standby-Betrieb um die Akkulaufzeit zu verlängern.

Sollte die Fehlermeldung
:<code> PRESENCE (Handy) - ping command returned with output: ping: icmp open socket: Operation not permitted </code>
im Log auftauchen und lan-ping dadurch nicht funktionieren, liegt ein Berechtigungsproblem vor. Kein Grund den User fhem zu root zu machen!
So sollten die Berechtigungen aussehen
:<code>sudo ls -la /bin/ping</code>
unter Jessie
:<code>-rwxr-xr-x 1 root root 38844 Feb 12 2014 /bin/ping</code>
unter Wheezy
:<code>-rwsr-xr-x 1 root root 33220 Mär 30 2012 /bin/ping</code>
Sollte es trotzdem unter Jessie nicht funktionieren kann man auch dort die Berechtigung analog wheezy setzen:
:<code>sudo chmod u+s /bin/ping</code>

=== FritzBox: direktes Abfragen der Aktivität via ctlmgr_ctl ===
{{Randnotiz|RNText=Um diese Methode auf einer FritzBox nutzen zu können, muss FHEM mit root-Rechten laufen. Dies ist standardmäßig nicht der Fall. Bitte dazu den Wiki Artikel [[FritzBox: fhem unter root starten]] beachten.}}
Eine sehr häufige und auch zuverlässige Methode ist auf einer FritzBox die Abfrage mittels ctlmgr_ctl Befehl. Über diesen lassen sich alle Geräte abfragen ob sie aktiv sind. Ist ein Gerät aktiv, so gilt es als anwesend.

Dieser Modus kann allerdings nur in FHEM Installationen direkt auf einer FritzBox verwendet werden. Des weiteren muss FHEM unter dem User root laufen. Um ein Gerät zu überwachen, wird lediglich der Gerätename benötigt, so wie er unter dem Menüpunkt "Heimnetz" auftaucht.

Die erforderliche Definition:
:<code>define Handy PRESENCE fritzbox iPhone-4S</code>

=== Bluetooth-Überwachung von Geräten durch den FHEM Server ===
[[Datei:Bluetooth-Adresse-iPhone.png|thumb|Bluetooth-Adresse eines iPhones]]
Jenach Aufstellungsort des FHEM Servers kann es sinnvoll sein, eine Bluetooth-Überwachung direkt durch den FHEM Server durchzuführen. Hierbei gilt allerdings zu beachten, dass Bluetooth nicht für große Reichweiten gedacht ist und in den meisten Fällen keine Wände überwinden kann. Das heisst, dass in den meisten Fällen damit nur ein Raum überwacht werden kann.

Je nach Einsatzzweck kann das auch so gewollt sein. Bluetooth USB Sticks, die bereits Bluetooth 4.0 unterstützen, können höhere Reichweiten über Zimmerwände hinaus erreichen. Vorausgesetzt, das Mobilgerät unterstützt Bluetooth 4.0.

Um eine Überwachung per Bluetooth durchführen zu können, benötigt man die Bluetooth-Adresse eines Gerätes. Diese ähnelt vom Aufbau einer MAC-Adresse. Generell wird die Adresse in den Telefon-Informationen bei Smartphones angezeigt.

Um eine Anwesenheitserkennung via Bluetooth durchzuführen, wird folgende Definition in der [[Konfiguration]] benötigt:
:<code>define Handy PRESENCE local-bluetooth XX:XX:XX:XX:XX:XX</code>

=== Bluetooth-Überwachung von Geräten durch verteilte Agenten in der Wohnung (presencd/collectord) ===
[[Datei:Raspberry-Pi-mit-WLAN-und-Bluetooth-Stick.jpg|thumb|left|Raspberry Pi mit Bluetooth- und WLAN-USB-Stick]]
Um eine zuverlässige und flächendeckende Bluetooth-Anwesenheitserkennung durchzuführen, ist es unerlässlich, mehrere Bluetooth-Empfänger zu verwenden, die auf mehrere oder alle Räume verteilt sind.

Hierfür bietet sich zum Beispiel ein [[Raspberry Pi]] mit einem Mini-Bluetooth-USB-Stick und evtl. einem WLAN-USB-Stick an. Jeder Raum wird mit solch einem Raspberry ausgestattet und ist im WLAN Netz verfügbar.

Dieses Netz aus Raspberrys wird mit dem presenced (Download-Link ist in der [http://fhem.de/commandref_DE.html#PRESENCE Commandref] zum Modul enthalten) ausgestattet. Es stehen bereits entsprechende Pakete für den Raspberry zur Verfügung.

Beide Programme (presenced/collectord) sind Perl-Skripte, die als Daemon im Hintergrund laufen und auf Anfragen via Netzwerk warten. Es wird lediglich eine vollständige Perl-Grundinstallation mit Standardmodulen benötigt. Nach Installation der *.deb Pakete sollten diese noch angewiesen werden, automatisch beim Rechner-Neustart gestartet zu werden:

<pre>
sudo update-rc.d presenced defaults
sudo update-rc.d collectord defaults
</pre>

Eine detaillierte Benutzung von presenced ist in der [http://fhem.de/commandref_DE.html#PRESENCE Commandref] Beschreibung zum PRESENCE Modul enthalten.

==== Jeden Raum einzeln ansprechen (presenced) ====
Nun kann zuallererst jeder Raum einzeln angesprochen werden. Dabei ist zu beachten, dass pro Definition in der Konfiguration nur ein Gerät in einem Raum spezifisch überwacht werden kann.

Eine Definition sieht dabei folgendermaßen aus:
:<code>define Handy_Wohnzimmer PRESENCE lan-bluetooth XX:XX:XX:XX:XX:XX 192.168.0.10:5111</code>

Damit wird nun das Gerät nur im Wohnzimmer (Raspberry mit IP 192.168.0.10) überwacht.

==== Alle Räume gemeinsam ansprechen (collectord) ====
Um jedoch alle Räume gemeinsam zu verwenden, gibt es den Collector-Daemon. Dieser kennt alle presenced-Installationen im Netzwerk und führt eine koordinierte Suche nach den gewünschten Geräten durch. Sobald ein Gerät in einem Raum erkannt wurde, meldet der collectord den Status einschließlich der Angabe des Raumes, in dem das Gerät erkannt wurde.

Um alle Räume zu kennen, müssen diese mit einem Config-File dem collectord mitgeteilt werden. Dieses sieht folgendermaßen aus:

<pre>
[Schlafzimmer] # Name des Raumes (wird in FHEM als Reading angezeigt)
address=192.168.179.31 # IP-Adresse oder Hostname des presenced
port=5111 # TCP Port, der verwendet werden soll (standardmäßig Port 5111)
presence_timeout=120 # Prüfinterval, das verwendet werden soll, wenn ein Gerät anwesend ist
absence_timeout=20 # Prüfinterval, das verwendet werden soll, wenn ein Gerät abwesend ist

[Wohnzimmer]
address=192.168.179.34
port=5111
presence_timeout=180
absence_timeout=20
</pre>

Standardmäßig ist dieses Config-File unter /etc/collectord.conf zu finden. Mit dieser Konfiguration kann der Collectord gestartet werden. Es empfiehlt sich diesen mit auf dem FHEM Server zu betreiben. Die erforderliche Definition in der Fhem-Konfiguration:
:<code>define Handy PRESENCE lan-bluetooth XX:XX:XX:XX:XX:XX 127.0.0.1:5222</code>

Sobald das Handy irgendwo in der Wohnung erkannt wurde, meldet der Collectord dies sofort an FHEM und teilt den Raum mit.

Eine detaillierte Benutzung von collectord findet man in der Commandref zum PRESENCE Modul.

=== Überwachung von Geräten mit Perl-Code ===
Es ist möglich zum Überwachen von Geräten eine eigene Perl-Funktion zu verwenden die dann vom PRESENCE Modul im Hintergrund aufgerufen wird.

define <name> PRESENCE function {...} [ <check-interval> [ <present-check-interval> ] ]

Sobald die Funktion den Rückgabewert 1 hat, ist das Gerät anwesend, bei 0 abwesend.

==== Beispiel DHCP Überwachung auf Airport Basestation ====
Die hier vorgestellte Überwachung der DHCP Lease auf Airport Basestations per SNMP ist absolut robust gegenüber dem Ruhezustand von iOS und setzt keine weitere Konfiguration auf dem iPhone voraus. Das Abmelden beim Verlassen des Empfangsbereiches der Basestation geschieht mit etwa 5-10 Minuten Verzögerung und ist somit auch vor kurzzeitigen Empfangsproblemen sicher. Das nebenstehende Bild (???) verdeutlicht noch mal die Unterschiede zwischen einer IP-Basierten Ping-Überwachung und der Überwachung auf Ebene der Basestation oder FritzBox.

Bevor der folgende Code verwendet werden kann ist das Perl Modul Net:SNMP zu installieren (z. B. mit: <code>cpan install use Net::SNMP</code>).

Zuerst ist folgender Code in 99_myUtils.pl einzufügen:

<pre>
use Net::SNMP;
sub
snmpCheck($$)
{
my ($airport,$client)= @_;

my $community = "public";
my $host = $airport;
my $oid = ".1.3.6.1.2.1.3.1.1.2";
#my $oid = ".1.3.6.1.2.1.3.1.1.2.25.1.10.0.1";

my ( $session, $error ) = Net::SNMP->session(
-hostname => $host,
-community => $community,
-port => 161,
-version => 1
);

if( !defined($session) ) {
return 0;
return "Can't connect to host $host.";
}

my @snmpoids = ();

my $response = $session->get_next_request($oid);
my @nextid = keys %$response;
while ( @nextid && $nextid[0] && $nextid[0] =~ m/^$oid/ ) {
push( @snmpoids, $nextid[0] );

$response = $session->get_next_request( $nextid[0] );
@nextid = keys %$response;
}

if( !defined($response = $session->get_request( @snmpoids ) ) ) {
return 0;
}

foreach my $value (values %$response) {
return 1 if( $value eq $client )
}

return 0;
}
</pre>

Danach lässt sich das Mobilgerät so überwachen:
:<code>define iPhone PRESENCE function {snmpCheck("10.0.1.1","0x44d77429f35c")} 30 30</code>

wobei 10.0.1.1 durch die IP-Adresse der Basestation und 0x44d77429f35c durch die MAC Adresse des Geräts als HEX-Zahl ersetzt werden muss.

== Das GEOFANCY Modul ==
Das Modul ermöglicht über einen sogenannten Webhook Mechanismus (umgangssprachlich oft auch als "Push" benannt) das aktive Melden des aktuellen Standortes. Die iPhone Apps [http://geofency.com/ Geofency] und [http://geofancy.com/ Geofancy] können dann aktiv und quasi in dem Moment, wo man den Wohnbereich betritt oder verlässt, benachrichtigen. Android Nutzern können [https://play.google.com/store/apps/details?id=de.egi.geofence.geozone&hl=de EgiGeoZone Geofence] nutzen. Das geht nochmals um einiges schneller, als die Erkennung im WLAN, bei der die Anwesenheit nur in (engen) Zyklen aktiv geprüft werden muss. Gleichzeitig werden Ressourcen in FHEM geschont. Die aktuelle Implementierung im iPhone 5S mit dediziert für das Tracking zuständigem Chip ist so gut, dass der Akku ebenfalls sehr geschont wird.

=== Modul in FHEM einrichten ===
Das Modul ist mit einer einfachen Definition sofort betriebsbereit:
:<code>define geofancy GEOFANCY geo</code>

Damit nimmt FHEM unter <nowiki>http://192.168.178.1:8083/fhem/geo</nowiki> entsprechende Meldungen des iPhones entgegen. Damit das nicht nur über das lokale WLAN funktioniert, bedarf es allerdings noch einiger zusätzlicher Maßnahmen. FHEM muss vom Internet erreichbar gemacht werden, dabei sollte unbedingt an die Absicherung des Zugriffs gedacht werden.

Zunächst einmal habe ich bei mir eine eigene FHEMWEB Instanz dafür angelegt:
<pre>
define WEBhook FHEMWEB 8088 global
attr WEBhook column Alarms: Apartment: Living: Bedroom: Kitchen: Sonos: Residents: Weather: Bathroom: Logs: Statistics: DashboardRoom: System: hidden: all:
attr WEBhook hiddenroom input,detail,save,Unsorted,Everything,CUL_HM,FS20,Commandref,style,Edit files,Select style,Logfile,Floorplans,Remote doc,FileLogs,Apartment,Bathroom,Bedroom,Kitchen,Living,Residents,System,Weather,Event monitor,NEW
attr WEBhook room hidden
attr WEBhook webname webhook
</pre>

Damit ist unter der URL <nowiki>http://192.168.178.1:8088/webhook/geo</nowiki> das GEOFANCY Modul erreichbar. Ich verstecke in dieser Ansicht noch alle Räume, die ich so habe. Wer die Raumnamen allerdings kennt, kann sie trotzdem aufrufen. Die Anzeige in den Räumen kann man mit dem Attribut column und entsprechend leeren Definitionen verstecken. Nun muss man explizit den Devicenamen kennen, um noch etwas über die Konfiguration in Erfahrung bringen zu können.
Auch wenn das Security-by-Obscurity ist - ich fühle mich wohler damit.

=== Webhook weiter absichern ===
Mit Hilfe eines [http://fhem.de/commandref.html#allowed allowed]-Devices lässt sich die FHEMWEB Instanz noch weiter absichern indem nur die tatsächlich benötigten Kommandos erlaubt werden (in diesem Fall keine) und damit alle anderen nicht erlaubten (attr,define,get,set,...) automatisch nicht mehr zur Verfügung stehen:
<pre>
define allowedWEBhook allowed
attr allowedWEBhook allowedCommands ,
attr allowedWEBhook allowedDevices ,
attr allowedWEBhook validFor WEBhook
</pre>

Außerdem ist dringend zu empfehlen, den Zugriff über TLS/SSL und HTTP Basic-Authentication weiter abzusichern. Läuft FHEM auf einem Raspberry Pi, dann empfehle ich dazu die Konfiguration eines ReverseProxy (vorzugsweise HAproxy, Pound oder Varnish, notfalls auch Nginx oder Apache); damit ist man am flexibelsten und kann auch alle FHEMWEB Instanzen direkt über einen einzigen Port (meist 443, der HTTPS Standard Port) zusammenfassen. Ich möchte hier allerdings beschreiben, wie weit man mit FHEM Bordmitteln kommt und nehme das Beispiel einer Installation auf einer Fritzbox.

Wie TLS aktiviert wird, steht in der Commandref für [[FHEMWEB]]. Um die Kommandos auf der Fritzbox ausführen zu können, muss zuerst Telnet aktiviert werden (bitte Google benutzen). Anschließend wechselt man auf der Fritzbox ins Verzeichnis /var/media/ftp/fhem und kann dann den Hinweisen aus der [http://fhem.de/commandref.html#FHEMWEB Commandref] unter dem Punkt HTTPS folgen. Letztlich fehlt noch das entsprechende Attribut:

<pre>
attr WEBhook HTTPS
</pre>

Als nächstes aktivieren wir Benutzername+Passwort für den Zugriff. Die commandref für allowed gibt auch hier unter dem Punkt basicAuth entsprechende Hinweise. Wir fügen hier einfach mal einen Benutzer "webhook" mit dem Passwort "Geofancy" hinzu, das sieht dann so aus:

<pre>
attr allowedWEBhook basicAuth { "$user:$password" eq "webhook:Geofancy" }
</pre>

Weitere Infos zur Absicherung gibt auch [[FritzBox Webzugriff absichern]].

Um zu testen, ob unsere Absicherung erfolgreich war, kann man die URL <nowiki>https://192.168.178.1:8088/webhook/geo</nowiki> aufrufen (wichtig ist, dass man jetzt https und nicht mehr http eingibt; ansonsten bekommt man keine Antwort). Eine Zertifikatswarnung kann getrost ignoriert werden, verschlüsselt wird trotzdem. Es sollte auch eine Passwort Abfrage kommen und die Eingabe der entsprechenden Daten sollte dann zu einer entsprechenden Meldung vom GEOFANCY Modul führen:

<pre>
NOK No data received, see API information on http://wiki.geofancy.com
</pre>

Das ist ok, schließlich sind wir keine App, sondern der Mensch, der nur mal eben prüfen will :-)

=== Zugriff vom Internet ermöglichen ===
Das ist je nach Fritzbox und Software Version unterschiedlich. Grundsätzlich gilt: Eine Weiterleitung des ports 8088 vom Internet auf das laufende FHEM auf Port 8088 intern ist von AVM so nicht vorgesehen.
Bei mir führte folgendes zum Erfolg:

* Einloggen per Telnet auf der Fritzbox (ich habe FritzOS 6 installiert)
* Konfiguration editieren mittels "nvi /var/flash/ar7.cfg"
* Suchen nach richtiger Zeile durch Eingabe von "/internet_forwardrules" und Enter
* Hinzufügen einer weiteren Zeile (Vorsicht, die bestehende Zeile endet mit ; und das muss in , umgeändert werden, so dass das ; schließlich am Ende der Zeile steht.

So sieht es bei mir vorher aus:
:<code>internet_forwardrules = "tcp 0.0.0.0:488 0.0.0.0:488 0";</code>
Hinterher:
:<code>internet_forwardrules = "tcp 0.0.0.0:488 0.0.0.0:488 0", "tcp 0.0.0.0:8088 0.0.0.0:8088 0";</code>

Danach mittels ":x" abspeichern und sofort per "reboot" die Box neu starten, um diese Änderungen zu aktivieren. Das ist wichtig; ansonsten zeigt die Erfahrung, dass die Änderung nicht dauerhaft erhalten bleibt und die gerade gemachten Änderungen verloren gehen.

Wer die Einstellungen zu "internet_forwardrules" bei sich nicht finden kann, hat womöglich eine andere Version als ich oder ein leicht anderes Gerät und bemüht am besten Google, was er tun kann, um das Gleiche zu erreichen. Möglicherweise tauchen die Einträge auch erst auf, wenn man mal über das Webinterface ein Forwarding eingerichtet hatte.

Hat man einen DynDNS Dienst oder myFritz auf der Fritzbox aktiviert, so kann man jetzt auch von draußen auf den Webhook zugreifen. Das kann man prüfen, indem man das iPhone aus dem WLAN ausbucht und einmal die externe Adresse eingibt, also z.B. https://meindyndns.org:8088/webhook/geo.

=== Weitere Alternativen für den Zugriff aus dem Internet ===
Als Alternative zum Port Forwarding kann man sich auch per VPN in das lokale Netzwerk einwählen. iOS bietet dazu auch eine automatische Aktivierung des VPN (VPN on Demand), wie z.B. [http://forum.loxone.com/dede/netzwerk-firewall-and-security/8121-vpn-demand-ios-8-1-1-fritz-box-kleine-how.html hier] beschrieben wird.

Auch eine Alternative ist, das Portforwarding nicht direkt an FHEM einzurichten, sondern an einem im Netzwerk laufenden Reverse-Proxy, der dann seinerseits die Anfragen an FHEM weiterleitet. Dies kann z.B. Apache, Nginx oder am besten HAproxy sein.
Letzterer ist dabei sehr flexibel, allerdings nicht unbedingt einfach zu konfigurieren. Ein paar Inspirationen diesbezüglich gibt es z.B. [https://github.com/Hoanoho/HSE/tree/develop/lib/cfg/any/stat/etc/haproxy hier] und [https://github.com/Hoanoho/HSE/tree/develop/lib/cfg/any/dyn/etc/haproxy hier]. Wer pfSense nutzt, findet [http://loredo.me/post/116633549315/geeking-out-with-haproxy-on-pfsense-the-ultimate diesen Artikel] womöglich auch interessant. Er zeigt auch, dass mit HAproxy noch weit mehr möglich ist.
Der Reverse-Proxy sollte dabei auch unbedingt der TLS Termination Point sein (TLS Offloading). Nicht nur spart man sich dann die Aktivierung von TLS in FHEM, sondern man hat auch mehr Einfluss darauf, wie TLS arbeitet (z.B. Deaktivierung von SSLv3, forcieren von TLSv1.2, nur als sicher eingestufte Cipher Suite... siehe auch Infos auf der [https://wiki.mozilla.org/Security/Server_Side_TLS Mozilla Website]).

=== Einrichten in der Geof[e|a]ncy.app ===
Hat das alles soweit geklappt, können endlich in der Geofency.app bzw. Geofancy.app am iPhone die gewünschten Bereiche definiert werden. Am Besten zuvor in den Global Settings die folgenden Einstellungen hinterlegen:

* URL: https://meindyndns.org:8088/webhook/geo
* POST (oder GET, ist egal - das FHEM Modul kann beides)
* HTTP Basic Authentication: EIN (entsprechend Username und Password eintragen)

Anfänglich ist es empfehlenswert noch "Notification on success" und "Notification on Failure" einzuschalten. Ersteres kann man ausmachen wenn man weiß, dass es soweit funktioniert. Über "Send Test-Request" kann man einmal einen Test schicken und erhält das Ergebnis entsprechend dargestellt. Es sollte sowas kommen wie
:<code>POST Success: test OK</code>. In Geofancy.app gibt es keine Rückmeldung über den Erfolg des Testrequests. In FHEM sollten sich durch den Testrequest jedoch die Readings sofort aktualisieren (Ggf. ist ein Reload der FHEMWEB-Seite nötig da zusätzliche Tabellenzeilen nicht via Longpoll ergänzt werden).

Funktioniert das soweit, kann man eine neue Lokation als sein Zuhause anlegen. Es empfiehlt sich einen ID-Namen zu setzen; dieser ist dann in FHEM als Name für die Lokation sichtbar. Für die eigene Wohnung empfiehlt sich hier "home" (da dies auch direkt vom RESIDENTS Modul so verwendet werden kann). Man kann auch Trigger für andere Standorte anlegen. FHEM weiß dann sogar, wenn ihr im Büro seid und könnte sich dabei auch unterschiedlich verhalten, als wenn ihr "auf Achse" seid. Bei letzterem ist der Status im GEOFANCY Modul "underway", was so viel heißt wie "unbekannter Aufenthaltsort".

Hinweis: Zumindest für Geofancy.app liefert ein Testrequest wohl zufällige Locations zurück. Die eigenen Location-IDs werden also nicht übergeben, selbst wenn man sich in einem Geofence befindet. Um zu testen muss man sich wohl oder übel selbst bewegen ;-).

=== GEOFANCY Modul individualisieren ===
Die im GEOFANCY Modul dargestellten Readings sind nun in etwa so, wenn ihr euch bewegt:

<pre>
Readings:
2014-01-18 14:37:42 lastDevice -
2014-01-18 14:37:42 lastDeviceUUID 51F23894-AAAA-BBBB-CCCC-0123456789AB
2014-01-18 14:37:42 state dev:51F23894-AAAA-BBBB-CCCC-0123456789AB trig:test id:home lat:48.9999 long:11.9999
</pre>

Wer genauer hinschaut sieht: Mein iPhone heißt wohl 51F23894-AAAA-BBBB-CCCC-0123456789AB.
Damit nun die Readings für mein iPhone richtig angelegt werden, muss ein Device Alias gesetzt werden. Sinnvoll erscheint mir der Vorname des Besitzers:
:<code>attr geofancy devAlias 51F23894-AAAA-BBBB-CCCC-0123456789AB:Julian</code>

Weitere Alias-Namen können mit Leerzeichen einfach angehängt werden.
Jetzt werden weitere Readings angelegt, sobald GEOFANCY entsprechende Daten vom Mobilgerät empfängt:

<pre>
Readings:
2014-01-18 14:37:42 Julian arrived home
2014-01-18 14:37:42 currLocLat_Julian 48.9999
2014-01-18 14:37:42 currLocLong_Julian 11.9999
2014-01-18 14:37:42 currLocTime_Julian 2014-01-18 14:37:42
2014-01-18 14:37:42 currLoc_Julian home
2014-01-17 19:18:23 lastArr Julian home
2014-01-17 18:41:46 lastDep Julian Office
2014-01-18 14:37:42 lastDevice Julian
2014-01-18 14:37:42 lastDeviceUUID 51F23894-AAAA-BBBB-CCCC-0123456789AB
2014-01-17 18:41:46 lastLocArr_Julian 2014-01-17 08:58:37
2014-01-17 18:41:46 lastLocDep_Julian 2014-01-17 18:41:46
2014-01-17 18:41:46 lastLocLat_Julian 48.1111
2014-01-17 18:41:46 lastLocLong_Julian 11.1111
2014-01-17 18:41:46 lastLoc_Julian Office
2014-01-18 14:37:42 state dev:Julian trig:test id:home lat:48.9999 long:11.9999
</pre>

Möchte man nun etwas bestimmtes tun, wenn man nach Hause kommt oder das Heim verlässt, kann man am Besten ein entsprechendes Notify auf das Reading currLoc_Name setzen. Ich aktualisiere lediglich zwei Dummies, durch die dann alle weiteren Notifies ausgelöst werden:

<pre>
define n_Julian.Presence notify geofancy:currLoc_Julian:.home set Julian.homestatus:FILTER=STATE!=home home
attr n_Julian.Presence room Residents
define n_Julian.absence notify geofancy:currLoc_Julian:.underway {\
if (Value("Julian.homestatus") ne "gone") {\
fhem("set Julian.homestatus:FILTER=STATE!=absent absent");;\
}\
}
define n_Julian.whereabout notify geofancy:currLoc_Julian:.* set Julian.whereabout:FILTER=STATE!=$EVTPART1 $EVTPART1
</pre>

Wer es noch einfacher möchte (bzw. auch noch mehr Features) schaut sich einmal die neue Modulfamilie aus RESIDENTS[http://fhem.de/commandref_DE.html#RESIDENTS], ROOMMATE[http://fhem.de/commandref_DE.html#ROOMMATE] und GUEST[http://fhem.de/commandref_DE.html#GUEST] an. Diese sind direkt auf GEOFANCY abgestimmt. Dabei kann das devAlias Attribut entfallen und man hinterlegt die UUID stattdessen direkt im ROOMMATE oder GUEST Device (Attribut r*_geofenceUUIDs). Das erspart es für jeden Bewohner und jedes Device zig unterschiedliche Devices der Typen Notify, DOIF oder Watchdog anlegen und pflegen zu müssen.

Wer mehr Kontrolle möchte kann natürlich bei notify, DOIF und Co. bleiben: <code>define n_rr_Julian.location notify geofancy:currLoc_Julian:.* set rr_Julian:FILTER=location!=$EVTPART1 location $EVTPART1</code>. Wobei "Julian" dabei als devAlias in GEOFANCY eingtragen wurde, rr_Julian der Name des ROOMMATE aus RESIDENTS ist. Außerdem wurden die Location-IDs in der Geofency.app bzw. Geofancy.app so gewählt, dass diese direkt einem ROOMMATE-Status entsprechen (also z.B. home, wayhome...).

== Beispiele für die Nutzung der Anwesenheitserkennung ==
Hier sollen Beispiele für den Nutzen von Anwesenheitserkennung aufgezeigt werden.

=== Abschalten aller Verbraucher (Licht, Musikanlage) beim Verlassen der Wohnung ===
Typisches Szenario: Man geht ausser Haus, aber hat vergessen im Bad das Licht aus zu machen. Allerdings geht man heutzutage fast garnicht mehr ohne Handy aus dem Haus.

Nun soll FHEM in der gesamten Wohnung das Licht, sowie sonstige Verbraucher ausschalten, wenn ich länger als 15 Minuten ausser Haus bin. Dazu benötigt man zuerst eine structure, die alle Verbraucher und sonstigen Devices, die das betrifft, zusammenfasst.

<pre>
define Gesamte_Wohnung structure Gesamtes_Licht Licht_Wohnzimmer Licht_Kueche LED_Kueche Licht_Bad Licht_Schlafzimmer AV_Receiver TV_Steckdose
attr Gesamte_Wohnung room Wohnung
</pre>

Nun kann man mittels eines watchdogs eine Überwachung für sein Handy anlegen:

<pre>
# Überwachen der gesamten Wohnung mittels collectord sowie presenced in jedem Raum
define Handy PRESENCE lan-bluetooth XX:XX:XX:XX:XX:XX 127.0.0.1:5222
attr Handy event-on-change-reading state # Ein Event soll nur bei der Änderung des Anwesenheitsstatus (Reading: status) erfolgen. Wichtig für den watchdog!!!

# Nach 15 Minuten Abwesenheit (Handy im Status "absent") soll die gesamte Wohnung ausgeschaltet werden.
define watchdog_Anwesenheit watchdog Handy:absent 00:15 Handy:present set Gesamte_Wohnung off ; trigger watchdog_Anwesenheit .
attr watchdog_Anwesenheit regexp1WontReactivate 1
</pre>

== Anwesenheitserkennung Bluetooth PebbleBee mit PRESENCE Modul ==
Im Forum gibt es einen {{Link2Forum|Topic=28753|LinkText=langen Beitrag}} über die Einrichtung eines BT-Tag an einem RaspberryPI mit FHEM. Dabei werden Skripte wie blescan.pl und lepresenced genannt.
Da mittlerweile viele neue Informationen zusammen gekommen sind wurde der Wiki Eintrag erstellt.

Im Folgenden wird die Konfiguration für '''LE Deviced (z.B. Gtags,Pebbles etc.)''' und '''NICHT LE Device (z.B. IPhone)''' beschreiben.

'''Wo finde ich denn lepresenced?'''

lepresenced kann über Github heruntergeladen werden (Link weiter unten)

'''Was ist der Vorteil gegenüber blescan.pl?'''

{{Randnotiz|RNText=Beide hier beschriebenen Wege (presenced/lepresenced) können parallel auf dem selben BT-Dongle laufen, da sich die Ports unterscheiden!}}
blescan.pl hat u. a. das Problem, dass dank der wundervollen Bluetooth-Implementierung unter Linux ab und zu der Scan fehlschlägt und das Interface resettet werden muss. Das tut blescan.pl auch mit aller Gewalt. Dazu kommt, dass bei längeren Scanzeiten und vielen Tags sich die Prozesse anstauen, weil immer nur auf einen Tag "gewartet" wird. Außerdem wurden mit der Einführung von lepresenced sämtliche Supportverträge gekündigt lepresenced läuft dauerhaft und merkt sich bei allen sendenden Tags den Zeitstempel des letzten Empfangs.

=== Getestete Hardware/Software===
* '''Raspbian System''' - wheezy, Jessie
* '''BT-Dongle''' - CSL NET BT USB2.0 Stick, Bluetooth V4.0, Nano '''Achtung''': Es muss ein BT V4.0 oder höher verwendet werden. Nur dieser unterstützt ''LowEnergy''
* '''BT-TAG''' - Gtag von Gigaset, TrackR, UDOO Neo, PebbleBee, iTag von Unitec, X4-LIFE Multifunkti BL-Anhänger, iTag Wireless Anti, Trackr bravo

=== BT Dongel am PI installieren ===

Um den BT Dongle ''(hier: CSL NET BT USB2.0)'' am PI verwenden zu können, müssen die notwendigen Pakete über die Paketverwaltung von debain nachinstalliert werden.
Wer bereits ein BT-Dongle installiert hat, kann diesen Schritt überspringen.
<pre>
apt-get install bluetooth
</pre>
Nach erfolgreicher Installation der Pakete sollte der RaspberryPI neu gestartet werden.
<pre>
sudo reboot
</pre>

Nach dem erfolgten Reboot bitte das Log des Raspberry auf folgende Einträge prüfen:
<pre>
Feb 12 19:52:55 fhem kernel: [ 4.773600] Bluetooth: Core ver 2.20
Feb 12 19:52:55 fhem kernel: [ 4.773748] NET: Registered protocol family 31
Feb 12 19:52:55 fhem kernel: [ 4.773765] Bluetooth: HCI device and connection manager initialized
Feb 12 19:52:55 fhem kernel: [ 4.773797] Bluetooth: HCI socket layer initialized
Feb 12 19:52:55 fhem kernel: [ 4.773821] Bluetooth: L2CAP socket layer initialized
Feb 12 19:52:55 fhem kernel: [ 4.773890] Bluetooth: SCO socket layer initialized
Feb 12 19:52:55 fhem kernel: [ 4.797531] usbcore: registered new interface driver btusb
</pre>
Sobald der BT-Dongle erkannt wurde ''leuchtet'' (wenn vorhanden) auch die ''blaue/gelbe'' LED am Dongle auf.

=== BT-Tags aktivieren ===
Jetzt kann der BT-Tag aktiviert werden. Bei einigen Tags muss dafür die '''Batteriesicherung''' gezogen werden.

Einen Tag wird mit folgendem Befehl auf der Konsole gesucht:
<source lang="bash">
sudo hcitool lescan

Ausgabe z.B.:
LE Scan ...
7C:2F:80:A1:XA:XD (unknown)
7C:2F:80:A1:XA:XD Gigaset G-tag
7C:2F:80:A1:X4:X1 (unknown)</source>
Eine Übersicht über die möglichen Befehle von hcitool gibt es mit der Eingabe von:
<pre>
sudo hcitool

Ausgabe z.B.:
hcitool - HCI Tool ver 5.23
Usage:
hcitool [options] <command> [command parameters]
Options:
--help Display help
-i dev HCI device
Commands:
dev Display local devices
inq Inquire remote devices
scan Scan for remote devices
name Get name from remote device
info Get information from remote device
spinq Start periodic inquiry
epinq Exit periodic inquiry
cmd Submit arbitrary HCI commands
con Display active connections
cc Create connection to remote device
dc Disconnect from remote device
sr Switch master/slave role
cpt Change connection packet type
rssi Display connection RSSI
lq Display link quality
tpl Display transmit power level
afh Display AFH channel map
lp Set/display link policy settings
lst Set/display link supervision timeout
auth Request authentication
enc Set connection encryption
key Change connection link key
clkoff Read clock offset
clock Read local or remote clock
lescan Start LE scan
lewladd Add device to LE White List
lewlrm Remove device from LE White List
lewlsz Read size of LE White List
lewlclr Clear LE White list
lecc Create a LE Connection
ledc Disconnect a LE Connection
lecup LE Connection Update
</pre>

Falls beim SCAN kein Tag gefunden wird, sollte das BT Interface neu gestartet werden. Dazu ist kein Reboot des PI notwendig.
<source lang="bash">
sudo hciconfig hci0 down
sudo hciconfig hci0 up
sudo hcitool dev
</source>

=== Anleitung für ein LE Device (z.B. Gtags,Pebbles etc.) ===

Herunterladen des Skripts lepresenced.
<pre>
https://github.com/mhop/fhem-mirror/blob/master/fhem/contrib/PRESENCE/lepresenced
</pre>

Zur "Installation" des Skripts folgendermaßen vorgehen:
Unter /fhem manuell den Ordner „script“ anlegen:
<pre>
mkdir script
</pre>
Datei lepresenced reinkopieren und ausführbar machen:
<pre>
sudo chmod +x /opt/fhem/script/lepresenced
sudo chgrp -cR dialout lepresenced
</pre>
Skript erstmalig starten:
<pre>
sudo ./lepresenced --loglevel LOG_EMERG -d
</pre>
Kommt beim Starten des Skript eine Fehlermeldung, müssen die Abhängigkeiten aufgelöst werden.
<pre>
Can't locate Net/Server/Daemonize.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 / usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl .) at /opt/fhem/lepresenced line 17.
BEGIN failed--compilation aborted at /opt/fhem/lepresenced line 17.
</pre>
Um die Abhängigkeiten aufzulösen muss folgendes nachinstalliert werden und anschließend ein Reboot durchgeführt werden.
<pre>
sudo apt-get install libnet-server-*
</pre>

Nach dem letzten Schritt sind alle Bedingungen für eine abschließende Konfiguration der BT-Tags in FHEM abgeschlossen worden.
Jetzt kann der Tag dem FHEM-Server bekannt gemacht werden.
<pre>
-- Name Modul Modus MAC vom Gtag IP vom PI Port Abfragezeit in Sekunden
define MeinGtAG PRESENCE lan-bluetooth xx:xx:xx:xx:xx:xx 127.0.0.1:5333 120
</pre>

Den absent und present Mode kann man einfach testen, in dem man den Gtag mit Alufolie einwickelt.

=== Anleitung für ein NICHT LE Device (z.B. IPhone) ===
Die Installation kann (wie in der commanref beschrieben) über Debian Pakete erfolgen.
<pre>
.deb package for Debian (noarch): presenced-1.3.deb http://svn.code.sf.net/p/fhem/code/trunk/fhem/contrib/PRESENCE/deb/presenced-1.3.deb

.deb package for Raspberry Pi (raspbian): presenced-rpi-1.3.deb http://svn.code.sf.net/p/fhem/code/trunk/fhem/contrib/PRESENCE/deb/presenced-rpi-1.3.deb
</pre>

<pre>
sudo dpkg -i presenced-rpi-1.3.de
</pre>

Installation perl script file (Auszug commanref)
<pre>
direct perl script file: presenced http://svn.code.sf.net/p/fhem/code/trunk/fhem/contrib/PRESENCE/presenced
</pre>

Nach dem letzten Schritt sind alle Bedingungen für eine abschließende Konfiguration der BT-Tags in FHEM abgeschlossen worden.
Jetzt kann der Tag dem FHEM-Server bekannt gemacht werden.
{{Randnotiz|RNText=Wenn man mit collectord arbeitet muß man die Erkennung bei allen Devices auf port 5222 setzen.
lan-bluetooth xx:xx:80:xx:xx:AC 127.0.0.1:5222 20 120}}
<pre>
-- Name Modul Modus MAC vom Gtag IP vom PI Port Abfragezeit in Sekunden
define MeinGtAG PRESENCE lan-bluetooth xx:xx:xx:xx:xx:xx 127.0.0.1:5333 120
</pre>

=== Automatischer Start ===

Damit das leprecend Skript beim Systemstart mitgestartet wird, sollte eine Crontab Eintrag gesetzt werden. Alternativ die rc.local anpassen.
Ersteres würde so aussehen:

Ein sh-Skript mit dem Inhalt:
<pre>
sudo start-stop-daemon -d /opt/fhem/script -S -x /opt/fhem/script/lepresenced
</pre>
unter dem Verzeichnis /home/pi ablegen, welches sich init_start.sh nennt.

Das Skript dann unter: sudo crontab -e einhängen mit folgender Folge:
<pre>
@reboot /home/pi/init_start.sh
</pre>

Zweiteres so:
<pre>
sudo nano /etc/rc.local
</pre>

Datei rc.local, freie Stelle suchen, vor "exit 0":

<pre>
# Start lepresenced
/opt/fhem/script/lepresenced --loglevel LOG_EMERG -d
exit 0
</pre>

=== Batterieüberwachung (aktuell nur G-Tags) ===

Leider überträgt der G-Tag nach der Einrichtung als Device in FHEM kein Reading mit seinem aktuellen Batteriestatus.
Dem wurde mit Hilfe des Forum Abhilfe geschaffen.
Im Folgenden wird erläutert wie die Batterieüberwachung eingerichtet werden kann.

'''Voraussetzung:'''

bc - Basiscalculator [https://packages.debian.org/de/sid/bc Bc-Paket]
<pre> sudo apt-get install bc </pre>

Anlegen eines Shellskript auf dem Raspberry System.
Die Parameter <<MAC-Adresse>> und <<TagName>> müssen durch die Werte des auszulesenden G-Tags ersetzt werden.
<pre>
#!/bin/bash
stringZ=$(sudo gatttool -b 5C:2B:80:C1:14:41 --char-read --handle=0x001b)
stringZ=${stringZ:33:2}
stringZ=$(echo "$stringZ" | tr a-f A-F)
decimal=$(echo "ibase=16; $stringZ" | bc)
perl /opt/fhem/fhem.pl 7072 "setreading MeinGtag Batterie $decimal"
</pre>

Dem Device in FHEM (hier MeinGtag) ein userReading mit dem Namen '''Batterie''' hinzufügen.
Das Shellskript mit folgendem Befehl starten:
<pre>
./GtagBatterie.sh
</pre>
'''Wichtig ist hierbei,''' dass Skript mit "./" und nicht mit "sh" aufzurufen. Beim Aufruf mit "sh GtagBatterie.sh" produziert es einen Fehler
<pre>GtagBatterie.sh: 3: GtagBatterie.sh: Bad substitution </pre>

Das Reading wird auf den ausgelesenen Wert der Batterie gesetzt.

Hinweis: Es sollte für jeden G-Tag ein eigenes Skript abgelegt werden. Das Skript kann per crontab oder fhem Kommando (system) regelmäßig aufgerufen werden.

=== Batterieüberwachung (alle Devices vom Typ "MODE=lan-bluetooth") ===

Es gibt eine weitere Möglichkeit um den Batteriestatus von LE Devices abzurufen und in FHEM als Reading darzustellen.
Dabei wird der Batteriezustand für alle LE Devices, die bereits in FHEM konfiguriert sind und per lepresenced überwacht werden, automatisch in einem shell-Script ermittelt.
Näheres dazu im Forumartikel [https://forum.fhem.de/index.php/topic,56960.0.html [Erweiterung]: Anwesenheitserkennung/Batterieüberwachung].

Vorteile:
* Automatische Ermittlung aller in FHEM konfigurierten LE Devices
* Möglichkeit, diese Devices alternativ manuell im Script einzutragen
* Es werden nur Devices abgefragt, die im Status "present" sind, also mit ziemlicher Sicherheit auch verfügbar sind
* Ein eventuell auf dem FHEM telnet-Port gesetztes Passwort kann im Script hinterlegt werden

'''Voraussetzung:'''

'''Funktionierendes lepresenced''' - siehe [[Anwesenheitserkennung#Anleitung_f.C3.BCr_ein_LE_Device_.28z.B._Gtags.2CPebbles_etc..29|Anleitung für ein LE Device (z.B. Gtags,Pebbles etc.)]]

'''socat''' - TCP port forwarder
<pre>
sudo apt-get update && sudo apt-get install socat
</pre>

'''gatttool''' - Bestandteil von bluez

gatttool ist auf den meisten Distributionen im bluez-Paket, allerdings nicht bei Opensuse. Dort muss man das Sourcepaket von bluez installieren und selbst kompilieren.
gatttool sollte dann nach /usr/bin oder /usr/local/bin kopiert werden,

Zusätzlich zu den notwendigen Erweiterungen werden für die Ausführung von gatttool '''Root-Rechte benötigt'''!

Das Script selbst gibt es hier: [https://raw.githubusercontent.com/micky0867/lebattery/master/lebattery lebattery]

Am Besten unter /opt/fhem/script/lebattery speichern und ausführbar machen:
<source lang="bash">
sudo su -
mkdir /opt/fhem/script
cd /opt/fhem/script
wget https://raw.githubusercontent.com/micky0867/lebattery/master/lebattery
chmod 755 lebattery
</source>

Je nach Bedarf können im Script noch die folgenden 3 Parameter angepasst werden:
<source lang="bash">
# If allowed_telnetPort is protected by a password, add the password here
TELNETPASSWORD=""
# Attribute for batterylevel in FHEM
ATTRIBUT="batterylevel"
# Use this, if you dont want the script to determine the tags on its own
LETAGS=""
</source>

Das Skript wird dann unter root folgendermaßen gestartet:
<pre>
/opt/fhem/script/lebattery -v
</pre>

Ausgabe des Skripts, wenn es mit dem Verbose Parameter -v gestartet wird.

Beide Devices sind vom Typ NUT mini, das Device mit dem FHEM-Namen '''nut_Micky''' ist im Status '''absent'''. Das zweite Device ist im Status '''present'''.
<pre>
Determining address for nut_Micky ...
nut_Micky is in state absent, no further action required

Determining address for nut_Test ...
Fetching batterylevel for nut_Test (F3:44:04:81:54:89) ...
Setting batterylevel for nut_Test to 100%
</pre>

Mein crontab-Eintrag (User root) sieht so aus:
<pre>
3 3 * * * /opt/fhem/script/lebattery -v >/opt/fhem/script/lebattery.log 2>&1
</pre>
Damit wird jeden Morgen um 3 Minuten nach 3 Uhr der Zustand der Batterien aller Devices ermittelt und in FHEM abgespeichert. 
Bevor man das mit crontab macht, sollte man allerdings zunächst sicher stellen, dass es auch ohne crontab funktioniert....

Bei Problemen kann man auch erstmal schauen, ob das mit dem gattool überhaupt funktioniert:
<pre>
gatttool -t random -b <MAC-Adresse> --char-read --uuid 0x2a19

handle: 0x0017 value: 64
</pre>
In diesem Fall hat die Batterie noch 100% (hex 64).

=== Problemlösungen ===
Falls es Probleme beim Starten des Skripts gibt bzw. man das Skript ohne Reboot des Systems neustarten möchte, kann man dies per kill Befehl erledigen.
<source lang="bash">
ps -ef | grep lepresenced
sudo kill <pid>
</source>

Debuglevel lepresenced setzen:
{{Randnotiz|RNText=Um Debug-Meldungen zu bekommen (Vorsicht bei SD-Karten-Systemen wie dem RPi) - Hierbei werden die Schreibzyklen auf die SD-Karte erhöht.}}
<pre>
lepresenced --loglevel LOG_DEBUG
</pre>
Nur das wichtigste Loggen:
<pre>
lepresenced --loglevel LOG_WARNING
</pre>
Keinerlei LOG-Einträge
<pre>
lepresenced --loglevel LOG_EMERG
</pre>

==== Ansprechpartner ====
# {{Link2FU|5068|PatrikR}} (Patrick) für lepresenced
# [[Benutzer Diskussion:Devender|Devender]] ({{Link2FU|20043|Dirk}}) für Wiki und Doku

[[Kategorie:Code Snippets]]
[[Kategorie:Glossary]]

Benutzer:Hartenthaler

2016-11-24T15:36:37Z

Hartenthaler: neue Seite angelegt

Hallo!
Ich bin Hermann Hartenthaler aus Berlin.