Wer HMIP-Wandtaster wie z.B. den HMIP-WRC6, der HMIP-WRC2 oder den HMIP-BRC2 besitzt hat sich vielleicht schonmal gefragt, warum man das Drücken einer Taste auf den Schaltern als Events nicht mit Openhab, Node-Red oder IOBroker abfragen kann, um z.B. Geräte anderer Hersteller zu bedienen.  Dies liegt daran, dass die Schalter im  Normalfall keine Events an eine CCU schicken, wenn eine Taste betätigt wird. Bei Taster-/Aktoren-Komibinationen tritt dieses Thema nicht auf, da sie immer Events an die CCU schicken.

Warum ist das so?

Einige diese Wandtaster funktionieren mit Batterien. Daher hat EQ3 eine Möglichkeit gesucht, den Batterieverbrauch zu reduzieren. EQ3 geht davon aus, dass die meisten Taster über eine Direktverbindung mit dem Aktor verbunden sind. Diese Direktverbindung wird immer im Gerät gespeichert. Daher hat EQ3 die Geräte so konfiguriert, dass sie ihre Aktionen nicht automatisch an die CCU senden. D.h. eine Tastendruck löst über die Direktverbidnung zwar einen Aktor (z.B. Licht aus), die CCU erhält aber nicht die Info, dass dies über einen Tastendruck erfolgt ist. Stattdessen sieht die CCU, dass der Aktor seinen Zustand geändert hat. Die folgenden beiden Möglichkeiten erzeugen dennoch diese Events, so dass man sie auch mit Drittsystemen empfangen kann. Die Lösung bezieht sich dabei auf eine CCU und nicht auf einen HAP.

Events durch Programme erzeugen

Die erste einfache Möglichkeit ist, Dummy Programme zu erstellen, in denen ein Taster abgefragt wird. D.h. man erstellt ein neues Programm auf einer CCU und fragt z.B. ab, ob der Wandtaster mit einem kurzen Tastendruck betätigt wurde. Es wird kein Befehl ausgeführt, so dass das Programm nur aus einer Abfrage besteht.

Nach Speichern des Programms wird durch die CCU eine Konfigurationsänderung an den Taster geschickt, der bei batteriebetriebenen Geräten bestätigt werden muss.

Im Anschluss erhält die CCU bei jedem Tastendruck einen Event. Diesen Event kann man dann auch mit Drittsystemen abfragen, da er durchgereicht wird. Dabei ist es nun egal, wie die Taste gedrückt wird, der Event wird immer generiert.

Als ich allerdings versucht habe, ganz viele Oder-Bedingungen mit verschiedenen Tastern  in einem Programm abzufragen war das Ergebnis, dass nur das Event des ersten Tasters tatsächlich generiert wurde. Ich schließe daraus, dass für jeden Taster (nicht für die Art des Tastendrucks) ein eigenes Dummy-Programm erzeugt werden muss. Daher habe ich mich für die zweite einfachere Möglichkeit entschieden.

Events über Kanaleinstellungent aktivieren

Ja, diese Möglichkeit gibt es, ich habe sie bisher übersehen.

Zu jedem Gerät und Taster gibt es einen eigenen Kanal. Wer in den Geräteeinstellungen den Kanal mit dem gewünschten Taster anklickt (nicht auf Einstellungen gehen sondern nur auf den Namen klicken) erhält folgenden Screen:

Hier befindet sich ganz unten der Bereich "Taster-/Schaltevent an Zentrale" und darunter zwei Button mit "Aktivieren" und "Deaktivieren". In der dazugehörigen Hilfe weist EQ3 nochmal auf den Grund hin, warum dies Events nicht automatisch erzeugt werden. Drücke ich den Aktivieren-Button, dann fragt die CCU, ob eine Verknüpfung des Tasters mit der CCU angelegt werden soll (dies ist keine Direktverknüpfung). Nach Bestätigung dieser Meldung und Bestätigen des "OK"-Buttons im Hauptfenster schickt die CCU anschließend eine Konfigurationsänderung an den Taster. Nach dem Bestätigen dieses Events auf einem batteriebetriebenen Taster empfängt die CCU ab sofort alle Events, wenn eine Taste betätigt wurde.

Hinweis: Wenn man vorher ein Programm angelegt hat (siehe oben) um das Thema zu lösen, dann wird mit dem Löschen des Programms auch automatisch wieder eine Konfigurationsänderung an den Taster geschickt, die das Gerät vorher bestätigen sollte, bevor die zweite Lösung umgesetzt wird.

Mit dieser Lösung lassen sich jetzt auch die Events von HMIP-Tastern einfach in anderen Systemen empfangen und können dort Aktionen z.B. mit Aktoren anderer Hersteller auslösen.

Die Installationen  von Balkonkraftwerken nimmt stetig zu. Hierüber kann tagsüber zusätzlich Strom erzeugt werden, der den Stromverbrauch in einem Haushalt durch direkten Konsum senken kann. Wer bereits Homematic-IP Komponenten nutzt, kann diese Messung auch einfach in die vorhandene Gerätewelt von HMIP integrieren.

Schalt-/Mess-Steckdose für den Innenraum

Soll das Balkonkraftwerk über eine Zuleitung ins Haus an eine Steckdose angeschlossen werden, kann die HMIP-PSM Schalt-Mess-Steckdose zu verwenden.

EQ3 hat Ende 2021 ein Update für die Firmware der Strom-/Mess-Steckdose HMIP-PSM bereitgestellt. Die aktuelle Version der Firmware 2.22.8 unterstützt auch die Messung als Leistungsempfänger und nicht nur als Verbraucher. Hierzu ist es wichtig, zwei Einstellungen vorzunehmen. Ich habe dies beispielhaft unter einer CCU3 vorgenommen, das Ganze sollte auch mit einem Homematic Access Point funktionieren.

