Wie im letzten Absatz meines Artikels zum DIY WiFi Environment Sensor erwähnt, war eines meiner Ziele herauszufinden, ob es sich lohnt zu lüften oder nicht. Um das zu erreichen, habe ich mir mittlerweile eine einfache App geschrieben, die mir genau das sagt. So konnte ich auch endlich mal etwas "sinnvolles" coden, um mich ein bisschen in Swift einzuarbeiten.

Die App liest beim Starten die Temperatur und relative Luftfeuchtigkeit meines Sensors drinnen (besagter WiFi Environment Sensor) und meines Sensors draußen (ein Elgato Eve Degree) aus. Diese Werte werden dann wie nachfolgend beschrieben verglichen, um zu einer Lüftungsempfehlung zu kommen. Lüftungsempfehlung heißt dabei, dass man die Luftfeuchtigkeit drinnen durch öffnen des Fensters senken kann. Eine einfacher Vergleich der relativen Luftfeuchtigkeit reicht hier natürlich nicht aus, da diese von der jeweiligen Temperatur abhängig ist.

Zuerst wird der Sättigungsdampfdruck in hPa mit Hilfe der Magnus-Formel für drinnen und draußen berechnet:

indoorSaturationVaporPressure = 6.112 * exp((17.62 * indoorTemperatureInC) / (243.12 + indoorTemperatureInC))
outdoorSaturationVaporPressure = 6.112 * exp((17.62 * outdoorTemperatureInC) / (243.12 + outdoorTemperatureInC))

Als nächstes wird der eigentliche Dampfdruck auf Basis der aktuellen Luftfeuchtigkeit ermittelt:

indoorVaporPressure = indoorSaturationVaporPressure / 100 * indoorHumidity
outdoorVaporPressure = outdoorSaturationVaporPressure / 100 * outdoorHumidity

Mit dem eigentlichen Dampfdruck kann nun der Wasserdampfgehalt, also die absolute Menge von Feuchtigkeit in der Luft in g/m³, errechnet werden:

indoorVaporAmount = (indoorVaporPressure / (461.5 * (273.15 + indoorTemperatureInC))) * 100000
outdoorVaporAmount = (outdoorVaporPressure / (461.5 * (273.15 + indoorTemperatureInC))) * 100000

Der Wasserdampfgehalt drinnen und draußen lässt sich abschließend wie folgt als Abweichung in Prozent in Relation setzen:

differenceVaporAmountInPercent = indoorVaporAmount * 100 / outdoorVaporAmount - 100

Meine App empfiehlt eine Lüftung, wenn der Unterschied mehr als 10% beträgt, denn nur dann lohnt es sich wirklich und sieht im Ergebnis wie folgt aus.

Neben der reduzierten Anzeige, ob sich das Lüften lohnt, lassen sich in der App mit einem einfachen Tap auch noch diverse Details abrufen, z.B die oben angesprochenen Werte oder der Taupunkt.

Wenn eine solche App nicht nur für mich interessant ist, lasst es mich wissen. Um den Code zu veröffentlichen, müsste ich den noch aufräumen und die Sensoren, die vergleichen werden sollen, konfigurierbar machen. Aktuell sind die Sensoren für mein spezielles Setup direkt im Quellcode hinterlegt.

Es gibt einige Räume im Haus, deren Temperatur und Luftfeuchtigkeit ich gerne überwachen möchte. Im Wohnzimmer habe ich dazu ein Elgato Eve Room stehen aber das für viele Räume anzuschaffen ist mir erstens zu teuer und zweitens komme ich mit Bluetooth LE nicht durch die Decken. Mehrere HomeKit-Hubs aufzustellen (bspw. AppleTV) ist irgendwie auch keine Lösung und Elgato kommt leider auch nicht mit einem angekündigten Bluetooth Range Extender um die Ecke (angeblich da Apple das nicht freigibt) aber das wäre ingesamt vermutlich auch unbezahlbar.

Was bleibt? DIY! Lötkolben raus, IDE auf und einen Sensor Marke Eigenbau selber basteln.

Die Hardware

