Hallo,
ich habe einen Stromzähler EMH eHZ-K und einen IR Lesekopf.
In der SML-Protokollbeschreibung steht, dass die Escape-Sequenz
1b 1b 1b 1b ist, gefolgt von 01 01 01 01. Jedoch sehe ich diese
Sequenzen nicht. Die Schnittstelle ist auf 9600Baud 8N1 eingestellt.
Hat jemand eine Idee?
Ich lese testweise mit
sudo hexdump -C /dev/ttyUSB0
aus und sehe die einzelnen Datenbytes. In der Bedienungsanleitung habe
ich
das gefunden:
"81 81 C7 82 03 FF Hersteller-Kennung"
Und die finde ich tatsächlich auch im Datenstrom:
00000400 79 77 81 81 c7 82 03 ff 01 01 04 48 01 01 00 09
|yw.........H....|
00000410 01 01 09 01 48 00 b6 00 07 01 08 00 01 01 62 1e
|....H.........b.|
Dass er ASCII sendet kann ich hier nicht sehen.
Hast du den sicherheitspin eingegeben?
Bei meinem EMH ist es so dass ohne diesen PIN nur eine Kennung und?
(weiß nicht mehr genau) der Zählerstand raus geht aber keine aktuelle
Leistung
Stevven schrieb:> Hast du den sicherheitspin eingegeben?
Nein habe ich nicht. Ich habe gelesen, dass man die Pin nach
Stromausfall neu reinblinken müsste und ich brauche auch nur
Gesamteinspeisung und Gesamtbezug.
In der Betriebsanleitung steht: "Der „Reduzierte Datensatz“ enthält
keinen Wert für die Momentanwirkleistung, die Zählwerksstände werden in
kWh ausgegeben."
Mich wundert, dass die SML Datenstrukturen nicht zu erkennen sind.
Fast scheint mir, als wäre im reduzierten Modus das SML Format auch ein
anderes.
Heinz schrieb:> Mich wundert, dass die SML Datenstrukturen nicht zu erkennen sind.
für mich sehen die bisher gezeigten 32 Byte auch nicht nach korrektem
SML aus. Kannst ja mal einen etwas längeren Ausschnitt hier reinstellen.
Vielleicht erkennt man dann etwas, was in den bisherigen 32 Byte nicht
offensichtlich ist.
Meine erste Vermutung wäre, dass bei deinem Empfang oder deiner
Datenausgabe was schief läuft (Werte verloren gehen oder verfälscht
werden). Aber da du die Herstellerkennung sauber siehst, ist das auch
nicht so richtig wahrscheinlich.
Trotzdem würde ich an deiner Stelle mal ein Oszi (sofern vorhanden) an
den IR-Lesekopf hängen, und mir bei den ersten paar Bytes anschauen, ob
das Signal sauber oder irgendwie "grenzwertig" ist (bezüglich Pegel oder
Bitdauer). Vielleicht empfängst du ja manche Bytes korrekt, andere
nicht.
Außerdem könntest du das Oszi auf den Beginn des Telegramms triggern,
und dann mal ein paar Byte von Hand dekodieren - das wäre eine
unabhängige Überprüfung, ob das Telegramm mit 1b 1b 1b 1b 01 01 01 01
beginnt oder nicht.
Heinz schrieb:> Fast scheint mir, als wäre im reduzierten Modus das SML Format auch ein> anderes.
Dass der Ausgang je nach Detailgrad zwischen SML und nicht-SML
umschaltet fände ich seltsam. Natürlich kann man auch sowas nicht
ausschließen, aber ich hab bisher von so einer Konfiguration noch nicht
gehört.
Achim S. schrieb:> Trotzdem würde ich an deiner Stelle mal ein Oszi (sofern vorhanden) an> den IR-Lesekopf hängen, und mir bei den ersten paar Bytes anschauen
Der IR Lesekopf und die Datenerfassung ist ok. Der Lesekopf war zuvor an
einem Iskra MT631 angeschlossen
> Kannst ja mal einen etwas längeren Ausschnitt hier reinstellen.> Vielleicht erkennt man dann etwas
Hier ein Ausschnitt, werde das auch analysieren aber vielleicht hat ja
jemand einen Tipp. Mir würde auch helfen, wenn jemand einfach nur sagen
kann, was das für ein Protokoll ist. Mich interessieren zwei Werte:
Energieeinspeisung und
-bezug
03560000770702080101520300000177
0001ff011e5200000001070108020162
035600007707c782010183023874c477
ee52bd92ce8587fa559bb636b89f2cea
0e1f1ca8016300761500426200720171
66011b1b00771b1b0101760700396200
726376010015406c014500000001edf4
070039c100626307010b454d00a90701
0aff620110957707c782010104450177
0000ff01010b454d00a901770001ff64
82015203000001770002ff6482015203
000001770001ff011e52000034010100
01ff621e560002b40701080201620356
000077070208010152030000017781c7
ff010183a03893c43fee86bda8ce3f87
265566b6afb8702c650eca1c0101d600
0015c1486200020163001b1b1aef1b1b
01017615004a62007201760700104009
014800b6006347760700396200726377
01014500000007620a72620010797781
c7ff0101044801010009ff0101014500
000001010000ff01821e520000340101
08000101621e560002b4070108010162
03560000770702080101520300000177
0001ff011e5200000001010002ff621e
56000000078181c78205ff010183a038
93c43fee86bda8ce3f87265566b6afb8
702c650eca1c010100000015c14e6200
020163991b1b1a001b1b010176070039
62007263760100154070014500000001
2ea5070039c100626307010b454d00a9
07010aff620110957707c78201010445
01770000ff01010b454d00a901770001
ff6482015203000001770002ff648201
5203000001770001ff011e5200003401
010001ff621e560002b4070108020162
03560000770702080101520300000177
81c7ff010183a03893c43fee86bda814
3fdc26b7668daf30708d655aca010186
05070039c1006263020163001b1b1ab9
1b1b0101761500566200720176070010
4009014800b60063a776070039620072
017709014800b6000062ff726500da79
818103ff01014d480701000901010901
4800b600070108000101621e56000034
070108000101621e5600000002b40101
0001ff621e5600003407010801010152
0002b407010801015203000001770002
ff011e5200000001818105ff01011ea0
d893ed3f7686c1a8143fdc26b7668daf
30708d655aca0101cbda070039c10062
63020163001b1b1aea1b1b0101761500
5c62007201760700104009014800a9b6
0163007615005d620072017709014800
b6000062ffff016595dd7707c7820101
04450177010009ff0101014500000001
010000ff01821e5200003401010000ff
01821e520000b4010108010162035600
01770002ff011e520000b40101000802
0162520300000001010002ff621e5600
0000078182050101021e74d8c477ee52
bd92ce8587fa559bb636b89f2cea0e1f
1c01019d000015c1606200020163001b
1b1a211b1b0101761500626200720176
070010400b094d48a9b6016300761500
c163620007010b094d000007620a7201
65001095df79818103ff01014d480700
09ff0101014500000001070108000101
621e5600003477070208648201520300
b401010801016203560000770702ff01
1e520000b40101000201620356000077
0002ff011e5200000001818105ff0101
1ea0d893ed527692c18514fa559bb636
b89f2cea650eca1c01017c000015c166
6263020163001b1b1a84451b1b010100
00396200726301760700104009014800
b6006397760700396962007201770901
4800b6000062ff016595e10781820301
044501770000ff01010b454d00a90101
08000101621e56000034070108006401
01520300000177000101ff621e560000
77070208010152030000b40101000801
1e5200000001010002ff621e56000000
078182010101021e74d877ed527692c1
ce3f87265566b6afb8702c650eca0101
9d007615006c620072017131aa001b1b
1b1b1a721b1b0101070039c162007201
010015407a0145000000011efd071500
c16f007263017709014d48a9b607010a
726500e3078182030101454d77070000
01010b454d00a901770001ff01821e52
00003401010000640101625203000001
0701080101625203000001770002ff01
1e520000b40701080201620300000177
0002ff011e5200000007818205010102
3874c477ee52bd92ce8587fa559bb6af
9f30ea8d1f5aa80163d0007615007262
Hallo,
Heinz schrieb:> Nein habe ich nicht. Ich habe gelesen, dass man die Pin nach> Stromausfall neu reinblinken müsste und ich brauche auch nur> Gesamteinspeisung und Gesamtbezug.
besitze mehrere mMe4.0 mit SML bei allen konnte ich die wiederholte
Eingabe der Pin aussetzen. So das die Pin nicht mehr benötigt wird, wird
auch bei Ausfall und Umbau nicht mehr nachgefragt.
Info: habe die Empfangsdiode eHZ abgeklebt. Störungen beim Start.
Heinz schrieb:> Der IR Lesekopf und die Datenerfassung ist ok. Der Lesekopf war zuvor an> einem Iskra MT631 angeschlossen
Es geht mir nicht darum, dass der Lesekopf "kaputt" ist. Aber dass er an
einem Sender saubere Signale liefert bedeutet nicht automatisch, dass er
das an einem anderen Sender ebenso tut. Das ist als Fehlerursache nicht
unbedingt wahrscheinlich. Aber es wäre eine mögliche Erklärung.
Nachmessen schafft Klarheit.
Dein Hexdump beinhaltet keine korrekte SML-Nachricht. Aber Bruchstücke
davon lassen sich erkennen. Deshalb gehe ich jetzt eher davon aus, dass
das Problem bei deinem Empfang der Daten und deren Übertragung liegt.
Beispiele:
1b1b1aef1b1b
010176
Wenn man das mit den folgenden Bytes in Anführungsstrichen ergänzt, wird
es sinnvolles SML
"1b 1b" 1b 1b 1a ef "XX XX" -- Ende des Telegramms mit CRC XX XX
1b 1b "1b 1b 01 01" 01 01 -- Beginn neues Telegramm
76 -- Liste mit 6 Einträgen...
Das folgende Schnippsel dürfte (mit Ergänzungen fehlender Bytes) die
Wirkenergie anzeigen:
01 08 00 "ff" --Obis-Code Wirkenergie
01 --optionales Statuswort (kein Inhalt)
01 --optionaler Timecode (kein Inhalt)
62 1e --Einheit Wh
"52 fc" -- Multiplikator 10^-4
56 00 00 34 07 "XX" -- Zahlenwert x00003407XX
01 --Ende Listeneintrag
08 --Oktett-String zu neuem Listeneintrag...
Im Zahlenwert fehlt offensichtlich auch wieder ein Byte. Ob es am Ende
fehlt oder mittendrin, lässt sich nicht einfach sagen. Wenn du mal den
Zählerstand abliest und mitteilst, lässt sich der korrekte Hex-Wert dazu
wahrscheinlich rekonstruieren. Es wäre jedenfalls ein Integer mit 48
Bit.
Inzwischen bin ich überzeugt, dass dein Zähler SML sendet, dass dir aber
beim Empfangen und Übertragen immer wieder Bytes verloren gehen, so dass
das Telegramm keinen Sinn mehr ergibt.
Achim S. schrieb:> dass dir aber> beim Empfangen und Übertragen immer wieder Bytes verloren gehen
Hm, dann werde ich das mal in meine Überlegungen mit einbeziehen.
Werde auch die Empfangsdiode des Zählers versuchsweise abkleben
Hallo,
nun das Protokoll zeigt nicht eine Start_Sequenz und mit viel Fantasie
ein Bruchteil der Ende_Sequenz.
Der Zähler muss im ~"Normalstatus" sich befinden.(Störungen über die
Empfangsdiode eHZ können das verhindern). Und Du solltest die Pin auch
benutzen, wenn Du sie hast.
Das Protokoll zeigt aber auch das Du kein Programm hast zur Auswertung
der Daten. Scan auf Start und evtl. Ende.
Ich habe auch nur alle ~1000ms ein Datenstrom von 328 Byte.
Heino schrieb:> So hier mal zwei komplette Datenpakete:
woher glaubst du zu wissen, dass das gerade zwei komplette Datenpakete
sind. Machst du es an den rudimentär erkennbaren Escape-Sequenzen fest
(1b 1b 1b ...)? Dann sollte schon die unterschiedliche Länge der beiden
Pakete dir zu denken geben.
Ich stelle dir hier mal den Beginn der beiden Datenpakete gegenüber
(festgemacht an den rudimentären Escape-Sequenzen):
1b 1b 01 01 07 00 42 17 00 62 63 01
1b 1b 01 01 76 07 00 42 62 00 72 63 76 01
Im direkten Vergleich siehst du Lücken - das sind Stellen, an denen du
jeweils ein oder mehrere Bytes verloren hast. (Und wenn die Bytes in
beiden Paketen verloren gegangen sind, siehst du noch nicht mal die
Lücken.)
Nochmal der Vorschlag von gestern: hänge ein Oszi an den Lesekopf,
triggere auf den Start des Pakets und schau dir die ersten paar Bytes
des Pakets direkt auf dem Oszi an. Ein paar Byte lang lässt sich ein
UART Signal auch von Hand dekodieren. Ich wette, du siehst die volle
Startsequenz (1b 1b 1b 1b 01 01 01 01), von der deine
Datenerfassung/übertragung die Hälfte verschluckt.
Und mit ein bisschen Glück siehst du dem Signal vielleicht auch noch an,
warum deine Datenerfassung sie verschluckt ("zu kurzes Stopbit",
grenzwertige Pegel, ....)
Hi,
sorry, aber man sieht ein Ende eines Telegramms aber kein Start somit
kein gültiges Aussage.
Rechne einfach mal zurück (56kW x 10000)[1/10W] in Hex [00 08 8B 80]01}
findest Du nicht.
Heino schrieb:> Es lief parallel ein anderes Script, das auch auf die Schnittstelle> zugegriffen hat.
Mist, genau auf diese mögliche Fehlerursache wollte ich dich eigentlich
schon direkt nach dem Betrachten deines ersten Datensatzes hinweisen:
Heinz schrieb:> Hier ein Ausschnitt> ...
Allerdings erschien mir diese Hypothese dann doch etwas an den Haaren
herbeigezogen und ging deswegen von Übertragungsfehlern auf Grund eines
schlecht dimensionierten bzw. schlecht an den IR-Sender des Zählers
angepassten Lesekopf aus.
Peter* schrieb:> kleine Anmerkung: [03 0F] sind keine 783KW
Von 783KW war auch nicht die Rede sondern von 783 kWh (bzw. 782 kWh -
zwischen den beiden Messungen, die einige Stunden auseinander lagen, ist
der Wert für 2.8.0 wohl noch um 1 nach oben gegangen).
Und 783 kWh steht korrekt im SML-Telegramm:
62 1e --Einheit Wh
52 03 --Saklierungsfaktor 10^3=1000
56 00 00 00 03 0f --Zahlenwert 0x030F = 783
783*1000*Wh ergibt 783 kWh
Ein weiterer möglicher Fehler ist ein falscher Modus der seriellen
Schnittstelle. Wenn sie auf ASCII eingestellt ist, dann könnte noch ein
höheres Handshaking-Protokoll gefahren werden, das die gesendeten
Zeichen interpretiert und damit die Daten zerhackt. War bei meinem
Zähler jedenfalls so.
Abhilfe: stty -F /dev/ttyUSB0 9600 cs8 -cstopb -parenb raw
Am besten vor jedem Lesen setzen, ein anderes Programm könnte die
Parameter zwischenzeitlich umgestellt haben.
Dies nur als Hinweis, damit es nicht nur heute sondern auch morgen noch
funktioniert.
Hallo,
in der Tat, richtig!
Klinkt brutal, ich habe wohl zur Zeit nur auf dem privaten Sektor die
eHZ's, die haben aber 1/10Wh Auflösung statt 1kWh. Wahrscheinlich auch
egal.
Ich protokolliere die Phasen.
Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.
Wichtige Regeln - erst lesen, dann posten!
Groß- und Kleinschreibung verwenden
Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang
Announcement: there is an English version of this forum on 
Thread beobachten
Seitenaufteilung abschalten