Als erstes sollte in den Einstellungen  des BSM unter "Verbrauchs- und Leistungsmessung" als Modus "Einspeisemodus" gewählt werden. Zusätzlich empfehle ich, in den Kanälen des Schaltaktors die Option "Aktion bei Spannungszufuhr" auf "Ein" zu stellen. Wenn mal der Strom ausfällt oder die Sicherung ausgeschaltet wird ist gewährleistet, dass die Steckdose immer sofort eingeschaltet wird, da sonst auch kein Strom vom Balkonkraftwerk in euer Hausnetz fließen würde.

Schalt- und Messaktor für den Außenbereich

Die Schalt-Mess-Steckdose sollte nicht in eine Außensteckdose gesteckt werden, da sie nicht spritzwassergeschützt ist. Daher bietet sich hier eine andere einfache Lösung an. Der Unterputz Homematic IP Schalt-Mess-Aktor HmIP-FSM16 bietet die gleiche Funktionalität wie die Schalt-Mess-Steckdose HMIP-PSM. Hierfür muss nur das Firmware Update 1.22.8 installiert werden. Anschließend kann in den Einstellungen für das Gerät ebenfalls wie oben beschrieben der "Einspeisemodus" gewählt werden.

Den HMIP-FSM16 kann man nun in eine IP65 oder IP66 Dose einbauen, die es in allen Baumärkten gibt. Mit Kabelverschraubungen ebenfalls aus dem Baumarkt kann man dann zwei Kabel (Zu-/Ableitung) mit einer Gummikupplung und einem Gummistecker und dem HMIP-FSM16 zusammenschalten. Fertig ist der Schalt- und Messaktor für den Außenbereich, der nun einfach zwischen Stecker des Balkonkraftwerkes und der Außensteckdose platziert wird. Die Teile gibt es auch als Kompletpaket bei ELV unter dem folgenden Link.

Da die Kabel relativ tief in den HMIP-FSM16 eingefügt werden müssen und ich flexible Anschlussleitungen verwende, habe ich diese über ein paar WAGO-Kleemmen mit einem starren Kabel verbunden, die ich dann in den FSM16 gesteckt habe. Man kann die flexiblen Leitungen auch mit Hülsen crimpen, wenn man Hülsen hat, die lang genug sind.

Aufzeichnen

Verwendet Ihr eine CCU kann das Aufzeichnen des Verbrauchs anschließend über CCU-Historian erfolgen, oder die Daten werden z.B. über NodeRed an eine InfluxDB weitergegeben und mit Grafana visualisiert. Wie das geht steht in einigen älteren Artikeln auf dieser Webseite. Um die Leistung pro Tag zu erfassen reicht es aus, den Stromzähler des FSM16 oder des PSM auszulesen (Datenpunkt ENERGY_COUNTER), für die aktuelle Leistung ist der Datenpunkt "POWER" entscheidend. Beim PSM können diese in Kanal 6, beim FSM16 in Kanal 5 ausgelesen werden.

TIPP:

Leider hat der Datenpunkt ENERGY_COUNTER des Gerätes einen Nachteil: Er zählt die erzeugte Leistung in Wattstunden, so dass ganz schnell die Grenze der Speichervariable erreicht wird und sich diese intern wieder auf Null setzt. Dies erzeugt dann in Auswertungen unschöne Sprünge oder Peaks. Wer das vermeiden möchte kann mithilfe einer CCU das zu jeder Messteckdose existierende versteckten Programme und die versteckte Systemvariabeln "anzapfen" und die Werte in kWh in einer eigenen Systemvariable ablegen. Damit wird der zuvor beschriebene negative Effekte bei einem Overflow vermieden. Wer nicht weiß wie das geht, kann mir dazu gerne eine Nachricht schreiben.

Nachdem mein alter Ferraris Stromzähler ausgetauscht wurde habe ich mir vorgenommen, alle Werte der Stromzähler zu digitalisieren und kontiniuerlich zu protokollieren.

Ziel war, hier so wenig Aufwand wie möglich zu investieren. Daher habe ich nach einer möglichst vorgefertigten Lösung für Infrarotsensoren gesucht. Der für mich passende Sensor ist die Lösung, die auch auf Volkszähler.org beschrieben ist.

Die folgende Lösung habe ich exemplarisch für folgende SmartMeter von ISKRA erstellt (eine Anpassung an andere Hersteller ist einfach möglich):

• ISKRA MT681
• ISKRA MT175

Für eine Erfassung und Weiterverarbeitung der Werte möchte ich Tasmota auf einem Wemos D1-Mini benutzen.

Es gibt viele Seiten mit verschiedenen Erläuterungen zum Anschluss der SmartMeter. Mir hat u.a. auch folgender Link geholfen:

https://hessburg.de/tasmota-wifi-smartmeter-konfigurieren/

Sensorauswahl

Die Zähler von ISKRA geben erfasste Daten über eine Infrarot-Schnittstelle aus. Um diese auszulesen ist ein Infrarotempfänger, für eine Befehlsübetragung (die ich aber nicht brauche) ein Infrarotsender erforderlich. Wer so einen Sensor selber bauen möchte findet hierzu im folgenden Video die nötigen Informationen:

Da ich keine großen Lötarbeiten durchführen wollte, habe ich mich für eine (fast) fertige Lösung entschieden, nämlich den

ttl ir lesekopf lese-schreib-Kopf EHZ Volkszähler Hichi Smartmeter, der auf ebay für ca. 19 Euro zu finden ist. In einem 3D-gedruckten Gehäuse befindet sich die bereits fertiggestellte Platine.  Man muss nur noch eine 4-adrige Leistung anlöten. Hierzu empfehle ich, ein einfaches Telefonkabel mit 4 Adern zu verwenden. Da die Lötstellen auf der Platine sehr nah am Rand sind, habe ich das Kabel umgekehrt angelötet, d.h. ich führe dieses über die Platine zur Lötstelle und kann somit eine bessere Zugentlastung realisieren.

