Der Frust mit der Datenaufbereitung

Anfangs März 2022 haben wir neue Beispieldaten auf unseren Demo-Server geladen. Dazu haben wir Messwerte aus dem "London Datastore" verwendet – einer öffentlich zugängliche Datenquelle, von der ich bei unserem letzten Hackathon 2021 in Brugg erfahren habe.

Daten aus dem Abschnitt "Low Carbon London Heat Pump Load Profiles" konnten wir einwandfrei importieren. Einziger Kritikpunkt hier: Diese sind in Standardzeit gespeichert, also ohne Sommer-/Winterzeitumstellung. Standardzeit-Angaben sind immer dann problematisch, wenn nur Messwerte innerhalb Sommerzeit vorliegen (etwa für Juni oder Juli), weil dann unklar ist, ob es sich bei einem bestimmten Datum um Sommerzeit oder um Standardzeit handelt. Aber mindestens dokumentiert sollte es sein, was hier nicht der Fall ist.

Standardzeit-Angaben haben den Vorteil, dass Daten nicht doppelt vorkommen (während der Umstellung auf Winterzeit) und normalerweise auch keine Lücken auftreten (Umstellung auf Sommerzeit). Ein Datum in Standardzeit während der Sommerzeit hat aber den grossen Nachteil, dass es streng genommen gar nicht existiert. Was für einen Anwender nicht gerade intuitiv ist, der diese Werte vielleicht mit einem händisch erstellten Messprotokoll abgleichen muss oder mit Daten aus einer Wetterstation.

Völlig unbrauchbar sind aber die "SmartMeter Energy Consumption […]"-Daten. PIs Import-Routine – die wir sogar noch anpasst haben, um mit den absurden Sekunden-Werten (".0000000", siehe Abbildung) umgehen zu können – bricht hier mit der Fehlermeldung ab, dass das Datums-Intervall nicht korrekt ist.

Dass das Datums-Intervall "irgendwo" (genauer gesagt bei Zeile 3'242) einfach ändert wäre ja vielleicht noch o.k. – wenn sonst alles in Ordnung ist. In OpenPi können wir solche Werte beim Import einfach auslassen. Aber dass bei Zeile +24'000 einfach 2 Jahre zurück gesprungen wird, macht eine Datei gänzlich unbrauchbar. Weil völlig unklar ist, wo genau der Fehler liegt…

Gemäss der gängigen Meinung bestehen Datenanalysen im Durchschnitt zu 80% aus Datenaufbereitung. Was überhaupt nicht sein muss, würde der Datenexport "aus der Maschine" (einer Betriebsdatenerfassung, einem Logger, einer Leittechnik) vernünftig programmiert werden. Es ist reine Zeitverschwendung und dazu sehr fehleranfällig, anstelle den Export einmal richtig zu coden, hunderte Male die fehlerhaft exportierten Daten neu aufzubereiten.

Hier unsere Wünsche an all jene, die Export-Routinen für Messwerte programmieren:

• alles in Ortszeit angeben, die Standardzeit höchsten zusätzlich,
• Zeitzonen-Angaben dokumentieren,
• den UNIX-Zeitstempel mit ausgeben ("just to make sure"),
• das Datum runden – auf Sekunden wenn das für die Anwendung reicht,
• die Zahlenwerte runden – wenn es mehr als drei Nachkommastellen braucht lieber den Bereich ändern,
• und ganz zum Schluss mal ein paar Tests machen, vor allem für die Zeitumstellungen.

Und bitte die Messstellen-Bezeichnung, KKS/AIC-Nummer etc. immer ÜBER die Spalte mit den Werten schreiben. Ein "schönes" Layout im Tabellenkopf mit vermeintlich gut lesbarer Legende und Querverweisen zu den Daten braucht weder ein Data Scientist noch der Betriebsingenieur.