pattyland's Blog

Alles was einen Stecker hat und mehr kann als waschen…

16. Februar 2017
von Sören Müller
Keine Kommentare

IFTTT Actions im Intranet mit Adafruit IO & MQTT

Ich freue mich immer wenn Entwickler von IoT Geräten Möglichkeiten einbauen auf Ereignisse zu reagieren. Bestes Beispiel ist der Echo*, dem Amazon mit IFTTT ein paar nette Trigger spendiert, z.B. wenn der Timer ausläuft oder ein Wecker losgeht.

Worüber ich nicht besonders freue, ist das diese Trigger meistens nur mit IFTTT funktionieren. Klar, Amazon versucht damit einer größere Zielgruppe von Bastlern zu erreichen als wenn Sie z.B. HTTP Requests einbauen würden. Dafür erreiche ich meine Smarthome Geräte nicht mehr, die alle hinter meiner FRITZ!Box im Intranet stehen. Während ich darauf warte das Amazon für mich diese Trigger einbaut, hab ich mich nach Übergangslösung angeschaut, wie ich (möglichst sicher) IFTTT Actions in meinem Intranet auslösen kann.

Der erste Gedanke ging natürlich an den IFTT Maker Channel, Portfreigabe im Router und ein nginx o.ä. der die Requests entgegen nimmt und Skripte ausführt. Ehrlich gesagt war mir immer etwas mulmig bei dem Gedanken Zugriff von außen in mein Intranet zu ermöglichen… Klar, mit fail2ban etc kann man vieles verhindern aber am liebsten war mir eine Möglichkeit in die andere Richtung.

Danke es sehr guten Tipps von Nils (Danke!) habe ich mir mal MQTT angeschaut, ein offenes Protokoll für M2M Kommunikation. Der häufigste Anwendungsfall im Bereich MQTT wird vermutlich sein, das Sensoren oft und ohne Aufwand Werte an einen Server schicken sollen, und Clients diese Auswerten und reagieren. Für mich besonders interessant war aber die Möglichkeit das Clients sich mit dem „Broker“ verbinden, und die Nachrichten dann in Echtzeit gepusht bekommen, es gibt kein Polling. Ein paar Sekunden Verzögerung könnte viele Aktionen schon unnütz werden lassen.

Ich habe im ersten Versuch einen MQTT Server bei CloudMQTT gemietet, und über den IFTTT Maker Channel einen PHP Datei aufgerufen die MQTT Events erstellt hat. Beim Basteln bin ich dann auf Adafruit IO getoßen. Adafruit IO bietet sogenannte Feeds. Die können auch vielen verschiedenen Quellen beschrieben werden und z.B. mit MQTT ausgelesen werden, Außerdem hat es eine native IFTTT Integration und war in meinen Tests noch ein paar Sekundenbruchteile fixer als mit PHP. Ein Applet für Alexa könnte z.B. so aussehen:

 

 

Damit wäre der Broker auch schon fertig. Als Client kann theoretisch alles fungieren; Es gibt für viele Programmiersprachen fertige Bibliotheken. Bei läuft die komplette Hausautomation auf einem C.H.I.P., und dort fast alles über Node.js. Ich hab mich deshalb auch entschieden den Client in JavaScript zu schreiben, die passende Bibliothek für Node.js trägt den passenden Namen mqtt.

So sieht mein Code im Moment aus:

Kurz erklärt:

Verbinde dich über MQTT mit io.adafruit.com und abonniere (subscribe) meinen Feed „alexa-timer“. Hier können beliebig viele Feeds abonniert werden.  Spanned wird’s dann beim Listener. Hier warte ich bis eine „message“ ankommt und schaue in welchem Feed diese gepostet worden ist, die eigentliche Nachricht ignoriere ich im Moment. Da ist hier im Intranet bin, stehen mir alle Möglichkeiten offen: In meinen Fall weise ich meine ha-bridge die Lampe Nr. 4 einzuschalten, was dazu führt das mein selbstgebautes Ambilight rot blinkt. Außerdem starte ich ein Skript dass sich via ADB mit meinem Fire TV verbindet und die Pause-Taste simuliert, damit ich den Timer nicht aus Versehen verpasse weil ein Film oder Musik läuft.