Die 4 Adern benötigt man für

1. die 3.3. Volt Spannungsversorgung
2. GND (Nullleiter)
3. RX (Empfangskanal)
4. TX (Sendekanal)

Da ich nur Daten empfangen möchte würden auch 3 Adern ausreichen.

Den Sensor befestige ich nun auf der optischen Infrarotschnittstelle des ISKRA MT175. Dabei ist die Diode 1 der Empfänger und die Diode 2 der Sender. Dementsprechend muss der Hichi Sensor umgekehrt auf der optischen Schnittstelle angebracht werden, d.h. Sender auf Empfänger und Empfänger auf Sender . Wer hier genau hinschaut wird feststellen, dass es eine dunkle LED gibt. Dies ist der Empfänger und die helle Diode ist dementsprechend der Sender.

Der Anschluss der Adern an den D1 Mini habe ich in folgendem Schaubild dargestellt:

Freischaltung optische Schnittstelle

Die von den Energieversorgern (oder Netzbetreibern) bereitgestellten SmartMeter können häufig erst nach einer Freischaltung der optischen Schnittstelle Daten übertragen. Daher ist es notwendig, sich von seinem Energieversorger den Freischaltcode zu besorgen. Mit diesem kann man anschließend die Übertragung der Daten über die optischen Schnittstelle freischalten. Anleitungen hierzu kann man leicht im Internet finden. Der ISKRA MT175 besitzt zur Vereinfachung einen blauen Button, mit dem man den Code eingeben kann. Ansonsten verwendet man einfach eine Taschenlampe, mit der man den Code über den optischen IR-Sensor eingibt.

Vorteil der Freischaltung ist, dass damit auch weitere Werte vom SmartMeter erfasst und ausgelesen werden können. Hierzu gehören beispielsweise die aktuelle Leistung sowohl beim Verbrauch als beim Ertrag (Photovoltaik).

Tasmota konfigurieren

Um die Sensordaten auszulesen, muss der D1-Mini mit Tasmota geflasht werden. Hier ist insbesondere wichtig, dass die Scripting-Funktionalität für Tasmota freigeschaltet ist, sonst kann man die Daten nicht verarbeiten.

Wie man das macht, habe ich bereits in meinem folgenden Beitrag beschrieben:

Tasmota Scripting aktivieren

In Tasmota müssen keine GPIOs über das Menü "Configure Module" konfiguriert werden. Stattdessen kopiert man sich von der Tasmota-Seite einfach das Script für das gewünschte Smartmeter herunter. Diese Scripte sind auf folgender Seite zu finden:

https://tasmota.github.io/docs/Smart-Meter-Interface/

Das passende Script kopiert man unter dem Menüpunkt "Console/Edit Script" einfach in den Editor. Wichtig ist, dass oben das Häkchen neben "Script enabled" aktiviert wurde!

Wenn alles richtig gelaufen ist, dann sollten auf der Tasmota Startseite, die im Script aktivierten Werte erscheinen. Das könnte z.B. wie folgt aussehen (ich habe die Bezeichnungen hier schon geändert, siehe dazu das nächste Kapitel):

Wenn das so nicht funktioniert, dann habe ich im übernächsten Kapitel ein paar Tipps, wie man den Fehler finden kann.

TASMOTA Script verstehen

Die von der Tasmota-Seite kopiertem Beispielscripte kann man modifizieren und einfach im Scirpteditor ausführen lassen.

Da es hier aber ein paar kleiner Fallstricke gibt macht es Sinn, dieses Script zumindest teilweise zu verstehen. Für den ISKRA MT175 sieht das Ganze so aus:

Die Scriptsprache ist in der Tasmota Doku in zwei Abschnitten beschrieben

1. Für das Auslesen der Smart Meter findet man hier alle Infos
2. Für die Verwendung der Scriptsprache sind hier die vielen Sprachdetails zu finden. Wer bisher mit Rules gearbeitet hat, kann diese Befehle mit einem kleinen Präfix "=>" weiter verwenden.

Wichtig ist, dass man sich streng an die Syntax hält. So ist z.B. bei einer IF-Abfrage unbedingt notwendig, das "then" in eine neue Zeile zu schreiben, damit die folgenden Befehle auch ausgeführt werden.

Ebenso gibt es den Hinweise, dass in dem ">M" Block Kommentare zu Fehlern führen können und am Ende vor dem Hashtag keine Leerzeichen stehen sollten.

Ausprobieren kann man alles, in dem man das Script speichert und sich die Ergebnisse dann in der Console anschaut. Ja, das ist ein wenig Hin- und Herklicken, funktioniert bei diesem Interpreter aber sehr einfach. Fehlermeldungen werden auch ausgegeben, allerdings manchmal etwas wenig aussagekräftig, so dass es sinnvoll ist, in der Doku nachzuschauen.

Der Inhalt des Scriptes lässt sich wie folgt erläutern:

">D" bedeutet, dass ab hier die Deklaration von Variabeln erfolgt. In den Smartmeter-Scripten ist dies nicht notwendig. Wer aber später Variabeln für die weitere Verarbeitung braucht, kann diese unterhalb dieses Statemenst platzieren.

">B" hier beginnt der Block, in dem der Code steht, der beim Booten ausgeführt werden soll. Dieser bleibt ebenfalls immer stehen.

"Sensor53 r" ist ein fester Befehl, der das Einlesen der SmartMeter-Beschreibungen initiiert. Hier braucht nichts geändert zu werden.

">M 1" gibt an, dass hier der Block für die SmartMeter Beschreibungen kommt. Wer hier beispielsweise zwei oder drei SmartMeter auslesen will, der gibt anstelle der "1" eine "2" oder "3" an.

"+1,14,s,16,9600,MT175". Die Zeile ist recht einfach zu verstehen, alle Werte müssen durch Kommata getrennt werden.

