IoT: Monitor temperature and humidity on a Grafana dashboard

 I wanted to set up an IoT project for a long time for learning purposes. When I started to learn for a AWS certificate I thought it was big time for some hands on practice.

The goal

Monitor temperature and humidity in the attic in order to get critical min and max temperatures during the course of a year.

The architecture

I had a rough idea about the components I wanted to use and I quickly realized that using AWS IoT core and Lambda was a common way to do the job. I was also curious about using a time series db, so Influxdb came into play. I didn't want to spend time on the UI, so Grafana was a natural choice.

Data handling at the edge

I use a Raspberry Pi 3.0 with a Debian OS at the edge. It's connected to a humidity and temperature sensor. I collect data with the dht.DHT22 driver from the adafruit lib.

Three Python scripts manage the data handling at the edge:

1. Collect sensor data with the above mentioned lib. Since temperature and humidity don't change too fast, I collect data every 1 second though the sensor provides a higher sample rate. The data is stored in a log rotation (5 files switched on an hourly basis).
2. Every hour a cron job triggers a script that fetches the data from the past hour from the log and aggregates temperature and humidity to mean, max and min values, which are totally sufficient for my purpose.
3. Every hour a cron job triggers a script that publishes the aggregated data to AWS IoT core

Data handling in the cloud

I set up two triggers for the data I subscribe to with IoT Core:

1. Persist the messages to S3. This helped me to replay ingestion when I messed up with the lambda code, the configuration or the Influxdb. On the long run I set up S3 so that they are deleted after a couple of days.
2. Call a Lambda function that extracts the data from the message and stores them in the influxdb. If storing the data fails, I setup SNS to send an email.

Data visualization

I installed Influxdb and Grafana on an EC2 instance, which provides me an easy approach to visualize the data I collect from the sensor under my roof. 

Learnings

I spent a lot of time writing the javascript for the Lambda function. I was finally successful using Visual Studio Code with the AWS toolkit. So I created, built and tested the code locally, then deployed the result to the cloud.

Things I touched:

• IAM
• S3
• Route 53
• Security Groups
• IoT Core
• SNS
• Lambda
• Cloud Watch
• EC2

Bottom line

With regards to my AWS learning this project created a huge progress. Components, services and configurations are much clearer to me now. I would say the result has the level of a proof of concept. I spent 2 to 4 hours per day over three weeks. 

I built a ukulele

 I build my frist Guitar last autumn with Wolfgang Teller in a three days workshop. He pre-built the soundboard with the rosette, sides where glued to the head and tail block, the raw shape of the neck was cut and glued already. 
