Viele Wechselrichter oder Messsteckdosen liefern Momentanwerte der Leistung, beispielsweise 350 W. Ich benötige jedoch häufig nur die kumulierten Werte in Form von Zählerständen, d. h. die kumulierte Energie über einen bestimmten Zeitraum in Kilowattstunden.

Dazu braucht man im Prinzip nur die Leistungswerte mit einem Zeitstempel.

Im folgenden Artikel beschreibe ich, wie ich das mit Node-Red gelöst habe. Das Prinzip ist auf viele andere Geräte übertragbar, die keine Zählerstände liefern.

Grundprinzip

Ein Zendure-Hyper-2000-Wechselrichter liefert über die Cloud nur die erzeugte Leistung per MQTT zu einem bestimmten Zeitpunkt, nicht aber einen Zählerstand, anhand dessen ich die erzeugte Energie beispielsweise an einem Tag ablesen könnte.

Dabei lassen sich Energie und Zählerstand recht einfach aus der Leistung berechnen. Die dazu benötigten Werte lassen sich physikalisch wie folgt beschreiben (vereinfacht):

• Leistung (Watt) = Spannung * Stromstärke (z.B. in Watt)
• Energie (kWh) = Leistung * Zeit in einem Zeitintervall (z.B. in Kilowattstunden)
• Zählerstand =  Summe der Energiewerte in Zeitintervallen (z.B. in Kilowattstunden)

Eine Lampe, die eine Stunde lang eingeschaltet ist und 500 Watt benötigt, verbraucht somit eine Energie von 0,5 kWh. Wäre die Lampe dimmbar und würde sie nach einer halben Stunde auf 250 Watt gedimmt werden, würde sie in der ersten halben Stunde 0,25 kWh und in der zweiten halben Stunde 0,125 kWh, also insgesamt 0,375 kWh, verbrauchen.

Ein Wechselrichter produziert in relativ kurzen Zeitabständen unterschiedliche Leistungen, sodass ich die Energie für viele kleine Zeitintervalle berechnen und aufsummieren muss. Mathematisch entspricht dies einer Integralfunktion über ein Rechteck. Da jeder übermittelte Leistungswert einen Zeitstempel besitzt, können die erforderlichen Daten schnell ermittelt werden.

Voraussetzungen

Ich realisiere die Berechnung in Node-Red und speichere die Zählerstände in eine InfluxDB-Datenbank. Grundsätzlich speichere ich nur die resultierenden Zählerstände in der Datenbank ab, indem ich die Energie des letzten Zeitraums hinzufüge.

Im Programm benutze ich einige Flow-Variablen, das heißt, diese speichern Werte zwischen, die beim nächsten Programmdurchlauf verwendet werden, wenn ein neuer Leistungswert geliefert wird. Diese Variablen sind:

Flowbeschreibung

Die Verarbeitung und Speicherung der Daten erfolgt durch einen Flow, dessen Struktur wie folgt ist:

Von meinem Wechselrichter erhalte ich per MQTT-Abfrage eine Vielzahl von Werten als Input. Aus diesen extrahiere ich im nächsten Function-Node zuerst die aktuelle Leistung.

In der Funktion „Energie berechnen” ermittele ich die Energie im letzten Zeitintervall. Mit dem anschließenden Switch-Node teste ich, ob die Variable „f_Zaehlerstand” vorhanden ist (Bedingung für Ausgang 1: „ist nicht Null”, für Ausgang 2: „ansonsten”). Warum mache ich das?

Für die Zählerstandsermittlung hole ich mir initial immer den Zählerstand aus der Datenbank und rechne dann mit Flow-Variablen in Node-Red weiter. Dadurch spare ich mir bei jedem Durchlauf die Datenbankabfrage des letzten Zählerstandes, die nur Zeit kostet. Allerdings muss ich am Anfang (nach einem Neustart von Node-Red) den Zählerstand einmal in die Variable laden. Dies stelle ich mit dem Switch-Node fest, der einfach prüft, ob die Variable „f_Zaehlerstand” einen Wert größer 0 liefert. Falls nicht, führe ich eine Abfrage der InfluxDB-Datenbank mit dem „influxdb in“-Node „Letzten Zählerstand auslesen“ und dem Function Node „Letzten Zählerstand zwischenspeichern“ aus. In diesem speichere ich den letzten Zählerstand aus der Datenbankabfrage in der Variablen „f_Zaehlerstand”.

Liefert der Switch-Node das Ergebnis „>0”, wurde eine korrekte Energieberechnung durchgeführt. Im nächsten Funktionsknoten „Zähler hochsetzen” addiere ich die beiden Variablen „f_letzterZaehlerstand” und „f_energiekWh” und erhalte somit den neuen Zählerstand, den ich im anschließenden „InfluxDB Out”-Knoten in die Datenbank schreibe.