"+1" bedeutet, dass hier die Deklaration des ersten SmartMeters kommen (wenn da +2 drin stehen würde, dann wäre es der zweite SmartMeter, usw.).

"14" gibt die GPIO Nummer an an der der RX-Kanal aufgesteckt wurde. In diesem Beispiel ist dies Port D5. Nehmt Euch hierzu ein Bild eines D1-Mini und schaut die Nummer einfach nach. Diese Nummer muss unbedingt an Eure Lösung angepasst werden, wenn Ihr einen anderen Port verwenden wollt. Hier liegt dann auch ein häufiger Fehler, wenn´s mal nicht funktioniert.

"s" das s gibt an, dass es sich um einen SML-SmartMeter handelt.  Hier würde ein "w" stehen, wenn es sich um einen OBIS-SmartMeter handelt. Damit wird also das Protokoll angegeben, um die Nachrichten des SmartMeters decodieren zu können. Normalerweise sollte das Protokoll auf dem SmartMeter stehen, alternativ könnt Ihr Euren Energiversorger fragen.

"16" Dies ist ein Flag, welches angibt,  das hier ein Medianwert aus den empfangenen Daten ermittelt werden soll. Das ist sinnvoll, wenn es beispielsweise mal Unterbrechungen gibt oder sich Werte sehr schnell umfangreich ändern. I.d.R. braucht man das nicht anzupassen.

"9600" ist die Baudrate, mit der die Daten über die Infrarot-LEDs übertragen werden. Dies hängt vom SmartMeter ab, dennoch braucht dies i.d.R. nicht angepasst zu werden.

"MT175" ist der Name den dieser SmartMeter erhält. Dieser kann frei gewählt werden, sollte aber knackig kurz sein (wegen des begrenzt verfügbaren Speichers). Über diesen Namen kann man später die einzelnen Werte in einer Scriptsprache ansprechen.

Als nächstes fehlen nun noch die Definition der Werte, die empfangen, formatiert und dargestellt und wo diese in Tasmota gespeichert werden sollen.

Hierzu die folgende Beispielzeile des MT175

1,77070100100700ff@1,Leistung,W,Power_curr,1

"1" gibt an, dass es sich im den ersten Smartmeter handelt.

"77070100010800ff@1000" gibt das Datenpaket an, welches ausgelesen werden soll.

"@1000" in den Beispielscripten steht hier entweder @1000 oder @1. Ich habe bisher nicht herausfinden können, ob es sich bei dem Parameter um die Auflösung des auszulesenden Wertes oder um eine andere Form der Formatierung handelt.

"Leistung" ist ein String, der die Bezeichnung des Datenwertes darstellt und auch im MQTT verwendet wird (kann beliebig geändert werden).

"W" ist ebenfalls ein String, der die Einheit für die Konsolenausgabe darstellt (kann beliebig geändert werden).

"Power_Curr" ist ein String, der den Variablennamen angibt, in dem die Daten gespeichert werden. Wenn der Wert im Script weiter verarbeitet werden soll, dann wird der Wert über diesen Variablennamen angesprochen (kann beliebig geändert werden).

"1" gibt die Anzahl der Nachkommastellen an (kann beliebig geändert werden).

Die guten Beispielscripte auf der Tasmota-Seite beinhalten häufig eine große Anzahl von möglichen zu empfangenden Werten. Da nicht immer alle Werte gebraucht oder auch vom Smartmeter gesendet werden, löscht man einfach die Zeilen mit diesen nicht benötigten Werten.

Fehler suchen

Ja, auch mir ist es passiert, das erst einmal nichts funktioniert hat, daher anbei meine Tipps, wie man hier schnell zu einer Lösung kommt:

1. Prüfen, ob die Lötstellen fest sind. Da es sich nur um 4 Adern handelt ist das relativ einfach möglich (ich habe alle Lötstellen ein zweites Mal mit dem Lötkolben erwärmt und die Kabel fixiert).
2. Prüfen, ob der SmartMeter sendet. Da man so in den kleinen optischen Fenstern nichts sieht, nimmt man einfach ein Smartphone geht auf die Fotofunktion und hält die Kamera auf den Fotosensor. Da die Kameras auch UV-Licht sichtbar machen können, sollte hier ein zyklisches Blinken zu sehen sein. Wenn dem nicht so ist, dann muss der SmartMeter evtl. noch mit der PIN des Energieanbieters freigeschaltet werden.
3. Prüfen, ob der Sensor richtig auf der Sendefenster sitzt. SmartMeter, wie der ISKRA MT175 besitzen 2 Dioden, die zum Senden und Empfangen gedacht sind. Der Sensor hat ebenfalls zwei Dioden, so dass Sender auf Empfänger und Empfänger auf Sender sitzen sollte. Die einfache Regel ist, dunkle/schwarze Diode des SmartMeters auf helle Diode des Sensors und umgekehrt. Manchmal ist das runde Ding auch einfach nur zu weit gedreht worden, d.h. achtet darauf, dass das Kabel möglichst senkrecht oben oder unten aus dem Sensor herauskommt.
4. Prüfen, ob das RX-Singal auch an einem RX-Kanal des D1 Mini angeschlossen ist. Da die Kabel alle unterschiedliche Farben haben, kommt man hier schnell durcheinander. Deswegen empfehle ich, RX und TX Kabel entweder zu markieren oder die Farben für die Kanäle aufzuschreiben und diese dann bis zum PIN des D1-Mini korrekt zu führen.
5. Prüfen, ob die Spannung und Erdung (GND) richtig geschaltet sind. Gerade, wenn man Breadboards verwendet, kann schnell ein Kabel locker sein, so dass kein Strom fließen kann. Achtet bitte auch darauf, eine Spannungsversorgung nur über die 3.3 Volt Leitung vorzunehmen.
6. Testen, ob die Kommunikation funktioniert. Hierzu kann in der Tasmota Console folgender Befehl verwendet werden: "Sensor53 d1". Dies bewirkt einen Dump aller empfangenen Werte des SmartMeters und die Darstellung auf der Console. Wenn als Ergebnis eine Masse von Hexadezimal-Werten erscheinen, dann ist alles richtig (die Decodierung erfolgt durch die o.a. Scripte und Erläuterungen).
7. Prüfen, ob die richtige Portnummer für den Datenempfang im Script angegeben wurde. Man vergisst leicht, dass der GPIO, an dem der RX-Kanal angeschlossen ist, auch im Script eingetragen sein muss. Die Beispielscripte nutzen teils andere Portnummern. Ich hatte das erst nicht geändert und hab daher stundenlang nach dem Fehler gesucht, bevor ich diese einfache Lösung gefunden habe.
8. Prüfen, ob man das richtige Script für sein SmartMeter gewählt hat. Es gibt mittlerweile eine Vielzahl von Scripten für unterschiedliche SmartMeter. Nur wenn man das passende Script für sein SmartMeter verwendet, werden die Werte richtig ausgelesen. Eine Vielzahl von Scripten für unterschiedliche Smartmeter sind auf der Tasmota Seite unter SMartMeter Descriptors zu finden.

