WLan-Anwesenheitserkennung mit UniFi-Accesspoints in FHEM einbinden und an Loxone weiterleiten

IM EINSATZ?

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

FHEM, für mich nach wie vor das Schweizer Taschenmesser unter den Smart-Home-Gateways, setze ich nun auch für die heimische Anwesenheitserkennung per WLan ein. Da ich insgesamt vier UniFi-Accesspoints installiert habe, verrät mir das System sogar recht genau, in welchem Bereich des Hauses welches Gerät anzutreffen ist.

Wie man diese wirklich zuverlässige WLan-Anwesenheitserkennung in nur wenigen Schritten auf einem Raspberry Pi einrichtet, ist Inhalt des nachfolgenden Blogpost. Hier wird anschließend auch kurz gezeigt, wie die Anwesenheitsinfos einzelner Devices zwecks Visualisierung an Loxone weitergereicht werden können.

UniFi-Accesspoints und die Tracking-Möglichkeiten

Nach mehr als eineinhalb Jahren seit meinem ersten Blogpost Pimp my WLAN – Bester Empfang im ganzen Haus durch Zero Handoff Roaming folgt nun endlich ein weiterführender Artikel zum Thema UniFi, den ich aufgrund des zurückliegenden Hausbaus einfach immer wieder vor mich her geschoben hatte. Umso froher bin ich, dass die Umsetzung auf Anhieb geklappt hat und die Qualität der Anwesenheitserkennung – es werden primär zwei iPhone X getrackt – bisher absolut fehlerfrei läuft.

Aktuell nutze ich dazu pro Stockwerk zwei UAP-PRO (Affiliate-Link), welche räumlich so positioniert sind, dass die beiden Stockwerke des Hauses recht gleichmäßig versorgt werden. Im Erdgeschoss ist ein Accesspoint bspw. hinter der Küchenblende und ein weiterer im hinteren Dielenbereich installiert:

Das Besondere am WLan-Tracking der hier vorgestellten UniFi-Lösung ist dabei, dass keine stromfressende, direkte Abfrage einzelner Geräte (LAN-Ping) notwendig ist. Mobile Endgeräte, die im Standby aus naheliegenden Gründen auf Stromsparmechanismen zurückgreifen müssen, wären so nämlich nach wenigen Minuten nicht mehr erreichbar und würden als “offline” angezeigt, obwohl sie sich noch vor Ort befinden.

Stattdessen lässt sich die Anwesenheitsinformation direkt aus dem UniFi-Controller auslesen, welcher primär als Einrichtungs- und Verwaltungssoftware der UniFi-Accesspoints fungiert. Und das funktioniert auch dann reibungsfrei, wenn Geräte in den Stromsparmodus wechseln und nicht mehr anpingbar sind. Einzige Einschränkung ist dabei, dass der Status eines “schlafendes” Gerätes beim Verlassen der Reichweite erst nach einer Verzögerung von knapp fünf Minuten auf “offline” wechselt. Aber diese Einschränkung ist halb so wild, gerade wenn man noch weitere Ortungsdienste wie bspw. Geofancing oder die Anwesenheitserkennung durch Präsenzmelder einbeziehen kann.

UniFi-Controller auf dem Raspberry Pi installieren

Die UniFi-Controller-Software ist glücklicherweise für verschiedene Betriebssysteme verfügbar und lässt sich so auch mit wenigen Handgriffen auf einem Raspberry Pi installieren. Genutzt werden kann bspw. ein Grundsystem, basierend auf einem Raspbian-Image, dessen Einrichtung inkl. FHEM im Artikel FHEM-Server auf dem Raspberry Pi in weniger als einer Stunde einrichten beschrieben wurde.

In meinem Fall kommt aber ein bereits im Schaltschrank installierter Raspberry Pi auf Basis eines fertigen LoxBerry-Image zum Einsatz, wie im Blopost LoxBerry in 10 Minuten auf dem Raspberry Pi installieren – Die ultimative Erweiterung für dein Smart Home von Loxone erklärt. Das Coole an LoxBerry ist dabei, dass sich dort FHEM als LoxBerry-Plugin mit nur einem Klick nachinstallieren lässt und man auf diese Weise super einfach mehrere “Welten” unter einer Haube kombinieren kann.

Aber egal welches Grundsystem darunterliegt, die Installation läuft im Grunde überall gleich ab. Im Detail unterscheiden sich die Befehle aber dennoch etwas, weshalb nachfolgend zwei Wege gezeigt werden, einmal für ein Raspbian-Grundsystem und einmal für eine fertige LoxBerry-Installation.

Zuerst per ssh auf dem Raspberry Pi einloggen.

Im Falle von Raspbian lautet der Login:

ssh pi@192.168.3.69

Die IP muss natürlich jeder entsprechend anpassen. Das Standardpasswort lautet – sofern nicht geändert – “raspberry” (ohne Anführungszeichen).

Als Voraussetzungen wird JSON benötigt, welches vermutlich schon vorinstalliert ist. Zur Sicherheit einfach nochmal prüfen:

