Anwesenheitserkennung: Unterschied zwischen den Versionen

Aus FHEMWiki
Keine Bearbeitungszusammenfassung
K (Ergänzung und Umformatiert)
 
(152 dazwischenliegende Versionen von 27 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
Viele Benutzer führen bereits eine eigene Anwesenheitserkennung durch. Diese basiert in den meisten Fällen auf Ping Checks oder bei FritzBoxen über den 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.
== Vorüberlegungen ==
 
In FHEM gibt es mittlerweile mehrere Module, welche eine zuverlässige Anwesenheitserkennung bieten, ohne dabei FHEM bei der Ausführung zu beeinträchtigen.
 
Eine erweiterte Funktion der Anwesenheitserkennung ist die Standortverfolgung, welche sich nicht nur auf eine 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.
Generell gibt es mehrere Ansätze um Anwesenheitserkennung mit Handys/Smartphones durchzuführen.


Zeile 17: Zeile 10:
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.
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 ==
{{Randnotiz|RNText=Eine mögliche Lösung für diesen Effekt, ist die Verwendung von [[Blocking Call]] in eigen entwickelten Anwesenheitserkennung}}Viele Benutzer führen bereits eine '''eigen''' entwickelte 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.


Es gibt Geräte, welche ihr WLAN/Bluetooth auch im Standby ständig an 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.
Da es in FHEM aber mittlerweile '''mehrere''' Module gibt, die eine zuverlässige '''Anwesenheitserkennung''' bieten, ohne dabei FHEM bei der Ausführung zu beeinträchtigen, empfiehlt sich deren Einsatz.


Andere Geräte wiederum schalten WLAN im Standby Betrieb aus um Akku zu sparen. Bluetooth hingegen bleibt weiterhin aktiviert und kann auf Anfragen reagieren. (iPhone)
Eine erweiterte Funktion der Anwesenheitserkennung ist die Standortverfolgung, die sich nicht nur auf ein oder sehr wenige mit (eigenem) WLAN versorgte Gebiete beschränkt.


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


Auch wenn man Bluetooth aktiviert hat, so bleiben einige Handys erst dann empfangsbereit, wenn sie bereits zu irgend einem Bluetoothgerät gekoppelt wurden. Sind diese Geräte noch nie gekoppelt worden, so deaktivieren diese ihren Bluetooth Empfänger beim verlassen des Bluetooth-Menüs im Gerät (iPhone).
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)


Hier gilt es vor allem auszuprobieren wie stark der Akku durch eine Anwesenheitserkennung beeinträchtigt 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.
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.


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 verbessere 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 überträgt 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).
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).


= Das PRESENCE Modul =
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.


Das PRESENCE Modul bietet für die Anwesenheitserkennung mehrere Varianten an. Diese sind aktuell folgende:
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).


* '''lan-ping''' - Das überwachen via PING Checks, welche durch den FHEM Server versandt werden.
== PRESENCE-Modul ==
* '''fritzbox''' - Das überwachen von Geräten auf einer FritzBox via ctlmgr_ctl (Nur auf einer FritzBox möglich)
Das [[PRESENCE]] Modul bietet für die Anwesenheitserkennung mehrere Varianten an. Diese sind aktuell folgende:
* '''local-bluetooth''' - Das überwachen via Bluetooth Checks, welche 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 eine Presence-Daemon, welcher nach Bluetooth-Geräten sucht. Um mehrere Presence-Daemon mit FHEM zu verbinden, gibt es den Collector-Daemon, welche 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ück gibt (0 oder 1)
* '''shell-script''' - Das überwachen mithilfe eines selbst geschriebenen Shell-Programms/Skript, welches eine 0 oder 1 ausgibt um den Anwesenheitsstatus mitzuteilen.