Hier ist nochmal eine kleine Grafik die den Weg von Alexa zum IoT Gerät beschreibt:

So könnte sieht das ganze dann im Ergebnis aus:

6. Februar 2017
von Sören Müller
4 Kommentare

Hyperion mit Alexa steuern

Schon seit ein paar Tagen habe ich nun auch ein paar LED-Streifen hinter meinem Fernseher, die dank Hyperion auf einem Raspberry Pi* mich in den Genuss von Philips Ambilight kommen lassen. Eine Demo davon gibt’s zum Beispiel hier.

Nun steht seit kurzem auch ein Echo Dot* auf meinem Wohnzimmertisch, und ich habe natürlich direkt geschaut, welche Geräte man noch mit Alexa steuern kann, die nicht im Standardrepertoire enthalten sind.

Der „normale“ Weg über AVS, bei dem ich extern einen Dienst mit SSL-Zertifikat usw. hosten muss, kam für mich erstmal nicht in Frage. Viel besser fand ich den Ansatz der ha-bridge. Diese emuliert eine Bridge für Philips-Hue-Geräte für Alexa und lässt einen für diese beliebige Aktionen festlegen. In Kombination mit hyperion-remote, das netterweise direkt mit Hyperion ausgeliefert wird, lässt sich das ganze sehr einfach mit Alexa steuern:

  1. ha-bridge downloaden und starten (Wichtig: Java 1.8. Wenn ihr kein Google Home habt, nehmt einen Port > 1024, damit ihr keine Root-Rechte braucht)
  2. Shellscript erzeugen, das sich via SSH auf dem Computer einloggt, auf dem Hyperion läuft und mit hyperion-remote die gewünschte Farbe/Effekt einstellt. Beispiel

     
  3. Gerät in ha-bridge anlegen, das das Skript beim gewünschten Event aufruft

 

 

DDanach muss man Alexa nur noch sagen, dass sie neue Geräte suchen soll, und nach ein paar Sekunden sollte Alexa in der Lage sein:

5. Februar 2017
von Sören Müller
8 Kommentare

Elgato Avea mit Siri & Homekit steuern

Nachdem ich hier recht abenteuerlich beschrieben habe, wie man die Avea von Elgato* an IFTTT anbinden kann, habe ich immer wieder Ausschau nach neuen Möglichkeiten gehalten. Die Lösung mit der App war sehr langsam, unzuverlässig und stromfressend.

Da mein ursprüngliches Ziel immer die Anbindung an Siri war, hatte ich schon länger ein Auge auf Homebridge geworfen, eine Möglichkeit, Geräte in HomeKit einzubinden, die nicht mit HomeKit kompatibel sind.

Und siehe da, vor ein paar Wochen hat jemand aus einer sehe rudimentären Implementierung des Avea Protokolls auf node Basis sich daran gemacht, daraus ein Plugin für HAP-NodeJS zu schreiben, das Tool, was die Basis für das etwas weiter entwickelte Homebridge ist. Da man beide Dienste parallel laufen lassen kann, war das aber kein Problem.

Da die genaue Installation je nach System sehr unterschiedlich sein kann, gehe ich im Folgenden nur auf die grundlegenden Schritte ein:

  1. Node.js installieren
  2. HAP-NodeJS installieren
  3. avea_node Modul für Node.js installieren
  4. Accessory für HAP-NodeJS installieren

Es gibt eine Datei, die nur mit einer Birne arbeitet, dort muss nur der Name angepasst werden und los geht’s! Das andere Beispiel ist für den Betrieb mit mehreren Birnen; da ich nur eine habe, habe ich das nicht getestet. Das Wiki dort ist eine gute Anlaufstelle für mehr Details und häufige Probleme!

Diese Lösung ist deutlich schneller und zuverlässiger als die erste. Außerdem kann ich mit Siri nun auch direkt die Helligkeit und Farbe meiner Avea steuern! Sogar die Einbindung in Szenen und die Nutzung von Auslösern ist möglich; ich nutze z.B. einen Amazon Dash Button* in Kombination mit Homebridge um die Birne auch ohne Siri ein- und ausschalten zu können.

