Das ist smartes Licht. Und was macht es? Es leuchtet smart.


10.03.2017 von

https://www.iteratec.de/fileadmin/Bilder/News/iteratec_logo.png https://www.iteratec.de/fileadmin/Bilder/News/iteratec_logo.png iteratec GmbH

Sicherlich habt Ihr schon mal von unserem Mitarbeiter-Event “iterathon” gehört, bei dem wir uns einen Tag Auszeit von unseren Projekten nehmen, um vollkommen lösgelöst von jedem Zwang an unseren eigenen Ideen zu arbeiten. Ende Februar 2017 fand dieses Event wieder statt.

Dieses mal habe ich mich (bisher war ich bei jedem iterathon dabei) mit ein paar Kollegen mit dem Smart Light System Philips Hue beschäftigt. Wir hatten dabei, wie beim iterathon üblich, eine Menge Spaß und am Ende des Tages viele neue Erkenntnisse gesammelt. Daran möchte ich Euch nun teilhaben lassen. Bevor es aber richtig losgeht, möchte ich zuerst noch ein paar Worte über den iterathon verlieren.

iterathon extends hackathon implements iteratec

Der iterathon läuft im Grunde genau wie ein klassischer hackathon ab, entspricht von der Art und Mentalität her jedoch eher unserer allgemeinen iteratec-Firmenkultur. Der iterathon, der in der Regel einen Tag dauert, wird in unseren Büros abgehalten und von Kollegen für Kollegen organisiert. Wir beschäftigen uns einzeln oder in kleinen Arbeitsgruppen mit den Themen, die uns wichtig sind und an denen wir Spaß haben.

Jede Gruppe kann daher an einem eigenen Thema arbeiten. Ein bestimmtes Ergebnis wird pro Gruppe zwar angestrebt, muss aber nicht zwingend eingehalten werden. Am Ende des Tages werden die Ergebnisse vorgetragen und konsolidiert. Eine Bewertung über Zielerreichung, “sexyness” oder Sinnhaftigkeit gibt es so direkt ebenfalls nicht. Das liegt daran, dass die Projekte und dessen Ziele sehr individuell und somit nicht unmittelbar vergleichbar sind. Viele beschäftigen sich zwar mit klassischen Ein-Tages-Projekten wie z. B. “IoT in Less than One Day”, andere nutzen aber auch die Zusammenkunft der Kollegen als KickOff für Innovation-Frei-Day-Projekte oder Ähnliches. Es geht beim iterathon also bunt gemischt zu, und das gilt nicht nur für die Themen, sondern auch für die Atmosphäre, zu der ich an dieser Stelle nichts weiter schreiben werde, sondern folgendes Video und Bilder dieses Artikels sprechen lasse.

Philips Hue ist eine Smart Light Lösung mit einfacher Architektur und funktioniert Out of the Box

Schon einige Monate vor dem iterathon lag ich einem Kollegen in den Ohren, er solle sich doch das Philips Hue StarterKit inklusive drei Glühlampen zulegen und mir dann sagen, was er davon hält. Ich war mir selbst nämlich noch nicht ganz schlüssig und wollte deshalb mit voller Dreistigkeit besagten Kollegen vorschicken. Als der sich dann kurz nach dem Kauf des StarterKits weitere Glühlampen zugelegte habe ich mir die Philips Hue Bridge und eine Philips Hue Iris angeschafft. Und somit möchte ich nun auch “in den heißen Scheiß” einsteigen.

