ModBus nutzen, aber wie?

[stobor]

Hallo,
bei uns in der Verteilung wurde zur Wärmepumpe ein Eastron Energiemessgerät SDM630- Modbus V2 mit installiert. Das Gerät verfügt über einen ModBus Anschluss. Nun verlockt es mich, hie rüber FHEM die aktuellen Verbrauchswerte der Wärmepumpe auszulesen. Ich habe mir dazu gerade einen DSD TECH SH-U11H USB zu RS485 und RS422 Adapter bestellt. ich hoffe, dass ich diese Kombination mit FHEM verwenden kann, um den Stromverbrauch/aktuelle Leistungsaufnahme auslesen zu können.
Kann mir jemand Tipps geben, wie ich die Konfiguration vornehmen sollte? Wie muss ich ggf. Treiber installieren und FHEM konfigurieren?

Die Verbindung zwischen Slave (Energiemessgerät) und Master (USB Dongle) erfolgt tatsächlich nur über 2 Drähte? Oder muss Gnd auch mit verbunden werden?

[Aurel_B]

Ich würde GND auch verbinden, allerdings nur auf 1 Seite (als Abschirmung). Terminierung (120 Ohm Widerstand) nicht vergessen! Danach USB Adapter einstöpseln (geht unter Linux meist ohne Treiber), Gerätekennung ausfindig machen (im Idealfall /dev/serial/by-id/ falls hochwertiger Adapter, ansonsten unter /dev/serial/by-path/). Baudrate, Parity und Stopbit von deinem SDM630 ausfindig machen (oft 9600,n,1) und Adapter unter FHEM einrichten (Typ: Modbus). Danach ModbusAttr Device einrichten, dafür musst du die Modbus ID von deinem Stromzähler kennen (oft 1). Und dann erste Register einrichten. Einige Minuten in der Doku lesen sollte Klarheit verschaffen.
Falls es nicht klappt: USB Adapter an dein Laptop ran, QModMaster https://sourceforge.net/projects/qmodmaster/ herunterladen und damit versuchen, ein Register auszulesen. Geht rascher für die Fehlersuche.

[stobor]

Mega! Danke. Das probiere ich, sobald alle Teile da sind.
120 Ohm kommen an beide Enden, oder?

[Nobbynews]

Oder einfach mal das Modul zum SDM630DM ausprobieren.
https://forum.fhem.de/index.php?topic=25315.msg274011#msg274011

[Aurel_B]

120 Ohm kommen an beide Enden. Leider haben die wenigsten Geräte diesen Abschlusswiderstand eingebaut (kann man manchmal mit einem Jumper aktivieren)...

[stobor]

Ich würde GND auch verbinden, allerdings nur auf 1 Seite (als Abschirmung). Terminierung (120 Ohm Widerstand) nicht vergessen! Danach USB Adapter einstöpseln (geht unter Linux meist ohne Treiber), Gerätekennung ausfindig machen (im Idealfall /dev/serial/by-id/ falls hochwertiger Adapter, ansonsten unter /dev/serial/by-path/). Baudrate, Parity und Stopbit von deinem SDM630 ausfindig machen (oft 9600,n,1) und Adapter unter FHEM einrichten (Typ: Modbus). Danach ModbusAttr Device einrichten, dafür musst du die Modbus ID von deinem Stromzähler kennen (oft 1). Und dann erste Register einrichten. Einige Minuten in der Doku lesen sollte Klarheit verschaffen.
Falls es nicht klappt: USB Adapter an dein Laptop ran, QModMaster https://sourceforge.net/projects/qmodmaster/ herunterladen und damit versuchen, ein Register auszulesen. Geht rascher für die Fehlersuche.

Ich habe jetzt einmal QModMaster installiert und ein wenig herumprobiert - bin in der Thematik nicht so fit.
Ich kann Werte abfragen, auch wenn ich die Ergebnisse nicht wirklich mit den auf dem Display des SDM630 angezeigten Werten übereinstimmen:

Du darfst diesen Dateianhang nicht ansehen.

Du darfst diesen Dateianhang nicht ansehen.