Weiterverarbeitung der Daten

Die Daten werden automatisch (wenn man den MQTT-Server eingestellt hat) per MQTT übermittelt, so dass man mit Drittsystemen auf die Werte zugreifen kann. Ich empfehle, diese z.B. über Openhab, NodeRed oder IOBroker in Verbindung mit eine Datenbank z.B. in influxdb zu speichern und per Grafana darzustellen, so erhält man einen super Überblick über zeitabhängige Verbräuche oder die Stromerzeugung.

Wenn man mit der Scriptsprache die Werte weiter verarbeiten möchte, dann kann man z.B. wie folgt die Werte ansprechen

tmp1=MT175#Total_in

und mit diesen Variablen und der Scriptsprache weiter arbeiten.

Ich versende z.B. die Werte zusätzlich an eine CCU3, indem ich in den Scripten die folgende Zeile aufrufe:

=>WebSend [192.162.153.17:8181]/cuxd.exe?ret=dom.GetObject("SV_Stromzaehlerstand").State(%tmp1%)

Insgesamt lässt sich mit der hier beschriebenen Lösung einfach arbeiten und auch die Einrichtung hat nicht viel Zeit in Anspruch genommen.

Die Digitalisierung von Gas- und Wasserzählern in einer SmartHome Lösung führt zu einer höheren Transparenz der Verbrauchskosten, wenn man mit Gas heizt und Warmwasser erzeugt. Bei den bestehenden Gaszählern in Privathaushalten  handelt es sich fast immer um Balgengaszähler, die die verbrauchten Kubikmeter an Gas zählen.

Aufgabenstellung

Für mich stellte sich die Frage, wie man einen Gaszähler und einen Wasserzähler digital auslesen und die Ergebnisse auch an eine Homematic CCU oder andere Smarthome Lösungen wie z.B. Openhab oder IOBroker übertragen kann.

Ich nutze bereits Tasmota auf anderen D1 Mini's. Für Tasmota habe ich auch die Scripting Funktionaliät aktiviert (siehe auch meinen Beitrag Tasmota Scripting aktivieren, wie man sich eine eigene Tasmota Version kompiliert).

Ich besitze einen Balgengaszähler vom Typ BK-G4. In diesem befindet sich unter der Zähleranzeige eine kleine Öffnung. Die Zähler sind mit einem rotierenden Magneten ausgestatt (i.d.R. an der Ziffer 6 als sichtbarer silberner Belag, der beim Rotieren von außen gemessen werden kann). Die kleinste messbare Einheit ist vorne auf dem Zähler angegeben z.B. in der Form 1imp 0,01m³.

Der Wasserzähler ist ein Aquadis+ P50 von Itron. Dieser besitzt eine kleine Drehscheibe auf der sich ein kleines silbernes magnetisches Dreieck befindet.

Sensor installieren

Um den kleinen Magneten auf der Zählscheibe des Gaszählers messen zu können, ist ein einfacher Reedkontakt erforderlich (wie z.B. bei Fensterkontakten). Ich habe mir dazu bei Conrad den Sensor MK04 bestellt. Dieser besitzt zwei Leitungen. Die eine wird auf dem Pin GND und die andere auf einem beliebigen anderen PIN angeschlossen. Dieser PIN wird dann als SWITCH konfiguriert (siehe nächstee Kapitel).

Das Prinzip eines Reedkontaktes ist recht einfach. Durch einen Magneten wird ein Schalter bewegt, der eine Verbindung zwischen zwei Kabeln herstellt, so dass dort ein Strom fließen kann. Verschwindet der Magnet, so wird der Schalter wieder geöffnet, die Verbindung ist damit getrennt. Jedes Schalterschließen entspricht dabei einem Wert von 0,001 m³.

Den Sensor befestigt man mit Klebeband oder mit einem gedruckten Gehäuse von unten in der Vertiefung unter dem Zähler. Ich habe den Sensor mittig unter der letzten Zählerscheibe angebracht, das muss man aber ausprobieren.

Für den Wasserzähler mache ich es mir einfach. Hierfür gibt es bereits einen fertigen Sensor, den man einfach nur auf den Wasserzähler aufstecken muss. Ein Reedkontakt wie für den Gaszähler würde aber auch funktionieren. Ich verwende von Itron das Modell "Cyble-Sensor V2 KLF 1" (K-Faktor=1, LF-Signal)" mit 2 Adern. Dieser liefert mir pro Liter Verbrauch ein Signal.

Es empfiehlt sich, vor der Installation der Sensoren Tasmote (wie in den nächsten Kapiteln beschrieben) auf dem D1 Mini zu konfigurieren und mit diesem direkt zu prüfen, ob ein Signal in Tasmota ankommt. Dies sieht man immer dann, wenn in der Console eine MQTT Nachricht abgesetzt wird.