Berechnung

Im Folgenden ist die Vorgehensweise bei der Berechnung in dem Function-Node "Energie berechnen" kurz beschrieben:

1. Zunächst wird die Leistung ausgelesen und ein Zeitstempel erzeugt.
2. Anschließend werden die Flow-Variablen ausgelesen und zwischengespeichert.
3. Nun erhalten die Flow-Variablen die aktuelle Leistung und den aktuellen Zeitstempel.
4. Danach wird geprüft, ob es sich um die erste Messung handelt. Dies kann mittler der Variablen f_Zaehlerstand erfolgen, die bei der ersten Messung noch nicht ermittelt ist (z. B. nach einem Neustart von Node-Red). Falls ja, wird die Funktion abgebrochen (die
5. Erläuterung erfolgt weiter hinten).
6. Anschließend wird die Zeitdifferenz zwischen dem letzten und dem aktuellen Zeitwert berechnet (auch in Stunden).
7. Schließlich kann die Energie in Wattstunden berechnet werden.
8. Das Ergebnis wird von der Funktion zurückgeliefert.

Der gesamte Ablauf kann selbstverständlich noch vereinfacht werden. Ebenso sind Erweiterungen denkbar. So habe ich beispielsweise eine kleine Absicherung eingebaut, falls die Datenbank nicht beschrieben werden kann (z. B. aufgrund eines Connection-Errors). In diesem Fall werden die Energiewerte zwischengespeichert, bis ein erneutes Schreiben möglich ist.

Neben den großen Batteriespeichern für fertige PV-Anlagen setzen sich zunehmend modulare Hybridsysteme mit AC/DC- und DC/AC-Wandlern durch. Diese ermöglichen das Laden mit Gleichstrom aus den Solarpanels sowie das Laden mit überschüssigem Wechselstrom aus dem Hausnetz. Damit kann der Strom aus alten Solaranlagen, die aus der Förderung fallen, ebenso wie der Strom aus Balkonkraftwerken, der sonst meist kostenlos ins Netz geht, einfach für den Eigenverbrauch genutzt werden.

Ein großer und seit Jahren aktiver Hersteller ist die Firma Zendure aus dem Silicon Valley.

Für viele Speichermodelle bietet Zendure eine API an, mit der über die Hersteller-Cloud auf Daten des Speichers zugegriffen werden kann. Nach Aussagen des Herstellers funktioniert das für die folgenden Speichertypen

• SuperBase V (6400, 4600)
• Satellite Battery (6400, 4600) und
• SolarFlow (800, 800 Pro, 2400 AC, Hyper 2000) und
• SuperBase V (6400, 4600).

Wer möchte, kann die Cloud auch komplett aussperren. Dies ist beispielsweise in folgendem Beitrag von Tobias Schulz beschrieben. Dann hat man jedoch keinen Zugang zur gut gemachten App sowie zur KI-basierten Speicherverwaltung. In diesem Beitrag zeige ich wie ich einen Zendure Hyper 2000 mit Speicher über die Hersteller Cloud mit Node-Red abfrage. Zendure stellt hierzu eine kleine Dokumentation unter github zur Verfügung.

Cloud Verbindung herstellen

Für die Inbetriebnahme eines Geräts (Wechselrichter und Batteriespeicher) ist das Anlegen eines Accounts in der Cloud des Herstellers und die Registrierung der Geräte erforderlich (Link). Ebenso muss die Zendure-App installiert werden, um die Geräte anzumelden und notwendige Firmware-Updates auf Speicher und Wechselrichter einzuspielen. Darüber hinaus ermöglicht der Zugang über die App den Abruf sämtlicher Statusdaten und Statistiken der registrierten Geräte. Die App hat mittlerweile einen sehr guten Entwicklungsstand erreicht, der eine komfortable Steuerung und Auswertung der Leistungsdaten ermöglicht. Für weitere Informationen verweise ich auf die Webseite des Herstellers.

Nach der Registrierung und Inbetriebnahme des Hyper2000-Wechselrichters über die App kann durch Klicken auf das Zahnradsymbol oben rechts die Seriennummer des Geräts aufgerufen werden. Diese steht sowohl unter dem Gerätenamen als auch unter dem Menüpunkt „Gerätedaten“.

