So nach und nach bringe ich viele meiner Smarthome Komponenten auf einen gemeinsamen Standard. Dabei habe ich mich entschieden, sämtliche Geräte über einen NodeRed Server zusammen zu führen. Auch das HomeMatic System kommuniziert mit NodeRed. Hier übergebe ich unter anderen auch die Messwerte des EVU-Zählers (bei mir ist ein Siemens IM350 Smartmeter verbaut) an die HomeMatic CCU. Dies geschieht wie schon einem früheren Beitrag erwähnt, über die LED-Impulsschnittstelle (1000 Impulse/kWh). Hierzu wird einfach ein Fototransistor über der LED am Zähler angebracht, der die Blinkimpulse der LED erkennt und in der Zählersensor-Sendeeinheit HM-ES-TX-WM in die Momentanleistung umrechnet und über die Zeit integriert und die Daten dann an die CCU weitersendet. Das funktioniert an sich ganz gut. Nur die Aktualisierungsrate (im Minutenbereich) ist mir zu lange. Auch scheint der Fototransistor immer wieder auf das Streulicht der benachbarten LED (diese zeigt die Blindleistung in 1000 Impulse/kvarh an) zu reagieren. So entstehen Abweichungen zwischen der Zählung über den HomeMatic Sensor und den direkt am Zähler abgelesenen Werten.
Das geht auf jeden Fall genauer. Wenn man sich den IM350 Smartmeter Zähler im Detail ansieht, bzw. das Manual durchliest, so stellt man schnell fest, dass er eine sog. "Kundenschnittstelle" besitzt. Diese Kundenschnittstelle stellt einige Messdaten über eine galvanisch getrennte Datenleitung im Sekundentakt zur Verfügung. Dazu gehören unter anderen die momentane Wirkleistung in beiden Richtungen, sowie die Zählerstände von Wirk- und Blindleistung in Bezugs- und Einspeiserichtung. Also perfekte Ausgangbedingungen, um den HomeMatic Zählersensor durch eine eigene Konstruktion zu ersetzen. Nach ein wenig Internetrecherche habe ich schnell erkannt, dass ich nicht der Einzige bin, der sich mit genau dieser Thematik beschäftigt. Die Daten der Kundenschnittstelle purzeln nach Anforderung über eine Daten-Request Leitung mit einer Geschwindigkeit von 115kbaud heraus. Sie sind allerdings verschlüsselt, und nicht direkt lesbar. Um den 16 Byte langen Entschlüsselung Key zu erhalten, muss der Energieversorger konsultiert werden. Der Schlüssel ist an die Seriennummer des Smartmeters gebunden und für jedes Smartmeter individuell. Nach einigem Telefonieren mit meinen Kärntner Energieversorger wurde mir der Key-Code per Mail zugesandt. Im nächsten Schritt testete ich mit einem USB-UART Adapter an einem PC, ob bei korrekter Beschaltung der Schnittstelle auch wirklich Daten aus dem Zähler herauskommen. Dazu habe ich einen RJ11 Stecker auf ein geeignetes 6pol. Kabel gekrimpt und das offene Ende des Kabels entsprechend des Datenblattes des Zählers beschaltet. Dazu ist nicht besonders viel notwendig. Eine 5V Versorgung muss die Schnittstelle aktivieren, ebenso muss auch die Data Request Leitung an 5V geschaltet werden und schon stehen an der Data Out Leitung die Datenpakete an. Es funktioniert übrigens auch mit einer 3V3 Versorgung. Mit einem Terminalprogramm am PC (ich verwende meist putty oder hterm) kann man die verschlüsselten Daten visualisieren.
Jetzt ging es daran, sich zu überlegen, wie die Daten entschlüsselt und aufbereitet werden. Hierzu findet man mit Netz zwei Ansätze:
* über einen RaspberryPi, mit einer Python-Umgebung und einem Python Skript. Die Skripten übernehmen hier den Empfang und die Entschlüsselung der Daten und stellen sie dann auf unterschiedliche Weise zur weiteren Verarbeitung zur Verfügung
* über einen ESP32. Der ESP ist ebenfalls in der Lage eine 128Bit AES Verschlüsselung zu dekodieren und hat noch reichlich Ressourcen um die Daten aufzubereiten und über WiFi zu versenden. Außerdem ist ein ESP für wenig Geld in ausreichender Stückzahl verfügbar. Also habe ich mich für diese Lösung entschieden. Dazu gibt es auf GitHub ein open source Projekt vom User https://github.com/Andre-Schuiki/esphome_im350 in dem er einen ESP32 IM350 Decoder als Basis für eigene Projekte zur Verfügung stellt. Mit seinen Sourcen erhält man einen Decoder der die Zählerdaten im Sekundentakt ausliest und über die USB UART Programmierschnittstelle und auch via Telnet über WiFi ausgibt. Dieses Sourcen habe ich als Basis verwendet.
Mein Ziel ist es, die aus dem Smartmeter gewonnenen Daten in MQTT Messages zu verpacken und an meinen MQTT Broker zu senden. Ab da ist es dann ein Einfaches, sie in NodeRed und die HomeMatic CCU zu bekommen und dort zu speichern. Also habe ich den Code angepasst. Dazu wurde die Wifi Verbindung zum Router auf eine statische IP gesetzt. (sind in settings.h zu definieren). Die ausgelesenen Messwerte, sowie die RSSI der WiFi Verbindung, werden jetzt über MQTT Topics zur Verfügung gestellt. (die IP-Adresse zum Broker ist auch in settings.h zu definieren). Wenn man den Code jetzt kompiliert und auf den ESP jagt, dann sollte er sich in das jeweilige Netzwerk einbuchen. Solange der ESP noch auf einem PC-hängt, kann man über die Programmierschnittstelle und ein Terminal auch gleich überprüfen was er tut. Verbindet man jetzt den RJ11 Stecker mit der Kundenschnittstelle des Zählers, dann solle im Display des Zählers im Sekundentakt das Dreieck über der Beschriftung "KU" blinken. Passiert das, dann sollten auch schon im Terminal die Messwerte stehen (vorausgesetzt man hat den KEY vom EVU nicht vergessen in secrets.h einzugeben). Klappt auch das, dann stellt ein Blick auf den MQTT-Broker (mit z. Bsp.: MQTT-Explorer) sicher, dass die Messages auch ankommen. Jetzt kann der ESP vom PC entfernt werden.
 |
| Anschlussbelegung |
 |
| ESP32 im "freifliegenden" Testaufbau |
 |
| so kommen die Daten im MQTT Broker an |
 |
| und können zum Beispiel so in NodeRed verarbeitet werden |
wenn jemand an den angepassten Skripten interessiert ist, kann ich die gerne zusenden. Betreffend einer Veröffentlichung auf GitHub muss ich mich erst informieren welche Lizenzbedingungen betreffend des ursprünglichen Repositorys zu erfüllen sind. Es wird dann hier (public) verfügbar sein:
https://github.com/ingmarsretro/esphome_im350/tree/main/standalone_version_mqtt
Keine Kommentare:
Kommentar veröffentlichen