Zentrale Steuerung der Homematic Gebäudeautomatisierung über ein Tablet mit individueller grafischer Oberfläche
Nach der erfolgreichen Einrichtung meines Smarthomes stand nun das nächste Projekt an: Steuerung aller Komponenten und Programme über ein in die Wand integriertes Tablet mit hübscher, individueller Oberfläche.
Vor Beginn dieses Projekts konnte ich die verwendeten Homematic-Geräte auf drei Wegen bedienen: Durch programmierte und verknüpfte Hardware-Schalter, über die Weboberfläche der Homematic CCU2 (Affiliate-Link), oder aber über die in meinem früheren Post schon einmal vorgestellte App „@Home“ von Gerald Klunker.
Nun möchte ich mich im nächsten Step von den vorgefertigten Programmoberflächen (GUIs) der genannten Weboberflächen oder Apps lösen. Eine Oberfläche soll her, die den Grundriss der Wohnung, des Gartens, etc. zeigt und die Geräte zur Statusinformation und zur Bedienung an den korrekten Stellen anzeigt.
Nur wie mache ich das am sinnvollsten?
Einige durchgeführte Internetrecherchen später war ich zumindest schon mal schlauer. Die Ergebnisse teile ich hier mit allen Interessierten.
Wo kommen die Daten her?
Der Weg, die gewünschten Daten auf das Tablet zu bringen führt eindeutig über die Bereitstellung einer Weboberfläche und somit der Darstellung der Oberfläche im Browser des Tablets. Das heißt im Umkehrschluss aber auch, dass die Oberfläche irgendwo bereitgestellt werden muss. Meine erste Idee war es daher, eine kleine Oberfläche direkt auf der Homematic-Zentrale CCU2 (Affiliate-Link) zu hosten. Angesichts der relativ kleinen technischen Spezifikationen (Prozessor, Speicher, etc. ) der CCU verwarf ich diesen Gedanken dann wieder ganz schnell.
Für mich persönlich stellt es nun auch keinen großen Aufwand dar, einen sowieso vorhandenen Server um einen Webserver zu erweitern. In meinem ersten Testfall missbrauchte ich meinen Backupserver zum Hosting.
Nutzer, die nicht gerade eine virtualisierte Serverfarm nutzen, können eine Weboberfläche aber auch auf einem vorhandenen Desktoprechner oder einem Mini-PC wie dem „Raspberry Pi hosten“. Letzterer hat besonders den Vorteil, dass diese Mini-PCs nur den Bruchteil der Energie benötigen, die Desktoprechner oder Server benötigen. Gerade im 24-Stunden-Betrieb der Lösung macht sich dieser Unterschied schnell in der Stromrechnung bemerkbar.
Was wird gehostet?
Zunächst einmal brauchen wir eine Art Datenadapter, der die Daten der CCU abruft und gleichzeitig auch Steuerungsdaten an die CCU übertragen kann. Diesen Datenverarbeitungskern gibt es bereits als vorgefertigtes Paket „CCU.IO“.
„CCU.IO“ besteht aus einem Webserver (Eine vorgefertigte Apache-Variante) einem Dienst zur Kommunikation und den Webinhalten. Im Detail handelt es sich bei den Webinhalten um eine Startseite und diverse Unterseiten mit denen „CCU.IO“ so konfiguriert werden kann, dass es mit meiner vorhandenen CCU „spricht“ und die abgeholten Daten anzeigt. Dies ist möglich, weil die CCU selber von Haus aus umfangreiche Protokolle zur Kommunikation mit externen Geräten ermöglicht, wie zum Beispiel XML-RPC-Prozeduren oder HTML POST- und GET-Methoden.
Ist also der „CCU.IO“-Server auf die vorhandene CCU konfiguriert, so kann der Server als eine Art Relais für die CCU angesehen werden. „CCU.IO“ stellt zunächst einmal alle Daten der CCU in Tabellen als Datenpunkte dar. So lassen sich Geräte, Systemvariablen oder Programme anzeigen, oder eben ausführen und in ihren Variablen ändern.
Das funktioniert, ist aber noch nicht hübsch.
Wie wird das ganze jetzt „cool“?
„CCU.IO“ bietet auch die Möglichkeit noch weitere Add-Ons direkt über die CCU.IO-Weboberfläche zu installieren, bzw. aktiv zu schalten. Unter anderem das Add-On „DashUI“. Und „DashUI“ macht genau das: Es hostet eine HTML5-basierte Oberfläche in der sich Geräte, Programme oder Variablen des Homematic-Systems neben weiteren zusätzlichen Daten wie zum Beispiel Wettervoraussagen von extern darstellen lassen.
Die Erstellung der Ansichten geschieht dabei ebenfalls über die Weboberfläche von „DashUI“. Und das sogar größtenteils ohne Programmierkentnisse. Grundlagenverständnis von HTML und CSS sollte aber vorhanden sein.
Die gewünschte Oberfläche kann dann mit sogenannten „Widgets“ zusammengeklickt werden.
Bei der ersten Erstellung einer Oberfläche sollte man sich darüber im Klaren sein, auf welchem Gerät man seine Weboberfläche in Zukunft aufrufen möchte: Denn Dash.UI ist nicht responsive. Stelle ich also ein für 1024×768 Pixel optimiertes Dashboard auf einem kleineren Display dar, muss ich scrollen. Andersherum bleibt vielleicht ein großer Teil des Bildschirms leer.
Damit sich sämtliche Anzeigen und Schalter logisch angeordnet wiederfinden, dient in meinem Fall ein als Grafik hinterlegter Grundriss als Hintergrund der Weboberfläche.
In meinem Fall sieht man also aus der Vogelperspektive die Anordnung sämtlicher Schalter oder Werte. Denkbar wäre so aber auch die Abbildung echter Fotos mit passend eingebetteten Widgets, oder die Darstellung von 3D-Renderings.
