Brennerstuhl Brematic Gateway mit Apple HomeKit steuern

Seit dem Update auf Apple iOS 10 ist Apple HomeKit für mich durch die bessere Integration in das UI sowie die Steuerung über Siri interessanter geworden. Das macht für mich die Benutzung von Home-Automatisierung deutlich bequemer.

Ich verwende bisher zum einen Phillips Hue sowie das brennenstuhl® Brematic Home Automation Gateway GWY 433 zur Steuerung der Beleuchtung meines trauten Heims. Ersteres ist dabei von Haus aus Apple HomeKit kompatibel, Letzteres jedoch leider nicht. Da das brennenstuhl® Brematic Home Automation Gateway GWY 433 bisher für mich die günstigste Möglichkeit war, bestehende Geräte und Beleuchtungen zu Steuern, war schnell klar, dass ich Hierfür eine Lösung suchen würde.

Da sich das brennenstuhl® Brematic Home Automation Gateway GWY 433 ab Auslieferung mit der Stecker Pro App über Netzwerk steuern lässt, und ich auch in der Vergangenheit bereits andere Apps, unter anderem im Android Store, entdeckt hatte, habe ich die Kommunikation mit dem Gateway erst einmal als das kleinere Problem angesehen und mich auf die Integration in Apple HomeKit fokussiert.

Nach ein wenig recherche habe ich herausfinden können, dass eine Integration eigener Geräte in Apple HomeKit durch eine eigene Server Applikation im Prinzip möglich ist, woraufhin ich mich auf die Suche nach einem node.js Projekt gemacht habe, dass mich hierbei unterstützt. Dabei bin ich auf das Projekt Homebridge gestoßen, das mir recht vielversprechend erschien. Durch Homebridge wurde das Problem der Apple HomeKit integration bereits für mich gelöst.

Nun musste noch die Kommunikation zwischen Homebridge und dem brennenstuhl® Brematic Home Automation Gateway GWY 433 hergestellt werden. Leider erwies sich dies als deutlich komplizierter als zunächst vermutet.

Zum besteht die Dokumentation zur Erstellung eines Homebridge Plugin lediglich aus Beispiel-Code, der sich jedoch ausschließlich auf die Implementierung als "Platform" beschränkt. Alle Details zur Implementierung als "Accessories" musste ich mir aus dem Code anderer Plugins erschließen.

Zum anderen gibt es leider so gut wie keine Dokumentation zum Protokoll mit dem das brennenstuhl® Brematic Home Automation Gateway GWY 433 gesteuert werden kann. Durch Reverse Engineering, viel Recherche und Testing, ist es mir dennoch gelungen das Protokoll rudimentär zu implementieren. Viele Details sind mir leider jedoch noch immer unklar. In einem separaten Post werde ich hierzu bei Gelegenheit ausführlicher berichten.

Letztendlich habe ich ein Homebridge Plugin verfasst dass unter dem Namen homebridge-brematic auf GitHub liegt und über NPM installiert werden. Eine Anleitung kann in der entsprechenden README gefunden werden. Bisher lassen sich damit die brennenstuhl® RCS 1000 N und kompatibel Funkschalter steuern, da dies die einzigen mir vorliegenden Funkschalter sind. Sollten mir bei zufällig weitere Funkschalter in die Hände fallen, werde ich die Kompatibilität noch erweitern.

Wie bei all meinen Projekten würde ich mich natürlich über Feedback freuen. Hierfür steht auch ein Gitter Channel zur Verfügung. Weiterhin habe ich für dieses Projekt auch eine Wishlist auf beerpay.io  angelegt, über die die Implementierung weiterer Features oder die Kompatibilität anderer Funkschalter angefragt werden können.

Sollte irgendjemand da draußen Interesse daran haben, sich an diesem Projekt zu beteiligen, würde ich mich natürlich sehr freuen.

Emmet - The essential toolkit for web-developers

Eine der Dinge, die ich in meiner täglichen Arbeitswelt nicht habe, ist zu viel Zeit. Daher bin ich immer daran interessiert, wenn möglich genau diese, mir sonst an anderer Stelle fehlende Zeit einzusparen.

