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.

Nicht erst seit Corona ist die Messung des CO2-Gehaltes in der Raumluft eine Möglichkeit festzustellen, ob genügend Frischluft (oder Sauerstoff) in einem Raum vorhanden ist. Ich war teilweise überrascht, wie teuer manche Sensorlösungen verkauft werden und habe mich daher entschlossen, einen eigenen Sensor zu bauen, der sich auch einfach in mein Smarthome integrieren lässt. Mit einer kleinen LED möchte ich anzeigen, ob ein vorgegebener Grenzwert überschritten wird. Die Daten des Sensors sollen zyklisch an mein Smarthome-System gesendet werden.

Benötigte Hardware

Als Sensor habe ich mich für einen CO2-Infrarotsensor MH-Z 19C entschieden. Der Sensor sendet seine Informationen über eine UART-Schnittstelle (Tx,Rx-Kanal), besitzt zusätzlich einen Temperatursensor und benötigt eine Versorgungsspannung von 5V. Mit diesen Anschlussmöglichkeiten eignet er sich hervorragend für den Anschluss an einen Wemos D1-Mini (8266 Chip), den ich schon in vielen meiner Projekte verwendet habe. Über diese kann ich dann auch alle Daten an einen MQTT-Broker senden und so die Daten einfach in meinem Smarthome-System weiterverarbeiten. Den Sensor gibt es in verschiedenen Ausführungen, wobei ich mich für die Version mit den Stiftleisten entschieden habe, um den Anschluss zu vereinfachen. 

Auf dem D1 Mini verwende ich die Tasmota Version 14.3.0. Um den CO2-Infrarotsensor MH-Z 19C an den D1 Mini anschließen und auslesen zu können, benötige ich die Tasmota Sensor Version (alternativ kann man den MH-Z19C auch einfach in der Standardversion aktivieren und spart dadurch viel Speicherplatz auf dem D1 Mini).

Ich erstelle meine Programme gerne mit der Skriptsprache von Tasmota. Da es diese Funktion in den vorkompilierten Versionen von Tasmota nicht gibt, kompiliere ich mir selbst eine Version und flashe den D1-Mini damit. Dies geht sehr einfach und ist im folgenden Artikel von mir beschrieben:Tasmota Scripting aktivieren

Ich empfehle, in der Konfiguration des D1-Mini neben dem WLAN auch direkt einen MQTT-Server anzugeben.

CO2-Sensor anschließen

Der Anschluss des CO2-Sensors ist recht einfach. Als Ergänzung habe ich noch eine rote LED hinzugefügt, die bei Überschreitung eines definierten Grenzwertes aufleuchten soll. Die gesamte Schaltung ist in der folgenden Abbildung dargestellt:

Nun muss der Sensor in Tasmota konfiguriert werden. Dies geschieht über die serielle Schnittstelle mit TX (Sendekanal) und RX (Empfangskanal).

Unter Configure / Configuration Module wähle ich als Module Type "Generic(18)" (steht meistens ganz unten in der Liste) und speichere das. Erst dann kann ich alle meine GPIOs sehen und konfigurieren.

• GPIO1 (TX) wird auf "MHZ Tx (60)" (Sendekanal) gesetzt.
• GPIO3 (RX) wird auf "MHZ Rx (61)" (Empfangskanal) gesetzt.

(Tipp: In der langen Liste stehen die beiden Werte im unteren Dritttel).

Um die LED einschalten zu können, wird noch ein Relay benötigt, dass wie folgt definiert werden muss:

• GPIO5 (D1) wird auf "Relay 1" gesetzt.

Nach dem Speichern und dem automatischen Neustart sollten Temperatur und CO2 Gehalt wie folgt auf der Tasmota Oberfläche erscheinen:

Hinweis: Aufgrund der Vorheizzeit kann es bis zu einer Minute dauern, bevor der Sensor Werte liefert!

Script für LED-Warnung erstellen

