Rahmenloses Wanddisplay

Einleitung

Über die letzten Wochen habe ich endlich mein Rahmenloses Wanddisplay bzw. Wall mounted Display Projekt fertig gestellt. Eine besondere Anforderung war das die Befestigung nicht sichtbar sein sollte.

Zum Einsatz kommt ein Galaxy Tab A von Samsung mit 10.1 Zoll Display. Hier läuft Habpanel in einem Webview innerhalb einer Android App.

Die App läuft in einer Art Kios Mode und verhindert so das z.B. das man mit der Zurück Taste aus versehen die Web App verlässt. Außerdem läuft im Hintergrund ein REST Server über den Openhab das Display des Tablets ein- bzw. ausschaltet je nach dem ob man schläft oder das Haus verlassen hat.

Wall mounted Tablet

Das am Tablet selbst habe ich auf der Rückseite 2 Metallplättchen angeklebt und in die Wand 2 Magneten eingelassen. Auf diese Art kann man da Tablet halterlos befestigen.

Was ist hinter dem Wall mounted Display Wall mounted display komplet montiert Detailansicht vom Wall mounted Display

Den mini USB Stecker habe ich von einen Qi Charger genommen, abgetrennt und mit einem zweiten Kabel verbunden.

Teileliste

Habpanel

Habpanel vom openHAB Projekt ist einer auf Angular basierende Web App. Durch den Unterbau kann es sehr flexibel erweitert und angepasst werden. Aufgrund der Anzahl an Elementen die bei mir mittlerweile in openHAB registriert sind (~600) musste ich allerdings ein paar Anpassungen vornehmen. Der normale “digest cycle” von Angular hat aufgrund des Konzeptes von Habpanel auf meinem Tablet zu einer CPU Last von ca. 20 Prozent geführt. Außerdem war gerade bei komplexen Dashboard ein spürbares delay von 1500ms bis 2000ms beim Dashboard wechseln spürbar. Jetzt läuft es mit ca. 2-3% CPU und einem delay von max 500ms.

Aber jetzt erstmal ein paar Bilder

Hauptmenu vom Wall mounted Display Untermenu des Gartens vom Wall mounted Display Untermenu des Wohnzimmers vom Wall mounted Display Untermenu zur Steuerung aller Lampen vom Wall mounted Display Untermenu zur Steuerung aller Rollläden vom Wall mounted Display Temperatur und Luftfeuchtigkeit auf dem Wall mounted Display Wetterbericht auf dem Wall mounted Display

Die Habpanel Oberfläche ist Teil meines Deployment Projektes und kann dort ausprobiert werden. Alternativ kann es auch direkt aus meinem Github Repository bezogen werden.

Meine nachfolgend beschriebenen “digest” Optimierungen sind bereits enthalten.

Optimierung des Angular “digest” Prozesses

Die größte Herausforderung ist der Angular “digest cycle”. Vorher, wusste keines der Widgets was es eigentlich anzeigen soll. Mit dem Ergebnis das nach jedem Item Update die komplette Habpanel UI einen digest cycle durchlief und refreshed wurde. Dadurch lief mein Tablet die ganze Zeit mit fast 20% CPU Last und verbrauchte dementsprechend viel Energie. Es werden in meiner Konfiguration ca. 30-40 Items jede Minute geupdatet bei einer Gesamtanzahl von ca. 500 Items. Auf dem Hauptscreen (Erstes Bildschirmfoto) wurde davon aber nur ca. 100 angezeigt.

Gelöst habe ich es, indem ich den digest cycle komplett überspringe. Alle meine Widgets sind als Custom Directives implementiert. Diese wiederum schalten alle Angular “watcher” aus. Statt dessen registrieren sie sich selbst für Item updates. Zusätzlich überschreiben die Direktive die “getItem” und “getItemState” Methode. Alle weiteren Widgets die sich innerhalb diese Custom Directive befinden registrieren sich wiederum bei Ihre “root” Direktive.

Während des ersten ItemUpdate Prozesses leitet die Direktive dieses Event nun zu allen Subwidgets weiter und sammelt im Anschluss alle benutzte Items über ihre Aufrufe von getItem, getItemState.

Ab sofort werden Updates an die richtigen Widgets weiterleiten oder Aktualisierungen für nicht verwendete Items werden vollständig ignorieren. Mein Tablet läuft jetzt mit 2-3% CPU und reagiert auf Touch Gesten wesentlich schneller.

Ich hatte auch mit einer Lösung experimentiert, die Watcher nur temporär beim passendem Item Update zu triggern. Aber das war leider nicht so effizient. Der digest cycle wurde trotzdem in vielen weiteren unerwünschten Situationen angestossen was wiederum zu unnötigen Widget Updates führte. Die Einzige Situation wenn ich ein Widget updaten möchte ist wenn es initialisiert wird oder wenn sich das Item ändert. Am Ende habe ich die zuvor beschriebene Lösung implementiert.

Ein weiteres Problem war eine spürbare Verzögerung wenn ich von einem Unterbildschirm zurück zum Hauptbildschirm gesprungen bin. Dies wurde auch durch meine digest cycle Änderungen verbessert. Vorher lag die Verzögerung bei ~1500ms. Nun liegt sie bei ~500ms und fühlt sich sehr wesentlich besser an.

https://intranet-der-dinge.de/
https://intranet-of-things.com/