Eine der häufig unnötig Zeit kostenden Tätigkeiten ist dabei das Aufbauen der benötigten DOM Struktur. Dabei ist es oft der Fall, dass viele wiederkehrende Elemente, wie beispielsweise Listen und deren Elemente, angelegt werden müssen. Diese Arbeit ist oft mühselig und kostet unnötig Zeit.

Abhilfe kann hierbei Emmet schaffen. Mit dem selbst ernannten "essential toolkit for web-developers" lassen sich mit einfachen Anweisungen schnell und einfach komplexe Strukturen aufbauen.

Einen Überblick über die Funktionen findet ihr in der Emmet Dokumentation.

Emmet ist als Plugin für viele Editoren verfügbar. Viele Online IDEs  wie CodePen und JSFiddle haben Emmet sogar schon integriert.

Glücklicherweise wird Emmet nativ von meiner Lieblings-Entwicklungsumgebung PHPStorm von JetBrains unterstützt.

Für alle, die gerade erst beginnen, oder ausgelößt durch diesen Artikel, mit Emmet zu arbeiten, kann ich dieses Cheat Sheet Empfehlen.

Ich hoffe, dass ihr genauso viel Interesse an Emmet findet und dies euch ebenfalls eure Arbeit erleichtert.

Callbacks in JSDoc

lange Zeit habe ich mich gefragt, ob es in JSDoc  eine Möglichkeit gibt, Callbacks beziehungsweise die Parameter die an die Callbacks übergeben werden sauber zu dokumentieren.

Bis dato habe ich zwar die Callbacks die an die aufrufenden Funktion übergeben werden mit @param Dokumentiert, die Parameter die an diesen Callback übergeben werden musste man jedoch schlichtweg wissen.

Bei kleineren Skripten ist dies ja noch möglich, bei größeren Skripten führt die häufig schnell ansteigende Zahl der Callbacks jedoch auch zu einem recht proportionalen Verlust der Übersicht über eben diese.

Des weiteren konnte ich mir nicht vorstellen, dass es hierfür keine Lösung gibt, denn dinge die man schlichtweg wissen muss stehen ja schon prinzipiell kontrovers gegen den Grundgedanken einer Software Dokumentation und damit auch gegen das Prinzip von JSDoc.

Nach einiger Recherche habe ich heute dann doch die korrekte Lösung dann doch ganz am Ende der Dokumentation zu @param finden können:

/**
 * This callback type is called `requestCallback` and is displayed as a global symbol.
 *
 * @callback requestCallback
 * @param {number} responseCode
 * @param {string} responseMessage
 */
/**
 * Does something asynchronously and executes the callback on completion.
 * @param {requestCallback} cb - The callback that handles the response.
 */
function doSomethingAsynchronously(cb) {
    // code
};

Zunächst definiert man über den @callback Parameter die Callback Funktion mit den zugehörigen Parametern. An der aufrufenden Funktion kann man nun mit {callbackName} auf die zuvor dokumentierte Callback-Funktion verweisen.

Ich bin froh, nun einen Ansatz gefunden zu haben, der mir einen besseren Überblick in großen Projekten verschafft und hoffe, dass ich dem ein oder anderen dadurch ebenfalls helfen konnte.

Performant HTML5 Canvas detection

Für ein aktuelles Projekt muss ich in der Applikation prüfen, ob HTML5 Canvas zur Verfügung steht und genutzt werden kann. Ist dies nicht der Fall, soll dem Anwender eine entsprechende Rückmeldung gegeben werden, mit der Bitte doch bald einmal seinen Browser zu aktualisieren.

Der übliche Weg, der auch in den meisten Frameworks verwendet wird, ist ein entsprechendes Canvas Element zu erzeugen und das Ergebnis zu überprüfen.

Beispiel:

var canvasSupport = !!document.createElement("canvas").getContext;

Leider ist dieser Ansatz, gerade im Internet Explorer, aber auch in anderen Browsern recht performance hungrig. Ein anderer Weg ist es das im HTML Standard und im W3C Working Draft definierte Interface anzusprechen. Eine Dokumentation dazu ist auch im Mozilla Developer Network zu finden.

