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.
- Wenn das Mobilgerät nicht im Netz ist, dann schaltet die CCU auf „abwesend“.
Das kann durchaus auch passieren, wenn das Telefon mit leerem Akku im Haus liegt oder aus
Energiespargründen das Netzwerk deaktiviert.
- Umgekehrt bedeutet ein zu Hause vergessenes Smartphone natürlich, dass die CCU meint,
jemand wäre zu Hause. Man sollte sich daher sehr genau überlegen, welche Ereignisse man
von der automatischen Erkennung abhängig macht.
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.
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:
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):
Kanal ist aktiv: Der CUxD sendet Pings und ändert je nach Antwort den Schaltzustand
des virtuellen Gerätes
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.
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.
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.
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.
- Ist er zu niedrig, so erkennt das virtuelle Gerät zu schnell die Abwesenheit des
Smartphones und wechselt in den Zustand aus – und kurz danach wieder ein,
wenn das Gerät wieder erreichbar ist.
- Ist er zu hoch, dauert es sehr lange, bis der CUxD Abwesenheit erkennt und zu aus
wechselt.
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.