Aktionen an Standorte knüpfen – GeoLocation und FHEM

IM EINSATZ?

Dann schau dir UNSEREN LOXKURS an und profitiere von unserem Wissen!

Bei dem ganzen Thema Anwesenheitserkennung gibt es gefühlt tausende Ansätze: Bluetooth, WLAN, Mac-Adressen prüfen und viele mehr. Die meisten scheitern allerdings an Ihrer Zuverlässigkeit oder Reichweite. Dann erkennt der Raspberry schnell mal das Bluetooth-Tag nicht mehr und man wird als abwesend gekennzeichnet, weil man einfach zu weit weg ist. Außerdem funktionieren diese Lösungen eben nur Zuhause.

Was wäre aber, wenn man jede Location auf der Welt in FHEM integrieren könnte? Also den Arbeitsplatz, die Innenstadt, die besten Freunde oder die Eltern? Jetzt könnte man sich fragen, was man mit den Infos möchte – mit GeoLocation könnte man eine ähnliche Lösung wie Tado bauen. Man zieht dazu verschieden große Kreise um das eigene Zuhause – von einem sehr kleinen bis sehr großen Radius. Wenn man nun immer weiter Richtung Heimat fährt, könnte man die Heizung entsprechend hochstellen. Im vorletzten Kreis würde man dann z.b. die Boost-Funktion von HomeMatic-Thermostaten nutzen, um es bei der Ankunft schön warm zu haben.

Eine weitere Möglichkeit ist zum Beispiel, die Frau/Freundin bzw. den Mann/Freund zu Hause automatisch zu Informieren, wenn man von der Arbeit losgefahren ist. Ob sie oder er diese Information unbedingt haben muss, muss jeder für sich selbst entscheiden 😉

Zugriff von überall auf der Welt? Internet!

Damit man in FHEM von überall auf der Welt entsprechende Aufrufe durchführen kann, muss der eigene Raspberry natürlich in Internet verfügbar gemacht werden. Aber keine Sorge, in diesem Artikel lernst Du, wie alles korrekt abgesichert wird. Zusätzlich hast Du damit natürlich die Möglichkeit, Apps und die Weboberfläche von unterwegs ebenfalls nutzen zu können. Also zwei Fliegen mit einer Klappe!

Und bevor alle schreien: Eine Alternative zu allem gezeigten hier wäre natürlich auch VPN. Dieses ist zwar schneller eingerichtet, aber ist längst nicht so flexibel. Gerade, wenn man von anderen Webanwendungen etwas zu FHEM schreiben möchte, ist man mit VPN schon raus. Der große Pluspunkt hier ist also Flexibilität!

Was wir in diesem Beitrag alles tun werden:

  1. DynDNS konfigurieren um den Hostnamen einfacher merken zu können
  2. Port-Forwarding im Router konfigurieren
  3. Mit echten Letsencrypt-Zertifikaten die Verbindung verschlüsseln lassen
  4. Apache-ReverseProxy installieren, um Zugriffe bestmöglich abzusichern
  5. GeoLocation via IFTT oder per FHEM-App einrichten

Klingt nach einer langen ToDo-Liste – aber bitte nicht abschrecken lassen, alles halb so wild! Natürlich ist das Thema sehr sensibel, aber wenn man es richtig macht, besteht nahezu kein Risiko. Der Prozess sieht am Ende wie folgt aus:

Wie man sieht, läuft die Verbindung bis zum Apache-Server verschlüsselt ab. Dieser gibt dann intern die Verbindung weiter an FHEM. Es wäre sogar denkbar, dass man den Port 8083 von außen auf dem Raspberry gar nicht erreichbar macht – so müssten dann eben alle Verbindungen über den Apache laufen.

Ich für meinen Teil nutze die Verbindung von außen aber wirklich nur unterwegs, da man ansonsten auch aus dem Heimnetz immer erst den Weg über das Internet gehen würde, was die Sache natürlich nicht unbedingt beschleunigt.

Schritt 1/5 – DynDNS konfigurieren

