openHAB: Home-Automation mit Java

Stefan Tilkov: Herzlich Willkommen, zu einer neuen Episode unseres Podcasts. Heute zum Thema Heimautomatisierung (Home automation) mit Java und OSGI und dem schicken Produkt OpenHAB. Dazu haben wir zwei Gäste — Kai, vielleicht fängst Du an und stellst Dich kurz vor.

Kai Kreuzer: Ja, wie du schon sagtest, mein Name ist Kai, Kai Kreuzer. Ich bin Java-/ OSGi-Entwickler und Softwarearchitekt. Das schon seit geraumer Zeit, über 10 Jahren. Ich bin im Raum Frankfurt zu Hause und arbeite derzeit bei der Deutschen Telekom.

Stefan Tilkov: Und wir haben noch einen zweiten Gast, Thomas Eichstädt-Engelen. Thomas, sag auch was zu dir!

Thomas Eichstädt-Engelen: Ja, meinen Namen hast du gerade gesagt. Mein Name ist Thomas Eichstädt-Engelen. Ich bin auch im Bereich Java und OSGi unterwegs und ich arbeite für die Firma innoQ, die bekannt sein sollte. Und im Moment bin ich im Projekt bei der Deutschen Telekom.

Stefan Tilkov: Ok, über das Projekt reden wir nicht so wahnsinnig viel, aber wir können über ein OpenSource-Projekt sprechen, in dem ihr beide zusammen arbeitet. Das ist das Thema unseres heutigen Podcast, nämlich openHAB. Wer von euch beiden will denn einfach kurz mal starten und uns erklären, was um Himmels Willen das denn ist.

Kai Kreuzer: Hehe, ich habs gegründet, insofern fang ich gern damit an. Was zum Teufel das ist - letztendlich ist es erstmal ein Stückchen Software, was ich für mich geschrieben hab, weil ich was brauchte, um bei mir zu Hause ein bisschen was zu regeln und zu steuern. Ich dachte mir dann, das brauchen vielleicht noch andere Leute und hab deswegen ein OpenSource-Projekt draus gemacht. Der Name openHAB steht für open Home Automation Bus. Damit sieht man auch schon um was für Art Software es geht, nämlich um Heimautomatisierung.

Stefan Tilkov: Ok, was genau versteht man unter Heimautomatisierung. Messen, steuern, regeln - was misst, steuert, regelt man da typischerweise?

Kai Kreuzer: Das fängt an von klassischen Dingen, wie erstmal Lichter, Rollläden, Heizungen zu Multimediatechnik. D.h., irgendwo Radios steuern, Multi-Room, Lautsprecher, Lautstärkeregelung, solche Dinge und geht dann auch schnell in ganz andere Dinge über: alles, was heutzutage IP-vernetzt möglich ist. Da gibts die tollsten Geräte, wie irgendwo Pflanzensensoren, die messen ob die Pflanze gegossen werden will, usw. Also da ist eigentlich der Phantasie keine Grenze gesetzt.

Stefan Tilkov: Thomas, was hast du mit dem Ganzen zu tun, wie bist du dazu gekommen?

Thomas Eichstädt-Engelen: Ich habe auch ein Haus oder eine Wohnung zu automatisieren und habe mich dann vor einiger Zeit, ungefähr im Jahre 2010, nach einer Software auf die Suche gemacht, die das kann und zwar nach einer OpenSource-Software. Es gibt da einige kommerzielle Produkte, die allerdings, ja dem Stand der Technik von vor 10 Jahren etwa entsprechen. Insofern war einfach der Wille da etwas anderes oder etwas neueres zu finden und da bin ich dann nach kurzer Suche auf openHAB aufmerksam geworden. Da hatte der Kai so seit zwei, drei Monaten das Projekt online, die Version 0.1 und ja, so bin ich dann Stück für Stück eingestiegen, habe erste Funktionserweiterungen geschrieben und bin so immer mehr in das Projekt halt eben reingerutscht.

Stefan Tilkov: Mhm ok, jetzt - da haben wir ja vorher schon mal drüber gesprochen - gibt es einen anderen Podcast zu dem Thema, zum Thema openHAB ganz allgemein. Sozusagen zur Außensicht des Ganzen. Es wird auch ein bisschen über die Interna gesprochen, aber vor allem wird erklärt, was das Projekt so leistet. Wir wollten uns jetzt nicht eine zu große Überschneidung zu dem anderen Podcast haben und haben uns deswegen vorgenommen uns heute ein bisschen auf die Interna zu fokussieren. Vielleicht könnt ihr uns einen kurzen Überblick darüber geben, wie openHAB intern aussieht, woraus es besteht, aus welchen technischen Elementen, was für eine Architektur das ganze hat und wie unterschiedliche Anforderungen darin umgesetzt wurden.