Natürlich möchte ich, dass eine rote Lampe aufleuchtet, wenn ein Grenzwert überschritten wird. Bezüglich möglicher Grenzwerte verweise ich auf den folgenden Artikel. Dazu muss ich den Sensorwert auslesen und in einem kleinen Programm das Relais immer dann einschalten, wenn der Grenzwert überschritten wird. Bei dieser Abfrage prüfe ich, ob die LED schon an ist, damit ich nicht ständig den Einschaltbefehl sende. Natürlich schalte ich die LED wieder aus, wenn der Grenzwert unterschritten wird.

Die Daten können nun vom MQTT-Broker "abgeholt"  und beispielsweise in InfluxDB gespeichert und ausgewertet werden. Wie das geht habe ich in folgenden Artikeln beschrieben

Möglicher Anpassungen

Ich versorge den Sensor über ein USB-Kabel mit Strom. Theoretisch könnte man dies auch mit einer Akkulösung realisieren. Dazu wird dann der Deepsleep-Modus verwendet (siehe hierzu Füllstandssensor (Zisterne) für HMIP selber bauen). Wichtig ist, dass der Sensor eine Vorlaufzeit zur Temperaturanpassung benötigt. Daher sollte der Sensor frühestens nach 1 Minute wieder in den DeepSleep-Modus gehen.

Anstelle einer LED könnte man auch eine mehrfarbige LED verwenden, die den jeweiligen Zustand anzeigt.

Inzwischen habe ich den Sensor auf eine Platine gelötet und mir mit dem Drucker ein passendes Gehäuse gedruckt.

Eine Bodenfeuchtemessung im Garten ist hilfreich, wenn man Pflanzen oder Rasen rechtzeitig und ausreichend bewässern möchte. Wenn man einen größeren Garten oder z.B. einen Schrebergarten hat, ist oft kein WLAN an allen Stellen verfügbar. Als Alternative bietet sich dann das Versenden der Sensordaten über LoRaWAN an. Die Vorteile habe ich bereits in meinem Beitrag LoRaWAN mit eigenem Gateway einrichten genannt.

ELV hat hierzu ein interessantes Produkt für einen überschaubaren Preis im Programm. Dazu braucht man das  LoRaWAN-Interfaces ELV-LW-INT1 und den  universellen Bodenfeuchtesensor SoMo1, I²C. Beide zusammen sind bei ELV für ca. 75 Euro zu erhalten.

Ich mit diesen Komponenten in einem größeren Garten die Bodenfeuchte und -temperatur gleichzeitig messen und halbstündlich an einen MQTT-Server übertragen. Ich habe dazu in der Nähe ein LoRaWAN-Gateway im TTN-Netz verfügbar.

Vor der Inbetriebnahme muss das System konfiguriert werden. Da die Konfiguration viele Möglichkeiten anbietet und für den Laien nicht trivial erscheint beschreibe ich, wie man den Sensor für diesen Zweck in Betrieb nehmen kann.

Installation der Hardware

Auch wenn die Platine als „Bausatz“ angeboten wird, sind keine Bestückungs- oder Lötarbeiten erforderlich. Das Interface besitzt neben 2 Mignon-Batterieslots vom Typ LR6 (AA) auch 2 Sensoranschlüsse mit UART- oder I²C-Schnittstelle. Obwohl insgesamt nur eine Spannungsversorgung über die Batterien (Akkus) von 3V zur Verfügung steht, können trotzdem 3,3 bzw. 5V an die Sensoren ausgegeben werden (über Transistoren). Dies ist wichtig, da die meisten Sensoren die etwas höhere Spannung für eine korrekte Messung benötigen. Die Platine besitzt keine externe Spannungsversorgung und kann daher nur durch Bestückung mit den 2 Mignonzellen in Betrieb genommen werden. Zur Befestigung liegen noch 2 Schrauben und eine Stiftleiste bei, über die ein Firmware-Update über einen USB-UART-Konverter UM2102N durchgeführt werden kann. Die richtige Firmware ist bereits installiert.