sudo apt-get -y install libjson-perl

Dann werden die notwendigen Sources für den UniFi-Controller hinzugefügt:

sudo sh -c "echo 'deb http://www.ubnt.com/downloads/unifi/debian stable ubiquiti' > /etc/apt/sources.list.d/ubnt.list"

Anschließend werden die notwendigen Keys ergänzt:

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv 06E85760C0A52C50

Abschließend wird der UniFi-Controller installiert:

sudo apt-get -y --allow-unauthenticated install unifi

Ganz zum Schluss dann noch ein Neustart des Systems:

sudo reboot

Wer den UniFi-Controller bereits installiert hat, kann auch einfach ein Update anstoßen mit: “sudo apt-get update && sudo apt-get -y –allow-unauthenticated install unifi” (ohne Anführungszeichen) – Neue Versionen sind übrigens in regelmäßigen Abständen verfügbar, es lohnt sich also hin und wieder ein Update anzustoßen.

Im Falle von LoxBerry lautet der Login:

ssh loxberry@loxberry.fritz.box

Auf einem LoxBerry-System sehen die Befehle wie gesagt etwas anders aus, da hier root-Befehle nicht per “sudo” ausgeführt werden können. Stattdessen loggt man sich erstmal per ssh regulär mit dem im System hinterlegten User ein (hier “loxberry”) und wechselt dann in der Konsole mit “su -” (ohne Anführungszeichen) in die root-shell, gefolgt von den nachfolgenden Befehlen:

echo "deb http://www.ubnt.com/downloads/unifi/debian stable ubiquiti" > /etc/apt/sources.list.d/ubnt.list

apt-key adv --keyserver keyserver.ubuntu.com --recv 06E85760C0A52C50

apt-get -y install unifi

reboot

Nach dem Neustart des Systems – egal ob Raspbian oder LoxBerry – ist der Unifi-Controller dann unter dem Port 8443 erreichbar:

https://192.168.3.69:8443 bzw. https://loxberry.fritz.box:8443

Wichtig dabei ist das https, da eine verschlüsselte Verbindung aufgebaut wird.

Wer die initiale Einrichtung seiner UniFi-Accesspoints auf einem anderen System durchgeführt hat, kann die bestehende Konfiguration praktischerweise auf dem Raspberry Pi übernehmen, um nicht alles neu einrichten zu müssen. Dazu einfach im Ursprungssystem auf “Settings” -> “Maintenance” -> “Download Backup” klicken un die Sicherung mit der Endung .unf landet auf der Fesplatte. Im neuen System dann “Restore” -> “Choose File” wählen und das Backup zurückspielen. Sobald alles wie gewünscht läuft, geht es an den nächsten Schritt.

UniFi-Controller in FHEM einbinden

In FHEM lässt sich der uniFi-Controller einfach über den FHEM-Konsolenbefehl

define UnifiController Unifi localhost 8443 username password

einbinden. “username” und “password” sind die Login-Daten, die im UniFi-Controller vergeben wurden. Wer nur möchte, dass FHEM lesenden Zugriff auf die Daten erhält, muss vorher eben entsprechend einen Benutzer mit eingeschränkten Rechten im UniFi-Controller einrichten.

Standardmäßig aktualisiert FHEM den Online-Status der WLan-Devices dann alle 30 Sekunden. Wer diesen Wert ändern möchte (würde ich jedoch nicht empfehlen), muss obigen Befehl nur um das passende Attribut ergänzen. Details dazu in der FHEM-Commandref.

Damit man das FHEM-Device schnell wiederfindet, wird es per FHEM-Konsolenbefehl in einen Raum gepackt:

attr UnifiController room Zentral

Mit “Save config” werden alle Änderungen dauerhaft gespeichert.

UniFi-Controller Readings

Klickt man nun das Gerät in FHEM an, sollten nach kurzer Zeit alle relevanten Statusinformationen unter “Readings” auftauchen.

Neben den Informationen zu den einzelnen Accesspoints (Anzahl angemeldeter Geräte, SSID, etc.) werden hier auch alle angemeldeten WLan-Devices aufgelistet, inkl. Anwesenheitsstatus (connected, disconnected) und bei welchem Accesspoint das Geräte gerade angemeldet ist (bei mir bspw. “Diele” oder “Schlafzimmer”). Dummerweise wird hier nicht die eindeutige MAC-Adresse ausgegeben, wer also automatisierte Trigger nutzen möchte, muss darauf achten, dass sich die Gerätenamen ändern können, sofern im Endgerät ein anderer Name eingetragen wird. Beim iPhone lässt sich der Gerätename bspw. unter “Einstellungen” -> “Allgemein “-> “Info” -> “Name” anpassen.

Da ich an dieser Stelle alle für mich relevanten Informationen per UDP-Nachricht an Loxone weiterleite, habe ich keine weiterführende Logik in FHEM definiert. Deshalb hier nur eine kurze Ergänzung, wie man aus ausgewählten Readings bspw. eigene Einträge (Dummies) erstellen kann.