Da das Internet auch nur ein großes Netzwerk ist, könnte man natürlich immer per IP arbeiten, um die eigene Installation zu Hause zu erreichen. Problematisch ist nur, dass sich die Provider von Privatanschlüssen eine sog. Zwangstrennung überlegt haben, welche euch regelmäßig eine neue IP-Adresse zur Verfügung stellt. Somit könnt ihr die IP in keiner App speichern, da sie nicht von Dauer ist.

Wichtig an dieser Stelle: Ihr braucht eine IPv4-Adresse! Unitymedia vergibt z.B. bei aktuelleren Anschlüssen keine IPv4-Adressen mehr. Hier ist unbedingt darauf zu achten, dass man sich nicht in einem Subnetz des Providers befindet. Prüfen kann man dies auf Seiten wie “wieistmeineip.de”.

Ein DynDNS (dynamischer DNS) sorgt nun dafür, dass einer Domain immer die aktuelle IP zugeordnet ist. Der Router (in meinem Fall die FritzBox) geht also immer wieder an den Dienst und teilt die aktuelle Internet-IP mit. Alternativ kann das auch der Raspberry selbst durchführen – aber die meisten Router haben dafür vorgefertigte Oberflächen, in welche man die Daten nur eingeben muss.

Provider für DnyDNS gibt es da draußen extrem viele. Eigentlich viel zu viele. Kostenlos wie kostenpflichtig. Die Auswahl dafür ist euch selbst überlassen – allerdings solltet ihr vorher einmal prüfen, ob Letsenrypt für dies entsprechende Domain noch Zertifikate ausstellt. Dies ist wichtig, damit wir in Schritt 4 die Verbindung auch verschlüsseln können. Aber dazu später mehr. Soweit mir bekannt ist, sind die myfritz-Domains nicht erlaubt.

Ich selbst habe in meinem Hosting-Paket bei allinkl DynDNS enthalten. Das heißt, ich lege einfach eine neue Subdomain an, welche dann zu mir nach Hause führt. Dies funktioniert bei allinkl ab dem Paket “PrivatPlus” (siehe Punkt DDNS). Mit eigenen Domains funktioniert Letsencrypt am zuverlässigsten. Außerdem bekommt man dort noch jede Menge andere Leistungen, welche man immer brauchen kann.

Beispiele:

  • fhem.meintechblog.de (im Fall von allinkl oder einem anderen Provider)
  • deinname.dyndns.org (wenn man sich z.B. für dyndns.org entscheidet)

Nachdem wir uns nun auf der Fritzbox (fritz.box) angemeldet haben, klicken wir auf “Internet” und dann auf “Freigaben”. Dort finden wir den Reiter “Dynamic DNS” und tragen die entsprechenden Zugangsdaten ein. Danach ist der erste Schritt auch schon erledigt.

Bei anderen Router-Herstellern funktioniert das natürlich eventuell ein wenig anders, aber generell bietet heute fast jeder Hersteller diese Möglichkeiten.

Affiliate-Links

Schritt 2/5 – Port-Forwarding im Router konfigurieren

Ein kleiner Schritt. Dazu einfach wieder auf der Fritzbox anmelden, unter “Internet” und “Freigaben” auf den Reiter “Portfreigaben” klicken und dort den Port 443 weiterleiten. Port 80 leiten wir nicht weiter. Das Zielsystem ist natürlich unser FHEM-Server. Also der Raspberry Pi oder ein Intel NUC usw.

Im folgenden Screenshot ist auch noch Port 3000 weitergeleitet, welcher für Alexa-FHEM gebraucht wird. Das ist aber eine andere Baustelle und wird hier nicht weiter behandelt. Zeigt aber auf jeden Fall auf, welche Flexibilität hier gewonnen wird, wenn DynDNS einmal konfiguriert wurde.

Natürlich könnte man Port 80 auch weiterleiten und dann in der Apache-Konfiguration sagen, dass dieser auf Port 443 umleitet, aber wir wollen ja möglichst wenig Angriffsfläche bieten.

Wichtig hierbei ist natürlich, dass der FHEM-Server im Netzwerk immer die gleiche IP vom DHCP-Server bekommt oder eine statische IP vergeben wird. Andernfalls wundert ihr euch, dass irgendwann nichts mehr funktioniert.

Schritt 3/5 – Let’s Encrypt Zertifikat erstellen