Das war eine Beispiel-Abfrage aus der SDM-Doku:

Du darfst diesen Dateianhang nicht ansehen.

Ich hätte erwartet, dass ich in der QModMaster Ausgabe irgendwie den auf dem Display angezeigten Strom-Wert wiederfinde ( es sollte ja wohl die 10,62A kommen, oder?).

Mit FHEM habe ich das Gerät noch nicht verbunden. Das würde ich machen, sobald ich sicher bin, dass die Kommunikation vernünftig funktioniert, bzw. , dass ich das verstehe. Oder reicht das als Test so schon aus?

[holle75]

Schau doch tatsächlich mal in den von Nobbynews verlinkten Beitrag und folgend rein? https://forum.fhem.de/index.php?topic=133276.msg1273438#msg1273438

Da wird so ziemlich alles im Detail erklärt.

Warum den Umweg und nicht direkt die Herausforderung in fhem angehen?

Die SDM´s laufen, sogar mit noch einigen mehr Geräten am selben Bus, vorzüglich.

Als Anregung auf Schnell ohne jetzt gedanklich wieder komplett drin zu sein ein SDM220 (ID´s und IODevice nicht vergessen anzupassen/anzulegen)

RAW

Code Auswählen Erweitern

defmod Xtender_AC_out ModbusSDM220M 2 5
attr Xtender_AC_out event-min-interval Power__W:900,Voltage__V:900,statEnergy_total__kWhDay:900
attr Xtender_AC_out event-on-change-reading Power__W:20,Voltage__V:3,Energy_total__kWh:0.1,statEnergy_total__kWhDay:0.1,statEnergy_total__kWhMonth:0.1,.*Last.*
attr Xtender_AC_out event-on-update-reading Power__W,Voltage__V,statEnergy_total__kWhDay
attr Xtender_AC_out polldelay-Voltage__V 1

Code Auswählen Erweitern

defmod Eastron Modbus /dev/ttyUSB1@9600,8,E,1
attr Eastron busDelay 0.5
attr Eastron dropQueueDoubles 1
attr Eastron profileInterval 120
attr Eastron skipGarbage 1
attr Eastron timeoutLogLevel 4
attr Eastron verbose 2

[Aurel_B]

Ich hätte erwartet, dass ich in der QModMaster Ausgabe irgendwie den auf dem Display angezeigten Strom-Wert wiederfinde ( es sollte ja wohl die 10,62A kommen, oder?).

Hast du schon mit den Datentypen rumgespielt? Könnte auch ein Float sein etc.

[stobor]

Ich habe den SH-U11H nun mal an meine Kiste angesteckt. Aber leider finde ich das neue Device weder in dev/serial/by-id noch in dev/serial/by-path. In diesen Ordnern erscheint kein neues Gerät.

lsusb zeigt das Gerät allerdings an:

Code Auswählen Erweitern

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 005: ID 8087:0aaa Intel Corp.
Bus 001 Device 008: ID 067b:23a3 Prolific Technology, Inc.
Bus 001 Device 006: ID 03eb:204b Atmel Corp. LUFA USB to Serial Adapter Project
Bus 001 Device 004: ID 2109:2812 VIA Labs, Inc. VL812 Hub
Bus 001 Device 003: ID 03eb:204b Atmel Corp. LUFA USB to Serial Adapter Project
Bus 001 Device 002: ID 2341:0042 Arduino SA Mega 2560 R3 (CDC ACM)
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

In der Anleitung des Herstellers steht u.a.:

Code Auswählen Erweitern

Linux Kernel 5.5 and above already includes built-in drivers for PL2303G Chip.

If you's Linux kernel is v2.6.15 ~v5.4, 
Please update the PL2303G Linux driver in the following way.

