Announcement: there is an English version of this forum on 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?
Danach hatte ich bei meinem Zähler auch gesucht und dann festgestell das er ASCII sendet.
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: > Es wäre jedenfalls ein Integer mit 48 Bit. kleine Korrektur: ein integer mit 40bit...
Guten Morgen
auch wenn es total unsinnig ist, schonmal mit
('/dev/ttyUSB0', 9600, 7, 'E', 1, timeout=1) versucht?
Kostet ja nix ...
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.
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|
Der abgelesene Zählerstand zu den zwei Datenpaketen 2.8.0: 782kWh 1.8.0: 56kWh
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.
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
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.
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?
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.
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
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
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.