Nach ein bisschen Recherche bin ich als Sensor auf den Bosch BME280 gestoßen, der Temperatur, Luftfeuchtigkeit und Luftdruck messen kann. Den Sensor gibt es bspw. bei AliExpress für um die 3 € auf einem Breakout Board.

Da die Sensordaten natürlich auch irgendwie per HomeKit verfügbar sein sollen, gab es dazu noch ein NodeMCU, ebenfalls von AliExpress für ca. 2,50 €. NodeMCU ist ein Entwicklungsboard, das einen ESP8266 Chip zur Verfügung stellt und damit WiFi / WLAN Applikationen sehr einfach zu bauen und zu programmieren macht.

Nach dem Anlöten von vier Pins an das BME280 Breakout Board kann man die beiden Hardwarekomponenten einfach nach folgendem Muster mit Jumper-Kabeln verbinden:

NodeMCU | BME280
3V      | VIN
G       | GND
D3      | SCL
D4      | SDA

Zusätzlich habe ich noch den D8 Pin des NodeMCU mit RST Pin des NodeMCU verbunden, um die Deep Sleep Funktionalität des Boards zu nutzen. Die Idee ist hier, dass das Board nicht permanent läuft und Strom konsumiert, sondern nach einer Messung für einen definierten Zeitraum einschläft und danach eine neue Messung startet. Durch die so erzielte Stromeinsparung könnte man den Sensor später auch mit einer Batterie betreiben aber das habe ich in diesem Projekt nicht umgesetzt.

Die Software

Bei der Software gibt es drei Komponenten, die ich nachfolgend beschreibe. Zum einen die Firmware für den ESP8266 Chip, dann einen Webservice zum speichern und verwalten der Sensordaten und zu guter letzt ein Plugin für Homebridge, um den Sensor in HomeKit verfügbar zu machen. Den Sourcecode für alle drei Komponenten findet ihr in einem GitHub Repository.

Firmware

Die Firmware für den ESP8266 Chip habe ich mit der Arduino IDE entwickelt. Dazu braucht es neben der IDE selbst noch den ESP8266 Arduino Core, der die Unterstützung des Chips bereitstellt. Zusätzlich gibt es auch Bibliotheken, um mit dem BME280 Sensor zu kommunizieren. Hierbei habe ich mich für den Adafruit Unified Sensor Driver und die Adafruit BME280 Library entschieden. Wie man die einzelnen Bibliotheken einbindet ist auf den jeweiligen Projektseiten gut beschrieben.

Für mein Board musste ich die I2C Adresse des BME280 noch anpassen. Die Adafruit Breakout Boards nutzen hier wohl standardmäßig die Adresse 0x77, meine Boards aus dem Reich der Mitte nutzen aber die Adresse 0x76. Das lässt sich aber einfach im Header-File Adafruit_BME280.h der Adafruit BME280 Library anpassen, indem man dort nach der Zeile #define BME280_ADDRESS (0x77) sucht und entsprechend anpasst (sofern nötig).

Um das Board per USB anzusprechen und die Firmware drauf zu laden, braucht es noch einen USB to Serial Driver. Bei mir unter macOS hat dieser Treiber sich als funktionierend herausgestellt, wie es auf anderen Betriebssystemen aussieht kann ich leider nicht sagen.

Damit ist alles vorbereitet und es kann an die Programmierung der ESP8266 Firmware gehen. Der komplette Sourcecode findet sich auf GitHub, ich möchte aber noch mal kurz auf den Ablauf eingehen:

Wenn das NodeMCU Board Strom bekommt, wird die setup() Methode aufgerufen. Darin wird zuerst eine Verbindung zum WiFi aufgebaut, die SSID sowie das Passwort sind dabei konfigurierbar. Als nächstes wird die Verfügbarkeit des BME280 geprüft und der Sensor mit einigen Parametern initialisiert. Man muss diese Konfiguration nicht zwingend vornehmen, da der Sensor auch ohne misst, für meinen Anwendungsfall haben sich aber die im Code hinterlegten Sampling-Raten als die zuverlässigsten und genauesten herausgestellt. Nachdem im nächsten Schritt eine Messung von Temperatur (t), Luftfeuchtigkeit (h) und Luftdruck (p) vorgenommen wird, werden die ermittelten Werte an den Webservice (siehe unten) geschickt. Zu guter Letzt wird das Board in den Tiefschlaf versetzt und wacht dann nach der festgelegten Zeit wieder auf und das Ganze beginnt von vorne.