1. terminal // open terminal AP. S1.png
2. uname -r // found out the nearest Linux kernel version first , S2.png
3. make all // make new driver, if you have meet error message during make kernel driver, please send email to us. , S3.png
4. sudo cp pl2303.ko /lib/modules/$(uname -r)/kernel/drivers/usb/serial
// copy new driver to kernel. S4.png
5. sudo gedit /etc/modules // edit modules ,  S5.png
6. pl2303 // add pl2303, save, close modules   , S6.png
7. reboot // reboot OS , S7.png
8. plug in new cable, and then enjoy!
Punkt 3 (make all) klappt bereits nicht:
make: *** No rule to make target 'all'.  Stop.


uname -r liefert: 4.15.0-197-generic

Im Verzeichnis /lib/modules/4.15.0-197-generic/kernel/drivers/usb/serial liegt übrigens schon eine pl2303.ko.

Ohne Einträge im Verzeichnis by-id oder by-path werde ich vermutlich ncihts.

Kann mir da jemand helfen?
Danke

[Aurel_B]

Punkt 3 (make all) klappt bereits nicht:
make: *** No rule to make target 'all'.  Stop.

Hmmm, bist du im richtigen Verzeichnis? Liegt dort eine Makefile?

Im Verzeichnis /lib/modules/4.15.0-197-generic/kernel/drivers/usb/serial liegt übrigens schon eine pl2303.ko.

Das ist komisch, vielleicht passt der Treiber nicht zu deinem Gerät (Device-ID oder so nicht gelistet). Ich verwende USB-to-RS483 Adapter von Waveshare, die klappen alle ohne Probleme und werden direkt erkannt.

[stobor]

Ich bin leider kein Linux-Experte. Vielleicht habe ich etwas übersehen/missverstanden. Ich sollte wohl noch in des OS-spezifische Verzeichnis wechseln , vermute ich. Dann passiert etwas mehr:

Code Auswählen Erweitern

jay@nuc:~/PL2303G_Linux_Driver_v1.0.6$ uname -r
4.15.0-197-generic
jay@nuc:~/PL2303G_Linux_Driver_v1.0.6$ cd 4.15_ok/
jay@nuc:~/PL2303G_Linux_Driver_v1.0.6/4.15_ok$ ls
Makefile  pl2303.c  pl2303.h
jay@nuc:~/PL2303G_Linux_Driver_v1.0.6/4.15_ok$ make all
make -C /lib/modules/4.15.0-197-generic/build M=/home/jay/PL2303G_Linux_Driver_v1.0.6/4.15_ok modules
make[1]: Entering directory '/usr/src/linux-headers-4.15.0-197-generic'
arch/x86/Makefile:161: CONFIG_X86_X32 enabled but no binutils support
make[1]: gcc: Command not found
  CC [M]  /home/jay/PL2303G_Linux_Driver_v1.0.6/4.15_ok/pl2303.o
/bin/sh: 1: gcc: not found
scripts/Makefile.build:340: recipe for target '/home/jay/PL2303G_Linux_Driver_v1.0.6/4.15_ok/pl2303.o' failed
make[2]: *** [/home/jay/PL2303G_Linux_Driver_v1.0.6/4.15_ok/pl2303.o] Error 127
Makefile:1594: recipe for target '_module_/home/jay/PL2303G_Linux_Driver_v1.0.6/4.15_ok' failed
make[1]: *** [_module_/home/jay/PL2303G_Linux_Driver_v1.0.6/4.15_ok] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-4.15.0-197-generic'
Makefile:4: recipe for target 'all' failed
make: *** [all] Error 2
jay@nuc:~/PL2303G_Linux_Driver_v1.0.6/4.15_ok$

Aber failed ist wohl trotzdem nicht toll, oder?

Ich habe jetzt noch GCC installiert: sudo apt-get install build-essential

Danach kommt:

Code Auswählen Erweitern

jay@nuc:~/PL2303G_Linux_Driver_v1.0.6/4.15_ok$ make all
make -C /lib/modules/4.15.0-197-generic/build M=/home/jay/PL2303G_Linux_Driver_v1.0.6/4.15_ok modules
make[1]: Entering directory '/usr/src/linux-headers-4.15.0-197-generic'
  CC [M]  /home/jay/PL2303G_Linux_Driver_v1.0.6/4.15_ok/pl2303.o
