PROXMOX-diagslave ModBus/TCP SLAVE-Server(VM) mit C.M.I und UVR16xx-Umgebung über ModBus/TCP verbinden

Hallo,

um externe Messwerte in die UVR16xx über das C.M.I reinzubekommen, führt kein Weg an Modbus/TCP vorbei.

in diesem Beitrag wird beschrieben wie man den diagslave (Modbus/TCP-Slave Server) in einer PROXMOX-VM (Linux Container LXC) als Dienst zum laufen bringen kann.

Proxmox VE ist eine auf Debian-Linux basierende Open-Source-Virtualisierungsplattform zum Betrieb von virtuellen Maschinen mit einem Webinterface zur Einrichtung und Steuerung von x86-Virtualisierungen.

Zur Installation vom Proxmox Virtual Environment gibt es im Internet viele Videos, damit klappt die Installation reibungslos.

Ich persönlich finde es ist eine einfach zu bedienende Web-Oberfläche zur Verwaltung von virtuellen Maschinen. Besonders gut gefällt mir, dass man sowohl die Web-Oberfläche nutzen kann, oder das CLI (also Kommandozeile).

Als Hardware verwende ich für das Proxmox VE einen Intel-NUC(Next-Unit-of-Computing) Mini-PC mit einer leistungsfähigen CPU mit 12 CPU-Kernen (i7-10710U), viel Arbeitsspeicher (64GB)

und einer schnellen SSD-Platte (HP SSD EX900 M.2 1TB) damit das ganze auch super schnell läuft und die nächsten Jahre viel mehr Spass macht als mit einem Windows-Rechner.

Das Proxmox VE verwende ich zum lernen und forschen und kann damit einfach sehr viele Rechner und einzelne Dienste separat virtualisieren und doch alles übers Netzwerk miteinander betreiben wie wenn alles theoretisch ein Rechner wäre.

Das organisieren oder aufteilen von einzelnen Diensten (wie ioBroker, NodeRed, Fhem, HomeAssistant, Influx-DB usw.) und mehrere verschiedene Rechner in einzelne VM's erspart beim wilden austesten und rumspielen manchen kompletten Neuaufbau eines gesamten Systems, sodaß man beim arbeiten ohne Rücksicht alles ausprobieren kann.

Wenn mal was nicht mehr läuft, dann braucht man nur die entsprechende VM recovern (zurückspielen) oder neu aufbauen.

PROXMOX Web-Oberfläche --> create CT LXC Container

Also zuerst mit der Web-Oberfläche einen neuen LXC Container mit dem Namen ModbusSlave erstellen und starten und in die console reingehen und nachfolgende Befehle eingeben.

1.schauen wie das aktuelle Verzeichnis heisst und die net-tools und den mc installieren

pwd

apt install net-tools

apt install mc

2. tarball downloaden:

wget https://www.modbusdriver.com/downloads/diagslave.tgz

3. tarball auspacken:

tar xzf diagslave.tgz

4. ins /systemd/system/ Verzeichnis wechseln und mit dem nano-Editor die Datei diagslave.service anlegen

cd /etc/systemd/system/

nano diagslave.service

5. dann nachfolgenden Datei-Inhalt mit copy und paste ins Editor-Fenster reinkopieren

Unit]

Description=diagslave Service

After=multi-user.target

[Service]

Type=idle

User=root

ExecStart=/root/diagslave/x86_64-linux-gnu/diagslave -m tcp -p 502

Restart=always

[Install]

WantedBy=multi-user.target

6. und danach speichern mit (ctrl-o) und den nano-Editor beenden mit (ctrl-x) und die zwei nachfolgenden Befehle im Terminal-Fenster ausführen:

systemctl daemon-reload

systemctl enable diagslave.service

Das wars dann schon.

Der Modbus-disgslave LXC Container muss nun neu gestartet (reboot) werden!

Danach läuft ein PROXMOX-diagslave ModBus/TCP SLAVE-Server mit eigener Ip-Adresse

und wartet auf connects vom CMI und connects von iobroker oder Node-RED usw..