== Ping-Überwachung von Geräten im WLAN/LAN ==
* '''lan-ping''' - Das Überwachen via PING Checks, die durch den FHEM Server versandt werden.
Um ein Gerät via Ping zu überwachen definiert man folgendes in der fhem.cfg:
* '''fritzbox''' - Das Überwachen von Geräten auf einer FritzBox via ctlmgr_ctl (Nur auf einer FritzBox möglich) '''Abgekündigt'''
* ''' Bluetooth'''
:- '''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äten, ü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.


<pre>
Für eine bessere Übersicht befinden sich die '''Details''' zur '''Einrichtung''' und '''Benutzung''' von PRESENCE auf folgende '''Seite''' [[PRESENCE|PRESENCE]]
define Handy PRESENCE lan-ping 192.168.0.30
</pre>


Dadurch wird die IP-Addresse 192.168.0.30 aller 30 Sekunden geprüft, ob sie erreichbar ist. Wenn sie erreichbar ist, ist der Status "present" (anwesend), ansonsten "absent" (abwesend)
Im Forum [https://forum.fhem.de/index.php/topic,76342.0.html] findet man eine Lösung zum Problem des "deep standby" Modus von den neuen iPhones und Android Geräte. Mittels hping3 werden Packete an das Gerät geschickt, damit die "wach" bleiben. Dann werden die Mac-Adressen via 'arp' gelesen.


Mann kann das Timeout verändern indem man es als zusätzlichen Wert hinten anhängt:
== 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.


<pre>
Für eine bessere Übersicht befinden sich die '''Details''' zur '''Einrichtung''' und '''Benutzung''' von GEOFANCY auf folgende '''Seite''' [[GEOFANCY|GEOFANCY]]
define Handy PRESENCE lan-ping 192.168.0.30 60
</pre>


Nun würde das Handy aller 60 Sekunden geprüft werden.
== livetracking-Modul ==
Das [[livetracking]] Modul baut auf der App Owntracking auf. Wird sie installiert, so kann man via MQTT oder HTTP an FHEM Angaben über den eigenen Standort, die Batteriestärke und die Entfernung zum Heimatort senden.  


Nur wenn man bei einem iPhone/iPad die Funktion "über WLAN synchronisieren" aktiviert hat, so ist dies auch im Standby zuverlässig pingbar. Standardmäßig deaktivieren Apple-Geräte ihr WLAN im Standby-Betrieb um Akku zu sparen.
Livetracking ist unter Linux (RPi) wie folgt zu installieren. Zuerst sind zwei Perl-Module zu holen
sudo apt-get -y install libnet-oauth-perl
sudo apt-get -y install libmath-round-perl
Das Modul selbst wird ohne weitere Angaben durch
define <name> livetracking
in FHEM angelegt. Es erhält ein Attribut, das auf das owntracking-Gerät in FHEM verweist durch
attr owntracksDevice <hier-owntracking-device-angeben>
Das owntracking-device selbst ist ein MQTT-Gerät, das in der App entsprechend anzulegen ist. Eine beispielhafte Installation (hinter einem VPN) sieht hier so aus
defmod <hier-owntracking-device-angeben> MQTT_DEVICE
attr <hier-owntracking-device-angeben> IODev Mosquitto
attr <hier-owntracking-device-angeben> subscribeReading_OWNTRACKS owntracks/<nutzer-und-app-spezifische-angaben>




'''Hinweis: 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.'''
== Beispiele für die Nutzung der Anwesenheitserkennung ==
Hier sollen Beispiele für den Nutzen von Anwesenheitserkennung aufgezeigt werden.


== FritzBox: direktes Abfragen der Aktivität via ctlmgr_ctl ==
=== Abschalten aller Verbraucher (Licht, Musikanlage) beim Verlassen der Wohnung ===
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.
Typisches Szenario: Man geht ausser Haus, aber hat vergessen im Bad das Licht aus zu machen. Allerdings geht man heutzutage fast gar nicht mehr ohne Handy aus dem Haus.


Dieser Modus kann allerdings nur in FHEM Installationen direkt auf einer FritzBox verwendet werden. Desweiteren muss FHEM unter dem User root laufen.
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.
Um ein Gerät zu überwachen wird lediglich der Gerätename benötigt, so wie er unter dem Menüpunkt "Heimnetz" auftaucht. In der fhem.cfg sieht dies folgendermaßen aus.


<pre>
<pre>
define Handy PRESENCE fritzbox iPhone-4S
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>
</pre>


 
Nun kann man mittels eines watchdogs eine Überwachung für sein Handy anlegen:
'''Hinweis: 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.'''
 
== 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, das Bluetooth nicht für große Reichweiten gedacht ist und in den meisten Fällen keine Wände überwinden können. Das heist, dass man in den meisten Fällen damit nur einen Raum überwachen kann.
 
Je nach Einsatzzweck kann das auch so gewollt sein. Bluetooth USB Sticks welche bereits Bluetooth 4.0 unterstützen können höhere Reichweiten über Zimmerwände hinaus erreichen. Voraussgesetzt das Handy 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 sich 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 Zeile in der fhem.cfg benötigt:
 
<pre style="margin-right: 210px;">
define Handy PRESENCE local-bluetooth XX:XX:XX:XX:XX:XX
</pre>
 
== 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, welche auf mehrere oder alle Räume verteilt sind.
 
Hierführ 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 das Raspberry zur Verfügung.
 
Beide Programme (presenced/collectord) sind Perl-Skripte welche als Daemon im Hintergrund laufen und auf Anfragen via Netzwerk warten. Es wird lediglich eine vollständige Perl-Grundinstallation benötigt mit Standardmodulen. Nach Installation der *.deb Paket 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 findet man in der [http://fhem.de/commandref_DE.html#PRESENCE Commandref] zum PRESENCE Modul.
 
=== Jeden Raum einzeln ansprechen (presenced) ===
 
Nun kann man zuallererst jeden Raum einzeln ansprechen. Dabei ist zu beachten, dass pro Definition in der FHEM.cfg nur ein Gerät in einem Raum spezifisch überwacht werden kann.
 
Eine Definition sieht dabei wie folgend aus:
 
<pre>
define Handy_Wohnzimmer PRESENCE lan-bluetooth XX:XX:XX:XX:XX:XX 192.168.0.10:5111
</pre>
 
Damit wird nun das Handy 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 inkl. der Angabe des Raumes, in welchem 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 welcher verwendet werden soll (standardmäßig Port 5111)
presence_timeout=120    # Prüfinterval welches verwendet werden soll, wenn ein Gerät anwesend ist
absence_timeout=20      # Prüfinterval welches verwendet werden soll, wenn ein Gerät abwesend ist
 
[Wohnzimmer]
address=192.168.179.34
port=5111
presence_timeout=180
absence_timeout=20
</pre>
 
Mit dieser Konfiguration kann der Collectord gestartet werden. Es empfiehlt sich diesen mit auf dem FHEM Server zu betreiben.
Nun kann man in der fhem.cfg folgenden Eintrag hinzufügen.


<pre>
<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
define Handy PRESENCE lan-bluetooth XX:XX:XX:XX:XX:XX 127.0.0.1:5222
</pre>
attr Handy event-on-change-reading state  # Ein Event soll nur bei der Änderung des Anwesenheitsstatus (Reading: status) erfolgen. Wichtig für den watchdog!!!


Sobald das Handy irgendwo in der Wohnung erkannt wurde, meldet der Collectord dies sofort an FHEM und teilt den Raum mit.
# 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 .
Eine detaillierte Benutzung von collectord findet man in der Commandref zum PRESENCE Modul.
attr watchdog_Anwesenheit regexp1WontReactivate 1
 
== Ü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.
 
<pre>
define <name> PRESENCE function {...} [ <check-interval> [ <present-check-interval> ] ]
</pre>
 
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. das geht z.b. mit: cpan install use Net::SNMP.
 
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[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>
</pre>


Danach lässt sich das Mobilgerät so überwachen:


<pre>
=== Benachrichtigung bei Batteriewechsel ===
define iPhone PRESENCE function {snmpCheck("10.0.1.1","0x44d77429f35c")} 30 30
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.
</pre>
Die Bluetooth-Adresse des Sensors kann mittels eines BLE-Scanners ermittelt werden.
 
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. 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 einem einfachen Define sofort betriebsbereit:


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


Damit nimmt FHEM unter http://192.168.178.1:8083/fhem/geo entsprechende Meldungen des iPhones entgegen. Damit das nicht nur über das lokale WLAN funktioniert, bedarf es allerdings noch einiger Kniffe.
Anschließend wird eine DOIF-Regel definiert, die eine Nachricht an die installierte FHEM App absendet:
Man muss FHEM vom Internet erreichbar machen und sollte dabei unbedingt an die Absicherung des Zugriffs denken.
 
Zunächst einmal habe ich bei mir eine eigene FHEMWEB Instanz dafür angelegt:
 
<pre>
<pre>
define WEBhook FHEMWEB 8088 global
define Eve_Room_BLE_Battery_Msg DOIF ([Eve_Room_BLE] eq "absent") (set Msg_iPhone message 'Batteriewechsel beim Eve Room Sensor im Wohnzimmer.')
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 Eve_Room_BLE_Battery_Msg wait 600
attr WEBhook room hidden
attr WEBhook webname webhook
</pre>
 
Damit ist unter der URL http://192.168.178.1:8088/webhook/geo 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. Auch wenn das Security-by-Obscurity ist - ich fühle mich wohler damit.
 
== Webhook weiter absichern ==
 
Außerdem ist dringend zu empfehlen, den Zugriff über SSL und HTTP Basic-Authentication weiter abzusichern. Läuft FHEM auf einem RaspberryPi, dann empfehle ich dazu die Konfiguration eines ReverseProxy (z.B. nginx oder Apache), damit ist man am flexibelsten und kann auch alle FHEMWEB Instanzen direkt über einen einzigen Port (meist 443, der HTTPS/SSL Standard Port) zusammenfassen. Ich möchte hier allerdings beschreiben, wie weit man mit FHEM Boardmitteln kommt und nehme das Beispiel einer Installation auf einer Fritzbox.
 
Wie SSL aktiviert wird, steht in der [http://fhem.de/commandref.html#FHEMWEB 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 [http://fhem.de/commandref.html#FHEMWEB Commandref für FHEMWEB] 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 WEBhook basicAuth { "$user:$password" eq "webhook:Geofancy" }
</pre>
 
Weitere Infos zur Absicherung gibt auch http://www.fhemwiki.de/wiki/FritzBox_Webzugriff_absichern
 
Um zu testen, ob unsere Absicherung erfolgreich war, kann man die URL https://192.168.178.1:8088/webhook/geo 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:
 
<pre>
internet_forwardrules = "tcp 0.0.0.0:488 0.0.0.0:488 0";
</pre>
 
Hinterher:
<pre>
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";
</pre>
 
Danach mittels ":x" abspeichern und sofort per "reboot" die Box neu starten, um diese 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.
 
== Einrichten in der Geofancy.app ==
Hat das alles soweit geklappt, können endlich in der 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)
 
Ich empfehle anfänglich 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
 
<pre>
POST Success: test OK
</pre>
 
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.
Ich benutze für meine Wohnung passenderweise "home". 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".
 
== 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  51F23894-AAAA-BBBB-CCCC-0123456789AB          arrived home
    2014-01-18 14:37:42  currLocLat_51F23894-AAAA-BBBB-CCCC-0123456789AB 48.9999
    2014-01-18 14:37:42  currLocLong_51F23894-AAAA-BBBB-CCCC-0123456789AB 11.9999
    2014-01-18 14:37:42  currLocTime_51F23894-AAAA-BBBB-CCCC-0123456789AB 2014-01-18 14:37:42
    2014-01-18 14:37:42  currLoc_51F23894-AAAA-BBBB-CCCC-0123456789AB  home
    2014-01-17 19:18:23  lastArr        51F23894-AAAA-BBBB-CCCC-0123456789AB home
    2014-01-17 18:41:46  lastDep        51F23894-AAAA-BBBB-CCCC-0123456789AB Office
    2014-01-18 14:37:42  lastDevice      51F23894-AAAA-BBBB-CCCC-0123456789AB
    2014-01-17 18:41:46  lastLocArr_51F23894-AAAA-BBBB-CCCC-0123456789AB 2014-01-17 08:58:37
    2014-01-17 18:41:46  lastLocDep_51F23894-AAAA-BBBB-CCCC-0123456789AB 2014-01-17 18:41:46
    2014-01-17 18:41:46  lastLocLat_51F23894-AAAA-BBBB-CCCC-0123456789AB 48.1111
    2014-01-17 18:41:46  lastLocLong_51F23894-AAAA-BBBB-CCCC-0123456789AB 11.1111
    2014-01-17 18:41:46  lastLoc_51F23894-AAAA-BBBB-CCCC-0123456789AB  Office
    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. Das ist sehr unübersichtlich.
Wir setzen deshalb einen Alias-Namen für das Gerät. Sinnvoll erscheint mir der Vorname des Besitzers:
 
<pre>
attr geofancy devAlias 51F23894-AAAA-BBBB-CCCC-0123456789AB:Julian
</pre>
 
Weitere Alias-Namen können mit Leerzeichen einfach angehängt werden.
Die alten Readings löschen wir mit
 
<pre>
set geofancy clear readings
</pre>
 
Jetzt sehen die Readings schon viel freundlicher aus:
<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-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 currLog_Name setzen.
Ich aktualisiere lediglich 2 Dummies, durch die dann alle weiteren Notifies ausgelöst werden:
 
<pre>
define n_Julian.Presence notify geofancy:currLoc_Julian:.home set Julian.homestatus home
attr n_Julian.Presence room Residents
define n_Julian.absence notify geofancy:currLoc_Julian:.underway {\
if (Value("Julian.homestatus") ne "gone" && Value("Julian.homestatus") ne "absent") {\
  fhem("set Julian.homestatus absent");;\
}
define n_Julian.whereabout notify geofancy:currLoc_Julian:.* set Julian.whereabout $EVTPART1
</pre>
 
= Beispiele für die Nutzung der Anwesenheitserkennung =
Hier sollen Beispiele für die Nutzung von PRESENCE 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, welche alle Verbraucher und sonstige Devices, welche 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 ; setstate watchdog_Anwesenheit defined
attr watchdog_Anwesenheit regexp1WontReactivate 1
</pre>
</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.
[[Kategorie:Code Snippets]]
[[Kategorie:Code Snippets]]
[[Kategorie:Glossary]]
[[Kategorie:Glossary]]
[[Kategorie:Anwesenheitserkennung]]

Aktuelle Version vom 23. Januar 2024, 20:23 Uhr

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.

Info green.pngEine mögliche Lösung für diesen Effekt, ist die Verwendung von Blocking Call in eigen entwickelten Anwesenheitserkennung

Viele Benutzer führen bereits eine eigen entwickelte Anwesenheitserkennung durch. Diese basiert in den meisten Fällen auf Ping Checks oder bei 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.

Da es in FHEM aber mittlerweile mehrere Module gibt, die eine zuverlässige Anwesenheitserkennung bieten, ohne dabei FHEM bei der Ausführung zu beeinträchtigen, empfiehlt sich deren Einsatz.

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

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 Geofency oder 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).

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) Abgekündigt
  • Bluetooth
- 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äten, über Netzwerk. Auf einer oder mehreren Maschinen im Netzwerk (z.B. 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.

Für eine bessere Übersicht befinden sich die Details zur Einrichtung und Benutzung von PRESENCE auf folgende Seite PRESENCE

Im Forum [1] findet man eine Lösung zum Problem des "deep standby" Modus von den neuen iPhones und Android Geräte. Mittels hping3 werden Packete an das Gerät geschickt, damit die "wach" bleiben. Dann werden die Mac-Adressen via 'arp' gelesen.

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 Geofency und Geofancy können dann aktiv und quasi in dem Moment, wo man den Wohnbereich betritt oder verlässt, benachrichtigen. Android Nutzern können 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.

Für eine bessere Übersicht befinden sich die Details zur Einrichtung und Benutzung von GEOFANCY auf folgende Seite GEOFANCY

livetracking-Modul

Das livetracking Modul baut auf der App Owntracking auf. Wird sie installiert, so kann man via MQTT oder HTTP an FHEM Angaben über den eigenen Standort, die Batteriestärke und die Entfernung zum Heimatort senden.

Livetracking ist unter Linux (RPi) wie folgt zu installieren. Zuerst sind zwei Perl-Module zu holen 

sudo apt-get -y install libnet-oauth-perl
sudo apt-get -y install libmath-round-perl

Das Modul selbst wird ohne weitere Angaben durch 

define <name> livetracking

in FHEM angelegt. Es erhält ein Attribut, das auf das owntracking-Gerät in FHEM verweist durch 

attr owntracksDevice <hier-owntracking-device-angeben>

Das owntracking-device selbst ist ein MQTT-Gerät, das in der App entsprechend anzulegen ist. Eine beispielhafte Installation (hinter einem VPN) sieht hier so aus 

defmod <hier-owntracking-device-angeben> MQTT_DEVICE
attr <hier-owntracking-device-angeben> IODev Mosquitto
attr <hier-owntracking-device-angeben> subscribeReading_OWNTRACKS owntracks/<nutzer-und-app-spezifische-angaben>


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

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

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

# Ü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


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. 

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

Anschließend wird eine DOIF-Regel definiert, die eine Nachricht an die installierte FHEM App absendet: 

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

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.

Abgerufen von „http://wiki.fhem.de/w/index.php?title=Anwesenheitserkennung&oldid=39046“