In unserem letzten Beitrag zum Thema Presence Detection (Smart Home Advanced: Anwesenheitserkennung über Geofences) haben wir die Power von Geofences für das Smart Home mit dem Open Source Server FHEM gezeigt. Geofences sind virtuelle Linien, bei deren Überquerung das Smartphone eine Kommunikation mit dem Smart Home herstellt und beispielsweise die Heizung bereits automatisch auf dem Heinweg aktiviert. Um diese Anwesenheitserkennung auch im Smart Home Server Loxone verwenden zu können, gilt es, die Anwesenheitsinformationen von FHEM an Loxone weiterzuleiten.

In diesem kurzen Howto zeigen wir, wie du das bewerkstelligst und so die intelligenten Bausteine zur Smart-Home-Programmierung in Loxone noch besser nutzen kannst.Vorab: Hier der Loxone Onlineshop meines Vertrauens, sofern ihr “akuten” Bedarf habt: smarthirsch.de (Affiliate-Link)

Voraussetzung für dieses Howto ist, dass du die Geofence-Anwesenheitserkennung mit FHEM, wie im Blogpost Smart Home Advanced: Anwesenheitserkennung über Geofences beschrieben, bereits umgesetzt hast. In dem genannten Artikel zeigen wir dir, wie du mit FHEM (einem Open Source Smart Home Server), der meist auf einem kleinen Raspberry Pi Einplatinencomputer (Affiliate-Link) betrieben wird, Geofences einrichtest und mit FHEM-“Bordmitteln” die Anwesenheit von Smart-Home-Bewohnern überwachst. Diese Statuswerte wollen wir jetzt in Loxone nutzen und übergeben diese per UDP-Schnittstelle.

Das grundsätzliche Vorgehen zum Datenaustausch zwischen FHEM und Loxone hatten wir bereits im Blogpost 5 Gründe zur Erweiterung deines FHEM-Servers mit Loxone + Howto geschildert.

Trigger auslösen

Die Einrichtung beginnt damit, den Trigger zu definieren, bei dem FHEM eine UDP-Nachricht an Loxone weiterleitet. Ich versuche hierbei immer so viel Information wie nötig, aber gleichzeit so wenig wie möglich zu übergeben, um den gesamten Datenaustausch zwischen FHEM und Loxone stabil zu halten. FHEM sendet jedesmal eine UDP-Nachricht, wenn das entsprechende Device ein “Event” auslöst. Um diese Events zu minimieren, nutze ich in diesem Fall das Attribut “event-on-change-reading” (das Device für meine Anwesenheit heisst “rr_Christoph”). Das Attribut wird über den folgenden Befehl in der FHEM-Kommandozeile gesetzt.

attr rr_Christoph event-on-change-reading state,wayhome

Damit wird ein Trigger immer dann ausgelöst, wenn sich entweder der Status (home, absent, …) oder die Eigenschaft “wayhome” ändert, die angibt, ob sich der Bewohner gerade auf dem Heimweg befindet.

Trigger nutzen – UDP Nachricht absenden

Im weiteren Verlauf gilt es, den durch FHEM erzeugten Trigger dahingehend zu nutzen, UDP-Nachrichten an FHEM zu versenden. In der FHEM-Kommandozeile wird dazu folgender Code abgesetzt (jede Zeile ist ein eigener Befehl).

define ResidentToLoxone notify .*:(home|absent) {ResidentToLoxone("$NAME")}

define ResidentWayHomeToLoxone notify .*:wayhome.* {ResidentToLoxone("$NAME")}

Anschließend wird in der Datei “99_myUtils.pm” (Edit files -> 99_myUtils.pm ) am Ende der Datei (jedoch noch vor der “1;”) folgender Code ergänzt, der die Statuswerte der Bewohner ausliest und per UDP als 0 oder 1 an Loxone übergibt. Siehe dazu auch im Blogpost 5 Gründe zur Erweiterung deines FHEM-Servers mit Loxone + Howto.

#AnwesenheitToLoxone
sub ResidentToLoxone ($)
{
my ($device) = @_;
my $state = ReadingsVal("$device","state","-1");
if ($state eq "absent") {
$state = "0";
}
if ($state eq "home") {
$state = "1";
}
my $arrival=time_str2num(ReadingsVal("$device","lastArrival","-1"));
my $departure=time_str2num(ReadingsVal("$device","lastDeparture","-1"));
my $wayhome=ReadingsVal("$device","wayhome","-1");

UDP_Msg("192.168.178.76" , "7000" , "$device: $state $arrival $departure $wayhome");
}

Wer noch keinen UDP-Austausch zwischen FHEM und Loxone konfiguriert hat, ergänzt anschließend auch noch folgende Zeilen.

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";
}

Statuswerte in Loxone empfangen uns auslesen

Wie schon im Blogpost 5 Gründe zur Erweiterung deines FHEM-Servers mit Loxone + Howto erklärt, wird in Loxone ein neuer UDP-Eingang (z.B. “FHEM UDP”) angelegt.

Unterhalb des Eingangs kann dann für jeden Statuswert ein neuer “Virtueller UDP Eingang Befehl” angelegt werden. In der Befehlserkennung im Eigenschaften-Fenster auf der linken Seite, wird dann definiert, welcher der per UDP übergebenen Werte ausgelesen werden soll.