Kai Kreuzer: Ja da hole ich vielleicht sogar noch ein Stückchen weiter aus, nämlich dahingehend, was mich überhaupt dazu getrieben hat, diese Architektur zu wählen. Denn bevor ich mit der Software angefangen habe, hatte ich eigentlich schon ein Stück Software genutzt, auch ein OpenSource- Projekt namens MisterHouse, welches eigentlich all das getan hat, was ich machen wollte. War wunderbar funktional, alles mögliche drin. Wahnsinnige Funktionsabdeckung, aber das Ding war irgendwie 10 Jahre alt, in Perl geschrieben, ein riesen Verhau von Code und ich habe gesagt: ok für den Use-Case meines Zuhauses, was über Jahrzehnte eigentlich dann betrieben werden soll, gepflegt werden soll, war das für mich nicht wartbar. Insofern kam ich da eigentlich her aus der Perspektive eines Entwicklers, der ein OpenSource-System vorfinden und gesagt hat: ok, es ist zwar schön, es kann viel, aber für mich als Entwickler, um dort zu contributen, um Teile weiter zu entwickeln, war das keine akzeptable Lösung. Insofern bin ich wirklich hergegangen und hab gesagt: ok, jetzt versuche ich mal das gleiche nochmal zu machen, reinventing the wheel. Nur mit einer schönen architektur. Und da ich im beruflichen Umfeld mit Eclipse RCP, Java, OSGi viel zu tun hatte, habe ich dann natürlich naheliegenderweise gesagt: ok, nutze ich das Wissen, was ich da habe und versuche darauf basierend jetzt diese software zu entwicklen. D.h., die Kernsoftware, die wir die openHAB-Runtime nennen, ist ein headless OSGi, ein Stück. D.h., alles modular aus OSGi-Bundles aufgebaut und durch diesen modularen Aufbau leicht erweiterbar bzw. auch flexibel ausstattbar. Weil jeder User unterschiedliche Features vielleicht haben will und er kann sich letztendlich dann eigene Sachen hinzubauen, hinzulinken und auf seiner Runtime betreiben. Das war so die Kernfunktionalität erstmal, der Kernaufbau.

Stefan Tilkov: Das heißt im Prinzip ist jedes Gerät, das ihr automatisiert, jede spezifische Schnittstelle, die ihr bedienen müsst, ist ein eigenes OSGi-Bundle. Ist das richtig?

Kai Kreuzer: Ja, ganz genau. Die heißen bei uns Bindings und ein Binding ist im Moment wirklich gleich zu setzen mit einem OSGi Bundle und das setzt die Konnectivität zu einem speziellen Protokoll, einem Hardware-System, wie auch immer um. Ein wesentlicher Aspekt für die Architektur war auch zu sagen: “Ok, alles was man machen will, soll erstmal ganz losgelöst von der Hardware betrachtet werden können.” D.h. ich will irgendwo ein User-Interface haben und ich möchte mir Regeln anlegen und all das reicht auf einer rein virtuellen Ebene sag ich mal. D.h. ich kann mir meine Interfaces designen, ich sag da will ich jetzt das und das steuern, diese Funktionalität haben, ohne zu sagen, das muss jetzt aber physikalische genau dieses Gerät unter dieser Adresse usw. sein. Und die Bindings sind dann eben das Stückchen was am unteren Level der Architektur herkommt und die physikalische Anbindung dann herstellt, aber auch beliebig austauschbar ist. D.h., in einem Moment, wenn mir ein Gerät kaputt geht, ich das vielleicht durch ein anderes ersetze, mit nem anderen Protokoll, brauche ich nichts an meinen ganzen UIs, an meinen Regeln und sonstigen ändern, sondern kann einfach nur dieses stückchen Binding austauschen.

Stefan Tilkov: D.h. also im Prinzip sind OSGi Bundles oder sind die OSGi Mechanismen euer primärer Abstraktionsmechanismus bei dem ganzen. Das ist das, was ihr sozusagen als Hauptstrukturierungsmittel benutzt und alles rankt sich darum.

Kai Kreuzer: Genau. Also ich würde nicht sagen, für die funktionale Seite, sondern für die Modularität. Da ist OSGi wirklich ein ganz zentrales Element.

Stefan Tilkov: Und wie sind eure Erfahrungen da. War das eine positive Sache? Weil ich hab so gemischte Erfahrungen. Thomas weiß das auch, wir haben sie zum Teil gemeinsam. Ist das ausgeräumt, ist das ganze so ausgereift, dass ihr die Entscheidung nochmal so treffen würdet oder kämpft ihr auch gelegentlich mal gegen OSGi?