Auf einer Vielzahl von Webseiten ist die Installation eines Reedkontakts am Gas- und Wasserzähler bereits dargestellt, z.B. unter

http://monitor4home.com/beispiele/gaszahler-mit-reedkontakt-ausstatten

http://blog.bubux.de/gaszaehler-auslesen/

https://smart-wohnen.org/homematic-wasserzaehler-auswerten/

Sensorwerte an MQTT Broker übertragen

Für eine Nutzung von Gas- und Wasserzählerwerten reicht die Digitalisierung des Impulses und die Übertragung an ein weiteres System, was aus diesen Impulsen Werte berechnet. Am einfachsten ist die Verwendung des MQTT Protokolls, da dies fast alle zentral verarbeitenden Smarthome Systeme verstehen.

Die Telemetry Period lasse ich übrigens auf 300 stehen, da TASMOTA automatisch einen geänderten Sensorwert per MQTT übermittelt. Die Telemetry Period gibt nur an, wann spätestens ein Status per MQTT übermittelt wird.

Schritt 1

Um den Reedkontakt in Tasmota zu konfigurieren verwende ich einen Switch, der auf PIN D1 liegen soll. Der Switch toggled zwischen ON und OFF hin und her, je nachdem, ob der Schaltkreis offen oder geschlossen ist. Ein Switch wird nach der Einrichtung als Button mit der Bezeichnung "SWITCH 1" dargestellt, den man wie einen Button auch manuell betätigen kann. Der Toggle Mode des Switches ist per Default eingestellt, diesen kann man aber über die Console auch mit dem Befehl "SwitchMode" umstellen. Die Modes sind auf dieser Tasmota Seite erläutert.

In der Console sollte man nun sehen, welche Werte per MQTT über den Switch gesendet werden (ich habe hier noch einen Switch mehr verwendet verwendet):

15:07:57.409 MQT: tele/AZD-TEST/SENSOR =

und

15:07:58.310 MQT: stat/AZD-TEST/RESULT=

