Hallo an die Fachleute beim Zähler auslesen.
Ich komme mit meinem Vorhaben einfach nicht weiter. Vielleicht kann mir
hier jemand auf die Sprünge helfen.
Ich möchte meinen Zähler vom Typ ISKRA eHZ-MT681-D4A51-K0p auslesen. Mit
dem Handy habe ich geprüft ob die Diode sendet. Das tut sie, auch ohne
PIN Eingabe. Ich kann auch keinen PIN eingeben! Trotz gegenteiliger
Anleitungen zu dem Zähler MT681. Westnetz hat mir auch telefonisch, nach
Abfrage der Zählernummer, bestätigt das es für meinen Zähler (alt, einer
der ersten) keinen Pin gibt. Hier werde ich auch nicht schlauer:
(https://www.westnetz.de/de/faq/moderne-messeinrichtungen.html)
Mit dem Lesekopf ALLNET Optischer D0-Lesekopf (ALL3688) empfange ich bei
der Einstellung 9600,8,1 auch Daten.
Doch diese entsprechen nicht dem erwarteten SML Aufbau.
Ich empfange in Hex 727272727F7F7F7F anstatt die 1B1B1B1B01010101
Siehe Screenshot anbei (HTERM)
Beim googeln habe ich jemandem mit demselben Problem gefunden, leider
wird dort keine Lösung beschrieben.
Andere Baudraten und Stopbits, Parität, etc. hat alles nichts gebracht.
Auch ein rotieren des Bytes nach links mit anschließendem Invertieren
bringt nichts. Dann komme ich zwar zu 1B bzw. 01 ABER es passt beim Rest
auch nicht, denn anstatt der &h76 für eine SML-Message kommt dann &hBA
:-(
Aber der Zähler spuckt ca. alle 1sec die 212 Bytes raus. Wie müssen
diese interpretiert werden?
Matthias 🟠. schrieb:> Ich empfange in Hex 727272727F7F7F7F anstatt die 1B1B1B1B01010101
Na ja, wenn man 727272727F7F7F7F invertiert und zusätlich die
Bitrichtung jedes Bytes umdreht, dann wird daraus immerhin
B1B1B1B101010101. Wäre aber eine seltsame Bitmanipulation, und das
Ergebnis wäre immer noch nicht wie erwartet.
Wenn du die Möglichkeit hast würde ich das Austangssignal am
Fototransistor mal per Oszi anschauen (die ersten paar Byte) und von
Hand dekodieren. Vielleicht kommt man dann darauf, was schief läuft.
Matthias 🟠. schrieb:> Auch ein rotieren des Bytes nach links mit anschließendem Invertieren> bringt nichts. Dann komme ich zwar zu 1B bzw. 01 ABER es passt beim Rest> auch nicht, denn anstatt der &h76 für eine SML-Message kommt dann &hBA> :-(
Mit dem Oszi kann ich das Signal mal messen ... ich bin im Keller.
Matthias 🟠. schrieb:> Andere Baudraten und Stopbits, Parität, etc. hat alles nichts gebracht.
trotzdem zeigen, welche hast du denn probiert?
edit: scheint aber richtig zu sein
www.mikrocontroller.net/topic/481077
edit 2: laut Datenblatt hat das Ding zwei Schnittstellen, eine Uni- und
eine Bidirektionale. Die Frontseitige ist die richtige.
Boah ich stehe mit dem alten Oszi DST1062B auf Kriegsfuß, an dem neuen
windows 10 PC will meine alte Software nicht ... finde jetzt gerade
keinen passenden USB Treiber etc.
Daher nur der Screenshot via USB:
die Zeitskala ist mir zu "grob" zum manuellen dekodieren. aber der
Ruhepegel vor Beginn der Übertragung müsste High sein.
Matthias 🟠. schrieb:> Den Lesekopf habe ich wie angegeben angeschlossen.
ist OK, aber das sagt nichts darüber aus, ob das Teil invertierte Pegel
treibt oder nicht. es ist ja dafür gemacht, ein weiteres Modul von
derselben Firma anzuschließen. wenn das invertierte Pegel erwartet,
passt der Ausgang für ihn.
Matthias 🟠. schrieb:> Daher nur der Screenshot via USB:
Bei der geringen Zeitauflösung ist das ziemlich mühsam abzulesen. Stell
das Oszi doch einmal so ein, dass nur etwa drei Byte erfasst werden,
damit die Pixel nicht so stören. Oder besser noch wäre Logikanalysator
mit dem du das Signal mit vernünftiger Zeitauflösung über einen größeren
Zeitbereich aufzeichnen kannst.
Achim S. schrieb:> die Zeitskala ist mir zu "grob" zum manuellen dekodieren. aber der> Ruhepegel vor Beginn der Übertragung müsste High sein.
Auf dem Oszi ist vorne L-Pegel zu sehen. Stellt sich die Frage, ob das
Oszi richtig getriggert wurde.
Wolfgang schrieb:> Auf dem Oszi ist vorne L-Pegel zu sehen. Stellt sich die Frage, ob das> Oszi richtig getriggert wurde.
Da hast du natürlich auch recht: wenn das nicht der Start der Sequenz
sein sollte, ist die Aussagekraft der Messung gering. Aber immerhin
zeigt die gemessene Sequenz zwei mal hintereinander vier identische
Bytes - ist also nicht ganz unwahrscheinlich, dass es sich doch um den
Beginn der Übertragung handelt.
Gehn wir einfach mal den umgekehrten Weg.
Matthias: im Anhang siehst du in einer alten Messung von meinem Zähler,
wie das erste Byte der Sequenz korrekt aussehen sollte. (Na ja: die
Flanken müssen nicht unbedingt so verschliffen sein wie in meiner
Messung :-)
Matthias 🟠. schrieb:> Den Lesekopf habe ich wie angegeben angeschlossen.
Der Lesekopf arbeitet ja mit 12V, spricht also eventuell RS232, das
heisst er arbeitet mit invertierten Pegeln.
Nach dem Oszi-Bild sind die logisch-0-Pegel aber nicht 12V sondern eher
so 3.3V
Wie hast du den mit deinem PC verbunden? Über einen Spannungsteiler und
einen UART-USB-Adapter?
LG, Sebastian
... schrieb im Beitrag #7202535:
> Da hast du dann den Zaehlerstand vermutlich sogar ausgedruckt> schwarz auf weissem Papier.
Aber nicht alle zwei Sekunden. Mit der Menge an Papier könnte man mollig
warm über den Winter kommen :)
LG, Sebastian
... schrieb im Beitrag #7202535:
> Warum willst du ueberhaupt den Zaehler auslesen?>> Dein Energieversorger wird dir schon eine Rechnung schicken.> Da hast du dann den Zaehlerstand vermutlich sogar ausgedruckt> schwarz auf weissem Papier.
Nachdem man ihn optisch abgelesen hat und an den Energieversorger
geschickt hat. Warum also so lange warten? :D
mppt schrieb:> Zwischenfrage, kann dieser Tastkopf nur lesen oder hat der auch eine> Sendediode?
Nein der Kopf kann nur lesen.
... schrieb im Beitrag #7202535:
> Warum willst du ueberhaupt den Zaehler auslesen?
Weil ich für mich und meine Kinder den momentanen Verbrauch zu
Erziehungszwecken visualisieren möchte
und weil es mein Hobby ist und ich ein Projekt habe
und ich eine Menge lerne und meinen Kindern darin ein Vorbild sein
möchte
und ... reicht das an Gründen?
Zurück zum Problem:
Peter K. schrieb:> Invertiert der LEsekopf nicht?> Ich habe einen billigen aus Ebay für 19€ der invertiert meines Wissens> direktYalu X. schrieb:> L=1 und H=0, dann ist lt. Oszi alles perfekt.
Das heist ich muss das Signal vorher mit Hardware invertieren? Sonst
kommt die Serielle-Schnittstelle damit nich klar oder reicht das via
Software zu invertieren?
Sebastian W. schrieb:> Matthias 🟠. schrieb:>> Den Lesekopf habe ich wie angegeben angeschlossen.>> Der Lesekopf arbeitet ja mit 12V, spricht also eventuell RS232, das> heisst er arbeitet mit invertierten Pegeln.>> Nach dem Oszi-Bild sind die logisch-0-Pegel aber nicht 12V sondern eher> so 3.3V>> Wie hast du den mit deinem PC verbunden? Über einen Spannungsteiler und> einen UART-USB-Adapter?>> LG, Sebastian
Ich habe den Lesekopf mit dem Pollin Adapter
(https://www.pollin.de/p/rs232-ttl-wandler-mit-max3232-810358) für HTERM
an den PC angeschlossen. Hier hatte ich für die Versorgung des
Leseskopfes auch höhere Spannung draufgegeben (+12V) aber festgestellt
das der Kopf runter bis 1,8 Volt arbeitet. Erst ab 1,5 Volt stellt er
die Arbeit ein.
Für den zweiten Teil/Versuch nutze ich ein Pi Pico RP2040 und nutze
daher die 3,3 Volt. Damit habe ich den HEX Dump und die Zeitmessung
erstellt.
Leider lese ich auch hier nur die verkehrten Bytes ein.
An dieser Stelle: DANKE für eure Hilfe.
Achim S. schrieb:> Wolfgang schrieb:>> Auf dem Oszi ist vorne L-Pegel zu sehen. Stellt sich die Frage, ob das>> Oszi richtig getriggert wurde.>> Da hast du natürlich auch recht: wenn das nicht der Start der Sequenz> sein sollte, ist die Aussagekraft der Messung gering. Aber immerhin> zeigt die gemessene Sequenz zwei mal hintereinander vier identische> Bytes - ist also nicht ganz unwahrscheinlich, dass es sich doch um den> Beginn der Übertragung handelt.
Ist der Start, weil ich in der Pause von meinem Hexdump parallel am Oszi
auf Single-SEQ gedrückt habe. Vorher ist L, ich habe das Ergebnis nur
nach links Verschoben, damit man mehr sieht :-)
> Gehn wir einfach mal den umgekehrten Weg.> Matthias: im Anhang siehst du in einer alten Messung von meinem Zähler,> wie das erste Byte der Sequenz korrekt aussehen sollte. (Na ja: die> Flanken müssen nicht unbedingt so verschliffen sein wie in meiner> Messung :-)
Ich bin heute Unterwegs und komme erst heute Abend dazu weiter zu
machen, ich erstelle dann eine feinere Auflösung ...
Matthias 🟠. schrieb:> Das heist ich muss das Signal vorher mit Hardware invertieren?
ja
Matthias 🟠. schrieb:> oder reicht das via Software zu invertieren?
nein, reicht nicht. wegen der invertierung werden ja auch Start und
stoppbit falsch interpretiert.
Matthias 🟠. schrieb:> Ich habe den Lesekopf mit dem Pollin Adapter> (https://www.pollin.de/p/rs232-ttl-wandler-mit-max3232-810358) für HTERM> an den PC angeschlossen.
Versteh ich nicht. Du hast den Tastkopf ab die TTL-Seite des
Pollin-Adapters angeschlossen, und dann den Pollin-Adapter an die
serielle RS232-Schnittstelle des PC?
LG, Sebastian
Matthias 🟠. schrieb:> Das heist ich muss das Signal vorher mit Hardware invertieren? Sonst> kommt die Serielle-Schnittstelle damit nich klar oder reicht das via> Software zu invertieren?
Natürlich reicht es, das Signal in der Software anders herum zu
interpretieren. Das funktioniert allerdings nur mit einem Soft-UART, bei
dem die Definition der Pegel für H und L konfigurieren kannst.
Sebastian schrieb:> Versteh ich nicht. Du hast den Tastkopf ab die TTL-Seite des> Pollin-Adapters angeschlossen, und dann den Pollin-Adapter an die> serielle RS232-Schnittstelle des PC?
Ja, nur die Serielle am PC war wieder ein USB Adapter.
Hintergrund war der: Pollin Adapter 5V und der Lesekopf dann die 12
Volt. Ich wollte ausschließen das meine zu geringe Spannung zum Problem
führt.
Ist aber nicht so, sondern der Lesekopf gibt leider ein invertiertes
serielles Signal aus.
Also habe ich in meinem Fundus gesucht und eine SN74HCT14N gefunden.
Jetzt sieht das Signal so aus: siehe Bild
UND das obwohl ich den Inverter IC nur mit 3.3V versorge, aber zum
Testen reicht und klappt es!
Achim S. schrieb:> nein, reicht nicht. wegen der invertierung werden ja auch Start und> stoppbit falsch interpretiert.
So danke an alle!
Ich habe neues gelernt und jetzt sehe ich mal zu wie ich den Verbrauch
heraus lese.
Anbei noch der neue Hex-Dump und ein Bild vom Testaufbau:
Matthias 🟠. schrieb:> 1B 1B 1B 1B 01 01 01 01 76 05 32 BF 6B 70 62 00 v 2¿kpb> ...
Wenn du das von Sebastian verlinkte Protokoll richtig umgesetzt hast,
solltest du aus den von dir geposteten vier Nachrichten u.a. folgende
Ergebnisse herauslesen können:
Matthias 🟠. schrieb:> Anbei noch der neue Hex-Dump und ein Bild vom Testaufbau:> PicoMite MMBasic Version 5.07.04> Copyright 2011-2021 Geoff Graham> Copyright 2016-2021 Peter Mather>> run> 1B 1B 1B 1B 01 01 01 01 76 05 32 BF 6B 70 62 00 v 2¿kpb
Matthias, ich würde in solchen Ausschnitten immer die Zählernummer
verwischen.
LG, Sebastian
Sebastian W. schrieb:> Matthias, ich würde in solchen Ausschnitten immer die Zählernummer> verwischen.
Ja, ich hatte kurz gezuckt ob ich den ganzen Dump poste, aber ehrlich
man muss ja vom Fach sein. Und vorher habe ich ja noch nicht gewusst wo
die Nummer steht.
Aber danke für den Hinweis.
LG, Matthias
Ich werde, da mein Datensatz ohne PIN immer den gleiche Aufbau hat und
die gesuchten Werte immer an der selben Stelle stehen, einfach zählen
und die gewünschten Daten dann schön visualisieren.
Matthias 🟠. schrieb:> Ich werde, da mein Datensatz ohne PIN immer den gleiche Aufbau hat und> die gesuchten Werte immer an der selben Stelle stehen, einfach zählen> und die gewünschten Daten dann schön visualisieren.
Dass die gesuchten Werte immer an derselben Stelle stehen, stimmt nicht
ganz. Taucht die Escape-Sequenz (1b 1b 1b 1b) irgendwo in den Nutzdaten
auf, wird sie verdoppelt, d.h alle nachfolgenden Bytes verschieben sich
um 4 Positionen (s. Seite 68 der SML-Spezifikation).
Die Wahrscheinlichkeit, dass dieser Fall eintritt, ist zwar sehr gering,
es ist aber auch kein großes Problem, die verdoppelten Escape-Sequenzen
im Datenstrom zu erkennen und entsprechend zu behandeln.
Edit:
Des Weiteren können in SML Zahlenwerte mit variabler Breite (bspw. 8, 16
oder 32 Bit, je nach Bedarf) dargestellt werden. Ob dein Zähler von
dieser Möglichkeit Gebrauch macht, weiß ich nicht. Meiner tut es
zumindest bei dem Wert für die aktuellen Leistung, so dass auch hier mit
einer Verschiebung der nachfolgenden Daten zu rechnen ist. Da die
Leistungsangabe der letzte relevante Wert in der Nachricht ist, ist aber
auch das nicht so kritisch.
Hab schnell mal mein Python Script umgebaut, das kann OBIS lesen inkl.
CRC Check. Normalerweise wirft es die Daten über MQTT raus, hab ich eben
mal auskommentiert. Ausgabe:
Stefan B. schrieb:> Python Script
Interessant.
Yalu X. schrieb:> Edit:>> Des Weiteren können in SML Zahlenwerte mit variabler Breite (bspw. 8, 16> oder 32 Bit, je nach Bedarf) dargestellt werden. Ob dein Zähler von> dieser Möglichkeit Gebrauch macht, weiß ich nicht. Meiner tut es> zumindest bei dem Wert für die aktuellen Leistung, so dass auch hier mit> einer Verschiebung der nachfolgenden Daten zu rechnen ist.
Ja dies passiert, ich habe heute die Ausgabe einfach den ganzen Tag
laufen lassen und es zerreißt die Ausgabe beim stumpfen abzählen ;-(
Also doch zumindest ein Teil parsen und passend darauf mit der
Auswertung reagieren. Wo wäre auch sonst die Herausforderung :-)
Ich werde aber erst in ein paar Tagen dazu kommen. Endspurt im Büro und
vor den Ferien ... doch bin ich einfach glücklich das die Werte
überhaupt gesendet werden!