Podcast

openHAB: Home-Automation mit Java

OSGi fĂŒr das Internet der Dinge

In diesem Podcast unterhalten sich die openHAB-Committer Kai Kreuzer und Thomas EichstĂ€dt-Engelen mit Stefan Tilkov ĂŒber den technischen Hintergrund des openHAB-Projektes, die Community die sich darum gebildet hat und die Erfahrungen mit einem populĂ€ren Open Source-Projekt.

ZurĂŒck zur Episode

Transkript

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.