Der Feuchte- und Temperatursensor ist ebenfalls sofort einsatzbereit, kann Bodenfeuchte und -temperatur messen, besitzt einen AD/DA-Wandler und ist wasserdicht vergossen. Nach dem Einbau in eine Dose kann das Kabel des Sensors über die gekennzeichneten 4 Drähte an die Schnittstelle wie folgt angeschlossen werden:

• (braun) an +UB2
  
• (schwarz) an GND
• (blau) an SDA
• (weiß) an SCL

Weitere Detailinformationen finden sich z.B. in folgendem ELV-Journalartikel.

Wer kein LoRaWAN-Gateway in der nähe hat findet im Artikel LoRaWAN mit eigenem Gateway einrichten weitere Hinweise zum TTN-Netzwerk oder der Gateway-Einrichtung.

Ich empfehle, die Batterien erst wie im nächsten Kapitel beschrieben einzulegen.

Device und Applikation in TTN Netzwerk ergänzen

Nach dem Einloggen in das TTN-Netzwerk geht man auf den Reiter „Applications“. Als erstes erstelle ich eine Application und gebe hier einen aussagekräftigen Namen „Loris-Bodenfeuchte1“ ein.

Anschließend erstelle ich ein neues Device, indem ich auf „New Device“ klicke.

Bei „End device type“ kann man das Device direkt im Repository suchen (Option 1). Dazu wählt man ELV aus und findet dann schon das LoRaWAN Interface 1. Als Frequency Plan wird SF9 gewählt und nach Eingabe der JoinEUI (liegt dem Interface als kleiner Aufkleber bei) kann man auf Confirm tippen. Danach werden noch die DevEUI und der AppKey ergänzt. Die End-Device ID wird automatisch generiert und man kann nun „Register end device“ drücken. (Update Juli 2025: Die End-Device ID wird mittlerweile nicht mehr automatisch generiert. Hier kann man beispielsweise auch die DevEUI in der Notation "eui...." eintragen). 

Nach dem Einlegen der Batterien oder Akkus blinkt das Board kurz rot/gelb und wechselt dann auf grün.

Jetzt kann man unter „Live data“ beobachten, wie das Gerät Kontakt zum Netzwerk aufnimmt und Nutzdaten sendet. Zum Dekodieren der Daten benötigt man einen Payload Parser (ein kleiner Codeblock, der die vom Gerät empfangenen hexadezimalen Bytewerte übersetzt). Wenn man das Gerät wie beschrieben aus dem Repository ausgewählt hat, wird der Payload-Parser automatisch mitgeliefert. Dieser befindet sich unter dem Device im Reiter "Payload Formatter" "Uplink". Hier sollte "Use device Repository formatters" stehen. Den Code von eQ3  kann man sehen (und editieren), wenn man die Device aufruft und im Menü (OBEN!) den Reiter "Payload-formatters" aufruft.

Alternativ kann man diesen Code auch auf der ELV-Seite unter Downloads unter dem Link „ELV-LW-INT1 Payload-Parser“ herunterladen.

Sensor konfigurieren

Wer die Installation bis hierhin erfolgreich durchgeführt hat, wird feststellen, dass nur Statusdaten der Schnittstelle gesendet werden, aber keine Sensorwerte für Bodenfeuchte und Temperatur. Dies liegt daran, dass die Messung und Übertragung der Werte von den Sensoren erst aktiviert werden muss. Das Interface hingegen ist so vorkonfiguriert, dass es alle 30 Minuten eine Statusmeldung sendet.

Grundlagen zur Sensorkonfiguration

Die Befehle und Grundlagen für die Konfiguration der Sensoren und des Interfaces findet man in folgenden Dokumenten:

• Excel-Tabelle auf zum Interface mit allen Details zu Befehlen, Parametern, etc.
• Bau- und Bedienungsanleitung des Interfaces
• ELV-Journal 2/2024 unter Bausätze