Now I wanted to build a guitar from scratch and starting with a small instrument seemed to be a good idea. I always wanted a tenor ukulele and I also was curious about how a pure koa instrument would sound like. I decided to build only with hand tools, so now circular saw, no band saw, no planer (the decision was easy - I don't have any of these machines, but I was impressed by many youtube videos from luthiers who deliberately craft with hand tools). This was before I knew how challenging it would be to plane a peace of dry koa from 5 millimeters to 1.5 millimeters.

I was looking for templates and found a nice one with v-bracing another thing I was curious about.

So I started looking for wood and also started to build the mold.

The sides

When I planed the sides to 2 mm, I didn't dare to go to far with the plane and rather sanded them down from 3 mm, which was a lot of sanding. 

I pondered a lot whether I should buy or build the bender and finally decided to build one myself. It turned out that the wood began to carbonize during bending, so I switched over to a more basic variant, which worked fine.

I failed to bend the initially planed cutaway body and dropped it in favor of a classical shape. Bending so far was the biggest challenge.

Learning: I did a rather bad job and I have to train it much more. Don't start with very hard wood like koa! Work with the scraper before bending, the wood might crack from the cuts from planing. 

I moved on with the head and tail blocks. 

Learning: Measure twice! I had to cut the head and tail blocks two and tree times, before I finally got them right with all angles.

I planed the sides so that they meet with the head and tail level

I was ambitious to cut slotted linings myself. I took me a while to get them nice (better don't look to close), unfortunately I learned to late how I add a depth stop to the saw blade. You find a lot of examples from luthiers using cloth spins with rubber band as clamps for the lining. Works nice!

I reached the first stage with a lot of learning

The back

I felt more experienced with the plane and went down to 2.2 mm with the plane and used the scraper and sanding paper to get to 2 mm. For glueing the bookmatches I used the traditional method of light pressure in a slightly too narrow setup. 

I added extra lining to the joint, 

cut out the back

added the bracing

And did some final tweaking with the chisel and rounded the bracing with the plane and sanding paper. 

T

I reached stage 2

I decided to already glue the back to the sides at this stage. I had my concerns in putting everything together in one go. 

I also build the clamps from a threaded rod and a wooden staff.

The soundboard

Getting down to 1.5 mm worked well despite my worst fears. But I had difficulties not to leave bad marks in the wood and I am afraid it might come from a blunt blade. 

Learning: Grind the blade of the plane more often! 

The rosette

The rosette kept me awake at night. I mad a couple of trials before I dared to cut the channel into the soundboard. 

First draft:

Second draft:

Finally I decides to go with my first template.

The bridge

That was fun! I cut two channels with the router and did the rest with the  chisel. 

Before (left) and after:

Cutting the channels with the router:

Almost done:

Fits in:

That was annoying, the drill broke and it was quite an operation to get out and close the cut again. I did that operation from the bottom  of the bridge so it's not visible after the bridge is glued to the top.

The neck

I cut the nut with the router holding the body in a jig I build before

The neck block

The neck after cutting and gluing the head

Working on the neck with chisels, rasp, cutter

The binding

Due to the uneven sides I had difficulties to cut the channels for the binding with the router. I ended up with a mixture of a router cut from the top and a knife cut from the side with a home made channel cutter (right to the body)

The fret board

I gave the fret board a light radius of 22'', glued the frets and leveled them with a self-made file holder. The channel I cut with the Japanese saw where rather wide for thin slim frets, so no hammering was requited and I pressed the in the slot with clamps. 

I added a dot on the 5th and two on the 12th fret. 

Learning: Better prepare the neck and the fret board before glueing it together. They didn't perfectly fit. 

Kalte Liebe

Ein Paar im Business Dress steigt aus der U-Bahn. Sie küssen sich den Abschied während sich ihre Körper schon in die entgegengesetzten Richtungen ihrer nächsten Stationen winden. Ihre Augen fliehen voraus und schon aus dem Moment. Er wischt sich mit dem Daumen über die Lippen, auf denen ein trockener Kuss juckt.

No readiness - no sprint

Management tends to push high-level epics straight into Scrum teams with the help of willing PO and weak Scrum Master. With the effect, that the team is drowned by questions, unresolved dependencies and half done requirements. Missing acceptance criteria opens the door for technically driven assumptions and overengineering. With UX and design missing, the already slow team runs into changes after each sprint, when stakeholders, confronted with first results, realize what they really want and how it should look like. 

Try to prioritize on an epic level. You can do this with Moscow, Stacey diagram, value-effort/risk diagram or return on investment-effort analysis. Break epics down into features and prioritize again. Align with all teams, identify dependencies, negotiate API and gather all information that is required to make the features ready for implementation. If readiness has been achieved and stories are written, start implementing. The team should now be able to implement the feature fast and to get feedback on a first increment, that delivers the first function to a client. If the organization sticks to this workflow, features can be delivered fast and respond quickly to internal or external drivers for change.

Schlank bleiben

Werden Feature von Teams umgesetzt, die nicht das klare Ziel verfolgen, dem Kunden so schnell als möglich einen Mehrwert zu schaffen, bleibt die Implementierung unter Umständen technischer Selbstzweck, der im Kreislauf der Sprints immer tiefer in Anforderungen und technische Details getrieben wird, ohne jemals ausgeliefert zu werden.
Es reicht nicht, funktionierende Inkremente zu erzeugen, wenn diese lediglich an den PO übergeben werden, die Integration und das Deployment aber außerhalb des Teams liegen.
Zusammen mit PO und Scrum Master muss das Entwicklerteam lernen, ein Feature auf den Kern der minimalsten Funktionalität herunterzubrechen. Viel wichtiger als die Funktionsreife ist die initiale Integration in die bestehende Software und die Infrastruktur. Was ist eine Verbesserung wert, wenn sie am Ende des Sprints den Kunden nicht über Integration und Deployment erreichen kann? Wenn eine ausgefeilte UI keinen Endpunkt hat, über den es mit dem Rest des Systems sprechen kann?
Gemeinsam kann das Team einen schlanken Schnitt finden, mit dem ein Feature über alle Layer implementiert und ausgerollt werden kann. Ein erstes Feedback hilft, den nächsten Schritt sicher zu erkennen und so Sprint für Sprint ein reifes, von Feedback und Messdaten getriebenes Feature auf der Basis einer funktionierenden CI/CD zu entwickeln.

An inkrement a day keeps the doctor away

Kuenstler wie Ed Atkins liefern kein finales Werk mehr, eher Snapshots einer ohnehin ueber Animation verworfenen Wirklichkeit (z.B. im MMK Frankfurt). So wenig Entwickler Teams den Gewerken beim Hausbau gleichen, sondern vielmehr einer hoffentlich gut ausgeruesteten und erfahren Expeditionsmannschaft, so wenig laesst sich die Vorstellung von "fertig" auf Softwareentwicklung anwenden. Software befindet sich in einer Dauerschleife der Herstellung kleinster Inkremente, die einen direkten funktionalen Nutzen (ein neues Feature) fuer den Kunden haben oder ueber indirekte, nicht-funktionale Verbesserungen die Nutzung aller Feature verbessern (z.B. schnellere Ladezeiten).
Ich behaupte, dass man beim Bauen von Prototypen sehr gut verstehen und lernen kann, wie man durch konsequentes Runterbrechen auf kleinste Einheiten und einfachste Implementierung auch fuer die Zeit nach dem Prototyp in einen Zustand der inkrementellen Dauerlieferung von Nutzen kommen kann.
Mein Versuch zog sich ueber mehrere Wochen, zwei bessere Entwickler als ich, die am Stueck arbeiten, sollten das gleiche Ergebnis in 3 bis 4 Tagen erreichen.

Vorueberlegung zur Arbeitsweise

Ich wollte mehrere Anforderungen miteinander verbinden:

1. sinnvolle Prinzipien erstellen fuer das schnelle und inkrementelle Arbeiten an einem Prototyp
2. passende Zeiteinheiten finden fuer das Erstellen von Inkrementen
3. minimalistisch und Backend-frei arbeiten und *aaS bevorzugt nutzen

Anforderungen an die App

Ich wollte eine statische Seite, die Termine fuer ein Jazzfest listet, abloesen mit einer Seite, die ein nicht-Techniker administrieren kann. Langfristig sollten auch andere Festivals verwaltet werden koennen. Der Prototyp sollte eine Basis schaffen, mit der ich herausfinden kann, wie sich die staendig wechselnden Jazz-Band-Besetzungen im Festivalbetrieb abgebilden und verwalten lassen. Den grossen Kontext will ich kennen, um auf dem Weg dorthin die richtigen Entscheidungen treffen zu koennen. Aehnlich einem Trompetenspieler, der sich beim Spielen einer Tonleiter auf den hoechsten Ton konzentriert, also Luft und Spannung fuer diesen Ton aufbaut, um dann in dieser Haltung Ton fuer Ton zu spielen.
Was soll der Prototyp koennen?

1. Ich kann einen Zeitplan mit Band, Uhrzeit, Datum und Location fuer ein Jazzfest erstellen und administrieren
2. Ich kann die Daten fuer das Jazzfest ueber eine API auslesen und auf einer Seite fuer Nutzer darstellen
3. Ich kann die Details zu Band und Location pflegen und anzeigen
4. Der Admin kann Fotos hochladen und fuer die Seite verfuegbar machen

Schritt 1 - lokale Entwicklung

1. Admin UI mit Nodejs, Express und Mongose
2. Website fuer Nutzer mit Angular 2 und Webpack

Schritt 2 - Integration auf *aas Loesungen

1. Anbindung der Mongo DB auf mLab
2. Bereitstellen der Bilder auf Cloudinary.com
3. Hosten der NodeJs Applikation auf Heroku.com
4. Hosten der AngularJs Applikation auf einem Digital Ocean Ubuntu Server

Schritt 3 - Deployment

1. auf Heroku und Digital Ocean
2. Environments definieren

Die Anforderungen waren schnell formuliert, da es bereits eine Seite gab. Das groessere Ziel, es als Festival Planner fuer verschiedene Anwender verfuegbar zu machen, sollte im Kopf behalten werden, um bei Architektur und Datenmodell nicht zu kurz zu springen.

Regeln und Prizipien fuer das Entwickeln des Prototypen

• wenn ich keine VM oder Docker Container, die ich sofort (d.h. sofort) verteilbar und lauffaehig habe oder ausreichend Know How dazu habe, erstelle ich das Projekt direkt auf meiner Maschine
• modelliere die Daten nur mit einem Minimum an Properties, die notwendig sind, um die einfachste Funktionalitaet zu erzeugen. Z.B. hat im ersten Schritt eine Band nur einen Namen, ein Festival nur einen Namen, die Performance eine Zeitspanne, ein Ort nur einen Namen. Weitere Details helfen beim Verstaendnis ueber Struktur und Pflege der Daten nicht.
• mache keine Datenvalidierung solange nur du selbst und eine Hand voll Leute die Anwendung nutzen
• keine Layouts, keine Styles - wir wollen vorerst nur nakte Funktionalitaet
• starte mit statischen Daten und arbeite mit statischen Daten solange es sinnvoll geht
• implementiere Registrierung und Login erst, wenn du die Seiten oeffentlich machst

Regeln Prinzipien fuer die Organisation der Arbeit

• konzentriere dich auf die Elemente, die dein Geschaeftsmodell validieren und dem Kunden Mehrwert verschaffen
• lasse alle (Kano) Basiskriterien weg, von denen du sicher bist, dass du sie leicht liefern kannst (Login, E-Mail, Upload, Social Media integration, etc.)
• nutze alle Abstraktion, die schon fertig und verfuegbar ist (ORM, OGM, DI,...)
• verzichte auf eigene Abstraktion solange du mit der Modellierung der Daten und der Logik noch im Fluss bist
• validiere nicht Daten, sondern dein Datenmodell - jetzt ist der Zeitpunkt, wo du es schnell und einfach aendern kannst
• suche so frueh wie moeglich den realen Anwendungsfall und den realen Anwender
• formuliere nur Aufgaben, die in 3 Stunden umsetzbar sind. Ist die Aufgabe nach drei Stunden nicht umsetzbar, verwende solange Zeit, bis du die sie auf eine Groesse geschnitten hast, die in 3 Stunden erreichbar ist
• So erreichst du Prinzip Nummer 2: liefere jeden Tag mindestens 1 Inkrement
• Schreibe immer alle Aufgaben auf, die sich als Erweiterung oder Refacturing ergeben. Z.B. Registrierung und Login werden erst notwendig, sobald die Seite live geht. Passwort Reset und Passwort Aenderung koennen noch spaeter hinzugefuegt werden
• Das Nutzen von *aaS erspart mir eine wachsende Infrastruktur und hilft mir, eine modulare Struktur aufzubauen, in der ich Komponenten oder Services beliebig tauschen kann

Wer sich auf diese Weise an ein Projekt herangetastet hat, wird ohne Muehe mehrfach am Tag ein Deployment machen.

Krieg und Frieden

Berg-Am-Laim-Straße. Vater und Sohn mit dem Fahrrad auf dem Weg zur Kita . Er schiebt seinen Sohn bergauf unterstützend mit an. In der Seitenstrasse wartet eine schwarze myDriver Limousine bis die beiden passieren. Die Limo biegt ab. Auf gleicher Höhe angekommen, hupt der Chauffeur und winkt ihnen fröhlich anspornend zu. 100 Meter weiter, eine Karavane von Fahrradfahrern bewegt sich über die Kreuzung. Die wartende Schlange der Rechtsabbieger löst sich auf, ein Taxi jagt mit Motorengejaule los. Aus dem offenen Fenster prollt es: "so ein Dreck mit dene Scheiß Radlfahrern". Liebe Taxifahrer, den Prozess verliert Ihr auf der Straße, nicht vor Gericht.