[Frage] [V4.5 IP5] Optische Datenauslesung von eHZ (elektronischem Haushaltszähler)

[Kaaennixx]

Ich hatte auch überlegt die als Tipp zu nennen, aber wenn der Anspruch ist hochaufgelöste Messwerte zu erfassen ist das eine unnötige Datenmenge auf dem KNX-Bus.

Das stimmt natürlich, hatte ich gar nicht beachtet. Ich frage damit nur ein paar mal pro Tag den Zählerstand ab. Für hochauflösende Messwerte nutze ich mehrere Modbus Zähler.

[Franky]

Ich hatte auch überlegt die als Tipp zu nennen, aber wenn der Anspruch ist hochaufgelöste Messwerte zu erfassen ist das eine unnötige Datenmenge auf dem KNX-Bus.

Das stimmt natürlich, hatte ich gar nicht beachtet. Ich frage damit nur ein paar mal pro Tag den Zählerstand ab. Für hochauflösende Messwerte nutze ich mehrere Modbus Zähler.

OK, ich würde das zur Regelung des Eigenverbrauchs / Batterieladung verwenden (so der Plan, die Komponenten gibt es aber noch nicht), erstmal zur Überschussladung Wallbox und da will man natürlich eher "schnell regeln" und dann würde das den (KNX).Bus unnötig zumüllen. Ich denke für diee Regelung ist es vielleicht sinvoll, die Rohdaten nicht auf KNX zu senden ...

Franky

[gbglace]

Ja für die Livemessung für die Versorgung des EMS bitte nicht via KNX die Daten verteilen.

Ich habe mir dafür den neuen Victron Zähler besorgt. Der spricht direkt mit dem Steuergerät via deren CAN-Bus. Parallel dazu kann man sich selbst die Werte per Modbus TCP anziehen oder per MQTT.

Die optische Schnittstelle vom EVU Zähler hat halt den Tibberdongel dran, damit ich dort die dynamischen Strompreise bekomme.

Die Senderate ist da sehr hoch, denn wenn da mal jemand den Wasserkocher einschaltet muss der BatterieWR sehr schnell drauf reagieren, um da nicht doch noch in den Netzbezug zu gehen.

Insofern finde ich es an der Stelle nicht so verkehrt die Hersteller Smartmeter zu verbauen, wichtig ist eben nur das die Ihre Werte auch separat noch frei rausgeben, was bei dem Victron über drei Kanäle möglich ist und man damit selbst frei an seine Daten kommt.

[Marino]

Du meinst sicher den Victron VM-3P75CT oder?
Interessantes Gerät. Die Möglichkeit über CAN nativ verbinden zu können und trotzdem unabhängig per Modbus TCP an die Daten zu kommen finde ich toll.
Wenn man dann noch mit einem nativen KNX-Gerät den Preis vergleicht

Da mein Tibber-Pulse gerade unbemerkt 6 Wochen nicht mehr funktionierte (Ich musste proaktiv eine Battariewarnung aktivieren) und NodeRed die Live-Daten nicht mehr liest (hängt auf einmal bei connecting...), habe ich das umgebaut um NodeRed aus der Gleichung zu streichen. Das lief nur für die Tibber-Live-daten. Ich werde damit einfach nicht warm.

Daher ist das Thema gerade wieder aktuell.

[gbglace]

Ja genau den neuen blauen Victron-Zähler.
Die leere Batterie im Pulse hatte ich auch schon, hatte mich da in der App gewundert warum ich da für drei Tage nur graue Balken hatte mit dem Kommentar berechnet.

Im produktiven Kontext habe ich die Tibber-API auch nur für das Auslesen der Preise in Verwendung. Da werde ich dann aber Mitte Juni auch nochmal in meinem NR aktiv werden müssen, da dann die Preise 1/4h kommen und nicht mehr in 1h Blöcken.

Für die Livedaten usw. war mir das von vornherein zu instabil, das einmal quer durchs Internet gezogen an die WR Steuerung zu geben. Das wollte ich da direkter zum abgreifen haben, da kam mir der neue Victronzähler gerade recht. Die Vorgängermodelle hatten ja auch immer mal so Ihre Sorgen entweder in der Auflösung der Messwerte oder in der Konnektivität.

