stromzähler via IR auslesen Wiener Netze AM550

[erwin]

Hi all,
die neuen Stromzähler in Österr. senden geben ihre daten verschlüsselt über eine "Kundenschnittstelle"  aus. Jeder Netzbetreiber verwendet andere Zähler daher gilt das nur für diesen Zähler und Wr. Netze!
Mir ist es nun gelungen, ein python-script (aus dem web) auf perl zu portieren, und zwar für den ISK AM550, betrieben von Wiener Netze
Ein paar zusätzliche recherchen waren noch nötig, die Quellen sind im attachten script enthalten.

Im Idealfall könnte man das ins das vorhandene OBIS Modul integrieren...
Aber es stellen sich ein paar Fragen:
1) Der Zähler sendet (unaufgefordert) 1* pro Sekunde ein Packet mit 105 Bytes mit 9600bps. Da bleibt nicht viel Zeit für Pause....
    völlig unsinnig, das  jede Sekunde auszuwerten... Ausserdem befürchte ich das das zu viele resourcen von FHEM frisst.     
2) Meine Idee wäre, das ganze in einem externen task zu aggregieren und dann z.b. jede Minute an FHEM-OBIS Modul zu übergeben. Alternativ denke ich auch an MQTT
    Stellt sich sofort die Frage, auf welcher Plattform dieser task laufen soll: RPI/Linux, ESP82xx, Arduino,...? ESP/Arduino hätte natürlich den Charme, dass der Raspberry/FHEM nicht im Zählerkasten sein muss!

Nachden ich wenig bis keine Ahnung von Arduino und ESP und schon gar nicht von Verschlüsselung habe - geht die Frage an die Experten 

Das script (=proof of concept) funktioniert mit dem enthaltenen sample daten/key, aber auch mit meinen vom Zähler gesendeten Daten/meinem Key.
l.g.erwin

[KölnSolar]

Hi Erwin,

Im Idealfall könnte man das ins das vorhandene OBIS Modul integrieren...

Wird denn OBIS gesendet ?

Der Zähler sendet (unaufgefordert) 1* pro Sekunde ein Packet mit 105 Bytes mit 9600bps

Das macht ein Teil der OBIS-Zähler auch(oder ähnlich).
Grüße Markus

[erwin]

Hi Markus,

Wird denn OBIS gesendet ?

nein, es werden 4byte Werte gesendet, das Format ist im script beschrieben, der +kWH Wert stimmt mit meinem Zähler überein, ob die anderen Werte korrekt sind,
weiß ich noch nicht.... (die sind aus dem python example...)
Aber: sobald das gesichert ist, könnte man diese Werte relativ einfach in ein "OBIS Format" übersetzen...
l.g. erwin

[KölnSolar]

Aber dann ist das doch von hinten durch die Brust ins Knie. 
Dann lieber ein eigenes Modul auf Basis des OBIS-Moduls. Wenn es passend strukturiert ist, kann man ne Menge übernehmen, aber auch vieles ersparen.
Grüße Markus

[erwin]

Aber dann ist das doch von hinten durch die Brust ins Knie.

..ist relativ, falls das emfangen, ENTSCHLÜSSELN (AES CTR-mode)  und parsen auf einer anderen Platform / task stattfindet, ist das konvertieren in OBIS conformes Format die leichteste Übung.... 
Ich bin davon ausgegangen, das das entschlüsseln viel Zeit/Perfomance in Anspruch nimmt, allerdings (mit meinen unproff. messmethoden) komme ich auf ca. 0.2 ms für die 105 bytes...
Erwin

[gvzdus]

Definitiv macht es Sinn, das live zu decoden, also sich über die sekündlichen Werte zu freuen.
Bei mir hängt am OBIS-Modul Diverses an Steuerung, u.a. die OpenWB mit der PV-Überschuss-Ladesteuerung. Das ist einfach sehr schön, wenn man quasi die Stromrichtung und aktuelle Leistung ohne Eingriff ins Stromnetz "geschenkt" bekommt.

Das Entschlüsseln sollte dabei nicht das Problem sein. In der Praxis fällt eher ins Gewicht, dass bei 9600 Baud FHEM quasi jede Millisekunde Daten bekommt und dann die Verarbeitung im Modul anstößt, wobei das Modul dann feststellt: "Nein, noch kein ganzer Datensatz". Aber da bei Euch die Daten komprimierter als im OBIS-Format in Deutschland abgelegt werden, ist das eher sparsamer.