Thomas Eichstädt-Engelen: Also da wir im Moment, da das auf der Binding- Seite also ein Binding gleich ein Bundle ist, ist das im Moment noch recht gut händelbar. Wir hatten jetzt allerdings auch schon die ersten Anforderungen, da ging es irgendwie um die serielle Schnittstelle, die jetzt auch von - ja also wir wollten sozusagen eine weitere Schicht einbauen, die eben die Transportschicht ist und wir hatten eben unterschiedliche Bindings, die allesamt eben auf die serielle Schnittstelle zugreifen wollten und so haben wir dann eben gesagt, es macht keinen Sinn, dass eben jedes dieser Binding jetzt eben selbst seine eigene serielle Schnittstelle eben mitliefert. Also die entsprechenden Libraries dazu. Insofern wollen wir das zentralisieren. Und an der Stelle ging es dann schon wieder los, da bekamen wir eben Classloader-Probleme. Wenn ich das richtig im Kopf habe, die einfach der Dynamik geschuldet waren und den unterschiedlichen Classloadern, die eben auf der einen Seite Segen und auf der anderen Seite eben Fluch zugleich sind. Aber eben für die Idee, die dahintersteckt, dass man sagt: wir haben ein Core-System, das ist eben komplett unabhängig von der Hardware. Und wir haben eben auf der anderen Seite diese Bindings, die sozusagen jeder sich selbst nach seiner aktuellen Konstellation zu Hause zusammenstellen kann, ist das ein perfektes Medium. Also ich kann mir die Hardware-Binding in einen bestimmten Ordner herunterladen und dort werden die automatisch nachgeladen, zur Laufzeit des Systems. Es können eben auch Bindings ausgetauscht werden, also Versionsnummern ausgetauscht werden. Alles darauf ausgelegt, dass eben das Core-System weiterlaufen kann und wirklich nur kleine Stücke des Systems eben punktuell wirklich zur Laufzeit ausgetauscht werden können. Und dafür ist OSGi eben gemacht und das tut es auch sehr gut.

Stefan Tilkov: Was bedeutet das jetzt für mich als Entwickler? Also nehem wir an, ich würde das jetzt gerne einsetzen, ich möchte zu Hause - ich weiß auch nicht, was möchte ich denn gern? - ich möchte gerne meine schicken neuen Sonos-Geräte möchte ich irgendwie gerne fernsteuern. Hat dann irgendjemand zufällig schon so ein Binding geschrieben, dann kann ich mir das einfach runterladen und in den entsprechenden Folder werfen und alles ist gut. Was mache ich, wenn ich das noch nicht habe und jetzt selber das entwickeln möchte. Wie ist da meine Werkzeugkette aus und wie groß ist die Hürde für mich um so ein Binding zu entwickeln?

Kai Kreuzer: Also der erste Schritt ist da generell erstmal am besten auf der Diskussionsliste zu fragen, ob vielleicht schon jemand anderes dabei ist. Auch wenn es noch nicht existiert ist durchaus eine Wahrscheinlichkeit da, dass jemand anderer schon dran arbeitet. Um dann die doppelte Arbeit zu vermeiden erstmal da synchronisieren. Wir versuchen das dann entsprechend auch zu vermitteln und wenn sich mehrere Leute finden, die irgendwie an was gemeinsam arbeiten wollen, wird das dann auch entsprechend koordiniert. Aber letztendlich wenn du dann sagst, ok du willst das machen, baust du dir deine IDE erstmal auf. Das ist ein vorgefertigtes Yoxos-Profil bei uns. D.h., eine Eclipse-IDE wird dann per Knopfdruck aufgesetzt mit allen Bundles und Plug-Ins für Eclipse, die du brauchst. Du importierst dir das Repository als deinen eigenen Clone. Wir benutzen Distributed Versioning System Mercurial. D.h., du hast dann lokal den Code erstmal bei dir als deinen eigenen Clone und dann hast du deinen Workspace da, du kannst alles aus der IDE schon raus anstarten, das ganze System. Und kannst dann hergehen und baust dein eigenes Bundle. Dazu ist der erste Schritt dann erstmal, dass du im Prinzip das Skeleton aufbaust, üblicherweise im Moment per Copy und Paste von einem anderen existierenden Binding, das ist das einfachste. Und dann hast du die Möglichkeit erstmal zu entscheiden: will dein Binding sozusagen nur rauskommunizieren, also Befehle, die jetzt bei openHAB abgesetzt werden über ein User-Interface z.B., das nach draußen geht um da was zu schalten oder hast du auch aktives Feedback von externen Geräten, z.B. dass du Statusupdates melden willst und darauf dann z.B. Regelen abfeuerst oder sowas. Und für diese beiden Richtungen gibt es dann entsprechend definierte Interfaces in openHAB, die du entsprechend dann implementierst und mit einem Publish-Subscribe-Mechanismus, der technisch auf dem Event-Admin-Service von OSGi basiert, letztendlich dann nur ganz einfache Events abfeuerst bzw. empfängst und darauf reagierst. Diese Events sagen üblicherweise nur für dieses eine Feature - bei uns Item genannt - wie z.B. ein Schalter, schickst du jetzt ein Kommando On/Off oder sagst, der Dimm-Wert von irgendwas ist jetzt bei 40% und solche Dinge. Also im Prinzip relativ einfach mit einfachen Interfaces und schnellem Erfolg dahinter.

