Wer von Euch hat einen Zaehler, den er über die optische Schnitstelle ausliest und würde mir einen Dump zur Verfügung stellen?
Ich habe angefangen das komplett nach der Norm aufzudröseln um etwas zu haben, was allgemein verwendbar und nicht für jeden eine Insellösung ist.
Bevor über die Feiertage ein erstes BETA kommt, wäre ich für jeden DUMP dankbar, um zu sehen ob meine Idee so funktioniert.
Einen Sketch um einen Dump zu erstellen gibt es hier
Nur einmal durchlaufen lassen und die Ausgabe mir zur Verfügung stellen wäre genial.
Ich weiß nicht ob ich's heut noch schaff
Bin jetzt dann "familiär" unterwegs und komm erst spät heim. Also falls sich jemand anders findet (@Rentner ?) wäre es super. Ansonsten mach ich's evtl. später noch.
Deinen hab ich schon - und den von @Renter auch - die tun schon mal - Ich muss nur noch die PublicClose-Funktion bauen und die Mehrfachcodes zusammenfassen...
Danke!
Hmmm.
Ich könnte nur einen Sensor-Dump (Sensor53 d1 in der Konsole) aus einer Tasmota-SW bereitstellen. Format ist anders, aber ggf. mit einem kleinen Makro in Notepad++ auf Deine Bedürfnisse anzupassen.
Zähler ist für Strom - ein Holley Zweirichtungsrichtungszähler, Auslesegerät ein Bitshake SmartMeterReader.
ist Ende der ersten und Anfang der zweiten Nachricht zu sehen.
Die Sequenz 1b 1b 1b 1b 01 01' bräuchte ich mindestens 2 mal, damit ich eine vollständige Nachricht bekomme. Dann könnte man versuchen was geht.
Aber mach Dir keinen Streß.
Danke.
Hallo, @wno158 danke für Deinen Einsatz
ich hab mir die Dumps auch mal angesehen.
Irgendwie werde ich den Eindruck nicht los da das schon mal ein "paar" Bytes fehlen.
eigentlich startet eine SML Datensatz mit 1b 1b 1b 1b 01 01 01 01
und endet mit 1b 1b 1b 1b xx xx xx xx
wobei xx xx xx xx die Prüfsumme ist. Man kann also recht einfach nach der Startsequenz suchen. Unmittelbar davor müsste eine Endsequenz sein.
z.B in dem Dump3.txt gibt es die Startsequenz 2 mal ->14:07:40.561 : 77 ba 1b 1b 1b 1b 01 01 01 01 76 04 00 00 01 62 00
ja, der Dump ist etwas eigenartig.
Tasmota benutzt ein "Userdefined Format", welches die SML_Spezifikation hergibt.
Damit ist es möglich gänzlich auf die der Spezifikation zu Grunde liegenden Basics zu verzichten.
Der Inhalt der SML_Datei(*) wird in "unspeziferte" Nachrichten verpackt, die dem SML_Protokoll folgen.
Es gibt einen Headerblock der mit 77 (& 0x70 => Liste / & 0x07 => 7 Elemente) beginnt. In den Elementen selbst ist versteckt, was sich dahinter verbirgt.
Der erste Eintrag ist z.B. 0x07 (& 0x00 => Bytefolge / & 0x07 => 7 Elemente)
In dem Fall (Alle Angaben in HEX):
01 -> Elektrische Energie
00 -> Channel 0
60 -> Manufaktur Spezific Abstract Media related purpose -> Und hier ist klar, das der Inhalt ein eigenes Datenformat von Tasmota innerhalb der SML-Spezifikation ist
5A 02 bezeichnen das Format selbst und in der Bytefolge/Zeichenkette ist versteckt, was als nächstes mit den folgenden 6 Elementen passiert. Und in den Elementen sind weitere Unterebenen versteckt.
Daher wird es schwer, daraus wieder etwas sinnvolles zusammenzustellen.
Für mich aber trotzdem interessant, da evtl. der Aufbau der ursprünglichen Nachricht rausgelesen werden kann.
Und evtl. später um das Tasmotaprotokoll ggfls. zu nutzen um Ergebnisse zu bekommen
Ihr werdet Euch wundern, wie aufwändig es ist, für jede Structur die jeweiligen Elemente abzubilden. Grund ist, das es keine feste Länge gibt und der Aufbau einer Nachricht innerhalb der Datei erst im Stream selbst ermittelt werden muss...
(*) Eine SML_Datei bezeichnet einen Stream, ohne spezifisches Medium - also nur eine Aneinanderreihung von Bytes.
@Rentner
Tut mir leid, ich selbst bin was SML angeht vollkommen unbedarft. Ich habe nur die Dump-Funktion für Sensor53 gefunden und benutzt - d.h. Console aufgemacht, Dump eingeschaltet, gewartet, ausgeschaltet und dann den Inhalt des Konsolenfensters gespeichert. Durchaus möglich, dass da was fehlt; ich fand es auch merkwürdig, dass die Startsequenz dann so gar nicht mehr auftaucht.
@my_xy_projekt
Für den Zähleradapter hat bitShake wohl ein eigenes Compilat der Tasmota-SW hergestellt (ich soll nicht updaten, dann geht es nicht mehr). Weiters läuft darin ein spezielles Script, das aus dem Datenstrom Sachen extrahiert. Da lasse ich nicht alles auf der Webseite anzeigen. Hatte bisher nicht die Zeit (und Lust) mich dahinein zu vertiefen, denn ich will nur wissen, was ich alles an die Avacon verschenke.
Um RAW-Daten aufzunehmen, müsste ich umlöten und einen anderen ESP anflanschen. Mache ich erst, wenn ihr sagt, dass es wirklich nötig ist
Gestern kam mir genau diese Idee, weil der Fototransistor auch zwei digitale Eingänge zu schalten vermag. Jetzt kann ich mit dem einen nach meinen Programmfehlern forschen, während der andere ununterbrochen Daten sammelt. Bisher vertragen sich die ESPs, ich darf sie nur nicht verwechseln
Ich hab mal ganz schnell angefangen bei tasmota ind die Doku zu SmartMeter reinzuschauen.
Ok.
Die truncen die Dumpline, wenn denen im Inhalt nichts entgegenkommt, was gebraucht wird.
Und auch da wird anscheinend auch nur auf den jeweiligen OBIS-Code geparst.
Anders lässt sich die (falsche) Annahme
nicht erklären.
Denn richtig ist, dass das Feld F ebenso auch adere Codes enthalten kann:
Es ist also nicht möglich die Daten vollständig zu dekodieren, wenn diese nicht der Vorgabe 0xFF auf Feld F entsprechen.
Ja, natürlich interessert das evtl. nicht jeden.
Aber Hilfe naht....
(Nachtrag: Bitte beachten, dass dadurch das in den Specs dezimal und hexadezimal vermischt werden (siehe Feld A vs. B-F) die Lesart manchmal sehr schwer ist....)
(// Nachtrag 2: Gerade gesehen, das meine Aussage in #8 nicht ganz richtig ist. -> geändert)
Oh?!
Grad mal noch weiter gelesen.
Meinen die das ernst?
Das Label (kWH), der Scaler (3) versteckt sich in dem SML_Datenpaket! Es garantiert niemand, dass das immer gleich bleibt.
Damit ist der Ausflug beendet.
Das macht mehr Irre, als das es hilft.