Beispiel:

var canvasSupport = !!window.HTMLCanvasElement;

Wie vermutet und durch einen jsPerf Test belegt, ist diese Methode in vielen Browsern deutlich schneller. Der Grund hierfür ist recht schnell klar: Bei der zweiten Methode muss nicht erst ein entsprechendes Element erzeugt werden.

Dass dieser Weg deutlich schneller sein muss, ist daher nur logisch. Überrascht hat mich jedoch das Ergebnis. Bei eigens durchgeführten Tests im sogar recht aktuellen Internet Explorer 11 lag der unterschied bei ca 200%!

Den Entsprechenden Test könnt ihr auch selbst durchführen. die URL lautet:
http://jsperf.com/htmlcanvaselement-vs-getcontext-checks

The Power of SASS

See the Pen Particle Orb CSS by Nate Wiley (@natewiley) on CodePen.

Heute bin ich über CodePen über diese SCSS Demo gestolpert die mich doch sehr überrascht hat: Das Ergebnis an sich ist technisch nicht so anspruchsvoll und ließe sich selbstverständlich mit HTML5 Canvas oder ähnlichem problemlos lösen. Die hier vorgestellte Lösung basiert jedoch ausschließlich auf SCSS und kommt ohne JavaScript oder ähnlichem aus. Dies hat mich tatsächlich doch überrascht und mir ein weiteres mal gezeigt, wie mächtig CSS bzw. SASS & LESS doch sind.

Spotify Playlist: Power-Working

Für alle freunde der härteren elektronischen Klänge habe ich einmal eine Playlist mit Liedern die mir beim Arbeiten den richtigen Kick geben zusammengestellt.

 

Falls euch noch Tracks einfallen, die unbedingt in diese Playlist sollten, würde ich mich freuen, wenn ihr mir einen Kommentar hinterlasst.

Shopify Checkout Hack

Für einen Kunden arbeite ich derzeit an einem Web-Shop der auf Wunsch des Kunden mit Shopify umgesetzt wurde.

Wie in diesem Beitrag mehrfach bestätigt, ist es bei Shopify regulär leider nicht möglich den Checkout Prozess anzupassen, weder per Template noch über ein Custom Stylesheet.

Für den Kunden ist es jedoch essenziell, verschiedene Änderungen am Checkout-Prozess vorzunehmen. Zu dem Zeitpunkt an dem ich in dieses Projekt involviert wurde, war die Entwicklung jedoch schon zu weit fortgeschritten, dass ein Wechsel der Shop-Lösung leider nicht mehr möglich war. Daher blieb mal wieder keine andere Möglichkeit, als irgendwie einen Weg zu finden, die Änderungen umzusetzen.

Nach intesivem auseinandersetzen mit Shopify, der Administrationsoberfläche dieser Lösung, und dem integrieten Template System, ist mir nach einiger Zeit aufgefallen, dass es bei hinterlegtem Google Analytics Account die Möglichkeit gibt, Anpassungen für das Google Analytics Tracking zu hinterlegen. Diese Option kann in der Administrationsoberfläche unter

> General > Google Analytics > Additional Google Analytics Javascript

gefunden werden.

Wie sich nach einigen Tests rausstellte, wird der Code, der an dieser Stelle hinterlegt wird, auf allen Shopify Pages, inclusive der Checkout Pages als reguläres <script> Tag geladen.

Ein paar Zeilen später hatte ich ein Script gebaut, dass gegebenenfalls JQuery nachlädt, den aktuellen Schritt des Checkout Prozesses ermittelt und gegebenenfalls JavaScript Code ausführt. Das Ergebnis findet Ihr hier:

Vor dem Einfügen des Scriptes, sollte dieses noch komprimiert werden. Ich persönlich bevorzuge dafür das in node.js entwickelte Tool UglifyJS.

Falls irgendjemand diese Lösung benutzt oder sogar erweitert, würde ich mich über Feedback als Kommentar zu diesem Post freuen.