FHEMWiki - Benutzerbeiträge [de]

IPCAM

2020-07-28T14:49:34Z

Micky0867: Weitere Parameter für Snapshots von Reolink-Kameras.

{{Infobox Modul
|ModPurpose=Einbindung von Netzwerkkameras
|ModType=d
|ModForumArea=Sonstiges
|ModTechName=49_IPCAM.pm
|ModOwner=mfr69bs ({{Link2FU|6|Martin Fischer}})}}

[[IPCAM]] ermöglicht die ereignis- oder zeitgesteuerte Erzeugung von Mitschnitten bei Netzwerkkameras. Außerdem ist es möglich, die Kamera im PTZ-Modus oder über eigene Befehle zu steuern.

== Voraussetzungen ==
Die Kamera(bilder) müssen über eine URL erreichbar sein.

== Definition ==
Das IPCAM Objekt wird angelegt mit
:<code><nowiki>define <name> IPCAM <ip[:port]> </nowiki></code>

Zusätzlich zum obigen Define muss zwingend noch das ''path'' Attribut gesetzt werden.

== Attribute ==
Die wichtigsten Attribute von ''IPCAM'' werden im Folgenden aufgeführt, die komplette Liste findet sich in der {{Link2CmdRef|Anker=IPCAMattr}}.

=== Authentifizierung ===
;basicauth
:Hinterlegung von Benutzernamen und Passwort

=== Eigene Befehle ===
;cmd01, cmd02, ... cmd15
:Festlegung von Befehlen, die nicht zu den vordefinierten gehören, z.B. <code>attr ipcam cmd01 led_mode=0</code>

=== Vordefinierte Befehle ===
;cmdPanLeft, cmdPanRight, cmdTiltUp, cmdTiltDown, cmdStep
:Diesen Befehlen können die Kameraspezifischen Werte zugeordnet werden, z.B. <code>attr ipcam cmdTiltUp command=0</code>

=== Pfade ===
;path
:...

== Unterstützte Netzwerkkameras ==
{{Randnotiz|RNText=Die Aufzählungen der unterstützten und der problematischen Netzwerkkameras sollten ergänzt werden, sobald neue Erkenntnisse vorliegen; beide Listen sind nicht vollständig.}}
Bei den folgenden Netzwerkkameras ist gesichert, dass sie durch das ''IPCAM'' Modul unterstützt sind:
* {{Link2Forum|Topic=33347|Message=257115|LinkText=Foscam 9805W}}
* Foscam FI9831P
* {{Link2Forum|Topic=13826|LinkText=Instar 2905}}
* {{Link2Forum|Topic=100493|LinkText=IN-8015 Full HD}}
* {{Link2Forum|Topic=36201|LinkText=IN-6001HD}}
* {{Link2Forum|Topic=11664|LinkText=Instar 6011, 6012, 2905}}
* {{Link2Forum|Topic=58676|LinkText=Instar IN-5905HD, IN-5907HD, IN-6014HD, IN-6012HD-PoE}}
* {{Link2Forum|Topic=15217|LinkText=WansView (Modell nicht näher spezifiziert)}}
* {{Link2Forum|Topic=11664|Message=158052|LinkText=Wansview 620, 625, 6012}}
* Axis 205
* D-Link DCS-933
* Mobotix (jedenfalls S26 und Q25)
* Xiaomi Dafang (nur mit alternativer Firmware)

Nicht gesichert, ob die Kamera unterstützt wird bzw. ob alle Funktionen nutzbar sind:
* {{Link2Forum|Topic=33347|LinkText=Foscam FI9831W}}

=== Pfad-Parameter für Axis 205 ===
<pre>
attr Cam1 path /jpg/image.jpg
</pre>

=== Pfad-Parameter für D-Link DCS-933 ===
<pre>attr Cam1 path image.jpg</pre>

=== Parameter für Hikvision DS-2CD2032-I ===
Mit folgenden Parameter wurde (lt. diesem {{Link2Forum|Topic=39932|Message=322269|LinkText=Forenbeitrag}}) die Hikvision DS-2CD2032-I erfolgreich betrieben:
<pre>
define Cam1 IPCAM 192.168.xxx.xxx
attr Cam1 basicauth <username>:<passwort>
attr Cam1 delay 0
attr Cam1 group Kamera
attr Cam1 icon it_camera
attr Cam1 path Streaming/channels/1/picture?snapShotImageType=JPEG
attr Cam1 snapshots 1
attr Cam1 storage /opt/fhem/www/snapshots/cam1
</pre>

