oliverlorenz.com

[feed] [twitter] [xing] [linkedin] [github]

Dieser Blog ist nicht kaputt.

Archive Posts

2016-01-01

HVV-Tweets Microserviced

Über Silvester konnte ich einem Projekt nachkommen, welches schon ewig in meiner Schublade lag. Die Code4Germany-Jungs haben mal zu mir gesagt, dass man sich bei Projekten vor allem über Dinge Gedanken machen soll, die einen echten Mehrwert für “normale” Menschen bieten. Und ich glaube, ich bin genau über so einen Fall gestolpert.

Motivation

Ich habe die HVV (Den Hamburger Nahverkehr) auf Twitter abonniert um immer über evtl. Zwischenfälle auf meinen üblichen Strecken infomiert zu sein. Twittert die HVV über irgendetwas, bekomme ich aktiv eine Popup-Meldung auf meinem Handy zu sehen. Ich bin sehr dankbar über diesen Service, aber eine Sache störte mich doch.

Wie viele Leute die morgens und abends zur Arbeit und zurück kommen wollen, interessieren mich nur wenige Linien. Leider kann man dem offiziellen Twitter-Client nicht beibringen, nur auf bestimmte Schlüsselworte zu reagieren. So werde ich bei der Arbeit immer wieder von Meldungen aus meiner Arbeit gerissen, die völlig irrelevant für mich sind.

Trotzdem sind die für mich relevanten Meldungen Gold wert, wenn es darauf ankommt. Die Quelle der Information ist also die Richtige, nur ist das Paket der Informationen zu groß geschnitten. Es sollte eine Möglichkeit geschaffen werden, dass ich als Nutzer wählen kann, was mich wirklich interessiert. Dabei ist eine Lösung entstanden, die glücklicherweise nicht nur in meinem Szenario funktioniert.

Die Lösung

Microservice them all!

Ich habe mittels NodeRed einige ausgewählte Twitter-Accounts abonniert, die mir als Datenquelle für Meldungen dienen.

NodeRed Configuration

Diese analysiere ich auf bestimmte Schlüsselwörter und retweete diese mit Linien-spezifischen Accounts, die ich angelegt habe. Für jede Linie eine. Hier die vollständige Liste der derzeit existierenden Accounts:

Nun ist es also möglich, jede Hamburger U- und S-Bahn-Linie einzeln auf Twitter zu abonnieren um sich damit ganz gezielt auf dem Laufenden zu halten. Unnütze Informationsflut Adé. Ich kann Mircoservices so langsam nicht mehr hören. Trotzdem bestätigt sich auch hier mal wieder, wie nützlich es ist, kleine Komponenten zu haben, die man einfach zusammenstecken kann.

Dazu muss ich noch sagen, dass der “Service” gerade erst live gegangen ist. Es ist nicht auszuschließen, dass sich der eine oder andere Bot noch merkwürdig verhält.

Mögliche Erweiterung und Feedback

Ich werde jetzt erstmal beobachten, wie das Ganze anläuft. Sollte es Bedarf geben, könnte man den Service auch auf Busse, Regionalbahnen und Fähren ausweiten. Außerdem könnte man auch gezielt auf Haltestellen reagieren und die Meldungen auf entsprechende Accounts verteilen.

Ich hoffe, ich konnte mit diesem Projekt einen kleinen Beitrag leisten, den Alltag in Hamburg wieder ein bisschen angenehmer zu machen. Ich freue mich sehr über Feedback und Anregungen :)

Weitere Beiträge zu den Hamburg-Bots

Hamburg Bots - Teil 2

Es ist etwas ruhiger um die Bots geworden. Aber nur nach außen. Denn ich habe fast jeden Tag an dem Projekt gearbeitet, um das Projekt voran zu bringen und den Service näher Richtung Vervollständigung zu treiben.

Aktueller Stand

Zuerst die wichtigste Nachricht: Neben den U- und S-Bahnen habe nun auch Bots für alle Regionalbahnen im Bereich Hamburg angelegt, was verdammt viel Arbeit war. Euch stehen jetzt also 19 weitere Bots zur Verfügung, die ihr nach euren Bedürfnissen abonnieren könnt. Die vollständige Liste könnt ihr hier einsehen.

Liste aller Bots

