Announcement: there is an English version of this forum on Hallo zusammen, nach einem Jahr Test und deren Ergebnisse sind hier die aktuellen Progamme. Der bisherige Beitrag war: Beitrag "DTZ541 mMe Datenlogger mit ESP (WEB-Sicht)" Das Programm läuft auf den ESP8266 Chip. Was ist neu? Unterstützung mehrerer Zähler, speziell alle, die nach dem SML-Protokoll die Daten liefern. Holley, EMH, Apator, Logarex, Iskra und allen die den SML Standard unterstützen. Auch die AS1440, E640 und ISKRA MT174 werden unterstützt, wenn das entspechende sketch übertragen wird. Allerdings brauchen diese unbedingt eine Infrarot Sendediode am StromLog. Anbei die dementsprechenden Programme. Für alle Module, wie z.B. WEMOS muss im Setup der Serial.swap() aktiviert werden. Die white List und der Schaltplan ist hier zu finden https://zaehlerinfo.de Anbei sind die Arduinodateien und die Serverscripts. Um das Filesystem einzubinden, was unbedingt gemacht werden muss, finden sie unter ESP8266 LittleFS Data Upload. Einfach mal googeln ;-) Warum? Naja... Arduino ist ein offenes System ;-) allerdings alles wieder ohne Datenverschlüsselung! Gruß infozaehler.de und Peter
Angehängte Dateien:
-
homeassiover.jpg
42 KB
Hallo zusammen, hier eine neue Version des StromLogs 3.9. - Anzeige der Minusleistung für LogaRex LK13 (ab BJ 2019) ergänzt - JSON script Unterstützung ergänzt - Unterstützung des Home Assistant https://www.home-assistant.io/ Beschreibungen sind hier: https://infozaehler.de/dtztecdiscr.html Gruß infozaehler.de oder einfach nur Peter
:
Bearbeitet durch User
Hochinteressant, aber anderswo lese ich, dass man "intelligenten" Zählern auch was senden muss und nicht nur empfangen kann - hier sehe ich in den Schaltplänen aber nur einen Fototransistor zum Empfang!? Ich selbst habe da keine Erfahrung, mein Zähler ist dumm und sendet nur S0-Impulse. Trotzdem frage ich mich, wie zukunftssicher dieses Projekt ist, wenn die Senderichtung fehlt.
Dieter R. schrieb: > Hochinteressant, aber anderswo lese ich, dass man "intelligenten" > Zählern auch was senden muss und nicht nur empfangen kann - hier sehe > ich in den Schaltplänen aber nur einen Fototransistor zum Empfang!? > > Ich selbst habe da keine Erfahrung, mein Zähler ist dumm und sendet nur > S0-Impulse. Trotzdem frage ich mich, wie zukunftssicher dieses Projekt > ist, wenn die Senderichtung fehlt. Jupp, das ist eine gute Frage, bzw. wenn man das Messstellenbetriebsgesetz kennt, dann löst sich das auf ;-) Alle neu verbauten Zähler müssen mindestens mME oder iMS sein. Die Messstellenbetreiber sind verpflichtet bis 2032 Zähler auszutauschen, wenn diese nicht den neuen Anforderungen entsprechen. Diese sind: - alle 1...2,3, Sekunden sendet der Zähler per push den aktuellen Stand, plus Zusatzdaten, nach Eingabe einer PIN. Die werden nur dekodiert und an irgendeine Datenbank gesendet. Entweder die Eigene oder eben meinen Service ;-) Also braucht man keine Sendediode, weil der Zähler sendet von sich selbst alle paar Sekunden das Protokoll. Allerdings ist die Schaltung auch für den pull-Betrieb ausgelegt. Nur ist das Programm nur im ersten Betrag enthalten. Also der AS1440 z.B. benötigt eine Sendediode. Schaltplan kann ich veröffentlichen, wenn Bedarf besteht. Gruß Peter
:
Bearbeitet durch User
Beitrag #7065099 wurde von einem Moderator gelöscht.
Sinnerklärer schrieb im Beitrag #7065099:
> Gibts einen bestimmten (Hobby) oder unbestimmten (Kontrollfreak) Grund?
Schon mal auf die Strompreise geguckt?
Da rechnet es schnell, wenn man weiß, wo irgendetwas versickert. Hast du
schon mal deine Grundlast angeguckt und überlegt, was da alles läuft?
Die einfache Antwort könnte sein: "Weil ich's kann"
Peter R. schrieb: > Gruß infozaehler.de oder einfach nur Peter Hallo einfach nur Peter :-) Danke für die Infos! Das würde mir als Bastelprojekt auch reizen! Frage wegen ESP: Nutzt du die Espressif IDE? Weil wenn ich mir Arduino anschaue gibt es dort keine strings.h etc obwohl die Sourcen auf .ino lauten. Zudem: Würdest du einen Beispielcode teilen bei dem der ESP einfach die optische Schnittstelle ausliest und per WiFi versendet? ggf mit decodierung von 1.8.0 und 2.8.0 sowie 16.7.0 für die Momentanverbrauchsanzeige? PS: deine WebSite nutzt SSL und das Zertifikat ist ungültig! Damit würdest du bei Google auf den hintersten Platz landen und man würde dich nicht finden. Grüße Jens Gesendet von meinem iPhone 13 Pro via Tapatalk
:
Bearbeitet durch User
Kurze Frage: Du schreibst: "The meter transmit its data per UV-light continuously every 1..60 seconds. Our UV optocoupler receive this UV light and exchange it for a serial stream"... Ist das wirklich UV? Ich meine es ist IR!
Jens K. schrieb: > Kurze Frage: > > Du schreibst: "The meter transmit its data per UV-light continuously > every 1..60 seconds. Our UV optocoupler receive this UV light and > exchange it for a serial stream"... > > Ist das wirklich UV? Ich meine es ist IR! Ja, sorry.. das ist InfraRot ;-) Muss ich den Text überarbeiten. Übrigens, der Code ist hier im Beitrag weiter oben enthalten. Programmiert mit Arduino. LittleFS, WiFiManager und NTPClient muss mit eingebunden werden. Ist in den Bibliotheken bei Arduino zu finden und muss eingebunden werden. Gruß Peter
:
Bearbeitet durch User
Hallo Peter, Dein Projekt ist das, was ich benötige. Fast: Ich möchte die Daten dazu verwenden, eine Wärmepumpe für Warmwasser so zusteuern, dass sie dann, wenn meine Photovoltaikanlage überschüssige Energie an das EVU liefert, in den Super-Modus schaltet und den Wassertank auf eine höhere Temperatur bring. Die Wärmepumpe braucht nur über einen Relaiskontakt angesteuert zu werden. Ich brauche dafür die Info von meinem Smart-Meter (Logarex LK13), ob und wie viel Energie an das EVU abgegeben wird. Meine Frage: liefert mein Smart-Meter im Standard-Modus (nur ein IR-Empfänger) eine Info über die ans EVU abgegebene (negative) Energie. Oder ist es dazu notwendig die IR-Schnittstelle mit einen Sender zu versehen. Danke und Grüße Heiner
Heiner K. schrieb: > Oder ist es dazu notwendig die IR-Schnittstelle mit einen Sender zu > versehen. Hallo Heiner, nein, du brauchst wahrscheinlich keine IR-Sendediode. Wenn dein Logarex ein LK13BE80xxxx und nicht älter als BJ 2019 ist, dann sendet der automatisch alle paar Sekunden die internen Werte. Das kannst du rausbekommen, wenn du mit der Handykamera raufguckst (Umgebung abdunkeln). Dann siehts man blinken. Die momentane Leistungswerte sendet der Zähler aber erst, wenn das erweiterte Protokoll mit INFO on eingeschaltet wurde. Dazu brauchst du die PIN zum Freischalten. Die bekommt man vom Netzbetreiber. Dann ist dein Vorhaben möglich. Das sieht im Protokoll so aus (wenn negativ, steht ein "-" davor): ********andere Werte ******* 1-0:16.7.0*255(000123*W) 1-0:32.7.0*255(223.0*V) 1-0:52.7.0*255(240.1*V) 1-0:72.7.0*255(229.9*V) 1-0:31.7.0*255(021.45*A) 1-0:51.7.0*255(001.31*A) 1-0:71.7.0*255(004.03*A) ******** weitere Werte ***** ABER: Die Logarex haben ein Problem mit der Helligkeit der IR-Diode. Die lässt im Laufe der Zeit nach. Dann muss der Lesekopf empfindlicher gemacht werden. Das erreicht man mit der Veränderung zweier Widerstände. Als optimal hat sich bewährt, am Emitter des 4,7 k und am Kollektor des BCxyz 1,2 k anzuschließen. Allerdings musste ich bei einem Zähler sogar mal 22 k einlöten. In dem hier veröffentlichten Programm ist noch nicht die JSON-Erweiterung eingebunden und es noch ein BUG mit dem Minus drin. Kommt später noch. Gruß Peter
"Mein" Zähler liefert im 2s Rhythmus ohne Pin und Anregung sowohl bezogene als auch gelieferte Arbeit - allerdings nur volle kWh ohne Nachkommastellen. Das dürfte für deine Anwendung zu ungenau sein. Mit Pin und ohne Anregung kommen angeblich 4 Nachkommastellen.
Peter R. schrieb: > In dem hier veröffentlichten Programm ist noch nicht die > JSON-Erweiterung eingebunden und es noch ein BUG mit dem Minus drin. > Kommt später noch. Ohh sorry, die aktuelle Version habe ich doch schon ober weiter veröffentlicht ;-) Also ist der BUG weg und JSON Erweiterung schon drinne. Gruß Peter
Georg G. schrieb: > "Mein" Zähler liefert im 2s Rhythmus ohne Pin und Anregung sowohl > bezogene als auch gelieferte Arbeit - allerdings nur volle kWh ohne > Nachkommastellen. Das dürfte für deine Anwendung zu ungenau sein. Mit > Pin und ohne Anregung kommen angeblich 4 Nachkommastellen. Richtig. Im Normalzustand kommt nur die beiden Zählerstände in kWh ohne Kommastellen und Zusatzdaten raus. Nach Einschalten von INFO on kommen die Zählerstände mit 4 Nachkommastellen, die momentane Leistung und je nach Netzbetreiber weitere Werte Spannung, Strom usw. raus. Hier mal ein komplettes Protokoll, eines freigeschalteten Zählers: /LOG5LK13BE803049 1-0:96.1.0*255(001LOG0064800017) 1-0:1.8.0*255(000956.4392*kWh) 1-0:1.8.1*255(000816.0000*kWh) 1-0:1.8.2*255(000354.4392*kWh) 1-0:2.8.0*255(000531.8322*kWh) 1-0:16.7.0*255(000123*W) 1-0:32.7.0*255(223.0*V) 1-0:52.7.0*255(240.1*V) 1-0:72.7.0*255(229.9*V) 1-0:31.7.0*255(021.45*A) 1-0:51.7.0*255(001.31*A) 1-0:71.7.0*255(004.03*A) 1-0:81.7.1*255(000*deg) 1-0:81.7.2*255(000*deg) 1-0:81.7.4*255(000*deg) 1-0:81.7.15*255(000*deg) 1-0:81.7.26*255(000*deg) 1-0:14.7.0*255(48.9*Hz) 1-0:1.8.0*96(00000.0*kWh) 1-0:1.8.0*97(00000.0*kWh) 1-0:1.8.0*98(00000.0*kWh) 1-0:1.8.0*99(00000.0*kWh) 1-0:1.8.0*100(00000.4*kWh) 1-0:0.2.0*255(ver.03,EF8C,20170504) 1-0:96.90.2*255(0C69) 1-0:97.97.0*255(00000000) ! Gruß Peter
Peter R. schrieb: > nein, du brauchst wahrscheinlich keine IR-Sendediode. Wenn dein Logarex > ein LK13BE80xxxx und nicht älter als BJ 2019 ist, dann sendet der > automatisch alle paar Sekunden die internen Werte. Das kannst du > rausbekommen, wenn du mit der Handykamera raufguckst (Umgebung > abdunkeln). Dann siehts man blinken. Mist, der Zähler ist von 2018 und in der Handykamera blink nichts. Was kann ich da machen? Grüße Heiner
Heiner K. schrieb: > Was kann ich da machen? anderes Handy oder Digitalkamera probieren. Manche (guten) Kameras haben IR Filter hinter der Linse.
Georg G. schrieb: > anderes Handy oder Digitalkamera probieren. Manche (guten) Kameras haben > IR Filter hinter der Linse. Danke für den Tipp. Bei einer anderen Kamera blinkt's. Ist das Protokoll bei älteren LK13BE80xxxx, hier KL13BE803039, anders? Grüße Heiner
Heiner K. schrieb: > Ist das Protokoll bei älteren LK13BE80xxxx, hier KL13BE803039, anders? also, wenn der von alleine blinkt, denke ich, sendet der auch das Protokoll ;-) Ich weis nicht, welche Module du schon hast? Also irgendein ESP8266 Modul (WEMOS, WIFI Kit8 o.ä.) nehmen. Das Programm mit JSON Erweiterung raufspielen. Lesekopf basteln (geht auch ohne MAX485). Den Kollektor per Widerstandsteiler (wegen Pegelwandlung auf 3,3V) an RxD anschließen. Bei einigen Modulen ist der Serial0 durch USB-Anschluss belegt, dann in der Setup-Routine folgenden Code nach Serial.begin(9600,SERIAL_8N1) einfügen: Serial.swap(); // set serial pins on 13(RX) and 15(TX) und damit RxD auf einen anderen PIN legen. Mehr Infos hier: http://stefanfrings.de/esp8266/ Mit dem Handy ESP-WLAN suchen und verbinden. Dein WLAN-Daten eingeben und speichern. Dann die IP des ESP suchen -> wenn gefunden (ggf. im Router gucken) Dann die IP im Browser eingeben... dann müsstest du schon etwas sehen. Was alles rauskommt, an Daten, siehst du wenn im Browser eingibst: DEINEIP/allData Man kann auch das Rohprotokoll ausgeben lassen, aber dann braucht man einen Server, der das entgegennimmt und speichert (zur Not nimm meinen: infozaehler.de/json2server.php). Einzustellen bei den Einstellungen. Für das Rohprotokoll sind keine Logindaten nötig. Geht ohne ;-) DEINEIP/sendProtocols Nachgucken dann hier: https://infozaehler.de/logJSONProt.txt Das Rohprotokoll steckt in der Variable "buffer" und ist mit BASE64 codiert. Decode mit: https://base64.guru/converter/decode/ascii Gruß Peter
:
Bearbeitet durch User
Ich habe das Teil auch gerade nachgebaut und im Testbetrieb mit 4 AA Zellen betrieben - nach ca. 30 Std. waren die Batterien leer :-( In einem eigenen Projekt hatte ich beim ESP den sleep Modus verwendet und konnte trotz 5 Minuten wake-up eine Laufzeit von 4 Wochen erreichen... Evtl. könnte man hier auch noch etwas Energie sparen?
Sven schrieb: > Evtl. könnte man hier auch noch etwas Energie sparen? Tja, ausgelegt ist das Projekt mit 5V Netzteil. Wenn das über Batterien realisiert werden soll, gibt es einige Herausforderungen: - der Lesekopf wird statisch mit 5V versorgt. Stromschlucker 1 - der StromLog sendet alle 15 min die Daten, also muss der rechtzeitig aktiviert werden. Stromschlucker 2 - einen Zugriff auf den ESP ist in dem Sleep-Modus wahrscheinlich schwierig -> nicht getestet und man kann nicht den aktuellen Verbrauch sehen. möglicher Ansatz: - WakeUp rechtzeitig vor dem Senden. Läuft die Softwareuhr dann noch? - Spannung für den Lesekopf zuschalten. Machbar mit Pin vom ESP. - warten bis ein komplettes Protokoll empfangen wurde. Wie viele sind nötig? (beim ersten wird die Schnittstellengeschwindigkeit identifiziert. Danach der Zählertyp und dann die Daten. Das kann ein paar Sekunden dauern) - Daten senden und wieder zurück in den Sleep-Modus Wäre eine Option... aber nach einer doch nicht allzu langen Zeit sind die Batterien leer gesaugt. Und die dann alle 2,3..5 oder X Monate zu wechseln? Wird schwierig. Dafür saugt der ESP leider zu viel Strom. Gruß Peter
>Wäre eine Option... aber nach einer doch nicht allzu langen Zeit sind
die Batterien leer gesaugt.
Ja, das ist richtig, sollte bei mir ja auch nur eine Übergangslösung
sein. 30 Std. finde ich überraschend wenig, aber erscheint logisch nach
deinen Ausführungen.
Danke für dein praktische Projekt.
Mangels vorhandener Bauteile habe ich mir die Lesekopfplatine + Magnet
bei ebay für 12€ besorgt (Platine TTL IR Lesekopf Lese-schreib-Kopf
Volkszähler Smartmeter Stromzeller PCB). Der Magnet passt genau in ein
30er Installationsrohr.
Sven schrieb: > Ja, das ist richtig, sollte bei mir ja auch nur eine Übergangslösung > sein. 30 Std. finde ich überraschend wenig, aber erscheint logisch nach > deinen Ausführungen. Wenn du einen Elektriker kennst, der kann eine Steckdose im Zählerschrank einbauen. Dann hat die Batterielösung ausgedient ;-) Ich habe hier noch andere ESPs für Temperaturen und sowas am laufen. Da sind Akkus verbaut mit Solarzelle. Die funktionieren von Februar bis November gut durch. Aber Dezember und Januar reicht die Sonne nicht aus und ich stecke ein Netzteil ran. Der ESP braucht beim Senden bis zu 500mA. Das ist schon nicht gerade wenig, ist aber im Vergleich zu anderen Verbrauchern im Haushalt ist das noch wenig. Einen kWh Verbrauch des ESPs habe ich noch keine auswertbaren Daten. Das könnte ich aber mit den Testzählern in der Werkstatt mal ausprobieren. Da hängen ja ein paar rum ;-) Einfach mal den Verbrauch damit testen... gute Idee ;-) Gruß Peter
Hallo zusammen, hier ist ein Link zum Stromverbrauch aus dem Netz des StromLog. In meiner Werkstatt hängt ein LogaRex LK13BE80XXX, wo nur das Netzteil des StromLog dranne ist. Damit kann man den Verbrauch des StromLog einsehen. Benutzer: StromLog Passwort: StromLog Anmelden kann man sich hier: https://infozaehler.de/meinzaehler.php Nach der Anmeldung bleibt man, wenn die Cookies nicht gelöscht werden, einen Monat eingeloggt. Gruß Peter
Hallo Peter, ist es richtig, dass nach einem Reset (oder power fail) Nutzer-Id- und Daten-Server- Einstellungen verloren gehen?
Sven schrieb: > Hallo Peter, > ist es richtig, dass nach einem Reset (oder power fail) Nutzer-Id- und > Daten-Server- Einstellungen verloren gehen? Nein, die Daten werden im internen Dateisystem gespeichert und werden nach dem Reset oder Spannungsausfall wieder eingelesen. Dafür ist die class configDTZ implementiert. Wenn das nicht funktioniert, dann ist das Filesystem nicht richtig installiert! Wie das gemacht wird steht hier: https://arduino-esp8266.readthedocs.io/en/latest/filesystem.html Gruß Peter
Hi, ich habe gelesen Du hast den MT691 bei Dir implementiert. Habe Dein Sketch getestet, bekomme aber nur den Gesamtverbrauch. Kann der Zähler nicht mehr? habe schon das I-Net kreuz und Quer gelesen bin aber nicht schlüssig geworden. Gruß Stefan
Stefan M. schrieb: > Hi, > > ich habe gelesen Du hast den MT691 bei Dir implementiert. > Habe Dein Sketch getestet, bekomme aber nur den Gesamtverbrauch. > Kann der Zähler nicht mehr? > habe schon das I-Net kreuz und Quer gelesen bin aber nicht schlüssig > geworden. > > Gruß > Stefan Hallo Stefan, Es kann sein, dass der Zähler nicht auf INFO on per Pin freigeschaltet wurde. Dann sendet der nur den Zählerstand ohne kommastellen. Auch die Leistung wird nicht ausgegeben. Also Pin vom netzBetreiber besorgen und mit Taschenlampe INFO on einstellen. Dann kommt auch die momentane Leistung raus. Gruß Peter
Hi, Verdammt! Ich dachte wenn da Info steht ist Info aktiv. Fehlanzeige! Erst als ich das Ding beblinkt hatte und mit der Pin befröhlicht hatte. Kamen dann die Daten :-) Man Man Man. Daaanke! Ganzen Tag mit zerspielt^^ Wäre es möglich nur den Teil Deines Skripts zu bekommen, der den MT691 ausliest. Ohne das ganze Drumrum. Du kennst Dein Skript ja sicher in und auswendig, dann muss ich das nicht erst auseinanderpflücken. Und könnte den Part in mein Standarddatensammelskript übernehmen. Danke & Gruß Stefan
Hi, Schön, dass du die Ursache identifizieren konntest ;-) Also, der StromLog beinhaltet zwei Protokolle. SML und S0, beim ersten Start wird nach der Zählerkennung gesucht... Oder besser gesagt, nach den Protokolltypen und bei der aktuellen Version, noch die Schnittstellengeschwindigkeit. Der MT961 sendet mit SML 8n1 9600 und das S0 wird ignoriert. Also, aus der Rechenbelastung ist das nicht mehr wichtig, dass zu trennen. Und gerade das SML Protokoll ist rechenintensiver als S0. Und sorry... Das jetzt zu trennen, ändert nichts, zumal beide Protokolldekodierungen teilweise gleiche Funktionen nutzen. Also, überall, wo S0 steht, kann nach Prüfung gelöscht werden... Und natürlich deren Aufruf. Bei den Unteraufrufen ist mit Vorsicht zu agieren. Sorry... Ich werde die beiden Versionen / Protokolle nicht trennen, weil ich mit einem einzigen Script soviele Zähler, wie möglich unterstützen will. Es ist einfacher, nur ein Script aktuell zu halten, als viele unterschiedliche Versionen. Gruß Peter
Hi Peter, kein Problem, ich schaue mir das mal an und pflücke ein wenig dran rum. Danke für Deine Hilfe soweit und die genialen Vorgaben an denen ich mich bedienen kann :-) Gruß Stefan
Hallo Stefan,
das bekommst du schon hin ;-) und ich meine natürlich auch den MT691.
Übrigens, das mit meiner Bezeichnung "S0" (Protokoll) stimmt nicht ganz
mit der Normung überein. Ich habe das nur so genannt. In Wirklichkeit
gibt es zwei Protokolle:
- das SML "Smart Meter Language" wird hexadezimal übertragen
- und das nach IEC 62056-21 (was ich einfacher halber S0 bezeichne)
Dieses übertragt die Daten im menschlesbaren Format, so wie ich das vom
LogaRex schon gepostet habe.
Hier das Protokoll des ISKRA MT691 (SML, 8N1, 9600):
1B1B1B1B01010101
76
05 000343C5
62 00
62 00
72
63 0101
76
01
01
05 00011697
0B 0A0149534B00045EC391
72
62 01
65 000114EB
62 01
63 5F1C
00
76
05 000343C6
62 00
62 00
72
63 0701
77
01
0B 0A0149534B00045EC39107
01
00
620AFFFF
72
62 01
65 000114EB
75
7707 01 00 60 32 01 01 01 01 01 01 04 49534B 01
7707 01 00 60 01 00 FF 01 01 01 01 0B 0A0149534B00045EC391 01
7707 01 00 01 08 00 FF 65 00082D04 01 62 1E 52 FF 62 00 01
7707 01 00 02 08 00 FF 01 01 62 1E 52 FF 63 01A1 01
7707 01 00 10 07 00 FF 01 01 62 1B 52 00 52 FF 01 01 01 63 1543
00
76
05 000343C7
62 00
62 00
72
63 0201
71
01
63 9A39
00
000000
1B1B1B1B1A
03
6B9F
Gruß Peter
Hi Peter, wenn Du mir jetzt noch verraten könntest in welchen Bytes die KWh und die aktuellen Watt liegen. Ich hatte erst die Vermutung, das es sich hier um die Bytes ohne Space handeln könnte, kam aber nicht auf schlüssige Ergebnisse. 7707 01 00 60 32 01 01 01 01 01 01 04 49534B 01 7707 01 00 60 01 00 FF 01 01 01 01 0B 0A0149534B00045EC391 01 7707 01 00 01 08 00 FF 65 00082D04 01 62 1E 52 FF 62 00 01 7707 01 00 02 08 00 FF 01 01 62 1E 52 FF 63 01A1 01 7707 01 00 10 07 00 FF 01 01 62 1B 52 00 52 FF 01 01 01 63 1543 Danke Stefan
Stefan M. schrieb: > 7707 01 00 01 08 00 FF 65 00082D04 01 62 1E 52 FF 62 00 01 Also das ist so zu lesen: 77 -> Liste mit 7 Einträgen 07 -> Wert mit 6 Einträgen, hier die OBIS Kennzeichnung 01 00 01 08 00 FF -> Kennzeichnung für Bezug 65 -> Status: Wert unsigniert (uint) mit 4 Stellen 00 06 2D 04 -> Wert (keine Ahnung was der aussagt= meist ist der 0) 01 -> Werte-Zeit: hier 0 62 1E -> uint mit einem Wert -> Das ist die Einheit 52 FF -> int mit -1 -> das ist der Scaler für den Zahlenwert -> also mal 10^-1 62 00 -> uint mit Wert 0 -> das ist die Zahl für den hier OBIS Kennzeichnung (Das ist der eigentliche Wert = Zahl mal Scaler mal Einheit) 01 -> Wertsignatur -> hier 0 OBIS-Kennzeichnungen gibt es sehr viele, aber für Stromzähler im Haushalt sind die überschaulich: 1.8.0 Bezug tariflos 1.8.1 Bezug Tarif 1 1.8.X Bezug Tarif X (X ist eine Zahl von 1-9) 2.8.0 Einspeisung Tariflos 2.8.X Einspeisung Tarif X ( X = 1-9) 10.7.0 momentane Leistung Alle weiteren OBIS kannste in der strings.h im Programm-Code nachschauen oder googeln ;-) Gruß Peter
:
Bearbeitet durch User
Hi, ich verstehe es nicht, Verdammt! Dein Beispiel 7707 01 00 01 08 00 FF 65 00082D04 01 62 1E 52 FF 62 00 01 hier meine Daten, irgendwie länger?!? 7707 01 00 01 08 00 ff 65 001c0104 01 62 1e 52 ff 65 05 60 c4 b8 01 Der Zähler steht hier bei 9022 Die aktuelle Leistung --> 77070100100700ff habe ich auch schon sind die beiden markierten Bytes 77 07 01 00 10 07 00 ff 01 01 62 1b 52 00 53|00 c3|01 01 01 63 77 6e Ich blicke es nicht. Vielleicht das Thema mit Wald und Bäumen und so. Danke soweit Stefan
Stefan M. schrieb: > hier meine Daten, irgendwie länger?!? > 7707 01 00 01 08 00 ff 65 001c0104 01 62 1e 52 ff 65 05 60 c4 b8 01 > Der Zähler steht hier bei 9022 > > Die aktuelle Leistung --> 77070100100700ff > habe ich auch schon sind die beiden markierten Bytes > 77 07 01 00 10 07 00 ff 01 01 62 1b 52 00 53|00 c3|01 01 01 63 77 6e Das ist auch nicht ganz easy ;-) Das Protokoll hat einige Kodierungen. Das ist auch der Grund, warum deiner länger ist. Das Byte, was vor dem Zahlenwert kommt sind die ersten 4 bit der Typ des Wertes und die nächsten 4 bit die Länge des Wertes. 7(X) => 7 ist ein Listenelement und X ist immer die Länge 0(X) => 0 ist nicht definiert (offen für alle Werte) und wird für Hersteller- Zählernummer verwendet 5(X) => 5 ist Zahlenwert signiert, also Plus- oder Minuswert 6(X) => 6 ist Zahlenwert unsigniert, also nur Pluswerte Beispiel, dein Zählerstand: 62 1e = 6(2) 6 unsigniert,(2) Länge, inkl. Kennzeichnungsbyte (62 1e sind zwei Werte) und 1e -> Code für W/h 52 FF = 5(2) 5 signiert mit FF -> also -1, das ist der Skaler 10^-1, als mal 0,1 65 05 60 c4 b8 = 6(5wer Länge) -> (hex)05 60 c4 b8 ->(dez)90227896 Und jetzt zusammen: 90227896 mal 0,1 = 9022789,6 W/h -> durch 1000 für kW/h = 9022,7896 kWh Und die Leistung ist: Einheit 1b = W, Scaler = 0, Wert (hex)00 c3-(dez)195 macht zusammen 195 mal 1 mal Einheit W = 195 W Achso, noch was. Mein Testzähler ist nagelneu und hat deshalb 0 W/h noch ;-) Gruß Peter
:
Bearbeitet durch User
Danke Peter, hätte aber auch selbst drauf kommen können. Nun habe ich eine Kombi aus Deiner und der hier -->https://github.com/akabza/ESP8266_SML was eigenes gebaut. Daaaanke noch einmal Stefan
Hallo zusammen,
jetzt habe ich ein Protokoll des Zählers Holley DTZ541 mit BJ 2018
bekommen. Dieser konnte mit der normalen Software nicht ausgelesen
werden, weil der Hersteller in seiner Firmware ein Bug in der CRC16
Berechnung drin hat.
Nach einer Analyse habe ich die Software entsprechend angepasst.
In der CRC16 Berechnung ist zu ändern:
- CRC StartValue ist 0x0000 (SML Standard ist 0xffff)
- OutputValue XOR ist 0x0000 (SML Standard ist 0xffff)
- Im Holley 2018 Protokoll sind die CRC16 Bytes vertauscht. Also erst
kommt das MSB und dann das LSB (Standard ist LSB, MSB)
Mit folgenden Ergänzungen kann nun auch der Holley Bj 2018, das
Protokoll ausgelesen werden. In der Funktion "void decodeDataSML()"
einfügen/bzw austauschen:
#define HLY2018
.......
#ifdef HLY2018
crc_ccitt = refUint(crc,16)^0x0000; // reflected CRC-output and
finish it with xor by 0x0000 HLY 2018
#else
crc_ccitt = refUint(crc,16)^0xffff; // reflected CRC-output and
finish it with xor by 0xffff
#endif
.......
#ifdef HLY2018
uint16_t check_crc = dataDTZ[pointerEOT+1]; // load the first value
of crc HLY2018
check_crc <<= 8; // do it to a MSB
check_crc |= dataDTZ[pointerEOT+2]; // add the lower part
HLY2018
#else
uint16_t check_crc = dataDTZ[pointerEOT+2]; // load the first value
of crc correct SML
check_crc <<= 8; // do it to a MSB
check_crc |= dataDTZ[pointerEOT+1]; // add the lower part
#endif
.......
#ifdef HLY2018
crc = 0x0000; // set crc to begin by 0x0000 HLY2018
#else
crc = 0xFFFF; // set crc to begin by 0xffff
#endif
Gruß Peter
Hallo Peter, ich versuche schon seit längerem, mehr oder weniger erfolglos, meinen PV-Zähler ISKRA MT681 auszulesen. Die zum Teil älteren Code-Beispiele, die ich in der Vergangenheit gefunden habe, konnten selten überzeugen. Mit deinem DTZ-Logger hast du nicht nur ein "frisches" Programm geliefert, sondern es auch komfortabel ausgestattet - Wifi-Manager zum einloggen, LittleFS zum abspeichern, Datenbankanbindung. Alle Achtung !!! Daumen hoch !!! Ich habe deine zuletzt veröffentliche Version 3.91 vom 9.5.2022 runter geladen und versucht zu verstehen und anzupasssen. Zum Auslesen benutze ich einen "Hichi IR ttl". Zu meiner Schande hat sich bis jetzt nicht der gewünschte Erfolg eingestellt. Das Fabrikat ISKRA wird zwar erkannt, aber dann bekomme ich keine weiteren Daten. Meine Fragen an dich wären: Müsste der MT681 von deinem Programm erkannt werden und wärst du event. bereit eine aktualisiertere Version deines Programms zu veröffentlichen. Mit freundlichen Grüßen Klaus
Hallo Klaus, Danke für die Blumen ;-) Also der MT681 müsste eigentlich funktionieren, weil dieser das SML nach FNN Lastenheft unterstützt. Es kann sein, dass der MT681 mit 64 bit die Daten liefert. Das wird mit der Version 3.91 noch nicht vollständig unterstützt. Die neuere Version habe ich noch nicht veröffentlich. Die hat jetzt auch OTA (Firmware-update) drin. Wenn du eine LED am Anschluss IO14 dran hast, dann blinkt diese immer kurz auf, wenn ein Protokoll sauber empfangen wird. Du kannst diese auch auf einen anderen Ausgang umlegen mit: #define LED 14 (14 ist der Ausgang) Beim Einwählen ins WLAN blinkt diese auch 30 sek mit ca.0,5 Hz. Was für ein ESP kommt zur Anwendung? Wenn der ein USB-Anschluss hat, muss die serielle Schnittstelle auf die zweite umgestellt werden, und dann an diesen Eingang den Lesekopf ran hängen ( Serial.swap(); // set serial pins on 13(RX) and 15(TX) if it nessecary, for WEMOS or other modules). Ich habe mit einem "Hichi IR wifi" getestet und funktioniert. Der läuft nur mit dem neuen Release 4.0x nicht mehr, wegen zu wenig Speicher. Aber der darin verbaute Lesekopf ist der Gleiche, wie deiner. Wenn der bei dir blinkt, einfach mal in der Adresszeile eingeben: DEINEIP/sendProtocols Als Serveradresse muss drin stehen: infozaehler.de/json2server.php Dann kann ich mir das Roh-Protokoll anschauen und dir auch zusenden. Auch testen kann ich das Protokoll dann. Gruß Peter
Hallo Peter, vielen Dank für deine schnelle Antwort. - ich habe einige ESP12/32 zu verfügung und hätte bei zwei Hardwareschnittstellen lieber einen ESP32 eingesetzt. Um aber dein Programm ohne Softwareänderungen einsetzen zu können habe ich mich für das Feather-HUZZAH-Board von Adafruit entschieden. Der Grund sind nicht nur die kompakten Boardabmessungen, sondern auch der verbaute LIPO-Laderegler und der dazugehörige Batterieanschluß. Immer wenn ich eine Schaltung habe die zum einen auch bei Spannungsausfall weiterlaufen soll, oder an die externe Module angeschlossen werden sollen, die vom Stromverbrauch her gepuffert werden müssen, entscheide ich mich für Feather-Huzzah oder den Wemos-LOLIN32. Der IR-Empfänger ist sicherlich nicht der große Stromfresser. Anders siehts z.B. bei einem SIM800-GSM-Modul aus mit Spitzenströmen bis zu 2A. (Sicher ist sicher) - Für die zweite Schnittstelle habe ich folgende Zeile eingefügt: #include <SoftwareSerial.h> #define RXD2 13 // (GPIO13)/MOSI) // #define TXD2 12 // (GPIO12)/MISO // (Hat bisher immer funktioniert) - Die LED 14 blinkt, wie von dir beschrieben, regelmässig kurz auf. Rufe ich den StromLog-Status auf, steht unter Protocol errors meistens so etwas wie 100%. Der Aufruf von 'http://192.168.178.36/sendProtocols'; bringt folgende Meldung: '10 RAW Protocols will be send to server now.' Ich zweifel allerdings daran, dass irgendetwas sinnvolles übertragen wurde. - Bevor ich jetzt laut um Hilfe rufe schaue ich erstmal nach, was ich denn wohl sonst so noch verbockt haben könnte. Ich melde mich (Versprochen !)
Klaus B. schrieb: > Die LED 14 blinkt, wie von dir beschrieben, regelmässig kurz auf. > Rufe ich den StromLog-Status auf, steht unter Protocol errors meistens > so etwas wie 100%. Hallo Klaus, dieses Verhalten zeigt, dass die Prüfsumme des Zähler-Protokolls nicht mit der errechneten übereinstimmt. Und wenn die Prüfsumme nicht stimmt, werden die darin enthaltenen Werte nicht genutzt / verworfen. Kurzer Trick um die Werte zu sehen: // if(check_crc == crc_ccitt){ // compare crc-strings readValuesOBIS(); //} Nehme diese if-Anweisung raus, so dass readValuesOBIS(); immer aufgerufen wird. Dann sind wahrscheinlich Werte da. Wenn die sogar stimmen, dann liegt das Problem in der CRC-Berechnung. Gruß Peter
Peter R. schrieb: > Kurzer Trick um die Werte zu sehen: > // if(check_crc == crc_ccitt){ // compare crc-strings > readValuesOBIS(); > //} Sorry, richtig ist es so: //**************** debug end **************************************** // if(check_crc == crc_ccitt){ // compare crc-strings <- auskommentieren readValuesOBIS(); //************** protokoll debug only ****************/ if(sendProtocols > 0){ send2dbasePOST(sendProtokollDebug(),false); //debug sendProtocols --; } //************** protokoll debug end *****************/ // } // <- auskommentieren else { errorCounter ++; // meterManufractur = 0; } Dann funktioniert auch das senden des Roh-Protokolls ohne CRC-Prüfung. Gruß Peter
:
Bearbeitet durch User
Allenfalls wuerde es Sinn machen den Stromverbrauch selbst zu messen wie mit aufwndigen Tricks die bestehenden Zaehler auszulesen. Ich kenne jemanden bei einer grossen Liegenschaftsverwaltung, die lesen die Stromzaehler mit einer SPS aus... Ein Verbrauchsmesschip kostet ein paar Taler und ist selbst Low Power.
Hallo 'Flachtroll', sicherlich könnte man den Stromverbrauch in der Zuleitung selber messen. Wenn ich allerdings möchte, dass sich meine Messwerte mit denen meines Energieversorgers zum Jahresende decken, dann ist die beste Lösung wenn wir beide auf die gleiche Messeinrichtung (nämlich den installierten Zähler) zurückgreifen. Und um an diese Messwerte zu kommen muss ich sie zwangsläufig auslesen. - Ziel dieses Forums ist es ja nicht einen Ersatz für die vielen existierenden, kommerziellen Lösungen zu finden, sondern 'verstehen zu wollen'. 'Verstehen wollen' ist aber oftmals ein mühsehliger Prozess, dem sich viele nicht aussetzen wollen und stattdessen auf eine Fertiglösung zurück greifen. Eine Liegenschaftsverwaltung hat da eben ganz eindeutig andere Prioritäten. - Ich möchte einfach nur meinen erzeugten PV-Strom mit meinen Kauf- und Verkaufs-Strom in relation setzen. Dazu muss ich, zumindest für einen längeren Zeitraum, messen, protokollieren und wenn möglich visualisieren, immer in der Hoffnung dass sich positive Effekte für mein Verbrauchsverhalten ergeben. - Da ich ja für alle neuen Denkansätze offen bin, hast du mich mit dem Hinweis auf einen 'Low-Power-Verbrauchsmesschip' neugierig gemacht. Vielleicht hast du ja einen entsprechenden Link zur hand. Gruß Klaus
Ja, der Link waere : ADE7758 Das ist ein ganze Familie. Sin die modernen installierten Zaehler denn dafuer gemacht, sie selbst auszulesen ? Also mit eigener Schnittstelle fuer den Benutzer ? Fuer dessen Haussystem Mein Kollege von der Immobilienverwaltung hatte diese drehenden Zaehler, die hatten einen Reflektor pro Umgang. den hat er mit einer SPS gezaehlt. Die Lichtschranke alleine zug 20mA, plus natuerlich die SPS. Keine Siemens Logo, sondern eine dickere.
Angehängte Dateien:
Peter R. schrieb: > > Dann funktioniert auch das senden des Roh-Protokolls ohne CRC-Prüfung. > Hallo Peter, - RICHTIG VERMUTET - Nachdem ich die von dir vorgeschlagenen Änderungen und die für den HLY 2018 eingefügt hatte, wurden alle Werte auf der HTML-Seite korrekt angezeigt. Allerdings immer noch mit 100% Protocol Errors (wohl wg. fehlender Prüfsumme). - Ein anderes Problem wurde bereits unter Beitrag "Re: Digitale Stromzähler auslesen und in DB speichern" beschrieben. Solange der ESP läuft kann ich unter 'Einstellungen' meine vorher eingegebenen Daten abrufen. Nach einem Reset geht's wieder neu los. Ich habe versucht unter meinem Arbeitsverzeichnis einen Unterordner \data anzulegen und von dort die 'config.ini' mit den entsprechenden Inhalten fertig hochzuladen. Bisher ohne Erfolg. Was mache ich falsch ??? Soweit für heute Gruß Klaus
Klaus B. schrieb: > Ich habe versucht unter meinem Arbeitsverzeichnis einen Unterordner > \data anzulegen und von dort die 'config.ini' mit den entsprechenden > Inhalten fertig hochzuladen. Bisher ohne Erfolg. Hallo Klaus, das kann vielleicht am Speicher des ESPs liegen. Die ich nutze haben 2MB. Bei 1MB habe ich das getestet und es funktioniert das Dateisystem nur, wenn kein OTA installiert wird. Also es gibt keinen Fehler beim Kompilieren, aber danach werden keine Daten gespeichert. Es gibt auch welche mit 512kB, da kann ich mir vorstellen, dass da kein Filesystem mehr raufpasst. Getestet habe ich das aber nicht. Gruß Peter
Hallo Peter, Ich lesen diesen Thread hier schon seit einigen Wochen mit und wollte mich bei Dir für die super Arbeit und Zeit bedanken, die Du in die Entwicklung dieser Software gesteckt hast! Hier kurz meine Geschichte und damit vielleicht ein paar Anregungen, wie man die Software an seine eigenen Bedürfnisse anpassen kann... Nachdem vor einigen Monaten unsere alten Ferraris-Stromzähler gegen DTZ541 ausgetauscht wurden, suchte ich nach einer Möglichkeit, die Daten auszulesen und in meiner HomeAssistant-Instanz aufzubereiten. Ich wohne im Dachgeschoss (3.OG) eines Mehrfamilienhauses, WLAN reicht leider nicht bis in den Keller und LAN ziehen ist auch keine Alternative, also musste ich mir etwas anderes einfallen lassen. Nach ein paar Recherchen, zu Möglichkeiten der kabellosen Datenübertragung, bin ich bei LoRa gelandet. Also flux 2 HelTec WiFi LoRa 32 (V2.1)-Boards bestellt und losgebastelt. Vorteile dieser Boards sind: - ESP32 - LoRa + WLan + BT - OLED - Batterie-Anschluss (inkl. integrierter Ladeelektronik) Ein Board wird als "Lesegerät/Decoder/LoRa-Client" eingesetzt. Aus Peter's Code hab ich mir dazu die relevanten Teile rausgefischt, die ich zum Auslesen und Auswerten meiner Zählerdaten benötige. Als Lesekopf kommt ein TRCT5000 IR-Sensor zum Einsatz. Da ich keine Möglichkeit habe, das Board über ein Netzteil zu betreiben, setze ich dort einen 3000mAh-LiPo als Stromquelle ein. Das Board startet alle 3 Minuten aus dem Deepsleep, aktiviert über GPIO den TRCT5000 und prüft den aktuellen Akkustand. Anschliessend werden die empfangenen SML-Daten ausgewertet und aufbereitet, d.h. die Daten werden inklusive das aktuellen AkkuStandes zu einem String zusammengepackt, encoded und via LoRa in den Äther geschubst. Danach wird der ESP wieder in den DeepSleep geschickt. Das Display zeigt nur beim ersten Start alle relevanten Daten an (LoRa-Verbindungsstatus, ausgelesen Werte des Stromzählers + AkkuStand). Bei den nachfolgenden WakeUps aus dem Deepsleep bleibt das Display inaktiv. Zu Beginn dieses Projektes nutzte ich das zweite Heltec-Board in meiner Wohnung als "Gateway". Es empfing die LoRa-Daten des Senders und schickte sie via WLan an meinen MQTT-Server, von wo aus meine HomeAssistant-Instanz die Daten ziehen und aufbereiten konnte. Mittlerweile setze ich einen WisGate Edge Lite 2 LoRaWan-Indoor-Gateway ein, der die Daten empfängt und an meinen MQTT-Server weiterleitet. Natürlich kann man dort auch andere Gateways und Systeme nutzen (zB TTN, AWS IoT o.ä.), allerdings wollte ich zwingend meine Daten ohne externe Dienste oder "Clouds" zur Verfügung haben. Unterm Strich bin ich sehr zufrieden mit der Umsetzung. Die Daten kommen stabil an, trotz der 3 Betondecken und mehreren Wänden zwischen Sender und Gateway (mehr als 98% der Datenpakete kommen mit mehr als -100 dbm (RSSI) an). LoRa ist extrem energiesparend und kann im Freifeld unter guten Bedingungen auch mal schnell ein paar Kilometer überbrücken. Indoor schaut das natürlich ein bisschen anders aus, ist aber immer noch um Welten besser als WLan. Der 3000mAh Akku im Sender hält ca. 1 Monat durch, und da ich den AkkuStand im HomeAssistant auswerte, kann ich, wenn nötig, bei meinem nächsten Gang in den Keller einfach eine Powerbank mitnehmen, die den Akku wieder lädt. Soweit zu meiner Umsetzung und nochmals vielen Dank an Peter ;) Grüße Thomas
Hallo Thomas, würdest Du uns Deinen Code vorstellen bzw. zur Verfügung stellen? Grüße MAT
Hallo Peter, dein Projekt fand ich für das Auslesen von Zählern so gut gelöst das ich mir eine Version gekauft habe. Installation war einfach und das Gerät funktioniert. Da ich im Mietshaus wohne, bleibt nur eine Batterielösung. Diverse Hinweise gab es hier, wie man den Stromverbrauch reduzieren kann. Basteln liegt mir sowie das Programmieren. Arduino IDE installiert. Code aus dem Forum hier kompiliert. Testupload mit dem USB flasher und ESP auf dieses Modul https://www.amazon.de/gp/product/B09DYGB6FY/ref=ppx_yo_dt_b_asin_image_o00_s01?ie=UTF8&psc=1 Funktioniert, ESP meldet sich mit dem Wifi-Setup. Nun zu deiner Hardware :-) Dein Schaltplan zeigt die Pins RXD TXD GND RST zu finden auch auf dem Board. Direkt verbunden und stromversorgt über USB Powerbank lässt er sich nicht ansprechen. Grüne LED dimmt etwas im Takt und die Rote blinkt schwach. Stört der MAX485 der auf RXD und TXD mit drauf ist oder wo liegt der Haken? PS: Werde ich den Code, der zu einer Stromreduzierung führt, hier posten. USB Tool zur Strommessung und Aufzeichnung ist schon bestellt. Beste Grüße Christian
Die Frage wurde per Email beantwortet. Die Lösung ist: Es müssen alle 5 Pins vom Board mit dem Flasher verbunden werden. Flasher(10Kontakte) Peter's Board(5Kontakte) RXD-RXD TXD-TXD IO0-IO0 RST-RST GND-GND Nun geht es an die Optimierung. Update Folgt
Christian B. schrieb: > Update Folgt nun bin ich mal gespannt! Mein erster Versuch zum Auslesen meines Zählers verlief nicht so positiv..... MAT
Angehängte Dateien:
-
2022-09-11_17h48_09.png
520 KB
Also es funktioniert ja schon wie oben geschrieben(Collider) Ich habe folgenden Zähler, siehe Bild. Ist schon ein neueres Model von Logarex da, mit Taste zur Pin Eingabe. Info auf ON gestellt und ohne den Lesekopf(ohne Folie) extra zu positionieren drauf. Die Anzeige INFO im Display sagt nicht das die Funktion INFO ON ist !!! Erst wenn ihr die Wattzahl in Echtzeit seht, ist INFO ON. Daten kommen.
Ich habe einen Iskra MT174... von 2012 und bin nicht ganz sicher, was und ob ich etwas auslesen kann. Dieser Zähler hat noch nicht einmal ne PIN .... Werde deswegen erst einmal das ganze verschieben...
Matthias S. schrieb: > Ich habe einen Iskra MT174... von 2012 und bin nicht ganz sicher, was > und ob ich etwas auslesen kann. Hallo Matthias, den ISKRA kann man auch auslesen. Allerdings sendet der nicht von alleine und muss per IR-LED mit dem Befehl /?! (300baud 7E1) angesprochen werden. Danach gibt er seine Kennung aus, gefolgt von den Werten. Eine PIN hat der noch nicht drin und spukt alle Werte ohne PIN aus. Im ersten Beitrag hier ist das Programm für den ISKRA MT174 bei. Am besten den Lesekopf TTL besorgen und per Widerstandsteiler an RX und TX anschließen. Das Programm fragt dann per Senden den Zähler ab und Empfängt die Daten. Gruß Peter
:
Bearbeitet durch User
Eine Pin gibt es nicht weil wohl die Richtlinien erst später auf "Datenschutz" umschwenkten. Beim ISKR 174 werden die Einstellungen mit den beiden Tasten Orange und Blau gemacht. Wobei die Orange plombiert sein kann(Reset Fähigkeit) Auszug aus der Anleitung: Oben rechts in der Ecke des Zählers befindet sich eine optische Schnittstelle, die der Norm IEC 62056- 21 entspricht. Sie ist zum lokalen Setzen der Zählerparameter und zur Datenablesung bestimmt. Bild 15: Optische Schnittstelle Verwendet werden das Kommunikationsprotokoll nach IEC 62056-21, Mode C, und die serielle asynchrone Kommunikation. Möglich sind alle Datenübertragungsgeschwindigkeiten von 300 Bit/s bis 19.200 Bit/s, der standardmäßig eingestellte Wert beträgt 9.600 Übertragungsgeschwindigkeit verwendeten optischen Sonde unter 9.600 Bit/s liegt, ist die Übertragungsgeschwindigkeit der optischen Schnittstelle auf die Geschwindigkeit der optischen Sonde zu setzen. Die Wellenlänge des Schnittstelle beträgt 660 nm, die Lichtstärke im aktiven Zustand ist minimal 1 mW/sr. Vielleicht kann Peter was dazu sagen, ob sein Code das Lesen/Dekodieren kann. Hab mich mit dem Code noch nicht intensiv beschäftigt. Grundsätzlich sollte alles, was digital am ESP ankommt, dekodiert werden können. Eventuell ist die Baudrate der optischen Schnittstelle nicht passend. edit: sollte schneller schreiben :-)
:
Bearbeitet durch User
Da ich dran arbeite: Da die RTC noch im DEEP-SLEEP läuft kann der ESP intern aufgeweckt werden //Deep-sleep for 5 seconds, and then wake up system_deep_sleep_instant(5000*1000); Da kann man ansetzen
Hi, ich muss noch einmal mit meinem MT691 um die Ecke kommen. Seitdem ich meine Guerilla PV aktive habe, kommt es teils zum merkwürdigen Verbräuchen jenseits der 60kW. Also habe ich mir das Protokoll in den Momenten angeschaut. In den Fällen steht plötzlich ein 'FF' hinter dem TL-Field?!? Könnte mir ja vorstellen, dass wenn der Wert gegen Null geht, dass der den Scaler auf 'FF' setzt, der steht aber weiter auf '00'. @Peter Kannst Du da vielleicht Klarheit schaffen? Hier mal ein Beispiel: 1b1b1b1b010101017605139766886200620072630101760101050687ccd80b0a0149534b 00043e9318726201650687cf97620163287e00760513976689620062007263070177010b 0a0149534b00043e9318070100620affff726201650687cf977477070100603201010101 01010449534b0177070100600100ff010101010b0a0149534b00043e9318017707010001 0800ff65001d190401621e52fe65059377430177070100100700ff0101621b520053ff7c 01010163c4c10076051397668a62006200726302017101634d3700001b1b1b1b1a01b100 Konkret geht es dann ja hier darum: 77 070100100700ff 01 01 621b 5200 --> Stelle 3+4 Scaler '00' 53ff7c --> Stelle 1+2 TL signed Integer16 und dann das merkwürdige 'ff' 01 Danke im Voraus. Gruß Peff
:
Bearbeitet durch User
Bin ein Stück weiter gekommen, bei meinem MT691 :-) Sobald man einspeist dreht der Zähler quasi um. Bedeutet: wenn man 100W eingespeist werden gibt er 127-100 --> 27W per SML bei Type-Length-Value 52 aus. wenn man 150W eingespeist werden gibt er 32.767 -150 --> 32.617W per SML bei Type-Length-Value 53 aus. Auf dem Display wird die korrekte Einspeisung ausgegeben, allerdings ohne Vorzeichen, so dass man raten darf ob man einspeist oder nicht. Nun ist die Frage wie man aus dem SML herausließt, ob man einspeist oder nicht. Das einige was mir bisher aufgefallen ist, dass im Bereich des Gesamtverbrauchs sich bei Einspeisung etwas ändert. ohne Einspeisung 77070100010800ff 6500 1c11 0401 77070100010800ff 6500 1c01 0401 mit Einspeisung 77070100010800ff 6500 1d19 0401 Beispiel Peter 77070100010800FF 6500 082D 0401 aus dem c wird ein d und aus der 1 eine 9 Aber ob ich mich darauf verlassen kann ist ziemlich unklar, da nirgends dokumentiert. Zudem in Peters Beispiel von der Zähler der auf '0' steht dort was völlig anders steht. Was die Änderung der 1 zur 0 bei Einspeisung bedeutet ist mir auch unklar. Alles in allem noch keine Lösung aber vielleicht ein Ansatz Bin für alle Infos zu haben. Gruß Peff
Beitrag #7194496 wurde vom Autor gelöscht.
Angehängte Dateien:
-
2022-09-17_09h43_04.png
320 KB
Stefan M. schrieb: > > > Auf dem Display wird die korrekte Einspeisung ausgegeben, allerdings > ohne Vorzeichen, so dass man raten darf ob man einspeist oder nicht. > > > Bin für alle Infos zu haben. > > Gruß > Peff Gibt das +A und -A im Display nicht die Energierichtung an? Gruß Christian
:
Bearbeitet durch User
Ah! Das kann sein. Checke ich heute mal. Genau da baumelte das Kabel vom IR drüber^^ Bleibt die Frage offen, wie man es aus dem SML ausliest. Um dann die korrekte Leistung umzurechnen.
Stefan M. schrieb: > > Bleibt die Frage offen, wie man es aus dem SML ausliest. > Um dann die korrekte Leistung umzurechnen. Hab mich selber mit dem SML Protokoll noch nicht befasst, aber hier ist eine gute Info Seite. https://www.msxfaq.de/sonst/bastelbude/smartmeter_d0_sml_protokoll.htm Gruß Christian
Hallo zusammen, der eigentliche Wert setzt sich immer durch das Type-Length-Field (Byte) zusammen. Das erste Byte bezeichnet den Typ des Zahlenwertes, Liste(7),Boolean(4),Signiert(5) und Unsigniert(6) gefolgt von der Länge des Wertes. 52 -> signiert mit einem Byte (die 2 zählt auch das Type-Length-Field mit) 65 -> unsigniert mit 4 Bytes (32 bit) Es gibt unterschiedliche Anwendungen bei den Zählerherstellern. - es wird ein definiertes Type-Length-Field verwendet, was sich nie ändert, also fest programmiert ist. - das Typ-length-Field ändert sich in Abhängigkeit vom Zahlenwert. Also, um so größer der Wert wird, umso höher wird auch die Länge (2->3->5->9). Die Länge passt sich dynamisch an. Bei der momentanen Leistung liefern die Zähler ein signierten Wert. Ist dieser im positiven Bereich, dann wird Strom bezogen. Ist dieser Wert negativ, dann wird Strom eingespeist. So die Theorie ;-) Es gibt aber Fehler in der Firmware bei einigen Zählern (DZG) die senden z.B. den signierten Wert mit der Bezeichnung unsigniert :-O Und auch die Umsetzung bei der Leistung ist nicht immer gleich. Manche senden Bezug und Einspeisung mit unterschiedlichen Register, bzw. nur als positiven Wert ohne Vorzeichen, unabhängig von der Energieflussrichtung. Nicht gut, aber ist so. Gruß Peter
Stefan M. schrieb: > Konkret geht es dann ja hier darum: > 77 > 070100100700ff > 01 > 01 > 621b > 5200 --> Stelle 3+4 Scaler '00' > 53ff7c --> Stelle 1+2 TL signed Integer16 und dann das merkwürdige 'ff' > 01 Also 53 ff7c -> bedeuted signierter Wert mit 16 bit ffc7 und dezimal: -57 also der Zähler speist gerade (-)57 Watt in das Netz. Gruß Peter
Angehängte Dateien:
-
isk_mk.JPG
57 KB
Stefan M. schrieb: > Hier mal ein Beispiel: > 1b1b1b1b010101017605139766886200620072630101760101050687ccd80b0a0149534b > 00043e9318726201650687cf97620163287e00760513976689620062007263070177010b > 0a0149534b00043e9318070100620affff726201650687cf977477070100603201010101 > 01010449534b0177070100600100ff010101010b0a0149534b00043e9318017707010001 > 0800ff65001d190401621e52fe65059377430177070100100700ff0101621b520053ff7c > 01010163c4c10076051397668a62006200726302017101634d3700001b1b1b1b1a01b100 Hier die angezeigten Werte zum Protokoll. Der Zähler speist gerade ein. Siehe Bild ;-) Gruß Peter
Oh man, der Wald und die die Bäunme... Stefan M. schrieb: > 53ff7c --> Stelle 1+2 TL signed Integer16 und dann das merkwürdige 'ff' Schreibe selber 'signed' hin und schnalle es nicht^^ Danke für's aufwecken!
Hallo zusammen, hier ist das erste Utility für den StromLog. Leistung auslesen und schalten. Beitrag "Schaltsteckdose für StromLog ESP" Gruß Peter
Angehängte Dateien:
-
akku_verlauf.png
59 KB -
ha.png
66 KB
Hallo Matthias, Sorry, hat nen bisschen länger gedauert, hab aktuell nen Haufen Arbeit... Natürlich teile ich meinen Code gerne, bitte rollt aber nicht mit den Auge, C/C++ ist nicht meine liebste Sprache. Es gibt garantiert viele Stellen, die besser geschrieben sein könnten... ;) Den Großteil des Codes habe ich aus Peter's DTZ_Logger_Open übernommen und auf meine Bedürfnisse angepasst. Zusätzlich eingebaut sind die Funktionen für die Akku-Überwachung, das Senden der Daten an den Lora-Gateway und die Funktionen für die Ausgaben auf dem Display. Noch ein paar Screenshots aus meiner HomeAssistant-Instanz und einem Grafana-Board mit dem Akkuverbrauch zwischen zwei "Ladezyklen". Der 3000mAh-Akku hält aktuell ca. 35 Tage, bis er von der vollen Akkuladung auf ~3.6V abfällt, das finde ich vollkommen akzeptabel in anbetracht der Tatsache, dass alle 180 Sekunden eine Messung durchgeführt und übertragen wird. Grüße Thomas
Hallo zusammen, ich habe die Software für den StromLog komplett überarbeitet und neu strukturiert. Nach dem immer länger werdenden Bandwurm des Codes war das notwendig. In der global.h kann jetzt der Zählertyp selektiert werden. OTA ist mit implementiert und die Oberfläche ist auch neu überarbeitet. Weiterhin ist es erforderlich das Dateisystem littleFS einzubinden, um die Einstellungen speichern zu können. Die Datei "config.ini" muss in dem Unterordner "data" gespeichert werden. Allerdings, wie vorher, alles ohne Datenverschlüsselung. Gruß Peter
:
Bearbeitet durch User
Hallo, ich versuche seid einiger Zeit ebenfalls meinen digitalen Stromzähler über die IR-Schnittstelle auszulesen. Komme aber leider bei der Empfangshardware nicht weiter. Könntest du vielleicht noch mal die Schaltung teilen mit der du die IR Signale empfängst? Irgendwie scheinen (bei mir) sowohl Fototransistor/Phototransistor Fotodiode/Photodiode zu langsam zu sein für 96008N1. Meine Bauteile sind: Fotodiode, PD333-3C/H0/L2, für Tageslicht und Infrarot Fototransistor PT333-3C; Tageslicht und Infrarot Vielen Dank
Lars schrieb: > ich versuche seid einiger Zeit ebenfalls meinen digitalen Stromzähler > über die IR-Schnittstelle auszulesen. Hallo, um welchen Zählertyp handelt es sich? Es gibt Typen, die sind durch den Netzbetreiber per PIN verriegelt. Typ, Hersteller und Baujahr. Ansonsten müsste das eigentlich gehen, egal welche LED oder Transistor. So schnell ist 9600 8N1 nicht ;-) Gruß Peter
Lars schrieb: > Irgendwie scheinen (bei mir) sowohl Fototransistor/Phototransistor > Fotodiode/Photodiode zu langsam zu sein für 96008N1. Mit einem Smartfone sieht man ob Daten gesendet werden.
Rüdiger B. schrieb: > Lars schrieb: >> Irgendwie scheinen (bei mir) sowohl Fototransistor/Phototransistor >> Fotodiode/Photodiode zu langsam zu sein für 96008N1. Mit dem BPW40 geht es aber durchaus, ich benutze bei meinem ESY Q3MA einen (höher empfindlichen) SFH-309 FA4 am Front-IR-Sender. > > Mit einem Smartfone sieht man ob Daten gesendet werden. Das Apfelfon meiner Frau hat ein IR-Filter, da sieht man nichts. Aber mit meinem alten S*msung S2 geht es. Kann man auch mit der IR-TV-Fernbedienung testen, man muss dann nicht in den Keller;-)
Angehängte Dateien:
-
optoSendReceive.png
4,7 KB
Lars schrieb: > Komme aber leider bei der Empfangshardware nicht weiter. Könntest du > vielleicht noch mal die Schaltung teilen mit der du die IR Signale > empfängst? Anbei die Schaltung. Die kann senden und empfangen. Bei mME (Zähler ab 2018) braucht man nur den Empfangsteil. Gruß Peter
Thomas schrieb: > Natürlich teile ich meinen Code gerne, bitte rollt aber nicht mit den > Auge, C/C++ ist nicht meine liebste Sprache. Es gibt garantiert viele > Stellen, die besser geschrieben sein könnten... ;) > > Zusätzlich eingebaut sind die Funktionen für die Akku-Überwachung, das > Senden der Daten an den Lora-Gateway und die Funktionen für die Ausgaben > auf dem Display. > Hi Thomas, ich beschäftige mich gerade mit LoRA und dem TTN-Netzwerk, weil mein Stromzähler so ungünstig platziert ist, dass er seine Daten nicht über WLAN weitergeben kann. Eine Frage: üblicherweise werden die Daten per Gateway in die TTN-Cloud geschoben und von dort dann wieder zurück geschickt. Du hast anscheinend den Network-Server vom TTN-Stack_V3 lokal auf dem Gateway und hast die Daten dadurch nur lokal (private). Wird dann dafür auch ein Applikation-Server gebraucht und dafür ein Payload-Decoder? Wie schaut dieser Decoder für Dein Device aus? Sind für das Device spezielle Angaben bei der Registrierung notwendig (Activation Mode, LoRaWAN Version, etc...). Danke schon mal für Deine Rückmeldung. Gruß, Herbert
Hallo, vielen Dank für die zahlreichen Antworten auf meine Frage. Mein Zähler ist ein DTZ541. Und den PIN hatte ich bereits besorgt und eingegeben. Trotzdem vielen Dank für den Tipp. :-) Nach der Eingabe konnte ich auch tatsächlich mit der Smartphone Kamera die IR-LED Daten senden sehen. Ich werde es mal mit einem Nachbau der Schaltung probieren. Vielen Dank! Vielen Grüße
Angehängte Dateien:
-
oscilloscope_IR.png
11 MB
Hallo, ich habe nun die Schaltung einmal nachgebaut. Leider hatte ich nicht genau die Widerstandswerte die in der Schaltung angegeben waren. 850ohm & 1,2k ohm sind bei mir jeweils ein 1K Widerstand. der 4k7 wurde bei mit zu einen 4K4. Raus gekommen ist dieses Bild. Channel1 ist die Empfangsdiode Channel2 ist die Sendediode Nun hätte ich noch mal zwei Fragen: - Wodurch kommt der Versatz zwischen der fallenden Flanke Channel2 und der steigenden Flanke Channel1? - Das Signal der Sendediode ist ja "quasi" invertiert. Ist das richtig so wenn ich damit das serielle Signal 9600 8N1 empfangen möchte? Vielen Dank & Viele Grüße
Angehängte Dateien:
-
receive.bmp
1,4 MB
Lars schrieb: > 850ohm & 1,2k ohm sind bei mir jeweils ein 1K Widerstand. > der 4k7 wurde bei mit zu einen 4K4. Hallo, die Widerstände sind nicht das Problem. Abweichungen verschieben nur den Arbeitspunkt der Transistoren. Da aber die in Sättigung gehen, ist das nicht tragisch. Das Problem ist: Was ist das für ein Zähler? Sendet der die Daten von selbst? (Push-Betrieb) Oder muss der aufgefordert werden zu senden? (Pull) Was aus dem Zähler rauskommt, sieht in etwa so aus, wie auf dem Bild. Das Diagramm im Beitrag hiervor sieht nach einer Reflexion der Sende-LED aus. Gruß Peter
@Lars: Satte 11 MB für ein Bild mit 2 Wellenlinien. Respekt! https://www.mikrocontroller.net/articles/Bildformate
Hallo zusammen, was mache ich falsch, beim compilieren kommt immer:
1 | warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings] |
2 | |
3 | 376 | int poi=SearchOBIS("/",0);
|
4 | |
5 | ^~~ |
und das an mehreren Stellen?
Jürgen schrieb: > was mache ich falsch, beim compilieren kommt immer: Das ist nur eine Warnung. Es funktioniert trotzdem. Es ist vielleicht nicht ganz sauber programmiert, war aber am einfachsten die Suchfunktion mehrmals mit unterschiedlichen Strings / Chars zu nutzen. Die Funktion SearchOBIS erwartet einen Zeiger auf einen Char[x] mit mehreren Werten, also eigentlich ein String. Das meckert der Compiler an, aber es funktioniert trotzdem. Die Angabe "/" ist ein Konstanter String, welcher selbst aber aus mehreren Chars besteht mit am Ende einer 0x00. Gruß Peter
Ah, perfekt. Vielen Dank für die schnelle Antwort
Thread beobachten
Seitenaufteilung abschalten
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.