|
Anzeige
|
Wärmezähler über optische M-Bus-Schnittstelle auslesen
Gast
#7332179
@matthew_f Hab mir Deine Infos bei Github durchgelesen, weicht die verlinkte mbus-test Variante immer noch vom Original ab? D.h. "init-size 536" ist im Original ein anderer? Bei Dir funktioniert es mit dem SensoStar E, dann muss es eigentlich auch mit meinem SensoStar U gehen. Läuft der run.sh Skript auch mit einem USB-IR Lesekopf? VG Daniel Hallo Daniel, irgendwie habe ich dein Post vorher nicht richtig gelesen, und sehe erst jetzt, dass du Einträge für Energy und Volume hast aber sie sitzen auf 0. Ich hatte am Anfang das gleiche Problem (Beitrag "Re: Wärmezähler über optische M-Bus-Schnittstelle auslesen") und die Lösung war einfach zurück in der Ausgabe zu schauen, weil mehrere Ausgaben/MBus Dekodierungen stattgefunden haben. Das Eintragen-finden macht bei mir das Python Skript automatisch. Ansonsten, wenn das immer noch nicht funktioniert könntest du mein Version von damals as-is ausprobieren. Das habe ich scheinbar angefangen aber nicht zu Ende gemacht (https://github.com/mattfullerton/mbus-test-fork/) - aber ich kann das ergänzen und dann könntest du das run.sh usw. ausprobieren. Aber eigentlich wenn du schon Daten rausbekommst, denke ich nicht, dass du irgendetwas an mbus-test ändern müsstest. Eigentlich sollte ich eher schauen, dass mein Setup noch mit der aktuellster Version läuft. Aber... "never touch a running system", und keine Zeit, usw. Ich bin auch der Meinung, dass es funktionieren musste, solang bei dir im Display die Daten in MW/kW ausgegeben werden (und auch wenn nicht, habe ich keine Ahnung, ob die Daten nicht dann doch noch vollständig über MBus zu erwarten wären). Ich bin zuversichtlich... weil wie gesagt, das gleiche Problem hatte ich auch am Anfang. VG, Matt
Gast
#7333376
Wenn ich den SenoStar mit "verbose level 2" und "COMMANDS 2" abfrage, erhalte ich tatsächlich u.a. die erzeugte Wärmemenge angezeigt: DIF 04 VIF 06 function_field: 00 data_length: 4 data_field: 04 unit: 06 data bytes: 3C 11 00 00 Instantaneous value Energy (kWh) mbus_parse_data_field: DIF 0x04 was decoded using 4 byte integer result: 4412 factor 1.000000 n: 3 neg 0 In diesem Fall sind es tatsächlich 4412 kWh. Weiter unten erscheint es dann 4x hintereinander mit Null Werten: DIF 84 DIFE 20 VIF 06 function_field: 00 data_length: 4 data_field: 04 unit: 06 data bytes: 00 00 00 00 Instantaneous value Energy (kWh) mbus_parse_data_field: DIF 0x84 was decoded using 4 byte integer result: 0 factor 1.000000 n: 3 neg 0 Wie komme ich jetzt an den ersten Output mit der tatsächlichen Wärmemenge? Super, das freut mich! Das aussuchen der Werte mache ich mit Python. Das sind die Zeile hier: https://github.com/mattfullerton/volkszaehler_scripts/blob/main/readHeat/readHeat.py#L10-L28 Das Output von
Gast
#7334337
Danke Dir Matt! Kannst Du mir bitte noch verraten, was ich eingeben muss, damit es auf meinem Raspberry mit mbus-test funktioniert? Bin froh, dass ich mbus-test zum laufen bekommen habe, bin leider kein Experte. Von Python hab ich null Ahnung. Gibt es eine Möglichkeit die Daten per MQTT weiterzugeben? VG Daniel
Gast
#7337313
Matt und @all, ich benötige bitte Eure Unterstützung. Meinen SensoStar U konnte ich optisch (USB IR Lesekopf von Hichi) mit LORUSFREE direkt und fehlerfrei auslesen. Sämtliche Daten werden richtig angezeigt. Für mich als Laien stellt sich jetzt die Frage, wie ich diese Infos nutzen kann, um meinen WMZ 4x am Tag ohne Programmierkenntnisse auszulesen. Ich nutze iobroker und habe hier mehrere Raspberry´s. Gibt es einen Adapter für iobroker, der im Grunde wie Lorusfree ohne besondere Einstellungen funktioniert? Danke Euch! Ich kann dir gerne helfen, die Daten automatisch 4x am Tag auszulesen. Steht eigentlich alles hier: https://github.com/mattfullerton/volkszaehler_scripts/blob/main/readHeat/README.md Aber wir können gern über Zoom oder so reden. Nur ich schicke meine Daten an Volkszähler, was sehr einfach ist (ein URL mit der Wert drin). Mit ioBroker würde ich mich schlau lesen müssen.
Gast
#7337956
Hey ho, erstmal vielen Dank für diesen Thread - das ist super hilfreich. Ich habe auch einen Engelmann Sensor hier - konkret eigentlich einen Metrona Heat C - allerdings scheinbar (?) baugleich zum Engelmann. Mit der Firmware von naseweis bekomme ich auch eine wunderbare Antwort. Nur jetzt habe ich das gleiche Problem, das Thomas auch hatte - wie komme ich von der Binär-Antwort zur Tasmota Definition?
liefert mir den Binär-Blob. Als Definition habe ich aktuell folgendes eingetragen (alles geklaut):
Damit tut Tasmota leider überhaupt nichts, es werden keine Werte ausgewertet. Mit sensor53 d1 sehe ich aber eine Antwort:
Nur was mache ich jetzt mit der Antwort? Ich habe schon versucht im Hex-Editor die aktuellen Zähler-Werte zu finden - nur diese Zahlen finde ich nirgends. Hat jemand eine Idee? Vielen Dank Matthias Hi Matthias, Bei deinem dump kommen die Daten d8 0e 00 00 nach dem Register 04 06. Dann müsste dein Zählerstand 3800 kWh zeigen. Falls ja, solltest du 1,0406uuUUuuUu@1, Ausprobieren. Mit dem tasmota Decoder bin ich aber nicht so vertraut. LGD
Gast
#7339148
Hi, erstmal vielen Dank! Ich habe die Definition einfach mal ausprobiert - damit bekomme ich aber leider auch nur eine 0 zurück :-( Wie bist du denn auf die 3800 gekommen? Der Wert würde exakt stimmen. Wenn ich in der Doku lese, dann bedeutet uuUUuuUu ein unsigned long word. Ich hätte jetzt little-endian vermutet, aber irgendwie sehe ich nur fürs Ende "uu" oder "UU", nie den Mix aus "Uu". d8 0e 00 00 würden 4 Byte entsprechen, also 32 Bit. Im Hex Editor bekomme ich für 32 Bit an dieser Stelle aber 807417956 (big endian 1681399856) angezeigt - das passt auch nicht. Und zur 0 in Tasmota passt es auch nicht. Ich bin verwirrt, irgendwo habe ich einen Denkfehler -.- Ich habe es jetzt auch ein paar Minuten laufen lassen, es hat sich nicht eingefangen, irgendwie bleibt die 0 -.- Viele Grüße Matthias Hi, Hex 0e d8 = dec 3800 06 04 low high low high LGD
Hallo wenn Du Dir mal die ersten 4 Bytes anschaust, wirst du sehen, daß die anders sind als bei dem in meinem Skript verwendeten Sensostar U. Schau Dir mal dieses Dokument an, darin ist - wenn auch für einen anderen Zähler - die Struktur der Daten erklärt. Nimm mal 1,68040468x23uuUUUUUU@1,Energy total,,total,0 ; Total Wärmemenge Das mit den abgezählten Bytes usw. musst du u.U. anpassen. Cheerio Man sieht die Startsequenz (gelb) und danach die 23 zu überspringenden Bytes (blau). Dann kommen die relevanten Daten (rot) Das muss dann mit dem eigenen Dump in Übereinstimmung gebracht werden.
Angehängte Dateien:
Gast
#7345030
Vielen Dank für die vielen Infos :-). Dann probiere ich mal weiter! Matthias
Ich habe einen Allmess Integral-MK UltraMaXX mit dem ich mich wochenlang beschäftigt habe (leider lange ohne Erfolg). Der Volkszähler- ähnliche Lesekopf (UART-Ausgang) hat auf Anhieb an einem Stromzähler funktioniert. Am WMZ leider keine Antwort. Die batteriebetriebenen WMZ müssen mit Energie sparsam umgehen. Das brachte mich auf die Idee die Sendeleistung des Lesekopfes zu reduzieren und den Empfang empfindlicher zu machen. Also den Serienwiderstand der Sendediode von 180 auf 680 Ohm verändert, den Serienwiderstand des Fototransistors von 12k auf 39k. Und nun kann ich mich endlich mit der Antwort beschäftigen... LG
Hallo in die Runde. Selbes Problem hier. Ich habe einen PolluCom E mit Hichi TTL Kopf an einem NodeMCU mit Nicks tasmota_v3 und dem PolluCom Script von Christoph. Auch andere hier gepostete Scripts habe ich getestet - keine Chance. Eventuell habe ich es überlesen: Kann jemand sagen, welche Linse am PolluCom E RX und welche TX ist? Ich habe es natürlich in beide Richtungen versucht, es wäre aber hilfreich hier schonmal Sicherheit zu haben. Anschluss am NodeMCU passt, der Handy-Test funktioniert. Vielen dank für die super Arbeit, die hier bisher geleistet wurde! Hmm, ganz schön fix:
Das bisher erwähnte Auskommentieren von SND_UD 0 (Carsten)
hat hier keine Besserung gebracht. Ich denke, die Wakeup Seequenz wird nicht gesendet. Das siehst Du am Timecode. Probier mal meine Firmware. GrC Mit deiner Firmware vom 09.01. sehe ich keine Aktivität des Kopfes mehr in der Kamera des Handys. Das Script läuft weiterhin zu flott:
VG -T Wegen der Nachfragen zu den PolluCom Zählern hier eine kurze Zusammenfassung meiner Erfahrungen. Auch wenn das nichts neues ist, aber die optische Schnittstelle ist bei den Geräten fürs dauerhafte Auslesen ungeeignet. Der Zähler, mit dem ich viel getestet habe, antwortet beim zyklischen Abfragen nur noch 1-4x dann fällt er wieder in den Tiefschlaf, er lässt sich dann auch nicht mehr mit der MiniCom Software oder Python script auslesen. Nach ca. 24h kann er durch Drücken der Taste wieder für weitere 1-4 Auslesungen aktiviert werden. Ein anderer Zähler dessen Batterie noch „frischer“ ist lässt sich nach wie vor ohne Probleme zyklisch abfragen. (Ist nur die Frage wie lange noch) Es ist nicht unwahrscheinlich, dass wegen geringer Spannung der Batterie das Auslesen irgendwann überhaupt nicht mehr geht. Ein Servomotor oder ähnliches der immer wieder die Taste drückt könnte zumindest beim Auslesen 1x pro Tag helfen den Zähler immer wieder zu aktivieren. Damit würde man bei funktionieren Zählern die Anzahl der Auslesungen geringhalten. Das in der Zwischenzeit etwas abgewandelte scrip für den Sensus Pollucom F, welches bei Zählern mit voller Batterie sehr gut funktioniert habe ich nochmal angehangen. Vielen Dank dafür. Auch mit diesem Script ist die Wake Up Sequence, so sie denn gesendet wird, enorm kurz.
Ich beobachte das hier mal weiter, vielleicht hat ja doch noch jemand eine Idee. Sie mag kurz sein aber sie funktioniert hier bei mir, wenn ich den Teil aus dem Script lösche geht nix mehr. Kopf und PolluCom funktionieren, hiermit konnte ich dem Zähler gerade Daten entlocken: https://forum-raspberrypi.de/forum/thread/57389-sensus-pollucom-e-ueber-pymeterbus-auslesen/?postID=543096#post543096 RX am PolluCom E ist die linke Linse, falls sich das nach mir nochmal jemand fragt. Ich habe jetzt eine Lösung, die für mich funktioniert. Im Heizkreisverteiler hängt ein NodeMCU mit esp-link. Auf einem Linux, das anderswo ohnehin ganztägig läuft, baue ich mit socat eine virtuelle serielle Schnittstelle mit esp-link als Gegenseite. Oben genanntes Python-Script nutzt dann den virtuellen Port um über esp-link mit dem PolluCom E zu kommunizieren. Die Weitergabe der Daten erfolgt dann per MQTT. Hallo zusammen, ich finde den Forom echt toll und habe viel gelernt daraus. Ich kann nun mein WMZ Ultramess C3 von Molline die Verbrauchte Märmemenge mit dem Script abfragen. Doch was überhaupt nicht klappt ist die Auslesung nach einer Periode. Ich habe das Script angepasst das er den WMZ aller drei Stunden mal abfragen soll, doch es passiert einfach nichts. Ich erhalte nur noch im der Console diese Zeichenketten: 16:49:41.548 MQT: tele/tasmota_E3757E/STATE = {"Time":"2023-04-03T16:49:41","Uptime":"0T18:20:25","UptimeSec":66025,"Heap":19,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":1,"POWER":"OFF","Wifi":{"AP":1,"SSId":"FRITZ!Box 6490 2-4","BSSId":"3C:37:12:C7:8A:77","Channel":6,"Mode":"11n","RSSI":56,"Signal":-72,"LinkCount":1,"Downtime":"0T00:00:05"}} 16:49:41.554 MQT: tele/tasmota_E3757E/SENSOR = {"Time":"2023-04-03T16:49:41","WAERME":{"w_total":4711}} Nun meine Frage wie kann ich das Script so einstellen das es, sagen wir mal aller 4 Stunden den Zähler ausliesst? Es muss auch nicht ab Mitternacht passieren. In der Scriptsprache bin ich nicht so vertrraut. Vielen Dank aktuelles Script:
if time%period-1==0 and blk==1 ;one minute after we entered the first loop then blk=0 ; reset the flag endif #readmeter print wakeup start ;set serial protocol ret=sml(-1 1 "2400:8N1") ;send 0x55 for 3 seconds with 8N1 (72x), 2400 baud (wakeup sequence) for wkup 1 72 1 sml(1 1 "55555555555555555555") next print wakeup end wkup=1 print wait for the meter ;wait for the meter to wake up delay(350) ;switch serial protocol sml(-1 1 "2400:8E1") print request data ;set string to send to "105BFE5916" (request data) ;sml(1 1 "6804046853FE5000A116" sml(1 1 "105BFE5916")
Hi, ich versuche auch gerade einen Techem Ultra S3 (sollte auch ein Sharky 775 sein) auszulesen - jedoch ohne Erfolg.
Wird mir nichts angezeigt in Tasmota ;-( Hat noch jemand einen Tipp für mich? Wird doch nicht etwa bei dem Techem Zähler anders sein? Kann meinen Post leider nicht mehr bearbeiten - nutzt der Sharky 775 einen kombinierte IR Diode für Send / Receive? Die Leseköpfe (die ich habe) haben zwei getrennte Dioden - da wird das alignment schon schwierig?
Angehängte Dateien:
Ich verwende den Kopf von Hichi, der hat zwei getrennte Dioden. Das Gehäuse positioniere ich mit dem Kabel nach unten und dann muss ich es bündig an die beiden Erhebungen drücken damit es funktioniert. Dann liegen die beiden Dioden des Lesekopfes links und rechts neben der einen im Zähler. Weil es mir und anderen passiert ist: schaue im Log ob die Aufwachsequenz wirklich so lang ist, wie sie sein sollte (je nach Script im Bereich einiger Sekunden). GrC Hi Carsten und danke für die Tipps! Ist in der Tat ein Problem mit der Positionierung des Lesekopfes! Habe jetzt eine Position leicht versetzt zu einer Seite gefunden, die funktioniert. (Lesekopf ist ein ein Bausatz gewesen, 2 getrennte Dioden, Gehäuse selbst gedruckt, ähnlich wie Hichi) Habe auch nur mal das Plastikgehäuse des Lesekopfes aufgesetzt um mir durch die Löcher der LEDs eine gute Position auszuloten. Gar nicht so einfach! :-/
Hallo Zusammen, ich habe mir als Vorbereitung für einen Wärmepumpeneinbau einen Wärmezähler (gebrauchter Allmess Integral-V Ultralite) zugelegt. Momentan liegt er noch auf meinem Schreibtisch zum testen. Ich möchte zukünftig die Daten mittels Optischer Schnittstelle und einem Hichi Wifi Lesekopf an HomeAssistant senden. Wenn ich das Script von Frank (vielen Dank dafür) benutze, bekomme ich nach dem Speichern einmal Werte geschickt, allerdings passiert dann nix mehr. Ich sehe kein Weakeup oder sonstiges mehr. Lediglich die Statuslogs, die alle 5min gesendet werden. Sollte ich nicht alle x Minuten (abhängig von der Periodenzahl) normalerweise ein Wakeup im Konsolelog sehen? Viele Grüße Che Ok, ich war wohl zu ungeduldig. Das Teil fing erst ab Mitternacht an loszulegen. Danke an die Community für die tolle Arbeit, auch wenn es in diesem Thread recht unübersichtlich wurde. Was der Anzahl an Posts geschuldet ist. Ein Wiki wäre kein Luxus :) Viele Grüße Che Hallo, ich habe auch einen Sensus PolluCom E/S und wollte die Wärme-Menge optisch auslesen. Jetzt lese ich hier aber öfter, dass es bei zu schwachen Batterien oder bei längerer Laufzeit zu Problemen kommt. Wie sind eure Lnagzeit-Erfahrungen? Ich habe mein Konstrukt aus ESP-Link und Docker Container mit Python Script jetzt seit März laufen, Abfrage alle 55 Minuten. Bisher keine Probleme. So richtig langzeit ist das aber natürlich noch nicht. D.h.
Bei mir war nach ca. einem Jahr Ende, kein zyklischen auslesen mehr. (konnte ich bei 2 Zählern feststellen) Vermutlich habe ich am Anfang beim Testen auch wirklich sehr oft ausgelesen. Liegt auch nicht am ESP, gleiches ist auch per USB-IR-Kopf und Python Script festzustellen. Ungefähr 1x am Tag geht es nach vorherigen drücken der Taste noch. Ich habe schon von anderen gehört, dass sie das dann per SwitchBot/FingerBot machen, auch von einem Servo am ESP habe ich schon gelesen, war mir aber bisher zu aufwändig. Die tatsächlichen Zeiten können sich natürlich unterscheiden aber eine wirkliche dauerhafte Lösung scheint mir das Auslesen per IR-Schnittstelle bei diesen Zählern nicht zu sein. Vielen Dank, da der Austausch des WMZ bei leerer Batterie auch ein Kostenfaktor ist, werde ich mich mal nach Alternativen erkundigen und dann vielleicht gleich mit M-BUS on Board.
Was das Script angeht: https://github.com/ostpol/PolluComE, dort stehen die Anpassungen bzgl. Kommunikation zwischen Python und ESP-Link drin. Docker Container ist auch fertig. Disclaimer: Ich bin kein besonders guter Programmierer und auch zu Docker kenne ich nur Basics. Aber irgendwo muss man ja mal anfangen. ;) Befestigung sieht so aus: https://twitter.com/ostpol/status/1634896280202907648?s=12&t=xc7l-nC4po-ngRWAnWqoPw
Hallo, ein PolluCom E war mein erster Wärmemengenzähler. Er lief über M-Bus und wurde von mir zunächst zu oft abgefragt. Ich erfuhr das die Auslesehäufigkeit begrenzt wird, so dass die Mindestlaufzeit erreicht werden kann. Seit über 10 Jahren habe ich zwei Sontex Supercal 539 im Einsatz. Er wird von mir über M-Bus gespeist und somit wird die interne Batterie nicht belastet. Beim Kauf mußte ich extra angeben, das ich über M-Bus speisen möchte. Den 539 gibt es wohl nicht mehr. Heute ist es wohl der Sontex Supercal 739. mfg Klaus Hallo nochmal zusammen. Kann mir jemand bitte helfen zwecks der Dateninterpretation. Ich habe ein WMZ vom Typ Ultramess C3 von Molline. Ich bekomme folgende Daten heraus. 12:59:25.030 : 00 00 00 04 78 3c 9e 36 01 04 06 12:59:25.075 : 85 14 00 00 04 13 1c d6 24 12:59:25.118 : 00 04 2b 00 00 00 00 14 2b 18 12:59:25.161 : 3e 00 00 04 3b 00 00 00 00 12:59:25.203 : 14 3b 39 f3 f6 cf 02 5b 19 12:59:25.246 : 00 02 5f 19 00 02 61 fe ff 02 12:59:25.290 : 23 1f 02 04 6d 2d 2a f3 27 12:59:25.332 : 44 06 e5 07 00 00 44 13 0f 82 12:59:25.378 : 0d 00 42 6c df 2c 01 fd 17 12:59:25.420 : 40 03 fd 0c 05 00 00 84 20 06 12:59:25.463 : 00 00 00 00 c4 20 06 00 00 12:59:25.505 : 00 00 84 30 06 00 00 00 00 12:59:25.553 : c4 30 06 00 00 00 00 7d 16 Leider kann ich nur nur Total energy auslesen mit "04 06". Wie kann ich die anderen Werte wie m³, power, flow und Temp auslesen. Ich habe diese Werte probiert, aber da kommt nichts raus :-( 1,0C14bcd8@100,Total volume,m³,v_total,2 1,0B2Dbcd6@0.01,Current power,W,p_act,0 1,0B3Bbcd6@1000,Current flow,m³/h,F_akt,3 1,0A5Abcd4@10,Flow temp,°C,t_flow,1 1,0A5Ebcd4@10,Return temp,°C,t_return,1 1,0B61bcd6@100,Temp diff,°C,t_diff,2 Vielen Dank toptobias Hallo zusammen, so nach längerem Probieren habe ich es nun rausgefunden um die Daten aus einem Molline Ultramess C3 auszulesen. Hier die Konfiguration: 1,0406uuUUUUUU@1,Total energy,kWh,w_total,0 1,0413bcd8@100,Total volume,m³,v_total,2 1,042Bbcd6@1,Current power,W,p_act,0 1,043Bbcd6@1000,Current flow,l/h,F_akt,3 1,025BuuUU@1,Flow temp,°C,t_flow,2 1,025FuuUU@1,Return temp,°C,t_return,2 1,0261bcd4@10,Temp diff,°K,t_diff,2 1,142Bbcd6@1,Maximum power,W,p_max,0 1,143Bbcd6@1000,Maximum flow,l/h,F_max,3 1,0478bcd8@1,Seriennummer,,serialnum,0 1,0223uuUU@1,Meter days,d,OpDays,0 1,03FD0Cuu@1,Firmware Version,,FW_Version,0
Angehängte Dateien:
Hallo zusammen in diesem wunderbar motivierenden Thread. Ich habe mich so n bisschen drangehängt und das ganze mit einem Sensonic II von ISTA probiert und es hat eigentlich auch ganz gut geklappt. Ich habe das Script von Corny (https://github.com/corny/mbus-esp32) auf einen ESP32 (+Volkszähler-IR-Interface) gespielt, etwas angepasst (hauptsächlich musste die Länge des Antworttelegrams angepasst werden) und die Antwort als JSON per MQTT an Iobroker übermittelt und da mit einem entsprechenden Skript aufgearbeitet. Hat auch alles sehr gut funktioniert, konnte alle 15-16 Minuten auslesen, bei kürzeren Intervall kam einfach keine Antwort. Hatte mir zum Testen eine originalverpackte Sensonic II mbus gekauft, weil ich zu faul war zum Testen immer vor meinem FBH-Verteiler zu sitzen und hab eine mit mbus-Anschluss genommen umd das auch direkt mal zu testen - und auch das hat genauso gut und mit dem gleichen Script funktioniert, lediglich die Aufwecksequenz braucht man nicht senden, auf (Kabel)-Mbus lauscht der Wärmemengenzähler wohl dauerhaft mit. Weiterhin war es extrem wichtig, die Dioden gut vor dem optischen Interface zu platzieren. Davorhalten hat nichts gebracht, da war die Fehlerquote sehr hoch. Mit einem gedruckten Tool hat das dann aber ganz gut funktioniert und hat auch noch gleichzeitig die beiden Dioden gegeneinander abgeschirmt. Das Ganze hat hervorragend funktioniert... SO LANGE ich an meinem Schreibtisch saß. Als ich das Projekt dann an den Zähler meiner Fußbodenheizung anschließend wollte, musste ich leider feststellen, dass scheinbar das optische Interface von meinem Zähler deaktiviert ist. Bei ISTa habe ich aber leider keinen Support ans Telefon bekommen, der davon Ahnung hatte. Angeblich ist der Port bei Mietgeräten immer deaktiviert, wenn man die Fernauslesung von ISTA nicht dazu kauft. Und jetzt die große Frage: Hat irgendjemand eine Idee, wie ich meinen Wärmemengenzähler zum reden bekomme? Die optische Schnittstelle kann ja nichts verstellen, ist ja wirklich nur zum Auslesen und auch genau dafür vorgesehen. Hat jemand zufällig zugriff auf die Montagehandbücher von dem Ding, so dass man mal nachsehen kann, wie die Monteure die optische Schnittstelle freischalten? Hat jemand zufällig shcon mal zugesehen, wie die dinger programmiert werden? Oder kennt jemanden, der sachdienlich weiterhelfen kann? Wäre klasse, wenn der Aufwand jetzt nicht umsonst war. Würde grundsätzlich ja auch das Fernauslesesystem der ISTA kaufen, aber man kann es halt nirgends einbinden und somit ist es nutzlos für mich. Viele Grüße Martin Hallo Martin, ich habe auch ein sensonic II und konnte die erfolgreich auslesen. Auf der optischen Schnittstelle der sensonic II eine spezielle Aufwachsequenz. Ich habe das damals mit Messung der Batteriespannung herausgefunden. Siehe hier: Beitrag "Re: Wärmezähler über optische M-Bus-Schnittstelle auslesen" @carsten12 Hallo, Ich hab letzte Woche den Fernwärmeanschluss bekommen mit dem Sharky 775. Jetzt hab ich versucht, den auszulesen mit dem Hichi Wlan Lesekopf. Das Script ist von Carsten waermezaehler.txt (896 Bytes) vom 23.12.2022. Ich bekomme zwar eine Antwort vom WMZ, aber die ist viel zu kurz, und ergibt auch keine Messwerte. Das Drehen des Kopfes brachte nix. Ich habs mit 2 verschiedenen Firmwares versucht, mit folgendem Ergebnis:
Ich wäre dankbar, wenn jemand eine Idee dazu hätte. Also, ich habs geschafft, hier eine kurze Zusammenfassung: (Ich hab noch die offizielle Kommunikationsbeschreibung des Sharky 775 angehängt) Firmware: tasmota.bin.gz von Carsten v. 09.01.23 (= tasmota12.3.1.bin.gz mit w_delta) (tasmota_V3.bin.gz von Nick 18.12.22 geht bei mir nicht) Script: waermezaehler.txt (889 Bytes) vom 23.12.22 (liest alle 1 bzw 5 min ab und sendet MQTT) oder: das "Mitternachtsscript" von Carsten v. 09.01.2023 (liest nach Mitternacht ab und berechnet Delta zum Vortag = w_delta) Bei 1. Inbetriebnahme muss vermutlich im Script "waermezaehler.txt": sml(1 1 "6804046853FE5000A116" aktiviert werden, um die Datenübertragung zu initieren -> Zähler sendet E5 (Ack) Dann nur noch sml(1 1 "105BFE5916") Befehlszeile: mit "sensor53 d1" kommt folgende Response: danach "sensor53 d0"
Sehr lehrreiche Beiträge. Als interresierter Laie will ich einfach nur danke sagen !! Kann ebenfalls berichten, Sharky 775 kann man mittels HichiTTL und tasmota auslesen. Ein Aspekt den ich trotzdem gerne fokussieren würde, da mich das etwas Zeit gekostet hat .. Die initiale Sequenz welche den Sharky Daten entlockt wird getriggert durch ein sml(1 1 "6804046853FE5000A116") . Dieses muss wohl einmalig nach der Inbetriebnahme passieren .. Bei mir hat das aber nicht auf anhieb funktioniert. Nach vielen hin-und-her und etlichen Fehlversuchen habe ich die Anregung von Thomas probiert und ins waermezaehler.txt -Script von Carsten ein Delay(100) eingehekelt. ..
.. Anschließend wurde Sharky ziemlich gesprächig... ha .. ein Glücksmoment nach vielen Stunden :-) !! Offensichtlich wollte er es etwas gemächlicher angehen und hat eine Pause gebraucht. Die initiale Sequenz kann dann wieder auskommentiert werden. Verwende ein Hichi TTL (Kabel nach unten) mit Wemos D1 mini .. TX-TX RX-RX, firmware tasmota.bin.gz von Carsten v. 09.01.23. Hallo ich habe den CF Echo 2 von Itron und durch die tolle Anleitung hier im Forum habe ich es geschafft und kann den WMZ auslesen und die Daten im HomeAssisstent anzeigen lassen. Nur leider werden ab und zu falsche Daten gesendet, dann werden auf einmal z.B. 50.000 mWh Total Energy gesendet. Hat hier jemand eine Idee woran es liegen könnte bzw ich das Problem beheben kann ? Ich weiß nicht wie ich das Script ändern kann das unschlüssige Werte gar nicht gesendet werden. Ich nutze das Script Waermemengenzaehler_Allmess.txt und habe Tasmota_V3 geflasht. Hallo allerseits, ich versuche vergeblich einen allmess Integral-V Ultralite Ha mit einem Hichi Lesekopf auszulesen. Ich nutze das Skript von Frank (Script_Waermemengenzaehler_Allmess.txt), welches bei Rubinho S. erfolgreich bei dem fast baugleichen WMZ (lediglich ohne HA) läuft. Ich habe mich mit Rubinho auch bereits direkt ausgetauscht und wertvolle Tipps sowie seine funktionierende Tasmota Version zugesendet bekommen. Ich kriege aber absolut keine Daten rein. Der Lesekopf wurde schon in allen erdenklichen, sinnvollen Positionen gedreht. Ich habe auch schon mal etwas Klebeband zwischen Lesekopf und den Dioden platziert, um den Abstand zu vergrößern. Der Lesekopf ist in Ordnung. Das Testskript mit Spiegel empfängt die eigenen Daten. Ich habe inzwischen die Befürchtung, dass die Dioden bei dem WMZ nicht in Ordnung sind, die Batterie zu schwach ist oder die optische Schnittstelle evt. sogar gar nicht aktiviert ist (wenn das überhaupt vom Hersteller vorgesehen ist). Vielleicht hat das Schwarmwissen hier aber auch noch einen entscheidenden Tipp in petto. Hier noch ein paar Zeilen Code aus der Tasmota Konsole nach dem Aufwecken. 22:00:00.315 wakeup start 22:00:03.328 wakeup end 22:00:03.330 wait for the meter 22:00:03.632 request data 22:02:30.849 RSL: STATE = {"Time":"2023-11-30T22:02:30","Uptime":"0T09:10:29","UptimeSec":33029,"Heap":22,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":0,"POWER":"ON","Wifi":{"AP":1,"SSId":"xxx","BSSId":"xxx","Channel":6,"Mode":"11n","RSSI":72,"Signal":-64,"LinkCount":1,"Downtime":"0T00:00:03"}} 22:02:30.855 RSL: SENSOR = {"Time":"2023-11-30T22:02:30","WP_WMZ":{"Energie_total":0.000,"Durchfluss_total":0.00,"Leistung_akt":0.00,"Durchfluss_akt":0.000,"temp_Vorlauf":0.0,"temp_Ruecklauf":0.0,"temp_diff":0.00,"Betriebstage":0}} Schon probiert?: [[https://www.mikrocontroller.net/topic/438972#7348585]] Danke für den Tipp. Habe ich bisher noch nicht gemacht und ich bin mir auch nicht sicher, ob das meine elektrotechnischen Kompetenzen hergeben, da ich mal stark davon ausgehe, dass ich das löten muss? Hast du das bei einem Hichi Lesekopf gemacht oder ist dein Lesekopf ein Eigenbau? Sicher musst du löten (oder jemand der das kann).
Kein Eigenbau. Hichi kompatibel würde ich sagen. Bei meiner Anwendung war ausschlaggebend die IR Sendeleistung zu reduzieren und den Empfänger empfindlicher zu machen. LG @thorsten_n Hi, ich hab das gleiche Problem, dass sporadisch unplausible Werte kommen, im Extremfall "0" oder irgendein Zufallswert. Das liegt vermutlich an dem optischen Interface, bei dem ab und zu Lesefehler auftreten. Wie ich das im Tasmota script beheben kann, hab ich noch nicht herausgefunden, aber ich hab "Hilfssensoren" ins configuration.yaml eingefügt, und mache die Plausibilitätsprüfung dort.
Ist vielleicht nicht besonders elegant programmiert, aber bei mir funktioniert es bisher. Für feedback bin ich dankbar :-) Hallo irgendwie funktioniert es bei mir noch nicht, Habe deinen Code auf meine Namen geändert, weiß nicht ob ich noch was falsch gemacht habe. Aber die Werte von den korrigierten sind gleich dem nicht korrigierten Werten.
Angehängte Dateien:
Hi, ich hab das ganze nochmal simuliert, bei mir funktioniert es: anstatt "sensor.tasmota_wp_wmz_energie_total" hab ich ein Numerisches Eingabefeld zum Testen "input_number.nummer". Der Code:
Angehängte Dateien:
Ich hab die Plausibilitätsprüfung jetzt auch im Tasmota script realisiert: (Ausschnitt) (die Grenze 400 muss eventuell angepasst werden, da Tasmota nach einem Reset eventuell 0 liefert und erst nach der nächsten Ablesung den richtigen Wert, was zu einem grösseren Sprung führen kann)
Oh super das wäre natürlich super wenn ich es direkt im Tasmota Script änder könnte. Allerdings vestehe ich noch nicht genau wo ich dies genau in meinem Script einfügen muss. Hier mein Script
Könntest du mir hier eventuell helfen ?
Beitrag #7573266 wurde von einem Moderator gelöscht.
Hallo zusammen, ich möchte einen Zenner Zelsius C5 Wärmemengenzähler (mit optischer Schnitstelle IRDA/ZVEI) auslesen. Ich nutze einen Wifi Volkszähler/IR-Lesekopf. Ich habe die Firmware tasmota_V3.bin.gz von Nick v. 18.12.22 und das folgende script von carsten vom 23.12.2022. Ich habe alles mögliche versucht (Lesekopf gedreht, Taste am Zähler gedrückt, Lesekopf verschoben). Ich habe nichts selbst kompiliert, lediglich die o.g.Firmware und das skript unverändert genutzt. Hier das script:
Ich bekomme keine Daten. In der console sehe ich folgendes: 13:28:54.152 read meter 13:28:54.153 wakeup start 13:28:57.448 wakeup end 13:28:57.449 wait for the meter 13:28:57.802 request data 13:29:57.046 read meter 13:29:57.047 wakeup start 13:30:00.341 wakeup end 13:30:00.342 wait for the meter 13:30:00.695 request data Was mache ich falsch? Igendein Tipp? Danke schonmal.
Hast du einfach mal einen Tag gewarte ? EWs kann manchmal etwas dauern bis Daten gesendet werden.
Habe es doch zum größten Teil hin bekommen und es werden die Werte in der Console angezeigt allerdings jede Sekunde ist dies so gewollt ? Jetzt bekomme ich die Daten nur nicht an HomeAssistent gesendet. Kann es sein das hierfür noch die user_config_override.h verändert werden muss ? Siehe angehängtes PDF Seite 34 Bin grade im Urlaub, melde mich an Wochenende. Hallo zusammen Aufgrund dieses Beitrages und der zur Verfügung gestellten Infos zum Auslesen der optischen m-bus Schnittstelle habe ich mir einen Allmess Integral-V UltraLite PRO Wärmemengenzähler (aktuell noch im Batteriebetrieb (neue Batterie)) sowie den Lesekopf von Hichi gekauft. An dieser Stelle, vielen Dank für die ganze Vorarbeit und das Teilen der Arbeit. Ich habe darauf die tasmota_V3.bin.gz Firmware aufgespielt und das angehängte Skript aufgespielt und Sensor53 d1 ausgeführt. Leider erhalte ich kaum eine Ausgabe und hoffe, dass jemand eventuell eine Idee hat, woran dies liegen könnte. Die Ausgaben im Anhang habe ich sehr unterschiedlich erhalten, ich erkenne da kein Muster. Für die Unterstützung danke ich im Voraus. Beste Grüsse Morris
Angehängte Dateien:
@thorsten_n Thorsten N. schrieb im Beitrag #7574139:
Im Anhang mein aktuelles Script. Es handelt sich um das modifizierte "Mitternachtsscript" von Carsten v. 09.01.2023 (liest nach Mitternacht ab und berechnet Delta zum Vortag = w_delta) Als Firmware verwende ich tasmota.bin.gz von Carsten v. 09.01.23 Das Sendeintervall stellst du ein bei Tasmota Main Menu - Configuration - Configure Logging - Telemetry Period (in Sekunden) Ich hab dir noch meine Testdatei angehängt (in C), dann kannst du die Korrektur mit einem Online C Compiler Testen.
Beitrag #7576073 wurde von einem Moderator gelöscht.
Also ich habe jetzt 2 Tage gewartet. Aber noch keine Rückmeldung vom Wärmemengenzaehler. Ich bin ratlos. @morris12 Hast du denn schon die Datenübertragung initialisiert mit sml(1 1 "6804046853FE5000A116" ? Die tasmota_V3.bin.gz von Nick hat bei mir auch nicht funktioniert. siehe: Beitrag "Re: Wärmezähler über optische M-Bus-Schnittstelle auslesen" und: Beitrag "Re: Wärmezähler über optische M-Bus-Schnittstelle auslesen" Noch einmal eine grunsätzliche Frage, weiß jemand wie der Lesekopf optimal platziert werden sollte ?Es gibt ja eine helle und dunkle Diode. Beim Wärmemengenzähler scheinen die Dioden übereinander zu liegen. Dann ist ja eigentlich nur die Frageob das Kabel nach rechts gucken sollte oder anders herum.
Angehängte Dateien:
Beim Echo muss das Kabel bei Verwendung des Hichi nach links zeigen.
Angehängte Dateien:
Danke super, und hält der bei euch gut ? Bei mir ist dieser sehr locker, scheint nicht sher magnetisch zu sein. Beim Stromzähler habe ich einen Hichi USB und dieser ist viel fester, wird richtig an den Stromzähler heran gezogen und man muss schon feste ziehen damit dieser wieder ab geht. Frage weil ich mir vorstellen kann das ich deshalb immer mal wieder merkwürdige Werte ausgelesen bekommen. @Walter Danke für die Hinweise, habe ich mittlerweile auch probiert, jedoch erhalte ich dann keine Rückmeldung vom Zähler: 11:39:16.940 read meter 11:39:16.941 wakeup start 11:39:20.232 wakeup end 11:39:20.233 wait for the meter 11:39:20.585 request data Habe dies mit verschiedenen Versionen von Nick und Carsten probiert, auch mit und ohne dem delay(100). Mit der Version von Nick und seinem skript habe ich wenigstens ein paar wenige Ausgaben vom Zähler (gemäss meinem letzten Post) erhalten, zumindest denke ich, dass dies Ausgaben von Zähler sind. Aber auch bei seiner Version/Skript hat sml(1 1 "6804046853FE5000A116" (mit delay(100) nicht gewirkt... Beste Grüsse Morris Also ich hatte mit der Firmware von Nick zuerst auch einen Einzeiler als Antwort:
Beitrag "Re: Wärmezähler über optische M-Bus-Schnittstelle auslesen"
Dann bin ich folgendermassen vorgegangen:
Firmware tasmota.bin.gz von Carsten v. 09.01.23, @Morris So wie ich die Ausgaben oben interpretiere, fragt das Script jede Minute beim Zähler ein Readout an -> sml(1 1 "105BFE5916"). Es kommt auch was zurück. Vermutung .. Die Antwort vom Zähler ist unvollständig, deswegen kann es auch nicht korrekt ausgewertet werden. Weiter oben war die Rede von schwächelnder Batterie. Auch nicht ganz abwägig, die Positionierung des Lesekopfes. Ich würde meinen, die Sequenz sml(1 1 "6804046853FE5000A116") hat den Zähler grundsätzlich initialisiert und kann deswegen auskommentiert werden. .. weitere Erfahrungen .. Bei meinem Sharky gehe ich ähnlich vor, Readout zyklisch alle 5 min, allerdings antwortet der Zähler viel seltener. Nach einem erfolgreichem Auslesen (Werte plausibel) dauert es eben ca. 110 Min. bis das nächste mal ein erfolgreicher Readout stattfindet. Dazwischen kommt einfach nix. Hier legt sich wohl die optische Schnittstelle definiert schlafen (ggf. wg. Batterieverbrauch). Das erschwert die Fehlersuche am Anfang. Vielleicht Optokopf verschieben, Änderung notieren, dann 3-4 Stunden warten usw. bis ein plausibler wert kommt .. Durchhalten!! ...und nochmal: Schon probiert?: [[https://www.mikrocontroller.net/topic/438972#7348585]] Hallo, nun habe ich es auch endlich geschafft meinen Pollucom E/S auszulesen. Ich habe dafür folgendes Setup:
-> /dev/serial0 ( Test mit minicom und weisser Oberfläche ist hilfreich)
Hallo zusammen, habe hier auch einen Sensus Pollucom E den ich gerne auslesen würde. Habe schon mehrfach versucht mit dem Script von "https://forum-raspberrypi.de/forum/thread/57389-sensus-pollucom-e-ueber-pymeterbus-auslesen/?postID=543096#post543096" diesen auszulesen. Leider klappt dies nicht. An der Positionierung kann es nicht liegen, da ich über Minicom 3 meinen Zähler einwandfrei auslesen kann. Ich verwende momentan einen Raspberry Pi3 an diesem UNIProg: https://github.com/PricelessToolkit/UNIProg_Programmer Habe mit eben diesem genauso wie er auch am Raspi hängt mit Minicom 3 an meinem Windows Laptop den Zähler auslesen können. Mir ist nun aufgefallen das es in Minicom 3 einmal den Sensus Pollucom E/C gibt und dann auch noch den Sensus Pollucom E/C (Neue Version) Ich kann bei mir nur die Neue Version auslesen. Könnte es sein das dieses Skript für die "ältere Version" ist? Und könnte mir jemand helfen das Skript an die neue Version anzupassen?
Hallo Tobias, ich versuche meinen Molline Ultramess C3 auszulesen. Ich sehe zwar, das er manchmal Daten liefert. Alles in allem aber nicht reproduzierbar. Könntest du bitte einmal dein Skript für den Zähler komplett posten. Welche Firmware verwendest du ? V3 von Nick oder die von Carsten ? Danke dir, Uwe Hallo Uwe Ich habe den Hichi Wifi Lesekopf von ebay gekauft, und habe keine neue Firmware installiert. Mir mir läuft die Tasmota 12.3.1 (https://github.com/arendst/Tasmota) das script was bei mir läuft ist dieses. Es ist nicht perfekt aber ich bekomme ein paar richtige Daten aus dem WMZ.
if time%period-1==0 and blk==1 ;one minute after we entered the first loop then blk=0 ; reset the flag endif #readmeter print wakeup start ;set serial protocol ret=sml(-1 1 "2400:8N1") ;send 0x55 for 3 seconds with 8N1 (72x), 2400 baud (wakeup sequence) for wkup 1 72 1 sml(1 1 "55555555555555555555") next print wakeup end wkup=1 print wait for the meter ;wait for the meter to wake up delay(350) ;switch serial protocol sml(-1 1 "2400:8E1") print request data ;set string to send to "105BFE5916" (request data) ;sml(1 1 "6804046853FE5000A116" sml(1 1 "105BFE5916")
1,142BuuUUUU@1,Maximum power,W,p_max,0 1,143Bbcd6@1000,Maximum flow,l/h,F_max,3 1,01FD17uu@1,Fehlerbyte,,Error_State,0 1,0223uuUU@1,Meter days,d,OpDays,0 1,03FD0Cuu@1,Firmware Version,,FW_Version,0 Wasnicht so richtig funktioniert, aber ich denke das liegt an der Berechung innerhalb von Tasmota, ist Temp diff und auch Error. Aber naja Hauptsache Total energy stimmt. Gruß Tobias Hallo Thomas, danke dir für deine Rückmeldung. Ich habe das mal als Startpunkt genommen. Etliche Stunden später gelingt es mir nun "manchmal" den Wärmezähler auszulesen. Und wenn es klappt werden auch sinnvolle Werte angezeigt. Mal abgesehen von der Firmware Version. Die stimmt noch nicht mit der überein die im Display des Zählers angezeigt wird. Auf meinem Zähler wird die Firmware "1.03 0.14" im Menü 2-09 angezeigt. Um die anderen Werte korrekt (In Übereinstimmung mit den im Displaye angezeigten Werten) darzustellen habe ich einige der Metrics Decoder angepasst. Ich habe lange mit der Hichi (Habe ich auch bei eBay gekauft) Firmware 12.3.1 gearbeitet bis die Werte die gelesen und angezeigt wurden, wenn sie denn gelesen wurden plausibel waren. Dann habe ich mich mal dran gemacht die aktuelle Version der Tasmota Firmware (13.4) für den SmartMeter zu bauen um zu versuchen ob ich damit den Zähler reproduzierbarer auslesen kann. Die angehängte Version habe ich jetzt bei mir mit folgendem Script im Einsatz:
Ein Datensatz sieht damit bei mir so aus:
Die gesendeten Befehle werden mit dem ACK sauber quittiert und dann der Datensatz gesendet. Mein Problem ist aber weiterhin, unabhängig davon ob ich die Tasmota 12.3.1 verwende oder die 13.4, das ich den Zähler nur sporadisch mal auslesen kann. Im Fehlerfall, wenn keine Daten gelesen werden scheint es so zu sein das es nicht gelingt den Zähler aufzuwecken. Die CMDs an den Zähler gehen raus. Es kommt aber kein ACK.
Ich habe es bereits damit versucht delays einzubauen, die WakeUp Sequenz länger oder kürzer zu machen und auch mit oder ohne "Initialize" und "set data frame mode standard" CMDs. Wenn jemand noch eine Idee hat was ich bzgl des aufwecken des Zählers noch probieren könnte, gerne. Grüße, Uwe
Angehängte Dateien:
Hallo Uwe Das mit den sporadisch auslesen habe ich auch. Ich habe sogar ein nicht Original Netzteil eingebaut, aber dieses hat auch nicht viel gebracht. Bei werden je nach Lust und Laune des WMZ am Tag 3 bis 7 Messungen auslesen. Hallt aber sehr willkürlich nicht zur selben Zeit. Wie du im script gesehen hast habe ich den Ausleseintervall auf eine Stunde gesetzt. Ich hatte ihn auch mal aller 8 Stunden auslesen lassen. Dann hast du 3-mal am Tag eine Ablesung. Wenn du eine genaue Auslesung des WMZ haben willst kommst du um ein BUS Modul nicht drum herum. Da kannst du sofort auf die Daten zugreifen. Beste grüße Tobias Hallo Tobias, dann belasse ich es jetzt mal dabei und schaue mal wie ich bei mir das Intervall einstelle damit ich mindestens 1 mal am Tag eine Aktualisierung bekomme. Zu oft mag ich auch nicht auslesen damit mir die Batterie nicht vorzeitig aussteigt. Nur der Vollständigkeit halber falls das hier noch jemand liest und auch diesen Zähler hat. Bei mir muss das "Total Volumen" auch als Hex decodiert werden und nicht als BCD8.
Muss bei meinem Zähler damit auch ersetzt werden durch
um mit dem auf dem Display angezeigten Wert überein zu stimmen. Damit sind in meinem Datensatz alle Werte Hex codiert. Viele Grüße, Uwe Hallo Uwe Vielen Dank für die Konvertierung. Diese habe ich nun auch übernommen, und nun stimmen die Werte. Zur Vollständigkeit lade ich dir mal die Docu über den M-Bus hoch. Vielleicht hillft es dir weiter. Beste Grüße Tobias Hallo Uwe Vielleicht hast du ein Tip was das ist: Mit deiner Kodierung kann ich nun die Werte richtig darstellen. Nur ein Wert macht mir Probleme und ich weiss nicht warum. Es geht um 1,143BuuUUuuUUs@1,Maximum flow,l/h,F_max,0 da bekomme ich ein risigen Wert von 3489067833 l/h angezeigt, am WMZ lese ich aber 890067,67- m³/h ab. Hast du eine Idee warum die Kodierung nicht stimmen kann? Vielen Dank Tobias Hallo Tobias, danke zunächst mal für die Protokollbeschreibung. Und dann..... Hut ab vor deinem Wärmezähler. Der Zeigt ernsthaft 890067,67- m³/h für das Register 4-02-1 als maximalen Durchfluss an ? Der mittlere Wasserbedarf der Stadt München sind 300-350.000 m³ pro Tag. Über den Daumen also 12.500 m³/h. Da hoffe ich mal, du musstest die Wärme nicht zahlen die das Wasser transportiert hat das dein WMZ als Durchfluss im Peak denkt gemessen zu haben scheint. Aber nun mal zu den 3489067833 l/h die Tasmota anzeigt. Das wäre in Hex 0xCFF6F339 bzw. im Byte Strom 0x39 0xF3 0xF6 0xCF. Gemäß Protokollbeschreibung ist der Wert wie die meisten anderen die der Zähler liefert vorzeichenbehaftet. Der Dekoder ist aber aktuell auf unsigned eingestellt. Als signed wird aus dem Hex Wert im 2er Komplement eine -805899463. Entsprechend -805899,463 m³/h. Der Wert ist schon mal näher dran an dem im Display. Und der hat ja an der dritten Nachkommastelle auch ein Minus :-) Ich würde mir noch ansehen ob die Daten korrekt empfangen werden und wenn ja, dann is es so das der Zähler den Wert ausgibt. Dafür brauchst du von der Konsole mal einen kompletten Datentransfer. Nur für die Doku. Aktivieren mit "sensor53 d1" warten bis ein kompletter Datensatz empfangen wurde und dann mit "sensor53 d0" wieder abstellen. Bei mir wäre das:
Da suchst du in der ersten Zeile mal nach dem 68xxxx68. Die beiden xx Bytes zwischen der 68 geben die Länge des Datenblocks an. Bei mir 0x85 == 133 Bytes. Los geht es mit dem ersten Byte nach dem 68xxxx68 Header. Bei mir die 0x08. Nicht Bestandteil des Datenblocks ist der CRC (Bei mir im Beispiel 0x4a) und das Stoppbyte 0x16. Also:
Die Checksumme gemäß Protokollbeschreibung ist das niederwertige Byte der Summe aller einzelnen Bytes. Du kannst diesen Datenblock in eines der Online Checksum tools kippen. Ich habe verwendet: https://www.scadacore.com/tools/programming-calculators/online-checksum-calculator/ Die benötigte Checksum ist die "CheckSum8 Modulo 256". Bei mir wird korrekt die 0x4a berechnet und damit ist mein Datenblock schon mal fehlerfrei empfangen worden. Dann suchst du dir das entsprechende Datenpacket für den "Durchfluss (Höchstwert)". Also 0x14 0x3b gefolgt von 4 Byte Nutzdaten. Bei mit die 0x75 0x03 0x00 0x00. In die richtige Reihenfolge gebracht 0x00000375 was den 885 l/h entspricht die bei mir angezeigt werden. Wobei du bei dieser Online Seite: https://www.rapidtables.com/convert/number/hex-to-decimal.html dir sowohl das Ergebnis ohne Vorzeichen als auch das 2er Komplement entsprechend mit Vorzeichen anzeigen lassen kannst. Entsprechend der Protokollbeschreibung habe ich bei mir das Decode vorzeichenrichtige Werte umgeschrieben. Ändert zwar bei mir nix da ich nur positive habe. Aber die Minus Zahl bei dir wäre mal ein Test.
Aber Achtung, ich habe bei mir auch die Variablen umbenannt falls du die nutzt. Die als "Coded" ausgegebenen Werte habe ich überprüft aber noch nicht dekodiert. Prinzipiell stimmen sie aber. Grüße, Uwe Hallo Uwe Du bist Klasse, nun stimmen bei mir die Werte im Tasmota mit denen im WMZ überein. Vielen vielen Dank dafür. Ja mit dem negativen Wert beim Durchfluss Maximum verstehe ich auch nicht so richtig, da war wohl der Zähler sich sehr verzählt oder er hat einfach gesponnen. Interessant ist aber das ich nun negative Werte anzeigen lassen kann. Ich habe dieses bei mir im Sommer bei der Temperatur Differenz. Da ist der Rückfluss des Wassers wärmer als der Zufluss. Da hatte ich immer eine kuriose Anzeige in Tasmota. Ich will demnächst noch mal genau verstehen wie man auf diese Werte kommt. Dank deiner super Anleitung werde ich mich da mal reinlesen und testen. Beste Grüße Tobias
Angehängte Dateien:
Hallo zusammen, ich versuche nun seit Tagen meinem Wärmezähler die daten mittels python Skript zu entlocken, leider bisher ohne erfolg. wmz-skript.py Es handelt sich um die Pollucom E (neuere version). Ich verwende den Hichi Lesekopf mit einem ftdi Adapter, das auslesen mit der MiniCom3 Software klappt bei beiden Zähler problemlos, daher kann ich die Batterie, Serielle kommunikation, Lesekopf positionierung etc. ausschließen. Ich bekomme nach dem senden des SND_NKE befehl, einfach kein E5 zurück. Hier ein Mittschnitt der seriellen Kommunikation, zuerst mit der MiniCom3 minicom3.txt darauf plaudert der zähler los. Hier das von dem python Skript. python_skript.txt Hatte vielleicht jemand ähnliche Problemme, ich weiß einfach nich in welche richtung ich graben soll. Probier doch erstmal mal, mit minicom oder einem anderen Terminal Programm an Port Com8? dich zu verbinden. Wenn da etwas kommt, ist vielleicht das Programm nicht ganz richtig. Problem gelöst! ser.dsrDtr = True musste ersetzt werden durch ser.setDTR(True) Hallo Uwe Ich wollte mal nachfragen ob du rausbekommen hast wie man das Datum im Tasmota richtig codiert und eine Anzeige außer als "0" rausbringt. Habe zwar auch ein wenig gespielt, aber es hat nicht funktioniert. Gruß Tobias Hallo Tobias, ja. Dekodieren der Zeiten habe ich eingebaut. Wird im Tasmota Web Interface angezeigt. Jeweils auf einer eigenen Zeile am Ende der Readings. Was ich noch nicht gelöst habe ist (i) die Zeiten Inline zu dekodieren und anzuzeigen. Also nicht auf einer eigenen Zeile sondern an der stelle an der die Kodierte Zahl steht. (ii) die beiden dekodierten Zeiten anstelle der kodierten im MQTT record zu übertragen. Das hier ist mein aktueller Stand.
Grüße, Uwe
Angehängte Dateien:
Hallo Uwe Vielen Dank für das Skript, ich habe das bei mir auch mal probiert. Daten sehen nun viel besser aus. :-) Gibt es noch eine besondere Einstellung wegen der letzten beiden Zeilen mit der Umwandlung des Datums? Bei mir werden diese trotz des Skriptes nicht angezeigt. Also wie ich dich verstanden habe werden die letzten beiden Zeilen also nicht via MQTT übertragen. Ist es möglich im Homeassistant das codierte Datum dort umzuwandeln? Beste Grüße Tobias
Angehängte Dateien:
Hallo Tobias, hast du diesen Block übernommen ?
Wenn dann im WebGui die Zeilen nicht angezeigt werden ist deine Firmware nicht mit:
Ich hatte hier Beitrag "Re: Wärmezähler über optische M-Bus-Schnittstelle auslesen" die config mit der ich meine Firmware übersetzt habe und auch das binary angehängt. Die Beschreibung der verwendeten defines findest du hier: https://tasmota.github.io/docs/Scripting-Language/ In HomeAssistant kannst du die Konvertierung auch machen. Ich bin nur noch nicht dazu gekommen. Wenn ich es habe, poste ich es. Grüße, Uwe Hallo zusammen. Dieser Thread war für mich mehrmals sehr aufschlussreich. Meine ersten Erfahrungen mit Optolesern lagen schon 14 Jahre zurück, da musste man die noch selber bauen und viel ausprobieren. Mein WMZ : Itron allmess UltraMaXX Es gab jetzt für einen meiner Wärmemengenzähler diverse Hürden zu nehmen. Magnet hält hier nicht, also hab ich mir was selbst gedruckt. Es gab aber keine Daten, nicht mit Tasmota, nicht mit Python, nicht mit LorusFree, nicht mit M-tool oder anderen Experimenten mit mehreren Optoplatinen. Irgendwann war ich genervt und besann mich auf diesen Beitrag "Re: Wärmezähler über optische M-Bus-Schnittstelle auslesen" Dank an Willy L. (sabberlotte) vom 14.02.2023 17:36 Alle Platinen die ich habe (5 Varianten,einschließlich Tasmota-Lesekopf) basieren auf dem Beispiel: https://wiki.volkszaehler.org/hardware/controllers/ir-schreib-lesekopf-ttl-ausgang Hier gibts im Empfangszweig den Widerstand R1 13k. Den habe ich letztendlich auf 68k geändert. Und siehe da, es ging sofort. Am Sendezweig hab ich nichts geändert, das führt aber eventuell zum Übersprechen. Der Empfänger liest dann die Daten die man selbst ausgibt. Dieser Effekt liegt auch am Gehäuse, was natürlich beim experimentieren oft fehlt. Ich verhinderte das Übersprechen erfolgreich mit schwarzen Schrumpfschlauchstummeln um Sender und Empfänger. Weiße Gehäuse (Selbstdruck) sind diesbezüglich schlechter als schwarze Gehäuse. Ein trennender Steg zwischen Sender und Empfänger ist hilfreich. Weitere Erkenntnisse: Der WMZ liefert seine Daten nach jeder Anforderung ab, er stellt die Mitarbeit also nicht ein, wie irgendwo weiter oben vermutet wurde. Die Positionierung muss natürlich stimmen bezüglich der Ausrichtung Sender/Empfänger, ist aber ansonsten ziemlich unkritisch. Wenn man eine TTL-Optoplatine an eine 8266-Platine anschliesst, wird diese dort mit 3,3V betrieben, möglicherweise noch abzüglich einer Schutzdiode. Aus einem FTDI-USB-Kabel (TTL-232R-3V3) kommen zwar 3,3V Signalleitungen aber die Versorgung liefert 5V! Abweichende Ergebnisse sind so absehbar :-) Die genannten 68k funktionieren bei mir mit beiden Konstellationen. Mein Zähler liefert einen ein Byte Zähler, der im Tasmota-Script im >M Bereich 1,92261704uu@1,cnt, ,readcnt,0 ausgewertet werden kann, so hat man schnell ein Überblick ob das Auslesen so abläuft wie zeitlich gewünscht, bei meinen Experimenten alle zehn Sekunden. Mein LorusFree sendet gar keine Aufwecksequenz, was mit einer Kamera mit Blick auf die Sendediode sofort auffällt. M-tool lässt sich vom Übersprechen gelegentlich verwirren, hat mir aber ansonsten geholfen. Nach dem alles lief war auch der Zweifel weg, ob die selbstkompilierte Version von Tasmota alles Nötige beinhaltete.
Angehängte Dateien:
Hallo Uwe Ja, ich dachte es mir das es an der Firmware liegt, ich habe aktuell nicht die neuste installiert. Aber irgendwie traue ich mich nicht deine Firmware aufzuspielen, da ich ja den Tasmota erst mal mit eine mini Firmware bespielen muss und dann mit deiner hinterher. Kann da was schiefgehen? Gruß Tobias Hallo Tobias, ich kann nur sagen das bei mir der Update der Firmware bisher immer ohne Probleme funktioniert hat. Ich lade auch erst die minimal Version und dann die neue. Da die Programmierung incl. Wifi erhalten bleibt ist das ganze in 2-3 Minuten erledigt. Und für den Notfall habe ich einen Programmieradapter in der Schublade. Grüße, Uwe Hallo Zusammen, spannender Tread. Hat jemand das von euch ggf. schon mal mit node Red probiert umzusetzten? Also in Node red gibt es diverse Serielle Nodes für z.B. Stromzähler. Auch einige die Mbus sprechen. Aber leider habe ich bisher keine Node gefunden, welche die Parität wechselt und die 0x55 sendet. Wer hat da einen Tip? Danke! Gruß Jo Hallo Uwe Ich bins nochmal, ich habe gestern die Firmware tasmota_13.4_V1.bin.gz auf den Kopf hochgeladen, dieses hat auch funktioniert, ich konnte ihn wieder erreichen per WLAN. Doch was nicht mehr geht ist die Auslesung. Habe nun 18 Stunden gewartet aber er zeigt nur noch 0 Werte an. Nun meine Frage muß ich was mit der "user_config_override.h" irgendwas machen? Vielen Dank Tobias
Sorry geht wieder, Der Kopf hat sich um 3 mm verdreht. Hallo Tobias, schön das die Lösung so einfach war. Die Datei "user_config_override.h" benötigst du auch nur wenn du dir das Binary selbst compilierst. Ich habe mir gestern mal das Thema dekodieren des ausgelesenen Datums angesehen. Du kannst dazu mal folgenden Code in Homeassistant in den Template Editor eingeben:
Und dir auf dieser Basis jeweils einen Template Sensor anlegen. Den Namen des jeweiligen Sensors musst du durch deinen ersetzen. Nach allem was ich bisher gefunden/gelesen habe scheint es aber keine Möglichkeit zu geben das Datum selbst als Zeitstempel zu verwenden mit dem Homeassistant die Readings in die Datenbank schreibt. Da wird wohl immer der Zeitstempel verwendet an dem HA die Sensor Daten empfängt. Wenn dazu jemand eine Lösung hat, sehr gerne- Grüße, Uwe Hallo zusammen, ich habe einige Zeit mitgelesen und auch für meinen WMZ das Skript angepasst zum Auslesen. Ich habe einen VoluMess VI Komfort, das scheint ein gebrand-labelter Engelmann zu sein der auch ein wenig andere Register hat. Es ist noch nicht perfekt, möchte es aber dennoch mal hier anhängen für die welchen es so genügt. Mein Problem ist aber ein anderes, nämlich dass die Auslesung sehr unzuverlässig ist. Im Debuglog sieht man, dass oftmals anfängliche Teile des Telegrams fehlen und daher die dekodierung in ca 40% der Fälle nicht funktioniert. Ein mitternächtliches Auslesen funktioniert daher für mich nicht, wenn ich zuverlässig 1x am Tag werte haben möchte. Aktuell habe ich das so umgangen, dass ich um 0, 1, 2 und 3 Uhr auslese. Meistens ist dann ein erfolgreicher Auslesevorgang dabei. Ist es möglich anstelle dieser festen stündlichen Auslesezeitpunkte in der >S Sektion, dass Auslesen auf Befehl, z.B. per MQTT anzustoßen? Dann würde ich es in einer Home Assistant Automatisierung so oft anstoßen, bis es einmal geklappt hat. Viele Grüße, Jonas Hallo, [[https://github.com/arendst/Tasmota/discussions/20029]] hier ist etwas ähnliches beschrieben. rl Hallo Tobias, ich hab das gerade bei mir ins HomeAssistant eingebaut. Hier die beiden Templates.
Und die aktuelle Version meines Tasmota Templates.
(i) Ich zeige im Web jetzt nur noch das dekodierte Datum an. (Label im Dekoder auf "*" setzen.) (ii) Variablen in Tasmota sind "float". Bei großen Zahlen wie der Zeit als unsigned double geht das aber zu lasten der Minuten. Will sagen bei der Berechnung des Datum Strings habe ich mich am Anfang darüber gewundert warum wenn ich alle paar Minuten auslese die Minuten immer als "00" angezeigt werden. Das habe ich gelöst indem ich mit der letzten Decoder Zeile die Minuten noch mal als unsigned word lese und damit rechne. (iii) Die Puffergröße setze ich jetzt über die zweite Decoder Zeile. Viele Grüße, Uwe
Angehängte Dateien:
Hallo Uwe Vielen Dank für die Infos und die konfiguration. Ich konnte diese in meiner Konfiguration anpassen, nun sehe ich die Daten, werde nun sehen wie lange die Aktualisierung benötigt. Ja bei dem WMZ ist das leider echt ein Problem mit dem periodischen Auslesen bei einem Infrarot Kopf. Da gibt es wohl wirklich noch keine gute Lösung. Bei mir wird etwa 5 mal am Tag ausgelesen, obwohl dieser jede Stunde versucht. Ich bin nun auf diese Seite gestoßen (https://github.com/Zeppelin500/MBusino), da wird der WMZ mittels MBUS ausgelsen, ja leider wird wieder neue Hardware benötigt, aber naja was zum Basteln. Da Konzept ist ganz gut, da wird der WMZ via Modbus ausgelesen und via WIFI an Homeassistant per MQTT die Daten übermittelt. Mal sehen ob das Funktioniert. Beste Grüße Tobias
Angehängte Dateien:
Hallo Uwe Mir ist bei meinem WMZ aufgefallen das die Uhrzeit nicht korrekt ist. Kann man mit deinem Script in Tasmota und/oder Homeassistant die Uhrzeit korriegieren? Oder noch besser gibt es ein Möglichkeit in dem WMZ die Urzeit zu ändern? Beste Grüße Tobias Hallo Tobias, stimmt. Ist bei meinem WMZ auch so. Sind bei mir ein paar Minuten. Habe ich bisher ignoriert. In HomeAssistant kannst du das am einfachsten machen. Die Variable "DatasetDate" aus meinem Template ist eine Unix Timestamp (Sekunden seit 01.01.1970) die in der letzten Zeile in einen String umgewandelt wird. Schau dir an wie viele Sekunden dein WMZ daneben liegt und addiere oder subtrahiere das als offset. Wenn die Uhr am Beispiel 5 Minuten nach geht ersetze:
durch
Zu einem einfachen Fix im Tasmota Script habe ich keine Idee. Man müsste ja den Übertrag auf die Stunden,Tage,...berücksichtigen. Mein erster Ansatz damals war die ausgelesene Zeit erst in ein Unix Timestamp zu konvertieren. Dazu habe ich aber in Tasmota nicht die passenden Funktionen gefunden und das manuell zu machen habe ich aufgrund der unterschiedlichen Anzahl von Tagen im Monat und der Schaltjahre als Lösung wieder verworfen. Viele Grüße, Uwe Hallo ihr, ich möchte meinen Wärmemengenzähler Engelmann Sensostar I per IR auslesen, verwende dazu einen Hichi-IR-Lesekopf mit Tasmota und bin, nicht zuletzt dank der Informationen aus diesem Thread, so weit, daß ich vom Zähler eine Rückmeldung bekomme. Allerdings mag Tasmota diese bisher noch nicht parsen. In der Tasmota-Console sehe ich folgendes:
Der Zähler ist batteriebetrieben, er spuckt also nur alle paar Stunden Werte aus, damit kann ich aber leben. Als Skript verwende ich das aus der Tasmota-Dokumentation für den Sensostar E (https://tasmota.github.io/docs/Smart-Meter-Interface/#engelmann-sensostar-e-heat-meter-used-with-hichi-ir-interface), da ist der Parser wie folgt definiert:
Wie man sieht, sind die Schlüsselwerte, also 04 78, 04 06, 04 13 usw., in den Daten vom Zählers alle vorhanden und sollten vom Raw-Parser eigentlich gefunden werden, in Tasmota sehe ich jedoch nur Nullen. Ich habe die Parserdefinition auch mal probeweise gegen die aus Uwes Template (Beitrag "Re: Wärmezähler über optische M-Bus-Schnittstelle auslesen") ausgetauscht, das Problem ist das Gleiche. Als Tasmota-Version war 12.3.1 drauf, ich habe auf 13.2 von Hichi upgedated, ohne Veränderung. Ich stehe wahrscheinlich auf dem Schlauch, aber wie kann ich Tasmota dazu bekommen, die Werte auch tatsächlich zu parsen?
Hat sich erledigt, einen Neustart und einen Tag später parst er einwandfrei. Hallo in die Runde, ich habe einen neuen Wärmezähler von Zenner bekommen ,der nennt sich Zenner Zelsius C5-IUF,das ist die Lora Version.Den würde ich gerne optisch auslesen wollen und habe aber bis jetzt nichts gefunden wie ich das machen kann.Ich habe mir einen BitShake lesekopf für meinen Stromzähler gekauft und den habe ich erstmal am Wärmezähler probiert aber nichts ist passiert.Beim Stromzähler funktioniert der Lesekopf.Die Bedienungsanleitung von dem Wärmezähler ist nicht wirklich aufschlussreich.Vielleicht kennt sich jemand hier damit aus und kann mir weiterhelfen. Vielen Dank schonmal und Grüße Mario Hallo Mario, ich lese auch den MBus aus, aber per Draht und speise damit auch gleich Strom ein. Ich habe zuvor SuperCal 539 Wärmezähler gehabt und hoffe das die neuen sofort laufen wenn ich die Herstellerkennung in meiner Software anpasse. Das war zuvor bei den ganzen alten PolluCom auf SuperCal 539 so problemlos gelaufen. Um das zu Unterstützen habe ich mir eine Parameterliste der C5 Wärmezähler schicken lassen. Sie liegt anbei. Die optische Schnittstelle (ZVEI, IrDA) ist tatsächlich in der Montage- und Bedienungsanleitung nicht erklärt worden, sondern nur als Standard deklariert worden. Dann müßte man nach "ZVEI IrDA" googlen. Vielleicht gibt es auch spezielle Leseköpfe. Hier ein Thread. Beitrag "Wärmezähler über optische M-Bus-Schnittstelle auslesen" Zenner war eigentlich ziemlich zuvorkommend. Ich hatte per Kontakt - Seite an die Firma gewandt. Habe noch einen interessanten Link gefunden. https://forum.iobroker.net/topic/60309/fernw%C3%A4rmez%C3%A4hler-optischen-zvei-schnittstelle mfg Klaus Hallo Klaus,danke für deine Antwort.Soweit ich weiß ist bei der Lora Version des C5-IUF kein MBus Modul verbaut da in der Anleitung nur optional drin steht somit wird es wegfallen und ich denke das es nachträglich nicht verbaut werden darf da es nicht mein Eigentum ist.Danke für die Parameterliste.Nach IrDA und ZVEI habe ich auch schon gegoogelt und bin auch auf die Foren gekommen,das hat mir leider nicht geholfen mit welchem lesekopf die Daten ausgelesen werden könnten. MfG Mario
Das MBus Modul ist wohl eher Hardware für die Drahtverbindung. Ich könnte mir vorstellen das über Lora die Daten per MBus - Protokoll gesendet werden. mfg Klaus Hallo nochmal,ist es möglich mit einem Hichi Lesekopf und V3 von Nick meinen Zenner Zelsius C5-IUF optisch auszulesen?Der Zenner sendet nur ZVEI und IrDA.Danke.Grüße Mario
Ich habe zufällig beide Teile da. Meine beiden Zenner Zelsius C5-IUF werden am Montag eingebaut und ersetzen Sontex SuperCal 539. Die hatte ich ürbigens schon über 10 Jahre in Betrieb und nie Probleme gehabt. Der Zenner Zelsius C5-IUF wird noch besser sein. Ich habe seit ein paar Wochen schon drei Hichi Leseköpfe im Einsatz. Einer war leider tatsächlich nicht ganz in Ordnung. Er lieferte innerhalb von einer Minute bei einem Lesevorgang in 1 s bis 2 s bis zu 3 erkannte Fehlversuche und teilweise Datenmüll. Der neue Lesekopf ist aber fehlerfrei. Der Hichi Lesekopf passt zumindest. IR-Fotodiode und IR-LED haben exakt den passenden Abstand und der Lesekopf wird magnetisch verankert. Welches Protokoll da geliefert wird ist mir unklar. Beim MBus muß man ja auch zunächst ein Datenpaket anfordern. Das wird bei der optischen Übertragung ähnlich sein. Aber, Du sagtest auch, daß der Zähler nicht Dein Eigentum ist. Insofern wird der Betreiber des Wärmemengenzählers den Zugriff auf den Zähler zumindest beschränkt haben. Meine MBus - Version wird auch über dem MBus mit Strom gespeist. Die vorhandene Batterie wird in der Regel gar nicht belastet. Bei mir ist auch die Lesehäufigkeit nicht beschränkt. Meine ganz alten PolluCom Wärmemengenzähler wurden nicht fremdgespeist und ich hatte damals so alle 5 Minuten ausgelesen. Das ging einige Wochen gut und dann liessen sie das häufige Auslesen nicht mehr zu und bremsten mich. Denn, die Batterie sollte ja 5 + 1 Jahr durchstehen können. OK, das war nur ein Tipp von mir. Ich denke, die Daten werden im Prinzip so wie beim MBus geliefert. Der Vorspann kann etwas anders sein. mfg Klaus
Beitrag #7781406 wurde von einem Moderator gelöscht.
Hallo da mein alter Hichi Lesekopf defekt war und dieser ab und zu falsche Werte geliefert hat habe ich mir einen neuen gekauft. Diesmal ist es ein Lesekopf "Pro3" auf dem ich aber ganz normale die minimale Tasmota Bin geflasht habe und danach die tasmota_v3.bin hier aus dem Forum. Habe dann das Backup vom alten Hichi eingespielt bekomme nun aber keine Daten. Liegt dies wohl jetzt an dem Lesekopf ? Ich dachte sollte gleich sein und dennoch funktionieren ? Zur Zeit vermute ich das es an der Positionierung liegt die eventuell nicht optimal ist. Das Script sollte ja passen da es vorher funktioniert hat
Angehängte Dateien:
Noch eine Frage kann ich irgendwo sehen das ich die richtige Firmware geflasht habe ? Nicht das hier noch eine Fehler ist. Alsoi das ich die V3 von Nick verwende. Ich glaube zwar nicht das hier der Fehler ist aber man weiß ja nie. Also mein Script sieht so aus:
Angehängte Dateien:
Was ist es denn für ein Stromzähler Model? Das Script sieht mit eher so aus als wenn es für einen Wärmezähler geschrieben wurde. Vielleicht wirst du bei dem Link fündig den ich dir anhänge: https://www.docs.bitshake.de/script/ Grüße Mario
Hallo es geht nicht um einen Stromzähler sondern um einen Wärmemengenzähler und zwar dem CF Echo 2 von Allmess bzw. Itron Gruß Thorsten Hallo und Gruß an die Gemeischaft :-) ich suche schon lange eine Möglichkeit meinen Wärmemengenzähler Sharky 775 auszulesen und war vor ca. 1 Jahr schon mal hier im Forum zum stöbern. Letzte Woche nochmals gesucht und diesen Beitrag von Thomas gefunden: https://thomasheinz.net/warmezahler-techem-ultra-s3-baugleich-sharky-775-uber-optische-schnittstelle-auslesen-tasmota/ Da ich an meinem Stromzähler bereits einen bitShake im einsatz habe bestellte ich einen weiteren für den Sharky 775 Mein bitShake befindet sich momentan noch auf der Tasmota: Tasmota 14.1.0 (tasmota32) von Theo Arends Das Script habe ich von der verlinkten Https verwendet mit einer kleinen änderung, da der Support von bitShake mir das extra geschrieben hat: "Die eine Zeile aus dem Script von der Webseite musst du wie folgt anpassen: +1,5,rE1,0,2400,WAERME,4" leider scheint er nicht zu kumunizieren mit dem Sharky 775 Habe den Lesekopf jetzt mal um 180° gedreht, bisher aber keine Veränderung Was mir nicht klar ist: wie mache ich die "Die initiale Sequenz welche den Sharky Daten entlockt wird getriggert durch ein sml(1 1 “6804046853FE5000A116”)" ??? Könnt ihr mir Helfen? Gruß Andreas
Angehängte Dateien:
Hey Andreas - bin der Autor vom Blogpost - alle Infos stammen aber von hier aus dem Mikrocontroller Forum, habe die nur für mich / andere gebündelt zusammengeschrieben. Habe da lange rumgebastelt, hauptsächlich ist / war es bei mir die Aurichtung des Lesekopfes auf dem Zähler. Vllt. sollte ich mir da mal was ausm 3D Drucker rauslassen, war wirklich ein "Pain". Die initiale Sequenz kannst du einfach in das Script mit aufnehmen Vor der Zeile
das aufnehmen
Sobald es einmal gelaufen ist kann man dies auch wieder entfernen. Hallo Leo, Danke für die schnelle Erklärung :-) Habe jetzt das orginal Script verwendet mit der initiale Sequenz Jetzt werde ich mich mal an das Ausrichten machen wenn er gesprächig wird sehe ich das doch in Konsole? (Screenshot von mir im ersten Beitrag also hier: {"w_total":0,"v_total":0.00,"p_act":0,"F_akt":0.000,"t_flow":0.0,"t_return":0.0} Habe ja Zeit, bisherige vorgehensweise seit über einem Jahr ist ein Bild am Tag vom Zähler und dann Excel Hallo Leo, bisher wird der Sharky nicht gesprächig :-) gefühlt viele Positionen versucht. Hast Du mal ein Bild von deiner Position des Lesekopfes
Evtl hilft es auch die "Innereien" aus dem Lesekopf kurz zu entnehmen, dann kann man durch die Aussparungen vom Lesekopf durchsehen und die Position dann mit Klebeband / Edding auf dem Sharky markieren. Hänge dir mal ein Foto an, aber denke das hilft dir nicht soo viel weiter.
Angehängte Dateien:
Hallo, danke für dein Bild
Ok, das ist natürlich eine Möglichkeit :-) habe jetzt aber Tape zum ausrichten verwendet Das Script habe ich von hier verwendet (mit Start Sequenz) und beite varianten mit der veränderten Zeile "+1,5,rE1,0,2400,WAERME,4"
Er kumuniziert halt überhaut nicht in der Konsole :-( Da ich hier alles gelesen habe in diesem Thread, tippe ich eher auf die FW vom Lesekopf. Ich verwende die orginale FW vom neu gekauften bitShake, also die Tasmota 14.1.0 (tasmota32) von Theo Arends Aber ich habe noch nie eine andere Tasmota FW auf einen ESP geflasht, daher bräuchte ich so zusagen ein kleines ToDo um auch wieder auf die originale zurück komme (um diesen an Bekannte an für einen Stromzähler zu verschenken) Habt ihr da etwas für mich, und welche FW mit einstellungen für den Lesekopf Gruß Andreas
Angehängte Dateien:
Das im Post gezeigte Script versucht genau um Mitternacht ein einziges mal den Zähler auszulesen. Da ist Geduld gefragt. Wenn die Ausrichtung dann nicht stimmt hast Du den nächsten Versuch einen Tag später. Zur Erprobung würde ich ein Script nehmen, dass alle 10 Sekunden was im Terminal ausgibt. rl
Hallo Ralf Ja danke für den Tip, dann suche ich mal rückwärts Gruß Andreas Hallo, kleines Update passend zu Weihnachten am 24.12.24 kam ein anderen Lesekopf, der "Wlan Hichi, IR Lesekopf für Stromzähler optisch auslesen - SmartMeter - Volkszähler - Optokopf - Wifi" Mittags dann grob ausgerichtet und mit einem Script aus diesem Forum gefüttert (ohne weitere Einstellungen)
Am späten Abend schaute ich dann in die WebUI vom Lesekopf => Bescherung => Daten wurden angezeigt :-) Also aus dem Script die Startsequenz entfernt und natürlich noch die MQTT einrichtung abgeschlossen => daher startete der Lesekopf natürlich neu und hatte keine Daten mehr in der WEBUI (also alles 0) leider redet er seither nicht mehr mit dem Wärmezähler, auch nicht mehr mit der Startsequenz im Script Habt Ihr eine Idee Gruß Andreas Hallo Andreas, das ist doch ein schönes Weihnachtsgeschenk .. das Feintunning kriegst auch noch hin .. Vielleicht liegts am Wärmezähler selbst. Bei mir ist der Sharky 775 nach einem erfolgreichem Auslesen erst wieder nach ca. 2 Stunden ansprechbar und liefert wieder Daten. Da die initiale Startsequenz wohl erfolgreich war, nimm diese wieder raus und schaue periodisch mal nach, ob Daten kommen (und ja, Geduld ist gefragt). Bei mir fragt das Script alle 5 Minuten nach, erfolgreiches Auslesen eben alle 110 Minuten. Das deaktivieren der optischen Schnittstelle scheint definierts Verhalten. Ob sich das von Gerät zu Gerät unterscheidet, weiß ich nicht. Nach etwas mehr als einem Jahr stelle ich jedoch vermehrt Fehlauslesungen fest, diese waren die erste Zeit nicht zu beobachten. Im Home Assistant werden die Charts unplausibel :-( Grüße
Hallo Phill kannst Du mal deinen Script hier Teilen? Gruß Andreas
na klar, ist auch CopyPaste hier aus dem Thread mit kleinen Anpassungen, ähnelt aber deinem .. damit kann ich mit meinem Sharky seit ner Weile gut kommunizieren, alle ca. 110 min. gibt's ein Echo. Weiter oben habe ich meine Erfahrungen beschrieben. Viel Erfolg !
super :-) habe jetzt deinen Script verwendet und => Antwortet sofort Vielen Dank Gruß Andreas
Angehängte Dateien:
Ich freue mich total das er jetzt Werte übergibt :-) Nur der Intervall der Daten ist bei mir etwas "willkürlich" siehe Spalte Minuten Uhrzeit Verbrauch Diff Minuten 09:18:00 0 kWh 00:11:00 11 09:07:00 2 kWh 01:15:00 75 07:52:00 5 kWh 03:07:00 187 04:45:00 1 kWh 00:40:00 40 04:05:00 3 kWh 02:27:00 147 01:38:00 1 kWh 00:05:00 5 01:33:00 8 kWh 01:30:00 90 00:03:00 2 kWh 01:51:00 111 22:12:00 5 kWh 03:17:00 197 18:55:00 1 kWh 01:26:00 86 17:29:00 1 kWh 01:10:00 70 16:19:00 1 kW gibt es dafür eine Erklärung? bzw. eine Lösung? Gruß Andreas
Angehängte Dateien:
Hallo, schön, dass es Ergebnisse gibt. Ich würde erstmal (vorsichtig) an der Ausrichtung spielen. Vorher markieren, Foto machen. Dann kann man versuchen im Script nach der Abfrage sml(1 1 "105BFE5916") delay(xxx) print ----- END CYCLE ----- noch ein delay(xxx) einzufügen. (z.B. delay(50) ) Dieses Delay in 100er Schritten erhöhen, testen. Mal sehen was passiert. [auskommentiert steht da: delay(10000), ist auf jedenfall viel zu hoch] Ich habe mal was über meine Erfahrungen geschrieben: Beitrag "Re: Wärmezähler über optische M-Bus-Schnittstelle auslesen"
Vielen Dank, vorsichtig möchte ich aus sein :-) bin ja erst einmal froh das etwas kommt und möchte das auch nicht kaput machen. wenn ich deinen Vorschlag richtig verstanden habe dann würde das so aussehen, siehe Screenshot?
Angehängte Dateien:
ja, stimmt so. Wenn aber die Ausrichtung nicht stimmt, werden die delays möglicherweise nichts ändern. Einfach experimentieren. Die Varianten des Scripts würde ich genügend gut dokumentieren. In einigen Tagen, oder Monaten, oder Jahren, weiß man nicht, was gut ging. Hallo nochmal eine Frage funktioniert das ganze auch mit einem Hichi IR USB Lesekopf also ohne Wlan ? Allerdings finde ich keinen Weg diesen zu flashen. Kann mir hier jemand behilflich sein ? Oder funktioniert es gar nicht. Mein Plan wäre diesen per USB mit Home Assient zu verbinden. Gruß Thorsten Niemann
Der wird an einen Rechner angeschlossen, am sinnvollsten an den, auf dem
läuft. Auslesen tue ich den per vzlogger und gebe die Daten per MQTT an HA weiter.
Logisch, da ist ja auch nix drin was selbständig arbeitet. Das macht in dem Fall der Rechner, an den der Lesekopf angeschlossen ist.
Nicht notwendigerweise, denn…
…die gibt‘s auch mit eingebautem ESP8266 mit Tasmota, dann braucht man keinen Rechner (ist ja auch nicht immer in Zählernähe vorhanden), dafür muß man ihn dann flashen.
Finde den Unterschied. Vielen Dank für die Hilfe. Daran habe ich gar nicht gedacht das hier Esp moder ähnliches verbaut ist. Habe nur daran gedacht das der Hichi mit Wlan dies hat und ist klar dieser braucht es ja auch um das Wlan bereitzustellen. Jetzt muss ich nur gucken wie ich das ganze unter Home Assient am laufen bekomme. Ich habe den Hichi IR USB bis jetzt für meine Smartmeter genutzt und die Daten wurden dann in der EDL21 integrität bereitgestellt, somit konnte ich die den Verbrauch dann auslesen. Aber dies wird mit dem WMZ wohl nicht so einfach sein. Ich denke muss ja auch wie bei dem Tasmota Skript eine spezielle Konfiguration erstellen damit die Daten ausgelesen werden kann. Aufwecksequenz etc. Habe gelesenm das es wohl den VZ Logger als Addon gibt, ich hoffe bekommen es hin. So konnte jetzt den VZ logger als addon installieren, jetzt muss ich nur noch eine VZlogger.conf erstellen. Hat jemand schon einmal eine für einen wmz erstellt uns könnte ein Beispiel dafür zeigen?
Erst einmal wünsche ich allen hier ein "gesundes Jahr 2025" Ich spiele noch ein wenig mit der Ausrichtung meines Lesekopfes am Sharky 775 da ich momentan nur alle 4h Daten bekomme. Den Lesekopf habe ich jetzt Außen gut gekennzeichnet und jetzt noch mal zu der position am Sharky: Viele Bilder im internet gesucht und hier mal eine Vermutung von mir im angehangenen Bild: kann es sein das der Lesekopf etwas nach rechts korrigiert werden muss? Gruß Andreas
Angehängte Dateien:
Hallo, kannst du mir sagen wie du die vzlogger.conf konfiguriert hast ? Ich klomme da einfach nicht weitrer. Da ich keine Ahnung habe wie diese für dem WMz aufgebaut werden soll.
Hier einmal das Log File vom VZLogger. Ich weiß nicht ob es was zu beudetn hat aber zumindest zeigt er bei last byte verschieden Werte an 0x16, 0x0, 0x10 0x 5b
Kann ich, auch wenn es dir nicht viel nützen wird, weil:
Davor steht aber, dass gar keine Daten empfangen wurden (0 bytes), deshalb sind die "last bytes" vermutlich nur Datenmüll. der zufällig irgendwo im Speicher steht. Andreas schrieb im Beitrag #7804245: ...
...
.. Hallo Andreas, Nachdem du es genauer wissen wolltest, hat mich das dann auch interessiert. Den Lesekopf nun "symmetrisch" nach links verschoben (.. erste Einkerbung neben Fixierung komplett vom Lesekopf überdeckt).. dann nach einem Tag -> keine Änderung zu beobachten. Zähler liefert weiterhin zuverlässig in bekannten Zyklus plausible Werte (bei meinem Sharky sind das die ca. 110 Min). Ich würde meinen, wenn der Lesekopf einigermaßen zentriert ist und auch plausible Werte ausgelesen werden, wars das zum Thema Ausrichtung (etwas Spiel scheint es auch zu geben). Der Rest ist eher in der Software zu suchen. Die Auslesezyklen scheinen mir vom Zähler abhängig. Ob man das im Rahmen der Initialisierung mit dem Lesekopf beeinflußen kann ? .. Weiterer Gedanke .. Im Sharky selbst können weitere Module verbaut sein. Bei mir ist ein Funkmodul integriert. Mit diesem kann die Fernwärmegesellschaft die Zählerstände drahtlos empfangen. ggf. beeinflusst die Hardwarekonfiguration des Zählers die Auslesezyklen an der optischen Schnittstelle. Dazu konnte ich in den Dokus nix finden. Okay scheint ja doch ziemlich kompliziert sein, zumindest für einen Laien wie mich. Ich hatte gedacht du könnste mir helfen, weil du folgendes geschrieben hattest.
Beim Protokoll habe ich auch keine Ahnung welches ich verwenden muss, habe d0 gewählt weil ich dachte dies könnte richtig sein. Also meinst du hier müsste ich OMS verwenden ? Kann man es irgendwie heraus finden welches Protokoll verwendet werden muss auf der Webseite zum CF Echo 2 habe ich nichts gefunden. Mit dem Tasmota Skript konnte ich den WMZ ja auslesen nur ist der Hichi Wlan leider defekt und den Hichi USB hatte ich übrig und ich dachte müsste hiermit auch funktionieren. Welches Protokoll wird den mit dem Tasmota Skript verwendet oder ist dieses wieder was anderes. In dem Skript gibt es ja einen SML Befehl bedeutet dies das dass SML Protokoll verwendet werdne muss ? SML und OMS sind zumindest ähnlich. Bei deinem Wissensstand würde ich empfehlen, auf eine Lösung zu setzen, die schon Mal irgendwo in den Weiten des Internets funktioniert hat.
Dann mach das so. Die Kosten für den Lesekopf sind im Verhältnis zum Aufwand alles selbst und neu zu machen minimal. Naja macht ja auch Spaß was neues auszuprobieren dadurch lernt man auch sehr viel. Deswegen habe ich schon etwas Ehrgeiz es hinzubekommen wenn es theoretisch möglich ist. Ich will jetzt erstmal ausprobieren ob ich das mbus Test Programm hier aus dem Beitrag ans laufen bekomme, dann weiß ich hoffentlich ob es überhaupt funktioniert und ich Daten vom wmz bekomme. Habe auch schon nach der Software lorusfree gesucht aber die gibt es zur Zeit wohl nicht als Download. Wenn das funktioniert würde ich mich weiter damit beschäftigt wie ich die Daten dann in Home Assistent bekomme. Ich habe auch gelesen das manche ein pyton Script erstellt haben und den wmz auszulesen, vielleicht bekomme ich dies ja hin. Ich glaube in Home Assistent kann man auch pyton Scripte ausführen. Ich habe jetzt ein Python Skript gefunden das eigentlich für einen anderen WMZ gedacht ist dies würde ich gerne versuchen anzupassen.
Was ich aber noch nicht verstehe sind die Hexadezimalen Zeichen bedeuten sollen. Mir ist klar das diese was mit dem anfordern der Daten zu tun haben aber ich habe das System noch nicht verstanden. Ich habe nur "xe5" verstande, dies ist ja wohl die Rückmeldung vom WMZ das die intitilaisierung erfolgreich ist. Habe versucht es irgendwie zu verstehen, auch mit Hilfe der Anleitung vom Allmess und verschiedenen WEbseiten aber ich verstehe es nicht. Vor allem weil es unter Tasmota wieder ganz anders aussieht, hier gibt es sml(1 1 "55555555555555555555") als Aufwecksequenz. Warum sieht es so aus wenn 0x55 gesendet werden soll. Bzw. warum es danach so aussieht sml(1 1 "105BFE5916"). Ich die 1 hinter der KLammer ist die Nummer des Meters der ausgelesen werden soll. Aber woher kommt die Nummer in den Anführungszeichen. Ich würde es wirklich gerne verstehen. Ich bin gerade etwas Ratlos
Disen Script von Phill (27.12.24) verwende ich ging ja auch relativ gut, nur halt nicht im sauberen Abstand von 110 min selbst mit den unregelmäßigen hätte ich leben können. Seit Neujahr allerdings nicht mehr (ziemlich böse böse Böller hier)
Ich habe das jetzt heute 2x mit Stromlos (ca. 30min) gemacht und dann kamen inerhalb 5min neue Daten siehe Anhang Mein Sharky 775 hat auch das Zusatzmodul (Funk) vom Fernwärmelieferanten. Kann natürlich auch sein das der Sharky ab 2025 nicht mehr mitspielen möchte Habt ihr noch eine Möglichkeit zur Fehlerbeseitigung Gruß Andreas
Angehängte Dateien:
Hier noch mal gebastelte Verläufe 2x Spannungslos des Lesekopf machen
Angehängte Dateien:
ich habe gestern noch eine Automation in HA eingebaut: wenn um 23:00 Uhr die letzte übermittlung älter ist als 120 min dann Lesekopf (ESP01S) 10min stromlos Das ist natürlich nicht das Ziel :-( Aber jedes mal danach kamen sofort innerhalb von 5min (Standart TelePeriod 300) ein aktueller Wert vom Sharky => also ist das Reproduzierbar Siehe Screenshot (jeweils der erste Datenpunkt war natürlich eine "0")
Angehängte Dateien:
Ich glaube ich habe endlich die Daten empfangen.. Habe einmal dieses zurück bekommen und ich find viele Zeichen wieder. Daten erhalten: b'4d 4d 68 08 00 72 26 54 83 22 77 04 09 04 3b 00 00 00 0c 78 26 54 83 22 04 06 21 34 00 00 0c 14 89 93 07 00 0b 2d 24 00 00 0b 3b 56 00 00 0a 5a 49 06 0a 5e 76 02 0b 61 30 37 00 04 6d 20 05 28 31 02 27 c3 03 09 fd 0e 22 09 fd 0f 47 0f 00 00 7e 16' [0 Das hier ist aus meinem tasmota Skript gewesen: 1,0406uuUUuuUUs@1000,Total energy,MWh,Energie_total,3 1,0C14bcd8@100,Total volume,m³,Durchfluss_total,2 1,0B2Dbcd6@10,Current power,KW,Leistung_akt,2 1,0B3Bbcd6@1000,Current flow,m³/h,Durchfluss_akt,3 1,0A5Abcd4@10,Flow temp,°C,temp_Vorlauf,1 1,0A5Ebcd4@10,Return temp,°C,temp_Ruecklauf,1 1,0B61bcd6@100,Temp diff,°C,temp_diff,2 1,0227uuUU@1,Meter days,d,Betriebstage,0 ;1,046Dxxuu@1-1,Hour,h,time_h,0 ;1,046Duu@1,Minute,min,time_m,0 ;1,046Dxxxxuu@1,Day,dd,time_d,0 Ich finde 0406 wieder, 0c 14 usw. Kann jemand bestätigen dass es nach den richtigen Daten aussieht?
Deine Daten habe ich hier https://dev-lab.github.io/tmbus/tmbus.htm reingesteckt. Aber an der 1.Stelle ein 68 eingefügt. 68 4d 4d 68 08 00 72 26 54 83 22 77 04 09 04 3b 00 00 00 0c 78 26 54 83 22 04 06 21 34 00 00 0c 14 89 93 07 00 0b 2d 24 00 00 0b 3b 56 00 00 0a 5a 49 06 0a 5e 76 02 0b 61 30 37 00 04 6d 20 05 28 31 02 27 c3 03 09 fd 0e 22 09 fd 0f 47 0f 00 00 7e 16 ergibt:
[c]
LEN 83
Type Data
L 77
C 8
A 0
CI 114
Errors sieht schlüssig aus. Du bist kurz vorm Ziel.
Hallo Andreas, mal nur so eine Idee, nimm doch mal ein besseres Netzteil. rl Super das freut mich, hätte nicht gedacht das es noch klappt. Jetzt muss ich nur noch einmal die richtige Position des Lesekopf finden. Den ich habe heute morgen die Position immer wieder verschoben und dann geguckt ob etwas gesendet wurde. Habe aber übersehen das wohl heute Nacht als das Skript lief die Werte empfangen wurde, ich weiß abe nicht mehr in welcher Position ich ihn gestern abend gesetzt habe. Muss jetzt einfach ausprobieren und ihn dann länger an einer Position lassen. Zumindest weiß ich jetzt das es funktioniert und nur an der richtigen Position gesetzt werden muss. Kennt sich hier jemand mit Python aus und kann mir sagen wie ich die Daten parsen kann und zu Home Assient senden kann, z.B. über MQTT. Vielleicht hat hier schon jemand einb fertiges Beispiel ansonsten muss ich wieder ausprobieren.
Hast Du die gezeigten Daten mit dem Pascal Script von weiter oben [[https://www.mikrocontroller.net/topic/438972?page=single#7806063]] empfangen? Dann sollten Daten viel häufiger kommen und Du kannst besser ausrichten. Welchen Lesekopf hast Du? Welchen Zähler hast Du eigentlich? Ich weiss ja selbst auch, dass es nicht einfach ist, sich in das Protokoll einzuarbeiten. [[https://m-bus.com/assets/downloads/MBDOC48.PDF]] [[https://www.ista.com/fileadmin/twt_customer/countries/content/Germany/Documents/Loesungen/Funk/M-Bus_System/Protokollbeschreibung_modul_mbus.pdf]] Es hält sich aber im Rahmen. Du bekommst Deine Rohdaten ja mit drei Aufrufen(Telegrammen) aus dem Zähler. Da hackst Du dir die interressanten Teile raus und bereitest sie auf. So macht es Tasmota ja auch, wie Du selbst oben gesehen hast. Aber auch in dieses Format muss man sich einarbeiten.
Ja ist aber ein Python Skript, keine Ahnung warum nur einmal Daten empfangen wurden. Von 1 Uhr bis ca 6 Uhr hat er jede Minute den Request gesendet aber ist nichts zurück gekommen. Ich habe ein CF Echo 2 und nutze ein Hitchi USB Lesekopf. Ich habe von dem alten kaputten Hichi Wlan Leskopf den Boden abgesägt und diesen zwischen WMZ und dem neuen Hitchi USB Lesekopf geklemmt. Da ich vorher anscheinend Reflexionen hatte und mir aufgefallen ist das bei alten kaputten Hichi Wlan die Dioden weniger weit raus gucken. Scheint funktioniert zu haben da ich seitdem weniger Reflexionen habe. Alles klar dann muss ich weiter ausprobieren
Ja, ohne zuverlässige Leseergebnisse brauchst Du nichts an der SW zu ändern. Und Du weisst jetzt, das es prinzipiell geht. Ich finde den Hichi WLAN Lesekopf eine gute Wahl, ohne spezifisch Werbung zu machen. Die Tasmota Anpassungen sind auch überschaubar. Hi zusammen! Ich verzweifle gerade ein bisschen, weil ich entweder dümmer bin als erhofft oder alles komplizierter ist als erwartet. Ich versuche einen Zenner Zelsius C5-IUF optisch mittels eines Bitshake SMR air (also mit Wifi) auszulesen. Der Lesekopf funktioniert soweit (Testskript mit Spiegel), aber dann geht nicht mehr viel. Ich hab versucht die optische Schnittstelle einmal zu initialisieren, dann entsprechende Wakeup-Skripte plus sml(1 1 "105BFE5916") ausprobiert. Mein Hauptproblem ist, dass ich NICHTS sehe, da ich nicht weiss, ob das Gerät überhaupt antwortet, wie häufig es sendet, etc. Kann mir da jemand weiterhelfen und sagen, welche Wakeup-Sequenz auf jeden Fall stimmt? Viele Grüsse aus Hamburg Carsten
Hi, frag doch mal bei bitshake nach, die haben eine sehr lange Liste mit Scripts. Ansonsten stell mal Dein Script hier ein. rl
Hi Ralf, hab schon nachgefragt und auch geschaut, aber die haben nur für 3 WMZ die Skripte (Engelmann und Kamstrup). "Mein" Skript hab ich rangehängt. Es kommt überhaupt kein Ergebnis, vermutlich liefert der WMZ nicht mal irgendwas zurück.
;set serial protocol ret=sml(-1 1 "2400:8E1") gehört hier nicht 8N1 hin? mit "Sensor53 d1" kann man in der Tasmotakonsole die Ausgabe der empfangenen bytes sehen. Da sollte nach dem data request mindestens \xE5 zurückkommen, oder mehr. Wichtig! nach Gebrauch unbedingt wieder auf "Sensor53 d0" zurücksetzen, sonst sieht man keine Daten mehr auf der Hauptseite. bei meinen Zählern gehts nicht ohne: "\x10\x40\xFE\x3E\x16" # SND_NKE mbus_init "\x68\x05\x05\x68\x53\xFE\x51\x0F\x0F\xC0\x16" # statusrequest vor der Abfrage.
Ja, stimmt, ich habs in einer meiner Versuche, das mal umzudrehen (N1->E1) nicht wieder korrigiert, danke!
Ja, das kenne ich, aber wie gesagt, man sieht überhaupt nichts, weil das Ding evtl. nur einmal am Tag Daten rauslässt. Wenn ich das dann nicht zufällig zur richtigen Zeit eingebe (dass er dumpen soll), dann sehe ich nix. Das Log ist dann ja ratzfatz weg. Debugging ist da irgendwie schwierig, oder komme ich noch an alte Logs ran?
Das ist ja das Schlimme, es gibt so viele Varianten und ich hab keine Ahnung, welche wirklich funktioniert, weil alle hier unterschiedliche Zähler haben, die etwas unterschiedlich funktionieren. Ich nehme das auch noch mit auf, dann mache ich halt alle Abfrage hintereinander, die ich finden konnte :-) Geht das eigentlich, dass man sich das result rausprinten kann mittels print result='%ret%' ? Siehe angehängtes Script
Die print Ausgabe geht in die Konsole. Die Hochkommas brauchst Du nicht.
Also dort wo auch die Werte stehen sollen. Das musst Du ausprobieren, ob die Tasmota Firmware bei Dir so kompiliert ist, sonst musst Du selbst kompilieren. Diese beiden Dokus muss man aufmerksam lesen ... und dann doch noch vieles ausprobieren. Die Scripts, vor allem die aufwändigen, von anderen Leuten studieren, hilft enorm weiter. Manche Sachen stossen an Grenzen, die man sonst nicht kennt. Anderes fühlt sich an, wie durch die Brust ins Auge. Ich hab mal was angehängt. (für einen meiner Zähler) [[https://tasmota.github.io/docs/Smart-Meter-Interface/]] [[https://tasmota.github.io/docs/Scripting-Language/]]
Ist eher ein alter Programmierer"trick": wenn Du quotes ausgibst, dann siehst Du, ob z.B. non printable characters in dem String sind, also z.B. ein Leerzeichen oder ein Zeilenumbruch. Ich hab auch klar zu viele prints drin, aber wollte erstmal gucken ob überhaupt was zurück kommt ;-)
Okay, das muss ich mir noch mal durchlesen, damit kann ich dann infos direkt auf die Hauptseite rausloggen/anzeigen?
Ja, ich denke da hab ich noch so einiges an Arbeit vor mir ;-) Aktuell sieht das log übrigens so aus: 22:17:43.960 set 2400 baud:8N1 22:17:43.961 result='???' 22:17:43.962 send 0x55 for 3 seconds with 8E1 (72x), 2400 baud (wakeup sequence) 22:17:43.965 result='???' 22:17:43.966 wait for the meter 22:17:44.367 switch to 2400 baud 8E1 22:17:44.368 result='???' 22:17:44.369 initialize 6804046853FE5000A116 22:17:44.370 result='???' 22:17:44.771 initialize 1040004016 22:17:44.772 result='???' 22:17:45.173 SND_NKE mbus_init 22:17:45.175 result='???' 22:17:45.176 send "105BFE5916" (request data) 22:17:45.177 result='???' Ist das normal, dass auch die Kommandos zum Setzen der Baudrate und Anzahl Bits keine Rückgabewerte liefern? Ich hab ja wirklich überhaupt keine Ahnung, ob überhaupt was funktioniert. Oder tappt man so lange im Dunkeln, bis man dann einmal per Zufall die richtige Wakeup Sequenz erwischt hat? LG Carsten
Nach der Wakeup Sequenz kommt erstmal nix zurück, die schickst Du so ins Blaue. Wenn Du ein für den Zähler gültiges Telegramm geschickt hast, kommt E5 zurück. Oder nach Aufforderung die Messwerte. Erstmal also das Script so simpel wie möglich halten und in der Konsole gucken, ob was zurückkommt. Der Haken dabei ist, man weis nicht, ob nix kommt, weil die Ausrichtung nicht stimmt, oder ob die Ansteuerung nicht stimmt. Ich habe meine Sensoren umgebaut, die Ausrichtung ist jetzt sehr unkritisch. Man kann sie sogar deutlich vom Zähler abheben. Bei meinen Zählern sind Kunststofflinsen Teil des Gehäuses. Da sollte die Sendediode so im Sensor stehen, das der Focuspunkt auch getroffen wird. Am Anfang kann man gut mit einem USB-Kopf und einem Programm in einer Programmiersprache deiner Wahl die Kommunikation prüfen. Es gibt auch Analyseprogramme, die man dann mit diesem Kopf auf den Zähler loslassen kann. Ach mich der WMZ noch verrückt. Zweimal habe ich ja Daten erhalten aber ish kann es nicht reproduzieren damit ich diese immer wieder erhalte. Ich habe auch starke Probleme mit Reflexionen da ich immer die Aufwachsequenz mit den 55 zurück bekommen. Wobei es auch komisch ist manchmal wenn ich den Lesekopf wieder ein Stück drehe bekomme ich andere merkwürdige Zeichen zurück. 95 95 usw. oder FF oder 55 55 00 55 61. Aber leider keine Daten die ich im Mbus Protokoll wiederfinden kann. Das was mich dann noch besonders stutzig macht als ich den Lesekopf auf eine dunkle Oberfläche komplett bündig gelegt habe habe ich noch Daten erhalten. Da können doch keine Reflexionen entstehen ? Die Dioden waren dann kompllett bedeckt. Dachte könnet etwas an dem Python Skript sein, aber was soll hier der Grund sein. Es werden ja die Daten nur serial ausgelesen. Das macht es einfach kompliziert. Ich denke wenn so viel Daten durch die Reflexion zurück kommen, kommen die richtigen Daten gar nicht an. So wie ich das Script verstehe werden nur 200 Zeichen ausgegeben und dann werden die richtigen Daten vielleicht gar nicht ausgegeben weil durch die Reflexion schon 200 Zeichen ausgegeben wurden.
Habs schon befürchtet. Wäre ja ein netter Zug vom Zähler wenn er ein paar mal blinkt und damit sagt: "bin jetzt wach"
Mein Problem ist, dass nach Meinung Anderer hier im Forum der Zähler nur 1-4 mal pro Tag überhaupt antwortet. D.h. ich kann einmal am Tag eine Änderung machen und dann 24h warten. Wäre alles etwas einfacher, wenn der Zähler sofort irgendwas machen würde, an dem ich ablesen kann, ob es funktioniert oder nicht
Und das kommt noch dazu! :-/
Da muss ich mir echt noch mal überlegen, ob es mir die Zeit wert ist, so einen Aufwand zu betreiben. Klar, wäre super, zumindest tagesgenaue Werte zu haben, damit ich die Heizungsregelung anpassen kann. Dank Dir für Deine Hilfe! Carsten
Verstehe ich nicht. Die Heizungsregelung regelt ja die Heizleistung in Abhängigkeit von Außentemperatur, Zimmertemperatur oder was auch immer. Der WMZ misst quasi das Ergebnis dieser Regelung. Wie sollte man aufgrund des Verbrauchs in die Regelung eingreifen?
Doch kann ich nachvollziehen. Man verstellt etwas an der Heizung und kann kann sehr einfach sehen wie sich der Verbrauch ändert. Natürlich sollten dann die Bedingungen Außentemperatur etc an beiden Tagen an ziemlich gleich sein
Ok, das verstehe ich.
Aber das kann man vergessen. Das wird man nie hinbekommen, und damit sind solche Vergleiche von vornherein sinnlos. Ich mache das Auslesen eigentlich nur, weil ich es kann ;-) Und natürlich ist es schön, später mal Tages/Monats/Jahresvergleiche zu haben.
Angehängte Dateien:
Genau. Es kann auch motivieren, die Heizung doch etwas kühler zu stellen, wenn man direkt sieht, wie sich das auf den Wärmeverbrauch und damit die Kosten auswirkt. Das ist ja auch der Hintergedanke beim Stromverbrauch. Wenn jeder seinen Stromverbrauch misst, kann er/sie gut nachvollziehen, wo man sparen kann. Bei uns (Fernwärme, gut isolierter Neubau) ist die Heizkostenrechnung z.T. doppelt so hoch wie bei Nachbarn mit ähnlichem Heizverhalten, dem will ich auf den Grund gehen. Da über den Wärmetauscher auch Warmwasser geht, könnte das die Ursache sein, muss aber nicht. LG Carsten
Hallo, kleine Info. Ich hatte auch einen Neubau einen hohen Verbrauch und bei mir lag es daran das die Zirkulationspumpe für Warmwasser rund um die Uhr lief, habe eine Zeitschaltuhr dazwischen geschaltet und nun ist der Verbrauch deutlich herunter gegangen.
Also bei mir hat es geholfen heraus zu finden das der Verbrauch so hoch istweil die Zirkulationspumpe durchlief. Weil ich selbst in den Sommermonaten einen hohen Verbrauch hatte und dies durch die Aufzeichnungen gut nachvollziehen können. Ich könnte natürlich auch jeden Monat hingehen und es ablesen aber so ist ja noch einfacher. So habe nun sehr wahrscheinlich heraus gefunden woran es liegtdas ich die richtigen Daten nicht bekommen habe. Lag wirklich daran das nur 200 Zeichen ausgewertet wurden. Habe es auf 800 erhöht und jetzt habe ich dreimal die Daten erhalten, halt mittendrin zwischen vielen 55
Verstehe nur noch nicht warum überhaupt Reflexionen enstehen werden die Daten auch beim senden gelesen. Ich dachte die Sequenz wird gesendet und dann wird 0,35 Sekunden gewartet und der Req_UD 2 gesendet und dann kommen doch erst die Daten vom WMZ zurück. Wie könenn da dann die Daten von der Aufwachsequenz wieder dabei sein ?
Ja, die Zirkulationspumpe ist mittlerweile sogar komplett abgeschaltet. Hat auch etwas gebracht, aber Verbrauch ist aus meiner Sicht immer noch zu hoch im Vergleich zu den Nachbarn. Aber stimmt, das ist nen ziemlicher Faktor, das konnte man schon beobachten. (bis sich das finanziell auszahlt, dauert es ja, da die Abrechnung ja immer nen Jahr verzögert kommt, d.h. die für 2024 kommt erst Mitte 2025).
Aus Laiensicht: Macht eigentlich nur Sinn, wenn das Senden der Aufwachsequenz asynchron passiert und dann schon vor Ende der Aufwachsequenz die Datenabfrage passiert. Keine Ahnung, ob der ESP/Tasmota so funktioniert, aber halte ich auch für unwahrscheinlich. LG Carsten
Hallo, mach mal bitte ein Foto vom Aufbau: Sensorfront, Zählerfront und montiert. rl
Mache ich wenn später zuhause bin aber ich glaube es liegt doch nicht an Reflexionen. Ich hatte zwischendurch die Aufwachsequenz aus meinem Python Script entfernt und immer doch die Daten aus der Aufwachsequenz erhalten. Hat dies vielleicht etwas mit dem Timeout Befehl zu tun ? Ich bin da noch nicht ganz durch gestiegen, bei der Serial Funktion stand auch etwas von Buffer und löschen. Wird vielleicht etwas zwischengespeichert und wird dann mit ausgelesen. Hier scheint man noch vieles einstellen zu können. Hier einmal das Script, ich hoffe ist verständlich sind noch ein paar Sachen drin wo ich nicht genau weiß was diese bedeuten und teilweise auskommentiert.
Angehängte Dateien:
Die Aufwachsequenz heißt so, weil sie gar kein Telegramm ist. In der MBUS Doku steht da garnichts von. Das ist eine Vereinbarung mit der man batteriebetriebene Geräte darauf aufmerksam machen kann, dass außen jemand was will. Es handelt sich einfach um ein Signal mit wechselndem Pegel. Der Trick mit \x55 ist folgender: hex 55 entspricht binär 01010101. Es gibt also auf der Sendeleitung einen gleichförmigen Wechsel von 1 und 0. Damit das Muster nicht gestört wird muss das im Format 8N1 gesendet werden. Startbit, 8Bit s.o., keine Parität, 1Stoppbit. Die Baudrate 2400 Bit pro Sekunde führt dann zum richtigen Timing. Mit der Anzahl der \x55 stellt sich dann die gewünschte zeitliche Länge der Aufwecksequenz ein, weil sich nahtlos 0 und 1 aneinanderreihen. Danach ist der Zähler bereit Daten zu empfangen. Vom Zähler gibts darauf keine Antwort ( und auch kein Echo ). Langer Rede kurzer Sinn, Deine \x55 sind Reflektionen, die von der Sendediode direkt in den Fototransistor einkoppeln. Ich habe bei meinen Sensoren kurze schwarze Schrumpfschlauchstücke auf Sender und Empfänger gesteckt. Das kommt aber auf die Gehäuse an, wie das geht. Normalerweise kann man die Platine verlustfrei aus dem Gehäuse nehmen. Ich finde die Reflektionen auch unschön, aber auf die Dekodierung wirken sie sich nicht aus. Im Pascal Script könnte man sie auch weglöschen.
Hallo ich habe jetzt um beide Dioden Klebeband gemacht aber immer noch das gleiche Problem. Im Gehäuse ist auch schon ein langer Steg, ich glaube der ist die dick das er komplett die beiden Dioden trennt. Hier auf den Foto ist das Klebeband nur bei einer Diode habe s aber jetzt an beiden Dioden gemacht. Bezüglich den löschen im Pascal Skript ist Pascal das gleiche wie Python. Weißt du wie man dies machen kann, ich habe hier noch nichts passendes gefunden
Angehängte Dateien:
Hallo Ralf und natürlich auch auch alle die mir geholfen haben :-) Lösung war nicht ein anderes Netzteil => habe seit gestern den "Hichi IR Wifi v2" verbaut und der sendet alle ca. 110 min die Daten Danke schön an alle Gruß Andreas
Angehängte Dateien:
Hallo, wollte noch Rückmeldung geben. Ich habe es wirklich ans laufen bekommen. Habe jetzt ein Python Script in Home Assistent welches die Daten ausliest umwandelt und per MQTT an Home Assistent schickt und wird dort als Gerät Wärmenmengenzähler mit den verschiedenen Sensoren angezeigt. Sind noch ein paar Kleinigkeiten die ich anpassen muss. Da nicht immer Daten zurück kommen, muss ich noch schauen woran es liegen kann. Weiß jemand wie oft dieser WMZ daten zurück gibt ? Ob man ihn stündlich auslesen kann oder doch nur täglich ? Muss auch sagen habe es nur durch die Hilfe von Google Gemini geschaft. Bin wirklich überrascht und auch ein bisschen erschreckt was Gemini leisten kann. Im Prinzip wurde der Code zu 90% von Gemini geschrieben und er funktionert. Ich habe den Anfang erstellt das die Daten serial ausgelesen werden aber dann kam ich mit dem umwandeln nicht weiter. Habe dann Gemini gesagt erstelle mir bitte einen code zum umwandeln der daten und senden diese per Mqtt zu Home Assistent. Dann hat er mir den kompletten Code erstellt. Dann habe ich noch nach den code für die Sensoren in Home Assistent gefragt, diese hat er mir dann auch noch erstellt. Die Reflexionen konnte ich nicht beseitigen deswegen habe ich gemini auch um einen Code zum entfernen dieser Zeichen gebeten, diesen hat er mir dann auch erstellt. Was mir noch aufgefallen ist, dass der Timeout Befehl (0.5) zu kurz eingestellt gewesen ist, und somit die Daten nicht emfangen wurden da vorzeitig schon das Timeout erreicht wurde, habe diesen auf 10s erhöht. Ich denke liegt daran das ja auch die Reflexionen gelesenb werden, und somit die 0.5 nicht ausreichen. Wenn jemand interesse an dem Code hat kann ers sich gernen melden.
Das weis ich leider nicht, aber wenn der Zähler batteriebetrieben ist, muß man mit dem Auslesen im Dauerbetrieb sparsam umgehen. Wenn er zuverlässig ausliest, reicht eigentlich einmal um Mitternacht. Das Script kannst du ja anhängen, hilft vielleicht weiter. Hallo hier einmal das Script, bei fragen gerne melden
@ Stefan (biscaya) Das macht es anschaulicher.
Angehängte Dateien:
@ Ralf (rl_rl) Danke für das Bild. Ich habe das ganze nochmal auseinandergenommen und durchgemessen, das passt alles. Wenn ich den Zähler in die Hand nehme und verdunkle, empfängt das Gerät die eigenen gesendeten Daten. Scheint also bezüglich Sensibilität zu funktionieren. Ich habe mittlerweile auch eine Ausgabe vom WMZ. Es handelt sich um einen Allmess Integral-MK UltraMaXX. Problem ist tatsächlich wohl der Abstand. Ich verwende einen Hichi Wifi (v1) Kopf. Wenn ich den einfach so aufsetze, kommt halt nichts. Keine Ahnung obs am Senden oder Lesen liegt. Der Abstand zwischen den Dioden passt. Wenn ich den Abstand vom gesamten Kopf zum Sensor leicht vergrößere, kommt etwas zurück. Aber leider sehr unregelmäßig. Manchmal ist die Antwort lang, meistens zu kurz. Ich bekomme das nicht in eine verlässliche Position :-( scheint im unter 1mm Bereich zu liegen, was da genau getroffen werden muss. Ich verstehe das nicht richtig, da ich hier von solchen Problemen eigentlich nicht wirklich was gelesen habe. Mir gehen da irgendwie so langsam die Ideen aus.
Man muß drauf achten ob das reflektierte Signal zurückkommt, oder ob auch Daten des Zählers zurückkommen. Wenn tatsächlich was zurückkommt UND Reflektion gelesen wird, ist das ein sequentieller Haufen, lässt sich aber erkennen. rl Danke nochmal für die Hilfe. Ich hab es jetzt hinbekommen. Nach zahllosen Experimenten mit dem Abständen und der Positionierung funktioniert das Auslesen jetzt sehr zuverlässig. Ich habe trotzdem leider noch ein Problem, was ich nicht gelöst bekomme. Die Werte die zurückkommen stimmen eigentlich alle zu 100% bis auf den Wert total energy. Hier kommt fast jedes mal an dritter stelle ein falscher Wert zurück. Da alle anderen Werte immer passen und das Auslesen jedes mal klappt, schließe ich jetzt mal ein Fehler beim Empfang aus. Hat jemand eine Idee woran das liegen könnte? Beispiel: Wert liegt bei 47.283, es wird ausglesen und der Wert 47.201 zurückgegeben, obwohl 47.301 richtig wäre. Der Fehler tritt immer an der selben Stelle auf. Nach X Auslesezyklen passt es dann plötzlich. Mein aktueller Quellcode:
wofür steht da ein 'ends'? (switch - case - ends)
Versuch mal den Puffer größer zu machen. (verdoppeln?) Vertausche mal zwei Zeilen. 1,0406uuUU@1,Total energy,kWh,w_total,0 1,0C14bcd8@100,Total volume,m³,v_total,2 Ist danach "Total volume" falsch? Hups, das ends ist wohl übrig geblieben. Ich habe den Code relativ hart beschnitten, da ich das Auslesen simpel halten wollte und per MQTT den Befehl aus Homeassistant sende. Hintergrund war, dass ich darüber das Delta errechnen wollte, da ich das für mich als einfacher erachtet habe. Zusätzlich habe ich in NodeRed dann noch eingebaut, dass nach dem Auslesen kontrolliert wird, ob die Anzahl der Auslesungen um +1 erhöht wurden, da ich zwischenzeitlich mal das Problem hatte, dass das nicht jedes mal geklappt hat. Das ist mittlerweile allerdings kein Problem mehr. Ich bin in Tasmota überhaupt nicht firm. Ends habe ich jetzt rausgelöscht. Wenn ich die zwei Zeilen vertausche ändert sich nur die Reihenfolge in der Übersicht der Auswertungen, der Wert ist trotzdem fehlerhaft. Mittlerwiele ist es auch nicht nur die dritte Stelle die nicht stimmt, sondern mir ist aufgefallen, dass der ganze Wert bis auf die ersten zwei Zahlen an verschiedenen Stellen daneben ist. Beispiel jetzt gerade: Ich habe die zwei Zeilen getauscht, ausgelesen - Ergebnis 47534 Zeilen zurückgestellt, Puffer verdoppelt - Ergebnis 47606 Der echte Zählerstand verglichen zu diesem Zeitpunkt war dann 47636 (am Zähler abgelesen) Beim dritten mal Auslesen mit dem selben Skript dann plötzlich korrekt :-/ So richtig schlau werde ich daraus nicht. Die anderen Werte scheinen immer korrekt zu sein, auch Total volume, obwohl das ja eebenfalls eine "lange" Zahl ist. Sollte ich doch nochmal an der Positionierung arbeiten?
Du kannst in der Tasmota-Konsole mal in der Eingabezeile
eingeben. Daraufhin werden die Rohdaten im Terminal ausgegeben. Etliche Ausgaben abwarten, dann markieren, kopieren und als txt-File abspeichern. Oder direkt hier: https://tasmota-sml-parser.azurewebsites.net/ reinkopieren und dekodieren. Die Zählerstandszeile kannst Du von dort in dein Script übernehmen. (Falls was mit der Decodierung nicht stimmt) Anschließend nicht vergessen:
sonst kommt nix auf der Webseite Danke für die Tipps! Ich habe jetzt mehrfach ausgelesen und abgespeichert, siehe Anhang. Sieht für mich so aus, als ob Lesefehler auftreten, die Antworten sind immer unterschiedlich lang und die Werte ändern sich / fehlen teilweise. Bei https://dev-lab.github.io/tmbus/tmbus.htm bekomme ich Parsing Error: Check sum failed, pos 1 Bei https://tasmota-sml-parser.azurewebsites.net/decode kommt direkt gar nichts, weil wahrscheinlich die Checksum auch dort als falsch erkannt wird? Uff, das ist echt übel. So langsam verzweifel ich daran. Ich dachte echt das Ding wäre jetzt gut ausgerichtet, da jedes mal eine ähnliche Antwort kam und er auch wirklich immer antwortet. Das war tatsächlich ja auch erst so, nachdem ich einen kleinen Abstandshalter eingebaut habe und einen Steg dazwischengebaut habe, damit die Dioden sich nicht stören. @Ralf (rl_rl) Leider zu spät für ein Bearbeiten des letzten Beitrags. Was hast du für einen ungefähren Abstand der Dioden zum "Glas" vor den Dioden des WMZ? Wenn ich den Lesekopf absolut akkurat gerade aufsetze, sendet der WMZ Daten aber der Lesekopf registriert nichts. Widerstand habe ich ja schon erhöht. Wenn ich ihn leicht drehe kommen die Daten wie vorher immer beschrieben, sind aber fehlerhaft (Spiegelung der Sendediode durch das Glas?). Ich habe das Gefühl, dass das an der Wölbung des Glases liegt, was vor den Dioden des WMZ ist. Komme da absolut nicht weiter. Egal ob ich komplett ran gehe oder Abstand habe, ich empfange dann nichts.
Ja, die 'Linsen' machen es zusätzlich schwer. Erstens muss man den Focus einigermassen treffen. Und wenn man schräg reinleuchtet weicht die 'Focusscheibe' zur Seite aus. Kann man gut mit Lupe und Taschenlampe probieren. Ich kann das mal probieren am echten Objekt, geht aber nicht spontan, ich hab aber noch Teile hier rumliegen. Ich hab mir damals Gehäuse gedruckt, die vorne auf den Nippeln klemmen und einen Kabelbinder zur Sicherung benutzen. Bild. Ich kanns jetzt nicht sehen, aber ich denke Diode und Transistor sind bündig mit der Gehäuseoberfläche.
Angehängte Dateien:
Hallo :-) ich habe leider "wieder" ein Problem und finde keine Lösung der "Hichi IR Wifi v2" verabschiedet sich alle 2/3 Tage
Stromlos machen => dann geht es wieder für 2/3 Tage Bisher habe ich:
Habt ihr eine Lösung für mein Problem woran das liegen kann? Verwendeter Script:
Habe in Homeassistant jetzt eigene Sensoren angelegt damit die ersten Werte "0" nach einem Neustart ignoriert werden und dann natürlich auch in InfluxDB alles passt ohne das ich noch etwas korrigieren muss
Angehängte Dateien:
Keine Lösung, aber ein Workaround: Über eine Zeitschaltuhr den Lesekopf einmal täglich stromlos machen. Oder vielleicht gibt's ja sogar in Tasmota eine passende Reboot-Funktion, die man mit einem Timer auslösen kann? Ja 👍 Momentan habe ich einen Shelly Plug am Lesekopf und dieser macht den Lesekopf stromlos wenn 10min nicht erreichbar. Dein Vorschlag ist auch schon vorbereitet: über HTTP request oder über MQTT topic Hätte aber gerne gewusst warum? Der MQTT Connect Count Sensor zählt natürlich auch hoch bevor das ganze passiert @Ralf (rl_rl) Ich bin tatsächlich einen Schritt weiter aber stehe wieder vor einem anderen Problem. Ich habe die Lese-Diode ausgetauscht sowie den Abstandhalter ausgebaut und den Lesekopf gerade fixiert. Jetzt haben sich die Daten so verändert, dass ich konstant jedes mal eine 68 am anfang habe. Ich habe zig mal ausgelesen und die Seite https://dev-lab.github.io/tmbus/tmbus.htm zeigt mir die Daten auch entsprechend immer richtig an. Hier mal eine Beispielausgabe: 68 4d 4d 68 08 00 72 52 14 38 21 92 26 17 04 12 00 00 00 0c 78 52 14 38 21 04 06 20 bb 00 00 0c 14 03 99 36 01 0b 2d 26 00 00 0b 3b 22 10 00 0a 5a 83 02 0a 5e 60 02 0b 61 25 02 00 04 6d 16 11 22 33 02 27 a8 04 09 fd 0e 08 09 fd 0f 11 0f 00 00 68 16 Zum Problem: Mit meinem oben geposteten Quellcode in Tasmota bekomme ich zum Teil trotzdem andere (falsche) Werte zurück - bspw. bei total Energy. Die andere Seite (https://tasmota-sml-parser.azurewebsites.net/decode) funktioniert leider nicht mit den Eingaben und liefert keine Ausgabe. Wie komme ich an die richtigen Decoder-Strings, wenn ich sie dort nicht bekomme? Die Daten müssten ja trotzdem jetzt korrekt sein nehme ich an? Ich habe mir einen Wolf gegoogelt, aber finde nichts.
https://itrona.ch/stuff/F2-2_PJM_5_Beschreibung%20SML%20Datenprotokoll%20V1.0_28.02.2011.pdf Hänge nochmal Daten an, von denen Du glaubst, dass sie richtig sind. Die Filterstrings in deinem Script findest Du in deinen Hexwerten wieder, Bei mir zB:
und Bild. Die Doku: https://tasmota.github.io/docs/Smart-Meter-Interface/
Angehängte Dateien:
Hallo, mal den Puffer vergrößern, falls Du das nicht mitkompiliert hast.
ändern bei 1,=so3,512
Hallo Ralf, Bei dem ersten v2 (Baugleich zum neuen) trat der gleiche Fehler auf. Daher mein Versuch mit dem anderen die neue Tasmota Version zu verwenden. Selber kompiliert habe ich ihn nicht, habe eine fertige verwendet: https://ottelo.jimdofree.com/stromz%C3%A4hler-auslesen-tasmota/#4 Aber versuche ich gerne :-)
mit dieser Zeile kamen in 7 Stunden keine Werte vom Lesekopf. Zeile wieder raus, dann kam innerhalb 1/2 h wieder ein Wert Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