Technisch ist hinter den Kulissen ebenfalls eine Menge passiert. Während die erste Version noch auf meinem kleinen Raspberry-Pi-Cluster lief, bin ich mittlerweile in die Cloud umgezogen, um die Ausfallsicherheit etwas zu erhöhen und die nötige Leistung für Node-Red bereitstellen zu können. Ich habe dabei auf IBM Bluemix Cloud gesetzt, da IBM an der Entwicklung von Node-Red aktiv beteiligt ist und One-Click-Installationen anbietet, was mir auch etwas Last von den Schultern nimmt. Außerdem läuft die Instanz zumindest in Europa.

Neben der Infrastruktur ist nicht nur die Anzahl der Bots gewachsen. Auch die Komplexität und der Aufwand hinter den Anforderungen steigen hinter jedem neuen Bot. Dazu gehört:

Komplexer sind auch die Anforderungen und die neu geplanten Features geworden. Euch möchte ich natürlich nur relevante Informationen über die Bots ausleiten. Deswegen habe ich das Kontext-Erkennungs-System hinter den Bots auf die nächste Ebene gehoben. Das hat aktuell noch nicht den starken Output zu euch da draußen, versetzt mich aber in die Lage demnächst mehr Informationen aus meinen Quellen herauszuholen und Relationen erkennen zu können. Ziel ist es, noch feingranularer zu werden. Das heißt noch mehr Möglichkeiten für euch, explizit Informationen zu abonnieren, die euch interessieren.

Änderung der Namen

Ich habe während des Erstellens der Neuen Bots das Namensschma der Bots umgestellt. Die Accountnamen beginnen nun alle mit bot_hh* was die Möglichkeiten der Ausweitung von Microserviced-Daten etwas allgemeiner hält und die Bots namentlich besser gruppiert.

Twitter - Motor und Bremse zugleich

Vor allem Twitter hat den ganzen Prozess extrem verlangsamt. Nach einer gewissen Anzahl von angelegten Accounts fordert Twitter eine Telefonnummer zur Verifizierung an. Etwas intransparent ist aber der Mechanismus dahinter. Oft kommen die Verifizierungs-SMS nicht an, oder man wird einfach gesperrt, weil man zu viele ungültige Versuche gebraucht hat, seine Nummer zu verifizieren. Außerdem scheint es eine maximale Anzahl von Accounts zu geben, die einer Telefonnummer zugeordnet werden kann.

Ich habe, bedingt durch die frustgetränkten Zwangspausen versucht mehr über diesen Mechanismus und seinen Regeln herauszufinden. Leider erfolglos. Wenn jemand dazu nähere Informationen hat, wäre ich sehr dankbar, wenn er/sie sich in den Kommentaren dazu melden würde.

Was kommen könnte

Das Thema liegt mir trotz der genannten Schwierigkeiten am Herzen. Die erste Welle der Feature-Wünsche konnte ich mit dem Einführen der Regionalbahnen hoffentlich abarbeiten.

Mein Ziel ist es natürlich auch noch die Hamburger Buslinien abzubilden. Das sind aber wohl weit über hundert. Vom Zeitplan her möchte ich dazu aber noch keine Aussage machen. Vermutlich wird das auch nicht nur ein Rollout.

Auch nicht zu vernachlässigen ist der Faktor, dass ich mir immer wieder neue SIM-Karten zulegen muss, um die intransparenten Twitter-Sperren zu umgehen. Das geht nach und nach auch ins Geld ;)

Zwischen-Fazit und Feedback

Ich bin immer noch überrascht, dass den Bots trotz fehlender Werbung immer noch jeden Tag neue Leute folgen. Es motiviert mich natürlich unglaublich, euch mit meinem kleinen Serivce wirklich einen Mehrwert zu bieten und ich würde mich freuen, wenn ihr die Bots weiter verbreitet. Redet mit euren Freunden darüber, wenn die Bahn mal wieder zu spät kommt.

Zum Schluss möchte ich natürlich noch fragen, welche Features ihr euch als nächstes wünscht. Buslinien? Andere Öffentliche Verkehrsmittel? Interessieren euch Informationen zu einzelnen Haltestellen? Ist Twitter die richtige Platform? Was nervt euch und was findet ihr gut?

Weitere Beiträge zu den Hamburg-Bots

2016-03-29

Spartakiade 2016 - Review

Hach! Wie sehr habe ich mich auf die Spartakiade gefreut! Nicht nur wegen den tollen Workshops, sondern auch wegen den tollen Leuten, die ich letztes Jahr dort kennen gelernt habe. Nicht zuletzt, weil es sich als Tradition etabliert, meine ehemaligen Kollegen André Langer, David Jobst und Ronny Poller dort zu treffen und sich nicht aus den Augen zu verlieren.