Grundsätzlich kommunizieren die Zendure Geräte über einen MQTT-Broker, der in meinem Fall in der Zendure-Cloud liegt. Für diesen brauche ich Zugangsdaten, damit ich Daten von meinen Geräten abfragen kann.  Mit der Seriennummer und dem Accountnamen kann nun ein Request an die Zendure-Cloud gesendet werden, um die Zugangsinformationen für eine sichere Abfrage aus Node-Red zu erhalten.

Die Abfrage kann beispielsweise mit einem cURL-Befehl durchgeführt werden. Ich verwende stattdessen eine Abfrage mit Node-Red.Hierzu benötige ich nur 3 Nodes.

Im inject-Node gebe ich als JSON-Objekt die Seriennummer sowie den Accountnamen wie folgt an:

Diesen Inhalt schicke ich nun an einen HTTP-Request-Node, und zwar als POST-Befehl an die Adresse https://app.zendure.tech/eu/developer/api/apply.
Für den Output verwende ich einen Debug-Node.

Nun erhälte ich im Node-Red Debug-Fenster einen String zurück, der wie folgt aussieht:

Hiervon sind folgende Teile wichtig:

• appKey: Der Accountname für die Anmeldung in der Cloud
• secret: Das Passwort für die Anmeldung  in der Cloud
• mqttUrl: Die URL des MQTT-Servers für die Datanabfrage

Nun sind alle Daten vorhanden, die man für eine weitere Abfrage benötigt.

von dem folgende Daten wichtig sind:

Daten abfragen

Um die Daten für das Gerät aus der Zendure-Cloud empfangen zu können, muss eine Abfrage beim MQTT-Server von Zendure erfolgen.

Dazu verwendet man einen MQTT-In-Node, für den man zunächst eine Verbindung mit den folgenden Daten einrichtet:

• Name: beliebig
• Server: mqtt-eu.zen-iot.com
• Port: 1883
• Connect automatically
• Protokoll: MQTT V3.1.1
• Bereinigte Sitzung verwenden

Unter dem Reiter „Sicherheit” werden folgende Daten angegeben:

• Benutzername: appkey (Der Accountname, den man von Zendure erhalten hat
• Passwort: secret (Das Passwort, was man von Zendure erhalten hat)

Im MQTT-IN Node werden folgende Eigenschaften eingetragen:

• Action: Subscribe to single topic
• Topic: appkey/#       (z.B. rtP7zHkq/#)
• QoS: 2
• Ausgang: Auto-Erkennung (parsed JSON Objekt, string oder buffer)

Nun sollte der Empfang funktionieren und die ersten Wert per payload-Objekt geliefert werden.

Daten auswerten

Beim Auswerten der empfangenen Daten stellt man schnell fest, dass immer nur Daten empfangen werden, die sich seit dem letzten Mal verändert haben. Damit enthält die payload immer eine unbestimmte Zahl von Einträgen mit jeweils unterschiedlichen Attributen.  Ebenso kann es durch die Cloudabfrage auch einen Zeitverzug ergeben (der für mich aber irrelevant ist). Ich habe festgestellt, dass für eine Hyper2000 neben der Seriennummer folgende Daten übertragen werden:

• remainOutTime ( Remaining discharge time in min = verbleibende Entladezeit)
• packInputPower (pack input power)
• electricLevel (Device battery percentage = Ladezustand der Batterie)
• solarPower1 (Solar1 Input Power in Watt = Leistung aus erstem Wechselrichter)
• solarPower2 (Solar2 Input Power in Watt = Leistung aus zweiten Wechselrichter)
• outputHomePower (output to home power in Watt = abgebene Leistung ins Hausnetz)
• hyperTmp (hyperTmp
• solarInputPower (solarInputPower = Leistung die gerade durch solarPanels in Speicher geladen wird)
• packState (packState = Gibt an, ob in Batterie gerade nichts passiert (0), geladen(1) oder entladen(2) wird)

Da es möglich ist, dass der Wert gar nicht geliefert wurde, muss man in einem anschließenden Switch-Node prüfen, ob das Ergebnis NULL ist. Anschließend kann der Wert weiterverarbeitet werden (z. B. in InfluxDB etc.)

Dies ist eine sehr einfache Lösung für die Auswertung, die natürlich durch eine effizientere Lösung mit weniger Redundanz ersetzt werden kann.

Interessant ist, dass Zendure keinen Zähler übergibt, der die Menge des von einer direkt angeschlossenen Photovoltaikanlage erzeugten Stroms in kWh misst. In der App ist ein solcher Zähler allerdings vorhanden. Zendure liefert stattdessen die jeweilige Leistung der PV-Module. In einem nächsten Beitrag zeige ich, wie sich aus der Leistung trotzdem Zählerstände berechnen lassen.

Mit einer Photovoltaikanlage wird vor allem in den warmen Monaten mehr Strom erzeugt als gespeichert oder verbraucht werden kann. Da es sich kaum lohnt, den Strom zu verkaufen, ist es besser, ihn zu verbrauchen. Was liegt da näher, als die Räume im Sommer mit Klimaanlagen kostenlos zu kühlen. Der folgende Beitrag zeigt, wie man mit einfachen Mitteln eine Split-Klimaanlage in das Smarthome-System Node-Red integrieren und den Stromüberschuss zum Kühlen nutzen kann.

Klimaanlage extern steuern

Die grundsätzliche Frage ist, wie eine Klimaanlage in ein Smarthome-System eingebunden werden kann. Sofern der Hersteller keine spezielle Schnittstelle zur Verfügung stellt (z.B. Modbus, etc.), ist die einfachste Möglichkeit, die Infrarotschnittstelle zur Fernbedienung des Klimagerätes zu nutzen. Die meisten Geräte verfügen über eine Infrarot-Fernbedienung, die bestimmte Infrarotsignale aussendet, um verschiedene Befehle an die Klimaanlage zu senden. Einige Fernbedienungen sind sogar bidirektional, d.h. sie können auch Statusinformationen von der Klimaanlage empfangen. In diesem Beispiel ist eine unidirektionale Fernbedienung ausreichend. Benötigt wird also ein Gerät, das  Signal der Klimaanlagen-Fernbedienung senden und über eine API von außen gesteuert werden kann. Mittlerweile gibt es eine Vielzahl von Geräten, die jedoch nicht mit allen Klimaanlagen funktionieren. Dazu habe ich einige Versuche unternommen.

1. Versuch

Als erstes Gerät habe ich den ELV Smart Home Bausatz IR-Sender ELV-SH-IRS8 getestet, da dieser direkt von einer HMIP-CCU angelernt werden kann. Leider stellte sich im Nachhinein heraus, dass meine Mitsubishi Heavy Industries Anlage nicht unterstützt wird. Außerdem muss man etwas Löterfahrung mitbringen, um das Gerät zusammenbauen zu können. Insgesamt ist die Auswahl der unterstützten Klimagerätehersteller überschaubar.

2. Versuch

Dann habe ich das BroadLink RM mini 3 getestet. Das Gerät heißt nicht nur so, sondern ist auch mini. Allerdings ist die Einrichtung ziemlich kompliziert. Um das WLAN einzurichten und die Klimaanlage anlernen zu können musste ich mehrere Apps benutzen, die teilweise nicht gut gepflegt waren. Die Anleitung selbst war nicht optimal und die blaue Status-LED am Gerät kaum erkennbar. Auch brach die WLAN-Verbindung zwischendurch immer wieder ab. Positiv war, dass eine große Anzahl von Klimaanlagen unterstützt wird. Allerdings habe ich keine brauchbare Node-Palette für Node-Red gefunden, mit der man das Gerät mit Node-Red steuern kann.

3. tado bietet die bisher beste Lösung

Schließlich bin ich bei tado gelandet. Diese bieten die Smarte Klimaanlagen Steuerung V3+ an. Um zu prüfen, ob mein Gerät überhaupt unterstützt wird, habe ich vor dem Kauf den Support (gelber Button unten rechts auf der Webseite) kontaktiert, da tado keine Kompatibilitätsliste veröffentlicht hat. Innerhalb kurzer Zeit hat jemand meine Angaben zur Fernbedienung und zum Hersteller der Klimaanlage aufgenommen und nach einem Tag hatte ich die Rückmeldung, dass meine Anlage unterstützt wird.  Die tado Lösung ist eine Cloud-Lösung, d.h. man muss auf jeden Fall einen Account anlegen und eine App installieren. Für Node-Red gibt es  zusätzliche Nodes, um dieses und andere Geräte steuern zu können.

tado legt großen Wert auf Design und einfache Bedienung, was man schon beim Auspacken merkt. Die Einrichtung ist komplett menügeführt und für den  Notfall gibt es auf der Webseite eine Anleitung. Folgende Tipps kann ich noch geben:

• Sowohl tado als auch broadlink wollen das Gerät mit dem 2,4 GHz WLAN verbinden. Wer sowohl ein 2,4 GHz als auch ein 5 GHz LAN mit dem gleichen Namen nutzt, dem empfehle ich das 5GHz LAN kurzzeitig zu deaktivieren, damit der Verbindungsaufbau fehlerfrei funktioniert.
• Bei tado wollte mein Gerät nach Aufbau der WLAN-Verbindung ein Update installieren. Dies funktionierte aber nicht, das Gerät blieb ständig im Installationsmodus. Nach mehreren Stunden kontaktierte ich erneut die tado-Hotline (gelber Button), die aus der Ferne die Installation starten konnte.

Danach konnte das Klimagerät mit einem einfachen Tastendruck auf der Fernbedienung identifiziert und automatisch eingerichtet werden. So sollte es sein!

Wer weitere einfach einzurichtende Verbindungen für Klimaanlage kennt, kann diese gerne hier posten!

Stromverbrauch auslesen

Um die Klimaanlage nur bei Stromüberschuss einschalten zu können benötige ich zunächst den jeweils aktuellen Stand meines  Saldos aus Stromverbrauch und Stromerzeugung am Zähler. Wie das geht, habe ich in dem folgenden Artikel beschrieben: SmartMeter mit Tasmota auslesen. Dieser Wert wird automatisch an den MQTT-Broker gesendet. Diesen rufe ich mit Node-Red bei jeder Änderung ab und speichere ihn zwischen. Wie man die Daten von einem MQTT-Server abruft habe ich im folgenden Beitrag Mit Node-Red, InfluxDB und Grafana Daten auf einem Synology NAS sammeln und visualisieren (Teil 2/2) im Kapitel MQTT-Nachrichten mit Node-Red auslesen und in influxDB speichern beschrieben.

Der Code im Function-Node sieht wie folgt aus:

Ich extrahiere den relevanten Wert aus dem MQTT-Objekt und speichere ihn in einer Flow-Variablen. So kann ich auf diesen Wert zugreifen, ohne den MQTT-Broker erneut zu fragen. Das Ergebnis gebe ich zur Kontrolle mit einem Debug-Node im Debug-Fenster aus.

Anmelden bei tado

Um das tado-Gerät von Node-Red aus steuern zu können, installiere ich die Erweiterung node-red-contrib-tado-client. Ich rufe den neu installierten Tado-Node auf und gebe als erstes unter "Tado Config" meine Anmeldedaten für die Tado Cloud ein, da ich dort zuvor mein Gerät angelegt habe.

Wichtige Ergänzung (Juni 2025)

Tado hat mittlerweile die Authentifizierung geändert und nutzt nun das OAuth2-Verfahren, um einen Zugriff auf die Rest-API zu ermöglichen. Nähere Infos dazu findet man unter:

https://support.tado.com/en/articles/8565472-how-do-i-authenticate-to-access-the-rest-api

https://datatracker.ietf.org/doc/html/rfc6749#page-48

Wer die alte Version der Library noch installiert hat, muss mindestens auf die Version V1.1.4 updaten. Ich empfehle ebenfalls das Lesen der Library-Informationen bzgl. weiterer Neuerungen.

Zur Nutzung sollte der Beispielflow tado.json von der Library aus GitHub in NodeRed geladen werden, denn hier befinden sich auch weitere Erläuterungen zur Einrichtung.

Auf der Beispiel-Flow-Seite befinden sich nun drei Bereiche:  "Authentication Flow", "Persistent Auth" und "Testing".

Durch Drücken des „Inject“-Nodes im Authentication Flow wird ein Debug Output erzeugt. In diesem steht ein Link. Diesen ruft man in einen beliebigen Browser auf. Wenn man noch nicht bei tado angemeldet ist, dann gibt man zuerst seinen Login-Namen und sein Passwort an. Anschließend bestätigt man nur den angezeigten Code und tado meldet „Erfolgreich verbunden“. Nun steht im Debug-Fenster in NodeRed der "Refresh_Token", mit dem man die weiteren API-Aufrufe vornehmen kann (hierzu empfehle ich, das nächste Kapitel zu lesen).

Ein Refresh-Token ist allerdings maximal nur 300 Sekunden gültig, so dass man dann einen Neuen erzeugen müsste (dies wird z.B. auch durch einen Deploy in NodeRed ausgelöst, da der Token dann aus dem Speicher gelöscht wird.

Damit das nicht passiert und der Token erhalten bleibt bzw. automatisch erneuert wird hat der Autor der Library den Beispiel-Flow „Persistent Auth“ beigefügt.

Zur Nutzung werden die Nodes in dem Flow zuerst aktiviert. Anstelle des Nodes „unknown: tado-token“ wird der tado-Node eingetragen und verbunden. In diesem wird für die Eigenschaft "Tado-config" nur die Auswahl "Tado-config" getroffen. Für alle weiteren Abfragen verwende ich ab jetzt nur noch "Tado-config" und nicht mehr "Tado-Cloud" (die folgenden Bilder wurden noch mit der alten Authentifizierungsmethode erstellt).

Parallel dazu wird im NodeRed Data-Verzeichnis eine Datei /data/tado.json angelegt und dort im JSON-Format der letzte verwendete Refresh-Token eingetragen.

Anschließend sollte der Flow ohne Probleme laufen. Dieser erneuert nun automatsch den Refresh-Token. Laut Angaben des Autors der Library wird der Refresh-Token maximal innerhalb von 30 Tage automatisch erneuert, wenn man nicht auf die API zugreift, bevor man einmal manuell eine Erneuerung auslösen muss. Alternativ reicht es aus, dass innerhalb von 30 Tagen einmal ein API-Zugriff erfolgt. Ich vermute, dass dies auch eine Sicherheitseinstellung von tado ist.

tado Parameter auslesen

Für die weiteren API-Aufrufe benötige ich meine Home ID. Diese erhalte ich, wenn ich den API-Aufruf "Get the current user" auswähle und den resultierenden Aufruf mit einem Inject-Node vorne und einem Debug Node hinten ergänze und ausführe. Als Ergebnis erhalte ich im Debug-Fenster ein Datenobjekt, das wie folgt aussieht:

Hier brauche ich nun die Zahl, die unter "homes" im Array[0] hinter "id" steht. 2359335 ist meine Home-ID, die ich für die weiteren API-Aufrufe benötige (das Objekt lässt sich durch Klicken auf die Pfeile auf- und zuklappen).

Zusätzlich frage ich noch die Zone ab, in der sich mein Gerät im Tado-Universum befindet (zur Erklärung von Zonen sollte man sich bei tado informieren).

Dazu öffne ich einen neuen tado-Node, wähle diesmal die API-Funktion "Get all zones" und gebe die eben gefundene Home-ID an. Mit Inject und Debug-Node erhalte ich wieder ein Datenobjekt, indem ich durch Aufklappen der Datenstruktur irgendwo den Namen meiner Klimaanlage finde, den ich beim Setup angegeben habe. Die Nummer hinter dem Feldnamen id des Objekteintrags darüber ist die Nummer, die ich brauche.

Wenn ihr nur eine Klimaanlage eingerichtet habt, werdet ihr höchstwahrscheinlich die Nummer "1" als Ergebnis erhalten.

Jetzt habe ich alles zusammen, um die Klimaanlage mit Node-Red ein- und auszuschalten.

Klimaanlage mit Node-Red steuern

Um die Klimaanlage einzuschalten, ruft man wieder einen Tado-Node auf und wählt die Funktion "Set a Zone's Overlay". Mit den folgenden Parametern schalte ich die Klimaanlage bei mir ein:

Hinweis: Da ich keine bidirektional sendende Fernbedienung habe, kann Tado nicht erkennen, ob ich die Klimaanlage manuell ein- oder ausgeschaltet habe. Ich kann die von Tado eingeschaltete Anlage zwar mit der Fernbedienung ausschalten, Tado hat intern aber immer noch den Status "ein" gespeichert. Auch die "Auto-"Funktion beim AC-Mode funktioniert bei mi nicht.  Ich gehe ebenfalls davon aus, dass dazu eine bidirektionale Fernbedienung erforderlich ist, die auch Temperaturwerte übermittelt. 

Analog schalte ich die Klimaanlage aus, wenn ich in die Eigenschaft des Schalters "Heating On/Off" einfach auf "Off" stelle.

Nun kann ich ein einfaches "Programm" in Node-Red erstellen, das in der folgenden Grafik zu sehen ist:

Oben habe ich bereits beschrieben, dass ich den aktuellen Zählerstand immer vom MQTT-Server hole und in einer Variablen zwischenspeichere. Nun füge ich nur noch einen Inject-Node hinzu und stelle dort ein, dass dieser in der Zeit von 8:00 bis 20:00 Uhr an jedem Tage und zu jeder Viertelstunde ein Ereignis auslöst.

Dann prüfe ich im nächsten Switch-Knoten, ob mein aktueller Stromverbrauch (Saldo) einen Überschuss von 400 Watt und mehr aufweist oder darunter liegt. Im ersten Fall schalte ich die Klimaanlage mit dem Tado-Node ein oder mit dem anderen Tado-Node aus. Der Inhalt des switch-Knotens sieht wie folgt aus:

Dieses einfache Beispiel kann nun leicht erweitert werden, indem man weitere Klimaanlagen hinzufügt und z.B. die Temperatur vorher kontrolliert.

Die Nutzung von Solaranlagen und Balkonkraftwerken führt ja immer wieder zu der Frage, ob und wenn ja ab wann sich ein Batteriespeicher lohnt und in welcher Größe dieser sinnvoll ist. Im Netz und auf Youtube bekommt man dazu bereits eine Vielzahl von Informationen, aber manche Aussagen scheinen mir dann doch zu weit hergeholt. Auch die viele Formeln zur Berechnung lösen bei mir teilweise Misstrauen aus. In meinem Beitrag zeige ich, wie man mit InfluxDB und Grafana interaktiv verschiedene Szenarien durchspielen kann.

Aufgabenstellung

Für meine Berechnungsgrundlage verwende ich die protokollierten Ertragsdaten einer PV-Anlage (ohne Batteriespeicher) mit einer Größe von ca. 3,2 kWp. Diese Daten liegen in einer InfluxDB 2.x-Datenbank vor und die folgenden Auswertungen mache ich ausschließlich mit Grafana. Eine wesentliche, aber mir unbekannte Größe ist der nächtliche Verbrauch, denn den möchte ich natürlich mit einem Überschuss tagsüber abdecken. Der Gedanke, über mehrere Tage mit einem Speicher "überleben" zu können, ist zwar nett, erfordert aber einen sehr großen Speicher (mehrfacher Tagesbedarf) und somit einer großen Anzahl von PV-Modulen, die aus meiner Sicht auf privaten Hausdächern kaum unterzubringen ist.

Für meine Berechnungen möchte ich die Größe des Speichers und den Strompreis interaktiv verändern können, ebenso wie die Größe der Anlage, die den Strom produziert.

Als Ergebnisse meines Beispiels sollen

• der durchschnittlichen Nachtverbrauch
• die Menge des gesparten Stroms
• der ersparte Wert in Euro

ermittelt werden und der Betrachtungszeitraum variabel sein.

Grafana Variabeln nutzen

Für jede Größe eines Stromspeichern könnte ich eine eigene Visualisierung erstellen, aber das ist mir zu umständlich. Ich möchte gerne per Dropdown-Menü die Größe eines möglichen Stromspeichern auswählen und Grafana soll mir anzeigen, was das bringt.

Variabeln werden immer für ein Dashboard angelegt, so dass man diese auch für mehrere Visualisierungen auf dem Dashboard nutzen kann.

Um Variabeln nutzen zu können, muss man das Konfigurationsmenü für das Dashboard auswählen. Dies befindet sich in der oberen Leiste mit dem Dashboard-Name auf der rechten Seite hinter dem Zahnradsymbol.

Unter "Settings" findet man nun auf der linken Seite den Menüpunkt "Variables".

Nach dem Drücken auf "New Variable" kann man die Variableneigenschaften näher definieren. Da ich eigene Werte zur Auswahl vorgeben möchte wähle ich unter "Variable type" "Custom" aus. Die Variable möchte ich unter dem Name "sinterval" in Grafana-Abfragen benutzen. Auf dem Dashboard soll als Label  "Speichergröße" erscheinen. Und unter Custom options trage ich durch Komma getrennt die Werte ein, die in meiner Dropdownliste erscheinen sollen. Sobald man diese Werte eingetragen hat sieht man die Ergebnisse bereits am untern Bildschirmrand.

Auf diese Weise lege ich drei Variablen an, die Erste für die Größe eines möglichen Batteriespeichers ("sbattery"), die Zweite zur Skalierung der Anlagengröße (und damit des Überschusses ("sscaler") und eine Dritte für den aktuellen Strompreis ("sprice").

Nach dem Anlegen der Variabeln sollte man nicht vergessen, das Dashboard zu speichern.

Durchschnittlichen Nachtverbrauch bestimmen

Ein Batteriespeicher dient primär dazu, Überschuss zu speichern und den Strom dann zu liefern, wenn die Sonne keinen Strom produziert (z.B. nachts). Daher verwendet man häufig die in der Dunkelheit benötigte Menge Strom als Maßstab, um die Mindestgröße eines Batteriespeichers zu bestimmen.

Ich schaue mir also für einen bestimmten Zeitraum an, welche Menge an Strom ich nachts benötige und ermittele hieraus den Mittelwert. Dabei gehe ich davon aus, dass der Zeitraum von Frühjahr (März) bis Herbst (November) ideal für eine Betrachtung ist, da eine Photovoltaikanlage zwischen November und März kaum soviel Leistung erzeugt, dass man Überschüsse erwirtschaftet, die man speichern kann. Als Uhrzeit für den nächtlichen Zeitraum habe ich 21:00 Uhr abends bis 5:00 Uhr morgen definiert.

Die Abfrage für diese Mittelwert sieht wie folgt aus:

Die "date"-Bibliothek braucht man für die hourSelection()-Funktion. Mittels der "timezone"-Bibliothek und der "location"-option löst man die Übersetzung der  UTC-Zeitangabe in die deutsche Zeit auf (im Winter UTC+1 sonst UTC+2 Stunden)

Den Verbrauch ermittele ich aus der Differenz der nächtlichen Zählerstände des Smartmeters. Wie man das macht findet ihr in folgendem Beitrag: SmartMeter mit Tasmota auslesen

Nun schränke ich die ermittelten Differenzen auf die von mir ausgewählte tägliche Zeitspannen mittels der hourSelection()-Funktion ein. Dies erfolgt vor der Aggregat()-Funktion, mit der ich die Summe für die Zählerdifferenzen für jeweils einen Tag bilde.

Und abschließend wird mit der Mean()-Funktion der Mittelwert über alle Nachtverbräuche gebildet. Aus der Auswertung ergibt sich, dass im von mir gewählten Zeitraum (vom März bis Ende Oktober) durchschnittliche 4,1 kWh in der Uhrzeit von 21:00 Uhr bis 5:00 Uhr morgens verbraucht wurden.

Einsparung eines Batteriespeichers berechnen

Im nächsten Schritt berechne ich mittels Grafana, wieviel kWh ich durch einen Batteriespeicher einsparen würde.  Die Werte kann man ebenfalls an einem Smartmeter auslesen, wenn dieser auch die ausgehende Leistung messen kann, die an den Netzbetreiber geliefert wird. Diese Zweirichtungsmessung bieten mittlerweile fast alle Geräte an, wenn man diese Daten für eine Protokollierung freigeschaltet hat.

Der Code hierzu lautet wie folgt:

Wie bei der Ermittlung der Verbräuche bilde ich die Differenzen der Zählerstände und addiere diese für jeden Tag mit der Aggregat()-Funktion.

Anschließend bearbeite ich die Werte mit der map()-Funktion und modifiziere die ermittelten Werte wie folgt:

Die Größe des Batteriespeichers gebe ich (wie oben beschrieben) durch den Wert in der Variabeln  "sinteraval" vor. Daraus ergibt sich, dass ich für alle Tage

• an denen der Überschuss größer als die Größe des Batteriespeichers in der Variabeln "sinterval" ist nur die Größe des Batteriespeichers
• an denen der Überschuss kleiner der Größe des Batteriespeichers in der Variabeln "sinterval" ist den Überschuss des Tages

weiterverwenden kann.

Bei der Berechnung muss ich den Wert in der Variabeln "sinterval" in einen float()-Typ umwandeln, da die Multiplikation sonst zum Typkonflikt führt.

Und mit der folgenden map()-Funktion baue ich noch einen Skalierungsfaktor ein, der "simuliert", wie groß mein Ertrag sein könnte, wenn die Anlage (und damit auch der Ertrag) um den Faktor "sscaler" größer wäre. Auch hier erfolgt eine Typumwandlung.

Ich habe noch ein zweites Panel erstellt, mit dem ich den Wert der Ersparnis in Euro ermittele. Dazu benutze ich die dritte Variable "sprice". Durch Austauschen der letzten Zeile in der vorigen Abfrage kann man diesen Wert in einem neuen Panel wie folgt ermitteln:

Meine Auswertung

Das Ergebnis der drei Panels sieht wie folgt aus:

Diese Daten liefern mit nun Anhaltspunkte für ein Kosten-/Nutzenverhältnis eines Batteriespeichers.  Dabei erhalte ich zuerst die Angabe, dass mein  Batteriespeicher größer ca. 5 kWh groß sein sollte, um den nächtlichen Verbrauch durch den Speicher abdecken zu können. Bei einem Preis von 40  Cent pro kWh würde ich ca. 228 € pro Jahr sparen. Gehe ich davon aus, dass ein Batteriespeicher mind. 2500 Euro kostet würde sich dieser rechnerich nach ca. 11 Jahren amortisieren. Ich gehe bei der Lebensdauer eines Batteriespeichers pessimistisch von 10 Jahren aus, so dass sich dies für den vorliegenden Fall wirtschaftlich nicht lohnen würde, sofern die Strompreise nicht durch die Decke gehen.

Würde ich die Anlage um 1,6 kWp erweitern, dann würde sich ein Batteriespeicher bereits nach 7,5 Jahren lohnen. Den passenden Wechslerichter habe ich hier noch nicht berücksichtigt.

Auch wenn das Modell  Faktoren außen vor lässt, bekommt man ein Gefühlt für die Wirtschaftlichkeit und ich kann die Angebote für diesen Fall jetzt deutlich besser einordnen. Viel Spaß bei den eigenen Berechnungen und Erweiterungen.