Forum: Haus & Smart Home Stromzähler SML Protokoll


von Heinz (Gast)


Lesenswert?

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?

von Rüdiger B. (rbruns)


Lesenswert?

Danach hatte ich bei meinem Zähler auch gesucht und dann festgestell das 
er ASCII sendet.

von Heinz (Gast)


Lesenswert?

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.

von Stevven (Gast)


Lesenswert?

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

von Heinz (Gast)


Lesenswert?

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.

von Achim S. (Gast)


Lesenswert?

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.

von Heinz (Gast)


Lesenswert?

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

von Peter* (Gast)


Lesenswert?

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.

von Achim S. (Gast)


Lesenswert?

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.

von Achim S. (Gast)


Lesenswert?

Achim S. schrieb:
> Es wäre jedenfalls ein Integer mit 48 Bit.

kleine Korrektur: ein integer mit 40bit...

von keine Ahnung (Gast)


Lesenswert?

Guten Morgen

auch wenn es total unsinnig ist, schonmal mit
('/dev/ttyUSB0', 9600, 7, 'E', 1, timeout=1) versucht?

Kostet ja nix ...

von Heino (Gast)


Lesenswert?

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

von Peter* (Gast)


Lesenswert?

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.

von Heino (Gast)


Lesenswert?

So hier mal zwei komplette Datenpakete:
00001310  01 71 8c dd 1b 1b 00 1e  1b 1b 01 01 07 00 42 17 
|.q............B.|
00001320  00 62 63 01 01 01 15 00  bb 0b 45 00 00 00 01 7f 
|.bc.......E.....|
00001330  76 07 00 42 62 00 72 63  77 01 01 45 00 00 00 07 
|v..Bb.rcw..E....|
00001340  62 0a 72 62 00 12 79 77  81 c7 ff 01 01 04 48 01 
|b.rb..yw......H.|
00001350  01 00 09 ff 01 01 01 45  00 00 00 01 01 00 00 ff 
|.......E........|
00001360  01 a2 1e 52 00 00 38 01  01 00 00 ff 01 a2 1e 52 
|...R..8........R|
00001370  00 00 0e 07 01 08 01 01  62 03 56 00 01 77 00 02 
|........b.V..w..|
00001380  ff 01 1e 52 00 00 0e 01  01 00 02 ff 62 1e 56 00 
|...R........b.V.|
00001390  00 00 07 01 08 02 01 62  03 56 00 00 77 07 c7 82 
|.......b.V..w...|
000013a0  01 01 83 02 38 74 c4 77  ee 52 bd 92 ce 85 87 fa 
|....8t.w.R......|
000013b0  55 9b b6 36 b8 9f 2c ea  0e ca 1c 01 01 01 63 44 
|U..6..,.......cD|
000013c0  7f 00 76 07 00 15 00 42  17 35 62 00 62 00 72 63 
|..v....B.5b.b.rc|
000013d0  02 01 71 01 63 41 bb 00  1b 1b 1b 1b 1a 00 c9 31 
|..q.cA.........1|

000013e0  1b 1b 01 01 76 07 00 42  62 00 72 63 76 01 00 15 
|....v..Bb.rcv...|
000013f0  07 bd 01 45 00 00 00 01  4f 75 07 00 42 17 00 62 
|...E....Ou..B..b|
00001400  63 07 01 0b 45 4d 00 00  00 07 62 0a 72 62 65 00 
|c...EM....b.rbe.|
00001410  88 79 81 81 03 ff 01 01  4d 48 07 01 00 00 01 01 
|.y......MH......|
00001420  0b 09 4d 48 a9 b6 77 07  01 08 64 01 01 62 03 56 
|..MH..w...d..b.V|
00001430  00 00 77 07 02 08 64 01  01 62 03 56 00 03 77 07 
|..w...d..b.V..w.|
00001440  01 ff 01 1e 52 00 00 38  01 01 00 01 ff 62 1e 56 
|....R..8.....b.V|
00001450  00 03 77 07 01 08 01 01  52 03 00 00 01 77 00 02 
|..w.....R....w..|
00001460  ff 01 1e 52 00 00 00 01  81 81 05 ff 01 01 1e a0 
|...R............|
00001470  74 d8 77 ed 52 76 92 c1  85 14 fa dc 9b b7 b6 36 
|t.w.Rv.........6|
00001480  b8 9f 2c ea 0e 1f 1c a8  01 63 00 76 15 00 3b 62 
|..,......c.v..;b|