Webservice

Die ermittelten Sensordaten der schönen neuen Hardware müssen natürlich auch irgendwo hin. Insbesondere, da ich mich dafür entschieden habe die Hardware nicht permanent Strom ziehen zu lassen sondern zwischendurch in den Tiefschlaf zu versetzen, braucht es natürlich eine Persistenzschicht. Darüber hinaus möchte ich später auch gerne eine Historie der Sensordaten abrufen können.

Um das zu realisieren, habe ich einen kleinen Webservice in Node.js geschrieben, der die Sensordaten entgegennimmt und in einer SQLite Datenbank speichert. In meinem Szenario läuft der Webservice auf einem Raspberry Pi, der auch schon meine bestehende Hombridge Installation beherbergt. Der Webservice stellt dabei REST Endpunkte zum Hinzufügen, Lesen und Löschen von Sensordaten zur Verfügung. Der komplette Sourcecode sowie eine API Beschreibung findet sich im entsprechenden GitHub Repository.

Homebridge Plugin

Um die Sensordaten in HomeKit verfügbar zu machen fehlt noch ein Plugin für Homebridge. Homebridge emuliert die HomeKit API und kann damit auch Geräte wie diesen Sensor mit entsprechender Funktionalität ausstatten und so bspw. auch über Siri steuerbar machen. Details zu Homebridge und zur Installation gibt es an anderer Stelle genug, ich gehe hier also nur auf das selbstgeschriebene Plugin ein.

Was das Plugin im Endeffekt macht, ist HomeKit ein neues Accessory zur Verfügung zu stellen, das die Services bzw. Charakteristiken Temperatur (Temperature) und Luftfeuchtigkeit (Humidity) anbietet. Da Luftdruck (Air Pressure) leider noch keine offizielle HomeKit Charakteristik ist, fällt der Wert leider erstmal unter den Tisch. Die Werte werden vom Plugin dann per GET Request vom Webservice (siehe oben) abgeholt und können in HomeKit Apps angezeigt oder per Siri abgefragt werden.

Derzeit wird nur der aktuellste Sensorwert ausgegeben, die Eve App von Elgato kann aber bspw. auch historische Daten anzeigen und das ist eine meiner nächsten Verbesserungsideen. Mit fakegato-history gibt es bereits ein Projekt, welches die Daten vermutlich entsprechend aufbereiten könnte. Teile des Projektes basieren dabei auch auf meinen Reverse Engineering Aktivitäten in dem Umfeld.

Das Gehäuse

Es hat zwar auch einen gewissen Charme, wenn überall im Haus Platinen zu sehen sind, die Meinung teilt aber nicht jede(r). Zum Glück gibt es ja freundliche Kollegen, die einen 3D-Drucker besitzen und sich bereit erklären ein Gehäuse zu drucken. Nachdem ich mit Onshape also ein entsprechendes CAD-Model designed und verschickt hatte, konnte ich den Sensor bereits am nächsten Tag in ein schickes Gehäuse stecken. Danke, Manuel!

Wenn ich weitere Sensoren dieser Art baue, werde ich das CAD Model wohl noch mal überarbeiten, da es an einigen Ecken ein bisschen knapp bemessen war. Gepasst hat es aber auch so irgendwie.

Das Ergebnis

Wenn man die Arbeitszeit (Basteln, coden, CAD Model bauen, etc.) mal aussen vor lässt, habe ich mir mit diesem Projekt für ein paar wenige Euro einen sehr gut funktionierenden Raumklima-Sensor gebaut. Ein freundliches "Hey Siri, wie ist die Luftfeuchtigkeit im Keller?" sagt mir damit ab sofort, ob ich dort besser mal lüften sollte. In Kombination mit einem Außensensor lässt sich damit natürlich auch herausfinden, ob das wirklich sinnvoll ist oder ob es draußen so feucht ist, dass das Lüften eher kontraproduktiv wäre.

