Ping-Pong mit dem Smartphone

Das Ping-Gerät des CUxD kann man verwenden, um die Anwesenheit eines Smartphones zu prüfen

9385 Zeichen
Score aktualisiert
100%
Code: 5f7a6dae16114a56b0594ae9b1210c24
Token in Entwicklung nicht aktualisiert
img-Tag in Entwicklung deaktiviert

Ich werde relativ häufig danach gefragt, ob es eine Möglichkeit gibt, dass die CCU automatisch erkennt, wenn die Bewohner zu Hause sind, indem zum Beispiel die Anwesenheit von Mobilgeräten geprüft wird. Mit Bordmitteln funktioniert das nicht – aber mit dem CUxD kann man was basteln.

Als Beispiel nehme ich mein neues iPhone, aber im Prinzip funktioniert jedes Gerät, welches die CCU im Netzwerk erreichen kann.

Probleme

Vorweg ein kleiner Dämpfer für die Begeisterung: Die Anwesenheitserkennung hat ihre Tücken.

Die Anwesenheitserkennung ist also relativ zuverlässig – wenn das Smartphone nach Hause kommt, kann die CCU sicher sein, dass es in Reichweite ist. Die Abwesenheitserkennung dagegen ist problematisch. Das sollte man stets bedenken, wenn man die automatische Erkennung für eigene Programme nutzt.

Infrastruktur vorbereiten

Die Anwesenheitserkennung funktioniert, indem die CCU regelmäßig Netzwerkpakete an das Mobilgerät sendet und auf Antwort wartet. Damit das funktioniert, müssen einige Bedingungen gegeben sein.

feste IP-Adresse oder Netzwerkname

Mein iPhone muss von der CCU unter einer definierten Adresse erreichbar sein. Das kann eine feste IP-Adresse sein oder ein eindeutiger Name. Die IP-Adresse wird vom DHCP-Server vergeben, für den Namen ist ein DNS-Server zuständig. Beides macht in einfachen Netzwerken der Internet-Router.

In der Regel muss man nur in der Weboberfläche des Routers etwas herumklicken, um einem beliebigen Gerät eine feste IP-Adresse zuzuweisen.

Antwort auf Ping

Ping ist ein kleines Programm, das ein kleines Datenpaket an einen Rechner im Netz schickt und ein kleines Datenpaket als Antwort erwartet. Kommt die Antwort, weiß Ping, dass das Gerät erreichbar ist.

Manche halten dies für ein Sicherheitsrisiko: Wenn ein Gerät auf Ping antwortet, dann weiß ein Angreifer, dass es unter dieser Adresse ein Gerät gibt. Manche Hersteller lassen ihre Geräte daher nicht auf Pings antworten. Auch die Installation einer Firewall kann Pings unterbinden.

Darum teste ich zunächst am PC, ob mein iPhone grundsätzlich erreichbar ist.

Windows-Taste + R bringt mich zum Ausführen-Fenster.

ping -t ip-adresse startet Ping für die entsprechende IP-Adresse

Erfolg sieht so aus:

Stromsparmodus

Die meisten Mobilgeräte haben mehr oder weniger aggressive Stromspar-Mechanismen, um den Akku zu schonen. Das iPhone zum Beispiel hört  nach dem Sperren des Bildschirms praktisch sofort auf, Pings zu beantworten.

Alle paar Minuten wacht es auf, macht sein Ding und schläft wieder ein. Damit kann man arbeiten, denn immer wenn es aufwacht, antwortet es auch auf Pings.

Ich habe auch noch ein schrottiges Android-Tablet. Das schläft ein und wacht erst wieder auf, wenn man es in die Hand nimmt, entsperrt und eine gefühlte Ewigkeit wartet, bis es sich wieder im WLAN eingebucht hat. Ein solches Gerät ist für eine komfortable Anwesenheitserkennung natürlich ungeeignet.

Ping-Gerät einrichten

Als erstes wird auf der Konfigurationsoberfläche des CUx-Daemons ein neues Systemgerät eingerichtet. Die Funktion ist Ping/Alive, Seriennummer kann 1 bleiben und den Namen kann man frei wählen.

Das ausgewählte Geräte-Icon bezieht sich nur auf die Darstellung in der WebUI. Egal, was man auswählt, die Funktion des virtuellen CUxD-Gerätes bleibt immer gleich.

Nachdem das Gerät auf der CCU erzeugt wurde, erscheint es dort im Posteingang. Falls nicht, hilft ein Neustart. Man kann es danach direkt im Posteingang bearbeiten, aber man kann genausogut auf Fertig klicken und dann in der Geräteliste loslegen.

In der Geräteliste öffne ich gleich den ersten Kanal und gebe ihm einen passenden Namen.

Hilfreich ist es, während der Testphase die Protokollierung einzuschalten: Das Gerät ändert seinen Schaltzustand zwischen ein und aus, je nachdem, ob das Smartphone erreichbar ist oder nicht. Genau wie bei einem echten Schaltaktor kann man das protokollieren lassen und später nachschauen, was passiert ist.

Nach den allgemeinen Kanaleinstellungen des neuen Gerätes klicke ich auf die Schaltfläche Einstellen. Nun kann ich die eigentliche Konfiguration vornehmen.

Die Bedeutung der Felder (und meiner Werte):

ACTIVE

Kanal ist aktiv: Der CUxD sendet Pings und ändert je nach Antwort den Schaltzustand des virtuellen Gerätes

