[OBIS V2] - Jetzt auch mit SML-Unterstützung

[stefanru]

Hi,

ich habe nun meinen SmartMeter auch per Lesekopf angeschlossen.
Hätte eine Frage wegen den Hex Werten die nicht übersetzt werden.
Bei mir werden die als DEC angezeigt aber ich finde die Entsprechung in der Anleitung meines Smart Meters nicht.
Ist diese Übersetzung nach DEC sicher korrekt?

Es geht um folgende Werte (power und total_consumption wurden automatisch angepasst) :

Code Auswählen Erweitern


1.0.36.7.0.255       0

1.0.56.7.0.255    139

1.0.76.7.0.255     13

1.0.96.50.1.255   EMH

power              152

total_consumption 1168098.1


Die Doku meines Meters sagt:

Code Auswählen Erweitern

OBIS-T-Kennzahl Bezeichnung Einrichtungszähler+A Einrichtungszähler-A Zweirichtungszähler+A/-A SaldierenderZähler
01 00 60 32 01 01 Hersteller-Kennung X X X X
01 00 60 01 00 FF Geräte-Identifikation X X X X
01 00 01 08 00 FF Zählwerk positive Wirkenergie, tariflos X X
01 00 02 08 00 FF Zählwerk negative Wirkenergie, tariflos X X X
01 00 10 07 00 FF Aktuelle Momentanwirkleistung (nurim ,,Vollständigen Datensatz") X X X X

Wenn ich da was anschaue sehe ich z.B. Hersteller Kennung laut Doku ist:
01 00 60 32 01 01
In FHEM wird das mit 1.0.96.50.1.255 angezeigt. Das passt doch irgendwie nicht?

Hat jemand eine Idee?

Gruß,
Stefan

[KölnSolar]

Hallo Stefan,

Das passt doch irgendwie nicht?

Oder zumindest fast 

Code Auswählen Erweitern

01 00 60 32 01 01 Hersteller-Kennung X X X Xist gleich

Code Auswählen Erweitern

1.0.96.50.1.255   EMHHex in Dec umgerechnet(nur bei der letzten Stelle nicht)
demnach

Code Auswählen Erweitern

1.0.36.7.0.255       0

1.0.56.7.0.255    139

1.0.76.7.0.255     13
=

Code Auswählen Erweitern

01 00 24 07 00 ??
01 00 38 07 00 ??
01 00 4C 07 00 ??
davon passt dann aber nichts auf Deine Beschreibung.

Wenn Du das device mal auf verbose=5 stellt, sieht man auch die Originaldaten u. Interpretation.

Grüße Markus

[stefanru]

Ok, dank dir vielmals.
Verbose 5 gibt leider auch nicht mehr her.
Dort kann ich aber sehen wie die Hex zusammen gebaut wird

Code Auswählen Erweitern


1-0:96.50.1*255(EMH)
1-0:96.1.0*255(
EMH5)
1-0:1.8.0*255(1173335.8*Wh)
1-0:36.7.0*255(0*W)
1-0:56.7.0*255(170*W)
1-0:76.7.0*255(12*W)
1-0:16.7.0*255(182*W)


Was mir auffällt ist das die 2 unbekannten Werte immer ungefähr die power ergeben:
Hier 170W + 12W = 182W.
Was könnten das für Bestandteile sein?

Dann gibt es noch einen 3ten Watt Wert der immer 0W ist.

Vielleicht hat noch jemand ne Idee?

Gruß,
Stefan

[KölnSolar]

Hi Stefan,
so dargestellt erkennt es ein Blinder mit nem Krückstock.  Es sind die Leistungswerte(richtiger: Arbeitswerte) der einzelnen Phasen.
0+170+12=182
Grüße Markus

[stefanru]

Ah jetzt ja!
Das ist mir einfach nicht aufgefallen, aber klar, 3 Werte

Dank dir!

Gruß,
Stefan

[gvzdus]

Guten Abend! Ich habe gestern alle 66 Seiten des Threads durchgelesen, und zunächst einmal herzlichen Dank an Icinger und alle Unermüdlichen, die hier im Thread helfen.

Ich möchte das Thema "Stromzähler-Auslesen" etwas pushen, und habe zunächst einmal eine Wiki-Seite zum "Stromzähler auslesen" verfasst. Ich würde mich über Korrekturen, Anmerkungen oder Erweiterungsvorschläge freuen und arbeite sie gerne ein:
https://wiki.fhem.de/wiki/Stromz%C3%A4hler_auslesen
Vermutlich langweilt Euch die Seite fachlich - aber es geht eher darum, Einsteigern eine Orientierung zu bieten.

Als nächsten Schritt würde ich gerne eine Wiki-Seite zum OBIS-Modul schreiben - wobei: Bei mir schnurrt alles, seit ich im November 2018 den EMH ED300L bekam, und schnurrt mit dem 2-Richtungszähler von ISKRA genauso. Das war "Kopf wiederanklemmen, staunen, dass ich jetzt auch die Einzelwerte für die Phasen sehe".
Ich arbeite im Push-Mode ohne "Downscaling durch Poll-Intervall".

Ich kann mich gerne auch um Probleme im Code kümmern, denn Icinger fragt ja durchaus nach Patches.

[KölnSolar]

Schön, dass Du Dich des Themas annimmst u. Stefan etwas unterstützt.

Gefühlt ist es bei Stefan ähnlich wie bei mir: Hauptsache funktioniert.  Wenn ich es richtig in Erinnerung habe, sind in der commandref noch die ein oder andere Lücke. Und dann haben wir noch die Ansteuerung der Zähler, die immer wieder mal angesprochen wird u. Stefan die ein oder andere Zwischenversion eingestellt oder gar außerhalb des Forums "verteilt" hat. Das sollte im Wiki zum OBIS-Modul auf jeden Fall stehen, da nur Einzelne es mal benötigen, es aber meines Wissens aus dem Teststadium noch nicht herausgekommen ist.

Zähler-Wiki sieht gut aus. Die Zukunft besser erklärt als es die meisten EVUs/VNBs/Msbs hinbekommen.

Grüße Markus

[gvzdus]

So, vorab: Tiefen Respekt vor Stefans Level of Perl! Da kann ich noch viel lernen... Ich schreibe nämlich angeblich - ob JS, Perl oder Java - in jeder Sprache immer nur C.

Trotzdem habe ich mich mal "ans Herz" getraut: An ein paar Stellen sind m.E. Redundanzen drin, bzw. - wenn man wie ich "reverse draufsieht" - Stellen wo man denkt: "Hey, dieser Zustand kann doch hier gar nicht vorkommen - weil: hast Du oben abgefangen".

Wer Lust hat, sein System kaputt zu machen, kann ja mal meine angehängte Version probieren.

Änderungen:
Da ja manchen Nutzern das Ganze auf einem Raspi 2 zu lahm war, habe ich an der Performance geschraubt: Bei mir auf dem Raspi 3B+ lagen die Zeiten für das Parsen einer Nachricht (vom MT175 von ISKRA) im Mittel bei 8,5 ms, jetzt sind es 5,5 ms. Dass anschließend bei mir 75 ms für die Notify-Verarbeitung draufgehen, weil viel dahinter hängt, ist eine andere Sache...

Außerdem wurden bei mir die Readings "PublicKey" und "ManufID" nur als "Zahlenreadings" angezeigt, obwohl die Regeln eigentlich im Code stecken (nur nicht greifen). Das habe ich gefixt.

Als Nächstes gehe ich wieder das Doku-Thema an.

@Stefan: Ich würde mich melden, wenn ich meine: "Das taugt jetzt..." Falls Du aber neugierig bei einem "diff" bist, warum ich irgendwas umgestellt habe: Gerne per Skype-Session drüber diskutieren... Im Kern habe ich einen Cache für Deine OBIS_code-Tabelle eingebaut, an ein paar Stellen m.E. optimiert (z.B. beim inkrementellen Buffer-Befüllen kein Hex hin / zurückkonvertieren) und RegExp-Auswertungen reduziert.

[Fakenius]

Sorry, wenn meine nachfolgende Frage Off Topic sein sollte, aber hier sind ja viele SML Experten zugange...

Ich habe jetzt auch eine sog. "Intelligente Messeinrichtung" bekommen, die spontan SML über IR sendet. Allerdings ist der Zähler sehr weit weg von meinem FHEM-Server. Serielle Kabel und WLAN scheiden damit aus, LAN wäre aber möglich.

Kennt jemand hier einen "Lesekopf", der sich unmittelbar an's Ethernet anschließen lässt und könnte OBIS damit etwas anfangen? Wenn ich das richtig verstehe, erwartet OBIS die SML-Daten bit/byteweise (UART, USB) und dekodiert diese dann!?

Im "Netz" wird dagegen ein Eigenbau angeboten, der den SML-Stream bereits "parsed" und dann per MQTT publiziert. Könnte dieser "fertige" SML-String dann an OBIS übergeben werden?

Alternativ könnte ich mir nur noch eine extra FHEM-Instanz z.B. auf einem Raspberry vorstellen, right?

Danke und ich bitte um Nachsicht, wenn das hier schon beantwortet worden sein sollte ...

[KölnSolar]

Im "Netz" wird dagegen ein Eigenbau angeboten, der den SML-Stream bereits "parsed" und dann per MQTT publiziert.

Wenn es in MQTT vorliegt macht es vermutlich keinen Sinn, das dann wieder in OBIS zu konvertieren nur um das Modul zu nutzen.

Kennt jemand hier einen "Lesekopf", der sich unmittelbar an's Ethernet anschließen lässt und könnte OBIS damit etwas anfangen?

Kennen tu ich es nicht, aber nichts anderes machen ja die ESP-Varianten. Man gibt einfach die IP anstatt dem serial_device an(glaub ich;den Rest macht FHEM intern) Auch gibt es diese serial2net Geschichten. Kenne ich mich aber nicht mit aus.

Serielle Kabel und WLAN scheiden damit aus, LAN wäre aber möglich.

Wieso geht LAN aber nicht seriell ? Draht ist ja dann scheinbar vorhanden.

Grüße Markus

[gvzdus]

Egal, ob schon beantwortet oder nicht:
Ich habe ziemlich viel die letzten Tage recherchiert, was es gibt. Und ganz einfache Lösungen mit Ethernet sind mir nicht über den Weg gelaufen. Die ESP8266 / ESP32-Welt hat halt Wifi von Haus aus, aber kein Ethernet.

Kann sein, dass noch jemand eine andere Idee hat, aber ich würde einen zweiten Raspi als einfachste Option sehen, entweder gleichartig zu Deinem FHEM-Server als Hardware-Backup, oder möglichst klein und stromsparend (Raspberry B+? Für 30 Euro?). Einfach, weil Du dann Dir das Reinlernen in andere Umgebungen ersparst.

Markus hat ja schon hinterfragt, warum nicht den LAN-Draht für Seriell missbrauchen. Ich bin nicht so der Typ, bei dem "Ich probiere mal, USB über Ethernet-Draht zu führen, indem ich das dranlöte" i.d.R. zum Glück geführt hat. Mit dem "Keller-Raspi" kannst Du dann ggf. noch andere Dinge machen (z.B. den Raspi als Hungerleider-Hotspot im Keller betreiben, um dort Shellys wachsen zu lassen).

OBIS hat keinen Wert über die SML-Dekodierung hinaus. Wichtig ist ja nur, die Daten in FHEM reinzubekommen. Da würde ich dann vom Keller-Raspi zum FHEM-Mainframe über MQTT gehen.

[Fakenius]

Erst einmal vielen Dank für die schnellen Antworten. Super Forum hier 

Wieso geht LAN aber nicht seriell ?

In Zählernähe liegt ein LAN-Kabel, das auch als solches benutzt wird. Ein weiteres (serielles) Kabel wäre extrem unschön. Vielleicht bei der nächsten Renovierung. Aber das ist auch eine WAF-Frage 

Bin ja irgendwie froh, dass ich nicht so ganz falsch lag mit meiner Einschätzung. Inzwischen habe ich per Google einen Arduino-Sketch gefunden, der SML aus dem Stream "selektiert". Müsste, sofern der läuft, nur noch per MQTT verschickt werden. Vielleicht kann man das auch noch komplett parsen, also bis auf Readingsniveau, sozusagen. Einen Arduino Uno habe ich noch. Werde also mal ein Ethernet Shield in China ordern. Habe da auch noch ein paar Rest-Skills, die ich wieder auffrischen könnte. Man darf ja sowieso gerade nicht raus 

Schönen Abend noch.

[AxelSchweiss]

RS485 ist keine Lösung ?

[Fakenius]

RS485 ist keine Lösung ?

Das ist doch auch kabelbasiert, soviel ich weiß !?

Ich habe mal weiter recherchiert: einen passenden Sketch, der den SML-Stream "zusammensetzt" habe ich ja gefunden. Den untersuche ich mal auf Eignung  Beim Chinesen gibt es Arduinos und Ethernet Shields für jeweils so um die 5-7 Euronen, ohne dass ich das jetzt optimiert hätte. Hätte gegenüber dem 2nd-Raspberry-Ansatz später den Out-of-the-Box-Vorteil, weil man vermutlich nicht viel konfigurieren muss (wegen DHCP wohl nur den MQTT-Broker einstellen), so meine Vorstellung ...

Also, ich mache mich mal dran "über die Tage" mit dem, was ich noch hier habe. Der Störfaktor seitens der Verwandtschaft ist ja dieses Jahr stark limitiert 

Wenn es dann interessiert, kann ich ja mit meinen potentiellen Resultaten einen extra Thread aufmachen.

Bis dahin (siehe Motto unten) ...

[gvzdus]

Wenn es dann interessiert, kann ich ja mit meinen potentiellen Resultaten einen extra Thread aufmachen.

Mich interessiert es auf jeden Fall, ich würde die Stromzähler-Seite https://wiki.fhem.de/wiki/Stromzähler_auslesen dann um eine Ethernet-Lösung aktualisieren.