Stefan Tilkov: Hmhm, wenn ich jetzt mal annehme, dass das System, mit dem ich da spreche eine relativ einfache Schnittstelle hat, vielleicht praktischerweise für mich sogar ein kleines Java-API, das ich dann nutzen kann. Mit was für einem Aufwand muss ich da rechnen, was würdet ihr kalkulieren für jemanden der sagen wir mit der IDE umgehen kann, vielleicht sogar besser als ich und weiß, was sich hinter OSGi grundsätzlich verbirgt. Wie viel Aufwand hat der dann um sowas zu erstellen?

Thomas Eichstädt-Engelen: Also es kommt ganz auf die Komplexität des Protokolls an. Oder bzw. auch auf den Umfang der Funktion. Also z.B. das MPD, also dieses Music-Player-Deamon-Binding, da lag eine entsprechende Java-Bibliothek vor. Und trotzdem waren eben noch einige Funktionalität drum herum zu entwickeln. Also es ist z.B. möglich, dass verschiedenste Player in unterschiedlichen Räumen anzusprechen sind und das muss man sich in einer entsprechenden Registratur aufbauen und halten. Also das ist von dort aus etwas komplizierter. Wenn man aber jetzt sagen würde, ich möchte einen einfachen Anschluss - was hatten wir denn als einfaches Binding? - irgendwas möchte ich in Richtung einer HTTP-Schnittstelle vielleicht anbinden, dort ist schon sehr viel vorgefertigt, da würde ich sagen ist man mit joa, zwei Tagen? Ist das jetzt vollkommen daneben, Kai? Was sagst du?

Kai Kreuzer: Hängt ein bisschen davon ab, aber wenn es wirklich was ganz einfaches ist, hast du das in wenigen Stunden eigentlich aufgesetzt und am laufen.

Thomas Eichstädt-Engelen: Ja.

Stefan Tilkov: Ok. Da ist wahrscheinlich die Frage ob ich das schon mal gemacht habe oder nicht, ne?

Thomas Eichstädt-Engelen: Ja.

Stefan Tilkov: Wenn ich schon mal so Module gebaut habe, ist das zweite sicherlich deutlich einfacher, als wenn ich erstmal kapieren muss, wie der ganze Mechanismus funktioniert. Ok, wie sieht denn eure Community aus? Also das ganze ist Opensource, ich weiß nicht ob wir das schon gesagt haben. D.h. erstmal, ich könnte theoretisch auch erstmal an der Plattform selber mitarbeiten, aber ich vermute mal, dass der größte Teil der Community- Aktivitäten sich rund um Bindings abspielt. Ist das so?

Kai Kreuzer: Das ist auf jeden Fall so, ja. Also wir sind für alle Arten von Contributions offen. Es fängt an irgendwo bei Bug-Reports, mit dann schon vorgefertigten Patches. D.h., da kommen auch Contributions in den Core rein. Aber die meiste Aktivität ist definitiv, dass Leute sagen: “Hey, schönes Projekt.”, nutzen das und haben dann wirklich ein System, was noch nicht unterstützt wird und insofern dann an den Bindings sich da dran machen und was neues vorfertigen. Wir werden da auch oft überrascht, dass irgendwelche Leute plötzlich kommen und sagen: “Hey, hier ist ein fertiges, guckt mal da, hier habt ihr es, könnt ihr mit aufnehmen.” Und ja man vorher von den Leuten auch gar nichts mitbekommen hat, irgendwie auf der Diskussionsliste und sie in sofern keine Fragen hatten, was eigentlich ein gutes Zeichen ist, dass die Leute das hinkriegen ohne viel Support zu benötigen. Insgesamt haben wir offizielle Commiter über 20 mittlerweile, d.h. Leute, die wirklich dann Zugang haben - auch zum Wiki - selbst Dokumentationen zu schreiben, von denen wir Code übernommen haben und davon ist, ich würde mal sagen, um die 70–80% dreht sich um Bindings, bei diesen Contributions.