Jetzt ist alles soweit vorbereitet. Allerdings brauchen wir noch ein entsprechendes Zertifikat, welches für die Verschlüsselung genutzt wird. Das könnten wir theoretisch auch kaufen, aber mit Let’s Encrypt wurde ein Diest geschaffen, welcher kostenlos Zertifikate ausstellt. Für uns also sehr praktisch.

Dazu laden wir die entsprechenden Quellen per git:

cd /opt
sudo git clone https://github.com/letsencrypt/letsencrypt
cd letsencrypt
./letsencrypt-auto certonly --rsa-key-size 4096 -d <domain>

Der Wert “domain” muss natürlich im letzten Aufruf durch Eure Domain ersetzt werden. Also zum Beispiel “fhem.meintechblog.de” (ohne Anführungszeichen).

Danach startet ein Wizard, in welchem wir als erstes gefragt werden, wie wir die Domain verifizieren möchten. Hier wählen wir Punkt 3 (Temporary Webserver). Im nächsten Schritt müssen wir unsere Emailadresse eingeben – an diese bekommen wir dann auch Informationen, wenn unser Zertifikat kurz davor ist abzulaufen usw. Den Lizenzbedingungen im nächsten Schritt stimmen wir natürlich zu.

Damit ist das Zertifikat auch schon erstellt. Im letzten Schritt binden wir die Scripts in den Apache-Webserver ein und verknüpfen Apache mit FHEM.

Schritt 4/5 – Apache-ReverseProxy installieren

Reverse was? Ein Reverse-Proxy arbeitet ähnlich wie ein Proxy-Server im Firmennetz, nur umgekehrt – Anfragen von außen werden angenommen und dann intern entsprechend weitergeleitet. So weiß der Besucher am Ende gar nicht, wo genau der eigentliche Dienst eigentlich läuft (also FHEM). Hier werden also die Anfragen angenommen, an FHEM weitergeleitet und dann die Antwort wieder an den Client geschickt.

Warum leiten wir die Anfragen nicht einfach direkt an FHEM weiter? Ganz einfach: Weil FHEM dafür nicht gemacht wurde. Mit dem Apache (oder gerne auch einem nginx) dazwischen, hat man viele Vorteile. so kann man z.B. für die Verbindung ein valides SSL-Zertifikat hinterlegen, hat alle Möglichkeiten für IP-Filter, Rewrites und vieles mehr. Außerdem ist der Apache millionenfach getestet. Immerhin laufen extrem viele Webseiten da draußen hinter einem Apache-Server.

Vorher noch ein paar Basics: HTTP läuft standardmäßig auf Port 80, daher müssen wir im Browser auch keinen Port angeben, wenn wir Webseiten aufrufen. HTTPS läuft auf Port 443 – und nur diesen Port werden wir auch nach außen verfügbar machen. Einfach um vorzubeugen, dass unverschlüsselte Daten überhaupt übertragen werden können.

Legen wir also mit der Installation los.

sudo apt-get update
sudo apt-get install apache2 libapache2-mod-proxy-html -y

sudo a2enmod proxy proxy_http ssl proxy_html
sudo service apache2 restart

Das wars auch schon. Alles, was danach folgt, ist Konfiguration.

cd /etc/apache2/sites-available/
sudo vi <domain>.conf

Natürlich könnt ihr die conf-Datei nennen wir ihr möchtet. In der Regel nennt man diese aber genauso wie die entsprechende Domain dahinter, damit man alles schnell wiederfindet, falls mehrere Domains vom gleichen Apache-Server behandelt werden. In die Datei schreiben wir folgendes:

<IfModule mod_ssl.c>
<VirtualHost *:443>
    ServerName fhem.meintechblog.de

    ServerAdmin matthias@meintechblog.de
    DocumentRoot /var/www/html

    ErrorLog ${APACHE_LOG_DIR}/fhem.meintechblog.de.error.log
    CustomLog ${APACHE_LOG_DIR}/fhem.meintechblog.de.access.log combined

    SSLCertificateFile /etc/letsencrypt/live/fhem.meintechblog.de/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/fhem.meintechblog.de/privkey.pem

    Include /etc/letsencrypt/options-ssl-apache.conf

    ProxyRequests Off
    ProxyVia Off
    ProxyPreserveHost On

    <Location /fhem>
        ProxyPass http://localhost:8083/fhem
        ProxyPassReverse http://localhost:8083/fhem
    </Location>

    <Directory />
        RedirectPermanent / /fhem
    </Directory>

    <Proxy *>
        AuthType Basic
        AuthName "Password for FHEM Required"
        AuthUserFile /etc/fhem-htpasswd
        Require valid-user
        Order deny,allow
        Allow from all
    </Proxy>
