Ich besitze privat mehrere (~25) Geräte meines Arbeitgebers AVM GmbH, darunter u.a. ein schaltbare Steckdose FRITZ!Smart Energy 200, früher bekannt als FRITZ!DECT 200. Diese erfasst auch den Energieverbrauch der angeschlossenen Geräte. Diese werden aggregiert für 24 Stunden, 1 Woche, 1 Monat oder 1-2 Jahr als CSV-Datensatz zur Verfügung gestellt. Diesen kann man sich entweder bei Bedarf über die Web-Oberfläche der FRITZ!Box herunterladen oder sich regelmäßig als Push-Service-Mail zuschicken lassen.

Prozedur

Zunächst ein Blick auf die Prozedur, wie man an die Daten kommt.

Kritik 1: Push-E-Mail

Der Push-Service hat (zumindest bei mir) jahrelang nicht funktioniert. Ursache war, dass ich irgendwann meinen Provider gewechselt habe. Als Absenderadresse war aber weiterhin die Anmeldekennung meines alten Providers als Absender-E-Mail-Adresse eingetragen. Die hat dann irgendwann nicht mehr funktioniert und von da an landeten alle Mail im Nirgendwo.

Bitte in der Benutzeroberfläche irgendwo anzeigen, wenn es Probleme mit der Push-E-Mail gibt.

Kritik 2: FRITZ!Box Web-Oberfläche

Die Navigation durch die Web-Oberfläche ist auch alles andere als intuitiv:

1. Die Konfiguration des globalen Push-Services ist unter System → Push Service
2. In der Übersicht wird die 200 zwar als Smart Home gerät angezeigt, aber nicht mit einem direkten Link zu deren Einstellungen
3. Diese findet man erst unter Smart Home → Geräte und Gruppen → Gerätename → Einstellungen → Allgemein bzw. Energieanzeige → Gesamtenergie (kWh)

Bitte verkürzt den Weg, um an die Information zu kommen.

Kritik 3: API

Für die automatische Weiterverarbeitung ist E-Mail suboptimal:

1. Man muss diese irgendwie per IMAP oder POP3 abholen
2. Man muss die E-Mail parsen und nach dem CSV-Anhang durchsuchen
3. Man muss dann die Daten irgendwo ablegen.

Den Download von der Web-Oberfläche kann man auch nicht von extern aufrufen.

Bitte schafft eine API, über die man sich die Informationen ohne viel Aufwand herunterladen kann. Für die Authentifizierung sollte einen standardisierten Mechanismus wie Benutzername-Passwort, HTTP-Header-Token, oder ähnliches verwendet werden.

Kritik 4: Dateinamen

Die Dateinamen der CSV-Dateien folgen 2 Schemata, je nach dem ob man sich die Datei per Push-Service zuschicken lässt oder sie von der Web-Oberfläche herunterlädt:

1. YYYYmmdd-HHMMSS-idXXXXX_ZEITRAUM.csv (Push-Service-E-Mail)
2. $NAME_dd.mm.YYYY_HH-MM_ZEITRUM.csv (Download)

• NAME ist der eingestellte Gerätename, die ID eine willkürliche(?) Nummer. Warum ist der in der Push-Service-E-Mail nicht enthalten? Den Namen des Geräts muss man sich also anderweitig aus der E-Mail parsen, sofern man mehrere Geräte hat. Die ID taucht an keiner anderen Stelle nochmals auf.
• Warum enthält die eine Variante Sekunden, die andere nicht?
• ZEITRAUM ist 24h oder week oder month oder 2years.
  Ausnahme: Beim Push-Service ist es 1month, also mit vorangestellter 1.

Bitte vereinheitlicht die Dateinamen für den Push-Service und den Download.

Kopfzeilen

Schauen wir uns nun den Inhalt der CSV-Dateien genauer an: Diese haben grob folgenden Aufbau:

sep=;
Kopfzeile
Datenzeilen…

Kritik 5: CSV Format

CSV-Dateien sind zwar einfach zu erzeugen, aber deren Weiterverarbeitung ist alles andere als trivial, weil es viele Unterformate gibt:

• unterschiedliche Zeichenkodierungen, e.g. ASCII, UTF-8, UTF-16, ISO-8859-1, ̇…
• unterschiedliche Zeichen für den Zeilenumbruch, e.g. LF (\n), CR (\r), CR+LF (\r\n), ̇…
• unterschiedliche Trennzeichen für die Spalten: Komma (,), Semikolon (;), Tabular (\t), Leerzeichen ( ), …
• Zeichenketten in einfache (') bzw. doppelte Anführungszeichen (") einschließen oder nicht
• unterschiedliche Dezimaltrennzeichen für Zahlen, e.g. Punkt (.) oder Komma (,)
• Escape-Mechanismus für Zeichen, sie ansonsten als Trennzeichen interpretiert würden
• initiale Leerzeichen nach Trennzeichen sind relevant oder werden ignoriert
• Datei enthält eine Kopfzeile oder beginnt direkt mit der ersten Daten-Zeile

Bitte stellt die Daten in einem strukturierten Format zur Verfügung, das einfach zu verarbeiten ist und nach Möglichkeit eine eindeutige Semantik hat.

Kritik 5: CSV Trennzeichen

Die Datei beginnt mit einem sep=;. Es handelt sich um eine Excel-Erweiterung, die von vielen anderen CSV-Parsern nicht verstanden wird. Sie ist nicht Bestandteil von RFC 4180: Common Format and MIME Type for Comma-Separated Values (CSV) Files. In W3C: Model for Tabular Data and Metadata on the wird lediglich erwähnt, das manche Programm so Metadaten ablegen. Davon wird davon abgeraten, denn es führt gerne zu Problemen:

• Der Python-Parser erkennt z.B. nur Kopfzeilen, wenn sie in der ersten Zeile sind. Die zusätzliche Zeile mit dem sep=; zerstört diesen Mechanismus.

Bitte diese Zeile entfernen.

Kritik 6: Kopfzeile uneinheitlich

Als nächstes folgt die Kopfzeile. Normalerweise dient dieser der Benennung der Spalten. Hier ein paar Beispiele¹:

1            |2             |3      |4                |5      |6           |7      |8|9       |10        |11|12     |13
Datum/Uhrzeit;Verbrauchswert;Einheit;Verbrauch in Euro;Einheit;CO2-Ausstoss;Einheit; ;Ansicht:;Datum     ;  ;1 Monat;dd.mm.YYYY HH:MM Uhr
Datum/   Zeit;Energie       ;Einheit;Energie   in Euro;Einheit;CO2-Ausstoss;Einheit; ;Ansicht:;1 Monat   ;  ;Datum  ;dd.mm.YYYY HH-MM Uhr
Datum/   Zeit;Energie       ;Einheit;Energie   in Euro;Einheit;CO2-Ausstoss;Einheit; ;Ansicht:;1 Woche   ;  ;Datum  ;dd.mm.YYYY HH-MM Uhr
Datum/   Zeit;Energie       ;Einheit;Energie   in Euro;Einheit;CO2-Ausstoss;Einheit; ;Ansicht:;24 Stunden;  ;Datum  ;dd.mm.YYYY HH-MM Uhr
Datum/   Zeit;Energie       ;Einheit;Energie   in Euro;Einheit;CO2-Ausstoss;Einheit; ;Ansicht:;2 Jahre   ;  ;Datum  ;dd.mm.YYYY HH-MM Uhr

1. Spalte 1 heißt uneinheitlich mal …/Uhrzeit, manchmal nur …/Zeit.
2. Spalte 2 heißt uneinheitlich mal Energie, manchmal aber Verbrauchswert.
3. Spalten 3, 5 und 7 haben jeweils die Überschrift Einheit und geben die physikalische Einheit der Spalte davor an. Die Namen der Spalten sollten besser eindeutig sein, denn manche CSV-Parser erlauben keine doppelten Spaltennamen.
4. Spalte 4 heißt uneinheitlich Verbrauch in Euro², manchmal aber Energie in Euro³. Warum steht hier überhaupt die Einheit Euro in der Überschrift, obwohl es dafür doch eine eigene Spalte 5 gibt?
5. Spalten 8-13 sind nur in der Kopfzeile zu finden. Sie benennen hier deswegen nicht die Spalten, sondern enthalten Meta-Daten über die gesamte Datei.
6. Spalten 8 und 11 sind leer. Das verwirrt manche Parser. LibreOffice z.B. erlaubt es, solche leeren Spalten zu ignorieren.
7. Spalten 10 und 12 sind manchmal vertauscht: Manchmal steht der Zeitraum in Spalte 10, manchmal aber auch in Spalte 12.
8. Spalte 13 enthält dern Zeitpunkt, zu dem die Datei generiert wurde. Die Stunden sind von den Minuten durch unterschiedliche Trennzeichen separiert: manchmal mit einem Doppelpunkt (:), manchmal mit einem Minus-Zeichen (-).

Bitte eine einheitliche und konsistente Kopfzeile erzeugen!

Datensätze

Je nach Zeitraum haben die Datensätze ein unterschiedliches Format für die 1. Spalte mit dem Datum/[Uhr]zeit: Man benötigt also pro Format einen eigenen Parser.

Kritik 7: Tag / 24h

Die Datei mit den Datensätzen für einen Tag enthält für die letzten 24 Stunden jeweils 4 Datensätze im Abstand von 15 Minuten. Die erste Spalte sieht wie folgt aus:

23:45;…
0:00;…
jetzt;…

Ohne Kontextwissen sind diese Zeitstempeln nicht zu interpretieren:

1. Man benötigt den Erstellungszeitpunkt der Daten aus der Kopfzeile oder dem Dateinamen, um das korrekte Datum zu ergänzen.
2. Man muss selber erkennen, zwischen welchen Zeilen der Datumswechel stattgefunden hat.
3. Das jetzt erfordert eine weitere Sonderbehandlung.

Es bleibt unklar, ob die Uhrzeit sich auf den Beginn oder das Ende der Erfassungsperiode bezieht. Vermutlich das Ende, zumindest ergibt das für jetzt den meisten Sinn.

Bitte immer einen kompletten Zeitstempel bestehend aus Datum und Uhrzeit angeben.
Bitte dokumentieren, ob es sich um den Beginn oder das Ende der Erfassungsperiode handelt.

Kritik 8: Woche

Die Datei mit den Datensätzen für eine Woche enthält für die letzten 7 Tage jeweils 4 Datensätze im Abstand von 6 Stunden. Die erste Spalte sieht wie folgt aus:

12;…
18;…
Do.;…
6;…

Ohne Kontextwissen sind diese Zeitstempeln nicht zu interpretieren:

1. Man benötigt den Erstellungszeitpunkt der Daten aus der Kopfzeile oder dem Dateinamen, um das korrekte Datum zu ergänzen.
2. Statt 0 Uhr wird der Wochentag benannt, der aber ohne Kontextwissen nutzlos bleibt. Zudem ist unklar, ob der Wochentag lokalisiert ist, d.h. die Wochentage der Spracheinstellung nach unterschiedlich benannt werden.
3. Die unterschiedlichen Datentypen Wochentag und Stunde machen das Parsen nur komplizierter.
4. Die Zeilen müssen in genau dieser Reihenfolge verarbeitet werden. Sie dürfen auf keinen Fall umsortiert werden, weil die Zeile Stunden ansonsten nicht mehr eindeutig einem Wochentag zugeordnet werden können.

Es bleibt unklar, ob die Uhrzeit sich auf den Beginn oder das Ende der Erfassungsperiode bezieht. Vermutlich das Ende.

Bitte immer einen kompletten Zeitstempel bestehend aus Datum und Uhrzeit angeben.
Bitte dokumentieren, ob es sich um den Beginn oder das Ende der Erfassungsperiode handelt.

Kritik 9: Monat

Die Datei mit den Datensätzen für einen Monat enthält für die letzten 31 Tage jeweils einen Datensatz pro Tag. Die erste Spalte sieht wie folgt aus:

31.12.;…
1.1.;…

Ohne Kontextwissen sind diese Datumsangaben nicht zu interpretieren:

1. Man benötigt den Erstellungszeitpunkt der Daten aus der Kopfzeile, um das korrekte Jahr zu ergänzen.
2. Man muss selber erkennen, zwischen welchen Zeilen der Jahreswechsel stattgefunden hat.
3. Es werden immer 31 Tage gelistet, auch wenn der Monat nur 30/29/28 Tage hat. Aggregiert man mehrere Dateien, so muss man auf die Überlappung der Tage achten und diese ggf. extra behandeln.

Die Angabe bezieht sich vermutlich auf einen kompletten Tag, also von 00:00 Uhr bis 00:00 Uhr des Folgetags. Bei der Umwandung in einen Zeitstempel muß man also 00:00:00 bzw. 23:59:59 als Uhrzeit ergänzen, je nach dem ob man mit dem Anfang oder Ende rechnet.

Bitte immer einen komplettes Datum inklusive Jahreszahl angeben.

Kritik 10: Jahr

Die Datei mit den Datensätzen für die letzten 1-2 Jahre enthält für jeden Monat jeweils einen Datensatz. Die erste Spalte sieht wie folgt aus:

Mai 2023;…
Juni 2023;…

1. Es bleibt unklar, wie die Monate lokalisiert werden, d.h. wie sie je nach Spracheinstellung benannt werden.

Die Angabe bezieht sich vermutlich auf einen kompletten Monat, also von 00:00 Uhr des 1. Tags inklusive bis 00:00 Uhr des 1. Tags des Folgemonats exklusive. Im Detail bleibt aber auch hier unklar, ob intern nicht auch einfach immer mit 31 Tagen pro Monat gerechnet wird. Bei der Umwandung in einen Zeitstempel muß auch hier darauf geachtet werden, ob mit dem ersten oder letzten Tag des Monats gearbeitet wird und welche Uhrzeit verwendet wird.

Bitte Datums-Angaben nicht lokalisieren.

Fazit

Innerhalb des FRITZ-Ökosystems funktionieren die Produkte ja wunderbar miteinander, aber der Export der Daten für die Weiterverarbeitung in einem anderen System ist eine Katastrophe. Insbesondere CSV als Format sehe ich als sehr problematisch, da die Weiterverarbeitung alles andere als einfach ist. Eine fehlenden API für den Abruf der aktuellen Daten per Skript macht es noch komplizierter.

Mein in Python geschriebener Parser inklusive einigen Testfällen und Validierung der Zeichenketten bringt es aktuell auf 324 Zeilen. Nicht gerade wenig für ein Programm, dass nur CSV-Dateien parsen und sie in ein einheitliches Format bingen soll.