ModBus nutzen, aber wie?

[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