Grundsätzlich tauscht man Informationen mit dem Interface und den Sensoren über eine Payload (eine Bytefolge von hexadezimalen Werten) aus. Befehle werden als Payload über einen Downlink-Kanal an ein Gerät gesendet, Daten werden über einen Uplink-Kanal empfangen. Kommandos werden als "frame-type" bezeichnet. In einem "frame-type" werden Daten wie z.B. Kanal und Parameter übertragen.

Für die zu übertragenden Codes (Bytes) müssen Werte berechnet werden, wobei teilweise zwischen dezimalen, hexadezimalen und binären Zahlenformaten gewechselt wird. ELV empfiehlt hierfür den folgenden einfachen Konverter.

In den folgenden Kapiteln werden einzelne Werte auch durch das Setzen von Bits ermittelt. Dabei gilt, dass die Bits in einem Byte von 0 bis 7 gezählt werden und rechts begonnen wird!

Sensoren über Kanäle ansprechen

Um die Sensoren und das Interface eindeutig anzusprechen benötigt man die Angabe einer Kanalnummer. Das Interface besitzt eine eigene Kanalnummer und neben dem gemeinsam verbauten Bodenfeuchte- und Temperatursensor wird auch ein Ultraschall-Disstanzsensor DUS1 unterstützt.

Folgende Kanalnummern stehen zur Verfügung:

Anzeige von Statusdaten

Theoretisch kann jeder Sensor eigene Statusdaten senden. Standardmäßig sendet das Interface jede halbe Stunde eine Statusnachricht und zusätzlich kann ich mir die Statusinformation des Feuchtesensors und des Temperatursensors jeweils in einem eigenen Zeitintervall senden lassen. Ich möchte aber insbesondere die Feuchte- und Temperaturinformationen immer zusammen erhalten und am liebsten noch zusammen mit den Statusinformationen des Interfaces (also insgesamt nur eine Nachricht mit allen Informationen jede halbe Stunde).

Dies kann ich erreichen, indem ich Statusgruppen verwende, in denen ich die Statusinformationen zusammenfasse und diese zusammengefassten Statusinformationen dann in eine Statusmeldung einfüge. In meinem Fall werden die Statusinformationen des Feuchtesensors und des Temperatursensors der Statusgruppe 1 zugeordnet. Ich werde für diese Sensoren nicht separat das Übermitteln von Statusinformationen aktivieren sondern werden das Interface so konfigurieren, dass es bei seiner halbstündlichen Statusinformation einfach die Gruppe 1 inkludieren soll. Damit wird die Statusmeldung auch die Informationen der Sensoren beinhalten.

Befehl zur Konfiguration der Sensoren

Zur Konfiguration verwende ich den "set single parameters" Befehl, dem ich beliebig viele Parameter übergeben kann. Mit diesem Befehl werden alle Parameteränderungen beginnen.

Feuchtesensor konfigurieren

Hierfür gelten folgende Punkte:

• Messungen müssen aktiviert werden, sonst kann der Feuchtesensor keine Daten senden.
• Man kann gleichzeitig auch das Messen der Temperatur aktivieren, so dass beide Werte synchron ermittelt werden!
• Der Bodenfeuchtesensor liefert immer sogenannte Rohwerte im Bereich von 3000 bis 4000 zurück. Diese kann man selber in Prozentwerte umrechnen oder vom Sensor direkt umrechnen lassen. Dazu ist das Ablesen der Sensorwerte im trockenen Zustand sowie in nassem Zustand erforderlich. Die beiden Rohwerte werden dann dem Sensor als Untegrenze für 0% und Obergrenze für 100% mitgeteilt.

Mit folgender Bytefolge konfiguriere ich den Feuchtesensor:

Temperaturmessung konfigurieren

Hierfür gelten folgende Punkte:

• Die Temperaturmessung wurde bereits über die Bodenfeuchtemessung aktiviert, so dass die Messzyklen für die Feuchtemessung automatisch gelten. Weitere Einstellungen zur Messwerterfassung sind bei diesem Ansatz nicht erforderlich.

Mit folgender Bytefolge konfiguriere ich den Temperatursensor:

Interface konfigurieren