cc1: error: code model kernel does not support PIC mode
scripts/Makefile.build:340: recipe for target '/home/jay/PL2303G_Linux_Driver_v1.0.6/4.15_ok/pl2303.o' failed
make[2]: *** [/home/jay/PL2303G_Linux_Driver_v1.0.6/4.15_ok/pl2303.o] Error 1
Makefile:1594: recipe for target '_module_/home/jay/PL2303G_Linux_Driver_v1.0.6/4.15_ok' failed
make[1]: *** [_module_/home/jay/PL2303G_Linux_Driver_v1.0.6/4.15_ok] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-4.15.0-197-generic'
Makefile:4: recipe for target 'all' failed
make: *** [all] Error 2

Im Verzeichnis /home/jay/PL2303G_Linux_Driver_v1.0.6/4.15_ok liegen diese Dateien:

• Makefile
• pl2303.c
• pl2303.h

Im make-file steht dies:

Code Auswählen Erweitern

obj-m    += pl2303.o
all:
    make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
clean:
    make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean

Hat noch jemand eine Idee?

[stobor]

Punkt 3 (make all) klappt bereits nicht:
make: *** No rule to make target 'all'.  Stop.

Hmmm, bist du im richtigen Verzeichnis? Liegt dort eine Makefile?

Im Verzeichnis /lib/modules/4.15.0-197-generic/kernel/drivers/usb/serial liegt übrigens schon eine pl2303.ko.

Das ist komisch, vielleicht passt der Treiber nicht zu deinem Gerät (Device-ID oder so nicht gelistet). Ich verwende USB-to-RS483 Adapter von Waveshare, die klappen alle ohne Probleme und werden direkt erkannt.

Ich habe jetzt auch noch mal das Linux aktualisiert (auf Ubuntu 20.04.6). Das USB Gerät taucht einfach nicht in der Liste (by-id / by-path) auf. Da muss es doch erscheinen, oder?
Welchen Adapter genau setzt Du denn ein, so dass er ohne weitere Installation läuft? Nutzt Du das Gerät auch für ModBus?

[Aurel_B]

Ich verwende 3 von diesen hier https://www.waveshare.com/product/iot-communication/wired-comm-converter/rs232-rs485-can/usb-to-rs232-485-422-ttl.htm seit fast 2 Jahren, absolut keine Probleme: sie haben eine eindeutige ID (wichtig wenn du mehrere Adapter hast) und funktionieren einwandfrei. Ich könnte mir vorstellen, dass dieser Adapter hier https://www.waveshare.com/product/iot-communication/wired-comm-converter/rs232-rs485-can/usb-to-rs485.htm auch gut funktioniert, kostet nur die Hälfte.
Was ich NICHT machen würde: irgendwelche Billigadapter mit CH340 Chip o.ä. nehmen, die haben z.B. keine eindeutige Geräte ID und deine Konfiguration muss dann u.U. angepasst werden falls du den Adapter an einem anderen USB Port einsteckst (oder einen Hub dazwischen schaltest etc).

Ich verwende die Adapter ausschliesslich für Modbus.

[stobor]

Ich sehe den Adapter nun auch - juhu!
Ich hatte im Internet noch einen Hinweis gefunden und daraufhin CuteCom installiert: https://z12.vfdb.org/wp-content/uploads/2015/04/Um-das-DRA818-Modul-über-den-PC-programmieren-zu-können-muss-eine1.pdf
Nun erscheint auch der Adapter:
by-id: usb-Prolific_Technology_Inc._USB-Serial_Controller_BLAZb113318-if00-port0
by-path: pci-0000:00:15.0-usb-0:4.4:1.0-port0

Jetzt geht es weiter, um das Ding in FHEM zu bekommen...

[stobor]

Ich habe nun meinen USB-zu-RS482/ModBus Adapter (DSD TECH SH-U11H) mit meinem System verbinden können.

Unter Linux wird der Adapter nun angezeigt:
by-id: usb-Prolific_Technology_Inc._USB-Serial_Controller_BLAZb113318-if00-port0
by-path: pci-0000:00:15.0-usb-0:4.4:1.0-port0