Hier kann man nun auch kontrollieren, ob der Switch bei geschlossener Verbindung "ON" oder bei geöffneter Verbindung "OFF" anzeigt (hängt vom Kabelanschluss ab). In meinem Test hatte der offene Zustan den Wert 1 (ON, der geschlossene Zustand der Wert 0 (OFF).

Schritt 2

Zwar funktionieren die Switche, aber es gibt zwei große Nachteile:

• Der Status der Switche wird nicht auf der Tasmota Console angezeigt
• Per MQTT wird bei mehr als einem Switch immer nur ein Switch STATUS geschickt, wenn sich dieser ändert. D.h. mit der RESULT Message (siehe oben) ist nicht identifizierbar, welcher Switch geschaltet wurde. Erst wenn die Telemetry Message erstellt wird (siehe oben) werden die Werte der beiden Switche per MQTT übertragen.

Dieses Verhalten ist mit dem Typ eines Switches zu erklären, für den es eigentlich gar keinen messbaren Status gibt. Stattdessen muss man gleichzeitig jedem Switch ein korrespondierendes Relay zuordnen, denn ein Switch schaltet per Default immer einen messbaren Power-Wert von ON auf OFF oder umgekehrt.

Switch und Relais werden durch die Nummernzuordnung einfach intern verbunden (Relais 1 und Switch 1).

In diesem Beispiel habe ich auch den PIN 3 für Switch 2 und PIN D4 für Relay 2 verwendet. Dieser steuert gleichzeitig auch die Mini-LED auf dem Board, so dass diese anfängt zu leuchten, wenn der Kontakt geschlossen wird.

Wenn man jetzt PIN D1 mit PIN GND verbindet, wird in Tasmota die Anzeige auf "ON" springen, wenn man die Verbindung auflöst wieder auf "OFF". Für einen zweiten Switch verfährt man genauso, wobei jetzt Schalter und Relay die Nummer 2 erhalten. Ebenso werden jetzt für jeden Switch bei einer Änderung die jeweiligen POWER-Werte sofort korrekt übertragen:

18:23:08.941 MQT: stat/AZD-TEST/RESULT =
18:23:11.832 MQT: stat/AZD-TEST/RESULT =

Welche Werte MQTT sendet kan man nun auch auf der Console betrachten. Sollte beim Schließen des Kontaktes "OFF" anstelle "ON angezeigt werden, dann invertiert man das Relay indem man den Typ Relay_i wählt.

Auf der Console sieht das Ganze dann so aus (mittels des Befehls "WebButton" , kann man die Beschriftung der Button ändern)

Sensorwerte an eine Homematic CCU übertragen

Neben der automatischen Versendung der MQTT Nachrichten möchte ich noch den Status des Reedkontaktes an eine CCU schicken und zwar nur dann, wenn sich der Wert tatsächlich geändert hat.  Die weitere Verarbeitung der Sensorwerte kann ich dann in der CCU vornehmen, so dass ich nur einen Wert übertrage, wenn sich der Reedkontakt verändert hat.

Hier ist jetzt noch folgendes zu berücksichtigen. Während MQTT Messages automatisch bei einem geänderten Sensorwert übertragen werden, muss ich bei der manuellen Übertragung berücksichtigen, wie häufig das Programm ausgeführt werden soll, um den Sensorwert "erwischen" zu können. Der Reedkontakt bei einem Wasser- oder Gaszähler ist höchstens eine Sekunde geschlossen, so dass ich einen Check sekündlich machen muss. Dies erreiche ich durch die Definition einer Sektion mit ">S", in der der Code steht, der sekündlich ausgeführt wird.

Das entsprechende kleine Programm für den Script Editor sieht nun wie folgt aus:

Das Script ist recht einfach.

In der ">D" Sektion wird die Variable definiert, die ich benötige um zu checken, ob sich ein Wert geändert hat. Je nachdem, ob der geöffnete Wert des Schalter ON oder OFF ist muss hier die Variable mit 1 oder 0 vorbelegt. Damit wird sichergestellt, dass bei einem Reset des D1 Mini der tatsächliche Zustand zu einem Zählen führt oder nicht.

In der ">B" Sektion weise ich der Hilfsvariablen direkt den Sensorwert zu. Damit verhindere ich, dass bei einem Reboot sofort der Zähler erhöht wird, wenn der Sensor auf "AN" steht. Denn ich möchte nur die vollständigen Zählimpulse erwischen.

In der ">S" Sektion trage ich nun das kleine Programm ein. Nun wird mittels sw[0] der erste (!) Switch ausgelesen. Der Rest erklärt sich von selber, eine Websend Message wird nur dann ausgelöst , wenn sich der Wert des Switches von 0 auf 1 ändert. Wichtig ist, dass die zweite Bedinung, die mit "and" beginnt in einer neuen Zeile steht. Hier ist Tasmota Interpreter sehr empfindlich.

Nun wird in der CCU immer ein Wert aktualisiert, wenn der Schalter geschlossen ist. Diese Variable kann man nun dort weiterverarbeiten, indem man beispielsweise bei jeder Änder der Systemvariable ein Programm ausführt um z.B. einen Zähler zu addieren.

Um aus den den Kubikmetern die kWh auszurechnen ist ein Blick auf eigene Gasrechnung  notwendig. Hier stehen die Faktoren die erforderlich sind, um eine Umrechnung vorzunehmen

Wenn man einen Bewegungsmelder einsetzen möchte hat man bei Homematic IP die Qual der Wahl. Im folgenden Beitrag habe ich drei dieser Sensoren für den Innenbereich getestet und hierzu ein paar Eindrücke gesammelt.

3 unterschiedliche Bewegungsmelder

Bei den von mir getesteten Bewegungsmeldern handelt es sich um folgende Modelle:

Alle Bewegungsmelder arbeiten mit Passive Infrarot Sensoren (PIR-Sensor). Die Batterielebensdauern habe ich nicht berücksichtigt, da dies immer vom Praxiseinsatz abhängt. Seitens eQ-3 werden aber mindestens 2 Jahre Lebensdauer angegeben.

Alle Sensoren ermöglichen den Sendeabstand einzustellen, sowie Bewegungen auch in den Sendepausen zu erkennen. Alle Bewegungsmelder melden einen Sabotagealarm, wenn sie während des Betriebs geöffnet werden.

Bewegungsmelder mit Dämmerungssensor HmIP-SMI

Der weiße Bewegungsmelder ließ sich einfach an der CCU anlernen. Irritierend war nach dem Anlernen die Phase, in der das Gerät häufiger rot blinkte. Im ersten Moment dachte ich, dass das Gerät die Kopplung nicht hinbekommt oder einen Fehler hat. Allerdings habe ich festgestellt, dass dieses rote Blinken nach einiger Zeit aufhört, das Gerät sauber in der CCU angezeigt wird und auch korrekte Daten liefert.

Die Erkennung von Bewegungen funktionierte einwandfrei, auch in Entfernungen bis zu 6 Metern. Ab 6 Metern müssen nach meine Erkenntnissen Bewegungen schon klar erkennbar sein. Das Umblättern von Zeitschriften reichte hier teilweise nicht mehr aus.

Angenehm ist die Möglichkeit, für das Auslösen des Sensors einen Helligkeitswert angeben zu können. Diesen ermittelt man am besten, indem man sich die Werte anschaut, die der Sensor bei verschiedenen Helligkeiten ausgibt, um den gewünschten Schwellwert dann einzutragen. Wichtig hierbei ist zu berücksichtigen, dass man die Zahl der Messungen angeben kann, von denen dann der geringste Wert als Auslöser für den Sensor verwendet wird. eQ-3 gibt hier einen Abstand von 6 Minuten pro Messung an.

Wenn eine Leuchte geschaltet wird sollte darüber hinaus beachtet werden, dass eine Anschaltzeit einer Leuchte größer oder gleich dem sogenannten Mindestsendeabstand ist, da sonst die Ein-/Ausschaltzeit der Leuchte durch den Mindestsendeabstand bestimmt wird. Diese Möglichkeiten gelten übrigens auch für den Präsenzsmelder.

Der Sensor kann auch in einer Raumecke installiert werden und dadurch mit dem 105 Grad Winkel einen ganzen Raum überwachen.

Folgende Parameter stehen für den Bewegungsmelder mit Dämmerungssensor in einer CCU zur Verfügung:

Präsenzmelder HmIP-SPI

Laut Werbung ist der Präsenzmelder auf die Erkennung von Präsenz, d.h. auf das Erkennen auch feinerer Bewegungen spezialisiert. Dazu wird er an der Decke installiert und kann mit einem 360 Grad "Blick" einen Bereich von 105 Grad unterhalb des Sensors abdecken.

eQ-3 gibt dabei an, dass die Sensibilität des Sensors abnimmt, je weiter man sich der 105 Grad Grenze nähert. Um dies zu testen, habe ich den Sensor direkt über einem Schreibtisch in eine Höhe von ca. 2,5 Metern platziert. Er erkannte auch feiner Bewegungen direkt unter dem Sensor recht gut (leichte Armbewegungen, etc.). Das stille Tippen auf eine Tastatur wurde dann doch manchmal nicht mehr erkannt. Mein Ziel, eine Lichtschaltung aufzubauen, bei der das Licht solange anbleibt, solange ich mich im Raum befinde hat daher nicht präzise genug funktioniert, so dass z.B. das Licht ausgeschaltet wurde, obwohl ich mich arbeitend am Schreibtisch befunden habe. Einwandfrei funktionierte hingegen die Erkennung von gröberen Bewegungen in einer Entfernung von bis zu 5 Metern (ist aber abhängig von der Installationshöhe des Sensors, d.h. je höher umso weiter funktioniert die Bewegungserkennung).

Die Möglichkeiten der Dämmerungsfunktion entsprechen den Beschreibungen des Bewegungsmelders mit Dämmerungsfunktion.

Folgende Parameter stehen für den Präsenzsmelder in einer CCU zur Verfügung:

Durchgangssensor HmIP-SPDR

Der Durchgangssensro wird mit den Gehäusefarben weiß und anthrazit geliefert. Empfohlen wird, diesen im Türrahmen einzubauen entweder geschraubt oder mit Klebestreifen. Ich habe diesen auf einer Hähe von ca. 90 Zentimetern so platziert, dass er einen Durchgang überwachen kann. Das Anlernen funktionierte einwandfrei. Eine Dämmerungsfunktion hat er im Vergleich zu den anderen Sensoren nicht.

Bei den anschließenden Tests fiel mir auf, dass der Sensor Bewegungen in die eine Richtung erkannte (links), rechts hingegen deutlich weniger Bewegungen zählte. Ich habe daraufhin nochmal die Lage leicht angepasst (Ausrichtung parallel zum Laufweg). Dies hat allerdings zu keiner Verbesserung geführt, das Gerät zählte die eine Richtung (links) scheinbar sensibler, als die Richtung von rechts. Trotz genauem Studiums der Anleitung konnte ich nicht herausfinden, wie man dieses Verhalten verändern kann, so dass korrekt gezählt wird. eQ-3 weist in der Anleitung darauf hin, dass bei mehreren Personen durchaus ein Erkennen schwierig werden kann. Allerdings ist dieser Fall in meinen Tests nicht vorgekommen. Ebenfalls habe ich nicht herausgefunden, wie man ohne Programmierung den Zähler zwischenzeitlich für rechts oder links auf Null zurücksetzen kann.

Folgende Parameter stehen für den Durchgangssensor in einer CCU zur Verfügung:

Darüber hinaus gibt es mehrere Optionen, die Betriebsart (d.h. die Art des Zählens) einzustellen, so dass Ereignisse in Abhängigkeit davon ausgelöst werden können:

FAZIT

Der Durchgangssensor HmIP-SPDR hat mich am wenigsten überzeugt. Das Feauture der richtungsabhängigen Durchgangserkennung funktionierte nicht zuverlässig genug. Dabei habe ich nicht rausfinden können, wann der Sensor eine Bewegung von der einen oder der anderen Seite zuverlässig erkennt. Damit erkennt der Sensor nur Bewegungen zuverlässig, ist aber durch die geringe Reichweite und den hohen Preis somit im Nachteil gegenüber den anderen Sensoren.

Der Bewegungsmelder HmIP-SMI  hingegen macht seine Sache bzgl. Bewegungserkennung auch in großen Entfernungen seht gut. Mit der Möglichkeit der Eckmontage und dem geringsten Preis ist er für mich die erste Wahl bei der Bewegungserkennung.

Der Präsenzmelder HmIP-SPI arbeitet erkennbar sensibler als der Bewegungsmelder HmIP-SMI und ist somit eine Alternative zu diesem Sensor. Allerdings hat auch dieser Sensor seinen Grenzen bei feinen Bewegungen, so dass er nicht alles erkennt insbesondere wenn der Abstand zwischen Sensor und Bewegungsort zu groß wird. Hat man einen großen Raum und platziert diesen an der Decke, dann müssten mehrere Sensoren so platziert werden, dass diese den ganzen Raum abdecken.

Wer eine elektrische Markise hat, möchte dass die Markise bei zu starkem Wind oder bei Regen besser eingefahren wird, damit die Markise keinen Schaden erleidet. Diesen Ausfahrschutz kann man für eine ausgefahrene Markise recht einfach erreichen, aber was ist, wenn man vor dem Ausfahren der Markise erst checken möchte, ob es regnet oder der Wind zu stark ist? Basis bei mir ist die Verwendung eines HMIP-BROLL Schalt-/Messaktors, der durch Drücken auf die obere Taste die Markise automatisch ausfährt und durch Drücken auf die untere Taste einfährt.

Lösungsansatz

Grundsätzlich brauche ich zuerst ein kleines Programm, welches nach einem Tastendruck prüft, ob es nicht regnet oder die Windgeschwindigkeit kleiner einem definierten Grenzwert ist. Ich nutze als Sensoren sowohl den HMIP Regensensor als auch die HMIP Wetterstation Pro mit dem Windmesser. Das Programm sieht wie folgt aus:

Wer das bis hierin genauso macht wird allerdings feststellen, dass beim Ausfahren trotzdem nichts geprüft wird.  Woran liegt das ?

Hier spielt nun das Thema Direktverknüpfung (oder beim Access Point die Gruppen) eine Rolle. Beim Anlernen des Rollladenaktors (HMIP-BROLL) werden automatisch zwei Direktverknüpfungen angelegt. Eine für den oberen Taster (i.d.R. Kanal 2) und eine für den unteren Taster (Kanal 1). Diese Direktverknüpfungen werden als Toggle Verknüpfungen erstellt und führen dazu, dass direkt im Schaltaktor das Aus- und Einfahren der Markise hinterlegt wird. Dabei ist nicht vorgesehen, dass vorher noch ein kleines Programm ausgeführt wird. Da es sich um eine im Geräte gespeicherte Information handelt, wird diese somit ohne Kommunikation mit CCU oder HAP ausgeführt.

Daher muss die Direktverknüpfung zwischen dem Taster für das Herunterfahren der Markise und dem Rollladen-Aktor gelöscht werden, damit das zentrale Programm zukünftig nur noch den Ausfahrvorgang durchführt. Im folgenden Bild ist die Direktverknüpfung zu sehen, die ich dazu auf der CCU gelöscht habe.

Im Anschluss steuert nun das oben erstellt Programm das Ausfahren der Markise und checkt ab sofort vorher, ob es regnet oder stark windet.