So sieht das Ganze dann in der iOS 10 Home App aus. Da meine Birne in einer IKEA PS 2014 steckt heißt sie Todesstern. Die Szene „Angriffsmodus“ schaltet die Avea auf rot 😉

  

25. März 2016
von Sören Müller
1 Kommentar

Elgato Avea mit IFTTT steuern

Die Avea Bulb von Elgato* war vor ein paar Jahren mein erstes Smart Home Gerät. Smart ist leider ein bisschen übertrieben, denn wirklich smart ist sie nicht. Über die iOS App oder eine Apple Watch lässt sich die Glühbirne ein- und ausschalten und verschiedene Farben/Szenen anzeigen; Automatisiertes steuern mit z.B. HomeKit oder Siri wird auf einer extra dafür eingerichteten Supportseite ausgeschlossen.

Ohne ein Reverse Engineering der iOS App wäre es vermutlich auch dabei geblieben, aber Elgato hat nach guten 2 Jahren eine App für Android nachgereicht. Ich hatte gehofft eventuell direkt die eine Aktivität der App steuern zu können, aber das geht scheinbar nicht. Nach einer kurzen Suche bin allerdings auf eine andere App gestoßen und möchte in diesem Blogpost meinen Proof of Concept für die Steuerung für Avea mit IFTTT vorstellen

Weiterlesen →

30. Juli 2013
von Sören Müller
2 Kommentare

MacBook Air/Pro mit SSD sicher löschen

Nachdem ich mein MacBook Air an Apple zurückschicken muss weil eine Ecke etwas in der Luft hing und dadurch nervige Geräusche verursacht hat, hab ich überlegt wie man eigentlich vorgeht wenn man ein MacBook mit SSD an der Hersteller zurückschickt oder verkauft. Eine einfache Wiederherstellung kam wegen den ganzen Passwörtern und Windows 8.1 Bootcamp Tests nicht in Frage. Ich beziehe mich in dieser Anleitung auf das MacBook Air 2013, allerdings wird das Verfahren wahrscheinlich auf allen Geräten mit SSDs von Apple funktionieren. Aufgrund der Funktionsweise von SSDs braucht man die Platte nicht mehr zig-mal mit Nullen und Einsen überschreiben, dafür gibt es den sogenannten „Secure-Erase“, dabei wird die SSD in Ursprungszustand gebracht. Dazu darf die SSD logischerweise nicht gemountet sein, also fix Ubuntu auf nen USB-Stick und los geht’s:

  1. Nach dem Boot der Live-CD befindet sich die SSD zur Sicherheit in einem „freezed“ Status, den müssen wir erstmal aufheben. Dafür wählen wir einfach die Suspend-Funktion von Ubuntu und fahren den Rechner dann mit dem Powebutton wieder hoch. 
  2. Mit dem Befehl

    können wir überprüfen ob alles bereit ist. Wenn die Ausgabe den folgenden Screenshot gleicht hat alles geklappt: Screenshot from 2013-07-30 21_10_00 Wichtig ist vor allem die Zeile „not frozen“
  3. Als nächstes müssen wir ein Passwort vergeben. Da dieses Passwort sowieso im nächsten Schritt wieder gelöscht ist, ist es egal was ihr nehmt. Ich habe mich für „patty“ entschieden: 
  4. Man könnte jetzt nochmal kurz via

    schauen ob die Zeile unter „supported“ jetzt „enabled“ anstatt „not enabled“ anzeigt. Screenshot from 2013-07-30 21_10_34
  5. Jetzt geht’s ans eingemachte. Mit

    werden alle Blöcke der SSD vom Controller gelöscht. Es dauert bei meiner 256 GB SSD ca 30 Sekunden, dann ist alles weg. Screenshot from 2013-07-30 21_12_19
  6. Mit

    kann man sich nochmals vergewissern das alles weg ist. Unter „supported“ sollte jetzt wieder „not enabled“ stehen. Screenshot from 2013-07-30 21_12_36

Wenn man das MacBook Air jetzt einschaltet scheint es verwirrt zu sein; Zumindest ist es sicher bereit zur Weitergabe 😉 Verwirrtes MacBook Air Quelle: wiki.ubuntuusers.de