Die Spartakiade hat sich im Vergleich zum letzten Jahr weiterentwickelt. Zum einen ist sie wohl wesentlich bekannter geworden, wenn man den Run auf die Tickets beobachtet hat. Ebenso das Rahmenprogramm, welches den Abend des ersten Tages unglaublich amüsant gemacht hat.

Olga Sheshukova hat sich zur Verfügung gestellt, Fotos von den Teilnehmern oder Gruppen zu machen. Eine tolle Idee. Ich bin auf die Ergebnisse gespannt! :)

Gregor Woiwode hat eine tolle Twitterwall erstellt, die uns über alle Happenings auf der Spartakiade auf dem laufendem hielt. Mein GitHub-Fork ist Dir sicher ;)

David Jobst, Ronny Poller und ich mit den Nerfguns Die Nerfguns waren eine tolle Idee! Ich hätte mir gewünscht, dass auch noch ein paar Andere über ihren Schatten springen und unserer kleinen Battle beigewohnt hätten.

Nerd Jeopardy Mein Persönliches Highlight war das Nerd Jeopardy. In verschiedenen Kategorien mussten nerdige Dinge erkannt werden. Egal ob bekannte Melodien, gespielt auf floppy Laufwerken, das Raten von Filmen in Form von Quellcode, oder das Erkennen von Bussystemen auf Mainboards in Form von Fotos - um nur Einiges zu nennen. Großes Kompliment an Jan Fellien und Torsten Weber.

Mit den Workshops waren die Teilnehmer über alle hinweg zufrieden. Die gewohnte Spartakiade Qualität. Ich persönlich bin dieses Jahr leider nicht zu 100% von den Workshops überzeugt.

Internet of Things, Coding Dojo / Code Retreat

Trainer: Christian Waha

Beschreibungstext des Workshops

Dieses Dojo ist ganztägig konzeptioniert. Code wird vom Sonnenaufgang bis zum Sonnenuntergang geschrieben. Das Thema? Es geht – natürlich – darum, testgetriebene Softwareentwicklung (TDD) zu üben. Diesmal mit Code Retreat und als „Schmankerl“ auch der Ansteuerung von Hardware.

Ein Code Retreat wäre zu einfach, nein es gibt auch eine Änderung bei der Hardware. Microsoft stellt für die Spartakiade extra Raspberry Pie’s 2 mit Windows 10 IoT / Arduino’s zur Verfügung. Zusätzlich stellt auch Intel mehrere Galileo Boards 2 Gen bereit.

Frei nach den „originalen“ Coding Dojo’s geht es bei diesem Zusammentreffen für die Lösung einer kleinen, aber herausfordernden Programmieraufgabe (Code Kata), auch um die Gleichstellung aller Teilnehmer, Aktivität im Dojo, respektvollen Umgang, eine optimistische Herangehensweise und eine zwanglose, lockere Atmosphäre. Oder kurz gesagt: Das Ziel & Ergebnis ist wie immer beim Dojo „Lernen & Lehren“ mit Spaß!

Quelle: spartakiade.org

Mein Review

Der Inhalt des Workshops war am ersten Tag nicht so, wie ich mir das vorgestellt habe. Meine Erwartungshaltung war zumindest eine kurze Einführung wie ich mit den Tools umzugehen habe. Vielleicht ein paar Links die mir das kleinteilige Zusammensuchen der Informationen in Blogs ect. gespart hätte.

Die Realität sah ein kurzes Brainstorming zu “Dingen die man umsetzen könnte” und das Verteilen der Hardware vor. Danach waren wir größtenteils auf uns allein gestellt. Das Team hat die Situation jedoch durch grundlegendes Wissen verschiedener Bereiche gut ausgeglichen, was für mich den Tag gerettet hat.

Während sich andere Teams an WLAN-gestützter Präsenserkennung abkämpften, haben wir einen sehr “Leanen” Ansatz gefahren und einen sensorbasierten Würfel programmiert. Einmal schütteln gleich würfeln sollte das Endresultat darstellen und dementsprechend oft aufblinken.

Da Niemand Erfahrung mit den Tools hatte und wir den Vormittag damit verbracht haben, auf Ladenbalken zu starren, haben wir klein angefangen:

Fazit: Die unzureichende Vorbereitung hat unser Team gut ausgeglichen. Der “Leane” Ansatz hat uns geholfen trotz der Hürden zu einem guten Ergebnis zu kommen und positiv aus dem Tag zu gehen. Entsprechendes Feedback haben wir dem Trainer bereits gegeben. Ich denke, in einer weiteren Iteration kann sich der Workshop in eine gute Richtung entwickeln.