Erstmal einen neuen Dummy erzeugen, um bspw. den Onlinestatus eines einzelnen Endgeräts anzuzeigen:

define iPhone.Melle dummy

Und diesen Dummy dann mit dem gewünschten Reading “Ms-X” befüllen, sobald ein neues Event generiert wird:

define UnifiControllerDummyUpdate1 notify UnifiController.-UC_wlan_state.* {my $status=ReadingsVal("UnifiController", "Ms-X", "-1");; fhem ("set iPhone.Melle $status")}

Und hier noch ein zweites Gerät für das Reading “iPhone”:

define iPhone.Joerg dummy
define UnifiControllerDummyUpdate2 notify UnifiController.-UC_wlan_state.* {my $status=ReadingsVal("UnifiController", "iPhone", "-1");; fhem ("set iPhone.Joerg $status")}

Onlinestatus von FHEM an Loxone weiterleiten

Dazu wird erstmal die 99_myUtils.pm erstellt bzw. erweitert (sofern bereits vorher erstellt). Weiterführende Informationen zum Anlagen der Datei gibt es bspw. im FHEM Wiki.

Eine funktionsfähige Datei, bei welcher der Status von zwei iPhones (iPhone und Ms-X) verschickt wird, sieht bspw. so aus:

##############################################
# $Id: myUtilsTemplate.pm 7570 2015-01-14 18:31:44Z rudolfkoenig $
#
# Save this file as 99_myUtils.pm, and create your own functions in the new
# file. They are then available in every Perl expression.

package main;

use strict;
use warnings;
use POSIX;

sub
myUtils_Initialize($)
{
my ($hash) = @_;
}

# Enter you functions below _this_ line.
use IO::Socket;

#UDP Befehle senden
sub UDP_Msg($$)
{
my ($dest,$port,$cmd) = @_;
my $sock = IO::Socket::INET->new(
Proto => 'udp',
PeerPort => $port,
PeerAddr => $dest
) or die "Could not create socket: $!n";
$sock->send($cmd) or die "Send error: $!n";
return "send $cmd";
}

#UnifiControllerToLoxone
#device:

#1 state (connected, disconnected)
#2 iPhone (connected, disconnected)
#3 iPhone_accesspoint (Diele, Kind, Kueche, Schlafen)
#4 iPhone_snr (Zahl 0-100)
#5 Ms-X (connected, disconnected)
#6 Ms-X_accesspoint (Diele, Kind, Kueche, Schlafen)
#7 Ms-X_snr (int 0-100)

sub UnifiControllerToLoxone($)
{
my ($device) = @_;
my $state = ReadingsVal("$device","state","-1");
if ($state eq "disconnected") {
$state = "0";
}
if ($state eq "connected") {
$state = "1";
}
my $iPhone = ReadingsVal("$device","iPhone","-1");
if ($iPhone eq "disconnected") {
$iPhone = "0";
}
if ($iPhone eq "connected") {
$iPhone = "1";
}
my $iPhoneAP = ReadingsVal("$device","iPhone_accesspoint","-1");
if ($iPhoneAP eq "Diele") {
$iPhoneAP = "1";
}
if ($iPhoneAP eq "Kind") {
$iPhoneAP = "2";
}
if ($iPhoneAP eq "Kueche") {
$iPhoneAP = "3";
}
if ($iPhoneAP eq "Schlafen") {
$iPhoneAP = "4";
}
my $iPhoneSnr = ReadingsVal("$device","iPhone_snr","-1");
my $MsX = ReadingsVal("$device","Ms-X","-1");
if ($MsX eq "disconnected") {
$MsX = "0";
}
if ($MsX eq "connected") {
$MsX = "1";
}
my $MsXAP = ReadingsVal("$device","Ms-X_accesspoint","-1");
if ($MsXAP eq "Diele") {
$MsXAP = "1";
}
if ($MsXAP eq "Kind") {
$MsXAP = "2";
}
if ($MsXAP eq "Kueche") {
$MsXAP = "3";
}
if ($MsXAP eq "Schlafen") {
$MsXAP = "4";
}
my $MsXSnr = ReadingsVal("$device","Ms-X_snr","-1");
UDP_Msg("192.168.3.5" , "7002" , "$device: $state $iPhone $iPhoneAP $iPhoneSnr $MsX $MsXAP $MsXSnr");
}

1;

Die jeweiligen Werte muss natürlich jeder entsprechend selbst anpassen.

Jetzt fehlt nur noch das notwendige notify, um die Übertragung von FEHM zu Loxone zu initiieren. Dieser wird in die FHEM-Befehlszeile eingegeben:

define UnifiControllerToLoxone notify UnifiController.-UC_wlan_state.* {UnifiControllerToLoxone("$NAME")}

Ein abschließendes “Save config” nicht vergessen.

Onlinestatus in Loxone einlesen

Um die UDP-Nachrichten in Loxone entgegenzunehmen, wird erstmal ein “Virtueller UDP Eingang” mit dem “UDP Empfangsport” 7002 erstellt. Darunter hängen dann die jeweiligen “Virtuellen UDP Eingangsbefehle”, um die einzelnen Werte einzulesen.

