MBus (nicht Modbus) über Pegelwandler auf RS232 und UM2102N nach USB abfragen

[bmwfan]

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

Code Auswählen Erweitern

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

Code Auswählen Erweitern

dmesg | grep tty
erhalte ich aber eine Fehlermeldung, die ich so nicht kenne und daher nicht sicher bin, ob das die Ursache sein kann.

Code Auswählen Erweitern

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

[der-Lolo]

Ist Modbus nicht 485?

[bmwfan]

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.

[Hollo]

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.

[bmwfan]

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

[der-Lolo]

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

[Hollo]

Den habe ich auch.
Nutze zwar mittlerweile ein TCP Gateway, aber der USB-Adapter funktioniert einwandfrei und ist auch zum Testen sehr hilfreich.

[bmwfan]

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

Code Auswählen Erweitern

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

Code Auswählen Erweitern

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

[pejonp]

@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

[Hollo]

...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/ weiterbringen.

[bmwfan]

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

[bmwfan]

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.

[Hollo]

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
Du musst ja die Baudrate(n) einstellen, deine Geräte zuordnen, und die Modbus-Register sehen/wissen.

[bmwfan]

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

[bmwfan]

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

Code Auswählen Erweitern

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

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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