Der Workshop-Tag wurde in einem YouTube Video zusammengefasst.

Maschinelles Lernen: Predictive Analytics for churn rate

Trainer: Olga Sheshukova

Beschreibungstext des Workshops

Stell dir vor, du hättest ein Unternehmen. Jedes Unternehmen hat Kunden und möchte diese solange wie es geht behalten. Predictive Analytics wird in letzter Zeit immer öfter dazu eingesetzt, die Abwanderungsquote (churn rate) vorherzusagen. So kann man aus einem Pool von Kunden genau diejenigen identifizieren, die in Zukunft „abspringen“ werden. Das Spannende daran ist, dass man mittels Marketing diese potentiellen „Abspringer“ kontaktieren und durch Rabatte oder andere Angebote als Kunden dennoch behalten kann.

Das Verfahren bei Predictive Analytics ist ein wenig wie ein „Blick in die Zukunft“ (die Lottozahlen gehen nicht vorherzusagen, der Rest schon): Eine Identifikation von potenziellen „Abspringern“ in der Zukunft auf der Basis der vorliegenden historischen Daten. Eingesetzte Werkzeuge sind Python und Bibliotheken für maschinelles Lernen.

Die Teilnehmer werden mittels „Hands-on“ kurz in die Datenanalyse eingeführt (Datenaufarbeitung, -säuberung, Metriken für Bewertung der Modellierung). Danach geht es direkt beispielhaft anhand eines Datensatzes mit der Modellierung, Auswertung und Vorhersagen für die Zukunft weiter. Auf das nie wieder ein Kunde verloren geht, den man hätte behalten können, wenn das einer nur gewusst hätte!

Quelle: spartakiade.org

Mein Review

Auf den zweiten Workshop-Tag habe ich mich sehr gefreut. Ich bin bei meinem aktuellen Arbeitgeber viel in Kontakt mit Sensordaten und wollte damit einen weiteren Baustein in meinem Wissensbaukasten rund im IoT beifügen.

Mangelnde Vorbereitung kann man der Trainerin nicht vorwerfen. Die Präsentation und das Wissen zum Thema war beeindruckend! Leider war ihr wohl aber nicht bewusst, dass wir durch die Bank weg wenig Erfahrung mit Python hatten. Das hat den Einstieg schwierig gemacht, denn es mussten die Sprache und die Thematik bezwungen werden. Auch hier wären ein paar kleine Code-Schnipsel hilfreich gewesen. Zumindest waren die Frameworks vorher bekannt, was uns schnell hat produktiv werden lassen.

Zum Anfang gab es etwas Theorie. Die war für mich auch bitter nötig, denn ich hatte noch nichts mit dem Thema zu tun. Zu behaupten, dass ich alles verstanden hätte, wäre aber gelogen ;)

Danach haben wir uns in 5 Gruppen aufgeteilt, die sich jeweils auf einen Algorithmus gestützt haben. Mit Hilfe dessen konnte jedes Team gewisse Vorhersagen auf Basis der Datensätze treffen.

Lars Kumbier hat ein öffentliches Doc erstellt, in dem wir Code-Schnipsel tauschen konnten. Super Idee! Das hat mir den Weg gezeigt ohne zu viel zu verraten. @Olga: Nimm das doch einfach mit in dein Workshop-Konzept auf. Das nimmt auch die Einsteiger gut mit :)

Wenn ich das verstanden habe, war das Olgas erster Workshop zu dem Thema. In bin mir sicher, dass es in der nächsten Version noch besser wird!

Fazit

Am Ende des Tages waren wir in der Lage, Models zu trainieren und auf weitere Datensätze anzuwenden. Dabei trat zu Tage, dass es sich immer um schwankende Wahrscheinlichkeiten handelt. Es bleibt immernoch dem Betrachter überlassen, was man damit macht.

Gesamtfazit

Ich hoffe meine Reviews klingen nicht zu negativ, denn auch wenn es Ecken und Kanten gab, habe ich auf den verschiedensten Ebenen wieder viel mitgenommen :)

Grundlegend kann man sagen, dass sich die Spartakiade von Jahr zu Jahr sehr positiv weiterentwickelt. Ich kann nur immer wieder sagen, dass es sich lohnt! Ihr begegnet tollen Menschen und lernt immer etwas dazu was euch in eurem Arbeitsalltag verborgen bliebt. Alleine deswegen lohnt es sich den sowieso schon geringen Preis zu investieren.