Im Wohnzimmer habe ich einen Schrank mit Milchglastüren, die ich von hinten beleuchten wollte. Das sieht meiner Meinung nach nicht nur schick aus sondern liefert auch schönes, indirektes Licht. Da ich schon ein paar farbige Philips Hue Lampen habe, sollte die Farbe der Milchglastüren natürlich auch zu wechseln sein, um im Zusammenspiel ein durchgehendes Farbambiente zu haben. Darüber hinaus muss alles mit Apple HomeKit kompatibel sein, denn damit realisiere ich derzeit meine Heimautomatisierung.

Für die Beleuchtung LED Strips zu nutzen war ein no-brainer aber als ich mir bspw. die Preise für die Philips Hue Lightstrips angeschaut habe, musste ich schon ein bisschen schlucken: Um die 75 € für einen 2 Meter langen Strip war irgendwie nicht das, was ich mir vorgestellt habe. Nach einigen Nachforschungen bin ich zu dem Entschluss gekommen, dass ich mir einfach ein paar günstige Einzelteile bestelle und das ganze selber baue. Es war eh mal wieder an der Zeit für ein kleines DIY Projekt. Dann mal los mit dem Gebastel…

Einkaufsliste

Als allererstes braucht man natürlich einen LED Strip und dabei habe ich mir für einen von AliExpress entschieden. Der hat einige gute Reviews, leuchtet in schönen RGB Farben und kostete nur 5,28 € für 5 Meter. Das ist zwar wesentlich länger als das, was ich für den Schrank gebraucht habe aber bei dem Preis ist das auch egal.

Als nächstes einen LED Controller. Der muss natürlich WiFi sprechen, damit ich ihn später über Homebridge in meine HomeKit Installation einfügen kann. Auch hier habe ich etwas bei AliExpress gefunden, das meine Anforderungen erfüllt und für 10,74 € zu haben war.

Nummer Drei auf der Einkaufsliste ist ein Netzteil, um Controller und LED Strip mit Strom zu versorgen. Ich habe mich am Ende für ein LEICKE Netzteil entschieden. Das ist zwar mit 14,99 € das teuerste Teil in meiner Installation aber ich hatte schon gute Erfahrungen mit diesem Netzteil. An dieser Stelle wird man vermutlich problemlos noch ein paar Euro sparen können.

Zu guter letzte natürlich noch ein paar 4 pin RGB Kabel/Drähte wie diese hier für ca. 4,50 € und ein paar Verbindungs-Clips für 1,50 €, da ich nicht direkt auf die LED Strips löten wollte.

Alles in allem macht das also einen 5 Meter langen, über WiFi steuerbaren RGB LED Strip für 37,01 €. Das ist so schon ganz nett aber ich bin mir fast sicher, dass man an der einen oder anderen Stelle noch sparen und vielleicht sogar die 30 € Marke knacken kann.

Man braucht auch noch einen Raspberry Pi oder etwas ähnliches, um Homebridge laufen zu lassen. Homebridge emuliert die HomeKit API und kann damit auch Geräte, die von Hause aus kein HomeKit unterstützen, mit entsprechender Funktionalität ausstatten und so auch über Siri steuerbar machen. Diesen Kostenblock habe ich mal bewusst weggelassen, denn ein entsprechendes Setup ist bei mir bereits vorhanden.

Hardware Zusammenbau

Als erstes habe ich den LED Controller mit dem Netzteil verbunden. Dazu habe ich den Stecker vom Netzteil abgeschnitten und den damit freigelegten Positiv- sowie Negativ-Draht an das Input V+ respektive Input V- des Controllers angeschlossen. Wenn man unsicher ist, welcher Draht positiv und welcher Negativ ist, nutzt man am Besten ein Multimeter, um sicher zu gehen. Das Netzteil und der WiFi Controller liegen in der finalen Installation außer Sicht auf dem Schrank, dort war auch eine Steckdose verfügbar war.