Das zentrale Element ist die Philips Hue Bridge. Diese Box agiert als Kommunikationsbrücke und verbindet die Teilnehmer im Heimnetzwerk bzw. Internet mit den Hue-Komponenten wie Glühlampen, Sensoren und Aktoren. Ganz salopp gesagt sorgt die Bridge dafür, dass eine Smartphone App die Hue-Lampen ein- und ausschalten oder dessen Farbe und Helligkeit verändern kann. Man muss hier verstehen, dass die Hue-Komponenten mit der Bridge über ihr eigenes Funknetzwerk nach dem ZigBee Light Link Standard kommunizieren. Eine Direktverbindung vom Smartphone über Wifi zur Glühlampe funktioniert daher nicht. Das bedeutet letztlich, dass sämtliche Kommunikation über die Bridge stattfindet. Die Bridge ist also Dreh- und Angelpunkt des Systems. Doch die Hue Bridge ist nicht nur eine Kommunikationsbrücke, sondern wickelt zudem noch diverse Low-Level Mechanismen wie z. B. die Kopplung und Synchronisation der Lampen eigenständig ab. Was aber für Entwickler am interessantesten sein dürfte, ist die integrierte RESTful-Schnittstelle mit JSON, über die letztlich die Lampen angesprochen werden. Und hier beginnt die Tüftelei.

Mit Philips Hue kommt man sehr schnell zu ersten Ergebnissen

Philips stellt für sein Hue System eine meiner Meinung nach gute Dokumentation bereit. Allerdings muss man sich vorher im Developer Programm registrieren, um Zugriff auf die Dokumentation, Beispielcode und das Hue SDK zu haben. Für die ersten Gehversuche braucht man nicht viel. Folgende Vorbereitungen sollten getroffen werden:

  • Hue Bridge ist mit dem LAN per Router oder Switch verbunden
  • Lampen sind mit Strom versorgt, eingeschaltet und mit der Bridge gekoppelt (das Koppeln führt man am besten mit der Hue App im Vorfeld durch)
  • Euer Entwicklungsrechner befindet sich im gleichen Netzwerk wie die Bridge
  • Die Bridge ist von eurem Entwicklungsrechner aus über das Netzwerk erreichbar


Nun nehmt Ihr ein Tool Eurer Wahl zum Ansprechen von REST-Schnittstellen und versucht mit der API (ein Blick in die Doku hilft) erste Anfragen abzusetzen. Alternativ kann man hierfür auch das API Debug Tool der Bridge benutzen.

Wenn der Ein-oder Andere von Euch das nun ausprobiert hat, wird er sehen, dass das mit dem Lampen ein- und ausschalten ggf. doch nicht ganz so einfach ist wie gedacht. Denn zum Schutz vor Missbrauch muss jeder Client (in diesem Fall Euer Tool) zuvor einmalig ein User Token holen, das von der Bridge ausgestellt wird. Bevor die Anfrage zum Holen des Tokens abgesetzt wird, muss der physikalische Knopf auf der Oberseite des Bridge-Gehäuses gedrückt werden.

URL:    http://<bridge_api>
Call:   POST /api
Body:   {"devicetype":"hello_hue#iphone max"}

Das empfangene User Token wird einfach an die Basis URL aller weiteren REST-Calls gehängt und somit bei jeder Anfrage erneut übertragen. Dadurch habt Ihr alle benötigten Berechtigungen für den Zugriff auf die Hue-Komponenten und könnt beispielsweise mit folgender Anfrage die Farbe der Glühlampe mit dem Identifier 5 neu setzen.

URL:    http://<bridge_api>
Call:   PUT /api/<token>/lights/5/state
Body:   {“hue”:34300, “on”:true, “bri”: 254}

An dieser Stelle empfehle ich sehr, sich einen Moment Zeit zu nehmen, um entlang der Dokumentation zu lesen und die API auszutesten, um ein Gefühl für Verhalten, Funktionsweise und Performance zu bekommen.

Das Hue SDK kapselt die REST-API und unterstützt beim Parsen der Daten von/zu Objekten

Um nun Eure erste App mit einem fancy Frontend zu entwickeln, könnte man natürlich hergehen und die für euren Usecase nötigen Anfragen per REST-Framework stellen und das Ergebnis in z. B. Java-Objekte parsen. Zum Glück könnt Ihr Euch diese Arbeit sparen, denn Philips stellt hier sein eigenes Philips Hue SDK bereit. Über das Hue Developer Portal ist das Framework für Java, Objective-C und noch weitere Sprachen erhältlich.

