Automatische Anwesenheitserkennung

Die einfache Variante, die Anwesenheit eines Gerätes über Ping zu eruieren, habe ich hier beschrieben. Dort ist auch die grundsätzliche Logik sowie bekannte Nachteile des Verfahrens beschrieben.

Mein altes iPhone hatte leider das Problem, teilweise extrem kurz im Netz zu sein. Das Ping-Gerät des CUx-Daemons hat es daher manchmal trotz vieler Versuche in kürzestmöglichen Zeitabständen nicht geschafft, die Anwesenheit festzustellen. Deshalb habe ich einen zweiten Weg ausgetüftelt, der auf dieser Seite beschrieben ist.

Aus verschiedenen Gründen war dies bisher der einzige dokumentierte Weg auf meinen Seiten – jetzt ist es die Alternative, wenn der einfache Weg nicht zuverlässig funktioniert.

Der Plan

Das Ping-Gerät des CUxD hat einige Beschränkungen, was die Frequenz des Pings angeht: Es können maximal sechs Pings am Stück gesendet werden und die Blöcke, in denen diese sechs Pings gesendet werden, liegen mindestens 15 Sekunden auseinander. Wenn das zu überwachende Gerät zu schnell wieder aus dem Netz ist, kann es sein, dass es nicht erkannt wird.

Mit meinem alten iPhone hatte ich dieses Problem – daher diese Seite –, das neue arbeitet aus irgendeinem Grunde etwas anders und der CUxD-Ping funktioniert. Also: mit jedem neuen Gerät ausprobieren.

Mit der Lösung auf dieser Seite wird im Sekundentakt ein Ping gesendet, und zwar ununterbrochen. Der Aufbau sieht folgendermaßen aus:

• Ein erstes WebUI-Programm startet Ping. Das Programm wird danach sofort wieder beendet; Ping läuft im Hintergrund weiter, was einige Sekunden dauern kann.
• Wenn Ping beendet wird, löst der CUx-Daemon ein zweites WebUI-Programm aus. Dieses wertet das Ergebnis aus und setzt eine Systemvariable auf anwesend oder nicht anwesend.
• Das zweite WebUI-Programm löst wiederum das erste aus, so dass es durchgehend läuft.

Ich brauche also zwei Systemvariablen. In der ersten wird das Endergebnis der Prüfung gespeichert und sie kann verwendet werden, um andere Programme auszulösen. Ich nenne sie Anwesenheit iPhone.

Die zweite heißt Anwesenheit iPhone Autotrigger und ermöglicht es dem zweiten Programm, das erste auszulösen.

WebUI-Programm 1: Ping starten

Das erste Programm wird immer dann ausgelöst, wenn Anwesenheit iPhone Autotrigger auf starten gesetzt wird. Die Auslösung erfolgt auf Aktualisierung, also bei jedem Setzen der Systemvariable unabhängig von ihrem vorherigen Wert.

Zu sehen ist hier, wie ein Befehl über den CUxD gestartet wird:

• der CUxD stellt ein „virtuelles“ Gerät zur Verfügung, das man über die WebUI ansprechen kann; wie man es einrichtet, steht hier
• über den Datenpunkt CMD_SETS wird eingestellt, welches Programm gestartet wird
• über einen kurzen Tastendruck wird der Befehl, der mit CMD_SETS gesetzt wurde, ausgelöst
• das WebUI-Programm wird danach sofort beendet, auch wenn Ping im Hintergrund mehrere Sekunden weiterläuft

Die virtuellen Geräte des CUxD bieten noch unendlich viel mehr Möglichkeiten. Für diesen Fall reichen aber schon diese zwei Funktionen.

Der Befehl, der abgesetzt wird, lautet ganz einfach ping -c 10 iphone.

Ich habe den Kanal passend umbenannt, damit ich jederzeit erkennen kann, dass er nur für diese Funktion verwendet wird.

Gerade bei länger laufenden Befehlen, deren Ergebnis auch ausgewertet werden soll, dürfen keine anderen Befehle dazwischenfunken. Wenn ich noch eine Anwesenheitserkennung für ein zweites Smartphone brauche, dann muss das über einen zweiten Kanal laufen.

Mit dem letzten Befehl setze ich nach einer Minute Anwesenheit iPhone Autotrigger wieder auf starten, falls das zweite Programm nicht innerhalb dieser Zeit ausgelöst wurde. Mindestens beim Neustart der CCU tritt dieses Phänomen auf.

WebUI-Programm 2: Auswertung

Wenn Ping beendet wird, dann setzt der CUxD für den entsprechenden Kanal den Datenpunkt CMD_RETS mit dem Exitcode des Programms. Wenn das passiert, wird das zweite WebUI-Programm ausgelöst.

Der Exitcode ist ein Zahlenwert, mit dem ein Programm beim Beenden dem aufrufenden System mitteilt, ob es erfolgreich beendet wurde oder nicht. Ping meldet Erfolg (Exitcode 0), sobald auch nur eines meiner 10 Datenpakete beantwortet wurde. Gingen alle 10 Pakete verloren, liefert es den Exitcode 1.

Bei Erfolg (CMD_RETS kleiner oder gleich 0) setzt das WebUI-Programm meine Systemvariable Anwesenheit iPhone auf anwesend, bei Misserfolg nicht. Nach einer Stunde wird die Systemvariable wieder auf nicht anwesend gesetzt.

Das Programm wird auf Aktualisierung ausgeführt und laufende Verzögerungen werden beendet. Wenn also innerhalb dieser Stunde ein Ping erfolgreich war, wird die Systemvariable erneut gesetzt und der Timeout beginnt von neuem.

Die Systemvariable Anwesenheit iPhone Autotrigger wird bei jeder Auslösung des Programms auf starten gesetzt: Egal, ob der Ping erfolgreich war oder nicht – das erste WebUI-Programm soll sofort wieder gestartet werden. Da ich im ersten Programm auf Aktualisierung ausgewählt habe, wird es auch jedes Mal gestartet.

Funktionsprüfung

Zur Funktionsprüfung kann man zum einen einfach unter Status und Bedienung / Programme nachschauen, ob die beiden WebUI-Programme regelmäßig ausgelöst werden. Zum anderen kann man auch die Protokollierung der beiden Systemvariablen aktivieren, indem man unter Einstellungen / Systemvariable die entsprechenden Haken setzt.

Unter Status und Bedienung / Systemprotokoll kann man dann verfolgen, wie die Variablen immer wieder gesetzt werden.

Das Protokoll zeigt den Ablauf nach einem Neustart.

Ursprünglich hatte ich im zweiten WebUI-Programm eine Verzögerung von 20 Minuten eingestellt: Wenn mein iPhone 20 Minuten nicht erreichbar ist, wird Anwesenheit iPhone auf nicht anwesend gesetzt. Anhand des Protokolls konnte ich feststellen, dass es sich manchmal längere Pausen gönnt, und ich habe den Wert drastisch erhöht.

Das Protokoll füllt sich sehr schnell mit Einträgen, daher sollte man die Protokollierung natürlich auch wieder deaktivieren, wenn alles läuft.