Dieses Projekt ist aus einem echten Problem entstanden: Eigentlich wollte ich tracken, wie feucht es im Keller ist – um einzuschätzen, was ich dort noch lagern kann.
Aus dem Keller-Monitoring wurde nichts, aber das Projekt wurde die perfekte Übung, um eine komplette Dateninfrastruktur von Null aufzubauen: Ein Sensor sammelt Daten, öffentliche Netze leiten diese weiter, mehrere Programme verarbeiten sie, und am Ende stehen Live-Daten auf einer Website.
Fachlich korrekt benannt wäre das eine einfache Datenpipeline mit Dashboard.
Was gemessen wird – und warum in einer Garage
Ich wohne in einem Altbau von 1905; leider hat genau dieser Umstand das Projekt in eine andere Richtung gelenkt als geplant war. Der Sensor konnte die meterdicken Mauern des Kellers nämlich nicht durchdringen. Der nächste Gateway, der die Signale des Sensors empfangen könnte, ist einfach ein Stückchen zu weit weg. Es kamen nur 10% der Pakete an. Deshalb musste ein alternativer Ort her.
Der Sensor sitzt nun in einer großen Garage mit über 100 Stellplätzen und überwacht den Bereich rund um mein Auto. Er misst Bewegungen, Temperatur und Luftfeuchtigkeit.
Das Besondere an ihm: Er ist ein sogenanntes LoRaWAN-Gerät. LoRaWAN ist eine Funktechnologie, die auf sehr große Reichweiten ausgelegt ist – mehrere Kilometer sind möglich – und die dabei kaum Strom verbraucht. Die Batterie hält unter normalen Bedingungen mindestens fünf Jahre.
Der entscheidende Vorteil: Man braucht kein eigenes WLAN, keinen Mobilfunkvertrag, keine zusätzliche Hardware. Der Sensor sendet einfach in die Welt – und in einer Stadt wie München stehen genug öffentliche Gateways (Empfangsstationen), die das Signal aufnehmen und ins Internet weiterleiten. Diese Gateways gehören Unternehmen oder Privatleuten – und sie leiten alle empfangenen LoRaWAN-Daten weiter, nicht nur ihre eigenen.
Wie schon genannt, es hätte eben auch fast aus dem Keller geklappt – aber eben nicht zuverlässig genug für mich. Ein eigener Gateway im Haus oder in der näheren Umgebung könnte das Problem aber sicher lösen.
Wo stehen Gateways in München
Die folgende Karte ist eine interaktive Visualisierung der aktuell bei TTN angemeldeten öffentlichen Gateways in einem gewissen Radius um das Münchner Stadtzentrum. So kann man ein Gefühl dafür bekommen, wie sie verteilt sind.
Warum das problemlos funktioniert: Die Datenpakete sind winzig (wenige Bytes), die Daten selbst sind verschlüsselt, und die anfallenden Übertragungskosten für die Betreiber der Gateways liegen faktisch bei null.
Vom Sensor zum Dashboard: Die Stationen der Daten
TTN und der Datenempfänger
The Things Network (TTN) ist ein etablierter Dienst, der LoRaWAN-Daten empfängt und an eigene Programme weiterleitet.
TTN ist „crowd-sourced“, es lebt davon, dass Nutzer (privat oder geschäftlich) ihre Gateways zur öffentlichen Nutzung zur Verfügung stellen. Es gibt auch eine kommerzielle Variante, wenn man z.B. keinen öffentlichen Datenverkehr auf seinem Gateway haben möchte, professionellen Support erhalten und Verfügbarkeiten zugesichert haben möchte. Zum Beispiel, wenn man sehr viele Sensoren ausfall- und störungssicher kommerziell betreiben möchte.
TTN übernimmt die Deduplikation von Paketen (die ja z.B. von mehreren Gateways aufgefangen werden könnten), und macht damit, was man dort als „Regel“ hinterlegt hat. Die Daten werden dort also hauptsächlich entschlüsselt und weitergeleitet.
Ich habe dort eine Weiterleitung eingerichtet und meinen Entschlüsselungsschlüssel hinterlegt. TTN macht aus dem komprimierten Datenpaket dann lesbare Werte: 20 °C, 50 % Luftfeuchtigkeit, 500 gezählte Bewegungen.
Diese Daten schickt TTN an meinen Datenempfänger – ein Programm, das ich selbst geschrieben habe. Technisch ist es eine API: Das Programm läuft selbständig auf einem Server, wartet auf Daten und schreibt sie in eine Datenbank.
| Schritt | Was passiert | Mein Beitrag | Kosten |
|---|---|---|---|
| 1. Sensor | Misst und sendet ein LoRaWAN-Paket per Funk | Gekauft, installiert | 34,99 EUR |
| 2. Gateway | Empfängt das Paket, gibt es per Internet an TTN weiter | — | 0,00 EUR |
| 3. The Things Network (TTN) | Entschlüsselt das Paket, leitet es weiter per MQTT oder API | Schlüssel hinterlegt, Weiterleitung eingerichtet | 0,00 EUR |
| 4. Daten-Empfänger | Wartet und nimmt die Daten an, prüft sie, schreibt sie in die Datenbank | Programmiert und auf einem Server eingerichtet | auf IONOS-Server / 1,00 EUR mtl. |
| 5. Datenbank | Speichert alle Werte dauerhaft | Eingerichtet | auf All-Inkl-Server / ca. 3,15 EUR mtl. |
| 6. Dashboard | Verbindet sich mit der Datenbank, zeigt die Daten als interaktive Grafiken an | Programmiert und auf einem Server eingerichtet | auf o.g. IONOS-Server |
Warum ein Server – und was Docker damit zu tun hat
Das Programm muss irgendwo laufen. Den eigenen Computer dafür dauerhaft eingeschaltet zu lassen wäre Verschwendung, und Privatanschlüsse sind von außen öffentlich ohnehin kaum erreichbar.
Stattdessen miete ich einen sogenannten VPS (Virtual Private Server) bei IONOS. Hier bekommt man ein Stück Rechenleistung auf einem großen Server – für etwa 1,00 EUR netto im Monat. Strom, Wartung und Internetanschluss inklusive. IONOS ist sehr günstig und man kann nach der Bestellung direkt loslegen. Man wählt noch ein Betriebssystem aus (verschiedene Linux-Distributionen stehen zur Auswahl), und kann dann per Fernsteuerung (SSH) alles einrichten.
Mein Programm kommt per Docker auf diesen Server. Das erlaubt mir, ein komplettes, in sich geschlossenes Programmpaket zu schnüren – Betriebssystem, alle nötigen Tools, Netzwerkkonfiguration – und dieses Paket dann auf dem Server zu starten. Einmal eingerichtet, läuft es eigenständig, startet sich bei Fehlern selbst neu, und lässt sich jederzeit per Fernzugriff austauschen oder aktualisieren.
Docker war für mich zu Beginn Neuland. Es war die größte Lernkurve des Projekts – und gleichzeitig das nützlichste Werkzeug.
(Eine erste Version lief auf Microsoft Azure. Das war aber, wie mit Kanonen auf Spatzen zu schießen: zu umfangreich, zu teuer, zu aufwändig für dieses Projekt.)
Was dabei herausgekommen ist
Am Ende gibt es ein Dashboard. Es zeigt die Live-Daten des Sensors – aktualisiert alle zwanzig Minuten – und erlaubt einen Blick auf historische Werte. Es ist von überall aus dem Internet erreichbar.
Die Programmierung selbst war dabei eher der leichtere Teil. Die eigentliche Herausforderung war die Infrastruktur: Daten empfangen, speichern, abrufen und darstellen – verteilt über mehrere unabhängige Server, die miteinander kommunizieren.
Das Dashboard
Hier eingebunden ist das fertige Live-Dashboard:
Was noch fehlt
Das System funktioniert – aber es hat Schwachstellen, die ich kenne:
Redundanz fehlt. Fällt ein einziger Server aus, entstehen Datenlücken. Für ein Privatprojekt ist das in Ordnung. Für ein kommerzielles System nicht.
Die wichtigsten Schwachstellen kurz zusammengefasst:
- Datenempfänger: Läuft auf nur einem Server. Fällt der aus, kommen keine Daten an. → Lösung: mehrere unabhängige Server oder eine Warteschlange, die Daten zwischenspeichert.
- Gateway: Ich verlasse mich auf fremde, öffentliche Gateways. → Lösung: ein eigenes Gateway aufstellen.
- TTN: Ein externer Dienst, auf den ich angewiesen bin. → Lösung: mit eigenem Gateway auch eigene Software nutzen.
- Datenbank: Kein Backup eingerichtet. → Lösung: zweite Datenbank als Spiegel.
Fazit
Dieses Projekt hat mir gezeigt, wie man Dateninfrastruktur von Grund auf aufbaut. Vom Sensor bis zum Dashboard – alles selbst programmiert, konfiguriert und in Betrieb genommen. Die eingesetzten Technologien: LoRaWAN, TTN, Python, Docker, Plotly/Dash, Waitress, Requests und eine SQL-Datenbank.
Aus statistischer Sicht passiert hier wenig. Aber das war nicht das Ziel. Das Ziel war: Daten sammeln, speichern, zeigen – automatisch, zuverlässig, günstig. Das funktioniert.
| Begriff | Was er bedeutet |
|---|---|
| LoRaWAN | Eine Funktechnik für sehr kleine Datenmengen über große Distanzen |
| Gateway | Ein Empfangsgerät, das Funksignale auffängt und ins Internet weiterleitet |
| The Things Network (TTN) | Ein Dienst, der Daten von Gateways sammelt und verteilt |
| Payload | Die eigentliche »Nutzlast« des Datenpakets |
| API | Eine digitale Schnittstelle, über die Programme miteinander kommunizieren |
| VPS-Server | Ein virtueller Computer, den man sich auf einem großen Server mieten kann |
| Docker / Image | Ein komplett fertiges Software-Paket, das alles zum Laufen mitbringt. |
| Orchestration | Das koordinierte Zusammenspiel verschiedener Programme |
| Dashboard | Eine einfache grafische Benutzeroberfläche zur Visualisierung von Daten |
| Redundanz | Das mehrfache Vorhandensein von Systemen zur Sicherheit |
Blick unter die Haube
Da dieses Projekt vor allem dazu gedient hat, mir Docker und Datenpipelines beizubringen, ist der Code vielleicht kein Clean-Code-Meisterwerk – aber er funktioniert. Wer möchte, das Set-up für den eigenen Keller (oder die Garage) nachzubauen: Der Quellcode für den Datenempfänger, das Dashboard und die Docker-Konfiguration findet ihr demnächst auf GitHub. Bis dahin gerne eine E-Mail an mich:
