Zum Hauptinhalt Zur Navigation

Mitmachprojekt: HTTPS vermiest uns den Wetterbericht

Wir haben die Bürotemperaturen eines ganzen Jahres analysiert. Dabei erhielten wir eine unerwartete Lektion für die Umsetzung von IoT -Projekten. Die Daten und der Auswertungscode stehen zum Download zur Verfügung.
/ Alexander Merz
42 Kommentare News folgen (öffnet im neuen Fenster)
Ösi-Tux mit Thermometer (Bild: Alexander Merz/Golem.de)
Ösi-Tux mit Thermometer Bild: Alexander Merz/Golem.de

Nach 18 Monaten findet unser Leserprojekt schließlich ein Ende. Vom 19. April 2016 bis zum 31. April 2017 übersandten uns Leser mit Hilfe kleiner selbst gebauter Messstationen die Temperatur ihrer Büros. Bereits im März 2017 nahmen wir eine Zwischenauswertung vor. Unsere finale Auswertung bietet dieser gegenüber kaum neue Überraschungen. Allerdings ist es uns gelungen, die Validierung, Analyse und die Visualisierung der Daten fast vollständig mit Hilfe von Skripten zu automatisieren, ohne dass uns dadurch mehr Aufwand entstand. Und wir haben die Schattenseite der Umstellung von Golem.de auf HTTPS kennengelernt.

Im ersten Teil des Textes werfen wir einen Blick auf die Daten, der zweite Teil stellt die Technik hinter der Analyse vor. Die umfangreich kommentierten Quellcodes für alle Analyseskripte und ein Dump der Datenbank mit den rohen Messdaten stehen über Github(öffnet im neuen Fenster) öffentlich zur Verfügung. Auf einer eigenen Übersichtsseite zum Bürotemperatur-Projekt befinden sich interaktive Diagramme und statistische Details zu den Daten.

8,5 Millionen Messwerte werden analysiert

Insgesamt wurden rund 8,49 Millionen Messwerte erfasst. Davon wurden rund 7,95 Millionen in die Messung einbezogen. Abgezogen wurden Messwerte unter anderem, weil sie außerhalb des betrachteten Zeitraums vom 14. April 2016, 12 Uhr, bis zum 31. April 2017, 24 Uhr, lagen oder die Temperaturwerte unglaubwürdig waren, zum Beispiel über 60 Grad.

Rund 7,8 Millionen Messwerte wurden mit einer Länderkennung geliefert beziehungsweise es konnte ihnen eine Länderkennung zugewiesen werden. Der Großteil der Messwerte stammt aus Deutschland, schon deutlich kleiner ist der Anteil der Nächstplatzierten, Österreich und der Schweiz. Insgesamt wurden Messwerte aus elf Ländern angeliefert.

Alle Bundesländer sind dabei

Knapp 7 Millionen Messwerten in Deutschland konnten wir ein Bundesland zuordnen. Im Gegensatz zu unserem Zwischenstand sind diesmal alle 16 Bundesländer dabei. Allerdings unterscheidet sich die Anzahl der Messungen zwischen den Bundesländern sehr stark. Berlin ist deutlich überrepräsentiert. Vielleicht ist an der Behauptung doch etwas dran, dass Berlin die IoT-Hauptstadt Deutschlands ist. Tabellen mit den statistischen Kennwerten zu Staaten und Bundesländern haben wir auf einer eigenen Übersichtsseite zum Bürotemperatur-Projekt aufgelistet.

Alte Probleme bleiben

Bereits in der Zwischenauswertung beschrieben wir das Problem, die genaue Anzahl der Teilnehmer beziehungsweise Messstationen zu ermitteln. Da wir keine Registrierung im Vorfeld forderten, können wir nur einen Teil der Messwerte konkreten Messstationen zuordnen. Die folgende Auswertung der Teilnehmer nach Land ist deshalb mit Vorsicht zu betrachten, die Zahlen können real nach oben wie auch nach unten abweichen.

Die gleiche Vorsicht ist angebracht, wenn wir uns die Anzahl der Messstationen pro Bundesland anschauen. Trotzdem zeigt die Grafik deutlicher als der Ländervergleich, dass die Anzahl der Messwerte nur eingeschränkt mit der Anzahl der Teilnehmer zusammenhängt.

Raspberry Pi führt weiter

Die Teilnehmer konnten auch eine Gerätekategorie angeben, mit der sie die Messungen durchgeführt haben. Wie bereits bei der Zwischenauswertung liegen Bastelrechner wie der Raspberry Pi vorn. Der Anteil von Mikrocontroller-Lösungen auf Basis von Arduinos und Funkmodulen wie dem ESP8266 ist deutlich kleiner.

Messwerte übers Jahr betrachtet

Die meisten Messwerte wurden im Juli 2017 übermittelt, danach sank die Anzahl kontinuierlich ab – bis zu diesem einen Tag im Februar, ab dem sich die Zahl der Messungen deutlich reduzierte, das gilt auch für die Anzahl der Teilnehmer. Schuld daran war eine Maßnahme, die unsere Leser eigentlich begeisterte: Ab dem 9. Februar 2017 war Golem.de nur noch per HTTPS erreichbar. Damit wurde aber eine ganze Reihe von Messstationen von der Übermittlung der Daten abgeschnitten. Ohne Änderungen am Quellcode der Geräte konnten diese keine Daten mehr senden. Dazu später mehr im zweiten Teil.

Ein kurzer Blick auf alle Messwerte zeigt eine Normalverteilung, die Standardabweichung beträgt 2,56 °C, der Standardfehler 0,0009, der Durchschnitt aller Werte beträgt 23,97 °C.

Temperaturschwankungen können groß ausfallen

Im Laufe des Messzeitraumes zeichnet sich der Sommer-Winter-Unterschied deutlich ab. Allerdings weniger in Hinblick auf die tägliche Durchschnittstemperatur, sondern vor allem auf deren Schwankungen. Diese sind im Sommer stärker als im Winter.

Interessant ist auch, wie stark die Schwankungen pro Messstation teilweise sind. Viele Büros sind zwar relativ gleichmäßig temperiert, im Median beträgt die Schwankung aber trotzdem 12,8 °C.

Im Winter ist es in Büros kaum kälter

Für Deutschland haben wir die gemessenen Temperaturen auch mit den Außenlufttemperaturen verglichen. Basis waren hierfür die öffentlichen Daten des Deutschen Wetterdienstes (DWD). Interessanterweise ist der Korrelationsfaktor zwischen den durchschnittlichen Bürotemperaturen pro Tag und den Außentemperaturen im Sommer niedriger (0,58) als im Winter (0,9).

In der Rangliste der Bundesländer liegt Bremen mit der höchsten Durchschnittstemperatur weit vorn – allerdings ist das Bundesland gerade einmal mit 15 Messwerten vertreten. Aufgrund der breiten Spanne an Messwerten pro Bundesland sind die Durchschnittswerte mit Vorsicht zu betrachten. Entsprechende Informationen finden sich in einer Tabelle am Ende des Artikels.

Die Technik hinter der Auswertung

Für den Zwischenbericht haben wir noch eine Vielzahl von Werkzeugen benutzt, darunter auch reine GUI-Programme. Diesmal haben wir alles komplett mit Hilfe von Python, SQL und R geskriptet. Alle Skripte sind in einem Git-Repository(öffnet im neuen Fenster) verfügbar und auch dort ausführlich dokumentiert. Im Gegensatz zu unserer ursprünglichen Planung sind alle Skripte neu entstanden. Von unserer Zwischenauswertung haben wir lediglich Konzepte und Wissen mitgenommen. Wohl deshalb haben wir trotzdem deutlich weniger Zeit in die Auswertung gesteckt als in unsere Zwischenauswertung.

Zuerst werden die Ortsinformationen mit Hilfe einer Geo-Datenbank(öffnet im neuen Fenster) validiert. Um eine möglichst gleichmäßige Datenbasis zu schaffen, wird die Geo-Datenbank auch benutzt, um zum Beispiel Ortsnamen oder GPS-Koordination nachzutragen. Die Python-Skripte lesen dabei zwar direkt aus der Datenbank, tragen die Änderungen aber nicht selbst ein. Stattdessen werden SQL-Skripte generiert. Wenn die ermittelten Daten, zum Beispiel aufgrund doppelter Ortsdaten, nicht eindeutig sind, werden sie in CSV-Dateien ausgegeben oder in auskommentierten Zeilen in einem SQL-Skript. Diese müssten wir dann kontrollieren. Derart generierte SQL-Statements haben wir in eine händisch gepflegte SQL-Datei eingefügt.

Im nächsten Schritt werden die Temperaturdaten aus Deutschland mit den Daten des DWD verknüpft, wenn die notwendigen Ortsinformationen vorliegen. Dabei haben wir jedem Messteilnehmer eine DWD-Wetterstation zugeordnet. Es flossen auch nur diejenigen DWD-Daten in den DWD-Durchschnitt ein, die wir einer Messstation zuordnen konnten.

Für den Download und das korrekte Entpacken der Geo-Datenbank und der DWD-Daten stehen entsprechende Skripte zur Verfügung.

Die eigentliche Analyse und Generierung der Grafiken erfolgt mit R. Üblicherweise generiert jedes Skript eine Grafik. Auf der Kommandozeile werden teilweise auch noch zusätzliche statistische Kennziffern ausgegeben, wir leiten die Ausgabe jeweils in eine Textdatei um.

Ein Raspberry Pi reicht nicht

Alle Skripte auszuführen, dauert auf einem besseren Desktopsystem mit 16 GByte RAM rund einen Arbeitstag und erfordert circa 25 GByte Festplattenspeicher. Die meisten Skripte benötigen zwischen 1 und 10 Minuten. Lediglich die Zuordnung der DWD-Stationen zu den Teilnehmern kann im Extremfall mehr als 10 Stunden dauern, wenn die MySQL-Installation mit den konservativen Standardwerten läuft und das System nicht auf die I/O-Geschwindigkeit optimiert wurde. Sinnvolle Einstellungen für MySQL haben wir ebenfalls in Github dokumentiert.

Ein Fehler, weil es zu gut läuft

Wir haben leider einen Teil der Messteilnehmer verloren, als wir auf HTTPS umgestellt haben. Das war die Folge zweier Fehler.

Unser erster Fehler war eigentlich Admins Traum. Unsere Server haben die Last durch das Messprojekt problemlos verkraftet. Das hatte aber zur Folge, dass wir die Erfassungsskripte als rein temporäres Projekt überhaupt nicht mehr auf dem Schirm hatten, als wir HTTPS durchtesteten. Hier gilt es auch zu berücksichtigen, dass das Projekt ursprünglich überhaupt nicht so lange laufen sollte.

Der zweite Fehler war es, den Traffic über unsere regulären Server abzuwickeln. Aus administrativen Gründen schien uns das ursprünglich sinnvoll. Aufgrund unserer Serverarchitektur ist es nicht möglich, einzelne Skripte oder Serverteile von HTTPS auszunehmen. Wir hätten also im Februar eine Entscheidung treffen müssen, ob wir HTTPS aufgrund dessen hinauszögern oder nicht. Unsere Entscheidung wäre eindeutig pro HTTPS ausgefallen.

Wir bedauern es, dass dadurch leider eine Reihe von Messteilnehmern ausgeschlossen wurde. In Zukunft werden wir solche Aktionen unabhängig von unseren regulären Produktivsystemen durchführen.

Fazit

Nach unserer Zwischenauswertung ließen wir die Frage offen, ob wir uns weiter in den Datenjournalismus vertiefen sollten. Die reine (menschliche) Arbeitszeit lag für die Gesamtauswertung diesmal bei nur rund 40 Stunden – ein Bruchteil des bisherigen Aufwandes. Dabei konnten wir den Vorgang in Form von Skripten auch noch komplett automatisieren. Der Lernaufwand im Frühjahr hat sich ausgezahlt.

Doch auch eine neue, wichtige Lektion haben wir gelernt: Für zukünftige Datenerhebungen müssen wir stärker auf die Serveraspekte achten, auch wenn es auf den ersten Blick wie der einfachste Teil des Projekts aussieht.

Und jetzt sind auch unsere Leser gefragt: Was interessiert euch, welche Daten sollen wir zukünftig erheben und auswerten?


Relevante Themen