Um nun vom Controller auf den LED Strip zu kommen, schließt man die entsprechenden Drähte an R, G, B und V+ des Controllers an und verbindet diese mit den entsprechenden Kontakten auf dem LED Strip. Für den Kontakt zum LED Strip habe ich mir, wie oben schon kurz angesprochen, Connector Clips besorgt und diese mit den Drähten verlötet. Es gibt zwar fertige Kabel mit Connector Clips aber da ich die Kabel auf die perfekte Länge für meine Installation bringen wollte, habe ich mich dazu entscheiden die selbst zu machen.

Beim Löten des ersten Connector Clips habe ich direkt gemerkt, dass ich seit Ewigkeiten keinen Lötkolben mehr in der Hand hatte (weit über 10 Jahre) und der, den ich habe, auch nicht gerade der Beste ist. Die ersten Lötstellen gewinnen also definitiv keinen Schönheitspreis aber erstens wurde es von Lötstelle zu Lötstelle besser und zweitens funktioniert es und das ist doch die Hauptsache.

Den ersten Connector Clip habe ich dann auch direkt dazu benutzt, um den Controller und den LED Strip zu testen. Dazu gibt es im App Store eine spezielle App für den Controller namens Magic Home WiFi, zum ganzen Softwareteil komme ich aber später noch mal im Detail.

Und siehe da, es wurde Licht!

Als nächstes habe ich dann die Kabel vorbereitet, in dem ich sie auf die richtige Länge gebracht, wo nötig mit Connector Clips versehen und im Schrank verlegt habe. Fehlten nur noch die LED Strips, die ich auch entsprechend gekürzt, mit Isolierklebeband in den Schrank geklebt und zum Abschluss mit den verlegten Kabeln verbunden habe. Fertig!

Verbindung mit HomeKit

Jetzt, wo die Hardware zusammengestöpselt und in den Schrank eingebaut ist, ging es an die Softwareseite.

Wie oben schon angesprochen, gibt es mit Magic Home WiFi eine App, mit der sich der eingesetzte WiFi Controller bedienen lässt. Die ist aber erstens nicht gut und zweitens ist der Plan, den Strip in das bestehende HomeKit Setup einzubinden.

Zuallererst sollte der WiFi Controller also in das bestehende WiFi integriert werden. Zwar macht der Controller ein eigenes WiFi Netz auf, über das es auch mit der Magic Home App zu finden und steuern ist, aber ich brauche den Controller in meinem bestehenden Netz und musste ihn deshalb umkonfigurieren. Man kann sich dazu einfach mit WiFi verbinden, das automatisch vom Controller aufgemacht wird, und im Browser eine Weboberfläche aufrufen die zur Konfiguration zur Verfügung gestellt wird. Die Zugangsdaten hierzu sind Benutzername admin und Passwort nimda. Kommt keiner drauf.

Auf dem Reiter "Work Mode" schaltet man den Controller dann in den Modus "STA mode" und kann daraufhin auf dem Reiter "STA Setting" die WiFi spezifischen Einstellungen hinterlegen, also das gewünschte WiFi auswählen, das Passwort hinterlegen, Adressbezug durch DHCP einstellen und so weiter. Nach einem Neustart des Controllers funktionierte das auch direkt wunderbar und ich habe nur noch in meiner Firewall dafür gesorgt, dass der Controller eine feste IP bekommt und nicht nach draußen, ins Internet, darf. Wer weiß wohin das Gerät sonst so telefonieren möchte…

Zur Verbindung des ganzen mit HomeKit, um den LED Strip bspw. auch per Siri steuern zu können, nutze ich Homebridge auf einem Raspberry Pi. Details zu Homebridge und zur Installation spare ich mir hier, denn dazu gibt es bereits an anderen Stellen mehr als genug Informationen. Worauf ich jedoch kurz eingehen möchte ist das Homebridge Plugin, das man für jedes konkrete Gerät benötigt. Es gibt unfassbar viele Plugins für alles mögliche, für den hier eingesetzten LED Controller habe ich mich für das Magic Home Plugin entschieden.

Um das ganze zu nutzen wird also flugs das Plugin installiert, in der config.json der Homebridge der Controller wie folgt als Accessory eingetragen und die Homebridge neu gestartet.