</VirtualHost>
</IfModule>

Natürlich müssen neben der Domain und Email-Adresse auch die Pfade angepasst werden, welche zur Zertifikatsdatei führen.

In meinem Fall ist die Verbindung zu FHEM nicht verschlüsselt. Also alles, was ich im internen Netz mache, geht ohne HTTPS zu FHEM. Außerdem habe ich für FHEM auch keinen Benutzernamen und kein Passwort hinterlegt. Solltet ihr dies getan haben, muss zum einen die Verbindung zu FHEM mit https ergänzt werden und zum anderen die Benutzerdaten in der Proxy-Config hinterlegt werden. Dies geht mit folgender Header-Zeile:

<Location /fhem>
    ProxyPass http://localhost:8083/fhem
    ProxyPassReverse http://localhost:8083/fhem
    RequestHeader set Authorization "Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ=="
</Location>

Natürlich muss der entsprechende Base64-String angepasst werden. Hier muss man wirklich zwischen zwei Requests unterscheiden: Der erste geht vom Client zum Apache und der zweite vom Apache zum FHEM. Damit der Apache den zweiten Request als Proxy erfolgreich durchführen kann, müssen wir ihm alle Infos mit an die Hand geben. So eben auch die Benutzerdaten für diesen Request.

Generell würde ich aber empfehlen, im internen Netz allen zu vertrauen und in der FHEM-Config weder HTTPS noch Benutzernamen und Passwort zu verwenden. Aber wie immer gilt: Geschmackssache.

Zuletzt müssen wir die Site noch aktivieren, indem ein Symlink zu “sites-enabled” erstellt wird. Die Idee vom Apache dabei ist, dass man jede Menge Configs vorhalten kann, aber nur die aktuell relevanten per Symlink aktiviert.