Hierfür gelten die folgenden Punkte:

• Standardmäßig sendet das Interface alle 30 Minuten eine Statusmeldung, so dass dies nicht gesondert eingestellt werden muss.
• Zusätzlich zu den eigenen Statusinformation sollen die Statusinformation des Feuchte- und Temperatursensors übermittelt werden.

Mit folgender Bytefolge konfiguriere ich das Interface:

Konfigurationsänderung an das Gerät schicken

Dazu geht man im TTN-Webinterface unter "End devices" auf das SoMo1-INT1 Gert, wählt den Reiter "Messaging" und dort den Reiter "Downlink". Als "FPort" muss nun "10" eingestellt werden. Danach kann man die in den vorherigen Kapiteln erstellten drei Bytefolgen (Payload) jeweils in das Payload-Feld eintragen (bitte  ohne das führende 0x) und anschließend den Button "Schedule downlink" drücken. Das Kommando wird beim nächsten Verbindungsaufbau zum Gerät gesendet (durch kurzes Drücken des Buttons an der Schnittstelle kann die Zeit verkürzt werden).

Unter "Live data" kann man nun die Übertragung der Befehle beobachten. Wenn dort die "decode downlink data message" Meldung „No decoder defined for codec elv-lw-int1-codec“ erscheint, kann man diese ignorieren. Es gibt aktuell keinen Payload-Decoder, der in der Lage ist, die gesendete Bytefolge wieder in Klartext umzuwandeln.

Es kann einige Zeit dauern, bis die Einstellungen vorgenommen sind, da normalerweise die eingestellten Sendeintervalle abgewartet werden müssen (in diesem Beispiel bis zu 1 Stunde).

Um die Daten an einen MQTT-Server zu schicken verweise ich auf die Erläuterungen in folgendem Beitrag Füllstandsmessung mit LoRaWAN.

Wenn dann eine Statusinformation gesendet wird, sollte das Ergebnis wie folgt aussehen:

Die Daten können dann z.B. in Node-Red weiterverarbeitet und zur Steuerung von Bewässerungssensoren verwendet werden.

HINWEIS: Die Bodentemperatur wird als Zeichenkette (String) geliefert und nicht wie der Feuchtewert als Zahl (float-Typ). Vor der Speicherung in einer Datenbank sollte der Wert daher vorher umgewandelt werden, damit man ihn grafisch darstellen kann.

Optionale weitere Befehle

In der folgenden Tabelle sind einige weitere Befehle zur Konfiguration der Sensoren aufgelistet:

Mit dem kleinen Shelly Plus PM Mini wird eine günstige Möglichkeit geboten, eine Leistungsmessung durchzuführen. Das Gerät ist nur ca. 28 x 32 x 16 mm (HxBxT) groß und passt in viele UP-Dosen z.B. hinter einer Steckdose. Das Gerät unterstützt dabei eine Messung bis zu 16A Leistung (ist leider nicht bei allen Shelly Geräten so), so dass man mit dem Gerät theoretisch die Leistung eines Balkonkraftwerks, von Lichtschaltern oder Steckdosen messen kann.

Im folgenden Beitrag beschreibe ich, wie man das PM Mini auch ohne Shelly-App über WLAN und MQTT einbinden und die Daten in Node-Red weiterverarbeiten kann.

Grundsätzlich erfolgt hier der Hinweise, dass das Arbeiten an Elektroleitungen immer nur von Fachleuten (Elektrikern) durchgeführt werden und immer die fünf Sicherheitsregeln der Elektrotechnik berücksichtigt werden sollten.

Gerät ins Netzwerk einbinden

Ich möchte auf die Shelly Cloud sowie das Einrichten der Shelly App verzichten, sondern nur eine lokale Nutzung mittels WLAN umsetzen. Nach der Stomversorgung spannt das PM Mini ein eigenes Netz auf (Access Point), mit dem man sich verbinden muss. Das WLAN erkennt man an dem Namen, der mit "ShellyPMMini..." beginnt. Um anschließend in den Shelly-WebAdmin-Oberfläche zu kommen, gibt man im Browser die Adresse "192.168.33.1" ein und schon sollte die administrative Weboberfläche  erscheinen. Bitte berücksichtigt, dass auch die Shelly-Geräte nur das 2,4 GHz WLAN unterstützen. Die Optionen und Anzeigen  in der WebAdmin-Oberfläche sind unter diesem Link super erklärt.

