Ich will unsere Wärmemengenzähler (Typ: Hydrometer Sharky 773) über RS232 unter Linux auslesen. Der Zähler hat eine RS232-Schnittstelle mit M-Bus-Protokoll drauf (Doku: http://www.wms.nl/Downloads/Hydrometer%20Sharky773%20%28E%29.pdf). Das RS232-Kabel war bislang an eine Box angeschlossen, die früher die Daten des Zählers an ein Pilotprojekt einer Firma per Internet ständig gefunkt hat. Ich kann mit der Box zwar per HTTP kommunizieren. Die wichtigsten Infos (z.B. den Zählerstand) gibt sie aber nicht her. Deswegen will ich den Zähler nun selbst auslesen. Ich habe erstmal erfolglos mit libmbus-Tools (http://www.rscada.se/libmbus/) versucht, den Zähler anzusprechen. Dann habe ich angefangen selbst zu basteln und Sachen auszuprobieren. Mein Hardwareaufbau: ein altes Notebook mit Ubuntu drauf plus ein FTDI-kompatibler USB-RS232-Adapter. Ich habe das Notebook über RS232 erstmal an die Box (über ein Null-Modem-Kabel) angeschlossen und geschaut, was diese an den Zähler rausschickt, um diesen abzufragen. Die gefundene Bytereihenfolge (10 7B FE 79 16), die die Box alle paar Sekunden rausschickt, soll auch laut jeder M-Bus-Doku zum Abrufen der Daten geeignet sein. Die Verbindung mit der Box habe ich mit 2400 Baud 8E1 ohne Flow Control eingestellt (so wie bei M-Bus-Protokoll auch nötig/üblich). Wenn ich mich jetzt von meinem Notebook aus über RS232 mit den gleichen Port-Einstellungen (B2400 8E1 etc.) die gleiche Byte-Reihe an den WMZ schicke, schweigt dieser, anstatt mir irgendeine Antwort zu schicken. Zumindest es kommt beim Notebook nichts an. Das war auch das Problem mit libmbus: der Zähler schweigt, egal was man dahin schickt. Jetzt frage ich euch, wie das sein kann, dass der Zähler auf die Anfrage der Box offensichtlich die Infos rausrückt und auf meine (identische) Anfrage nicht. Worin könnte sich der Unterschied im RS232 noch verstecken? Oder warum kann ich die Antwort des Zählers evtl. nicht sehen? (Der USB-RS232-Adapter funktioniert grundsätzlich. Unter Windows kann ich mit der Software des WMZ-Herstellers über den selben Adapter auf den Zähler zugreifen und Sachen lesen/ändern. Also unter Windows läuft er einwandfrei. Unter Linux auch keinerlei hinweise auf Fehlfunktion. Der Loopback-Test (Pins 2 und 3 kurzschalten) läuft richtig. Die Anfragen der Box kann ich damit ebenfalls sehen.)
Hast du einen Logic Analyzer um den UART-Traffic mal mitzuschneiden? Wie öffnest du den seriellen Port unter Linux, welche Software? Terminalprogramm (welches?) oder eigener C-/Python-Code (wie sieht der aus)? Bist du sicher, dass du alle relevanten termio settings gemacht hast? Sendest du ein abschließendes \r oder \n oder \r\n, und wenn ja, erwartet das Gerät diese Zeichen auch oder nicht? Uwe.
Ich exprimentiere mit dem Com-Port jetzt mit meinem eigenen kleinen Tool. Vollständiger Code in der Anlage. Öffnen mach ich so:
1 | memset(&newtio, 0, sizeof(newtio)); |
2 | newtio.c_cflag = BAUDRATE | CS8 | CLOCAL | CREAD | PARENB; // | CRTSCTS; |
3 | newtio.c_iflag = IGNPAR; |
4 | newtio.c_lflag = 0; |
5 | newtio.c_cc[VTIME] = 20; |
6 | newtio.c_cc[VMIN] = 0; |
7 | tcflush(fd, TCIFLUSH); |
8 | tcsetattr(fd,TCSANOW,&newtio) |
Bei CRTSCTS bin ich unsicher, aber schon beides probiert. Ich habe auch schon mit den Steuerleitungen RTS und DTR versucht. Die anderen Settings ergeben sich so aus der Spezifikation in diesem PDF: http://www.wms.nl/Downloads/Hydrometer%20Sharky773%20%28E%29.pdf. Der Anfragecode, den ich rausschicke, stimmt sehr wahrscheinlich auch. Er entspricht der Spezifikation und die Box sendet auch den gleichen Code. Aber irgendwas stimmt ja nicht, sonst würde das ja funktionieren. Irgendwas macht die Box und die Windows-Software anders als ich, aber ich komme nicht dahinter. Ich habe leider auch keine Hardware, um den Traffic genauer zu analysieren.
Korrektur. Die Protokollbeschreibung des Zählers ist in dieser PDF-Datei zu finden: http://www.wms.nl/Downloads/Sharky773%20M-Bus%20telegram%20v29%20%28E%29.pdf
Die Initialisierung ist evtl. zu kurz, da gibts noch einen Haufen weitere Flags die du evtl. brauchst. Siehe z.B.: http://en.wikibooks.org/wiki/Serial_Programming/termios#Basic_Configuration_of_a_Serial_Interface http://www.taurus.com/~jeff/2100/emulator/ttyaccess.txt usw. Uwe.
Ich habe schon einige Webseiten zum Thema RS232-Programmierung durchgearbeitet. Das ist für mich die beste und umfassendste, auch wenn sie ziemlich kompakt ist. http://www.netzmafia.de/skripten/hardware/Seriell/ Ich komme trotzdem noch nicht auf die Lösung meines Probles. Natürlich gibt's viele Einstellungen bei RS232. Frage ist, welche könnten dafür verantwortlich sein, dass das Schreiben (?) ins RS232 nicht funktioniert, während das Lesen geht.
Achtung: M-Bus arbeitet zwar hardwaremäßig wie RS-232, hat aber ein eigenartiges Timing, welches genau eingehalten werden muss. ich spreche selbst mit meiner Wärmepumpe per M-Bus, hab da auch mal was für den AVR programmiert, kann dir gerne mal ein paar Sourcen reinstellen, vielleicht hilft dir das weiter... Edit: verdammt, hab da was verwechselt: M-Bus und Modbus. meine Sachen sind für Modbus. M-Bus hatte ich mal, hab ich alles rausgeworfen... btw, da hätt ich noch einen M-Bus zu RS232 umsetzer günstig abzugeben :-)
Wenn der WM-Zähler Batteriebetrieben ist, dann darf man diesen nicht zu häufig abfragen, da der Zähler die RS232 nur begrenzt bedient, um die Batterie zu schonen. Ich kann mich nicht mehr genau erinnern, aber die Beschränkung war, glaube ich 1 bis 2 mal pro Stunde, also wirklich selten :(
Ich habe jetzt verschiedene USB-RS232-Adapter ausprobiert. Interessanterweise funktionieren sie unter Windows alle einwandfrei, so dass der WMZ ohne Probleme ausgelesen werden kann. Unter Linux ist das Ergebnis wie folgt ausgefallen. Der Adapter mit HL340-Chip bekommt gar keine Antwort vom WMZ. Der Adapter mit Prolific-Chip bekommt meist die ersten paar Bytes der Antwort, dann bricht die Übertragung meistens ab, noch bevor das Ende des Telegramms erreicht ist. Nur der Adapter mit einem FTDI-Chip funktioniert 100%. Ich vermute mal, dass die Linux-Treiber im Zusammenspiel mit den beiden billigeren Chips nicht ganz das tun, was sie sollen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.