Solltet ihr über euren Arbeitgeber an Tickets kommen können, so unterstützt die #Spartakiade dabei dieses tolle Format weiter auszubauen indem ihr Sponsor werdet oder die Supporter-Tickets kauft.

Schon mal im Kalender notieren:

Der Termin für die nächste #Spartakiade steht schon fest. Vom 18. zum 19. März 2017 wird wieder Sport getrieben.  (via @Spartakiade_org)

2016-05-20

Flow-based Programming und IoT

Auch schon bevor ich beruflich in diesen Bereich gegangen bin, habe ich mich in Ansätzen mit dem Thema Flow-based Programming auseinandergesetzt, ohne dass es mir bewusst so war.

Wer aktuell mit mir Tech-Smalltalked wird auffallen, wie sehr ich ins Schwärmen komme, wenn das Gespräch in Richtung NodeRED geht. NodeRED wirbt mit dem Slogan

“Node-RED is a tool for wiring together hardware devices, APIs and online services in new and interesting ways.”

Diese “neuen und interessanten Wege” sind nicht nur das. Die optische Darstellung der Flows unterstützen zusätzlich das Prototyping von kleinen Projekten und Schnittstellen unglaublich. Diese Möglichkeit motiviert auch fern ab des Rechners über workflows nachzudenken und einfach mal zu basteln. Viele meiner kleinen Alltags-Projekte sind so auf dem Handy entstanden.

Niemals zuvor konnte man kleine Dienste so schnell zusammenbasteln wie mit diesen Tools. Das gilt nicht nur für NodeRED, sondern auch für Automagic auf Android.

Beispiele

Monitoring - Bei Cybus haben wir zum Beispiel ein Emergency-Monitoring auf Basis von NodeRED aufgebaut. Intern liebevoll “Der Bademeister” getauft, überwacht dieser unsere Cybus Instanzen ob irgendwelche erkennbaren Probleme vorliegen.

Home-Automation - Meine Wohnung ist mittlerweile an verschiedenen Stellen IoTifiziert. Betritt eine bekannte Person die Wohnung geht im Flur z.B. das Licht an. Ist niemand mehr in der Wohnung, werden alle Lichter ausgeschaltet.

Situationserkennung und Metriken - Mein Handy ist ständig auf der Suche nach Informationen aus meinem Umfeld. Befinde ich mich in der Nähe von gewissen WLAN-Netzwerken tracke ich die Zeit mit wie lange ich mich an diesem Ort befinde. Schon habe ich einen Überblick über meine Arbeitszeiten.

Bots - Die Verarbeitungseinheit mein Projektes “Hamburg-Bots” basiert zu einem Großteil auf NodeRED. Wer mehr dazu erfahren will, kann sich gern hier belesen.

Das sind nur einige Beispiele. Die Möglichkeiten sind nahezu grenzenlos.

Tools

NodeRED

Hach! Ich komme schon wieder ins schwärmen. Installiert es euch und spielt damit! NodeRED wird hauptsächlich von IBM entwickelt und ist eine wichtige Komponente der IBM Cloud Solution Bluemix.

Die eigentliche Stärke dieses Projektes ist aber die Community dahinter. Es gibt bereits über 400 (!) Plugins die die Möglichkeiten des Tools erweitern. Auch ich habe mich mit meiner Trello-Node bereits an der Erweiterung beteiligt.

Wer sich einen Überblick verschaffen möchte sollte bei npmjs.org nach der Namenskonvention “node-red-contrib” suchen, oder dem Twitter Account @red_nodes folgen.

Automagic

Was NodeRED für den PC ist, ist Automagic für Android. Automagic versetzt einen in die Lage auf die komplette Bandbreite an Sensorik und Triggern eures Gerätes zuzugreifen und diese innerhalb von Flows miteinander zu kombinieren.

Was ich bis heute nicht verstehe ist die Dominanz des Konkurrenz-Tools Tasker in diesem Bereich. Es bietet weder die Vielfalt der Möglichkeiten, noch ist es in der Bedienung so intuitiv wie Automagic. Nichtsdestotrotz hat es Tasker geschafft eine breite Masse an Plugin-Entwickern um sich zu versammeln was auch Automagic zugute kommt. Denn: Die meisten Plugins für Tasker kann man auch in Automagic verwenden!

Automagic gibt es auch als Testversion. Sollte euch das Tool gefallen, unterstützt den Entwickler und gebt die wenigen Euro aus. Das Preis-Leistung-Verhältnis ist der Hammer!

Ausblick

