Messdaten aus Gebäuden sammeln: Architektur für viele Zähler
Wer Messdaten aus Gebäuden erfassen will, braucht vier Stationen: Werte annehmen und puffern, prüfen, als Zeitreihe speichern, für Verwalter und Bewohner auswerten. Den meisten Aufwand machen doppelte, fehlende und zurückgesetzte Werte.
Seit die Heizkostenverordnung fernablesbare Zähler verlangt (§ 5 HeizkostenV, Bestand nachzurüsten bis 31.12.2026) und mit § 6a eine monatliche Verbrauchsinformation vorschreibt, wächst bei Hausverwaltungen, Messdienstleistern und Betreibern von Liegenschaften die Menge an Verbrauchsdaten. Pflicht ist der Monatswert. Wer Tages- oder Viertelstundenwerte erfasst, tut das für eigene Auswertungen, etwa um Leckagen früh zu sehen.
Eine Tabellenkalkulation oder eine einzelne Datenbanktabelle reicht dafür nicht mehr. Hier geht es um die Architektur, mit der eine Plattform Zählerdaten von vielen Geräten zuverlässig verarbeitet, in vier Stationen. Welche Systeme wir in diesem Umfeld bauen, steht auf der Seite Energie und Gebäudeautomation.
Vor Station 1 · Herkunft
Woher die Werte kommen: Funk, Gateway, manuelle Ablesung
In einem gemischten Bestand kommen Messwerte auf mehreren Wegen an, oft für dieselbe Liegenschaft:
Funk im Gebäude: Wasserzähler, Wärmemengenzähler und Heizkostenverteiler senden über Wireless M-Bus (Norm EN 13757-4) an einen Sammler im Treppenhaus oder Keller. Der Sammler schickt die Telegramme gebündelt per Mobilfunk an die Plattform des Messdienstes.
Funknetze über das Gebäude hinaus: In manchen Liegenschaften laufen Zähler über LoRaWAN, ein Funknetz mit großer Reichweite und kleinen Datenmengen.
Smart-Meter-Gateway: Strom läuft dort, wo der Rollout angekommen ist, über intelligente Messsysteme nach dem Messstellenbetriebsgesetz, deren Gateway den Anforderungen der BSI-Richtlinie TR-03109 folgt. § 5 Abs. 2 HeizkostenV verlangt seit 01.12.2022 für neu eingebaute Geräte, dass sie sicher an ein Smart-Meter-Gateway angebunden werden können.
Schnittstellen der Messdienste: Oft kommen die Werte als Datei oder über eine Schnittstelle vom Messdienstleister, ohne direkten Kontakt zum Gerät.
Manuelle Ablesung: Wo noch nichts fernablesbar ist, liest jemand vor Ort ab. Im Projekt imm smartControl, das wir seit August 2021 entwickeln und das mit einem Dashboard für Messgeräte und ihre Messwerte begann, geschieht das mit einer Begleit-App: Der Techniker scannt einen NFC-Tag am Zähler, trägt den Wert ein, und die App synchronisiert ihn, auch wenn im Keller zunächst kein Empfang besteht. Das ist eine Vor-Ort-Ablesung, keine Fernablesung im Sinne der Verordnung.
Für die Architektur heißt das: Die Plattform sollte nicht an einen Weg gebunden sein. Jeder Eingang übersetzt seine Daten in ein gemeinsames Format, das mindestens Gerät, Zeitpunkt, Wert, Einheit und Herkunft enthält. Die Herkunft wird mitgespeichert, damit sich später nachvollziehen lässt, ob ein Wert gefunkt, geliefert oder abgelesen wurde. Liefern zwei Wege für denselben Zähler und Zeitpunkt unterschiedliche Werte, braucht es eine feste Rangfolge, etwa: mit Foto belegte Ablesung vor korrigierter Datei des Messdienstes vor Gateway vor Funk, und bei gleicher Herkunft gilt die spätere Lieferung, weil sie meist eine Korrektur ist. Diese Rangfolge legen Fachbereich und Entwicklung gemeinsam fest; der Tabellenentwurf weiter unten setzt sie mit einer Rangzahl je Herkunft um.
Station 1 · Eingang
Eingang puffern statt direkt schreiben
Der Eingang nimmt Werte an und bestätigt den Empfang, rechnet aber noch nichts. Er legt die Rohdaten unverändert ab und stellt einen Auftrag in eine Warteschlange. Die eigentliche Verarbeitung läuft dahinter, in eigenem Takt.
Diese Trennung hat drei Gründe:
Lastspitzen: Sammler senden oft zu festen Zeiten, viele davon gleichzeitig. Ohne Puffer trifft die ganze Welle gleichzeitig auf die Datenbank.
Wiederholbarkeit: Liegen die Rohdaten vor, lässt sich die Verarbeitung nach einem Fehler oder einer geänderten Regel erneut laufen lassen, ohne die Geräte noch einmal abzufragen.
Ausfälle von Gegenstellen: Ist ein nachgelagerter Dienst nicht erreichbar, bleibt der Auftrag in der Queue und wird später wiederholt.
Daraus folgt eine Pflicht: Die Verarbeitung muss idempotent sein, also bei doppelter Ausführung dasselbe Ergebnis liefern. Doppelte Werte sind in diesem Umfeld der Normalfall. Ein Funktelegramm wird von zwei Sammlern empfangen, ein Messdienst liefert eine Datei nach einer Korrektur erneut, eine App synchronisiert nach einem Verbindungsabbruch zweimal. Die direkteste Sicherung ist ein eindeutiger Schlüssel aus Messstelle und Zeitpunkt in der Datenbank. Welche von mehreren Lieferungen dann gilt, entscheidet die Rangfolge, nicht die Reihenfolge des Eintreffens.
Für die Mengenplanung hilft eine Rechnung mit angenommenen Werten: 2.000 Wohnungen mit je drei fernablesbaren Geräten und einem Wert alle 15 Minuten ergeben 576.000 Werte am Tag (2.000 mal 3 mal 96) und gut 210 Millionen im Jahr. Mit einem Wert pro Tag sind es 6.000 am Tag und knapp 2,2 Millionen im Jahr. Für die monatliche Verbrauchsinformation reicht meist der Tageswert. Viertelstundenwerte braucht, wer Lastgänge auswerten oder Leckagen früh erkennen will.
Station 2 · Prüfung
Plausibilisieren und Lücken erkennen
Zähler liefern in den meisten Fällen Zählerstände, also eine fortlaufend steigende Zahl. Der Verbrauch ergibt sich erst aus der Differenz zweier Stände. Daraus folgen die wichtigsten Prüfregeln:
Rückwärtslauf: Ein Stand, der kleiner ist als der vorherige, ist bei einem fortlaufenden Zähler ein Fehler oder ein Gerätetausch.
Sprung: Ein Verbrauch, der ein Vielfaches des üblichen Werts für diese Wohnung und diese Jahreszeit beträgt, wird markiert, nicht gelöscht.
Stillstand: Ein Warmwasserzähler, der in einer bewohnten Wohnung wochenlang denselben Stand meldet, ist möglicherweise defekt.
Lücke: Fehlt ein erwarteter Wert, wird das als eigener Zustand gespeichert, damit die Auswertung zwischen „kein Verbrauch“ und „kein Wert“ unterscheiden kann.
Der Gerätetausch verdient besondere Aufmerksamkeit. Wird ein Zähler ersetzt, beginnt der neue meist bei null oder einem Startwert. Ein System, das nur „Zähler der Wohnung 12“ kennt, rechnet dann einen negativen oder absurd hohen Verbrauch. Sauber wird es, wenn das Datenmodell die Messstelle (der Ort in der Wohnung) vom Gerät (die Seriennummer) trennt und jeder Tausch mit Datum, Endstand des alten und Anfangsstand des neuen Geräts erfasst wird. Der Verbrauch im Tauschmonat setzt sich dann aus zwei Teilstrecken zusammen.
Werte, die eine Prüfung nicht bestehen, bleiben gespeichert und tragen einen Status. Ersatzwerte, etwa geschätzte Verbräuche bei Lücken, werden als solche gekennzeichnet und nie mit gemessenen Werten vermischt. Für Abrechnungen ist später nachweisbar, welche Zahl gemessen und welche geschätzt war.
Station 3 · Ablage
Speichern und verdichten
Zählerdaten sind Zeitreihen: Viele kleine Werte, die fast nur angehängt und selten geändert werden, und Abfragen, die meist nach Zeiträumen filtern. PostgreSQL bringt dafür drei Bausteine mit:
Partitionierung nach Zeit: Die Tabelle wird in Monats- oder Jahresabschnitte geteilt. Abfragen auf einen Monat lesen nur diesen Abschnitt, und alte Abschnitte lassen sich als Ganzes archivieren.
Passende Indizes: Ein Index auf Messstelle und Zeitpunkt deckt die meisten Abfragen ab. Welcher Indextyp wann hilft, steht unter PostgreSQL-Indexing für Laravel-Apps.
Verdichtung: Aus Viertelstundenwerten werden Tages- und Monatssummen, die Dashboards und Verbrauchsinformationen lesen. Die Erweiterung TimescaleDB bietet dafür kontinuierliche Aggregate, die sich im Hintergrund aktualisieren. Ohne Erweiterung erledigt das ein geplanter Auftrag, der verdichtete Tabellen füllt.
Ob eine eigene Zeitreihen-Datenbank wie InfluxDB nötig ist, hängt von der Menge ab. Für einige Millionen Werte im Jahr reicht eine gut geplante PostgreSQL-Tabelle, und Stammdaten, Mietverhältnisse und Messwerte bleiben in einer Datenbank, was Auswertungen und Zugriffsrechte vereinfacht.
Ein Entwurf für die Messwerte, gekürzt auf das Wesentliche. Er setzt drei Regeln aus diesem Text um: Rohdaten bleiben unverändert in einer eigenen Tabelle, damit sich die Verarbeitung wiederholen lässt. Die gültige Tabelle ist nach Messstelle geschlüsselt, das Gerät steht als eigene Spalte daneben, damit ein Gerätetausch die Zeitreihe nicht zerreißt. Und eine neue Lieferung ersetzt einen vorhandenen Wert nur, wenn sie nach der Rangfolge vorgeht oder bei gleicher Herkunft später geliefert wurde:
-- Stammdaten (hier nicht ausgeführt): measuring_points (Ort in der Wohnung),
-- devices (Seriennummer), device_installations (Ein- und Ausbau mit Zählerstand)
-- 1. Jede Lieferung unverändert, auch Dubletten und Korrekturen
CREATE TABLE readings_raw (
id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
device_id bigint NOT NULL REFERENCES devices (id),
read_at timestamptz NOT NULL,
value numeric(14,3) NOT NULL,
unit text NOT NULL,
source text NOT NULL, -- radio, gateway, provider_file, manual
payload jsonb, -- Originaltelegramm oder Dateizeile
received_at timestamptz NOT NULL DEFAULT now()
);
-- 2. Ein gültiger Wert je Messstelle und Zeitpunkt
CREATE TABLE readings (
measuring_point_id bigint NOT NULL REFERENCES measuring_points (id),
read_at timestamptz NOT NULL,
device_id bigint NOT NULL REFERENCES devices (id),
value numeric(14,3) NOT NULL,
unit text NOT NULL,
source text NOT NULL,
source_rank smallint NOT NULL, -- 1 radio, 2 gateway, 3 provider_file, 4 manual mit Foto
status text NOT NULL DEFAULT 'ok', -- ok, flagged, estimated
received_at timestamptz NOT NULL, -- aus readings_raw, nicht now()
raw_id bigint NOT NULL,
PRIMARY KEY (measuring_point_id, read_at)
) PARTITION BY RANGE (read_at);
CREATE TABLE readings_2026_06 PARTITION OF readings
FOR VALUES FROM ('2026-06-01') TO ('2026-07-01');
-- Auffangpartition: Werte ohne passende Monatspartition gehen nicht verloren
CREATE TABLE readings_default PARTITION OF readings DEFAULT;
-- 3. Übernahme aus readings_raw: Rang vor Eingang, bei gleichem Rang gilt die spätere Lieferung
INSERT INTO readings AS r
(measuring_point_id, read_at, device_id, value, unit, source, source_rank, received_at, raw_id)
VALUES (812, '2026-06-03 00:00:00+00', 4711, 1234.567, 'm3', 'provider_file', 3,
'2026-06-04 06:12:00+00', 99812)
ON CONFLICT (measuring_point_id, read_at) DO UPDATE
SET device_id = EXCLUDED.device_id,
value = EXCLUDED.value,
unit = EXCLUDED.unit,
source = EXCLUDED.source,
source_rank = EXCLUDED.source_rank,
received_at = EXCLUDED.received_at,
raw_id = EXCLUDED.raw_id,
status = 'ok'
WHERE EXCLUDED.source_rank > r.source_rank
OR (EXCLUDED.source_rank = r.source_rank AND EXCLUDED.received_at > r.received_at);
Zum Entwurf
Was der Entwurf absichtlich offen lässt
Die Messstelle für einen Gerätewert ergibt sich aus device_installations: das Gerät, das zum Zeitpunkt des Werts an dieser Messstelle eingebaut war. Weil received_at aus der Rohtabelle kommt und nicht aus der Uhrzeit der Verarbeitung, liefert ein zweiter Lauf über dieselben Rohdaten dasselbe Ergebnis; eine exakt doppelte Lieferung ändert nichts. Ein vom Menschen gesetzter Status wie „flagged“ wird bei einer Korrektur zurückgesetzt und muss neu geprüft werden.
Die Auffangpartition verhindert, dass ein Wert mit unerwartetem Datum den Import abbricht. Sie ersetzt aber nicht das Anlegen der Monatspartitionen: Das erledigt ein geplanter Auftrag im Voraus, denn PostgreSQL lehnt eine neue Partition ab, solange die Auffangpartition schon Zeilen für diesen Zeitraum enthält. Liegen dort Werte, werden sie vorher umgezogen.
Station 4 · Auswertung
Auswertungen für Verwalter und Bewohner
Die Auswertung ist der Teil, den Menschen sehen, und sie hat zwei sehr unterschiedliche Zielgruppen.
Verwalter und Eigentümer brauchen den Überblick über viele Liegenschaften: Welche Geräte melden sich nicht mehr, wo fehlen Werte für die Abrechnung, wo ist der Verbrauch auffällig hoch? Für sie zählen Listen mit Handlungsbedarf mehr als schöne Diagramme. Die Mandantentrennung muss dabei sauber sein: Ein Verwalter sieht nur seine Liegenschaften, ein Eigentümer nur seine Einheiten.
Bewohner brauchen die monatliche Verbrauchsinformation. § 6a Abs. 2 HeizkostenV verlangt unter anderem den Verbrauch des letzten Monats in Kilowattstunden und Vergleiche mit Vormonat, Vorjahresmonat und einem Durchschnittsnutzer. Für die Software heißt das: Heizkostenverteiler liefern Einheiten, keine Kilowattstunden. Die Umrechnung und der Vergleichswert müssen irgendwo hinterlegt und dokumentiert sein, sonst lässt sich die Information nicht erzeugen.
Zwei Details machen die Auswertung belastbar. Zeitpunkte werden in UTC gespeichert und erst für die Anzeige in deutsche Zeit umgerechnet, sonst entstehen bei der Zeitumstellung doppelte oder fehlende Stunden. Und jede Zahl in einer Auswertung lässt sich bis zu den Rohwerten zurückverfolgen, mit Status und Herkunft. Wenn ein Bewohner eine Verbrauchsinformation anzweifelt, ist das die Antwort.
Kurz beantwortet
Häufige Fragen
-
Für die meisten Bestände von Hausverwaltungen trägt PostgreSQL mit Partitionierung nach Zeit, passenden Indizes und verdichteten Tabellen, auf Wunsch mit der Erweiterung TimescaleDB. Eine spezialisierte Zeitreihen-Datenbank rechtfertigt den zusätzlichen Betrieb erst bei sehr hohen Schreibraten. Ein Vorteil von PostgreSQL ist, dass Stamm- und Messdaten in einer Datenbank bleiben.
-
Fehlende Werte werden als eigener Zustand gespeichert, nicht als Null. Für Auswertungen kann ein Ersatzwert berechnet werden, etwa aus dem Verlauf davor und danach, er bleibt aber als geschätzt gekennzeichnet. So ist jederzeit nachvollziehbar, welche Zahl gemessen und welche ergänzt wurde.
Messdaten, auf die Verlass ist
Wir planen mit Ihnen die Strecke vom Zähler bis zur Auswertung, binden Messdienste und Geräte an und bauen Prüfregeln, die doppelte und fehlende Werte sauber behandeln.
Nachweise
Quellen und Stand
Stand: 03.06.2026. Fristen und Inhalt der Verbrauchsinformation laut §§ 5 und 6a HeizkostenV im Wortlaut. Die Mengenrechnung beruht auf angenommenen Werten. Der Tabellenentwurf ist ein gekürztes Beispiel, kein vollständiges Datenmodell; die Rangfolge der Herkünfte ist eine Annahme, die jedes Projekt selbst festlegt. Projektangaben zu imm smartControl laut Projektseite.
Weiterlesen:
MySQL oder PostgreSQL vom 18.06.2026: die Wahl zwischen den beiden Datenbanken.
Zeitumstellung in Software vom 19.10.2026: warum Zeitpunkte in UTC gehören.
Artikel teilen