Stefan Tilkov: Könnt ihr vielleicht doch noch mal so ein paar Beispiele nennen für Bindings, die ihr habt? Einfach, wir haben zwar bewusst ein bisschen ausgeklammert die Funktionalität, aber jetzt ist die Frage ja relativ naheliegend. Was wären denn so Beispiel-Bindings?

Thomas Eichstädt-Engelen: Also wir haben inzwischen eine ganze große Latte erreicht. Also eins der wichtigsten Bindings was entstanden ist, ist halt das KNX-Binding. KNX ist halt ein Gebäudeautomatisierungsbus, ein standardisierter Bus, der halt häufig eingesetzt wird. Im professionellen Bereich auf jeden Fall. Aber genauso gibt es eben auch ein Sonos-Binding, um eben die Sonos-Player anzusprechen, ein FritzBox-Binding, um bei Anrufen bestimmte Aktionen auszuführen, Asterisk-Telefonanlage, Musik-Player-Daemon. Generelles TCP /UDP-Binding - also wenn man wirklich jetzt etwas ansprechen möchte, was wirklich reines TCP benötigt, also kein weitere Aufsätze - hätten wir anzubieten. Exec-Binding, wo man bestimmte Befehle auf der Kommandozeile direkt ausführen kann, wo man also Third-Party-Tools dann eben mit benutzen möchte. PlugWise, das sind Funksteckdosen. Oder war es PowerLine?

Kai Kreuzer: PlugWise ist Funk.

Thomas Eichstädt-Engelen: Funksteckdosen. Dann was jetzt in naher Zukunft kommen wird, was sicherlich jeder kennt, ist das Philips U, was wir mit einem Binding versehen und dann eben auch direkt steuern können und - ja - eine ganze Reihe mehr. Also ich will die jetzt nicht alle aufzählen, auf der Homepage haben wir die im Wiki unter dem Bindings-Kapitel alle aufgeführt.

Kai Kreuzer: Vielleicht noch eine Ergänzung, weil das für sehr viele deutsche User auf jeden Fall attraktiv ist, ist jetzt die neuste Entwicklung “HomeMatic”. Was auch eben Funkprotokoll ist und über die großen Elektroversender zu beziehen. D.h., da gibts viele User, die das haben, zu Hause schon und da ist es sehr interessant, dass das jetzt auch eingebunden werden kann. Anderes sehr interessantes Protokoll ist EnOcean. Da wird zur Zeit dran gearbeitet und EnOcean sind insofern besonders interessant, weil das sind Geräte, die sogenanntes Energy-Harvesting betreiben. D.h. die brauchen keine eigene Stromversorgung, keine Batterie, Knopfzelle, für irgendwo z.B. einen Fensterkontakt haben, sondern die bekommen ihre Energie einfach nur dadurch, dass z.B. der Fenstergriff gedreht wird. Das reicht als Energie dann für das Funktelegramm. Insofern das, was jetzt immer mehr kommt, immer mehr Leute Interesse haben, insofern wird da bei uns auch dran gearbeitet.

Stefan Tilkov: Eine organisatorische Frage: ihr habt Mercurial erwähnt, als Distributed Version Control System. Naheliegende Frage, warum Mercurial und nicht git? Historische Gründe oder seid ihr überzeugt davon, dass ihr damit besser fahrt oder was ist einfach der Grund?

Kai Kreuzer: Im Prinzip, ja historische Gründe insofern, als dass ich diese Entscheidung Anfang 2010 getroffen habe. Damals war git noch nicht so gehypt wie heutzutage und es waren im Prinzip beide ungefähr gleich verbreitet, würde ich sagen, die Systeme. Ich habe mir das dann angeguckt insbesondere die Unterstützung in der IDE und da war git - weil es EGit in der Form nur ganz rudimentär erstmal gab - deutlich, deutlich schlechter. Da war der Support von Mecurial in Eclipse deutlich schöner, die Begrifflichkeiten waren näher an SVN dran und insofern fiel damals die Entscheidung für mich auf Mercurial. Allerdings mit dem Hinblick zu sagen: "Ok, es gibt die Tools um eigentlich so ein Version-System auch problemlos wieder umzuziehen, auf git, wenn es mal irgendwann opportun ist. Dass, wenn man jetzt git nutzen will, hat man sich jetzt in keine Sackgasse manövriert.

Stefan Tilkov: Aber ihr seid mit eurer aktuellen Infrastruktur, GoogleCode benutzt ihr glaube ich für das Source-Hosting?

Kai Kreuzer: Ja, genau.

