Die neue Version berücksichtigt eine Baudratenumschaltung beim Handshake. Ich bin mir weder sicher, ob das alle Zähler machen, die einen Handshake erfordern, noch bin ich mir sicher, ob die Umschaltung fehlerfrei funktioniert. Das sind aber alles lösbare Themen. Bitte mal um Rückmeldung.
Grüße
Jürgen
Hallo Jürgen,
habe die neue Version 1.02 probiert, kann es sein das dein Modul die Schnittstelle
wieder auf 300 umstellt ?
habe einmal auf 9600/19200 umgestellt, aber nach dem ersten Durchlauf steht wieder die 300 drin.
Gruß Jürgen
ja, das ist richtig. Es wird ein Handshake durchgeführt und der beginnt laut Zähler-Unterlagen immer mit 300bps. Der Zähler sendet dann seine mögliche Bitrate. Diese wird dann vom Modul beim Zähler angefragt und hoffentlich bestätigt. Dann wird der Serial-Port auf diese Bitrate eingestellt und die Daten empfangen. Bei dir sind es 19200bps. Bei der nächsten Anfrage geht es dann wieder mit 300bps los. Ich hoffe das klappt bei dir soweit.
Grüße
Jürgen
Hallo Jürgen,
mir ist aufgefallen, dass bei der Änderung auf die Version 1.02 weniger Daten als vorher aufgelistete werden.
dump(1).txt (1,8 MB)
Erst wenn ich die Zeit auf über 240 Sekunden einstelle, werden alle Daten wieder angezeigt(vorher waren es 120 Sekunden). Irgendwie klappt die Umstellung der Übertragungsgeschwindigkeit nicht wie gewünscht.
Gruß Jürgen
Hallo Jürgen,
die Daten kommen ja extrem langsam reingetröpfelt. Während die Daten ankommen, sollte der Serial-Port bei dir auf 19200bps stehen. Ist das so?
Hast du ggf. eine Fehlermeldung während des Handshakes im Debug?
Was findest du im Debug des Serial-Ports bezüglich Transmit?
Dein Debug aus der Obis-Instanz müsste so aussehen:
dump.txt (1,7 KB)
Von wo stammt deine dump.txt?
Grüße
Jürgen
Hallo Jürgen,
also die jetzt angehängte Dateien sind vom OBIS Plain Text Counter.
Die Schnittstelle bleibt auf den 300 bps stehen !
Gleich am Anfang geht der Handshake zum Zähler schief.
dump_nur ein Durchlauf.txt (67,4 KB)
dump_mit zwei Durchläufe.txt (73,0 KB)
Beim zweiten Durchlauf sieht man Überscheidungen der Daten, da ist der eine Datenfluss noch nicht zu Ende und es wird wieder eine neue Sequenz (nach der eingestellten Zeit) angestoßen → meine Meinung als Kopplungs Anfänger 
Gruß Jürgen
sehr schön. Kaum guckt man auf die richtigen Daten, schon offenbart sich der Fehler.
TXT: 22.02.2022, 15:26:12 | Received | <ETX>V/SAT63511C01667006895
TXT: 22.02.2022, 15:26:12 | Error | Unknown Message while Handshake
Da wird noch ein Rest der Vorgänger-Nachricht gesendet. Dadurch wird die eigentliche Nachricht nicht erkannt. Fix kommt gleich.
Grüße
Jürgen
Der Fehler ist jetzt behoben. Der Handshake sollte jetzt reibungslos funktionieren.
Die neue Version ist als Beta im Module-Store erhältlich.
Grüße
Jürgen
Hallo Jürgen,
die Schnittstelle wird jetzt umgeschaltet und dann wirds ruhig.
Keine Kommunikation mehr.
dump(3).txt (872 Bytes)
Gruß Jürgen
Hallo Jürgen,
sehr schade. Das passiert mir wirklich sehr selten. Aber jetzt gehen mir die Ideen aus. Wir haben den Handshake jetzt genau nach Handbuch aufgebaut. Er müsste jetzt also senden…
Hast Du noch irgendwelche Informationen, die uns weiterhelfen könnten?
Grüße
Jürgen
Hi Jürgen,
kein Problem, hast ja sehr viel Zeit und Mühe in diese Modul reingesteckt.
Wäre noch schön wenn du das wieder auf die 300er Geschwindikeit einstellen würdest.
Vielen Dank !
Gruß Jürgen
Da die Baudraten-Umschaltung nicht funktioniert werden die Versionen V1.02 und V1.03 wieder zurückgezogen. Wer diese Versionen aktuell verwendet und keine Probleme hat, braucht nichts zu tun. Bei Problemen bitte auf die Version V1.01 zurückwechseln.
Grüße
Jürgen
Die neue Version beinhaltet die Änderungen der zurückgezogenen Versionen allerdings ohne die Baudraten-Umschaltung. Sollten mit dieser Version keine Fehler hier im Forum gemeldet werden, so wird dies die erste Stable-Version werden.
Grüße
Jürgen
Update: Die Version ist jetzt Stable
Hallo,
ich habe inzwischen auch mal mit dem Weidmann IR-Modul und dem MT681 mich versucht. Beides hängt am Raspi (ttyUSB0)
Leider kommt hier zu Beginn diese Meldung:
und dann steht aktuell in den Logs:
Es kommt also teilweise etwas an, aber er schafft keine Verarbeitung. Mal ist ein Ausrufezeichen an dem Serial Port und entsprechend Cutter und Obis Counter Knoten und dann löst sich das von alleine.
Wie kommen die Variablen noch an den Obis Counter-Knoten?
Was steht im Debug des Serial Ports? Laut Produktspezifikation sendet der MT681 im SML-Format. Wenn meine Information richtig ist, dann musst Du das SML-Counter-Modul verwenden.
SML habe ich gerade mal installiert und es kommen nun auch Werte an. Allerdings meldet der Serial Port weiterhin oft ein Ausrufungszeichen samt den damit verknüpften Prozessen (Cutter+SML).
Hier der Debug, wenn Daten eintreffen und kein Ausrufungszeichen vorhanden ist
Hier die Config der USB-SST am Raspi
ok, dann haben wir doch schonmal das richtige Modul gefunden.
2 Bitten:
Wenn der Serial-Port als fehlerhaft markiert ist, dann stimmen deine Einstellungen dort nicht. Bitte mal kontrollieren.
Jürgen
Hallo,
ich habe mit Deinem Modul erfolgreich einen Siemens TD-3511 ausgelesen.
Vielen Dank für das coole Modul!
Hallo Jürgen,
werden bei dem Obis Modul von allen empfangenen Werten Variablen angelegt?
Oder ist im Modul-Code hinterlegt welche Variablen angelegt bzw. erkannt werden?
Hintergrund ist, ich habe mir mal die Debug Ausgabe angesehen und habe irgendwie das Gefühl, dass der Zähler mehr Daten sendet als in Variablen angelegt werden.
Bin aber nicht so tief drin um da sicher zu sein, dass der Zähler wirklich mehr Daten sendet.
Gruß
Giuseppe
Hallo Giuseppe,
wenn dir etwas fehlt, dann schicke mir einfach einen Auszug aus deinem Debug, dann gucke ich mir das an.
Grüße
Jürgen