Mit Flow-based Programming und IoT haben zwei Gebiete zueinandergefunden die ein enormes Potenzial haben. Flow-based Programming nimmt der Programmierung ein Stück weit die Komplexität. IoT verschiebt die Möglichkeiten immer mehr in die physische Welt. Diese Kombination bringt enorm viel Spaß denn die Lernkurve ist Steil und Projekte sind schnell umgesetzt.

Auf die einzelnen Tools werde ich in separaten Blog-Posts eingehen.

Wer einen tieferen Einblick in die Thematik haben möchte, sollte sich den 14. Oktober vormerken und mich auf dem Developer Open Space treffen!

2016-06-13

Docker Automated Builds

Wie oft habe ich schon vor tollen Docker Containern gesessen und mich dann doch dagegen entschieden diese zu benutzen, weil nicht zu erkennen war, wie das ganze Setup funktioniert, oder welche Dienste ggf. noch ohne mein Wissen gestartet werden.

Seit einiger Zeit gibt es nun auf DockerHub die Automated Builds. Diese schaffen einen deutlichen Transparenzsprung, denn die Quelle des Containers ist klar ersichtlich und die bereitgestellten Container basieren auch zwangsläufig auf dieser Quelle. Bei Containern, die diesen Flag nicht haben, würde ich immer vorsichtig sein!

so sieht ein automated build

So, jetzt aber Butter bei die Fische!

Schritt 1: Ein öffentliches Repository

Von Haus aus bringt DockerHub eine Unterstützung für GitHub und Bitbucket mit. Wir arbeiten in diesem Tutorial mit einem meiner Repositories, welches auf GitHub gehostet ist:

https://github.com/oliverlorenz/docker-node-red-extra

Warum noch ein NodeRed-Image? Nun ja: Erstens handelt es sich nur um ein Beispiel. Außerdem ist dieser Use Case für mich selbst von Relevanz, da mir in den üblichen Containern immer die entsprechenden Tools fehlen, die ich brauche.

2. Einen Automated build anlegen

Loggt euch bei DockerHub ein und wählt im Menü oben rechts Create > Create Automated Build. Das ist wichtig, denn ihr könnt die Art des Repositories nicht mehr ändern

Create > Create Automated Build

Folgt dann einfach den Anweisungen der folgenden Masken. Solange ihr die Visibility auf “public” lasst ist alles gut :)

3. Zusätzliche Einstellungen

Build-Settings

Als erstes sehen wir uns mal den Menüpunkt “Build-Settings” an.

Die Standard-Einstellungen sind garnicht schlecht. Immer wenn es eine Änderungen auf dem master-Branch innerhalb eures Code-Repositories gibt, wird DockerHub einen neuen Build für euch starten. Ihr könnt natürlich jeden beliebigen Branch bzw. Tag in die Übersicht eintragen.

Ich empfehle euch, an dieser Stelle mit Tags und dem master-Branch als “latest” zu arbeiten. Das hat den Vorteil, dass sich eure Nutzer explizit auf eine Version pinnen können und damit die Kontrolle behalten wann sie updaten wollen. Besonders bei Projekten die in Production-Umgebungen laufen, solltet ihr euren Nutzern zuliebe nicht darauf verzichten.

Falls es nötig werden sollte, könnt ihr mit dem rechten Button “Trigger” zusätzlich einen manuellen Build des entsprechenden Branches/Tags ausführen.

Create > Create Automated Build

Repository Links sind unglaublich praktisch! Eigentlich setzt man immer auf ein Base-Image auf. Oft macht es Sinn die Änderungen dieses Base-Images gleich in das eigene Projekt zu übertragen. Dabei hilft uns DockerHub hervorragend, denn durch das verlinken auf das Base-Image wird automatisch ein Build unseres Projektes ausgeführt, sobald es Änderungen im Base-Image gab. In unserem Fall habe ich auf “cpswan/node-red” verlinkt, welches meine Basis darstellt.

Create > Create Automated Build

4. Build Details

Zusätz zu den Build-Settings gibt es noch den Menüpunkt Build-Details. Diese lassen euch einen tieferen Einblick in eure Build-Logs zu. Grundsätzlich kann man aber sagen, dass es vom Informationsgehalt 1:1 dem entsprechen was ihr bei eurem lokalen Build sehen würdet.

Create > Create Automated Build

Fazit

Docker Builds sind eine klasse Sache! Endlich kann man erkennen welchen Containern man vertrauen kann und bei welchen man vielleicht etwas vorsichtig sein sollte. Die lose Kopplung zwischen GitHub/Bitbucket und DockerHub bringt neben Transparenz auch noch einiges an Komfort.

