vermutlich steht es außer Frage, dass eine zuverlässige Anwesenheitserkennung für die Hausautomatisierung unerlässlich ist.
Ich möchte daher zunächst mal die Frage in den Raum werfen, wie ihr die Anwesenheitserkennung umgesetzt habt und im Anschluss daran meine Lösung mittels OwnTracks und MQTT vorstellen.
Nachdem ich mich einige Zeit darin versucht habe, für die Anwesenheitserkennung auf die FritzBox und die im Heimnetz angemeldeten Geräte zurückzugreifen, habe ich davon wieder Abstand genommen. Zum einen ist die Auswertung der gerade angemeldeten Geräte nicht trivial (aber möglihch, z. B. mittels Node-Red, "node-red-contrib-fritz" und MQTT), zum anderen ist die Information, welche Geräte gerade im WLAN angemeldete sind, nicht unbedingt ein zuverlässiger Indikator dafür, welche Bewohner sich gerade zu Hause aufhalten.
Zwar gehen weder meine Frau und ich selten ohne Mobiltelefon aus dem Haus, aber für unsere Tochter funktioniert das ob ihres Alters aktuell noch nicht.
Außerdem schalten wir nachts das WLAN der FritzBox ab und meistens auch das WLAN auf den Telefonen.
Und falls tagsüber mal ein Akku leer sein sollte, würde das Ergebnis auch verfälscht.
Bei Ankunft zu Hause und beim Verlassen des Hauses einen Taster zu betätigen erscheint mir irgendwie das Gegenteil von Automation zu sein, auch wenn ein Tastendruck natürlich eine ganze Reihe von Funktionen auslösen kann.
Für die Anwesenheitserkennung (= Bewohner betritt das Haus) eignet sich zwar der ekey-Fingersensor ganz gut, aber wenn wir als Familie gemeinsam nach Hause kommen dann öffnet einer von uns die Tür und wir ziehen nicht alle unsere Finger über dem Scanner, nur um dem Haus mitzuteilen dass wir nun alle zu Hause sind.
Und beim Verlassen es Hauses wäre das wieder eine Extra-Aktion, während ich mir eigentlich erhoffe dass das Haus von alleine erkennt wenn niemand mehr zu Hause ist, dann die Alarmanlage aktiviert, die Tür verriegelt etc.
Als der Timberwolf Server mit einer der vorhergehenden Versionen die Cloudservices und namentlich IFTTT beigebracht bekam, habe ich es damit versucht. Die Integration zwischen TWS und IFTTT funktionierte auch tadellos, ebenso die Verknüpfung mit dem Location-Applet. Aber die IFTTT-App auf meinem Telefon war nicht dazu zu bewegen, regelmäßig die Position des Telefons abzurufen, daher führte dieser Weg auch in eine Sackgasse.
Nachdem ich meine ersten erfolgreichen Gehversuche mit MQTT gemacht hatte (viewtopic.php?p=53431#p53431), habe ich nach einer Möglichkeit gesucht, MQTT oder eine API für die Übermittlung der Telefonpositionen heranzuziehen. Leider habe ich keine Möglichkeit gefunden, die Google-Positionsangaben per API anzuzapfen.
Daher lautet meine aktuelle Lösung: OwnTracks-Apps auf den Telefonen, übermittlung der Telefonpositionen via MQTT.
Damit hängt die Anwesenheitserkennung zwar nach wie vor an der Position der Mobiltelefone, ist aber nicht mehr an die WLAN-Verbindung geknüpft und funktioniert gleichzeitig ohne eine Cloud und ohne Speicherung von Positionsdaten in einer Cloud.
OwnTracks-Apps gibt es für Apple und für Android in den jeweiligen App-Stores. Die Android-App ist mit knapp 23 MB Speicherplatz auch relativ schlank gehalten.
Die Integration erfolgt nun folgendermaßen:
1. Die OwnTracks-App auf dem Gerät installieren und die jeweiligen Berechtigungen erteilen. Selbstredend funktioniert die Positionsübermittlung nur dann zuverlässig, wenn man der App Zugriff auf die (genauen) Standortdaten einräumt, sie im Hintergrund laufen lässt und das Energiesparen deaktiviert.
2. Unter "Einstellungen" die MQTT-Verbindung einrichten (bei mir läuft Mosquitto als MQTT-Broker auf dem TWS in Portainer). Ich verwende auch Benutzernamen und Passwörter, siehe viewtopic.php?f=81&t=3487&p=57582&hilit ... ort#p57582.
Der Benutzername wird später Teil des MQTT-Topics.
3. Unter "Erweiterte Einstellungen" kann man noch ein paar Änderungen vornehmen um z. B. festzulegen in welchen Intervallen Positionsdaten gesendet werden.
4. Unter "Orte" kann man Geofencing für einen oder mehrere Orte einrichten, mit geographischer Position und Radius.
5. Weitere Informationen zur Einrichtung findet man unter https://owntracks.org/booklet, aber für den Anfang sollte das ausreichen.
6. Wenn alles klappt geklappt hat, dann sieht man z. B. im MQTT-Explorer die ersten Nachrichten:
7. Nun geht es an die Auswertung im Timberwolf Server. Dazu im MQTT-Gerätemanager ein neues Gerät anlegen mit dem Topic, was man im MQTT-Explorer sehen kann:
8. OwnTracks sendet zwei grundlegende Nachrichtentypen, Location und Transition, beide als JSON. In der Location-Nachricht werden bei jeder (relevanten) Standortänderung die Position und andere Daten gesendet, die Transition-Nachricht wird jeweils beim Betreten und beim Verlassen eines definierten Ortes gesendet.
Für die Anwesenheitserkennung ist natürlich letztere revelant.
9. Daher habe ich ein App-Level-Topic einrichtet und zwei Subscriptions, eine für Event und eine für Ort.
Wenn man nur einen Ort definiert hat, dann reicht eine Subscription für Event, denn dann kann man relativ einfach "enter" und "leave" über eine UND-Logiken auswerten.
Da ich mit OwnTracks meine Anwesenheit zu Hause und im Büro mitschreibe, habe ich mehrere Orte definiert und nehme die Auswertung über eine Custom-Logik vor.
10. Die Logik für die Auswertung sieht dann so aus:
Und hier ist der Code dazu:
Code: Alles auswählen
{
"Level": [
[
"$EventText",
"string",
""
],
[
"$TextEnter",
"string",
"enter"
],
[
"$TextLeave",
"string",
"leave"
],
[
"$Event",
"bool",
false
],
[
"$Location",
"string,64",
""
],
[
"$ReferenceLocation",
"string,64",
""
],
[
"$CompareMode",
"string",
"E"
],
[
"$Vergleich",
"bool",
false
],
[
"$Presence",
"bool",
false
]
],
"Module": [
[
"Stringcompare",
"$EventText",
"$Event",
"$TextEnter",
"$CompareMode"
],
[
"Stringcompare",
"$EventText",
"-$Event",
"$TextLeave",
"$CompareMode"
],
[
"Stringcompare",
"$Location",
"$Vergleich",
"$ReferenceLocation",
"$CompareMode"
],
[
"And", [
"$Event",
"$Vergleich"
],
"$Presence"
]
],
"Input": [
[
"Ort",
"Ort",
"$Location",
"u"
],
[
"Ereignis",
"Ereignis (ENTER oder LEAVE)",
"$EventText",
"a"
],
[
"Referenzort",
"Referenzort",
"$ReferenceLocation",
"u"
]
],
"Output": [
[
"Anwesenheit",
"Anwesenheit (TRUE oder FALSE)",
"$Presence",
"c"
]
]
}
11. Das Ergebnis der Logik schreibe ich in eine Zeitreihe und schicke es über einen Binärmultiplexer, der mir eine Zahl aus den drei Zuständen (abwesend, anwesend (= Zuhause) und "im Büro" berechnet). Dies ist nur für die Darstellung in einem einzigen Visu-Widget von Bedeutung:
Damit ist die grundlegende Funktionalität gegeben. Ich habe OwnTracks jetzt seit Wochen auf meinem und dem Telefon meiner Frau im Einsatz, die Trefferquote liegt bei annähernd 100 Prozent.
Mir sind folgende Einschränkungen bekannt:
- Damit OwnTracks Daten an den heimischen MQTT-Server senden kann, muss entweder eine ständige VPN-Verbindung zwischen Telefon und TWS bestehen (seit Einführung der Timberwolf VISU habe ich ohnehin eine ständige Wireguard-Verbindung zu meiner FritzBox, daher ist diese Voraussetzung erfüllt), oder man gibt den entsprechenden Port frei. Davon rate ich aus Sicherheitsgründen aber dringend ab.
Man man theoretisch auch einen MQTT-Server mit TLS-Verschlüsselung laufen lassen, aber damit kenne ich mich nicht aus und dann ist es m. W. auch keine leichtgewichtige und datensparende Verbindung mehr.
- Auf dem Huwei-Telefon meiner Frau gibt es ab und an Probleme mit der Verbindung. Das liegt aber am Zusammenspiel von Huawei und Wireguard, nicht an OwnTracks selbst.
Weitere Auswertungen und Möglichkeiten:
Über einen weiteren App-Level-Topic im MQTT-Gerätemanager werte ich die Position (Breite und Länge) meines Telefons aus und schreibe diese in TWS-Zeitreihen.
Wenn man sich in einem WLAN befindet, dann umfasst die Location-Nachricht auch den Namen des Netzwerks. Theoretisch kann man anstatt der Transition-Events auch diese Information aus dem JSON ziehen und auswerten.
Ebenso wird der Name des Ortes gesendet, wenn man sich innerhalb eines in der App definierten Ortes aufhält. Auch diese Information kann man auswerten.
Das Problem mit der WLAN-SSID und dem Ort ist allerdings, dass der MQTT-Gerätemanager noch nicht über Sendefilter verfügt. Wenn also eine Location-Nachricht gesendet wird, in der die SSID und der Ort fehlen, weil das Gerät sich nicht mehr dort aufhält, dann wird einfach nichts in die jeweilige Subscription geschrieben und die Auswertelogik bekommt die Änderung schlicht und einfach nicht mit.
Für den Ort kann man sich damit behelfen, dass man zwei Orte mit gleichen Koordinaten aber unterschiedlichem Radius definiert. Dann werden ggf. beide Orte in einem Array gesendet, aber immer der Ort mit dem kleineren Radius an erster Position. Somit würde man zumindest die Bewegung vom kleineren Radius zum größeren Radius mitbekommen und auswerten können.
Allerdings ist e. E. die Auswertung der Transition-Nachricht die einfachste und zuverlässigste Variante.
OwnTracks Recorder
Es gibt auch einen eigenen Recorder, der in einem Docker-Container und damit auf Portainer läuft. Damit kann man die Standorte der Telefone ebenfalls tracken und sogar schön auf einer Karte anzeigen lassen.
Die Einrichtung erfolgt wie folgt:
1. Zuerst zwei Volumes anlegen, eines für die Konfig und eines für die Daten:
2. Dann einen Container einrichten mit folgenden Einstellungen:
3. Die Volumes mappen:
4. Und die Umgebungsvariablen anpassen:
5. Unter Restart Policy auswählen: Unless stopped.
6. Den Container erstellen, fertig ist die Laube.
Über die IP des Timberwolf Servers und den Port 8083 kann man dann auf die Webseite des Recorders zugreifen.
Ich hoffe, ich habe alles hinreichend bebildert sodass es einfach nachzuvollziehen ist. Falls es Fragen gibt bitte einfach melden.
Viel Spaß und viele Grüße
Falk