Nun geht man auf "Configure Wifi-Setting", wählt "Enable Wifi-network" und gibt die SSID (Name des WLANs) sowie das Passwort für das WLAN an und speichert die Einstellungen. Theoretisch kann man das Gerät nun neu starten und es sollte dann unter einer eigenen IP-Adresse in der Netzwerkliste des Routers erscheinen.

Generelle Einstellungen

Da es bei älteren Shelly-Firmwareversionen zu Problemen mit der korrekten Leistungsmessung kam, sollte unbedingt die aktuelle Firmware für das PM Mini aufgespielt werden.  Dazu geht man auf "Settings" und "Firmware". Shelly prüft nun automatisch, ob eine neue Version verfügbar ist und bietet an, diese online zu installieren.

Nach dem Drücken von "Update" wird die Firmware aufgespielt und das Gerät neu gestartet. Nun sollten folgende Einstellungen vorgenommen werden:

MQTT-Settings

Für das erfolgreiche Senden von Nachrichten an einen MQTT-Broker müssen folgende Einstellungen vorgenommen werden:

Nach dem Speichern der Settings ist das Gerät vollständig konfiguriert und kann über "Settings" "Reboot-Device" neu gestartet werden. Anschließend kann man z.B. mit dem MQTT-Explorer prüfen, welche Informationen an den MQTT-Broker gesendet werden.

Tipp: Bei mir wurden zuerst keine Nachrichten gesendet. Erst als ich in den MQTT-Settings den Punkt „Generic Status update over MQTT“  enabled und dann wieder disabled habe, hat es funktioniert.

Daten in Node-Red weiterverarbeiten

Die Daten können jetzt in Node-Red weiterverarbeitet werden. In meinem Fall speichere ich diese direkt in einer InfluxDB ab.

Im mqtt-in-Node frage ich erst einmal das Topic vom MQTT-Server ab. Dieses findet man unter dem Namen, den man dem Shelly-Gerät  gegeben hat (siehe oben), gefolgt von einem "/pm1:0", also in meinem Fall heißt das Topic "EM-Licht/pm1:0". Als Ausgabe wird "Ein analysiertes (parsed) JSON-Objekt." gewählt.

Im Function-Node wird nun die Leistung aus dem JSON-Objekt extrahiert:

Der Code dazu lautet:

Das bedeutet, dass sich unter "aenergy.total" der benötigte Wert im payload-Objekt befindet.

Zuletzt speichere ich diesen Wert noch mit einem influxdb-out-Node in die Datenbank. Mit dieser Vorgehensweise kann man auch andere Shelly-Geräte ohne Shelly-App abfragen und deren Daten weiterverarbeiten.

Wie man Node-Red, MQTT und InfluxDB installiert und Daten austauscht steht unter anderem in meinen Beiträgen Mit Node-Red, InfluxDB und Grafana Daten auf einem Synology NAS sammeln und visualisieren (Teil 1/2) und  Mit Node-Red, InfluxDB und Grafana Daten auf einem Synology NAS sammeln und visualisieren (Teil 2/2)

Neulich bin ich wieder auf die die Ulanzi TC001 Pixelclock gestoßen und beschreibe im folgenden Beitrag, wie sich mit dem Display eigene Werte über Node-Red von beliebigen Smart Home Systemen darstellen lassen.

Ich habe die Pixelclock direkt bei Ulanzi bestellt. Innerhalb kurzer Zeit wurde sie geliefert. Sie besitzt ein Matrixdisplay aus 256 LEDs und versprüht damit einen gewissen Retro Charme. Sie ist mit einem Akku ausgestattet und über einen USB-C Anschluss kann man das Gerät aufladen oder auch mit einem Netzteil betreiben. Ich verwende dazu ein Netzteil, welches ich normalerweise für einen Raspberry PI benutze (5V, 1A).