Über eine 2-Draht-Leitung ist an dem Rs482-Adapter ein Eastron SDM630-Modbus V2 Energiezähler angeschlossen.

Wie muss nun die fhem.cfg konfiguriert werden? Ich durchblicke die Doku nicht so ganz. In einigen Beiträgen werden bspw. Module SDM630M verwendet, die habe ich aber nicht.
Außerdem habe ich nirgends die vollständige Beschreibung über die Definition der Schnittstelle gefunden. Der SDM630 ist bei mir so eingestellt:

• Adresse: 002
• 9600 Baud
• Parität: none
• Stop: 1

Kann mir jemand schreiben, wie der USB-2-Seriell-Adapter und der SDM630 in der fhem.cfg konfiguriert werden muss?

Vielen Dank

[stobor]

Die Verbindung meines Eastron SDM630-Modbus V2 über den USB-zu-RS482/ModBus Adapter (DSD TECH SH-U11H) hat geklappt  .
Leider kommen immer nach ein paar Minuten Timepout-Fehler, und die Werte werden nicht mehr aktualisiert:

Code Auswählen Erweitern

023.06.06 09:42:35 3: ModBusUSBAdapter: Timeout waiting for a modbus response, read buffer empty,
request: id 2, read fc 4 i240, len 30, master device HA_SDM630M_1, reading THD_Current_L1__prz (getUpdate for combined i240 len 2 THD_Current_L1__prz with i242 len 2 THD_Current_L2__prz and i244 len 2 THD_Current_L3__prz and i248 len 2 THD_Voltage_avr_LN__prz and i250 len 2 THD_Current_avr__prz and i254 len 2 PowerFactor_inverted and i258 len 2 Current_L1_demand__A and i260 len 2 Current_L2_demand__A and i262 len 2 Current_L3_demand__A and i264 len 2 Current_Max_L1_demand__A and i266 len 2 Current_Max_L2_demand__A and i268 len 2 Current_Max_L3_demand__A), queued 10.01 secs ago, sent 2.00 secs ago
2023.06.06 09:42:35 5: ModBusUSBAdapter: StartQueueTimer called from ResponseTimeout sets internal timer to process queue in 0.000 seconds
2023.06.06 09:42:35 5: ModBusUSBAdapter: ProcessRequestQueue called from Fhem internal timer as queue:ModBusUSBAdapter, qlen 1, request: request: id 2, read fc 4 i334, len 30, master device HA_SDM630M_1, reading THD_Voltage_L1_L2__prz (getUpdate for combined i334 len 2 THD_Voltage_L1_L2__prz with i336 len 2 THD_Voltage_L2_L3__prz and i338 len 2 THD_Voltage_L3_L1__prz and i340 len 2 THD_Voltage_avr_LL__prz and i342 len 2 Energy_total__kWh and i344 len 2 Energy_total__kVArh and i346 len 2 Energy_L1_import__kWh and i348 len 2 Energy_L2_import__kWh and i350 len 2 Energy_L3_import__kWh and i352 len 2 Energy_L1_export__kWh and i354 len 2 Energy_L2_export__kWh and i356 len 2 Energy_L3_export__kWh and i358 len 2 Energy_L1_total__kWh and i360 len 2 Energy_L2_total__kWh and i362 len 2 Energy_L3_total__kWh), queued 10.01 secs ago
2023.06.06 09:42:35 5: ModBusUSBAdapter: checkDelays clientSwitchDelay is not relevant
2023.06.06 09:42:35 5: ModBusUSBAdapter: checkDelays sendDelay, last send to same device was 1.999 secs ago, required delay is 0.7
2023.06.06 09:42:35 5: ModBusUSBAdapter: checkDelays commDelay, last communication with same device was 56351.735 secs ago, required delay is 0.7
2023.06.06 09:42:35 5: ModBusUSBAdapter: checkDelays busDelayRead, last activity on bus was 56351.736 secs ago, required delay is 0
2023.06.06 09:42:35 4: ModBusUSBAdapter: ProcessRequestQueue (V4.4.14 - 30.1.2023) qlen 1, sending 0204014e001e11da via /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller_BLAZb113318-if00-port0@9600,8,N,1, read buffer empty,
request: id 2, read fc 4 i334, len 30, master device HA_SDM630M_1, reading THD_Voltage_L1_L2__prz (getUpdate for combined i334 len 2 THD_Voltage_L1_L2__prz with i336 len 2 THD_Voltage_L2_L3__prz and i338 len 2 THD_Voltage_L3_L1__prz and i340 len 2 THD_Voltage_avr_LL__prz and i342 len 2 Energy_total__kWh and i344 len 2 Energy_total__kVArh and i346 len 2 Energy_L1_import__kWh and i348 len 2 Energy_L2_import__kWh and i350 len 2 Energy_L3_import__kWh and i352 len 2 Energy_L1_export__kWh and i354 len 2 Energy_L2_export__kWh and i356 len 2 Energy_L3_export__kWh and i358 len 2 Energy_L1_total__kWh and i360 len 2 Energy_L2_total__kWh and i362 len 2 Energy_L3_total__kWh), queued 10.02 secs ago
2023.06.06 09:42:35 5: ModBusUSBAdapter: Send called from ProcessRequestQueue
2023.06.06 09:42:35 5: DevIo_SimpleWrite ModBusUSBAdapter: 0204014e001e11da
 Die Verbindungsleitung (ca. 2m) ist abgeschirmt (am USB-Adapter auf Gnd gelegt). Ich hatte schon mit und ohne 120Ohm Terminierung an beiden Enden getestet. Das ergab keinen Unterschied.