IP_DNS_ADR

Das anzupingende Gerät: In meinem Fall ist das iPhone unter der Adresse iphone anzupingen. In vielen privaten WLANs werden Geräte eher über eine IP-Adresse erreichbar sein und nicht über einen DNS-Namen. Wie in meinem Beispiel ganz oben beschrieben, könnte hier also auch 192.168.178.15 stehen. Der konkrete Wert hängt von Ihrem Netz ab.

PORT

Der CUxD kann nicht nur prüfen, ob ein Gerät überhaupt reagiert, sondern auch, ob auf einem bestimmten Port ein Dienst lauscht. So kann man etwa die Erreichbarkeit eines Web- oder Mailservers testen.

Das iPhone sollte nichts zur Verfügung stellen – und für die Anwesenheitserkennung reicht es ohnehin, dass es einfach nur auf Ping antwortet. Der Wert 0 sorgt dafür, dass der CUxD nur pingt, aber keine Datenverbindung aufzubauen versucht.

INTERVAL_ALIVE

INTERVAL_FAIL

Wurde ein Ping beantwortet (ALIVE) bzw. schlug fehl (FAIL), wartet der CUxD die jeweilige Zeitspanne ab, bis er es erneut versucht.

Mein iPhone, das über lange Phasen im Stromsparmodus ist und nicht reagiert, sollte in möglichst kurzen Abständen angepingt werden. Je geringer die Frequenz, desto größer die Wahrscheinlichkeit, dass der CUxD eine aktive Phase des Smartphones erwischt. Daher wähle ich für beide Felder den Mindestwert 15.

MAX_RETRY

Schlägt ein Ping fehl, versucht es der CUxD bis zu fünf Mal erneut – also insgesamt sechs Versuche. Wenn auch nur einer erfolgreich ist, dann ist das iPhone „alive“ und das virtuelle Gerät wechselt zum Schaltzustand ein.

Je öfter der Ping versucht wird, desto größer die Chance, das iPhone in einer Wachphase anzusprechen, daher nehme ich den Maximalwert von 5 Versuchen.

THRESHOLD

Schaltschwelle: Im Screenshot habe ich 127 eingestellt. Das bedeutet, dass der CUxD 127 Versuche macht, das Gerät zu erreichen, bevor der Schaltzustand auf aus wechselt (also „nicht erreichbar“ für das iPhone gemeldet wird). Jeder Versuch besteht aus einem Ping und fünf Ping-Wiederholungen. Insgesamt schickt die CCU also 762 Pings an mein iPhone, bevor der CUxD aufgibt und Nichterreichbarkeit meldet.

CMD_EXEC_TRUE

CMD_EXEC_FALSE

Hier eingetragene Systembefehle werden beim Zustandswechsel ausgelöst. Man könnte zum Beispiel bei Nichterreichbarkeit eines PCs einen Etherwake-Befehl senden.

Für die Anwesenheitserkennung meines iPhones spielt das keine Rolle, daher bleiben die Felder leer.

Der Wert für THRESHOLD muss nach der Einrichtung des Gerätes ausprobiert werden.

Es gibt leider keine pauschale Aussage, welcher Wert der richtige ist – das hängt vom überwachten Gerät und auch von dessen Software ab. Bei meinem alten iPhone habe ich keine brauchbare Erkennung hinbekommen und darum eine alternative Anwesenheitserkennung zusammengebastelt. Das neue funktioniert dagegen trotz identischer Software und Einstellungen zuverlässig mit dem Ping-Gerät.

Ich würde mit einem relativ niedrigen Wert beginnen (z. B. 10), die Protokollierung einschalten und dann das Systemprotokoll beobachten: Wenn das Gerät nicht erkannt wird, obwohl es im Netz sein sollte, dann den Wert um 5 erhöhen und erneut testen; so lange, bis keine „false negatives“ mehr auftauchen.

Testprogramm in der WebUI

Zusammen mit dem T-Framework kann man ein kleines Testprogramm schreiben, mit dem man während der Testphase auf das Systemprotokoll verzichten kann.

Ich wähle hier einfach das virtuelle Ping-Gerät aus und lasse – je nach Erreichbarkeit – eine passende Meldung an meinen Telegram-Bot schicken.

Die erste Nachricht kommt direkt nach dem Speichern des Programms.

Auch einen zu niedrigen THRESHOLD-Wert erkenne ich am nächsten Morgen:

Wie man sieht, hat sich mein iPhone um 02:50 und um 05:14 so lange deaktiviert, dass der CUxD während der eingestellten Karenzzeit keine Antwort auf seine Pings erhalten hat und auf Schaltzustand aus gesprungen ist.

Ebenfalls gut zu sehen: Die Push-Nachricht über Telegram, die natürlich auch ans iPhone gesendet wurde, hat es gleich wieder aufgeweckt. iPhone wacht auf – iPhone bucht sich in WLAN ein, um Telegram-Nachricht herunterzuladen – iPhone ist erreichbar – Ping-Gerät springt wieder auf ein – CCU sendet weitere Push-Nachricht.

Ein gutes Argument für Stummschaltung in der Nacht.

Falls die Erkennung auf diesem Wege nicht zuverlässig einzustellen ist oder die Reaktionszeiten wegen zu hohen THRESHOLD-Werten unbrauchbar lang werden, kann man die Anwesenheitserkennung noch auf dem komplizierten Weg umsetzen.

Navigation