Vorher habe ich gezeigt, wie ihr über die REST-Schnittstelle das User Token holen - und den Status einer Lampe verändern könnt. Die folgenden Code-Ausschnitte zeigen, wie man das mithilfe des Hue SDK bei einer Android App oder Java-Anwendung macht.

void findAndConnect() {
    PHHueSDK hueSDK = PHHueSDK.create();
    hueSDK.getNotificationManager().registerSDKListener(new PHSDKListener() {
        @Override
        public void onAccessPointsFound(List<PHAccessPoint> bridges) {
            // assuming that only one bridge is available on the network
            hueSDK.connect(bridges.get(0));
        }
        @Override
        public void onAuthenticationRequired(PHAccessPoint accessPoint) {
            System.out.println("press the hw-button on the bridge now");
            hueSDK.startPushlinkAuthentication(accessPoint);
        }
        @Override
        public void onBridgeConnected(PHBridge bridge, String userToken) {
            System.out.println("connected -> start playing now");
            storeConnection(bridge, userToken);
            switchAllLightsOn();
        }
    });
    System.out.println("start searching for bridge...");
    PHBridgeSearchManager searchManager = (PHBridgeSearchManager) hueSDK.getSDKService(PHHueSDK.SEARCH_BRIDGE);
    searchManager.search(true, true);
}

Mit der Methode findAndConnect() kann man eine mit dem Netzwerk verbundene Bridge automatisch suchen und, falls gefunden, verbinden. Unmittelbar nach dem Aufruf des Callbacks onAuthenticationRequired() sollte in den nächsten Sekunden der Button auf der Bridge gedrückt werden. Wenn alles klappt, erhält man am Schluss des Verbindungsaufbaus eine Referenz auf die verbundene Bridge zusammen mit dem UserToken, das für zukünftige Sessions gespeichert werden sollte. Denn wie schon erwähnt ist dieser Schritt im besten Fall nur einmal nötig.

void directConnect(String bridgeIP, String userToken) {
    PHHueSDK hueSDK = PHHueSDK.create();
    PHAccessPoint accessPoint = new PHAccessPoint();
    accessPoint.setIpAddress(bridgeIP);
    accessPoint.setUsername(userToken);
    hueSDK.connect(accessPoint);
}

Mit der Methode directConnect() kann dann bei der nächsten Session direkt eine Verbindung aufgebaut werden. In beiden Fällen können als nächstes die Glühlampen, Sensoren und Aktoren angesprochen werden. Beispielsweise schaltet die Methode switchAllLightsOn() alle gekoppelten Lampen ein, sofern sie nicht schon eingeschaltet sind.

void switchAllLightsOn() {
    PHBridge bridge = phHueSDK.getSelectedBridge();
    PHBridgeResourcesCache cache = bridge.getResourceCache();
 
    PHLightState switchedOnState = new PHLightState();
    switchedOnState.setOn(true);
 
    // can also be written as lambda expression
    for (PHLight light : cache.getAllLights()) {
        if (light.getLastKnownLightState().isReachable()) {
            bridge.updateLightState(light, switchedOnState);
        }
    }
}

Mit Philips Hue lassen sich viele Ideen realisieren. Vieles davon gibt es aber (leider) schon

Wir sind zum Ergebnis gekommen, dass man mit den bereitgestellten Werkzeugen durchaus eigene Ideen umsetzen kann, ohne dafür gleich mehrere Wochen Zeit zu investieren. Während des iterathons habe ich beispielsweise eine kleine iOS App geschrieben, mit der man die Helligkeit und Farbe einer ausgewählten Glühlampe über Kippen und Neigen des Smartphones einstellen kann. Ein Kollege aus meinem Team hat währenddessen eine Java-Anwendung geschrieben, die Tastatureingaben auf dem Laptop registriert und die Lampen entsprechend einfärbt.