Auf der Oberseite befinden sich neben einem Lichtsensor drei Tasten, die zur Bedienung der internen Einstellungen dienen. Die Pixelclock zeigt bereits fünf eigene Apps an, zu denen ein Kalender oder die Akkuanzeige gehören.

Neue Firmware aufspielen

Um eigene Werte auf der Pixelclock anzeigen zu können, muss eine andere Firmware aufgespielt werden. Diese wird der blueforcer AWTRIX LIGHT Gruppe gepflegt und über diese Webseite mit einem Online-Flasher bereitgstellt. Nach dem Anschluss des Gerätes über das mitgelieferte USB-C-Kabel kann das Gerät über die Webseite geflasht werden.  Während dieses Vorgangs piept das Gerät kontinuierlich.

ACHTUNG: Der Online Flasher funktioniert lt. Hersteller nur mit Google Chrome und Microsoft Edge. Bei mir hat nur Google Chrome unter OSX funktioniert.

Nach erfolgreicher Installation meldet sich die Pixelclock mit einer bunten Anzeige, auf der "AWTRIX sowie die Versionsnummer der Firmware und "AP MODE" angezeigt werden. Dies bedeutet, dass die Pixelclock noch keine Verbindung ins WLAN hat. Da sie in diesem Modus ein eigene WLAN aufspannt kann man sich mit einem beliebigen Gerät mit diesem WLAN verbinden (Name i.d.R. "awtrix....").

Nach Eingabe der SSID und der Passwortes startet das System neu und sollte nun nach dem Versionsschriftzug eine IP-Adresse anzeigen. Unter dieser IP-Adresse ist das AWTRIX-Webinterface ab sofort erreichbar.

TIPP: Wer später eine aktuellere Firmware aufspielen möchte kann diese unter folgendem Link herunterladen und auf dem Webinterface der Pixelclock über den Menüpunkt "Update" installieren.

AWTRIX konfigurieren

Zur Anzeige eigener Werte ist ein MQTT-Broker erforderlich. In meinem Beitrag MQTT-Broker Mosquitto als Docker Image auf einem NAS installieren ist beschrieben, wie man diesen installieren kann.

Ich empfehle, folgende Einstellungen vorzunehmen:

• Unter "MQTT" die IP-Adresse des MQTT-Brokers (der Port kann i.d.R. auf 1883 bleiben, wenn man den nicht geändert hat)
• Unter "Prefix" den Namen, unter dem Daten für das Gerät zu finden sein sollen. In meinem Beispiel verwende ich "awtrix_test"
• (optional) Unter "Auth" einen Usernamen und ein Passwort für den Zugriff auf das Webinterface.

Nach Änderungen ist es sinnvoll, diese zu sichern.  Das kann man über den Menüpunkt "Backup" erledigen und kann somit später Konfigurationen einfach wiederherstellen.

Auf dem Gerät sollte man darüber hinaus alle Applikationen deaktivieren, die man nicht braucht. Bei mir ist nur der Kalender übrig geblieben. Dazu drückt man etwas länger die mittlere Taste und wählt über die links- oder rechts-Taste das Menü "APPS"  aus. Ein erneutes Drücken der mittleren Taste bietet anschließend die Möglichkeit, mit den Pfeiltasten die vorinstallierten Apps anzuwählen. Diese können über die mittlere Taste auf "ON" oder "OFF" gestellt werden.  Das jeweilige Untermenü verlässt man über das längere Drücken der mittleren Taste.

HINWEIS: Man kann auf dem Gerät nur die vorinstallierten Apps aktivieren oder deaktivieren. Eigene Apps werden hier nicht angezeigt, sondern werden nur über die MQTT-Nachrichten gesteuert. 

Icons installieren