Für den Anwesenheitsstatus rr_Christoph wird hier “rr_Christoph: \v” (ohne Anführungszeichen) eingegeben. Außerdem lege ich folgende, weitere “Virtuelle UDP Eingang Befehle” an, die den Zeitpunkt der letzten Ankunft, des letzten Verlassens und des Wayhome-Status auslesen.

Diese erhalten unterschiedliche Befehlserkennungen

• Last Arrival, Befehlserkennung rr_Christoph: \# \v
• Last Departure, Befehlserkennung rr_Christoph: \# \# \v
• Wayhome-Status, Befehlserkennung rr_Christoph: \# \# \# \v

Visualisierung der Anwesenheit konfigurieren

Die Loxone Config bietet verschiedene Möglichkeiten, Statuswerte zu visualisieren. Ich habe die Viualisierung wie folgt gebaut.

Die dazugehörige Konfiguration in Loxone sieht wie folgt aus.

Der zentrale Baustein “Christoph” ist ein Status-Baustein und hat den Haken “Verwenden” unter “Visualisierung” links im Eigenschaften-Fenster gesetzt. Am Eingang A1 hänge ich den Anwesenheitsstatus an. Der Eingang A2 wird mit dem Wayhome-Status verbunden, dem jedoch zunächst ein weiterer Status-Baustein vorgeschoben wird.

Schauen wir uns zunächst den Status-Baustein an, an dem der Wayhome-Status hängt. Ein Doppelklick darauf zeigt die Konfiguration.

Die Konfiguration bewirkt, dass bei einer 0, der Status “unterwegs” und bei einer 1, der Status “auf dem Weg nach Hause” angezeigt wird. Der Textausgang (!) dieses Bausteins wird dann mit dem zweiten Status-Baustein (an A2) verbunden. Er selbst wird nicht in der Visualisierung verwendet (Haken entfernen).

In der Konfiguration des zentralen Bausteins sieht die Konfiguration wie folgt aus.

Liefert die Anwesenheit eine 1, so wird “Zuhause” ausgegeben (und ein eigenes Symbol dafür). Liefert die Anwesenheit 0, wird “Abwesend”, erweitert um “und <v2>” ausgegeben. Dies bewirkt, dass der Status bei Abwesenheit entweder “Abwesend und unterwegs” oder “Abwesend und auf dem Weg nach Hause” lautet.

Ferner möchte ich die Uhrzeiten des letzten Eintreffens bzw. Verlassens auslesen. Dazu nutze ich “Merker”, die ebenfalls den “Verwenden”-Haken in der Visualisierung erhalten. Diese werden über eine Formel mit den Werten für die letzte Ankunft und das letzte Verlassen verbunden. Die Merker erhalten die Einheit “<v.u>”, was ganz wichtig ist, damit der übertragene Zahlenwert als Datum/Uhrzeit angezeigt wird.

Damit der korrekte Zahlenwert an den Merkern ankommt, muss zunächst noch ein wenig gerechnet werden, weshalb der Formel-Baustein vor dem Merker hängt. Ein Doppelklick darauf öffnet den Formeleditor. Der Inhalt lautet “I1-1230760800“. Doch was heisst das?

Der Loxone Miniserver rechnet mit Zeiten am dem 01.09.2009, erhält jedoch von FHEM umgerechnete Sekundenwerte ab dem 01.01.1970 (UNIX-Standard/The Epoch). Deshalb muss der gelieferte Sekundenwert um die Differenz in Sekunden (1230760800 inkl. Zeitzonenanpassung) korrigiert werden.

So lässt sich der Anwesenheitsstatus immer schön in der Visualisierung ansehen.

Aus meinen täglichen Leben

Ich habe die Übertragung der Anwesenheit vor allem wegen der Heizungssteuerung realisiert. Im Blogpost Smart Home Basics – In 3 Schritten zur soliden Temperaturregelung hatte ich bereits die Basics meiner Loxone-basierten Heizungsregelung erklärt. Die Logik basiert dabei in zentralen Räumen auf Zeitplänen. Mit der Anwesenheitserkennung kann ich Heizungssteuerung hier noch einmal effizienter machen.

Der Baustein “Intelligente Raumregelung” stellt mit dem Eingang “Is” genau das zur Verfügung, was ich brauche: Einen Port für frühzeitiges Verlassen, bei dem die Automatik-Regelung bei Abwesenheit “überschrieben” wird und das Smart Home auf die Spartemperatur gesenkt wird.

Der Vorteil bei der Verwendung von Geofences gegenüber einer WiFi- oder Bluetooth-basierten Anwesenheitserkennung liegt dabei darin, dass nicht bei jeder kurzen Abwesenheit (z.B. ein Gang in den Keller) meine Heizung hin- und hergeregelt wird, sondern nur bei tatsächlichen Abwesenheiten. Für mich eine top Sache, denn so muss ich mich wirklich nicht mehr um die Steuerung meiner Heizung kümmern. Alles funktioniert von selbst: effizient, komfortabel und super zuverlässig!

Dabei nutze ich die super Logik von Loxone, während mein FHEM-Server meine Heizungshardware steuert. Ich nutze hierfür z.B. unter anderem die HomeMatic Funk-Heizkörperthermostate (Affiliate-Link), was super funktioniert.