[table id=31 /]

Die Elemente werden dann noch mit passenden Status-Elementen verbunden, um den jeweiligen Online-Status passend zu visualisieren:

In der Loxone-App sehen die Anwesenheitsstatus dann folgendermaßen aus:

Wenn es beim Einlesen der Statuswerte hakt, startet man in der Loxone Config am besten den “UDP Monitor”. So sieht man direkt, ob und welche Nachrichten eingehen. So kommt man dann gewöhnlich schnell ans Ziel.

Aus meinem täglichen Leben

Mit der UniFi-Lösung bin ich insgesamt sehr zufrieden. Die UAP-PRO (Affiliate-Link) sind zwar nicht die schnellsten Accesspoints, reichen aber völlig aus, um auch mehrere HD-Streams im zweistelligen MBit-Bereich parallel an mobile Clients auszuliefern. Nur das Zero-Handoff habe ich aktuell deaktiviert, da ich hier laufend Probleme mit Geräten hatte, die sich nach dem Schlummermodus nicht mehr im WLan einloggen konnten.

Irgendwas war da bei meiner Konfigration faul, da ich auch massiv Bandbreitenprobleme hatte. Aber auch ohne Zero-Handoff funktoiniert der Gerätewechsel zwischen den Accesspoints bestens, sodass ich schon überlege die Accesspoints nach und nach gegen wesentlich schnellere UniFi AP AC High Desity (Affiliate-Link) zu tauschen. Neben dem hohen Preis schreckt mich aber vorallem der höhere Stromverbrauch ab, was sich bei insgesamt vier Accesspoints schon summiert.

In jedem Fall werde ich demnächst auch eine automatische Abschaltung nicht benötigter Accesspoints umsetzen. Nachts soll nur noch ein Accesspoint eingeschaltet bleiben und bei Abwesenheit alle vom Strom getrennt werden. Hier bietet sich die WLan-Anwesenheitserkennung mit Sicherheit an, um bspw. erst den Strom zu trennen, sobald keine der ausgewählten WLan-Geräte mehr verbunden sind.

Mit der vorgestellten WLan-Anwesenheitserkennung ist mein Setup nun also noch ein Stückchen vollständiger. Im laufenden Betrieb ist es wirklich immer spannend zu sehen, wie schnell die mobilen Endgeräte zwischen den Accesspoints wechseln, wenn man sich im Haus bewegt – auch ohne Zero-Handoff-Funktion. Entsprechend kann man aus den anzeigten Informationen sogar recht genau ableiten, in welchem Bereich sich gerade welches Endgerät befindet. Aktuell nutze ich diese zusätzliche Information jedoch noch nicht, ebensowenig wie die übermittelte Information zur Signalqualität. Aber wie so oft kommen Ideen für neue Anwendungsfälle irgendwann automatisch beim Herumspielen.

Als nächsten Schritt werde ich die WLan-Statusinfos erstmal auf Hausebene nutzen, um die Anwesenheitserkennung – aktuell basierend auf Präsenmeldern, wie im Artikel Operation Smart Home – Präsenzzonen für eine vollautomatische Beleuchtung sinnvoll nutzen beschrieben – zu erweitern. Um Strom zu sparen, kommen die Accesspoints zudem an schaltbare Steckdosen. Wobei es natürlich auch schön wäre, wenn sich die Accesspints einzeln über die UniFi-Controller-Integration ein- und ausschalten lassen würden. Mal sehen, evtl. ist das ja sogar schon mit dem passenden Befehl möglich. Oder ich tausche meinen Switch gegen einen Ubiquiti US-24-250W (Affiliate-Link). Dieser lässt sich dann ebenfalls vom UniFi-Controller aus steuern, sodass vermtulich auch einzelne Ports deaktiviert werden können. Mal sehen.

