Alternative Infrastruktur für Discovergy

Seit der Insolvenz der Discovergy GmbH häufen sich die Probleme. Mal ist die API nicht verfügbar, mal wird der Turnswechsel für einen aus der Eichung gelaufenen Zähler einfach storniert (mir gerade passiert). Recht schnell wird der Wunsch nach einer Alternative laut und am besten eine Alternative, bei der man selbstbestimmter und damit nachhaltiger sein Messwesen organisieren kann.

Dieser Beitrag richtet sich an bestehende Nutzer der Messdienstleistung von Discovergy (Zähler+Gateway+X), die wissen wollen, was man selbst machen kann. Es handelt sich nicht um eine schnelle Anleitung, die man in ein paar Minuten umsetzen kann, sondern vielmehr um ein Konzept, welches man selbst mit Leben befüllen darf/kann. Bei der Umsetzung in der Praxis hilft mein Unternehmen, die STROMDAO GmbH, gerne, denn dort beschäftigen wir uns seit einigen Monaten ausgiebig damit, unser Angebot trotz Discovergy innovativ und zukunftssicher zu gestalten.

Architektur

Das Produkt von Discovergy ist nicht nur ein Zähler. Das Gesamtprodukt oder der Service besteht aus dem Zähler, einer Übertragungskomponente (Gateway), dem Server/Service, der die Daten bei Discovergy entgegennimmt, einer großen Datenbank mit Messdaten beim Unternehmen, die letztendlich ihre Daten entweder über ein Portal oder über die API den zahlenden Kunden zur Verfügung stellt.

Keine dieser Komponenten ist alternativlos. Vielmehr ist es so, dass die Kerninfrastruktur von Discovergy die erste auf dem Markt gewesen ist und Standards, wie “Intelligente Messsysteme” erst einige Jahre später definiert wurden. Dies ist hat zur Folge, dass die Basisarchitektur etwas in die Jahre gekommen aussieht und sich mit einigen Open-Source Lösungen recht leicht nachbauen lässt.

Bislang gehen wir davon aus, dass die Zähler selbst bleiben sollen. D.h. ab der Schnittstelle auf der Oberseite des Easymeter alles ersetzt wird und möglichst viel “In-House” geschieht und nicht über das Internet übertragen werden muss.

Von der Hardware ergeben sich folgende Komponenten:

EASY-WM20
Raspberry PI 4.0 mit ausreichen Disc-Space
Wireless-MBUS Dongle für den Raspberry PI

Vorteile dieser Architektur

Selbst bei schlechter Internetanbindung (LTE, DSL,…) funktioniert alles sehr reibungslos. Die Messdaten können so auch für EnergieManagement genutzt werden, um intelligente Schaltungen vorzunehmen, wie die Steuerrung der Wärmepumpe oder des E-Auto mit Überschüssen der Photovoltaikanlage.

Geht an dieser Hardware etwas kaputt, so kann man selbst diese austauschen und spielt einfach das (hoffentlich vorhandene) Backup ein.

Nachteile dieser Architektur

Es handelt sich um eine eigene Lösung, die so nicht auf zukünftige Zählergenerationen oder der Wechsel auf intelligente Messsysteme (ImSyS) ausgelegt ist. Zudem hat man natürlich selbst die Verantwortung für den Betrieb, was nicht nur Zeit, sondern vor allem auch etwas Tüftelfieber bedarf.

Anstelle des EASY-WM20 kann man daher auch einer der vielen Leseköpfe verwenden, welche es beim Elektroniker des Vertrauens gibt (und recht leicht selbst gebaut werden kann).

Ein weiterer Nachteil ist, dass es keine Cloud-Infrastruktur ist. D.h. der Vorteil, dass die Daten In-House bleiben, wird zum Nachteil, wenn man zum Beispiel mehrere Standorte damit überwachen möchte. In diesem Fall reicht es jedoch, wenn die Messdaten auf einen eigenen Cloud-Server übertragen werden und dort die Komponenten installiert werden.

Software

Wir nutzen bei uns zunächst Node-RED, um die Daten (Telegramme) der Zähler entgegenzunehmen und in ein Format umzuwandeln, die in eine Datenbank gespeichert werden kann. Dies hat sich als relativ praktisch erwiesen, da wir so auch andere Zähler wie Janitza Zähler anbinden können, ohne eine andere Komponente des Systems anfassen zu müssen.

Für eine kleine Anzahl von Zähler (bis ca. 100.000) ist eine Zeitreihendatenbank absolut von Vorteil. Hier kommt InfluxDB zum Einsatz. Da wir meist mehrere Datenbankserver parallel haben (in einer Cloud-Lösung), schaffen wir es so auch mehr Zähler über dieses System zu betreiben. Die Unterscheidung, welche Instanz welche Daten bekommt, übernimmt bereits Node-RED in einem sogenannten Flow.

Neben den Messdaten sollte es immer auch eine Datenbank geben, welche die Stammdaten pflegt. Dies kann bei kleinen Installationen mit sehr wenig Zählern (<10) auch gut innerhalb von Node-RED über das Dateisystem geschehen. Bei mehr Zählern haben wir bislang immer NoSQL basierend auf MongoDB genutzt.

Für die Visualisierung nutzen wir Grafana. Dies ist an die InfluxDB angebunden und erlaubt sehr schnell individuelle Dashboards zu erzeugen. Hier sehen wir einen großen Vorteil, da etliche Informationen, die zum Beispiel bei der Inbetriebnahme einer Wallbox benötigt werden, nicht im Standard Discovergy-Portal vorhanden sind. Mit Grafana sind sie lediglich ein paar Mausklicks entfernt.

Fazit zur alternativen Infrastruktur

Der Aufwand für den Aufbau und die Kosten halten sich in Grenzen. Ein Raspberry PI als Datendrehscheibe reicht für alle Fälle, bei denen Discovergy lediglich an einem Anschluss eingesetzt wird. Die Erweiterung auf eine Cloud ist optional möglich, da nur Standardkomponenten eingesetzt werden, bei denen man zur Not ein paar YouTubes schauen kann.