Stefan Tilkov: Mit GoogleCode und Mercurial seid ihr zufrieden, also es unterstützt euch genau bei dem, was ihr braucht, nämlich den Contributionen oder würdet ihr da einen Mehrwert sehen auf was anderes umzustellen?

Thomas Eichstädt-Engelen: Im Moment nicht, also wir haben auch kürzlich wieder diskutiert, ob wir das tun wollen oder nicht. Sicherlich ist das GitHub-Frontend, also GitHub als Collaboration-Plattform sicherlich noch ein bisschen schicker. Also das ist Geschmackssache. Aber ansonsten bringt es uns eigentlich nicht mehr als wir jetzt auch haben und aus dem Grund haben wir das einfach wieder auf Eis gelegt. Und haben gesagt: ne komm, wir bleiben dabei. Auch wenn die Unterstützung, die Tool-Unterstützung sicherlich besser geworden ist, bringt es uns so wenig Mehrwert, dass wir einfach nicht wechseln wollen.

Stefan Tilkov: Kann ich gut nachvollziehen. War nur eine Neugier-Frage, denn ich kann mir vorstellen, dass die auch häufiger mal gestellt wird. Immer wenn mir so Blödsinn durch den Kopf geht, gibt es auch andere Deppen, denen das durch den Kopf geht. Ist zumindest meine Erfahrung. Was mich noch interessieren würde, was macht ihr denn damit, was ist eure private Nutzung von openHAB oder ist es eine reine akademische Übung, die ihr bastelt. Klang nicht so. Es klang, als habt ihr beide konkret Bedarf. Läuft bei euch openHAB und wenn ja, was regelt ihr denn so?

Kai Kreuzer: Ja also absolut. Wie gesagt, ich hab das Projekt angefangen, weil ich es für mich persönlich brauchte. Ich hatte 2008 mir ein Haus gebaut und da die Chance genutzt beim Neubau wirklich alles zu elektrifizieren, was nur irgendwie ging. Und hab dann aber eben festgestellt, ok die Hardware alleine reicht nicht und KNX - mit dem ich das realisiert hab - dem fehlten halt die wesentlichen Sachen, nämlich ein schönes User-Interface. Es gab zwar sündhaft teure Touch-Panels für die Wände, aber das war schon das Zeitalter von iPad und Smartphones, wo ich gesagt habe, das braucht man in der Form nicht mehr, man hat sein Bedienbildschirm ja immer bei sich. Und da gab es einfach keine sinnvollen Lösungen und insofern hab ich das bei mir extrem im Einsatz für erstmal alles visualisieren, steuern, viel für statistische Nutzung. D.h. mitschreiben von Temperaturen und Heizungskurven usw., um das dann zu optimieren. Automatische Regelungen, ich nutze sehr viel Text-to-Speech-Enginge auch. D.h. wenn es anfängt zu regnen oder so und die Wäsche hängt gerade draußen auf der Wäschespinne - jetzt im Winter nicht so, aber im Sommer - dann bekommt man das drinnen durchgesagt, kann schnell raus sprinten und die Wäsche rein holen, bevor man sieht: “Oh, es regnet!” und es ist alles nass. Also diverse Sachen. Ich hab es rund um die Uhr im Einsatz, auch meine Familie, meine Frau nutzt es sehr gerne, meine drei- und fünf-jährigen Kinder sind da auch schon fleißig dabei irgendwo Sachen mit anzustellen. Insofern ist das sehr ordentlich im Testing. Und langsam wird der Security-Layer, den wir aktuell noch nicht haben, wird immer notwendiger.

Stefan Tilkov: Je älter eure Kinder werden.

Kai Kreuzer: Ja genau.

Stefan Tilkov: Wie siehts bei dir aus Thomas?

Thomas Eichstädt-Engelen: Ja, also bei mir ist es ein ähnlicher Umfang, wobei ich jetzt weniger Aktorik im Einsatz habe. Bei mir ist es - z.B. nutze ich die Bewegungsmelder, die Öffnungskontakte, Fensterkontakte, die eingebaut sind, mehrfach. Neben der Tatsache, dass damit dann die Heizung dann z.B. ausgeschaltet wird, wenn man das Fenster öffnet, oder die Klimaanlage, die ebenfalls darüber gesteuert wird, nutze ich die Melder eben auch als Alarmanlage. Also es ist eine recht umfangreiche Nutzung der Rule-Engine, die wir mitliefern. Und ja, solche Szenarien, wie “Wenn eine bestimmte Soll-Temperatur im Raum überschritten wird, aber es draußen zu warm wird…” Also im Sommer ist es so, ich habe eine bestimmte Soll- Temperatur eingestellt - das sind 23° oben - und draußen wird es über dieser 23° warm, dann wird die Klimaanlage eingeschaltet, weil dann würde es auch nichts bringen, die Fenster zu öffnen und zu lüften. Und andersrum würde eben die Klimaanlage eben wieder ausgeschaltet, wenn die Außentemperatur unter der Innentemperatur liegt und zwar über die letzte Stunde, beispielsweise. Also solche recht umfangreiche Regeln kommen dann sehr schnell zustande. Wenn man einmal das Mittel in der Hand hat, dann ja, dann werden die Regeln schnell immer komplexer.