Nach dem Neustart in der console vom LXC Container prüfen ob der diagslave läuft mit der Prozessliste:

ps -e | grep -i "diagslave"

root@modbus-diagslave:~# ps -e | grep -i "diagslave"

99 ? 00:00:00 diagslave

root@modbus-diagslave:~#

oder mit folgendem Befehl kann man sich den status vom service diagslave anzeigen lassen:

service diagslave status

root@modbus-diagslave:~# service diagslave status

* diagslave.service

Loaded: loaded (/etc/systemd/system/diagslave.service; enabled; vendor preset: enabled)

Active: active (running) since Fri 2021-12-03 20:59:05 UTC; 15min ago

Main PID: 99 (diagslave)

Tasks: 1 (limit: 4915)

Memory: 50.3M

CGroup: /system.slice/diagslave.service

`-99 /diagslave/x86_64-linux-gnu/diagslave -m tcp -p 502

console von der LXC Container(VM) --> mit den abgefahrenen Befehlen

Die Informationen vom diagslave die er beim starten sonst im Terminalfenster ausgeben würde

findet man im syslog. Das befindet sich im nachfolgenden Verzeichnis:

/var/log/syslog

...

Dec 09 18:40:07 ModbusSlave systemd[1]: dmesg.service: Succeeded.

Dec 09 18:40:09 ModbusSlave diagslave[100]: diagslave 3.4 - FieldTalk(tm) Modbus(R) Diagnostic Slave Simulator

Dec 09 18:40:09 ModbusSlave diagslave[100]: Copyright (c) 2002-2021 proconX Pty Ltd

Dec 09 18:40:09 ModbusSlave diagslave[100]: Visit https://www.modbusdriver.com for Modbus libraries and tools.

Dec 09 18:40:09 ModbusSlave diagslave[100]: Protocol configuration: MODBUS/TCP

Dec 09 18:40:09 ModbusSlave diagslave[100]: Slave configuration: address = -1, master activity t/o = 3.00s

Dec 09 18:40:09 ModbusSlave diagslave[100]: IP configuration: port = 502, connection t/o = 60.00s

Dec 09 18:40:09 ModbusSlave diagslave[100]: Server started up successfully.

Dec 09 18:40:09 ModbusSlave diagslave[100]: Listening to network (Ctrl-C to stop)

Dec 09 18:40:09 ModbusSlave diagslave[100]: validateMasterIpAddr: accepting connection from 192.168.15.208 HomeAssistent

Dec 09 18:40:09 ModbusSlave diagslave[100]: .#015Slave 1: readHoldingRegisters from 7, 1 references

Dec 09 18:40:09 ModbusSlave diagslave[100]: .

Dec 09 18:40:09 ModbusSlave diagslave[100]: validateMasterIpAddr: accepting connection from 192.168.15.130 CMI

Dec 09 18:40:09 ModbusSlave diagslave[100]: .#015Slave 1: readHoldingRegisters from 7, 1 references

Dec 09 18:40:09 ModbusSlave diagslave[100]: .#015Slave 1: readHoldingRegisters from 8, 1 references

Dec 09 18:40:09 ModbusSlave diagslave[100]: .#015Slave 1: readCoils from 11, 1 references

Dec 09 18:40:11 ModbusSlave diagslave[100]: .

Dec 09 18:40:11 ModbusSlave diagslave[100]: validateMasterIpAddr: accepting connection from 192.168.15.205 NodeRED

Dec 09 18:40:16 ModbusSlave diagslave[100]: ..#015Slave 1: readHoldingRegisters from 7, 1 references

Dec 09 18:40:19 ModbusSlave diagslave[100]: .#015Slave 1: readCoils from 11, 1 references

Dec 09 18:40:19 ModbusSlave diagslave[100]: .#015Slave 1: readHoldingRegisters from 7, 1 references

Dec 09 18:41:55 ModbusSlave diagslave[100]: ..

Dec 09 18:41:55 ModbusSlave diagslave[100]: validateMasterIpAddr: accepting connection from 192.168.15.221 python-script

Dec 09 18:41:55 ModbusSlave diagslave[100]: .#015Slave 1: readCoils from 5, 1 references

Dec 09 18:41:55 ModbusSlave diagslave[100]: .#015Slave 1: writeCoils from 5, 1 references

Dec 09 18:41:55 ModbusSlave diagslave[100]: .#015Slave 1: readCoils from 5, 1 references

Dec 09 18:41:55 ModbusSlave diagslave[100]: .#015Slave 1: readHoldingRegisters from 2, 9 references

Dec 09 18:41:55 ModbusSlave diagslave[100]: .#015Slave 1: writeHoldingRegisters from 7, 2 references

Dec 09 18:41:56 ModbusSlave diagslave[100]: .#015Slave 1: readHoldingRegisters from 7, 1 references

Dec 09 18:41:56 ModbusSlave diagslave[100]: .#015Slave 1: readHoldingRegisters from 8, 1 references

Dec 09 18:42:05 ModbusSlave diagslave[100]: ..

Dec 09 18:42:05 ModbusSlave diagslave[100]: validateMasterIpAddr: accepting connection from 192.168.15.204 ioBroker

Dec 09 18:42:05 ModbusSlave diagslave[100]: .#015Slave 1: readInputDiscretes from 1, 16 references

Dec 09 18:42:05 ModbusSlave diagslave[100]: .#015Slave 1: readHoldingRegisters from 7, 2 references

Dec 09 18:42:06 ModbusSlave diagslave[100]: .#015Slave 1: writeHoldingRegisters from 7, 1 references

Dec 09 18:42:06 ModbusSlave diagslave[100]: .#015Slave 1: readHoldingRegisters from 7, 1 references

Dec 09 18:42:06 ModbusSlave diagslave[100]: .#015Slave 1: readHoldingRegisters from 8, 1 references

Dec 09 18:42:06 ModbusSlave diagslave[100]: .#015Slave 1: readCoils from 11, 1 references

Dec 09 18:42:32 ModbusSlave diagslave[100]: .

...

hier im syslog kann man nachschauen was der diagslave so treibt.

Im syslog stehen sehr viel mehr Informationen, deshalb erscheint es etwas unübersichtlich.

Mein Intel-NUC PROXMOX Mini-PC --> mit Modbus/TCP Verbindungen von verschiedenen SmartHome über diagslave zum CMI und zur UVR16xx Umgebung

Wer es ganz genau wissen will, welche ModBus/TCP - Kommunikation zwischen den einzelnen Komponenten wie CMI, diagslave, iobroker, python-client stattfindet, kann auch mit dem tool tcpdump die einzelnen Modbus-Befehle im Hex-Format sichtbar machen.

Ich lasse dazu in der console vom LXC Container(194) ModbuSlave einen speziell für TCP-Pakete parametrisierten tcpdump

(tcpdump -l -i net2 -vvX proto 6 | cat) laufen,

der auf dem Netzwerkgerät net2 lauscht und alle TCP-Pakete mit den Modbus-Befehlen (protokoll 6) mitliest

und somit die TCP-Pakete von dem ganzen ModBus/TCP-Verkehr auf der diagslave (VM) anzeigen kann.

Auffallend ist, dass bei den TCP-Paketen zwischen CMI und diagslave die ersten beiden Bytes vom Modbus-Header (00 00) sind. Bei allen anderen TCP-Paketen ist in den ersten beiden Bytes eine ID enthalten.

Die weiteren Infos zu den tcpdump-TCP-Paketen befinden sich im Dateianhang.

Das Modbus-Thema beim CMI ist etwas komplex und nicht einfach und übersichtlich darzustellen und zu beschreiben.

Ich habe mich mit dem Thema beschäftigt, weil es immer wieder Probleme mit Modbus/TCP-Verbindung

im direkten Kontakt zum CMI (Control and Monitoring Interface) gibt.

Mit dem dazwischengeschalteten diagslave funktionieren die Modbus/TCP-Verbindungen übers Netzwerk in die Aussenwelt sehr gut.

Gruß

Jürgen

Hallo Karl,

ja, das ist eher zufällig, denn ich bin schon eine Weile am forschen mit einem Modbus-Slave für meinen kleinen ESP32, um damit direkt per WLan aus dem Heizraum zusätzliche Werte von digitalen Sensoren (DS18x20 1wire-Sensoren) oder vom Lamdacheck in die UVR über das CMI reinzubekommen.

Die UVR hat ja bekanntlich 16 normale Eingänge.

Und am CMI hat man 64 analoge Modbus-Eingangsregister für 64 analoge Eingangswerte, also theoretisch für 64 digitale DS18x20 1wire-Sensoren, von denen die Temp-Werte direkt ins Modbus-Eingangsregister geschrieben werden können.

Und die will ich in Zukunft mehr nutzen.

Zum Testen hab ich dann mal alles was Modbus/TCP kann, an das CMI angeschlossen.

Mit dem NUC und PROXMOX kann ich ja jede Menge VM's mit den verschieden Smarthome-Lösungen parallel laufen lassen zum Daten senden ans CMI.

Das ist natürlich schon eine tolle Sache und mit wenig Aufwand zu realisieren.

Dann hab ich gleich noch die ganzen Einstellungen von den verschiedenen Smarthomes und dem diagslave dokumentiert.

Gruß

Jürgen

Hallo Karl,

es ist fast egal mit welchem Linux deinen LXC Container laufen lässt. Ist Erfahrungssache. Ich arbeite schon sehr lange mit Ubuntu und den LTS - Versionen.

Die aktuellste Ubuntu-Version mit Long-Term-Support (LTS) heißt "Focal Fossa 20.04" und ist im April 2020 erschienen.

Wie bei LTS-Versionen üblich, wird diese Ubuntu-Version 5 Jahre lang mit Sicherheitsaktualisierungen versorgt, deutlich länger als die Standard-Version von Ubuntu.

Wenn ich aktuell bleiben will, dann muss ich alle 5 Jahre die Version wechseln, ansonsten nicht.

Das wichtigste bei VM - Maschinen ist der grosse Arbeitsspeicher. Danach die schnelle Festplatte und erst dann die CPU.

Und Swapping ist das schlimmste was passieren kann. Da wird Arbeitsspeicher auf die Festplatte ausgelagert und dann wieder zurückgespielt, das bremst die gesamte

Systemgeschwindigkeit leider sehr.

Also bei deinem System fehlt es an RAM. Die 16 GB sind zu wenig. Ist ja kein Problem. Beim NUC hast ja 2 Steckplätze und kannst theoretisch bis zu 32GB grosse Speicher-Module reinstecken.

Was hast im Monent drin 2 * 8GB oder 1* 16GB. Wenn 2* 8 drin hast dann würde ich ein grosses 32GB Modul kaufen und dann 1*32 + 1*8 reistecken und dann hast 40GB RAM.

Damit läuft die Kiste schonmal deutlich schneller.

Das nächste ist die SSD-Platte. Da hat der NUC auch den schnellen M.2-Bus. Der ist um vielfaches schneller als der ATA-Bus und die viel kleinere Festplatte zum fast gleichen Preis.

Und in den einzelnen VM's kannst ja alles (RAM, CPU-Core, Festplattengrösse) manuell jederzeit ändern und so opimal wie möglich einstellen, damit keine Ressourcen verplemperst.

So und zur Neuanlage (create CT) :

ja, disk 4gb, RAM 1gb, 1CPU, LXC-Container

Bei der Netzwerkkarte vmbr0 lassen und DHCP zuerst einstellen.

ggf. noch zum einrichten die firewall abschalten und später wieder zuschalten.

Später wenn der LXC-Container fertig installiert ist und diagslave korrekt läuft,

dann kannst in der console mit ifconfig die aktuelle ip-Adresse anzeigen lassen, damit weisst was in den Programmen eintragen musst.

Und wenn am LXC-Container nix mehr ändern musst und alle Zugriffe von den Programmen iobroker..usw und CMI ordentlich laufen,

dann kannst manuell umstellen von DHCP auf statisch und eine feste ip_adresse eingeben,

damit sich die ip-Adresse beim nächsten durchstarten nicht mehr ändert.

Gruß

Jürgen

Hallo Karl,

also VM 220 löschen und nochmal neu anlegen.

Screenshots sind im Dateianhang.

Die 4 GB diskspace sind vollkommen ausreichend. Es sind von den 4GB noch 3 GB frei für diagslave.. wie du siehst.

Diskspace nur vergrössern nachträglich, verkleinern geht nicht so einfach.

Am besten klein anfangen und dann bei Bedarf vergrössern.

Gruß

Jürgen

Ubuntu 20.04 LTS diagslave tty1

diagslave login: root

Password:

Welcome to Ubuntu 20.04 LTS (GNU/Linux 5.4.34-1-pve x86_64)

* Documentation: https://help.ubuntu.com

* Management: https://landscape.canonical.com

* Support: https://ubuntu.com/advantage

The programs included with the Ubuntu system are free software;

the exact distribution terms for each program are described in the

individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by

applicable law.

root@diagslave:~# df -h

Filesystem Size Used Avail Use% Mounted on

/dev/mapper/pve-vm--193--disk--0 3.9G 756M 3.0G 21% /

none 492K 0 492K 0% /dev

tmpfs 32G 0 32G 0% /dev/shm

tmpfs 6.3G 104K 6.3G 1% /run

tmpfs 5.0M 0 5.0M 0% /run/lock

tmpfs 32G 0 32G 0% /sys/fs/cgroup

tmpfs 6.3G 0 6.3G 0% /run/user/0

root@diagslave:~#

Hallo Karl,

hab grad das Datenblatt von deinem NUC angeschaut der unterstüzt max. 32GB.

Also nur ein zweites 16GB Modul kaufen...

Intel® NUC-Kit NUC8i3BEK

Max. Speichergröße (abhängig vom Speichertyp)

32 GB

Nein, damit löscht nur die Netzwerk-Karte, ..sorry ..

Zum löschen die VM220 zuerst stoppen ,herunterfahren

und dann in der Zeile ziemlich rechts oben , links neben help, das more-Fenster öffnen und dort remove anklicken.

Dann geht wieder ein Fenster auf und du musst die ID eingeben die du löschen willst (220) bei dir und dann wird erst gelöscht.

Gruß

Jürgen

Hallo Karl,

die ganzen Befehle die in der Konsole vom LXC Container für den diagslave ausgeführt werden müssen, benötigen Root-Rechte.

In unserem Fall meldest dich als root an, dann werden die anschlissenden Befehle mit root-Rechten ausgeführt.

So solltest das auch machen.

Es gibt natürlich auch die Möglichkeit das ganze mit einem normalen User auszuführen und dann vor jeden Befehl das sudo davorschreiben,

dann werden die einzelnen Befehle auch mit root-Rechten ausgeführt. Aber dazu muss vorher auch richtig ein User für diese Aufgaben angelegt werden.

In dem Fall von unserem LXC Container für den diagslave ist nur ein einmaliges installieren vom diagslave notwendig, anschliessend brauchst nie wieder was

im LXC Container zu ändern. Deshalb ist es in diesem Fall besser als root einmalig anmelden und die ganzen Befehle einmalig als root auszuführen.

Wenn du einen anderen user als den user root verwenden willst, dann müssen in der Datei diagslave.service die Pfade für den entsprechenden

user geändert werden. Ich habe das ganze für den user root definiert. Um weitere Fehler zu vermeiden würde ich mit root arbeiten.

Gruß

Jürgen

Hallo Karl,

ja so wie es aussieht weist die Fehlermeldung beim "apt install mc" darauf hin dass einige pakete nicht gefunden worden sind und somit nicht installiert wurden.

In so einem Fall aktualisiert man die Paketlisten mit dem Befehl "apt update"

Zur weiteren Fehlersuche hab ich einen LXC Container mit debian10 template installiert und die Paketlisten aktualisiert.

Dabei kamen Hinweise, dass die Version vom debian10 template sich von Stable nach Oldstable geändert hat.

Debian GNU/Linux 10 diagslave2 tty1

diagslave2 login: root

Password:

Linux diagslave2 5.4.34-1-pve #1 SMP PVE 5.4.34-2 (Thu, 07 May 2020 10:02:02 +0200) x86_64

The programs included with the Debian GNU/Linux system are free software;

the exact distribution terms for each program are described in the

individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent

permitted by applicable law.

root@diagslave2:~# apt update

Get:1 http://ftp.debian.org/debian buster InRelease [122 kB]

Get:2 http://security.debian.org buster/updates InRelease [65.4 kB]

Get:3 http://ftp.debian.org/debian buster-updates InRelease [51.9 kB]

E: Repository 'http://security.debian.org buster/updates InRelease' changed its 'Suite' value from 'stable' to 'oldstable'

N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.

....

Das bedeutet:

Stable

stable ist die jeweils aktuelle offizielle Version. Debian veröffentlichte seit 2000 etwa alle zwei Jahre eine neue stable.

Mit Ausnahme von Sicherheitsaktualisierungen wird an den in ihr enthaltenen Paketen nichts mehr verändert.

stable gilt daher als geeigneter Kandidat für Server-Systeme, die lange Zeit zuverlässig laufen müssen.

Vor der Veröffentlichung werden für einige Monate mit hoher Priorität die als schwerwiegend eingestuften Fehlfunktionen beseitigt.

In dieser Zeit werden keine großen Versionssprünge in Paketen oder neue Pakete akzeptiert.

Kurz vor einer Debian-Veröffentlichung repräsentiert stable in Bezug auf Software-Versionen daher den Stand von vor etwa zweieinhalb Jahren.

Debian Squeeze mit Xdm

Oldstable

oldstable ist der Vorgänger der jeweils aktuellen stable, solange Sicherheitsupdates zur Verfügung gestellt werden.

Debian empfiehlt zwar, mit der jeweils aktuellen stable zu arbeiten, unterstützt oldstable aber noch mindestens ein weiteres Jahr mit Sicherheitsaktualisierungen.

Debian Buster mit Gnome, Gnome-Terminal und Firefox

Also das debian10 template würde ich nicht mehr benutzen, da es nicht mehr 100%ig unterstüzt wird.

Ist aber kein Problem.

Ich habe dann einen neuen LXC Container mit debian11 template installiert, dem aktuellen (stable) debian template.

Und mit dem ist dann die Installation von diagslave fehlerfrei gelaufen.

Ich kann dir nur das von mir verwendete ubuntu20 template empfehlen, damit hab ich nur gute Erfahrungen gemacht.

Mit dem habe ich 16 LXC Container angelegt und darauf alle SmartHome-Systeme und sonstigen Server(MQTT, Modbus, Datenbanken usw.) zum laufen gebracht ohne Probleme.

Gruß

Jürgen

Hallo Karl,

super, dann hast es ja jetzt geschafft den diagslave zum laufen zu bringen.

Gut Ding braucht Weil, heisst es.

Ja, für sonstige Arbeiten auf der console verwende ich immer das "schweizer Taschenmesser", damit ist der mc (midnight-commander) gemeint.

Damit kannst am einfachsten und schnellsten im System herumnavigieren und auch ins /var/log/ Verzeichnis wechseln und die syslog-datei lesen.

Ansonsten kannst auch alles mit linux Befehlen machen.

ins /var/log/ Verzeichnis wechseln mit cd /var/log

und syslog-datei lesen mit cat syslog

Jede LXC oder jede VM kann man sich als eigenständigen Rechner vorstellen.

Theoretisch kannst in jeder einzelnen LXC oder VM ein anderes Linux laufen lassen. Die dürfen sich gegenseitig nicht stören.

Bei den VM's bist noch viel flexibler, da kannst alle x86er linux oder andere OS-systeme die für x86er-Architektur gemacht sind verwenden

und selber als iso-datei in dein Proxmos-Laufwerk hochladen.

Ich habe z.B. auch eine externe iso-datei vom Raspi-OS (x86er-Version) hochgeladen, das gibts inzwischen ja auch.

Damit hab ich auch ein Raspi-OS in einer VM laufen mit Desktop-Oberfläche, mit viel mehr Performance.

Für jeden service, so auch für den diagslave-service gibt es drei Befehle.

Du brauchst normalerweise nicht rebooten, sondern service stoppen und service starten,

genauso wie im iobroker die Modbus-Instanz auch starten und stoppen kannst.

service diagslave start

service diagslave stop

service diagslave status

Mit ifconfig auf der console kannst dir die ip-Adresse von der diagslave-LXC anzeigen lassen, die kann sich beim rebooten mit DHCP-Einstellungen ändern.

Wenn irgendwelche Ungereimtheiten auftauchen, dann immer die logs anschauen vom iobroker und die Einträge im syslog vom diagslave.

Damit solltest normalerweise den ganzen Verkehr sehen und interpretieren können.

Wenn ganz tief reinschauen willst, dann hast ja noch den speziellen tcpdump Befehl für die diagslave-LXC.

Damit kannst dann jedes TCP-Paket anschauen das der diagslave liest und schreibt von und zu jeder ip-Adresse.

Damit sollte es möglich sein alle Modbus-Aktvitäten auf dem diagslave zu interpretieren.

Warum arbeitest du zum CMI hin nicht mit port 503 ? Ich dachte du hast im iobroker den port 502 schon für den Wechselrichter in Betrieb.

Du solltest im iobroker für jede Modbus-Instanz einen eigenen port verwenden.

Dann solltest im iobroker den Master zum diagslave auf port 503 fahren. Und den diagslave mit port 503 fahren. Und CMI auch mit port 503 fahren.

Sonst sind Fehler vorprogrammiert.

Also dann den diagslave auf port 503 laufen lassen.

Musst nur in der datei diagslave.service im verzeichnis /etc/systemd/system/

mit dem nano-editor nano diagslave.service .../diagslave -m tcp -p 502 auf ..../diagslave -m tcp -p 503 ändern

und wieder speichern ctrl-O und ctrl-X

und die diagslave-LXC rebooten.

Oder den diagslave neu aufbauen mit port 503

Oder zusätzlich eine zweite diagslave-LXC für port 503 neu aufbauen, dann hast zwei verschiedene diagslave-LXC zum testen, geht alles.

So hab ich es gemacht. Ich hab mir zwei diagslave-LXC aufgebaut, eine mit port 502 und eine mit port 503.

Dann kannst in Ruhe alles ausprobieren.

Gruß

Jürgen

Hallo Karl,

im CMI muss der modbus-port auch von 502 nach 503 geändert werden.

aber das hast bestimmt schon gemacht. (im letzten Bild stand er noch auf 502)

Wenn das cmi die ipadresse 192.168.2.20 hat,

dann sieht man im syslog das "readCoils from 2".

Da liest das CMI vom diagslave von adresse1, das wäre ok.

Welcher Wert gelesen wird, das sieht man hier nicht.

Wo ist der schreibbefehl vom iobroker ? "writeCoils from 2" ?

welche ip-Adresse hat der iobroker?

schau mal ob da ein eintrag vom iobroker im syslog findest.

im syslog vom diagslave müssen alle connects von allen geräten (CMI und iobroker) drinstehen.

Wenn kein eintrag vom iobroker im syslog findest, dann schreibt der iobroker nix zum diagslave.

Kannst die syslogdatei hier einstellen? vorher zippen, die ist ja nicht so gross

mit ifconfig werden die interfaces angezeigt. Dein Netzwerk-interface heisst eth0.

sorry, ich habe mehrere Netzwerkkarten in meinem NUC...und habe bei mir mit net2 getestet

Bei dir muss es nicht net2 sondern eth0 heissen im tcpdump befehl

tcpdump -l -i eth0 -vvX proto 6 | cat

Gruß

Jürgen