von Heino (Gast)


Lesenswert?

Der abgelesene Zählerstand zu den zwei Datenpaketen
2.8.0: 782kWh
1.8.0: 56kWh

von Achim S. (Gast)


Lesenswert?

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, ....)

von Peter* (Gast)


Lesenswert?

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.

von Heino (Gast)


Lesenswert?

So, jetzt geht es, ein wirklich dummer Fehler: Es lief parallel ein
anderes Script, das auch auf die Schnittstelle zugegriffen hat.
Der Tip von Achim S., dass die Daten invalide sind, hat mich auf die 
richtige Spur gebracht, Danke!!

000002e0  1b 1b 1b 1b 01 01 01 01  76 07 00 15 00 42 a3 e0
000002f0  62 00 62 00 72 63 01 01  76 01 01 07 00 15 00 13
00000300  36 a0 0b 09 01 45 4d 48  00 00 a9 b6 00 01 01 63
00000310  a0 e1 00 76 07 00 15 00  42 a3 e1 62 00 62 00 72
00000320  63 07 01 77 01 0b 09 01  45 4d 48 00 00 a9 b6 00
00000330  07 01 00 62 0a ff ff 72  62 01 65 00 13 2a 79 79
00000340  77 07 81 81 c7 82 03 ff  01 01 01 01 04 45 4d 48
00000350  01 77 07 01 00 00 00 09  ff 01 01 01 01 0b 09 01
00000360  45 4d 48 00 00 a9 b6 00  01 77 07 01 00 01 08 00
00000370  ff 64 01 01 82 01 62 1e  52 03 56 00 00 00 00 38
00000380  01 77 07 01 00 02 08 00  ff 64 01 01 82 01 62 1e
00000390  52 03 56 00 00 00 03 0f  01 77 07 01 00 01 08 01
000003a0  ff 01 01 62 1e 52 03 56  00 00 00 00 38 01 77 07
000003b0  01 00 02 08 01 ff 01 01  62 1e 52 03 56 00 00 00
000003c0  03 0f 01 77 07 01 00 01  08 02 ff 01 01 62 1e 52
000003d0  03 56 00 00 00 00 00 01  77 07 01 00 02 08 02 ff
000003e0  01 01 62 1e 52 03 56 00  00 00 00 00 01 77 07 81
000003f0  81 c7 82 05 ff 01 01 01  01 83 02 1e a0 38 74 d8
00000400  93 c4 77 ed 3f ee 52 76  86 bd 92 c1 a8 ce 85 14
00000410  3f 87 fa dc 26 55 9b b7  66 b6 36 8d af b8 9f 30
00000420  70 2c ea 8d 65 0e 1f 5a  ca 1c a8 01 01 01 63 2f
00000430  2b 00 76 07 00 15 00 42  a3 e4 62 00 62 00 72 63
00000440  02 01 71 01 63 55 55 00  1b 1b 1b 1b 1a 00 ab 87

von Peter* (Gast)


Lesenswert?

Hallo,

kleine Anmerkung: [03 0F]  sind keine 783KW

von Yalu X. (yalu) (Moderator)


Lesenswert?

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.

von Achim S. (Gast)


Lesenswert?

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

von Felix W. (fhwe)


Lesenswert?

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.

von Peter* (Gast)


Lesenswert?

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.

von Thomas Bayer (Gast)


Lesenswert?

Hallo,

EnBW hat im Dezember 2022 bei mir den ISKRA MT691 installiert. Das 
Auslesen (8N1)liefert nur die Werte für 1.8.0 und 2.8.0. 
Bedauerlicherweise wohl nur ein Byte:
So sieht die Nachricht aus:
77 07 01 00 01 08 00 ff
   65 00 1c 01 04 01
   62 1e Einheit Wh
   52 03 Skalierung 10^3
   62 37 Unsigned Byte als Wert (Ablesung: 55)
01

Der Wert des Bytes stimmt mit den angezeigten Wert überein. Nur was 
passiert beim Überlauf?