46 Kommentare
  1. hallo Jörg,

    danke für deinen Beitrag.
    Ich habe es bei mir ähnlich realisiert und bin mit meinen APs nach wie vor sehr glücklich. Ich nutze die Erkennung an welchem AP ich angemeldet bin zum Beispiel um die Follow-Me-Funktion der msg-Funktion zu nutzen und Sprachausgaben nur in Räumen auszugeben, in denen ich mich gerade befinde.
    Außerdem wird für eindeutig erkannte Räume die Heizung darüber geregelt.

    Funktioniert sehr gut.

    Gruß Mchael

    1. Hi Michael,
      wieviele AP hast du verbaut? Und hast du das Abfrage-Timing bei 30 Sekunden gelassen oder angepasst? Damit wollte ich mal etwas herumspielen…

      Grüße
      Jörg

  2. Hi Jörg,

    wann hast du das auf deinem PI zuletzt installiert?Ich hab des vor 14 Tagen schon vergeblich versucht, und eben nach deiner Anleitung nochmal. Selber Fehler 🙁 Unifi möchte eine mongodb Datenbank die es so für unseren (32Bit-System) Pi nicht mehr gibt 🙁
    The following packages have unmet dependencies:
    unifi : Depends: mongodb-server (>= 2.4.10) but it is not installable or
    mongodb-10gen (>= 2.4.14) but it is not installable or
    mongodb-org-server (>= 2.6.0) but it is not installable
    E: Unable to correct problems, you have held broken packages.

    Hast du da evtl ne Lösung 😉

    Grüße
    Achim

  3. Netter Beitrag, aber mal eine ernst gemeinte Frage:
    Welche Ersparnis erwartest du pro Jahr, wenn du die APs selektiv ausschaltest? Und dagegengerechnet: was kostet dich die Umsetzung des Ein-/Ausschaltens?
    Ich finde sowas immer irgendwie fragwürdig. 50€ investieren um 5€ pro Jahr zu sparen …
    Sparpotential sehe ich eher wo anders: einfach einen AP pro Etage weglassen. So groß ist deine Bude ja nun auch nicht, oder sind die Wände aus Stahlbeton?

    Viele Grüße
    Hans

    1. Hi Hans,

      drei Accesspoints brauchen etwa 20 Watt. Wenn ich diese bei Abwesenheit und Nachts automatisch ausschalte (für die Beispielrechnung einfach mal 12 Std/Tag), spart das bei 29 CT/kWh im Jahr knappe 25 Euro. Den vierten Accesspoint würde ich nachts anlassen, bei Abwesenheit könnte dieser natürlich auch vom Strom getrennt werden. Dann wäre die Einsparung noch größer. Da bei mir eh jede Steckdose schaltbar ist, kann ich die dafür notwendige Funktion recht simpel durch etwas Softwarelogik abbilden.

      Ein AP pro Stockwerk würde im Grunde schon reichen, klar. Kommt eben auf den eigenen Anspruch an. Ich möchte in allen Räumen einen gleichmäßig guten Empfang sicherstellen ohne Geschwindigkeitseinbrüche, denen man bei weniger AP zwangsläufig ausgesetzt ist. Vorallem auch im 5 GHz-Bereich. Und das schaffe ich nur mit zwei AP pro Stockwerk, habe da viel getestet.

      Grüße
      Jörg

    2. Hi Jörg,

      Super Beitrag, danke. Ich habe auch mein Netz auf Unifi umgebaut 🙂 3 AC-PRO APs, 4 Switches, Cloudkey und USG 🙂 Ich bin sehr zufrieden.
      Wie schaltest du deine einzelne APs an und aus? Ich finde nur die Option alle auszuschalten?
      Ich habe nur mit dem FHEM Plugin Erfolg gehabt:
      set poeMode

      Machst du es irgendwei anders?

  4. Hi Jörg,
    die Punkte “Jörg Zuhause” und “Melle Zuhause” hast du wie umgesetzt?
    Hintergrund: ich will einen Merker der “1” wird, wenn irgendjemand zuhause ist. Als Trigger für die Alarmanlage bzw. für den reset. (also, wenn beide iPhone weg sind=Alarm scharf; ein iPhone heimkommt=reset)
    LG

    1. Hi Herbert,
      das habe ich per Geofencing über Homebridge gelöst. Die jeweiligen iPhones senden dann über die “Home”-App die Info, ob das Gerät den definierten GPS-Bereich (z.B. 100m-Radius ums Haus) betritt oder verlässt. Funktioniert absolut zuverlässig.

      Grüße
      Jörg

    2. Hi Jörg,
      danke für die Antwort.
      Geofencing mittels ATV funktioniert bei mir leider nicht zuverlässig. kA woran es liegt aber manchmal wird der Status des iPhones (meist das meiner Frau) nicht erkannt.
      Die Anwesenheit mittels Unifi APs gefällt mir und wird gerade zu meiner ersten FMEM Erfahrung. Etwas strauchle ich noch, da sich mir nicht erschließt wozu bspw. die dummys verwendet werden. Sie finden sich nirgends (also 99_myUtils.pm) wieder?!
      Und ob ich für jeden Wert einen Dummy brauche. Also Status, AP und Snr?
      Da blicke ich noch nicht so ganz durch.
      Hab 2 dummies erstellt und die 99_myUtils.pm von dir adaptiert.
      Mit dem Ergebnis, dass das iPhone meiner Frau mit 0% angezeigt wird. Meines zB. aber gar nicht. Obwohl ich eigentlich dasselbe gemacht habe.
      Tja… aller Anfang ist wohl schwer 🙂
      LG

    3. Oja,
      davon kann ich ein Lied singen. 🙂

      Dummys tauchen nur in der fhem.cfg auf. Die 99_myUtils.pm ist ausschließlich für “Sonderlocken” bestimmt.

      Werte kannst du grundsätzlich in Dummys speichern, gewöhnlich dann in dessen Reading “state”. Ich mache es mittlerweile aber oftmals so, dass ich gewünschte Werte nicht immer in extra Dummys speichere, sondern bestehende Devices um entsprechende Readings manuell erweitere, um eben die Werte dort reinzuquetschen. Das ist oftmals übersichtlicher, wobei das natürlich Geschmackssache ist.

      Grüße
      Jörg

      PS: Ist den Apple TV per WLAN oder Kabel angebunden? Bei mir per LAN-Kabel.

    4. hi,
      ja meine ist per WLAN angebunden. Werd ich bei Gelegenheit mal checken obs daran liegt.
      Ich hänge leider etwas bei der o.a. Anleitung.
      Ich denke alles richtig gemacht zu haben (was natürlich nicht sein kann :))
      In Loxone kommt folgendes an: UnifiController: 1 1 AP Speis 35 AP Speis 32 -1 (UnifiController 1 state [1,0000],UnifiController 2 iPhone-Babsi [1,00000],UnifiController 3 iPhone-Babsi AP [0,00000])

      Das wars. Das Ergebnis ist, dass meine Frau immer “grün” ist und 0% hat. Auch, wenn sie lt. Controller disconnected ist. Die anderen 2 iPhones werden zudem vollkommen ignoriert.

      Im FHEM Log steht folgendes:
      2018.05.05 18:38:50 3: UnifiControllerToLoxone return value: send UnifiController: 1 1 AP OG 29 1 AP Speis 25 -1

      Was mache ich denn falsch?
      Dank und Grüße
      Herbert

    5. Hi Herbert,
      hmmm. Also bei mir kommt in Loxone als “Texdaten” im “UDP Monitor” z.B. sowas an:

      UnifController: 1 0 2 16 1 3 45

      Es dürfen also nur Zahlenwerte ankommen, dann sollte es auch klappen. Du liest die Readings anscheinend irgendwie nicht korrekt aus… Vielleicht hilft dir das ja schon weiter.

      Grüße
      Jörg

  5. Mal wieder ein toller und nützlicher Bericht! Ich nutze das auch schon länger und steuere einige Dinge mit der Anwesenheitskontrolle. Da die wenigsten wohl Loxone nutzen und alles innerhalb FHEM verarbeiten hier mein Notify um den Device DUMMY mit allen Infos aus dem Unifi Controller zu füllen. Eventuell ist es für den einen oder anderen nützlich:

    UnifiController.-UC_wlan_state.* { $EVENT=~s/://;;;; fhem(“setreading DirkS8 $EVENT”) ;;;; my $status=ReadingsVal(“UnifiController”, “Dirks-Galaxy-S8”, “-1”); fhem (“set DirkS8 $status”) ;;;; my $DirksAP= ReadingsVal(“UnifiController”,”Dirks-Galaxy-S8_accesspoint”,0) ;;;; fhem(“setreading DirkS8 AP $DirksAP”) ;;;; my $DirksSNR= ReadingsVal(“UnifiController”,”Dirks-Galaxy-S8_snr”,0) ;;;; fhem(“setreading DirkS8 SNR $DirksSNR”) ;;;; my $DirksESSID= ReadingsVal(“UnifiController”,”Dirks-Galaxy-S8_essid”,0) ;;;; fhem(“setreading DirkS8 ESSID $DirksESSID”) ;;;; my $DirksHOST= ReadingsVal(“UnifiController”,”Dirks-Galaxy-S8_hostname”,0) ;;;; fhem(“setreading DirkS8 hostname AP $DirksHOST”) ;;;; my $DirksSEEN= ReadingsVal(“UnifiController”,”Dirks-Galaxy-S8_last_seen”,0) ;;;; fhem(“setreading DirkS8 last_seen $DirksSEEN”)}

  6. Das ganze sollte auch ohne FHEM direkt mit Loxone funktionieren. Auf dem UniFi Controller muss einfach der Miniserver als Syslog-Server angegeben werden. Schon purzeln die ganzen Events direkt per UDP am Miniserver ein.

    1. Hmm,
      die Option “Enable remote Syslog server” ist aktiviert, Miniserver-Adresse und -Port eingetragen – leider kommen keine Daten per UDP rein…

    2. Also ich habe bei mir “Enable remote Syslog server” angehakt, IP vom Miniserver eingegeben und den Port bei 514 belassen. Im UDP Monitor sehe ich dann die events, wie z.B: “EVENT_STA_IP ath1: XX:XX:XX:XX:XX:XX” und “EVENT_STA_LEAVE …” Hiermit kann ich dann das an und abmelden als Digitaleingang in Loxone entgegennehmen.

      Tipp: da die Clients sich mal auf ath0, ath1, ath2 usw. verbinden, sollte man bei der Befehlerkennung mit der Wildcard arbeiten, also “ath\.”

    3. ja, das scheint zu gehen…. 🙂 super.
      Patrick, wie genau hast du das in Loxone per Virtual Input implementiert?

    4. Ich habe einen virtuellen Eingang ohne Prüfung der Senderadresse, aber mit Empfangsport 514 angelegt. Darunter habe ich für jedes Gerät dessen Anwesenheit ich tracken will 2 Befehle als Digitaleingänge angelegt. Im ersten wird eben,wie bereits beschrieben, der EVENT_STA_IP abgefangen (Gerät hat eine IP erhalten) und EVENT_STA_LEAVE (Gerät hat WLAN verlassen).

      Ob ein Gerät nun an- oder abwesend ist, zeigt der Baustein virtueller Status “iPhone 8 Plus Patrick”. Gesetzt wird der von einem Impulsschalter SR. Wenn EVENT_STA_IP getriggert wird, erhält der Impulsschalter auf S eine 1. Wird EVENT_STA_LEAVE getriggert, wird der Impulsschalter auf R resettet. Zusätzlich habe ich vor den R Eingang noch ein verzögerter Impuls geschnallt (D:60, T:0,5). Damit wird LEAVE nur dann an den Impulsschalter weitergegeben, wenn nicht innerhalb von 60 Sekunden wieder ein STA_IP kommt.

    5. Danke für diesen Tipp. Funktioniert super!

      @Oisin:
      EVENT_STA_LEAVE ath\.:

      STA_JOIN wird im Lösungsvorschlag von Patrick nicht benötigt.

    1. Welchen Port nutzt du und wie oft kommen Nachrichten an? Kannst du evtl. mal einen Auszug der übermittelten UDP-Nachricht posten?

  7. Ich habe es so wie du Jörg implementiert, funktioniert ganz gut. Danke!

    Wie könnte ich die Details aus dem “get cliendData” zu Loxone schicken?
    Ich hätte gerne dazu die info, ob 5GHz oder 2.4GHz, geht das?

    1. Hi Oisin,
      bekomme in FHEM kein Reading vom Unifi-Controller, der den Status 2,4 bzw 5 GHz enthält. Vielleicht sprichst du übers FHEM-Forum einfach mal den Plugin-Entwickler an. Denn technisch sollte das schon möglich sein denke ich.

      Grüße
      Jörg

    2. Hi Jörg, mit get clientData bekommt man eine Kanalnummer, davon kann man learnen ob ein Client eine 5Ghz oder eine 2.4Ghz Verbindung hat.

  8. Hallo Jörg

    Wie hast du das mit dem Datum bei “Ereignisse” gelöst?
    Ich übergebe bei 4 Handy die 3 Werte: Connected/Disconnected, Signalstärke und Zeit.
    Status und Signal funktionieren aber beim Datum gibt er mir nur 2018,0 aus und nicht z.B. 2018-10-3 10:50:10.
    Wie muss ich hier die Befehlskennung einstellen?
    So wie in deiner Erklärung splittet er mir auch beim Leerzeichen zwischen Datum und Zeit.

    Danke für die Hilfe

  9. Wie sieht denn der konkrete Befehl im virtuellen UDP – Eingang aus? Was ich nicht ganz verstehe: brauche ich unter dem virtuellen UDP Eingang virtuelle UDP eingangsbefehle? Oder brauche ich ganz normale virtuelle Eingänge? Wie kriege ich es hin, dass die Entsprechende Sequenz ein Signal ein/aus generiert, was ich dann an den Impulss Halter übergebe?

  10. Ich habe das Ganze jetzt auf Basis Unify-Syslog->Loxone eingerichtet und es funktioniert. Allerdings nur “im Prinzip”. Problem ist, dass das Signal für Leave nicht geliefert wird, wenn das Device tatsächlich das Netz verlässt. Es wird immer erst wenige Sekunden “nachgeliefert”, bevor das Signal für EVENT_STA_IP kommt. Damit ist das Ganze witzlos… Hat irgendjemand eine funktionierende Umgebung hinbekommen und kann evtl. helfen? Zum Beispiel Patrick Wagner? Wäre toll

    1. Hi, ich hatte das ganze so umgesetzt:
      Eingang (anwesend): EVENT_STA_IP ath\.:
      Eingang (abwesend): EVENT_STA_LEAVE ath\.:

      Eingang (anwesend) geht direkt an einen Impulsschalter (S) und an den verzögerten Impuls (R)

      Eingang (abwesend) geht an einen verzögerten Impuls (TR), dieser dann an den Impulsschalter (R)

  11. Hallo,

    Als aktueller Entwickler des fhem-Unifi-Plugins freue ich mich, wenn das Plugin eingesetzt wird. Ein Hinweis aber doch:
    Wenn Unifi-Controller und FHEM wie hier beschrieben (localhodt) auf demselben RasPi laufen sollte das Update-Interval sicherheitshalber auf 60 Sekunden gesetzt werden. Wenn man Pech hat ist aufgrund einer kurzzeitigen hohen Prozessoranforderung irgendeines Programms/Threads ansonsten in den 30 Sekunden ein Update noch nicht vollständig durch und es wird ein neues Update angefordert. Das erhöht wiederum die Prozessorauslastung und es kommt zu einer Selbstverstärkung. Dann hilft oft nur ein reboot.
    Das Ganze hängt natürlich von dem Umfang des Unifi-Netzwerks, FHEM und was sonst noch auf dem RasPi läuft ab. Kann also auch lange gut funktionieren.

    Wäre Klasse, wenn du das als Hinweis aufnimmst.

    Die Alternative über syslog zu gehen ist da eleganter und hat nichts mit regelmäßigem Polling zu tun. Ist aber für viele auch schwieriger aufzusetzen.

    Viele Grüße,
    Dirk

  12. Hallo Jörg,

    du hast folgendes geschrieben, Zitat: “Wer nur möchte, dass FHEM lesenden Zugriff auf die Daten erhält, muss vorher eben entsprechend einen Benutzer mit eingeschränkten Rechten im UniFi-Controller einrichten.”

    Ich möchte das gerne so umsetzen, weiß aber nicht, wo ich das im Controller machen kann.

    Ich bin für Hilfe dankbar.

    Viele​ Grüße​
    Gisbert​

  13. Hallo zusammen,

    danke erstmal für die Beschreibung, mangels FHEM und Perl Wissen hat mich die Erkenntnis etwas Zeit gekostet aber jetzt läufts bei mir.

    Ich musste allerdings das Event etwas anders als von dir beschrieben nennen, nämlich:
    define UnifiControllerToLoxone notify UnifiController.#UC_wlan_state.* {UnifiControllerToLoxone(“$NAME”)}

    statt:
    define UnifiControllerToLoxone notify UnifiController.-UC_wlan_state.* {UnifiControllerToLoxone(“$NAME”)}

    Vielleicht hilfts ja jemandem, ich hab einige Zeit gesucht aber nichts gefunden..

    Grüße Stefan

  14. Schön, dass es klappt. Eine Frage: Läuft das bei Dir stabil, d.h. ohne Aussetzer? Bei mir leider nicht. Ich habe leider immer wieder Aussetzer von 1-5 Minuten, in denen das iPhone dann als nicht präsent erkannt wird, obwohl es durchgängig im WLAN ist. Da die Alarmanlage darüber gesteuert wird, habe ich mir so beholfen, dass diese eben nur scharf geschaltet wird, wenn ein Device über mindestens 20 min. dauerhaft offline ist. Aber trotzdem ist die Anwesenheitserkennung eben leider (doch) nicht zuverlässig.

  15. @ König: bisher konnte ich das noch nicht feststellen, muss aber sagen, dass das Ding eben erst seit kurzem läuft.
    Falls mir noch was auffällt meld ich mich.
    Was mir schon aufgefallen ist, ist dass sich meine iPhones erst recht spät vom Controller abmelden.

    @ Gisbert: du gehst im Controller auf Einstellungen -> Administratoren und legst einen neuen User (z.B. FHEM o.Ä.) an, der nur die read-only Rolle hat. Funktioniert bei mir.

  16. Hallo Jörg,
    das schaut doch mal endlich nach einer zuverlässigen Lösung für eine Anwesenheitserkennung aus.

    Kannst Du mir sagen, ob ich zur Umsetzung zwingend die teuren Pro AP’s benötige oder ob es auch die kostengünstigere Lite Variante tut?

  17. Ich hab 3x die Lite Version (1x Long Range) und das funktioniert bei mir recht gut.

    Ich steuere damit jetzt den Betriebsmodus der Lüftung und schicke eine Push-Benachrichtigung wenn vergessen wurde alle Türen und Fenster zu schließen.

  18. Seit ein paar Tagen funktioniert die Anwesenheitserkennung bei mir nicht mehr.
    Zwei der drei im Einsatz befindlichen iPhones springen zwischen anwesend und abwesend hin und her.

    Stellt Ihr ähnliches fest?
    Liegt das vielleicht an einem iOS Update?

  19. Ja, ich habe das Problem auch. Aus irgendwelchen Gründen werden den Devices Neue Adressen zu gewiesen, die nicht identisch mit den Mac Adressen der iPhones sind. Ich habe das gelöst, indem ich im Monitor von Loxone die Adresse neu ausgelesen habe und sie den Geräten zu gewiesen habe. Jetzt funktioniert es wieder.

    1. Habe es jetzt bei mir auch wieder hinbekommen.
      Es lag daran, das in der FritzBox die Häkchen bei „Diesem Gerät immer die gleiche IP zuweisen“ fehlte.

      Danke für Deinen Hinweis. Dadurch bin ich in die richtige Richtung gekommen!!!

  20. Aha, interessant. Verändert sich die Mac-Adresse, wenn sich die IP ändert? Du liest aber schon über die MAC-Adresse aus, oder über IP?

    1. Weder noch!

      Ich frage im FHEM mit einem DOIF den Status des Devices anhand seines Namens ab und schalte damit einen Dummy:

      DOIF ( [Unifi_Controller:Axels-IPhone] eq „connected“) (set Axel anwesend)…

  21. Hey Jörg,
    vielen Dank für deinen tollen Artikel! Habe es gerade bei mir “nachgebaut” und es funktioniert direkt einwandfrei!
    Weiter so und alles Gute!

    Viele Grüße
    Fabian

Schreibe einen Kommentar

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

Das könnte dir auch gefallen