In FHEM habe ich bisher diese Settings:

Code Auswählen Erweitern

define ModBusUSBAdapter Modbus /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller_BLAZb113318-if00-port0@9600,8,N,1
setuuid ModBusUSBAdapter 6479081c-f33f-2cfb-4355-7c2c3d9340c8fada
attr ModBusUSBAdapter room ModBus
attr ModBusUSBAdapter verbose 5

define HA_SDM630M_1 ModbusSDM630M 2 60
setuuid HA_SDM630M_1 6479081c-f33f-2cfb-cb6f-8dd2c90129580e77
attr HA_SDM630M_1 userattr IODev
attr HA_SDM630M_1 IODev ModBusUSBAdapter
attr HA_SDM630M_1 room ModBus
attr HA_SDM630M_1 verbose 5
 
Hat jemand eine Idee?

Im Verzeichnis /opt/fhem/FHEM liegen u.a.

• 98_Modbus.pm - 2023-02-01 19:04:11Z StefanStrobel
• 98_ModbusAttr.pm - 2022-04-14 16:52:16Z StefanStrobel
• 98_ModbusSDM630M.pm - letzter Eintrag im Changelog der Datei vom 2016-02-28

Ich habe mir jetzt parallel einmal den von ansgru empfohlenen Adapter (https://www.waveshare.com/product/iot-communication/wired-comm-converter/rs232-rs485-can/usb-to-rs232-485-422-ttl.htm) bestellt. Mal sehen, wann der kommt und ob der was ändert.

[Aurel_B]

Puuh, das mit den Timeouts könnte verschiedene Ursachen haben. Was passiert denn, wenn du deinen USB Adapter mal an ein Laptop anschliesst, QModMaster startest und irgendein Register regelmässig (z.B. alle 5s) abfrägst? Läuft er dann auch in ein Timeout rein? Wenn ja könntest du Linux/FHEM schonmal ausschliessen.
Das ModbusSDM630M Modul kenne ich nicht, ich verwende immer ModbusAttr. Dort musst du die Register selber konfigurieren (hat bestimmt schonmal jemand für den SDM630 gemacht), dafür ist es immer auf dem aktuellsten Stand. Das ModbusSDM630M scheint ja inoffiziell zu sein und schon länger nicht mehr aktualisiert.

Edit: ich frage meine Zähler (ABB B23) im 5 Sekundentakt ab. Einer der Zähler hat 1-2x am Tag kurz Aussetzer, der Rest der Bande läuft ohne Probleme. ABER: der ABB braucht immer ca. 0.2s für die Verarbeitung eines Requests. Wenn die Requests zu rasch reinkommen oder zu viel auf der Leitung los ist verschluckt er sich. Ich habe daher bei allen ModbusAttr Definitionen folgendes gesetzt:

Code Auswählen Erweitern

dev-timing-commDelay 0.3
dev-timing-sendDelay 0.3

Zusätzlich auf dem Modbus Device

Code Auswählen Erweitern

clientSwitchDelay 0.4

Seither habe ich - abgesehen vom einten Zähler - keine Timeout mehr.

Bei mir kriegt auch jeder Gerätetyp einen neuen Modbus Adapter, d.h. alle ABB B23 Zähler sitzen an einem Waveshare Adapter, meine Arduinos mit RS485 Adapter an einem weiteren etc. etc.

[stobor]

Ich habe den USB-Adapter jetzt einmal am PC angeschlossen. Ich glaube, das ist ganz ok - siehe Screenshot.

Ich kann mal probieren, wenn ich anstatt des Moduls 98_ModbusSDM630M direkt ModbusAttr verwende. Hast Du da Beispiel-Settings? Ich habe derzeit keine Idee, wie das verwendet wird.

[stobor]

Puuh, das mit den Timeouts könnte verschiedene Ursachen haben. Was passiert denn, wenn du deinen USB Adapter mal an ein Laptop anschliesst, QModMaster startest und irgendein Register regelmässig (z.B. alle 5s) abfrägst? Läuft er dann auch in ein Timeout rein? Wenn ja könntest du Linux/FHEM schonmal ausschliessen.
Das ModbusSDM630M Modul kenne ich nicht, ich verwende immer ModbusAttr. Dort musst du die Register selber konfigurieren (hat bestimmt schonmal jemand für den SDM630 gemacht), dafür ist es immer auf dem aktuellsten Stand. Das ModbusSDM630M scheint ja inoffiziell zu sein und schon länger nicht mehr aktualisiert.

Edit: ich frage meine Zähler (ABB B23) im 5 Sekundentakt ab. Einer der Zähler hat 1-2x am Tag kurz Aussetzer, der Rest der Bande läuft ohne Probleme. ABER: der ABB braucht immer ca. 0.2s für die Verarbeitung eines Requests. Wenn die Requests zu rasch reinkommen oder zu viel auf der Leitung los ist verschluckt er sich. Ich habe daher bei allen ModbusAttr Definitionen folgendes gesetzt:

Code Auswählen Erweitern

dev-timing-commDelay 0.3
dev-timing-sendDelay 0.3

Zusätzlich auf dem Modbus Device

Code Auswählen Erweitern

clientSwitchDelay 0.4

Seither habe ich - abgesehen vom einten Zähler - keine Timeout mehr.

Bei mir kriegt auch jeder Gerätetyp einen neuen Modbus Adapter, d.h. alle ABB B23 Zähler sitzen an einem Waveshare Adapter, meine Arduinos mit RS485 Adapter an einem weiteren etc. etc.

Ich habe jetzt auch einfach mal Delays definiert:

Code Auswählen Erweitern

define ModBusUSBAdapter Modbus /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller_BLAZb113318-if00-port0@9600,8,N,1
attr ModBusUSBAdapter room ModBus

define HA_SDM630M_1 ModbusSDM630M 2 60
attr HA_SDM630M_1 userattr IODev
attr HA_SDM630M_1 IODev ModBusUSBAdapter
attr HA_SDM630M_1 dev-timing-commDelay 0.5
attr HA_SDM630M_1 dev-timing-sendDelay 0.5
 
Jetzt läuft das schon seit über einer Stunde
Bisher fühlt es sich so an, als ob die Delay-settings der Schlüssel zur Lösung waren...

Danke

[Aurel_B]

Das kann gut sein! Weil vom Screenshot her sieht das sehr vernünftig aus, 1 Fehler (falls das überhaupt einer war) auf > 1000 Anfragen. Kann gut sein, dass dein Zähler auch einen Delay braucht