Eigene Daten kann man mit vorangestellten Icons anzeigen lassen. Hierzu gibt es bereits eine riesige Auswahl auf der Seite Lametric. Wunderschön sind insbesondere die animierten Icons z.B. für Stromverbrauch oder Stromerzeugung. Wer hier nichts findet, kann sogar selber eigene Icons erstellen. Ich wähle für mein Beispiel das Icon mit der Nummer 21256 aus.

Nach dem Wechsel in das AWRTIX-Webinterface kann man unter dem Menüpunkt "Icons" durch die Angabe der Icon-Nummer von der Lametric-Seite ein oder mehrere Icons auf die Pixelclock laden.

Eigene Werte anzeigen lassen

Ich möchte auf der Pixelclock den aktuellen Stromverbrauch meines Smartmeters anzeigen lassen. Wie man diesen ausliest, habe ich in dem Beitrag SmartMeter mit Tasmota auslesen beschrieben.

In Node-Red baue ich dazu einen Flow, der aus folgenden Komponenten besteht:

Von einer CCU hole ich mir die Variable, in der der aktuelle Stromverbrauch gespeichert ist (das könnte natürlich auch der Wert von einem MQTT-Broker sein). Diesem Wert übermittle ich an einen Change-Node, in der die Nachricht zusammengestellt wird, die an einen MQTT-out-Node weitergegeben wird. Die Nachricht wird als json-String in einer Payload zusammengesetzt und besteht aus folgenden Bestandteilen:

In Node-Red sieht der Change-Node wie folgt aus:

TIPP: Es gibt eine große Zahl von Konfigurationsmöglichkeiten für eine Anzeige. Diese sind in der sehr guten Dokumentation unter folgendem Link zu finden.

Diese Informationen leite ich anschließend an den MQTT-out-Node weiter. Hier ist darauf zu achten, dass das Topic richtig eingetragen wird. Dieses besteht aus dem in AWTRIX festgelegten Topic (hier "awtrix_test"), gefolgt von dem Text "/custom" sowie einer eigenen Applikationsbezeichnung. In meinem Beispiel lautet das topic "awtrix_test/custom/stromverbrauch". Der letzte Name kann frei gewählt werden ist aber wichtig, damit man die verschiedenen Werte, die man an die Uhr übermittelt, eindeutig unterscheiden kann.

Sobald man den Flow in Node-Red deployed hat, sollte nach kurzer Zeit auf der Pixelclock der definierte Wert angezeigt und ständig aktualisiert werden. Es kann am Anfang ein paar Sekunden dauern, bis die Nachrichten vom Broker empfangen wurden.

Senken des Stromverbrauchs

Bei Messungen habe ich festgestellt, dass die Pixelclock bis zu 8 Watt im Betrieb braucht. Das erschien mir ziemlich viel, so dass ich zwei Maßnahmen empfehle, wie der Verbrauch gesenkt werden kann.

Zuerst sollte die Helligkeit des Displays heruntergestellt werden. Dazu wählt man im Menü der Pixelclock (langes Drücken auf die mittlere Taste) den Menüpunkt "BRIGHTNESS". Nach Drücken der mittleren Taste kann man hier einen eigenen Wert einstellen. Bei mir sind aktuell 10% eingestellt, was auch bei Tageslicht vollkommen ausreicht. Dadurch sank mein Stromverbrauch bereits auf weniger als 5 Watt.

Zusätzlich stelle ich ich die Anzeige z.B. nachts aus. Hierzu wird der Pixelclock einfach ein Befehl geschickt, der diese für eine bestimmte Zeit schlafen legt (Deep Sleep Modus des ESP).

Dazu wird in einem Change-Node die Eigenschaft "sleep" auf die Sekundenzahl gesetzt, die das Gerät im Schlafmodus verbringen soll. In meinem Beispiel sind das 12 Stunden oder 43.200 Sekunden:

Diese Information wird anschließend als Push-Nachricht über einen mqtt-out-Node an den MQTT-Server gesendet, wobei das Topic wie folgt lautet "awtrix_test/sleep".