Leider ist es derzeit nicht möglich Container auf ARM-Basis erstellen zu lassen. Bei meinen zahlreichen Diensten die auf meinen Raspberry Pis laufen, würde ich mir wünschen diese nicht immer direkt auf dem Raspberry selbst bauen lassen zu müsse. Aber was nicht ist kann ja noch werden!

Make Your Lichtschalter great again

In diesem Blog-Post geht es um mein erstes, im Produktiv-Betrieb befindliches Projekt. Die Deckenlichter meiner Wohnung zu schalten. Klingt einfach, ist es retrospektiv betrachtet auch; War aber doch mit einigen Iterationen und hart erkämpften Erkennissen gespickt.

Bisher lief meine Lichtsteuerung auf einem Raspberry Pi. Das hat sich schon immer falsch angefühlt, denn Hand aufs Herz: Wozu brauche ich ein Full-Stack-Linux um ein Funksignal zu senden? Kanonen und Spatzen und so …

Seit ich bei Cybus arbeite, habe ich meine Developer-Fähigkeiten ein Stück Richtung Hardware übertragen können. Man muss dieser ganzen Maker- und Bastel-Szene zugute halten, dass sich da in den letzten Jahren wirklich viel getan hat. Die Hardware ist unglaublich günstig geworden und auch solche Hardware-Phobiker wie ich können mit Stack-Overflow & Co richtig coole Projekte umsetzen.

Genutze Hardware

Nun zur Umsetzung:

Proccessing Unit

In meinem neuen Setup nutze ich einen ESP8266 bzw. Dieser ist in meiner Variante (8€) relativ günstig und bringt WLAN gleich Out-Of-The-Box mit. Wer bock und den Skill hat, kann diesen auch nicht nur mit C programmieren, sondern auch mit LUA füttern. Preis/Leistung top, wie ich finde!

Lichtschalter

Ich lebe in einer Mietwohnung. Somit fallen größere Umbauten einfach aus. Aber: “Challange accepted!”. Ich habe eine tolle Lösung gefunden.

Make your Lichtschalter great again

Die Lösung ist eine Lichschalter-Erweiterung von Intertechno. ITL-230. Dieses Gerät ist so klein, dass es in der Regel hinter den Lichtschalter passt. Das Besondere ist, dass der Lichschalter weiterhin normal funktioniert, zusätzlich reagiert er aber auch auf ein 433Mhz Signal.

Wenn ich die Betriebsanleitung richtig verstanden habe, dient der alt eingesessene Lichtschalter nun nur noch als Impulsgeber. Die Schaltung übernimmt die Box selbst; Ist somit aber “always on” und verbraucht somit ca. 1W. Aber: Halbwissen

Eine Einschränkung gibt es allerdings: Wer sein Heim schon auf LED umgestellt hat, ist leider mit den Geräten von Intertechno nicht gut beraten. Diese funktionieren leider nur bei klassischen Glühbiren oder Halogen-Lampen.

Achtung: Ihr arbeitet hier mit 230V Netzspannung. Ihr wisst alle, dass das gefährlich sein kann, also immer schön die Sicherung rausnehmen bevor ihr irgendwas am Schalter oder der genannten Schalterbox tut.

433Mhz Sender

Der 433Mhz Sender ist nichts besonders. Ich habe lediglich darauf geachtet, dass man eine externe Antenne anschließen kann und dieser unter 3,3V betrieben werden kann.

Verkabelung

Des Informatikers grauen! Etwas physisches tun, bäh! ;) Retrospektiv betrachtet hat es nur etwas interensivers Googlen und Scheuklappenarmen Fokus auf das Projekt gekostet um der Elektronik den Schrecken zu nehmen. Heutzutage gibt es so tolle Bauteile, die auch einfache aber technisch interessierte Menschen in die Lage versetzen, mehr oder minder komplexe Projekte umzusetzen.

Die Verkabelung ist easy. Ich habe euch hier den Aufbau abgebildet. Die LED ist optional. Ich habe sie mit reingenommen damit ich prüfen kann, ob mein Signal auch am entsprechenden PIN ausgegeben wird. Diese könnt ihr dann auch ganz einfach wieder entfernen.

schaltplan mit fritzing

Die Software

Die Software hat drei verschiedene Aufgaben:

Arduino-Software ist klassischerweise in zwei verschiedene Bereiche aufgeteilt. Das sollte man zumindest mal gehört haben.