Stefan Tilkov: Da fällt einem schon was ein. Und dafür habt ihr eine Regel- Engine, die man auch konfigurieren kann, ohne was zu programmieren, offensichtlich.

Thomas Eichstädt-Engelen: Haben wir, ja genau. Das haben wir jetzt noch nicht erwähnt. Also es gibt neben der Runtime, die wir haben, nutzen wir eben weitere Features aus dem Eclipse-Umfeld oder weitere Technologien. Das ist eben XText und XBase. Und wir haben eine Reihe von DSLs uns ausgedacht, mit denen man openHAB konfiguriert. openHAB wird aktuell über Dateien konfiguriert, was sehr schön aus XText eben dann hinten raus fällt. Es ist entsprechende Unterstützung, um dann auch eine IDE in Anführungsstrichen - bei uns heißt der “Designer” - einfach raus zu generieren. Und d.h., wir haben eben ein weiteres Tool neben der Runtime, das ist der sogenannte Designer. Und darüber kann man dann die Konfiguration mit Syntax- Highlighting, Code-Vervollständigung und den Annehmlichkeiten, die man halt aus der Java-IDE kennt, kann man eben dann auch konfigurieren.

Stefan Tilkov: Worüber wir noch gar nicht groß gesprochen haben ist dann die eigentliche Benutzeroberfläche. Kai, du hast zwar gerade erwähnt, dass man häufiger Smartphones und Tablets und was weiß ich was hat. Wie bindet ihr das ein? Was habt ihr da, habt ihr da native Client oder habt ihr da eine Web-Oberfläche oder alles mögliche?

Kai Kreuzer: Insgesamt haben wir da im Moment vier verschiedene User- Interfaces. Angefangen hatte ich das ganze mit einem HTML-/CSS-basierten Framework, welches im Prinzip aus der Zeit stammt, als es noch keine nativen iOS-Apps gab. Als noch von Apple die Ansage war, dass das alles Web-Applikationen sein sollten. Insofern stellt sich dieses User-Interface so dar, wie eine iOS-Applikation, ist aber insofern Cross-Plattform, d.h. einfach per Web zugreifbar. Auch im Web-Kit Browser vom PC aus. Und es ist erstmal so das Standard-User-Interface. Zusätzlich und da zurückkehrend zu deiner Frage der Contributions, haben wir auch native Clients und beide native Clients - sowohl iOS als auch Android Clients - sind wirklich komplett Contributions durch andere, wo wir wirklich nicht selbst mit Code geschrieben haben. Nur ein bisschen mitgeholfen haben mit den Konzepten und das umzusetzen. Und das sind aber wirklich dann auch gute Clients, die auch all die Funktionalität umsetzen, die du in der Web-Oberfläche hast. Und dann aber mit dem nativen Look and Feel eben. D.h., der Client für Android ist jetzt wirklich im Android 4 Style, also alles schwarz und passt da alles sehr gut ins Gesamterscheinungsbild. Und der vierte Client, den ich noch erwähnen will, ist der sogenannte GreenT. Es ist eine Sensor Touch basierte HTML-Oberfläche und die benutzt eben Sensor Touch als zu grunde liegende Plattform und bietet insofern da etwas mehr als unser Standard Web-Interface. Nämlich so Sachen, wie Slider-Support, schöne Übergänge mit Fading und solche Dinge. Insgesamt ist es so, dass für den Benutzer selbst es nicht sehr aufwendig ist sozusagen verschiedene User-Intefaces gleichzeitig zu betreiben. Denn wir haben eine deklarative Beschreibungssprache für den Content der User-Interfaces, d.h. mit ganz einfacher, textueller Beschreibung kann man sagen: ok, ich möchte jetzt hier bitte eine Seite haben, auf der meine Stockwerke gelistet sind und unter den Stockwerken sollen dann Unterseiten erscheinen mit den einzelnen Räumen und in den Räumen sind die und diese Geräte drin. Das beschreibt man einmal in einer sehr knappen Syntax und diese Information wird über eine REST-API nach außen bereit gestellt und von den Clients dann genutzt. D.h., alle Clients können diese eine Beschreibung benutzen und zeigen dir insofern den gleichen Kontent an.