Und preislich ist der Zähler echt sehr interessant. Als er ganz frisch war (da hatte ich ihn gekauft) lag der bei noch knappen 300€ mittlerweile ja fast nur noch die hälfte und da ist er echt interessant.

[Franky]

Erste (Zwischen) Erfolgsmeldung. Ich habe mir beide Leseköpfe (den Hager BKE-Datenschnittstelle EHZ001K für die unsichtbare Verkabelung hinter dem Zähler und einen Hichi TTL/UART Magnetkopf für vorne) besorgt. Ich will ja eine Verkabelung und LAN-Übertragung anstelle Wifi.

Mit einem Olimex ESP32 und einem https://www.olimex.com/Products/Modules/Interface/MOD-RS485/resources/MOD-RS485.pdf, aktuell noch den hier im Einsatz: RS485TTL bekomme ich Daten EHZ001K (RS485, A/B-Adern).

Die Daten muss ich jetzt noch konvertieren und über Modbus TCP senden. Was ich schon mal festhalten kann ist, dass die Aussage der Doku "Übertragungsrate elektrisch und optisch 921,6 kBit/s" falsch ist. Auf 9600 Baud eingestellt funktioniert die Datenübertragung. Sonst nicht. Die hohe Datenrate war der Grund, dass ich mir den "nicht-Olimex" RS486 Konverter geholt habe, da der die Datenrate hinbekommen hätte im Gegensatz zum Olimex RS485-Wandler. Den probiere ich als nächste aus, da er mit dem beiligenden "BUS-Kabel" einfach ans ESP32 Board gekoppelt werden kann. Bei 9600 Baud, hat kein RS485 Wandler Geschwindigkeitsprobleme.

Franky

EDIT

Das olimex mod485 läuft noch nicht. Mit KI-Unterstützung sieht der Prompt für ein Fortsetzen des debuggings so aus:

Code: Alles auswählen

Ziel: Rohdaten vom Hager EHZ001K (SML-Protokoll) über RS485 lesen.
Hardware:
Hager EHZ001K: Optischer Kommunikationskopf, gibt Daten via RS485 aus (LMN-Schnittstelle). Benötigt separate 12V-Versorgung.
Olimex MOD-RS485 development board:
Verwendet ADM3483ARZ Transceiver.
Max. Baudrate ist 250 kBit/s (aber wir zielen auf 9600 Baud ab, was passt).
Keine LEDs auf dem Board zur Funktionsanzeige (schwierig für Diagnose).
DE/RE-Steuerung: Benötigt einen GPIO vom ESP32 (wir verwenden GPIO14, verbunden mit UEXT Pin 9 des MOD-RS485) auf LOW (Empfangsmodus).
Verdrahtung zu ESP32 (über UEXT-Kabel): VCC (+3.3V), GND, UEXT Pin 3 (ESP32-TX/GPIO4), UEXT Pin 4 (ESP32-RX/GPIO36), UEXT Pin 9 (ESP32-GPIO14 für DE/RE).
Verdrahtung zu Hager: MOD-RS485 A an Hager B (Pin 6), MOD-RS485 B an Hager A (Pin 1), MOD-RS485 GND an Hager GND (Pin 3). (A/B-Kreuzung ist wahrscheinlich notwendig, da es beim DollaTek so war!)
Olimex ESP32-POE-ISO IoT Entwicklungsboard:
WROOM-Variante (entscheidend für GPIO-Verfügbarkeit).
Verwendet MicroPython.
GPIOs für UART2: RX=GPIO36, TX=GPIO4.
GPIO für DE/RE: GPIO14.
Stromversorgung: Per Micro-USB-Kabel (für Entwicklung/Tests) oder PoE.
Aktueller Stand (Fehlersuche Olimex MOD-RS485):
Der Loopback-Test mit dem Olimex MOD-RS485 ist fehlgeschlagen (ESP32 sendet, aber empfängt nichts vom Modul zurück).
Das ist das aktuelle Hauptproblem. Bevor wir uns mit dem Hager verbinden, MUSS der Loopback-Test funktionieren.
Software (MicroPython Skript):
Der ESP32 läuft mit einer MicroPython-Firmware.
Wir verwenden ein main.py-Skript, das den RS485-UART konfiguriert und Daten ausgibt.
Das Skript ist für 9600 Baud und die "freundlicheren" GPIOs (GPIO36/GPIO4) eingerichtet.
Es steuert GPIO14 auf LOW für den DE/RE-Pin des MOD-RS485, um den Empfangsmodus zu aktivieren.
Das Skript gibt Debug-Meldungen und die empfangenen Rohdaten als Hex-String aus.
Nächster Schritt für die neue Session:
Wir müssen den Loopback-Fehler des Olimex MOD-RS485 Moduls beheben. Dies ist der kritischste Punkt.
Wir werden uns auf folgende Prüfungen konzentrieren:
Stromversorgung des MOD-RS485: Direkte Messung der 3.3V am Modul (UEXT Pin 1 & 2).
UEXT-Kabel: Korrekter Sitz und Ausrichtung (Pin 1 Markierung).
A/B-Kurzschluss: Sicherstellen, dass A und B am MOD-RS485 für den Loopback-Test korrekt und fest verbunden sind.
DE/RE-Steuerung (GPIO14):
Ist GPIO14 korrekt mit UEXT Pin 9 des MOD-RS485 verbunden?
Wird GPIO14 im MicroPython-Skript wirklich auf LOW gesetzt? (Überprüfung des Codes).