Die Setup-Funktion übernimmt das Bootstrapping. Heißt: Dieser Code-Block wird nur einmalig ausgeführt. Hier empfielt es sich den initialen WLAN-Connect und den Connect zum MQTT-Broker zu machen, sowie die Initialisierung der RCSwitch-Library die das Signal für unseren 433Mhz Sender erzeugt.

Im Loop-Bereich hinterlegt man die Operationen die permanent auszuführen sind. Wie der Name schon sagt. In unserem Fall ist hier aber gar nicht viel zu tun. Falls der MQTT-Client die Verbindung verliert, reconnected er auch wieder.

Den Code könnt ihr so übernehmen. Lediglich eure WLAN-Zugangsdaten und die Verbindungsdaten zum MQTT-Broker müsst ihr anpassen.

Als MQTT-Broker kann ich Mosquitto empfehlen.

Inbetriebnahme

Schritt 1: Software überspielen

Zum überspielen der Software auf den ESP habe ich die Arduino IDE verwendet. Meine Konfiguration sah folgendermaßen aus:

ArduinoIDE Konfiguration

Sollte es unklarheiten im Code geben, würde ich mich freuen wenn ihr mir ein Issue auf Github stellt oder einfach einen Kommentar unter dem Post hinterlasst.

Habt ihr die Software überspielt, solltet ihr den Serial-Monitor öffnen. Dort ist vor allem wichtig zu erfahren auf welchen Topic der ESP subscribed. Das Format sieht ähnlich diesem aus:

ESP-XX-XX-XX-XX-XX-XX/a/1/1/on

Der erste Teil “ESP-XX-XX-XX-XX-XX-XX” soll einen eindeutigen Identifier darstellen, der auf der MAC-Adresse basiert. “a/1/1” sind die Geräte-Parameter für die Funksteckdose. Genaueres dazu könnt ihr hier erfahren. “/on” bzw. “/off” ist, glaube ich, selbsterklärend.

Schritt 2: Funktioniert alles?

Zum senden der MQTT-Messages nutze ich im weiteren Verlauf mosquitto_pub.

Sendet ihr nun eine Message an den entsprechenden Topic, sollte der ESP reagieren und die LED müsste im entsprechend kodierten Takt blinken. Hinweis: Das ganze führt noch nicht dazu, dass ihr das Licht schaltet. Es geht hier erstmal darum zu validieren, ob die Verkabelung richtig ist und die Software richtig funktioniert. Sollte alles so reagieren wie beschrieben, seid ihr auf dem richtigen Weg! :)

Schritt 3: ESP mit Lichtschalter koppeln

Versetzt nun die kleine Box hinter eurem Lichtschalter in den Lern-Modus. Dazu den kleinen Knopf drücken. Über den Zeitraum wo die LED blinkt habt ihr dann Zeit ein On-Signal über MQTT senden:

  mosquitto_pub -h "MQTT-BROKER-ADDRESS" -t "ESP-XX-XX-XX-XX-XX-XX/a/1/1/on" -m "1"

-m “1” solltet ihr immer mitsenden, weil einige Broker die Message sonst ignorieren. Der Inhalt ist aber völlig irrelevant.

Sollte alles funktioniert haben, hört die LED in diesem Moment auf zu blinken und das Licht geht an. Zum auschalten des Lichts könnte der Befehl wie folgt aussehen:

  mosquitto_pub -h "MQTT-BROKER-ADDRESS" -t "ESP-XX-XX-XX-XX-XX-XX/a/1/1/off" -m "0"

Fazit

Resultat Home-Automation ist auch an solchen kleinen Komponenten ein Endlos-Thema. Nicht weil man nie fertig wird, sondern weil man immer wieder Verbesserungspotenzial findet.

Ich freue mich sehr, dass ich diesen Schritt getan habe. Die Entkopplung über MQTT bringt den Vorteil, dass man die Processing-Unit universell einsetzen kann. Außerdem ist sie ohne Probleme austauschbar.

Die Komponenten sind sehr günstig, einfach zu bekommen, die Soft- und Hardware ist Open-Source und nun mit diesem Blog-Post auch in ihrem Zusammenspiel gut dokumentiert.

Zum ersten mal kann ich sagen, dass das Projekt einen Stand erreicht hat, der mich ruhig schlafen lässt. Nun freue ich mich auf eure Kommentare und hoffe von euch zu hören, dass ihr mit diesem Setup eurem Smart-Home vielleicht ein bisschen näher gekommen seid.

2016-12-31

Fefes Blog

https://blog.fefe.de