=== Pfad-Parameter für Foscam FI9831P ===
Die Version ist ohne basicauth und hat Nutzer und Passwort direkt in der URL. Kann natürlich geändert werden.
Sämtliche Befehle für die Foscam HD Kameras findet man [https://www.manualslib.com/manual/728928/Foscam-Ip-Camera.html hier]
<pre>
define IPKamera IPCAM <ip>:<port>
attr IPKamera cmd01 cmd=ptzStopRun&usr=xxx&pwd=xxx
attr IPKamera cmdPanLeft cmd=ptzMoveLeft&usr=xxx&pwd=xxx
attr IPKamera cmdPanRight cmd=ptzMoveRight&usr=xxx&pwd=xxx
attr IPKamera cmdPos01 cmd=ptzGotoPresetPoint&name=<Nameposition>&usr=xxx&pwd=xxx
attr IPKamera cmdTiltDown cmd=ptzMoveDown&usr=xxx&pwd=xxx
attr IPKamera cmdTiltUp cmd=ptzMoveUp&usr=xxx&pwd=xxx
attr IPKamera path cgi-bin/CGIProxy.fcgi?usr=xxx&pwd=xxx&cmd=snapPicture2
attr IPKamera pathCmd cgi-bin/CGIProxy.fcgi
attr IPKamera pathPanTilt cgi-bin/CGIProxy.fcgi?usr=xxx&pwd=xxx
attr IPKamera storage ./www/images/webcam
</pre>

=== Pfad-Parameter für Mobotix ===
<pre>
attr IPKamera path /record/current.jpg
</pre>

=== Pfad-Parameter für reolink (E1 Zoom) ===
<pre>
attr IPKamera path cgi-bin/api.cgi?cmd=Snap&width=<Breite>&height=<Hoehe>&channel=0&rs=<irgendwas>&user=Username&password=Passwort
</pre>

Beispiel:
<pre>
attr IPKamera path cgi-bin/api.cgi?cmd=Snap&width=1024&height=768&channel=0&rs=12345&user=User&password=Pwd
</pre>

Weitere Befehle sind aktuell noch nicht bekannt.

Es gibt eine spärliche Doku bzgl. cgi hier: https://cdn.reolink.com/wp-content/uploads/2017/01/Reolink-CGI-command-v1.61.pdf

Allerdings wird wohl für die Steuerbefehle (PTZ) ein Post-Request benötigt.

Weitere Kommandos wurden hier gesammelt: https://community.jeedom.com/t/reolink-liste-de-commandes-via-api-maj-29-04/25565

=== Einstellungen für Foscam C2 und Foscam R2 ===
Eine ausführliche Beschreibung zur Benutzung der IP Kameras Foscam C2 und Foscam R2 findet sich in {{Link2Forum|Topic=84677|LinkText=diesem Forenthread}}.

=== Parameter für Xiaomi Dafang ===
Diese Parameter gelten bei installierter alternativer Firmware von [https://github.com/EliasKotlyar/Xiaomi-Dafang-Hacks hier]
<pre>

Attributes:
attr IPKamera cmdPanLeft cmd=motor_left
attr IPKamera cmdPanRight cmd=motor_right
attr IPKamera cmdTiltDown cmd=motor_down
attr IPKamera cmdTiltUp cmd=motor_up
attr IPKamera delay 10
attr IPKamera event-on-update-reading snapshots
attr IPKamera icon it_camera
attr IPKamera path cgi-bin/currentpic.cgi
attr IPKamera pathPanTilt cgi-bin/action.cgi?
attr IPKamera snapshots 5
attr IPKamera storage /opt/fhem/www/ipcamera/dafang_1/shot
</pre>

=== Parameter für INSTAR Full HD ===
Die vollständige Schnittstelle und weitere Beispiele können direkt im [https://wiki.instar.de/Erweitert/ INSTAR-Wiki] eingesehen werden.<br>
Zur Integration einer INSTAR Full HD CAM können zum Beispiel folgende Attribute verwendet werden:
<pre>
attr INSTAR_8015 basicauth {USERNAME}:{PASSWORD}
attr INSTAR_8015 cmd01 cmd=setinfrared&-infraredstat=auto
attr INSTAR_8015 cmd02 cmd=setinfrared&-infraredstat=close
attr INSTAR_8015 cmd03 cmd=setinfrared&-infraredstat=open
attr INSTAR_8015 cmd04 cmd=setmdalarm&-aname=ftprec&-switch=on
attr INSTAR_8015 cmd05 cmd=setmdalarm&-aname=ftprec&-switch=off
attr INSTAR_8015 cmd06 cmd=setplanrecattr&-planrec_enable=0
attr INSTAR_8015 cmd07 cmd=setplanrecattr&-planrec_enable=1
attr INSTAR_8015 cmd08 cmd=setplanrecattr&-planrec_chn=11
attr INSTAR_8015 cmd09 cmd=setplanrecattr&-planrec_chn=12
attr INSTAR_8015 cmd10 cmd=manualrec&-act=on
attr INSTAR_8015 cmd11 cmd=manualrec&-act=off
attr INSTAR_8015 cmd12 cmd=sdfrmt
attr INSTAR_8015 cmd13 cmd=preset&-act=goto&-number=0
attr INSTAR_8015 cmd14 cmd=preset&-act=goto&-number=1
attr INSTAR_8015 cmd15 cmd=preset&-act=goto&-number=2
attr INSTAR_8015 cmdPanLeft -act=left
attr INSTAR_8015 cmdPanRight -act=right
attr INSTAR_8015 cmdPos15 -act=stop
attr INSTAR_8015 cmdTiltDown -act=down
attr INSTAR_8015 cmdTiltUp -act=up
attr INSTAR_8015 credentials /<ipcam-conf-path>/ipcam.conf
attr INSTAR_8015 eventMap /pos 15:MOVE-STOP/pan left:MOVE-LEFT/pan right:MOVE-RIGHT/tilt up:MOVE-UP/tilt down:MOVE-DOWN/cmd 1:IR-LED-auto/cmd 2:IR-LED-off/cmd 3:IR-LED-on/cmd 4:FTP-rec-on/cmd 5:FTP-rec-off/cmd 6:REC-SD-DISABLE/cmd 7:REC-SD-ENABLE/cmd 8:REC-SD-QUAL-HIGH/cmd 9:REC-SD-QUAL-MID/cmd 10:MAN-REC-Start/cmd 11:MAN-REC-Stop/cmd 12:FORMAT-SD-CARD/cmd 13:POS-WZ/cmd 14:POS-Flur/cmd 15:POS-Park/
attr INSTAR_8015 icon it_camera
attr INSTAR_8015 path tmpfs/snap.jpg
attr INSTAR_8015 pathCmd param.cgi
attr INSTAR_8015 pathPanTilt ptzctrl.cgi?-step=
attr INSTAR_8015 scheme https
attr INSTAR_8015 storage /<ipcam-snapshot-path>/snapshots
attr INSTAR_8015 webCmd POS-WZ:POS-Flur:POS-Park
</pre>

== Nicht unterstützte Netzwerkkameras ==
{{Randnotiz|RNTyp=y|RNText=Die hier aufgeführten Netzwerkkameras sind definitiv nicht unterstützt oder es gibt gravierende, hier beschriebene Einschränkungen.}}
;TRENDnet TV-IP320PI
:Aufruf der Funktion <code>get ''myCam'' image</code> führt zur Fehlermeldung ''...invalid Format''; auf Kamerabild oder Stream kann jedoch über die URL camHostnameOrIP/Streaming/channels/1/Picture (Bild) bzw. camHostnameOrIP/Streaming/channels/1/httpPreview (Stream) zugegriffen werden.

== Generierte Ereignisse ==
Das Modul ''IPCAM'' generiert die Ereignisse
* <code><nowiki>last: <name_of_device>_snapshot.<image_extension></nowiki></code>
* <code><nowiki>snapshots: <total_number_of_taken_snapshots_at_end></nowiki></code>

== Bekannte Probleme ==
Derzeit (08/2015) ist das Logging aus dem Modul zumindest lückenhaft und verbesserungsfähig. So sollten z.B. einige weitere Meldungen zur Fehlereingrenzung bei der Einrichtung eines IPCAM Objekts eingefügt werden:
* Ausgabe des kompletten Pfads / der URL, die bei der Erzeugung eines Snapshots aus einzelnen Bestandteilen zusammengesetzt wird
* Die Zuordnung von Meldungen zu ''verbose''-Leveln sollte kontrolliert und ggf. umgestellt werden
* siehe auch diesen {{Link2Forum|Topic=39932|LinkText=Forenthread}}, der Beschreibung von Problemen, eine Hikvision IPCam in Betrieb zu nehmen

Außerdem müsste das Modul dringend auf die aktuelle Form des Logging, [[verbose|verbose/Log3]], umgestellt werden.

Eine mögliche Lösung für das Problem "Wrong or not supported image format: unknown" habe ich hier beschrieben: {{Link2Forum|Topic=10772|Message=425265|LinkText=Forenbeitrag}}

== Links ==
* Forenthread zur {{Link2Forum|Topic=10772|LinkText=Erweiterung des IPCAM Moduls}}
* Forenthread zum Thema {{Link2Forum|Topic=21005|LinkText=Bewegungserkennung}}
* Forenthread zum Thema {{Link2Forum|Topic=30723|LinkText=Bewegungsmelder der Kamera "anzapfen"}}
* Webseite des Modulautors zum Thema [http://www.fischer-net.de/hausautomation/videoueberwachung.html Videoüberwachung]

Diskussion:List

2017-12-09T18:05:37Z

Micky0867: Die Seite wurde neu angelegt: „Mir ist gerade aufgefallen, dass die Ausgabe von<br> list KEY=VALUE<br> variiert, je nachdem, ob es ein oder mehrere Devices gibt, die darauf matchen. Das…“

Mir ist gerade aufgefallen, dass die Ausgabe von<br>
list KEY=VALUE<br>
variiert, je nachdem, ob es ein oder mehrere Devices gibt, die darauf matchen.

Das Wiki sagt:<br>
''Mit dem Befehl
list TYPE=FS20
''wird eine Liste (die Namen) aller Geräte des Typs FS20 ausgegeben.

Bei nur einem passenden Gerät werden aber alle Attribute des Geräts ausgegeben.

--[[Benutzer:Micky0867|Micky0867]] ([[Benutzer Diskussion:Micky0867|Diskussion]]) 19:03, 9. Dez. 2017 (CET)

Anwesenheitserkennung

2017-03-07T20:26:28Z

Micky0867: Typen random/public

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 (presenced/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 [http://fhem.de/commandref.html#PRESENCE 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.pm einzufügen, sollte diese noch nicht vorhanden sein muss diese aus dem Template welches unter Edit Files zu finden ist erzeugt werden.
'''Achtung, das ist nicht der komplette Inhalt der 99_myUtils!''' Das ist nur die einzelne Routine

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

==== Beispiel Anwesenheitserkennung mittels UniFi Controller ====

Die Anwesenheitserkennung bei Geräten in Verbindung mit UniFi-Produkten funktioniert selbst dann, wenn sich die Geräte im PowerSave-Modus befinden.

Beachte: Die Geräte werden erst ungefähr nach 5 Minuten, nachdem das Gerät das WLAN verlassen hat als disconnected angezeigt.

<code>define <NAME> PRESENCE function {ReadingsVal("<UniFi>","<NamedDevice>","") eq "connected" ? 1:0}</code>

=== Eventbasierte Anwesenheitserkennung am Beispiel mittels UniFi Controller ===
Der Vorteil gegenüber der Function-Variante ist, dass diese Variante ohne Blocking.pm-Overhead direkt ausgeführt werden kann und in "Echtzeit" abläuft (siehe {{Link2Forum|Topic=40287|Message=562823}}).

<code>define <NAME> PRESENCE event UniFi:NamedDevice:.disconnected UniFi:NamedDevice:.connected</code>

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

=== Benachrichtigung bei Batteriewechsel ===
Mit Hilfe des PRESENCE-Moduls kann man auch bei batteriebetriebenen Geräten eine Meldung ausgeben, sobald ein Batteriewechsel ansteht. Hier im Beispiel wird der Eve-Room-Sensor von Elgato eingebunden und anschließend mit einer DOIF-Nachricht ausgestattet.
Die Bluetooth-Adresse des Sensors kann mittels eines BLE-Scanners ermittelt werden.

<pre>
# PRESENCE-Modul für Elgato Eve Room Sensor mit Aktualisierung aller 6 Minuten
define Eve_Room_BLE lan-bluetooth <Bluetooth-Adresse> 127.0.0.1:5333 360
</pre>

Anschließend wird eine DOIF-Regel definiert, die eine Nachricht an die installiere [[FHEM_APP|FHEM App]] absendet:
<pre>
define Eve_Room_BLE_Battery_Msg DOIF ([Eve_Room_BLE] eq "absent") (set Msg_iPhone message 'Batteriewechsel beim Eve Room Sensor im Wohnzimmer.')
attr Eve_Room_BLE_Battery_Msg wait 600
</pre>

Die Aktualisierung des PRESENCE-Eintrages sollte nicht größer sein als das WAIT-Attribut der DOIF-Regel. Ansonsten könnte eine kurze Systemstörung zum Fehlalarm führen.

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

{{Randnotiz|RNText=Beide hier beschriebenen Wege (presenced/lepresenced) können parallel auf dem selben BT-Dongle laufen, da sich die Ports unterscheiden! }}
'''Wo finde ich denn lepresenced?'''

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

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

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 <br />'''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>

'''gawk''' - Zum extrahieren der Daten
<pre>
sudo apt-get update && sudo apt-get install gawk
</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.<br>
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 <Typ> -b <MAC-Adresse> --char-read --uuid 0x2a19

handle: 0x0017 value: 64
</pre>
In diesem Fall hat die Batterie noch 100% (hex 64).<br>
Der Typ ist abhängig vom Hersteller und kann public (G-Tags) bzw. random (Nut) sein. Im Zweifelsfall beides ausprobieren.

=== Anwesenheitserkennung / Anwesenheitsbenachrichtigung mit G-Tags ===

Ein Skript zur Nutzung der Gigaset G-TAGs zur Alarmierung bei öffnen und schließen von Türen und zur Anwesenheitserkennung, um die Alarmierung zu aktivieren bzw. deaktivieren.
Es kann verwendet werden um die Anwesenheit von mehrern Personen im Haushalt zu erkennen. Dabei wird eingeschränkt, dass nur bestimmte Personen die Alarmierung aktivieren können ( Eltern/Kind -Beziehung ).
Des Weiteren werden im Beispiel die Eltern benachrichtigt wenn eins der Kinder das Haus verlässt und die Eltern nicht anwesend sind.

{{Randnotiz|RNText= Namen der G-Tags in den Skripten bitte Anpassen!}}

Für die ''Notify'' und die ''RESIDENTS-Erweiterung'' wird ein Dummy benötigt.
<pre>
define Alarm dummy
attr Alarm devStateIcon aktiv:secur_locked@red inaktiv:secur_open@lightgreen
attr Alarm eventMap on:aktiv off:inaktiv
attr Alarm setList on off
attr Alarm webCmd aktiv:inaktiv
attr Alarm room Alarm
</pre>

====Mit Notify ====
<pre>
gtag.*.presence:.* {Anwesenheit_check("$EVTPART1", "$NAME")}
</pre>

Code für die 99_myUtils.pm
<pre>
### GTAG ANWESENHEITS CHECK
sub Anwesenheit_check($$) {
my ($EVENT, $NAME) = @_;

# gtag_rot - Alias Marco
# gtag_schwarz - Alias Ulli
# gtag_gruen - Alias Frida
# gtag_orange - Alias Hannah

my $RESIDENT = "rr_"; # Alle GTAGs sind Standardmäßig Residents Roommate
# $RESIDENT = "rg_" if (($NAME eq "gtag_orange") xor ($NAME eq "gtag_weis")); # Hier nur Gäste (Roomguest) Auskommentiert, da ich es so nicht brauche
my $ROOMMATE = ("$RESIDENT" . "$NAME"); # Residentsname zusammenbauen
my $ALIASNAME = AttrVal($ROOMMATE,'alias',$ROOMMATE); # ALIAS des Roommates auslesen

my $GTAG1 = Value('gtag_rot'); # ELTERN
my $GTAG2 = Value('gtag_schwarz'); # ELTERN

my $STATUS = "wahrscheinlich gerade los";
$STATUS = "anwesend" if ($EVENT eq "present"); # Status: anwesend
$STATUS = "unterwegs" if ($EVENT eq "absent"); # Status: unterwegs

Log 1, "$ALIASNAME ist $STATUS."; # LOG Eintrag erzeugen

if (($EVENT eq "present" && Value("Alarm") eq "aktiv") && ($NAME eq "gtag_gruen" xor $NAME eq "gtag_orange")) {
fhem("set teleBot send ALARMIERUNG BLEIBT AKTIV: $ALIASNAME ist da..."); # Telegram
# fhem("set Infopush msg 'ALARMIERUNG BLEIBT AKTIV' '$ALIASNAME ist da...'"); # Pushover
}
elsif (($EVENT eq "present" && Value("Alarm") eq "aktiv") && ($NAME eq "gtag_rot" xor $NAME eq "gtag_schwarz")) {
fhem("set teleBot send ALARMIERUNG INAKTIV: $ALIASNAME ist da...; set Alarm inaktiv"); # Telegram
# fhem("set Infopush msg 'ALARMIERUNG INAKTIV' '$ALIASNAME ist da...'; set Alarm inaktiv"); # Pushover
}
elsif (($EVENT eq "absent" && Value("Alarm") eq "aktiv") && ($NAME eq "gtag_gruen" xor $NAME eq "gtag_orange")) {
fhem("set teleBot send ALARMIERUNG BLEIBT AKTIV: $ALIASNAME hat das Haus verlassen."); # Telegram
# fhem("set Infopush msg 'ALARMIERUNG BLEIBT AKTIV' '$ALIASNAME hat das Haus verlassen.'"); # Pushover
}
elsif (($EVENT eq "absent" && Value("Alarm") eq "inaktiv") && ($GTAG1 eq "absent" && $GTAG2 eq "absent")) {
fhem("set Alarm aktiv; set teleBot send ALARMIERUNG AKTIV: $ALIASNAME hat das Haus verlassen."); # Telegram
# fhem("set Alarm aktiv; set Infopush msg 'ALARMIERUNG AKTIV' '$ALIASNAME hat das Haus verlassen.' '' 0 ''"); # Pushover
}
}
</pre>

<br>

====Mit Notify und Integration des RESIDENTS-MODUL====

Der hier beschriebene Code erweitert die Funktionen unter dem Punkt 5.93.
Das Notify muss daher mit der folgenden Zeile erweitert werden.

<pre>
define Alarm_AnwesenheitCheck notify gtag.*.presence:.* { Anwesenheit_check("$EVTPART1", "$NAME"), Anwesenheit_check_resi("$NAME") }
</pre>

Zusätzlicher Code für die 99_myUtils.pm um die RESIDENTS Funktion nutzen zu können:
<pre>
### RESIDENTS
sub Anwesenheit_check_resi($) {
my ($NAME) = @_;
my $ALIASNAME = AttrVal($NAME,'alias',$NAME); # ALIASNAME des GTAGs auslesen

my $RESIDENT = "rr_"; # Als Standard sind alle GTAGs Roommates
$RESIDENT = "rg_" if (($NAME eq "gtag_orange") xor ($NAME eq "gtag_weis")); # Hier nur GTAG Namen der Gäste (Roomguest)
my $ROOMMATE = ("$RESIDENT" . "$ALIASNAME"); # Residentsname zusammenbauen

if (ReadingsVal($NAME,'presence',$NAME) eq "absent") {
fhem("set $ROOMMATE absent"); # Resisents Status von Roommates setzen
}
elsif(ReadingsVal($NAME,'presence',$NAME) eq "present") {
fhem("set $ROOMMATE home"); # Resisents Status von Roommates setzen
}
}
</pre>
<br>

====Mit Notify und Fenster/Tür. -Kontakt Überwachung====

Erweiterung für die Überwachung von Fenster/Tür. -Kontakten. Dazu sind zwei weitere Notifys notwendig die auf die Trigger der Kontakte regagieren
und so eine weitere Funktion in der 99_myUtils.pm ansprechen. Die Notifys triggern auf Kontakte die mit dem Namen Kontakt* beginnen.
Sollten die eigenen Fenster/Tür. -Kontakt anderen Namen besitzen, müssen die Skripte dementsprechend angepasst werden.
<pre>
define Alarm_Kontaktmeldung notify Kontakt.*:contact:.* {Kontakt_Meldung("$EVTPART1", "$NAME")}
</pre>
<pre>
define Alarm_Sabotagealarm notify Kontakt.*.sabotageError:.on {Kontakt_Sabotage("$EVTPART1", "$NAME")}
</pre>

Zusätzlicher Code für die 99_myUtils.pm um die TÜRKONTAKTE-Meldung nutzen zu können:
<pre>
### TÜRKONTAKTE-Meldung/Zustand
sub Kontakt_Meldung($$) {
my ($EVENT, $NAME) = @_;
my $ALIASNAME = AttrVal($NAME,'alias',$NAME);
Log 1, "$ALIASNAME wurde $EVENT";
if (ReadingsVal("Alarm", "state", "on") eq "on") {
fhem("set teleBot send $ALIASNAME wurde $EVENT"); # Nachricht über Telegram
# fhem("set Infopush msg '$ALIASNAME' '$ALIASNAME wurde $EVENT'"); # Nachricht über Pushover
}
}

### TÜRKONTAKTE-Sabotagealarm

sub Kontakt_Sabotage($$) {
my ($EVENT, $NAME) = @_;
my $ALIASNAME = AttrVal($NAME,'alias',$NAME);
Log 1, "$ALIASNAME meldet Sabotagealarm";
fhem("set teleBot send Alarm: $ALIASNAME meldet Sabotagealarm"); # Nachricht über Telegram
# fhem("set Infopush msg 'Alarmanlage' '$ALIASNAME meldet Sabotagealarm' '' 2 ' ' 60 600 "); # Nachricht über Pushover
}
</pre>
<br>

==== Hinweis zur Benutzung / Fehlerhandling ====

Der Alarm dummy hat den Zustand on:off. Die Bezeichnungen und Namen müssen 1:1 übernommen werden damit das Script funktioniert.
Andernfalls müssen die Bezeichnungen für z.B. absent:unterwegs und present:anwesend - angepasst werden.
Die Benachrichtigung kann aktuell per ''Telegram'' sowie ''Pushover'' ('''Achtung mit zweiterem sind Abokosten verbunden!''') realisiert werden.
Diskussion zum Thema im Forum unter: [[https://forum.fhem.de/index.php/topic,64080.0.html]]
<br>

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

FHEM Tablet UI FAQ

2016-10-07T21:05:10Z

Micky0867: UI zeigt Statusänderungen erst nach Neuladen der Seite

==Das UI zeigt Statusänderungen erst nach 30s==

Sehr wahrscheinlich hast du die Aktualisierungsmethode '''longPoll''' deaktiviert. Es gibt zwei Aktualisierungsmethoden: shortPoll und longPoll.

'''shortPoll''' aktualisiert den Status aller Widgets auf einmal. Bei aktivem longPoll ist das shortPoll-Interval mit 15 Minuten festgelegt, ansonsten mit 30 Sekunden. shortPoll kann nicht deaktiviert werden.

'''longPoll''' benutzt den eventgesteuerten Benachrichtigungsdienst von fhem um Statusänderungen direkt zu aktualisieren. Das heisst, fhem sendet eine Nachricht per longPoll sobald sich ein Status ändert und das UI aktualisiert daraufhin automatisch nur die betroffenen Widgets. longPoll ist in fhem standardmäßig aktiv, kann aber deaktiviert werden. Im Zweifel bitte prüfen ob an der verwendeten [[FHEMWEB]]-Instanz das Attribut "longpoll 1" gesetzt ist (`list WEB`). Falls nicht, bitte `attr WEB longpoll 1` in fhem ausführen ("WEB" ist ggf. durch den Namen der verwendeten [[FHEMWEB]]-Instanz zu ersetzen). Im UI ist longPoll ebenfalls standardmäßig aktiv, kann aber ebenfalls deaktiviert werden. Bitte prüfen, ob der HTML-Code den Meta-Tag `<meta name="longpoll" content="1">` enthält. Falls nicht, bitte so übernehmen.

==Das UI zeigt Statusänderungen erst nach Neuladen der Seite im Browser==

Das kann durch einen zwischengeschalteten Proxy bzw. Reverse-Proxy passieren. Wenn nginx als Reverse-Proxy benutzt wird, kann das Problem mit der folgenden Konfiguration in nginx behoben werden:
<pre>
location /fhem {
proxy_pass http://meinfhemserver:8083/fhem;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_buffering off;
proxy_ignore_client_abort off;
break;
}
</pre>

==Das UI zeigt Statusänderungen gar nicht an==

Prüfe zunächst, ob die Statusänderungen nicht vielleicht nur verspätet kommen (siehe FAQ [[#Das UI zeigt Statusänderungen erst nach 30s|Das UI zeigt Statusänderungen erst nach 30s]]). Wenn tatsächlich keine Statusänderungen im UI ankommen, sind die Werte der data-get-on/off Attribute vermutlich falsch gesetzt. Prüfe im [[Event_monitor]] welche Werte die Events, die bei Statusänderungen erzeugt werden, genau haben und passe deine Attribute entsprechend an. Manchmal weichen die erzeugten Events von den Namen der zugehörigen Readings ab. Sollten allerdings gar keine Events erzeugt werden (manche Module erzeugen nicht für jede Readingsänderung ein Event), dann kann die longPoll-Aktualisierung für diese Statusänderung nicht funktionieren.

==Wie öffne ich die Javascript-Konsole?==

"FHEM Tablet UI" benutzt Javascript und um Fehlermeldungen nachvollziehen zu können ist es oft erforderlich Informationen aus der "Javascript Konsole" des Browsers zu posten. Je nach Browser wird die Konsole mit einer anderen Tastenkombination geöffnet:

{| class="wikitable"
|-
! Browser
! Tastenkombination
|-
|Chrome:
|{{Taste|Ctrl}} + {{Taste|Shift}} + {{Taste|J}}
|-
|Firefox:
|{{Taste|Ctrl}} + {{Taste|Shift}} + {{Taste|K}}
|-
|Internet Explorer:
|{{Taste|F12}}
|-
|Opera:
|{{Taste|Ctrl}} + {{Taste|Shift}} + {{Taste|I}}
|-
|Safari:
|{{Taste|Cmd}} + {{Taste|Opt}} + {{Taste|C}}
|}

==Wie kann ich eigene Icons verwenden?==

Die Button-ähnlichen Widgets (switch, push, symbol etc.) verwenden Fonts um Icons anzuzeigen. Standardmässig wird der Font [http://fortawesome.github.io/Font-Awesome/ Font-Awesome] mitgeliefert, der mehr als [http://fortawesome.github.io/Font-Awesome/icons/ 500 Icons] mitbringt. Wenn diese Auswahl nicht ausreichend ist, kann ein eigener Iconfont eingebunden werden. Am einfachsten kann ein solcher Font mit Hilfe der [https://icomoon.io/app IcoMoon App] erstellt werden.

===IcoMoon App===
IcoMoon bietet verschiedene Icon-Libraries aus denen gewählt werden kann. Viele davon sind unter kostenlosen Lizenzen verfügbar, die App weist transparent darauf hin, wenn man eine (bzw. aus einer) nicht kostenfreien Library auswählt. Standardmässig wird die Library "IcoMoon Free" angeboten, weitere können über den Button "Add Icons From Library" ausgewählt werden. Zielführender ist das "search" Feld oben zu verwenden. Die Icons aller Libraries sind verschlagwortet und über das Suchfeld findbar. Darüber hinaus können eigene Grafiken hochgeladen werden ("Import Icons"), diese müssen im SVG-Format vorliegen.

Nach abgeschlossener Icon-Auswahl wird über den großen Button "Generate Font" (unten) ein Font erstellt. Dazu sollte zunächst oben unter "Preferences" ein Font Name (z.B. "Font 1") und ein eindeutiger Class-Prefix (zB "font1-") gewählt werden. Insbesondere der Class-Prefix ist wichtig und sollte nicht zu lang ausfallen. Er wird bei der Benutzung der Icons dem Icon-Namen vorangestellt. Das Class-Prefix des mitgelieferten Font-Awesome lautet "fa-". Danach kann der Font über den Button "Download" herunter geladen werden.

===Nachbearbeitung===
Im heruntergeladenen Zip-file aus der IcoMoon App muss die Zeile
:<code>line-height: 1;</code>
auskommentiert oder gelöscht werden, da die Anzeige in den Buttons ansonsten "verschoben" wirkt.

===In FTUI einbinden===
Der gesamte Inhalt des Ziparchivs kann jetzt in ein eigenes Verzeichnis innerhalb der Fhem Tablet UI Installation kopiert werden, zB nach "customfonts/font1". Es sollte nicht in eines der Standardverzeichnisse kopiert werden, da dort die Gefahr besteht, dass die Dateien vom Updatemechanismus überschrieben werden. In der/den HTML-File(s) ist jetzt im <head>-Bereich noch der Pfad zur style.css aus dem Archiv anzugeben:
:<source lang="html5">
<link rel="stylesheet" href="customfonts/font1/style.css">
</source>

=== Verwenden ===
Jetzt können die eigenen Icons in den Widgets verwendet werden, indem sie im Attribut data-icon (bzw. data-icons, data-background-icon..) eingetragen werden; zB:
:<source lang="html5">
<div data-type="push" data-device="WECKER" data-icon="font1-alarmclock"></div>
</source>
Wichtig: Daran denken, vor dem Namen des Icons das selbst gewählte Class-Prefix (hier "font1-") zu notieren.

==Warum führen mich Links auf andere Seiten zurück zu FHEMWEB?==
Zur Auslieferung des FTUI an den Browser wird das Modul [http://fhem.de/commandref.html#HTTPSRV HTTPSRV] verwendet. Leider zeigt es ein seltsames Verhalten, wenn man ausgehend von einer Adresse ohne abschliessenden Slash oder Dateinamen auf einen Link mit relativem URL (also zB nur ein Dateiname) klickt. Der relative Pfad wird in so einem Fall ab dem letzten Slash der Adresse der Ausgangsseite ermittelt.

Ein Beispiel: Wir starten bei ''<nowiki>http://host:8083/fhem/tablet</nowiki>'' und klicken auf einen Link zur Datei ''wohnzimmer.html''. Dieser Klick wird '''nicht''' auf ''<nowiki>http://host:8083/fhem/tablet/wohnzimmer.html</nowiki>'' geleitet, sondern zu ''<nowiki>http://host:8083/fhem/wohnzimmer.html</nowiki>''. Da es ''<nowiki>http://host:8083/fhem/wohnzimmer.html</nowiki>'' nicht gibt, wird man darauf postwendend zu ''<nowiki>http://host:8083/fhem</nowiki>'' gebracht. Startet man den gleichen Vorgang ausgehend von ''<nowiki>http://host:8083/fhem/tablet/</nowiki>'' (mit Slash am Ende), wird man wie erwartet nach ''<nowiki>http://host:8083/fhem/tablet/wohnzimmer.html</nowiki>'' gebracht.

Darüber hinaus kann die Startseite - typischerweise index.html - nicht gefunden werden, wenn ein abschliessender Slash, aber kein Dateiname notiert wird.

Es sollte also insbesondere in der Definition des Links für FHEMWEB darauf geachtet werden, den vollen Pfad zur Startseite zu notieren (<code>define tablet_ui HTTPSRV tablet/index.html ./www/tablet Tablet Frontend</code>). Das gleiche beim Anlegen von Lesezeichen.

== Wie kann ich ein eigenes Hintergrundbild einbinden, anstatt des einfachen schwarz? ==
* Bild besorgen : "Einfach mal Tante Google's Fotoalbum befragen. ;)"
* In /opt/fhem/www/tablet den Ordner /images angelegen und Bild dort ablegen und in die **-custom.css eintragen.
<source lang="css"> body {
background:#000000 url(../images/orange_blue_bg.jpg) 0 0 no-repeat
}</source>

:So wird der Hintergrund aus der originalen CSS überschrieben.
* Wenn nicht schon geschehen, die CSS in den HTMLs verlinken/deklarieren:
:<source lang="html5">
<link rel="stylesheet" href="/fhem/tablet/css/fhem-tablet-ui-custom.css" />
</source>

Kleiner Tipp: Das Bild in genau der Auflösung suchen/herunterladen, in der die Seite später im FTUI dargestellt werden soll.

Das UI mit Hintergrundbild sieht besser aus, wenn der Vordergrund transparent erscheint.
Dazu muss noch folgendes in die fhem-tablet-ui-custom.css eingefügt werden:

<source lang="css">
.semitransparent {
background: rgba(0, 0, 0, 0.7) !important;
}
</source>

Diese Klasse benutzt dann man bei den Gridster Elementen:

<source lang="html5">
<li data-row="1" data-col="1" data-sizex="1" data-sizey="5" data-template="menu.html" class="semitransparent"></li>
</source>

==Wie baue ich ein Menü mit dem Pagetab Widget auf?==

Grundsätzliche Struktur:

index.html -> Header-Files (css/js), Nur ein Gridster-Element zum Import des Templates "menu.html"

menu.html -> eine Liste von Pagetab Widgets mit Links zu den Unterseiten

sub*.html -> Unterseiten mit den eigentlichen Widgets, keine Header-Files (css/js), ein Gridster-Element für menu.html

- Die index.html (Startseite) ist minimal und beinhaltet nur das Menu mit den 1-n Pagetabs und alle Links zu CSS und Scripts
<pre>
<!DOCTYPE html>
<html>
<head>
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no" />
<meta name="widget_base_width" content="74">
<meta name="widget_base_height" content="71">
<meta name="mobile-web-app-capable" content="yes">
<meta name="apple-mobile-web-app-capable" content="yes">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="longpoll" content="1"> 
<meta name="debug" content="1"> 
<meta http-equiv="Cache-Control" content="no-store" />

<link rel="stylesheet" href="/fhem/tablet/lib/jquery.gridster.min.css" />
<link rel="stylesheet" href="/fhem/tablet/css/fhem-tablet-ui.css" />
<link rel="stylesheet" href="/fhem/tablet/lib/font-awesome.min.css" />
<link rel="stylesheet" href="/fhem/tablet/lib/jquery.toast.min.css" />



<link rel="stylesheet" href="/fhem/tablet/css/fhem-tablet-ui-user.css" />

<script src="/fhem/pgm2/jquery.min.js" defer></script>
<script src="/fhem/tablet/lib/jquery.toast.min.js" defer></script>
<script src="/fhem/tablet/lib/jquery.gridster.min.js" defer></script>
<script src="/fhem/tablet/js/fhem-tablet-ui.min.js" defer></script>



<title>FHEM-Tablet-UI</title>
</head>
<body>
<div class="gridster">
<ul>
<li data-row="1" data-col="1" data-sizex="1" data-sizey="9" data-template="menu.html"></li>
</ul>
</div>
</body>
</html>
</pre>

- die per Template eingebundene menu.html enthält die Pagetabs mit den Links zu den Unterseiten
<pre>
<html>
<body>
<header>MENU</header>
<div class="cell">
<div data-type="pagetab" data-url="sub1.html" data-icon="fa-home" class="top-space"></div>
<div data-type="pagetab" data-url="sub2.html" data-icon="fa-music" class="top-space"></div>
<div data-type="pagetab" data-url="sub3.html" data-icon="fa-sliders" class="top-space"></div>
<div data-type="pagetab" data-url="sub4.html" data-icon="fa-lightbulb-o" class="top-space"></div>
<div data-type="pagetab" data-url="sub5.html" data-icon="fa-line-chart" class="top-space"></div>
<div class="bottom bottom-space-2x">
<div data-type="clock" data-format="H:i" class="large"></div>
<div data-type="clock" data-format="d.n.Y" class="small"></div>
</div>
</div>
</body>
</html>
</pre>

- Ganz oben im Menu ist die sub1.html, die zuerst angezeigt wird und die eigentlichen Haupt-Widgets hat

- Jede Unterseite sub*.html hat auch wieder die gleiche Menü-Leiste dabei, die wieder per Template eingebunden wird. Die Unterseiten haben keine Scripts oder CSS Links, da nur der Gridster Teil in die index.html importiert wird
<pre>
<html>
<title>FHEM Sub1</title>
<head>
</head>
<body>
<div class="gridster">
<ul>
<li data-row="1" data-col="1" data-sizex="1" data-sizey="7" data-template="menu.html"></li>
<li data-row="1" data-col="2" data-sizex="3" data-sizey="4">
<header>EXAMPLE1</header>

</li>
<li data-row="1" data-col="4" data-sizex="6" data-sizey="4">
<header>EXAMPLE2</header>

</li>
<li data-row="1" data-col="10" data-sizex="2" data-sizey="4">
<header>EXAMPLE3</header>

</li>
<li data-row="5" data-col="2" data-sizex="6" data-sizey="3">
<header>EXAMPLE4</header>

</li>
<li data-row="5" data-col="8" data-sizex="5" data-sizey="3">
<header>EXAMPLE5</header>

</li>
</ul>
</div>
</body>
</html>
</pre>

==Wie bekommt man Elemente nebeneinander und übereinander?==

'''nebeneinder''' klappt mit der CSS Klasse ''inline''

'''übereinander''' ist das Standardverhalten von div Elementen. Man steckt einfach alle Elemente, die untereinander angeordnet werden sollen, in einen gemeinsamen übergeordneten div Container.

Beispiel: Zwei Blöcken nebeneinander mit jeweils einem Switch und Label übereinander

<pre>
<div class="top-space inline">
<div data-type="switch" data-device="GalerieLicht" class=""></div>
<div data-type="label" class="cell">Galerie</div>
</div>
<div class="top-space inline">
<div data-type="switch" data-device="GartenLicht" class="" ></div>
<div data-type="label" class="cell">Garten</div>
</div>
</pre>

[[Kategorie: FAQ]]
[[Kategorie:FHEM Tablet UI]]

Anwesenheitserkennung

2016-10-05T15:00:46Z

Micky0867: Beispiel fuer gattool

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 <br />'''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") ===

Übernahme einer weiteren Möglichkeit um den Batteriestatus von LE Devices abzurufen und in FHEM als Reading darzustellen.
Dabei geht es darum, dass der Batteriezustand für alle LE Devices, die bereits in FHEM konfiguriert sind und per lepresenced überwacht werden, automatisch ermittelt wird.
Referenzierend auf den Forumsartikel [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, die o.g. Deviceermittlung im Script zu umgehen
* Es werden nur Devices abgefragt, die im Status "present" sind, also mit ziemlicher Sicherheit auch verfügbar sind
* Ein evtl. 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.<br>
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]]

Anwesenheitserkennung

2016-10-03T21:04:24Z

Micky0867: Aufruf per crontab zugefügt.

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 <br />'''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") ===

Übernahme einer weiteren Möglichkeit um den Batteriestatus von LE Devices abzurufen und in FHEM als Reading darzustellen.
Dabei geht es darum, dass der Batteriezustand für alle LE Devices, die bereits in FHEM konfiguriert sind und per lepresenced überwacht werden, automatisch ermittelt wird.
Referenzierend auf den Forumsartikel [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, die o.g. Deviceermittlung im Script zu umgehen
* Es werden nur Devices abgefragt, die im Status "present" sind, also mit ziemlicher Sicherheit auch verfügbar sind
* Ein evtl. 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....

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

Anwesenheitserkennung

2016-08-29T17:35:43Z

Micky0867: /* Batterieüberwachung (alle Devices vom Typ "MODE=lan-bluetooth") */

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.

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

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

Übernahme einer weiteren Möglichkeit um den Batteriestatus von LE Devices abzurufen und in FHEM als Reading darzustellen.
Dabei geht es darum, dass der Batteriezustand für alle LE Devices, die bereits in FHEM konfiguriert sind und per lepresenced überwacht werden, automatisch ermittelt wird.
Referenzierend auf den Forumsartikel [https://forum.fhem.de/index.php/topic,56960.0.html [Erweiterung]: Anwesenheitserkennung/Batterieüberwachung].

Vorteile:
<li>Automatische Ermittlung aller in FHEM konfigurierten LE Devices</li>
<li>Möglichkeit, die o.g. Deviceermittlung im Script zu umgehen</li>
<li>Es werden nur Devices abgefragt, die im Status "present" sind, also mit ziemlicher Sicherheit auch verfügbar sind</li>
<li>Ein evtl. auf dem FHEM telnet-Port gesetztes Passwort kann im Script hinterlegt werden</li>

'''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
<pre>
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,
</pre>

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]<br>
Am Besten unter /opt/fhem/script/lebattery speichern und ausführbar machen:
<pre>
sudo su -
mkdir /opt/fhem/script
cd /opt/fhem/script
wget https://raw.githubusercontent.com/micky0867/lebattery/master/lebattery
chmod 755 lebattery
</pre>
Je nach Bedarf können im Script noch die folgenden 3 Parameter angepasst werden:
<pre>
# 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=""
</pre>

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

Ausgabe des Skripts, wenn es mit dem Verbose Parameter -v gestartet wird.<br>
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>

=== 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.
<pre>
ps -ef | grep lepresenced
sudo kill <pid>
</pre>

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]]