EDIT2: Das MOD-RS485 habe ich nicht zum Laufen gebracht. Dafür läuft das DollaTek gut. Jetzt geht es an die Softwareseite

[Franky]

ok, ich bin ja ein linux guy, dazu esp32 und Auslesen über die hintere ehz-Schnittstelle vom Zähler. Ich glaube, ich dokumentiere das hier nur für mich aber was solls, das muss ja auch getan werden und vielleicht hilft die ein oder andere Information. Das ganze Projekt ist nur durch LLM-Unterstützung möglich geworden. Die LLM hat mich aber auch das ein und andere mal in die falsche Richtung geschickt.

initialer Prompt für die entwicklung von main.py (dem automatisch gestarteten Programm, das alles regelt:

Code: Alles auswählen

Ausgangslage:
Es wurde erfolgreich eine Kommunikationsbrücke vom Hager EHZ001K Stromzähler zum Olimex ESP32-POE-ISO etabliert.

Der Zähler gibt unaufgefordert Daten im SML-Protokoll über seine optische Schnittstelle (LMN) mit 9600 Baud aus, die via RS485 (mittels eines funktionierenden DollaTek-Adapters) auf den ESP32 gelangen.

Die ESP32-Seite läuft derzeit mit MicroPython und gibt die Rohdaten über USB aus.

Nächstes Vorhaben (Ziele für die neue Chat-Instanz):
Das Ziel ist es nun, die vom Hager Zähler empfangenen SML-Daten nicht nur über USB auszugeben, sondern sie über das Netzwerk verfügbar zu machen. Konkret soll:
- Modbus TCP zum Senden der Daten genutzt werden.
- Die Lösung über das Netzwerk (OTA) updatebar sein, ohne dass eine USB-Verbindung erforderlich ist.
- Die gesamte Implementierung stabil und leicht wartbar sein.
- Die Option, Tasmota als Firmware auf dem ESP32 einzusetzen, soll evaluiert werden.
- Die Sprache für den Code ist flexibel.

Ich hab mich für den Weg MicroPython (auf dem esp32) entschieden und dazu, den esp manuell über USB zu konfigurieren. das kann ich dann einfacher scripten und der ESP selbst braucht für die Installation keinen NetzwerkzugriffNotiz an mich: NIEMALS den Esp32 über die externe Stromversorgung und USB gleichzeitig befeuern, immer nur eine Spannungsquelle!! sonst "hat Puff gemacht"
Ich habe mich also dagegen entschieden:

• den ESP mit Befehlen auf dem ESP "upzudaten"

• eine neue Firmware zu kompilieren, die alles enthält.

Anweisung an die LLM hierfür: (ich hätte ihr noch den Grund angeben sollen, damit sie die Motivation später mit berücksichtigen kann).

Code: Alles auswählen

ok ich geh den offline weg. ich würde den esp32 jetzt gerne über usb so vorbereiten, dass ich ihn danach ans netzwerk hängen kann und alles weitere per ethernet anstelle usb machen kann. Die Ersteinrichtung will ich über USB machen, also kein direkter Zugriff des ESP während der Erstinstallation ans Internet.

Terminalzugriff auf den esp32:

Code: Alles auswählen

apt install picocom
picocom /dev/ttyUSB0 -b 115200
Exit with Ctrl+A, Ctrl+X.

Die Firmware (Micropython) für diesen esp32:

Code: Alles auswählen

https://micropython.org/download/ESP32_GENERIC/
https://micropython.org/resources/firmware/ESP32_GENERIC-20250415-v1.25.0.bin

flashen (immer erst löschen)
esptool.py --chip esp32 --port /dev/ttyUSB0 erase_flash
esptool.py --chip esp32 --port /dev/ttyUSB0 --baud 460800 write_flash -z 0x1000 ESP32_GENERIC-20250415-v1.25.0.bin

Für die Integration von Modbus

Code: Alles auswählen

git clone https://github.com/brainelectronics/micropython-modbus.git
cd micropython-modbus

"The umodbus library is in the micropython_modbus directory."
Transfer umodbus to ESP32 via USB

Code: Alles auswählen

pip3 install rshell
rshell -p /dev/ttyUSB0

Code: Alles auswählen

mkdir /pyboard/lib
mkdir /pyboard/lib/umodbus
cp -r micropython-modbus/umodbus/* /pyboard/lib/umodbus

Verify:

Code: Alles auswählen

ls /pyboard/lib/umodbus

You should see __init__.py, tcp.py, etc.
Exit rshell:

Code: Alles auswählen

exit

Test umodbus in REPL:
Reconnect to REPL with picocom /dev/ttyUSB0 -b 115200.
Run:

Code: Alles auswählen

picocom /dev/ttyUSB0 -b 115200

vorher:
[code]  File "<stdin>", line 1, in <module>
NameError: name 'umodbus' isn't defined

nach Eingabe von

Code: Alles auswählen

import umodbus

nachher:

Code: Alles auswählen

>>> print(umodbus)
<module 'umodbus' from '/lib/umodbus/__init__.py'>

funzt.
2be continued

[cybersmart]

Danke für den Link. Ich denke es geht nicht, da aus dem Lesekopf kein Modbus raus kommt. Ich bau mir jetzt einen Konverter auf ESP32 Basis. Wenn ich fertig bin, werde ich dazu wohl was online stellen...

Falls noch wer Zählerdaten vom eHZ direkt ausliest und mit dem TWS verarbeitet, bitte Info

Ich verwende auch Lesekopf mit esp32 und MQTT um die Daten in den TWS zu bringen.

[Franky]

Ich verwende auch Lesekopf mit esp32 und MQTT um die Daten in den TWS zu bringen.

@cybersmart cool, wie machst du die Konvertierung zu MQQT (z.B. Tasmota?) Ich gehe ja momentan den Weg über Micropython und versuche alles "selbst" zu machen. Auf Modbus bin ich jetzt nur gegangen, da ich noch keinen MQQT-Server laufen habe. Habe das aber noch nicht lauffähig, bin ich noch dran und werde berichten.

Gruß

Franky

[Franky]

So, hatte nicht viel Zeit, daran weiter zu arbeiten. Aber gestern ist meine Anlage verplombt worden und ich musste die Ausleitung der hinteren Zählerschnittstelle leider rausreißen. Bei einem anderen Monteur wäre es vielleicht durchgegangen, @blaubaerli, du hattest also vollkommen Recht mit deiner Einschätzung. Ich hatte es sogar schon am Laufen (also das Auslesen über die hintere Schnittstelle). Aber nicht schlimm, so habe ich viel gelernt und der Umstieg auf die vordere Schnittstelle (jetzt halt mit Kabelsalat und abfallenden Leseköpfen) wird auch nicht so schlimm sein.