Probleme mit Modbus-Slave

1

Hallo Forum,

Ich nutze die Modbus-Slave-Funktionalität vom EMS mittlerweile recht intensiv. OpenEMS ist quasi der “Modbus-Chef”, sammelt sämtliche Zählerdaten und stellt sie der Haussteuerung und mittlerweile 5 Siemens Logos zur Verfügung. Problem: nach einem Neustart vom OpenEMS startet die Mobus-Slave-Komponente nicht mehr.

[odbusExt] ERROR [s.common.worker.AbstractWorker] [ctrlModbusExt] Unable to start Modbus/TCP Api on port [503]: Cannot start TCP listener - Die Adresse wird bereits verwendet (Bind failed)

Zuerst dachte ich an offene Sockets auf Port 503. Aber selbst bei gezogenem Netzwerk-Kabel und nach einem Reboot tritt das Problem auf. Eine Änderung des Ports und ein “Komponente aktualisieren” funktioniert nicht. Die anderen Modbus-Master empfangen keine Daten vom OpenEMS-Modbus-Slave.
Ein Hochsetzen der Cycle-Time brachte auch nichts. Es könnte ja sein, dass die Zählerdaten zunächst nicht schnell genug gelesen und verarbeitet werden können.

Einzige Abhilfe: sämtliche (10 Stück) Zähler aus der “Controller Api Modbus/TCP Read-Only”-Komponente löschen, OpenEMS neu starten, alle Zähler wieder einfügen und die Komponente dann aktualisieren.

Gruß & schöne Feiertage,
klinki

2

Hallo Klinki,

wir hatten das Problem bei uns kürzlich auch. Die Ursache ist wohl, dass die Bridge öfters activated/deactivated wurde, beim deactivate aber der Server nicht schnell genug gestoppt wurde und dann deshalb beim activate nicht mehr auf dem gleichen Port gestartet werden kann.

Die Lösung ist, dass wir beim deactivate einen sleep einbauen - das hat geholfen:

Gruß,
Stefan

3

Guten Morgen Stefan,

Du meinst in “controller/api/modbus/AbstractModbusTcpApi.java”

		// wait until modbus slave was completely closed
		try {
			Thread.sleep(10000);
		} catch (InterruptedException e) {
			this.log.warn(e.getMessage());
		}

Habe das eben in meinem Repo geändert, kompiliert und eingespielt. Scheint zu laufen!
Vielen Dank dafür!

Gruß,
Klinki

2 Likes
4

Kurze Info an euch bei Fenecon @stefan.feilmeier eventuell auch eine Möglichkeit um die Port-Fehler der FEMS bezüglich des USB-Ports zu beheben. Der BB öffnet anscheinend ab und zu einen anderen Port, wenn der EasySync kurz mal weg war. Dann kann natürlich der EasySync nicht mehr auf den gleichen Port, weil der ja im BB noch “open” ist.

Eventuell “einfach” einen Check einfügen bei euch in der Impl, welcher checkt, ob ein Fehler vorliegt, dann schaut ob ein anderer Port vorhanden ist und den dann (wenn bestimme Bedingungen vorliegen) nutzt, um weiterarbeiten zu können :slight_smile:

Grüße !

5

@Sn0w3y: So einfach ist das leider nicht, einfach einen anderen Port zu prüfen. Das Problem lässt sich aber auf Betriebssystemebene lösen, indem man eine UDEV-Rule anlegt, die dafür sorgt, dass ein Gerät immer den gleichen Namen bekommt.

Hier ein Beispiel, um für das Gerät, das aktuell an /dev/ttyUSB0 hängt, immer einen Alias /dev/bus0 zu geben (das dürfte unser 2nd-/3rd-Level-Service auch so machen in diesen Fällen):

  1. Seriennummer des USB-Gerätes finden
udevadm info --name=/dev/ttyUSB0 --attribute-walk | grep '{serial}' | grep -v 'musb-hdrc' | cut -d \" -f 2
  1. UDEV-Regel anlegen/erweitern
vim /etc/udev/rules.d/99-usb-serial.rules
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="A74U1MK7", SYMLINK+="bus0"
  1. UDEV aktualisieren
udevadm control --reload-rules && udevadm trigger

Gruß,
Stefan

1 Like