Stefan Tilkov: Ok, was ist denn aus eurer Sicht das coolste Feature von openHAB?

Thomas Eichstädt-Engelen: Also ich finde, dass das coolste Feature nach wie vor die - muss ich dem Kai nochmal auf die Schulter klopfen - die absolut geniale Architektur ist. Also wir haben das jetzt, mehrfach kriegen wir das jetzt über neue Contributoren halt eben mitgeteilt, dass es einfach genial einfach ist, neue Bindings einzubauen. Es bietet genug, also die Architektur hat genug Freiheiten, um neue beliebige Features einzusetzen, aber ist auf der anderen Seite trotzdem so stark eingeschränkt, sag ich jetzt mal, dass man nicht totalen Blödsinn machen kann. Also das ist wirklich, das finde ich ist das Killer-Feature von dieser, von der Plattform.

Kai Kreuzer: Danke für das Lob Thomas, aber ich muss sagen, für mich ist das kein Feature, weil das tut ja nichts, du hast nichts davon, von dieser Architektur alleine. Insofern für mich ist das coolste Feature immer das, was ich zuletzt implementiert hab, denn sonst hätte ich es nicht implementiert. Das ist im Moment ganz konkret ein schöner Colour-Picker, d.h. ein schönes Farbrad, wo du dann jetzt die ganzen neu aufkommenden RGB- LED-Leuchten da ansteuern kannst, sowas wie eben das Phiips U System und das ist einfach schick, weil man dann sein Smartphone her nimmt und dann da die Farbe auswählen kann. Das macht einfach Spaß, das ist im Moment das coolste für mich.

Stefan Tilkov: Ok, gut ja dann habt ihr jetzt die einmalige Gelegenheit noch sämtliche shamless plugs los zu werden, die euch einfallen. Wo kann man mehr über openHAB erfahren? Was habt ihr an Auftritten, wo erzählt ihr was drüber in näherer Zukunft?

Thomas Eichstädt-Engelen: Also in erster Linie haben wir unsere Webseiten. Also die GoogleCode-Seite, die sehr technisch orientiert ist und insofern da wirklich alles beschrieben ist, die Architektur beschrieben ist, zu jedem Binding eine entsprechende Seite hinterlegt ist, was überigens auch ein Contribution-Feature ist. Also nur derjenige, der eine Wiki-Seite dafür schreibt, da wird auch das Binding veröffentlicht. Und dort haben wir sozusagen den öffentlichen Auftritt. Dann gibt es auch Konferenzen, auf denen wir uns noch rumtreiben. Das ist jetzt ganz aktuell als nächstes die JAX, auf der wir einen Vortrag halten. Und im Mai sind wir dann auch noch auf der GeeCon, in Krakau, in Polen.

Stefan Tilkov: Cool. Ok, habt ihr noch berühmte letzte Worte? Wollt ihr noch jemanden motivieren euch zu unterstützen?

Thomas Eichstädt-Engelen: Wollen wir? Ja klar. Also hmm, wie formuliert man’s? Wir wären froh oder wir sind froh um jede Contribution, die wir eben bekommen. Kai hat es eben schon gesagt, also die Fehlermeldung ist uns dabei genauso lieb, wie ein neues Binding, was uns entgegen gebracht wird, was uns überreicht wird. Wir haben ja auch - um da noch mehr zu unterstützen - haben wir auch inzwischen ein deutschsprachiges Forum, um da jetzt Leute oder mögliche Nutzer zu bedienen, die einfach nicht so gut in der englischen Sprache unterwegs sind. Also auch da bekommen wir sehr viel Zuspruch und auch Fehlermeldung geliefert und ja, wir sind froh um jeden, der einfach mitmacht. Also wir sehen an der Menge der Downloads - inzwischen sind es so knapp 900 jetzt für das 1.1 Release seitdem wir es veröffentlicht haben - dass auch einfach das Produkt ankommt.

Stefan Tilkov: Mhm, cool. Ok. Ja, würde ich mich bei euch sehr gerne herzlich bedanken für den Podcast, für die Information. Ich finde das Projekt extrem cool, bin sicher unsere Zuhörer auch. Alle Links sind wie immer in den Shownotes drin und zum Abschluss, Thomas, hast du uns auch nochmal Musik ausgesucht.

Thomas Eichstädt-Engelen: Genau, wie ich gerade erfahren habe, trifft das nicht auf allgemeinen Geschmack, aber meiner ist es jedenfalls, genau. Und das ist das Lied “Blue Acid” von Graphiqs Groove.

Stefan Tilkov: Alles klar. Damit Tschüss und bis bald, machts gut.

Kai Kreuzer + Thomas Eichstädt-Engelen: Tschüss.