Bei 2.8.0 wahrscheinlich ebenfalls
77 07 01 00 02 08 00 ff 01 01
   62 1e
   52 03
   62 25 (Ablesung 37)
   01 01 01 63 be 41 00 76 05 00 2b 98 29 62 00 62 00 72 63 02 01 71 01 
63 61 34 00 00 1b 1b 1b 1b

Hat jemand ähnliche Erfahrung gemacht?

von Achim S. (Gast)


Lesenswert?

Thomas Bayer schrieb:
> Bedauerlicherweise wohl nur ein Byte:
.....
> Der Wert des Bytes stimmt mit den angezeigten Wert überein. Nur was
> passiert beim Überlauf?

Sobald das eine Byte für den Messwert nicht mehr ausreicht, werden halt 
mehr als ein Byte verschickt werden.

von Muecke -. (muecke82)


Lesenswert?

Hallo zusammen,

sorry, das ich einfach so da ein platze.

ich versuche auch gerade mein Glück beim auslesen eines Stromzählers 
"ISKRA-MT681".

Hardware ESP32 DEVKIT V1, ISKRA-MT681, TCRT5000

Mein Code schaut so aus:
1
#include <IRremote.h>
2
int RECV_PIN = 15;
3
IRrecv irrecv(RECV_PIN);
4
decode_results results;
5
6
void setup()
7
{
8
 Serial.begin(9600);
9
 irrecv.enableIRIn();                                            
10
     Serial.println(F("Start ==> ESP32 - TCRT5000 - ISKRA-MT681 <== Start"));
11
}
12
13
void loop() {
14
 if (irrecv.decode(&results)) {
15
16
     Serial.println(F("NEU -- NEU "));
17
     Serial.println(F(" "));
18
     Serial.println(F(" "));          
19
20
     Serial.print(F("BIN => "));
21
     Serial.println(results.value, BIN);                          
22
23
     Serial.print(F("OCT => "));
24
     Serial.println(results.value, OCT);                          
25
26
     Serial.print(F("DEC => "));
27
     Serial.println(results.value, DEC);                          
28
29
     Serial.print(F("HEX => "));
30
     Serial.println(results.value, HEX);                          
31
32
     Serial.print(F("  0 => "));
33
     Serial.println(results.value, 0);                            
34
35
     Serial.print(F("    => "));
36
     Serial.println(results.value);                              
37
38
   irrecv.resume();     // Empfang des nächsten Wertes
39
 }
40
 // delay(100);
41
}

mein Ergebnis schaut dann so aus:
> NEU -- NEU
>
>
> BIN => 1111110001111100110000011111110
> OCT => 17617460376
> DEC => 2118017278
> HEX => 7E3E60FE
>   0 => ⸮
>     => 2118017278
> NEU -- NEU
> ... usw..

Mich frustriert es, denn meine Ergebnisse haben keinerlei Ähnlichkeit 
mit dem was Ihr da zeigt: -(.

Mache ich beim Auslesen was Falsch?
oder habe ich meinen Stromzähler nicht richtig eingestellt (PIN habe ich 
eingegeben aktueller Stromverbrauch wird angezeigt in der unteren Zeile 
am Stromzähler)

Die verschiedenen ausgeben habe ich für mich eingebaut da ich noch immer 
auf der Suche bin wie ich das Ergebnis richtig ausgeben muss.


Über Hilfe wäre ich sehr Dankbar.


Gruß Mücke

: Bearbeitet durch User
von Frank K. (fchk)


Lesenswert?

Muecke -. schrieb:
> Hardware ESP32 DEVKIT V1, ISKRA-MT681, TCRT5000
>
> Mein Code schaut so aus:

> #include <IRremote.h>
> int RECV_PIN = 15;
> IRrecv irrecv(RECV_PIN);
> decode_results results;

Diese Funktionen sind höchstwahrscheinlich nur für eine 
Infrarot-Fernbedienung gedacht. Für Deinen Stromzähler passt das nicht 
(anderes Protokoll). Auch Dein Infrarot-Empfangsmodul passt 
höchstwahrscheinlich nicht - das sieht mir eher nach einer 
Reflexlichtschranke aus.

Du musst schon genau das nehmen, was für diese Stromzähler gedacht ist. 
Das alles muss vom Protokoll und der Wellenlänge her passen.

Das Internet enthält eigentlich alles an Informationen, was Du brauchst.

fchk

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.