Ich habe das 47_OBIS-Modul von icinger (übrigens ein Österreicher) als Maintainer "geerbt". Wie schon geschrieben: Es *muss* nicht ins Modul, weil es eben ein anderes Format und nicht OBIS. Schön wäre allerdings, wenn ein AT-Modul den gleichen Output an Werten erzeugt, also auch auf die Namen "power" (in Watt, positiv = Netzbezug), "total_consumption" (in Wh) und "total_feed" (in Wh) setzt. Ich fürchte, eine "trocken-Integration" wird viele Zyklen erfordern.

Variante 1: Du planst eine Integration in 47_OBIS. Ich kann Dich dabei unterstützen, was wie gedacht ist, bzw. Attribute wie "AES-Key" einbauen, z.B. per Telefon oder Skype-Session. Außerdem das Testing übernehmen, dass Du 47_OBIS nicht "kaputt gemacht" hast.

Variante 2: Wenn Du ein eigenes Modul machen möchtest, kann ich ebenso einfach mal die Struktur von 47_OBIS erläutern.

Insgesamt bin ich etwas neidisch auf "Euch Ösis". Bei uns Piefkes kaspern wir mit den SmGWs erfolglos rum, haben gigantische Kosten und die "Kundeninformationsschnittstelle" - also das, was wir im Moment mit der modernen Messeinrichtung und OBIS haben - ist nicht vorgeschrieben, vielmehr ein ominöser Mehrwertdienst namens TAF14. Dies nur als Warnung für diejenigen, die glauben, sie würden mit einem richtigen SmGW in Deutschland *mehr* können. Nein, je nach Hersteller geht dann die OBIS-Info verloren.

Kontaktiere mich ggf. einfach per Privatnachricht!

[erwin]

Hi gvzdus,
danke fürs Feedback & Angebot,
ganz so rosig schauts in Ö leider auch nicht aus, jeder Netzbetreiber verwendet Zähler von unterschiedlichen Herstellern, hat unterschiedliche "Kundenschnittstellen" (IR, Modbus,...) und soweit ich das sehe, auch unterschiedliche Protokolle auf den Schnittstellen.... Das was es gibt, ist eine Verordnung: das die Kundenstelle jederzeit für den Kunden zugänglich sein muss, und die daten encryptet sein müssen... Was jeder Betreiber anders interpretiert.
Das entschlüsseln hab ich mal "geknackt" (mit perl),  mom. bastle ich an der IR->Wlan mit ESP8266, weil ich kein LAN-Kabel(oder anderes)  zum Zählerkasten habe...
evtl. kann ich das packet als "ganzes" via TCP schicken - im 8266- das seriell frame verarbeiten, crc check machen, usw..., im Idealfall auch decrypten und in obis strings schicken!
wird noch dauern...
Wennn ich's richtig gelesen hab ist das Protokoll DLSM ... und zwar die HDLC-Variante - leider sind die IEC Docs unter NDA!
l.g. erwin

[Gisbert]

Aber dann ist das doch von hinten durch die Brust ins Knie.  ...
Grüße Markus

*offtopic
Heißt es nicht ins Auge statt ins Knie? 
*offtopic Ende

Viele​ Grüße​ Gisbert​

[KölnSolar]

Et kütt wie et kütt. 

[erwin]

Hi Stromzähler -Betroffene,

kurzes update zu meinen Fortschritten:
Auf Basis ESP8266 (Wemos-d1-mini Pro) hab ich jetzt folgendes realisiert:
1) Auslesen der daten aus der "Kundenschnittstelle" (IP-head, seriell 9600 8N1) - jede Sekunde 1 record...
2) entschlüsseln auf dem ESP - key vom Netzbetreiber
3) Aufbereiten der entschlüsselten Daten nach Werten...
4a) Senden als JSON an einen TCP-Client. - WEMOS ist Server
4b) senden als JSON an MQTT-Server
      Mit MQTT ist's dann einfach, brauche kein extra FHEM-Modul zu schreiben...
4c) Debug - senden via Serial1 vom WEMOS
5)  MQTT2_DEVICE in FHEM, das die daten aufnimmt

Das ganze dzt. noch im alpha status, kann ich so noch nicht veröffentlichen...
Das schwierigste war das umlöten auf externe Antenne bei dem WEMOS! (winziger 0 Ohm Widerstand)
Was noch fehlt: Wifi-Manager, um WLAN u. MQTT parameter ohne compilieren/flashen ändern zu können, und parameter im "Betrieb" via MQTT / TCP zu ändern...,
                          OTA-update, event-reduktion in FHEM od. im ESP?, DbLog u. Grafana-Auswertung
l.g. erwin