cd /etc/apache2/sites-enabled
sudo ln -s ../sites-available/* .

Wenn nun ein Request von außen in den Apache geht, soll dieser natürlich seinen Benutzernamen und sein Passwort eingeben müssen. Dazu legen wir eine neue Datei an, welche die entsprechenden Infos enthält:

sudo htpasswd -c -s /etc/fhem-htpasswd <username>

Hier muss natürlich ganz hinten der gewünschte Benutzername eingetragen werden. Nach der Bestätigung mit Enter muss das Passwort eingegeben und erneut bestätigt werden. Fertig.

Zuletzt testen wir unsere Config noch einmal und starten den Apache neu.

sudo apachectl configtest
sudo service apache2 restart

Ab jetzt sollte über https://deinedomain.de/fhem alles wie gewünscht aufrufbar sein. Wichtig ist hier natürlich HTTPS statt HTTP (Port 80 haben wir ja nicht weitergeleitet) und /fhem am Ende.

Das ganze Konstrukt hat den Charme, dass man jetzt auch noch andere Dienste über den Proxy erreichbar machen könnte, ohne noch ein weiteres Zertifikat etc. zu erstellen. Wir haben also nun eine tolle Grundlage für weitere Spielereien. Ich habe zum Beispiel die Oberfläche meiner IP-Kamera ebenfalls über diese Domain zugänglich gemacht.

Schritt 5/5 – GeoLocation via App

Jetzt steht zwar die ganze Infrastruktur, aber eigentlich sollte es in diesem Beitrag doch um die Anwesenheitserkennung gehen, oder? Da wir nun alles vorbereitet haben, starten wir nun damit. Hier gibt es nun mehrere Apps und Möglichkeiten. Als erstes möchte ich IFTTT vorstellen. Diesen Dienst kennt wahrscheinlich schon die Mehrheit von euch. Dazu muss man als erstes die App installieren und die Location-Services für die App zulassen.

Dazu muss man natürlich damit leben, dass theoretisch ein komplettes Bewegungsprofil von euch gespeichert wird. Was genau mit den Daten passiert, weiss man also nicht. Für total verrückte Datenschutzanhänger ist die Lösung also nichts – das wird aber sicher in den Kommentaren auch noch einmal erwähnt.

Leider muss man je Gebiet zwei Aktionen erstellen. Also einmal, wenn man das Gebiet betritt und einmal, wenn man es verlässt. Dazu zieht man als erstes einen Radius auf und kann im nächsten Schritt auswählen, was passieren soll. Im zweiten Schritt, also bei der Aktion, wählen wir “Maker Webhooks” / “Make a web request” aus. So können wir eine beliebige URL triggern, wenn die Aktion ausgeführt wird.

Als URL stellen wir z.B. Folgendes ein:

https://ifttt:kkjshgk325@fhem.meintechblog.de/fhem?cmd=setreading%20arbeitszeit%20angekommen%20{{OccurredAt}}&XHR=1
  • ifttt ist dabei der Benutzername für die Authentication
  • kkjshgk325 ist das Passwort des Benutzers
  • fhem.meintechblog.de/fhem ist die URL über den Reverse-Proxy zu FHEM
  • Als Kommando können wir nun alles Mögliche tun. Ich habe mich für das Setzen eines Readings in einem Dummy-Device entschieden.
  • Der Wert des Readings ist dabei ein Platzhalter aus IFTTT – {{OccurredAt}} – diesen ersetzt IFTTT durch das aktuelle Datum und die aktuelle Uhrzeit beim Request. Eigentlich brauchen wir diese Info nicht, da schließlich das Reading selbst den Änderungszeitpunkt loggt

Und dann können wir mit diesen Daten auch schon tun, was wir möchten! Sei es Notifications versenden oder andere Spielereien.

Gerade in der Kombination mit IFTTT gewinnt man so neben den Location-Diensten ein mächtiges Feature hinzu. So kann man jede beliebige Quelle mit FHEM verknüpfen! So könnte man sich z.B. informieren lassen, wenn auf meintechblog.de ein neues Beitrag erscheint. Cool, oder?

Eine weitere Möglichkeit wäre die iOS-App FHEM APP zur Hausautomation mit FHEM (Affiliate-Link). Hier gibt es einen eigenen Menüpunkt “Geofency”, in welchen man ebenfalls zu bestimmten Orten URLs triggern kann. Hier sogar separat für Ankommen und Verlassen.

Möchte man ausschließlich die Anwesenheit kontrollieren, wäre diese App für mich die beste Variante, da diese App die Daten nicht irgendwo in ein großes Rechenzentrum zur Weiterverarbeitung leitet, sondern einfach nur stumpf die URL aufruft.

Natürlich gibt es noch weitere tolle Apps und Möglichkeiten für diesen Anwendungsfall – aber ich denke der Grundgedanke ist klar geworden und die großen Hürden wurden bereits ganz oben im Beitrag genommen.

Ich hoffe, ich konnte Euch ein wenig weiterhelfen! Falls ihr das Ganze noch einmal in einem Video erleben möchtet, habe ich diese Infos ebenfalls auf meinem YouTube-Kanal für euch zusammengefasst.

YouTube

Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube.
Mehr erfahren

Video laden

YouTube

Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube.
Mehr erfahren

Video laden

Affiliate-Links

13 Kommentare
  1. Hier gibt es glaub eine kleine Unstimmigkeit:

    fhem.meintechblog.de (im Fall von allinkl oder einem anderen Provider)
    deinname.dyndns.org (wenn man sich z.B. für dyndns.org entscheidet)

    Ab jetzt sollte über https://deinedomain.de/fhem alles wie gewünscht aufrufbar sein. Wichtig ist hier natürlich HTTPS statt HTTP (Port 80 haben wir ja nicht weitergeleitet) und /fhem am Ende.

  2. Hallo Matthias,

    wäre es nicht sinnvoll auf einem Deiner Raspberry PIs einen DNS Server aufzusetzen um intern und extern die selben Namen ohne Performanceprobleme verwenden zu können oder habe ich in deinem Artikel was übersehen?

    Viele Grüße

    Stefan

    1. Sicherlich eine gute Idee, auf meinem Root-Server für Webseiten habe ich Unbound dafür installiert. Klappt auch super 🙂 Alternativ könnte man auf den Rechnern, welche das Netz eh nie verlassen auch die /etc/hosts entsprechend erweitern (was natürlich nicht ganz so sexy ist wie ein eigener DNS). Danke für den Tipp! Echt gute Idee 🙂

  3. Hallo Matthias,
    bei mir wird beim start von Apache die fehlende Datei : /etc/letsencrypt/options-ssl-apache.conf angemeckert. Die Datei wird nicht angelegt.
    VG Thomas

  4. Ich würde die Iphone App Locative empfehlen ist gratis und mann kann die url manuel eingeben, ich hab über meinen Webserver ein Php Script das die Daten an den FHEM Server weitergiebt.(Sicherheit) .

    Über Bluetooth Bacon habe ich auch schon versuche, ist aber sehr instabiel.

  5. Hallo Matthias,

    wieder mal ein toller Artikel! Ich habe jedoch eine Anmerkung:

    Wenn Du, wie beschrieben, vom Apache an FHEM eine Benutzer/Passwort-Authentifikation durchreichen möhtest, dann musst Du zusätzlich mod_headers im Apache aktivieren, da sonst “RequestHeader” nicht verstanden und als Fehler in der Config erkannt wird.

    sudo a2enmod headers

  6. Und wenn man jetzt einen Anschluss von UnityMedia mit DS-Lite hat?
    Sollte man dann versuchen eine Lösung über einen Tunnelbroker zB. Feste-IP.net oä zu finden oder kann man einen beherzten Schritt in Richtung Zukunft und IPv6 wagen?

    1. Da ich davon nich betroffen bin, kann ich leider keinen Tipp geben, welches die beste Lösung ist :/ Zu wenig Erfahrungswerte von meiner Seite.

  7. Hallo Matthias,

    schöne Lösung, die prima funktioniert.

    Nicht hinbekommen habe ich allerdings Deinen Hinweis den Apache auch für andere Geräte im Haus zu nutzen. Was muss außer der zusätzlichen in der “sub.domain.de.conf” noch geändert werden?
    Beispiel: neben “sub.domain.de/fhem => localhost:8083/fhem” soll auch “sub.domain.de/nas => 192.168.178.15” weitergeleitet werden.

    Ich bekomme da einen Fehler und die URL wird im Browser zu “sub.domain.de/fhemfhemfhemfhem…”. Probiere ich bei “sub.domain.de/nas => localhost:8083/fhem” geht es. Scheint also damit zu tun zu haben, dass das Proxy Ziel nicht mehr localhost ist.

    Freue mich über eine Idee 🙂

  8. Hallo,

    für die Android-Nutzer ist die App “Tasker” evtl. eine gute Alternative für IFTTT. Das ganze funktioniert damit auf “offline”, man ist also nicht auf einen Webdienst angewiesen.

    @Eike: In deinem Fall müsste es ausreichen, eine zweite Location hinzuzufügen (ggf. mit eigener Authorisation):

    ProxyPass http://192.168.178.15
    ProxyPassReverse http://192.168.178.15

    In meinem Blog habe ich mich auch mit dem Hosten von mehreren Webanwendungen über einen Reverse-Proxy beschäftigt (hier am Beispiel ownCloud/Nextcloud/WordPress): https://decatec.de/home-server/zweite-web-anwendung-neben-owncloudnextcloud-einrichten-am-beispiel-wordpress/
    Ich verwende dazu allerdings nicht Apache, sondern nginx als Webserver, da diese (insbesondere auf einem Raspi) deutlich performanter ist und meiner Meinung nach einfacher zu konfigurieren ist. Das Prinzip ist jedoch das gleiche.

    Gruß,
    Jan

  9. Hallo,
    ich kämpfe mich gerade durch die Anleitung.
    Frage: “Dazu laden wir die entsprechenden Quellen per git”
    Das soll auf dem Raspi per ssh gemacht werden? Allerdings kennt er den Befehl git nicht.
    Wie mache ich da weiter?

    Gruß
    Stephan

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Das könnte dir auch gefallen