Raketenschnecke.net IPS-Android-Steuerung Uebersicht
Stand: 27.06.2012
Was hab ich mich gequält, um die Dinger stabil an IPS anzubinden. Mal gehen sie nicht aus, mal gehen sie nicht an, mal sind sie nicht erreichbar – und stürzen ab. Inziwischen habe ich aber eine sehr stabile Lösung gefunden, die ich vom Konzept her hier vorstellen will.
Seit Mitte letzten Jahres habe ich eine umfangreiche Android Tablett-Zucht. Inzwischen ist die Population auf 8 Devices angewachsen:
- 2x Asus TF101 (10“)
- 1x Acer Iconia A 500 (10“)
- 4x Acer Iconia A100 (7”)
- 2x Lenovo A1 (7”)
Im Folgenden beschreibe ich eine softwarebasierende Lösung, die eine bidirektionale Kommunikation zwischen Android-Devices und IP-Symcon ermöglicht. Diese Lösung ist aktuell (noch) keine Plug-and-Play Lösung und hat eher „Proof of Concept„-Charakter.
Wer also Ähnliches vor hat, kommt hiermit sicher sehr viel weiter und muss nicht die gleichen Erfahrungen durchleben, aber es ist ein doch enormer Aufwand, eine solche Lösung zu implementieren.
Noch ein Wort zu den Android-Tabs: alle Tabs dienen zur Visualisierung meiner Home-Automation, sowohl zu Informationszwecken als auch zur bidirektionalen Kommunikation zwischen Anwender und System (IP-Symcon)
Ein Teil der Geräte ist an die Wand getackert, ein Teil steht auf Tab-Gestellen (Dockingstations), ein Tab (Iconia A100) dient als Info- und Fernbedienungszentrale im Wohnzimmer.
Primäres Ziel
die Androiden bzw. die IPS-Visualisierung benötige ich eigentlich nur bei Anwesenheit (Anwesenheit im Sinne von Wohnung/Zimmer). In einigen Räumen bin ich 2h pro Tag anwesend, in einigen 10h. Daher müssen die Androiden nicht 7*24h „On“ sein. Daher muss eine Lösung her, die die Displays (nicht das ganze Tablett) abschaltet bzw. bei Anwesenheit wieder einschaltet. Eine Tasker-Zeitsteuerung hatte ich vorher, ist aber unbefriedigend. Also kommt nur eine Steuerung via Hausautomation/IP-Symcon in Frage.
Anbei einige erläuternde Videos:
| Übersicht der Steuerung: im Vordergrund ein Webfrontend im PC-Browser mit der Systemüberwachung der Tablets, im Hintergrund exemplarisch 3 Tablets: 2x für Webcam, 1x für IPS-Visualisierung | |
| im Detail die Steuerung im Android-Tablet: EG nimmt die IPS-Befehle auf und gibt diese an Tasker weiter. Tasker kümmert sich dann um die Steuerung der Hardware | |
| das IPS-Webfront mit der Android-Systemüberwachung. Man sieht recht deutlich, das längst nicht jeder Steuerbefehl beim Device ankommt und der Error-Handler eingreifen muss. Diese Visualisierung ist nicht betriebsnotwendig un dient mir in erster Linie als Unterstützung in der Entwicklungsphase. Letzendlich sollen die Tablets möglichst unauffällig und ohne manuelle Eingriffe vom System gesteuert werden |
Doch nun zur Anbindung:
Primäres Ziel war es, die Geräte nicht 7*24h im Dauerbetrieb zu halten, sondern anwesenheitsgesteuert ein- und auszuschalten. Gleichzeitig soll das Konzept offen für evtl. Erweiterungen sein (ich könnte mir z.B. Fernsteuerung der Tablet-Cams vorstellen)
Nach dem Einschalten soll ohne Eingriff des Users die Visualisierungs-Oberfläche (Webfront von IP-Symcon) geladen werden. Für jedes Android-Tab wurde ein eigenes Webfront (ff „WFE“) designet.
Neben einer Steuerlogik in IP-Symcon (der Homeautomations-Software) war eine Software notwendig, die auf dem Androiden die IPS-Steuerbefehle annimmt und in Aktionen auf dem Android-Device umsetzt.
Das Ganze soll bidirektional funktionieren, d.h. die Befehle sollen vom Device quittiert werden, so dass IP-Symcon eine gesicherte Info über den aktuellen Zustand des Devices hat. Nur so lässt sich ein dauerhaft fehlerfreier Betrieb sicher stellen. Ebenso wäre es so möglich, dass von den Devices Meldungen eigenständig an IPS versandt und ausgewertet werden können.
Auf dem Android-Device
wird dies über 2 Software-Pakete realisiert:
- EventGhost (for Android, Freeware) übernimmt die Kommunikation von und zu IP-Symcon
- Tasker (kostenpflichtig) übernimmt die eigentlichen Steuerungsaufgaben auf dem Androiden
Die Herausforderung
Eine einfache Kommunikation (Befehl an Device absetzen – fertig) hat sich als extrem unzuverlässig entpuppt: insbesondere die beiden Lenovos sind doch sehr zickig, ca., jeder 2.-3. Befehl kommt einfach nicht an. 
Bei den Acer und Asus-Geräten ist die Quote wesentlich besser, aber auch nicht akzeptabel. Also habe ich mir eine bidirektionale Kommunikationslogik ausgedacht, die solche Fehler korrigieren kann. In den beiden Bildern sieht man 2 exakt synchron angesteuerte Androiden: das Erste ist ein Acer A100 , das Zweite ein Lenovo A1 . Die Graphen zeigen das Eingreifen des Error-Handler bei nicht quittierten IP-Symcon-Befehlen an. Es dürfte sofort auffallen, dass das Lenovo sehr viel zickiger reagiert als das Acer A100.
Befehlsstruktur:
Vorab zum besseren Verständnis die Befehlsstruktur (das Schema ist von mir entwickelt und keinen Einschränkungen unterworfen, theoretisch kann man hier jeden Freitext nutzen).
Die Befehle zum Steuern eines Devices setzen sich wie folgt zusammen:
- „R2D2“ => Servername des IPS-Servers
- „A110“ => Device-Name (frei in IPS vergeben) des Androiden
- „Display“ => sprechender Befehlsname für die auszulösende EventGhost/Tasker-Aktion
- „On“ => Schaltzustand für die betreffende EventGhost/Tasker-Aktion
Beispiel Display-Einschaltbefehl an Android-Device: „R2D2.A110.Dislpay.On“
Befehle werden vom Androiden quittiert, in dem an den empfangenen Befehl ein „.Ok“ angehängt wird (Beispiel: ,„R2D2.A110.Dislpay.On.Ok“), dieser Befehl wird an IPS zurück geschickt
Die Befehlserkennung ist in EG case-sensitive!
Das Kommunikationsschema
sieht wie folgt aus (siehe dazu Bild „Kommunikationsschema“):
- Im Script „Device-Stammdaten“ befinden sich alle Informationen pro Android-Device: Client-Socket, Device-Name, devicespezifische Variablen usw. Dieses Script ist in alle beteiligten Scripte per „include“ eingebunden und liefert die Device-Daten
- Wird ein Steuerbefehl ausgelöst (derzeit „Display.Off“ und „Display.On“), so wird dieser Befehl via Script an den „Android-Connector“ (Punkt 3) geschickt. Gleichzeitig wird dieser Befehl in die Status-Variable des Devices geschrieben. Somit weiß IPS bzw. der Error-Handler (Script Punkt 11), dass a) ein Befehl abgesetzt wurde und b) welcher Befehl. Der Error-Handler legt sich nun via Timer auf die Lauer und wartet auf die positive Rückmeldung vom Androiden.
- Das Script „ Android-Connector“ nimmt diesen Befehl entgegen, und macht daraus einen Befehlsstring, den EventGhost auf dem Device verstehen kann. Gleichzeitig kümmert sich das Script um das Einschalten des gerätespezifischen ClientSockets
- Der Clientsocket kümmert sich unter zu Hilfename des „Handshake-Scripts“ um das Initialisieren des Handshake-Verfahrens zum Aufbau der Kommunikation mit EventGhost (ff „EG“)
- Ist das Handshake-Verfahren erfolgreich verlaufen, wird der EG-Befehlsstring (z.B. „Display.On“ via WLAN an das Device verschickt.
- Bei EG auf dem Android kommt dieser Befehlsstring als Event an. Kennt EventGhost dieses Event, werden damit verknüpfte Aktionen ausgelöst (in diesem Falle das Event „Display.On“, löst den Task „Display On in Tasker aus. Tasker wickelt dann die entsprechenden Befehle ab. Das alles muss natürlich auf dem Device konfiguriert werden, optimaler Weise vorher. Aber darauf komme ich in einem anderen Artikel zurück, vielleicht J
- Hat EG einen Befehl als solchen erkannt, sendet es umgehend diesen Befehl – ergänzt um ein an den Befehl angehängtes „Ok“ (Beispiel: Eingangsbefehl „R2D2.A110.Display.Off“, Quittierung: „R2D2.A110.Display.Off.OK“) an den IPS-Server zurück geschickt
- Der IPS Server-Socket wird per Keyword – welches EG zur Initialisierung selbstständig verschickt- geweckt. Anschließend erfolgt ein Handshake zur Authentifizierung der Kommunikation. Dies wird vom „Auswertescript SS“, Punkt 9 übernommen.
- Das „Auswertescript SS“ übernimmt nicht nur das Handshake, sondern wertet auch den empfangenen Befehl aus, von welchem die Präfixe „R2D2“ und „A110“ aus dem String entfernt und der verbleibenden String in die zum Device gehörende Statusvariable (siehe Punkt 10)geschrieben wird. Damit wird auch gleichzeitig der bisher gespeicherte Sendebefehl „Display.Off“ überschrieben.
- Die Status-variable nimmt erfreut die positive Rückmeldung – die das „Auswertescript SS“ soeben geschickt hat – entgegen.
- Durch die Variablen-Änderung (Rückmeldung vom Android wurde ja eben reingeschrieben) wird der Error-Handler erneut geweckt und schaut nach, was drin steht. Ist am Ende ein „Ok“ im String enthalten, legt er sich endgültig schlafen, setzt aber zuvor den Error-Counter (12) auf „0“. Habe fertich!
So der erfolgreiche Kommunikationsablauf. Erfolgt keine positive Rückmeldung durch das Android-Device, merkt das der bis dahin schlafende(-Punkt 2) Error-Handler und versucht, den Befehl (der ja in der Status-Variable steht) erneut zu versenden. Nach jedem Versand durch den Error-Handler wird der Error-Counter (12) um einen Zähler hoch gesetzt, anschließend legt sich der E-H erneut schlafen. Bisher haben sich 8 sec. Als Schlafzeit und max. 7 Punkte in der Error-Count-Skala als optimal herausgestellt.
So, nachdem ich nun (hoffentlich) das Konzept verstanden habe, kann es an die Implementierung gehen:
IPS-Implementierung
Pro Device wird ein ClientSocket angelegt, darunter eine Register Variable (diese wird in den Eigenschaften mit dem gerade angelegten CS verknüpft, als Zielscript wird das Handshake-Script eingetragen), darunter das Handshake-Script- Es wird 1 ServerSocket (egal, wie viele Androiden angebunden werden sollen) angelegt, darunter eine Register Variable (diese wird in den Eigenschaften mit dem gerade angelegten SS verknüpft, als Zielscript wird das Auswertescript SS eingetragen)
- Alle anderen Objekte gemäß Bild x-y anlegen