"accessories": [
    {
        "accessory": "MagicHome",
        "name": "Glasschrank",
        "ip": "192.168.1.40",
        "setup": "RGBWW",
        "purewhite": false
    }
]

"Hey Siri, mach den Glasschrank lila"

Das Endergebnis kann sich meiner Meinung nach wirklich sehen lassen. Ich zeige hier mal nur die oberen beiden Schrankfächer. Für einen größeren Bildausschnitt hätte ich vorher noch die Küche im Hintergrund aufräumen müssen.

Die Farbtöne des LED Strips weichen leider leicht von den Philips Hue Lampen ab. Das ist bei einigen Farben deutlich, bei anderen kaum wahrnehmbar. Im Großen und Ganzen reicht es für mich persönlich aber aus und passt ganz gut zusammen.

Ich plane aktuell noch das gleiche Prinzip zu nutzen, um eine Gardinenleiste auf der anderen Seite des Raumes, zum Garten hin, zu beleuchten. Unterbodenbeleuchtung für die Kinderbetten könnte man auch noch machen. Mal schauen...

I got myself an Elgato Eve Energy power sensor and switch to get a feeling for HomeKit in general and how I can make use of it.

The hardware itself looks clean and stylish and the installation is a breeze: You simply plug it in, fire up the Eve app and pair it. After about a minute of setting things up I was able to switch the outlet on and off and get statistics about the current power consumption in W and total power consumption in kWh.

After another minute of playing around I was also able to talk to the outlet using Siri, how cool is that? Asking Siri "Is the living room outlet turned on?" resulted in her answer "Your outlet is turned on", telling her “Turn off the oulet in the laundry room” switched the outlet off. Awesome.

Talking to my outlets and getting statistics is nice and all but what I really want is setting up triggers and do stuff depending on each other like sending notifications once the washing machine is done. I knew that the whole HomeKit framework is not yet where I want it to be (e.g. apps working with your accessories need to be running in the foreground) and the Eve accessories aren’t there es well (e.g. no triggers) but as already said, first of all I want to get a feeling for it.

To dive in deeper I fired up Xcode and played around with the HomeKit API, looking at what the outlet exposes to see where it takes me… Oh my, what a letdown! HomeKit has the concept of characteristics that tell you about the different aspects of an accessory. This is supposed to be standardized so all HomeKit apps can communicate with all kind of HomeKit hardware but Elgato does not seem to be interested in playing along: Yes, the characteristics are available but there is not the slightest bit of information about what the individual characteristics are representing and neither about their format.

Asking the Elgato support about a documentation of characteristics resulted in a short "Nope, documentation is not available". Thank you!

After being annoyed for a couple of hours I decided doing some reverse engineering to see what characteristics Eve Energy exposes and to make some sense of it. To do that I tried several test scenarios and dumped the value of all characteristics as well as the output of the Eve app in these.

Now it was simply a task of comparing characteristics, guessing formats and some calculations. To cut a long story short I summarized what I learned about Eve Energy in a Gist on GitHub. I haven’t made sense of everything up to now but it should be a good start. I try updating the Gist as I learn more and am open for comments and additions.

Knowing the filmography of Christopher Nolan - which includes movies like Memento, The Dark Knight and Inception amongst others - I expected quite a lot from this flick. Not too much, apparently, as Interstellar is absolutely epic. Right from the start I was totally immersed in it and only realized its runtime of 167 minutes after looking at my watch at 1:45 am, when the credits were rolling.

The more time I spend thinking about Interstellar the more it grows on me and with every thought it's getting clearer that the movie is excellent in many regards: The performance by the whole cast is compelling, with the the main characters played by Matthew McConaughey and Anne Hathaway as well as Mackenzie Foy standing out, the images are beautiful and the score is absolutely fabulous, Hans Zimmer outdid himself once again. Even the science seems to be pretty spot on, at least according to Neil deGrasse Tyson whom I trust on this. I even ordered a copy of The Science of Interstellar today to recap the science part.

To sum it up, Interstellar is a beautiful movie taking you on a trip through space and time you won't forget.