Unser zu Hause wird mehr und mehr „digital“, Smarthome-Lösungen halten Einzug. Dabei stehen immer öfter gute Bedienbarkeit und damit das User-Interface im Mittelpunkt. In unserem Projekt soll es um eine vielseitige und einfach zu realisierende Oberfläche für eine bestehende Lösung gehen.
Im ersten Bild ist unsere fertige Weboberfläche mittels „FHEM-Tablet-Interface“ zu sehen. Seit nunmehr vielen Jahren betreiben wir zu Hause eine Heimautomationslösung, welche immer wieder angepasst, bis heute mit käuflichen Komplettangeboten mithalten kann.
Steuerzentrale war immer ein möglichst stromsparender Kleinserver, zuerst ein Mini-PC mit IP-Symcon, dann ein Banana Pi und aktuell ein Raspberry Pi 3 mit FHEM. Das wird vielen Nutzern mittlerweile ziemlich bekannt vorkommen.
In Verbindung mit der freien Software FHEM lässt sich Hardware ganz verschiedener Hersteller ansteuern, wir haben größtenteils Sensoren und Aktoren aus dem Homematic-Programm und preiswerte Komponenten mit LaCrosse-Protokoll angebunden.
Für die Kommunikation per Funk hängen dazu am Raspi ein CUL-Stick und ein Jeelink-Adapter im Eigenbau. Der Raspberry selbst hat mittlerweile ein vollwertiges Gehäuse bekommen, wo auch eine SSD und eine unterbrechungsfreie Stromversorgung Platz gefunden haben. Die standardmäßige Web-Oberfläche von FHEM bietet viele Informationen. Für bessere Übersichtlichkeit und Design, sind in letzter Zeit mehr Möglichkeiten verfügbar geworden. So wie diverse Apps und eben auch das Tablet-Interface „FTUI“.
Der Ersteller ist der FHEM-Forum-User „setstate“. In 2017 hat die Version 2.5 Einzug gehalten. Das Frontend Framework basiert auf HTML, CSS und Javascript. Zum Betrieb braucht es eine FHEM-Installation mit einem HTTPSRV-Modul und klar, einen Browser.
Eine gelungene Erweiterung finde ich. Besser für die Touch-Bedienung ausgerichtet, kann man per Tablet, Smartphone, oder auch am PC, wichtige Werte in den Vordergrund rücken, vielseitig visualisieren und clever gruppieren.
Dazu braucht es nur bedingt tieferes Programmierwissen. Es wird mit HTML-Code gearbeitet, wo die vorhandenen Geräte per <DIV>-Statement eingebunden und abgefragt werden. Nach diverser Einarbeitung kann man sich an die Gestaltung einer solchen Oberfläche herantrauen, auch ohne wirklicher Profi zu sein.
Für Experten bietet das FTUI wiederum tolle Möglichkeiten. Anleitungen gibt es auf der Wiki-Seite von FHEM und in diversen Blogs. Im Ergebnis entsteht dann so etwas, wie auf den Bildern hier zu sehen, zum Beispiel auch eine Übersichtsseite über den Zustand der Batterien aller Geräte, welche nicht am permanenten Stromnetz hängen. Für ein einheitliches Aussehen haben alle unsere Seiten das selbe Hintergrundbild, dunkle Zellen mit diverser Transparenz und gleiche Fonts bekommen.
Das Ganze soll in nächster Zeit bei uns noch Schritt für Schritt wachsen. Die Entscheidung dazu viel quasi im Hinblick auf den Markt und die derzeit verfügbaren Systeme. Wo ich also noch ein Stückchen beim Unterbau mittels Raspberry Pi, FHEM und Homematic bleiben möchte, da eine gewisse Zukunftssicherheit da ist. Man will ja nicht ständig umsatteln.
Ein wesentlicher Vorteil des Tablet-UI ist außerdem, dass es auf verschiedenen Endgeräten mit unterschiedlichen Bildschirmgrößen funktioniert. Somit lohnt es sich also, das grafische User-Interface so gut als möglich auszubauen, um damit nicht zuletzt einen fast immer gleichen Blick per PC, Notebook, Tablet oder Handy auf seine aktuellen Daten zu haben.
Gut, dass der FHEM-Server, wie es bei aktuellen CMS gängig ist, eine Trennung zwischen Inhalten und Design erlaubt. Somit kann man eine neue Oberfläche gestalten, ohne alle bisherigen Verknüpfungen zwischen den mitunter vielen Aktoren und Sensoren anzutasten.
Aber man sollte sich wegen der Übersichtlichkeit vorher Gedanken machen, ob man wirklich alle Geräte und Zustände visualisieren und schaltbar machen möchte. Und gleichzeitig so „agil“ vorgehen, dass man etwa an den Verknüpfungen im Unterbau auch etwas ändert, falls es der Weboberfläche zuträglich ist. Damit wären wir bei der Planung angekommen. Möchte man eine Menge darstellen, machen sich mehrere Seiten gut, bei uns sind das derzeit:
1 – Startseite
2 – Skripte
3 – Batterie-Zustände
4 – Webcam
Und da geht noch viel mehr. Wo wir uns auf eine minimale Vorhersage auf der Startseite beschränken, mögen manche zum Beispiel eine komplette Wetterseite. Proplanta-Wetter ist derzeit recht beliebt. Auch Kalender findet man häufig, so wird das Tablet zur Informationszentrale. Andere binden auch noch diverse Utilities ein, wie etwa einen Button, um den Server herunterzufahren oder das Event-Log anzuzeigen. Auch keine schlechte Idee, weil man sich für solche Aktionen ansonsten meist tief durch ein Menü klicken muss.
Zurück zu unserem Projekt ist es eine gängige Methode, dass man seine Objekte im Layout nach Beleuchtung, Heizungssteuerung, Rolladen oder ähnlichen Aufgaben gruppiert. Eine andere, alles den in der Wohnung vorhandenen Räumen zuzuordnen. Wir haben per Raum zusammengefasst, ähnlich einem Grundriss, kann man dort noch ansatzweise die wirkliche Anordnung der Räume erkennen.
Mitunter hilft eine Skizze vorab. Nicht zuletzt kommt es darauf an, wie viele Objekte ich auf einer Seite unterbringen möchte, an welcher Stelle sie stehen sollen und wie breit und hoch die abzugrenzenden Sektionen, Links sein sollen. Da wird man schnell feststellen, dass diverse Räume mehr automatisierungslastig sind als andere. Und man wird zum Beispiel dem Wohnzimmer mehr Platz in der UI einräumen, als dem Flur oder Abstellraum.
Die maximale Anzahl an Spalten und Zeilen ergibt dann ein Gitter. Acht Spalten und vier Zeilen im Gridster-Layout waren für mich für die Startseite der beste Kompromiss, um die meisten im Haushalt vorhandenen Geräte übersichtlich abzubilden.
Platz genug für alle Widgets und immer noch per Finger am Tablet bedienbar. Für weitere Seiten bin ich davon etwas abgewichen. Wie wird das nun in HTML umgesetzt? Das Grundgerippe sieht wie gewohnt so aus:
<!DOCTYPE html>
<html>
<head>…</head>
<body>…</body>
</html>
Dazu kommt der FTUI-typische Meta-Rahmen mittels Gridster (oder Flex, Tabelle, Reihen). Ein Daten-Link wird durch Reihe und Spalte platziert (data-row, data-col) und seine Ausmaße in x- und y-Richtung (data-sizex, data-sizey) festgelegt, was dann so aussehen kann:
<body>
<div class=“gridster“>
<ul>
<li data-row=“1″ data-col=“1″ data-sizey=“1″ data-sizex=“2″>
<div … ></div>
<div … ></div>
</li>
<li … >
…
</li>
</ul>
</div>
</body>
Die Funktionalität der Devices wird durch Widgets bewerkstelligt, wovon es günstigerweise viele bereits integrierte Standard-Widgets und 3rd-Party-Widgets gibt. Daneben kann mit Templates gearbeitet werden.
An Stelle der leeren <DIV>-Statements von oben treten dann eine oder mehrere Gerätedefinitionen mittels Widget, je nachdem, wieviel Platz man in x- oder y-Richtung reserviert hat. Gerne in Zellen (cell) eingeschlossen, wo man zum Beispiel ein Wandthermostat visualisieren möchte:
<div class=“cell“
data-type=“thermostat“
data-device=“Wandthermostat_WZ_Climate“
data-valve=“ValvePosition“
data-get=“desired-temp“
data-temp=“measured-temp“>
</div>
Will man Daten empfangen oder per Push- oder Switch-Button senden, sind data-get, data-set-on oder data-set-off wichtige Schlüsselworte. Danach folgt die nächste Zelle mit einem oder mehreren Widgets, Links oder Textlabeln. Hat man den aktuellen Datenlink gefüllt, geht es zum nächsten, welcher vielleicht in der nächsten Zeile row liegt. Und da man ein Koordinatensystem aus data-row und data-col zur Verfügung hat, ist es nicht einmal von Belang, in welcher Reihenfolge, die einzelnen <li>-Statements im Quelltext angelegt werden. Eine gute Struktur hilft wie immer aber, sich auch später noch zurechtzufinden.
Im Standard-Umfang bietet FTUI alles Notwendige. Manch einer möchte noch externe Widgets einsetzen oder etwa sogar selbst welche entwerfen. Vorallem aber Klassendefinitionen für Größe, Farbe und Positionierung nicht vergessen. Beispiele dafür sind:
Größen für Symbole oder Labels: tiny: 60%, large: 125%, bigger: 200%,
Positionierung: top-space: 15px extra on top, inline: kein Zeilenumbruch…
Denn mit solcherlei Anpassungen schafft man sich sein eigenes, unverwechselbares Layout, und davon gibt es massig. Kompliment an die Entwickler. Alles weitere zum Quelltext würde wohl den Rahmen hier sprengen. Für die ersten Schritte kann man alles in
https://wiki.fhem.de/wiki/FHEM_Tablet_UI
recht gut nachlesen. Und es gibt mittlerweile eine umfangreiche Community, die meisten Fragen zum Start kriegt man deshalb durch Websuchen beantwortet. Bis man richtig firm wird, dauert es sicherlich ein Stück, ist aber am Ende so schwierig nicht.
Nun zur Installation des Tablet-UI. Da sind Nutzer, welche schon einen funktionierenden Hausautomations-Server per FHEM am Laufen haben, wissensmäßig im Vorteil. Dessen Web-Frontend erreicht man standardmäßig durch
http://meinserver:8083/fhem/
Mittels der Portnummer (8083/84/85) wird durch FHEM noch zwischen verschiedenen Endgeräten unterschieden, dadurch kann man auf Unterschiede zwischen PC, Tablet und Smartphone eingehen. Beim Tablet-UI gibt es einen extra Pfad in das Unterverzeichnis /ftui nach
http://meinserver:8085/fhem/ftui/
Da ist die Portnummer nicht mehr so wichtig. Nebenbei, der letzte Slash am URL ist aber nicht unwichtig, weil es ansonsten ein ungeliebtes Verhalten mit relativen Links geben kann. Aber zuerst muss man installieren. Auf dem Raspberry Pi werden durch
update all https://raw.githubusercontent.com/knowthelist/fhem-tablet-ui/master/controls_fhemtabletui.txt
alle notwendigen Dateien in das FHEM-Verzeichnis /opt/fhem/www kopiert. Anschließend ist mittels der FHEM-Kommandozeile ein neues HTTPSRV Device in FHEM anzulegen, welches auf den Ordner mit den gerade heruntergeladenen Dateien verweist, in dem man
define TABLETUI HTTPSRV ftui/ ./www/tablet/ Tablet-UI
eingibt. Damit die Tablet-UI mit FHEM kommunizieren kann, ist noch die longpoll-Einstellung im FHEMWEB Device festzulegen, was so aussieht:
attr WEB longpoll websocket
Oder, falls das nicht funktioniert (bei Problemen mit websocket):
attr WEB longpoll 1
Jetzt muss man noch die anfängliche Beispieldatei in /opt/fhem/www/tablet/index-example.html gegen den eigenen Entwurf austauschen, wenn man schon soweit ist. Nach einem Neustart von FHEM wird das Ganze dann aktiv.
Was wir entwickelt haben, läuft auf einem Lenovo-Tab klaglos, auch das Handy ist im Landscape-Modus gut verwendbar, alle Symbole sind da noch gut zu erkennen. Mein neuer Notebook hat auch einen Touchscreen. Und auf einem großen PC-Bildschirm geht’s natürlich auch. Und überall dort, wo man einen Browser mit Verbindung ins lokale Netzwerk aufrufen kann.
Ein Zugriff aus der Ferne ist auch kein Problem, wenn man eine statische Netzwerkadresse konfiguriert hat. Ist bei mir absichtlich nicht vorgesehen, das WLAN reicht uns, um im Garten bei schönem Wetter alles zu machen.
Auf dem Startbildschirm der UI sind also die wichtigstens Angaben platziert und per Raum gruppiert. Bisher reichen uns die Standard-Widgets, eines davon die Anzeige für die Wandthermostate der Heizung mit Soll- und Istwert. Die finde ich gelungen. Daneben wird für jeden einbezogenem Raum auch noch die Luftfeuchte angezeigt. Eine interessante Sache ist, diverse Lichtszenen zu schalten, wo auf Knopfdruck mehrere Leuchten je nach Stimmung und Bedarf verschieden gedimmt werden.
Bei den Skripten finde ich die generellen Funktionen gut. Vor allem möchte ich ein „Alles Licht aus“ nicht mehr missen. Denn da ist es nicht nur Spiel, sondern hilft echt. Zum Beispiel vor dem zu Bett gehen oder vor dem Urlaub. Da kann man mittels einer Abwesenheitsschaltung komplett alles in den Ruhestand versetzen und zum Beispiel auf alle Heizkörper die Absenktemperatur legen. Und so ist es auch bei uns gemacht. Bilder darstellen auch kein Problem, bei uns liegt ein Link auf der zuletzt durch die Webcam geschossenen Aufnahme…
Bei uns liegt das Tablet auf dem Tisch und eine Homematic-Fernbedienung gibt es auch. Damit ist man bei der Bedienung ziemlich mobil.
Auf einem Android-Gerät kann man die Web-Oberfläche auch mit dem Fully-Browser aufrufen. Den gibt es im Android-Store, und er ist eine wirkliche „Kiosk-Lösung“. Damit passt er gut zum FTUI, weil er den gesamten Platz vom Screen ausnutzt und das Display ständig am Laufen hält. Die Navigationszeile gibt es erst bei Bedarf. Dadurch hat man schon alle Mittel für einen Dauerbetrieb an Bord. In dieser Kombination lässt sich also auch ein tolles stationäres Infodisplay im Haus realisieren.
Interessiert man sich heute für ein schönes Smarthome und traut man sich zu, den Weg zu einer herstellerunabhängigen Lösung wie FHEM zu machen, dann sollte man sich das Tablet-UI auf jeden Fall ansehen. Denn mit wenig Anstrengung schafft man sich dann ein absolut schönes Interface, was jeden Tag richtig Spaß macht …