Im Laufe des Tages kamen wir auf viele weitere Ideen, wie beispielweise ein Jenkins Plugin, eine Musik-Visualisierung über die Lampen oder eine App, die alle Lampen ausschaltet, sobald das Handy die Verbindung zum heimischen Wi-Fi verliert. Das alles gibt es jedoch schon in Form von zahlreichen Apps, Browser Plugins, und Online-Diensten. Besonders ins Auge ist uns der Service "If This Then That" gesprungen, bei dem man nun auch Philips Hue anbinden kann. Dadurch lässt sich z. B. die Lampe entsprechend einfärben, wenn eine neue E-Mail im Posteingang liegt.

Ein langer Tag ging zu Ende und wir waren meistens, aber nicht immer ganz glücklich

Obwohl Philips Hue in vieler Hinsicht punkten kann, waren wir doch hier und da nicht so ganz zufrieden. Zum einen scheint das Thema Sicherheit nicht allzu groß geschrieben zu werden. Das User Token ist unseres Wissens unbeschränkt gültig und wird in der URL im Klartext übertragen. Die Glühlampen verlieren, sobald man diese vom Strom nimmt, ihren aktuellen Status (Helligkeit, Farbe) und leuchten bei der nächsten Stromversorgung in der Standardeinstellung. Offenbar ist das aber explizit von Philips aus Sicherheitsgründen so gefordert. Des Weiteren haben wir keinen nativen Push-Mechanismus gefunden, über den die Bridge einen verbundenen Client über Statusänderungen benachrichtigen würde. Das bedeutet, dass z. B. Apps durch zyklisches Pollen immer wieder an der Bridge aktiv anfragen müssen, um den aktuellen Status der gekoppelten Hue-Komponenten zu bekommen. 

Fazit: Uns hat das Entwickeln für Philips Hue insgesamt sehr gut gefallen und wir werden das Thema bei uns auf jeden Fall weiter verfolgen. Für Entwickler bietet Philips ein einfach zu verstehendes SDK mit viel Beispielcode für den Einstieg. Eigene Anwendungsfälle, die speziell für den Eigenbedarf umgesetzt werden, sind schnell prototypisch umsetzbar. Für technisch interessierte Nicht-Informatiker gibt es zahlreiche Apps für das Smartphone, die man einfach mal runterladen und ausprobieren kann.

studitherathon: Die iterathon Variante für Studenten

Nun habt Ihr also gesehen, wie und an welchen Themen wir beim iterathon arbeiten und ich hoffe, euch hat das Thema genauso gut gefallen wie uns. Zum Schluss möchte ich noch ein bisschen Werbung für die für Studierende abgewandelte Form des iterathons machen, den sogenannten studitherathon.

Der studitherathon findet einmal im Jahr statt und wird vor allem an den technischen Universitäten im Raum München zuvor angekündigt. Die Zielgruppe richtet sich insbesondere an Softwareentwickler, da unsere studitheratons in der Regel eher technische Themen behandeln. Jeder Student kann sich anmelden und mitmachen. Vorletztes Jahr haben wir z. B. eine digitale Schnitzeljagd mit Beacons, einer Android App mit Backend-Anbindung erfolgreich realisiert. Alle Beacons, die in den Büros am Ende der Veranstaltung versteckt waren, wurden über die entwickelte App aufgespürt.

Die Teilnehmerzahl des studitherathons ist leider auf circa 20 Teilnehmer beschränkt. Bei Interesse könnt ihr euch an uns wenden unter iterathon@Do not spamiteratec.de. Wir melden uns, wenn der nächste iterathon für Studierende stattfindet. Gerne könnt ihr auch Themenwünsche einbringen. Außerdem bieten wir Coding Dojos an.