Hallo,
ich habe einen Modbus mit mehreren Wärmemengenzählern und einem Durchflußmesser im Haus installiert und möchte deren Werte über einen in der Meßeinrichtung schon vorhandenen Pegelwandler auf RS232 abfragen. Am Raspi über USB ist ein UM2102N angeschlossen, der RS232 nach USB wandelt. Da ich nach dem Anschluß des UM2102N an den Pegelwandler (nur Tx, Rx und GND angeschlossen) und einem Scan mbus-serial-scan /dev/ttyUSB0 keine Device angezeigt bekommen habe, wurde alles zurückgebaut und ich betreibe den UM2102N am Raspi ohne den angeschlossenen Pegelwandler. Bei einem dmesg | grep tty
erhalte ich aber eine Fehlermeldung, die ich so nicht kenne und daher nicht sicher bin, ob das die Ursache sein kann.
dmesg | grep tty
[ 0.000000] Kernel command line: coherent_pool=1M bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2708_fb.fbswap=1 vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000 dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=PARTUUID=08eb77b1-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
[ 0.001078] console [tty1] enabled
[ 0.979698] 3f201000.serial: ttyAMA0 at MMIO 0x3f201000 (irq = 81, base_baud = 0) is a PL011 rev2
[ 1.985814] console [ttyAMA0] enabled
[ 3.869572] systemd[1]: serial-getty@ttyAMA0.service: Cannot add dependency job, ignoring: Unit serial-getty@ttyAMA0.service is masked.
[ 5.936920] usb 1-1.4: cp210x converter now attached to ttyUSB0
[ 20.157548] cp210x ttyUSB0: failed set request 0x5 status: -32
[ 20.422986] cp210x ttyUSB0: failed set request 0x5 status: -32
[ 76.647034] cp210x ttyUSB0: failed set request 0x5 status: -32
[ 76.913185] cp210x ttyUSB0: failed set request 0x5 status: -32
[ 133.126915] cp210x ttyUSB0: failed set request 0x5 status: -32
[ 133.393169] cp210x ttyUSB0: failed set request 0x5 status: -32
[ 189.609916] cp210x ttyUSB0: failed set request 0x5 status: -32
[ 189.873185] cp210x ttyUSB0: failed set request 0x5 status: -32
Ist diese Meldung normal, wenn keine RS232 als Gegenstelle angeschlossen ist oder deutet das auf einen defekten UM2102N hin?
Grüße Jürgen
Ist Modbus nicht 485?
Stmimt. RS485 des ModBus wird über einen schon installierten Wandler auf RS232 gewandelt. An dessen TX, Rx und GND habe ich den UM2102N angeschlossen mit TxD, RxD und GND. TxD auf Rx, RxD auf Tx.
Auf die Gefahr hin, aus Unkenntnis eine total falsche Aussage zu machen...
warum nimmst Du nicht einfach einen RS485 zu USB Adapter, um deinen Modbus (ich gehe mal von Modbus RTU aus) anzuschließen?
Das wird auch von FHEM "out-of-the-box" unterstützt.
Der genannte UM2102N ist doch nur ein UART zu USB Adapter, und zwei Umwandlungen hintereinander sind sagen wir mal supotimal.
Stimmt, da aber der RS485 - RS232 schon eingebaut war (ging früher auf eine Fernüberwachung) und der UM2102N noch unbenutzt vorhanden war dachte ich, ich versuche es einfach mal. Aber scheinbar hat der nagelneue UM2102N einen Fehler (diese request- Meldung).
Am Einfachsten ist es sicher, ich schaue mir nach einem RS485 - USB Wandler. Gibt es da eine Type die man empfehlen kann bzw. von denen man die Finger lassen sollte?
Grüße Jürgen
Ich habe diesen im Einsatz...
https://www.amazon.de/In-Circuit-901-274-USB-RS485-Adapter/dp/B00I9H0998/ref=sr_1_9?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&keywords=USB+RS+485&qid=1582394792&sr=8-9 (https://www.amazon.de/In-Circuit-901-274-USB-RS485-Adapter/dp/B00I9H0998/ref=sr_1_9?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&keywords=USB+RS+485&qid=1582394792&sr=8-9)
Den habe ich auch.
Nutze zwar mittlerweile ein TCP Gateway, aber der USB-Adapter funktioniert einwandfrei und ist auch zum Testen sehr hilfreich.
Habe jetzt auch den InCircuit-Adapter RS485 - USB eingebaut, aber trotz aller Versuche mit unterschiedlichen DIP-Schalterpositionen kein Empfang.
Die 5 Wärmemengenzähler sind auf 2400 Baud und Adresse 1..5 eingestellt. Habe ich an den Calec nachgeschaut.
Die Bridge ist auf USB0
pi@raspi1:~ $ ls -l /dev/serial/by-id
total 0
lrwxrwxrwx 1 root root 13 Feb 29 16:01 usb-FTDI_FT232R_USB_UART_AB0JPMV4-if00-port0 -> ../../ttyUSB0
Ein scan bringt
pi@raspi1:~ $ mbus-serial-scan -d -b 2400 /dev/ttyUSB0
Scanning primary addresses:
0 [2020-02-29 15:10:08] SEND (005): 10 40 00 40 16
1 [2020-02-29 15:10:08] SEND (005): 10 40 01 41 16
2 [2020-02-29 15:10:08] SEND (005): 10 40 02 42 16
3 [2020-02-29 15:10:09] SEND (005): 10 40 03 43 16
4 [2020-02-29 15:10:09] SEND (005): 10 40 04 44 16
5 [2020-02-29 15:10:09] SEND (005): 10 40 05 45 16
6 [2020-02-29 15:10:09] SEND (005): 10 40 06 46 16
7 [2020-02-29 15:10:09] SEND (005): 10 40 07 47 16
Das geht weiter bis zur Adresse 250 unabhängig, wie ich die DIP-Schalter an der Bridge setze.
Habe auch schon die Anschlüße (A/B und M+/M- vertauscht. Hat nichts gebracht. GND der Bridge ist mit -24V des Busses verbunden.
Hat noch jemand eine Idee, was ich versuchen könnte?
Grüße Jürgen
@bmwfan
Vielleicht muss start/parity/stop anders eingestellt werden von 8E1 vielleicht auf 7N1.
Was sind den für modbusgeräte verbaut ? Gibt es eine Beschreibung dazu ?
Greifen andere Geräte auf die modbus-Geräte zu ?
pejonp
Zitat von: bmwfan am 29 Februar 2020, 16:23:49
...Hat noch jemand eine Idee, was ich versuchen könnte?
Grüße Jürgen
Ja, vergiss alles, was ich geschrieben habe. :)
Ich habe mich durch den Thread-Titel völlig in die Irre leiten lassen.
Du hast KEINEN Modbus!
Du hast einen mbus / m-bus / Meter-Bus!
Das ist was anderes und hat nix mit RS485 zu tun.
Da brauchst Du wirklich einen Pegelwandler.
Auf die Schnelle könnte dich dieser Link http://blog.bubux.de/m-bus-wasserzaehler/ (http://blog.bubux.de/m-bus-wasserzaehler/) weiterbringen.
Die Geräte sind von Hermann Ehlers, Calec ST und da läuft ein MBus mit 2400 Baud. Ich war allerdings der Meinung, dass MBus und ModBus dieselbe Hardware, ein RS485 2-Drahtsystem verwenden und es deswegen egal ist, ob ich einen ModBus oder MBus-Wandler einsetze. Entscheident war meiner Meinung nach nur das Protokoll auf dem Raspi. Da habe ich mich wohl nicht sorgfältig genug informiert und viel Zeit in die Versuche gesteckt.
Das würde dann aber bedeuten, dass mein RS485-USB Wandler von InCircuit mit dem MBus nicht funktionieren kann?
Eingebaut ist ja schon ein Pegelwandler von MBus auf RS232, den ich mit einem UM2102N dann auf den Raspi geschalten habe. Da aber dasselbe Ergebnis. Im Gegenteil, der Scan brach nach einiger Zeit immer ab und ich musste das Terminalfenster schließen und neu starten. Vielleicht ein Timing-Problem durch den UM2102N.
Dann werde ich den Weg mit dem eingebauten Wandler auf RS232 und dann mit einem MAX 3232 zum Raspi versuchen.
Danke
Nachdem es immer noch nicht funktioniert hat, habe ich den eingebauten Konverter genauer unter die Lupe genommen, musste ihn dazu aber ausbauen, was ziemlich aufwendig war.
Es ist ein MBus <-> RS232-Modbus/RTU Konverter (siehe Bild).
Das bedeutet doch, dass ich ihn mit einem Modbus-Protokoll abfragen muss und nicht mit einem MBus-Protokoll?
Hardware passt ja nun mit RS232 und dem MAX3232.
So langsam kommt "Licht ins Dunkel", irgendwann läuft das. ;)
Also gehen wir aktuell mal von Folgendem aus:
- Deine Devices haben einen mbus mit 2400bd
- Du hast einen Konverter, der Modbus RTU über RS232 spricht
Das würde zumindest die bisherigen Probleme erklären
- Wenn Modbus erwartet wird, funktioniert dein mbus-serial-scan auf der Seite nicht
- Wenn es RS232 ist, passt der RS485 Adapter nicht
Was dir jetzt fehlt, ist eine Konfigurationssoftware, um den Konverter zu konfigurieren. Test-Tipp http://www.resi.cc/resi/software/index.php?language=german (http://www.resi.cc/resi/software/index.php?language=german)
Du musst ja die Baudrate(n) einstellen, deine Geräte zuordnen, und die Modbus-Register sehen/wissen.
Hallo Hollo,
die SW für den RESI habe ich, aber noch nicht angeschlossen. Da die Datenübertragung auf ein Modem für die Fernabfrage der Heizungsfirma ja lief dachte ich, dass durch systematisches Testen der Baudrate und des Parity-Bits die richtige Einstellung gefunden werden kann. Ich wollte die Einstellung nicht ändern, falls ich irgendwann den Fernzugriff nutzen will. Habe aber bisher keine Daten empfangen können.
Mal sehen, ob die RESI-SW die aktuellen Einstellungen auslesen kann da ich keine Informationen darüber habe. Ansonsten muss ich umkonfigurieren.
Dachte die Anbindung wäre kurz erledigt, aber es wächst sich zu einer echten Herausforderung aus.
Kann ich beim Konverter auf Modbus RTU konfigurieren, ob Master oder Slave? Aktuell frage ich in FHEM den Konverter mit ModBusAttr als Master ab.
Grüße Jürgen
Bin immer noch dran. Habe inzwischen von der Firma RESI auf Nachfrage (sehr guter Support!) die Info erhalten, dass der Pegelwandler so alt ist, dass die aktuelle Konfigurationssoftware nicht kommunizieren kann. Daraufhin bekam ich eine passende SW zugesendet, die direkt am COM 1 auch den Pegelwandler auslesen konnte!
Der Modbus läuft auf 9600 Baud, 8 Bit, keine Parität, 1 Stopbit und er hat die Adresse 100. Die Werte sind im angehängten Bild sichtbar.
Leider wird nicht angezeigt, ob der Pegelwandler als Master oder als Slave konfiguriert ist und das kann man an der Konfiguratins-SW auch nicht einstellen.
Dann am PC einen USB-TTL (2101) Wandler angeschlossen, aber damit konnte der Pegelwandler nicht mehr ausgelesen werden. Kann entweder ein Timing-Problem sein oder die Konfigurations-SW kann mit dem USB nicht kommunizieren.
Habe dann den USB-TTL Wandler am Raspi angeschlossen. MODBUS ist
Internals:
DEF /dev/ttyUSB0@9600,8,N,1
DeviceName /dev/ttyUSB0@9600,8,N,1
EXPECT idle
FD 4
FUUID 5e5bb02c-f33f-4dc5-25e0-dcfab39e48740ecc
LASTOPEN 1584123127.15686
MODE master
NAME modbus
NR 16
NTFY_ORDER 50-modbus
PARTIAL
PROTOCOL RTU
STATE opened
SerialConn 1
TYPE Modbus
devioLoglevel 3
nextOpenDelay 60
READ:
BUFFER
READINGS:
2020-03-13 19:12:07 state opened
REMEMBER:
lrecv 1584123127.33164
defptr:
WP 100
Attributes:
busDelay 2
room 9.6.1_ModBus
verbose 5
und MODBUSATTR
Internals:
DEF 100 30
FUUID 5e5bb172-f33f-4dc5-b2c2-8489005f30986276
INTERVAL 30
IODev modbus
MODBUSID 100
MODE master
MODULEVERSION Modbus 4.1.5 - 17.9.2019
NAME WP
NOTIFYDEV global
NR 17
NTFY_ORDER 50-WP
PROTOCOL RTU
STATE opened
TRIGGERTIME 1584124119.5507
TRIGGERTIME_FMT 2020-03-13 19:28:39
TYPE ModbusAttr
lastUpdate 1584124089.5507
READINGS:
2020-03-13 19:26:22 state opened
lastRead:
Attributes:
obj-h501-len 2
obj-h501-reading Heizung
obj-h501-unpack f>
room 9.6.1_ModBus
userattr obj-h501-len obj-h501-reading obj-h501-unpack
verbose 5
Auf 501 liegt der Wärmemengenzähler der Heizung, aber leider kein Empfang. Das steht im Log:
2020.03.13 19:26:22.216 3: WP: defined with id 100, interval 30, protocol default (RTU), mode master
2020.03.13 19:26:22.219 5: WP: UnregAtIODev called from Notify
2020.03.13 19:26:22.220 5: WP: UnregAtIODev is removing locks at modbus
2020.03.13 19:26:22.220 4: WP: GetIOHash (called from Notify) didn't find valid IODev hash key, calling SetIODev now
2020.03.13 19:26:22.221 5: WP: SetIODev called from GetIOHash
2020.03.13 19:26:22.222 5: WP: UnregAtIODev called from SetIODev
2020.03.13 19:26:22.222 5: WP: UnregAtIODev is removing locks at modbus
2020.03.13 19:26:22.223 3: WP: RegisterAtIODev called from SetIODev registers WP at modbus with id 100, MODE master, PROTOCOL RTU
2020.03.13 19:26:22.227 5: WP: UpdateSetList: setList=interval reread:noArg reconnect:noArg stop:noArg start:noArg close:noArg saveAsModule scanModbusId scanStop:noArg scanModbusObjects
2020.03.13 19:26:22.228 5: WP: UpdateSetList: getList=
2020.03.13 19:26:22.231 3: WP: Notify / Init: using modbus for communication
2020.03.13 19:26:22.232 5: WP: SetartUpdateTimer called from Notify kept existing timer, will call GetUpdate in 17.3 sec at 2020-03-13 19:26:39, interval 30
Und dies kommt alle 30 sec.
2020.03.13 19:29:09.556 5: WP: GetUpdate called from HandleTimeout
2020.03.13 19:29:09.557 5: WP: SetartUpdateTimer called from GetUpdate updated timer, will call GetUpdate in 30.0 sec at 2020-03-13 19:29:39, interval 30
2020.03.13 19:29:09.558 5: WP: GetUpdate objects from attributes: h501
2020.03.13 19:29:09.559 5: WP: GetUpdate full object list: h501
2020.03.13 19:29:09.559 5: WP: GetUpdate check h501 => Heizung, poll = 0, last = 0
2020.03.13 19:29:09.560 5: WP: GetUpdate tries to combine read commands
2020.03.13 19:29:09.560 5: WP: GetUpdate doesn't sort objList before sending requests
Was stimmt nicht?
Grüße Jürgen
Hmm, ich sehe erstmal keinen generellen Fehler.
Dein "Gateway" kümmert sich um die Umsetzung der Parameter der verschiedenen Devices auf einzelne Modbus-Register.
Ein Tipp wäre noch, mal mit den Adressen zu spielen.
Je nachdem, ob eine der beiden Seiten 0 oder 1 basiert arbeitet, könntest Du testweise mal die 501 gegen 500 oder auch 502 tauschen. Du kannst ja sehen, welcher Wert rauskommen soll.
Deine Registerangabe mit h und Len 2 sieht ja gut aus.
Mich wundert dieser Log-Eintrag
2020.03.13 19:26:22.220 4: WP: GetIOHash (called from Notify) didn't find valid IODev hash key, calling SetIODev now
2020.03.13 19:26:22.221 5: WP: SetIODev called from GetIOHash
Bedeutet dies, dass das Gateway gar nicht gefunden wird oder das IODev (modbus), obwohl das "opened" anzegt?
Ich bin ja auch gerade wieder in der seriellen Ecke unterwegs.
Dir ist klar, dass manchmal das Protokoll RS232 benannt wird, die Signalpegel aber gar nicht RS232 sind ? Bezüglich der Pegel ist RS232 ungleich TTL ungleich CMOS. Und bei TTL u. CMOS gibt es auch noch verschiedene Varianten.
Grüße Markus
Da es am PC am seriellen Port COM1 mit der Konfigurationssoftware von RESI funktioniert hat gehe ich davon aus, dass es tatsächlich ein RS232 mit korrekten Pegeln ist.
Trotzdem bekomme ich am PC mit einem USB-TTL Wandler sowie am Raspi mit dem Wandler oder einem MAX3232 keine Verbinfung hin.
ZitatKonfigurationssoftware von RESI
kenn ich nicht, aber die macht ja nur das Protokoll. Die Hardware die Pegel.
ZitatPC am seriellen Port COM1 ... funktioniert hat
Auch ein Konverter oder hast Du noch ne RS232 ?
USB-TTL kann nicht für RS232 funktionieren, weil die Pegel extrem unterschiedlich sind. Für RS232 bräuchtest du noch einen RS232-TTL-Pegelwandler oder direkt ein USB-RS232-Wandler.