EASTRON Zähler | Deye Hybrid-Inverter - RS485 Schnittstellen häufige Error Meldungen

[holle75]

wollte es schnell aktivieren, bekomme ein

Code Auswählen Erweitern

ModbusRS485_SDM220M can not be used as IODev, see log for details
im log

Code Auswählen Erweitern

2025.03.30 11:10:57 3: SDM220M: SetIODev from SDM220M to ModbusRS485_SDM220M but ModbusRS485_SDM220M does not exist (yet?)
2025.03.30 11:10:57 3: SDM220M: SetIODev found no usable physical modbus device
ich nehme an, da mein anderes IO Device dort sitzt, mag fhem das Device nicht anlegen.

[holle75]

.... dafür hat er das neue SDM220V1 Device automatisch auf das bestehende IO-Device gelegt, merke ich gerade. Auch interessant.
Läuft jetzt erstmal mit

[holle75]

da du noch die 3 Readings drinnen hast, kommt wieder im IO Device als Error

Code Auswählen Erweitern

timeout waiting for reply to fc 3 to id 1, h64512, len 5
der Rest was lesen angeht scheint zu funktionieren. Schalten werde ich nicht ausprobieren können.

[Nobbynews]

EDIT 27-03-2025:[/b] Das Modul 98_ModbusSDM72DMV2.pm ist noch nicht ganz fertiggestellt.

Das bisherige Modul 98_ModbusSDM72DMV2.pm habe ich 2022 erstellt.
Grundlage waren die zu diesem Zeitpunkt dokumentierten Register.
Daher würde mich jetzt mal interessieren, was daran noch nicht ganz fertiggestellt sein soll.
Ansonsten wäre es zur Abgrenzug aus meiner Sicht wünschenswert, hier für Deine Entwicklung einen anderen Namen zu wählen.

Norbert

[Burny4600]

wollte es schnell aktivieren, bekomme ein

Code Auswählen Erweitern

ModbusRS485_SDM220M can not be used as IODev, see log for details

Du hast das IO ModbusRS485_SDM220M anscheind nicht angelegt?

Code Auswählen Erweitern

define ModbusRS485_SDM220M Modbus /dev/serial/by-id/.....................@9600,8,N,1Das musst du für deine Schnittstelle noch anpassen!

Grundsätzlich kannst du auch dein IODev zum testen verwenden.

da du noch die 3 Readings drinnen hast, kommt wieder im IO Device als Error

Deaktiviere einfach in meinem Modul die drei Readings zB.

Code Auswählen Erweitern

#    "h64512" =>    {    # holding register 0xFC00
#                    # Serial Number Meter.
#                    name        => "Serial Number",            # internal name of this register in the hardware doc
#                    reading        => "Serial_Number",            # name of the reading for this value
#                    unpack        => "I*",                    # unsigned int32 pack / unpack code to convert raw values
#                    format        => '%u',                    # format string for sprintf
#                    poll        => "once",                    # only poll once after define (or after a set)
#                },
Verwende immer nur eines der drei Readings und gib mir Bescheid ob diese Reeadings dann auftauchen. Wenn sie nicht auftauchen entferne ich diese aus dem Modul.

@Nobbynews

Das bisherige Modul 98_ModbusSDM72DMV2.pm habe ich 2022 erstellt.

Hast du das für FHEM bereitgestellt! Ich denke nicht, sonst wäre das bei den FHEM-Updates bei allen aufgetaucht.

Ansonsten wäre es zur Abgrenzug aus meiner Sicht wünschenswert, hier für Deine Entwicklung einen anderen Namen zu wählen

Sorry, aber so wird das nichts. Wenn du es nur für dich verwendest, kann kein Entwickler darauf Rücksicht nehmen.

Daher würde mich jetzt mal interessieren, was daran noch nicht ganz fertiggestellt sein soll.

Ich habe angefangen alle EASTRON-Energiezähler zu vereinheitlichen, und den Meter_Code Register mit definiert, damit auch wirklich unter FHEM ersichtlich ist, ob der richtige Energiezähler ausgewählt wurde. Den Meter_Code Register gibt es nicht bei allen EASTRON-Energiezähler, speziell bei den Älteren nicht.

Bisher gab es nur das 98_ModbusSDM630M.pm Modul unter FHEM für alle EASTRON-Energiezähler. Hier fehlen viele Register und zudem ist es notwendig die Module abzugrenzen weil es ansonsten zu Fehlern am EASTRON-Energiezähler kommen kann, wenn das falsche Modul mit nicht vorhanden Registern ausgewählt wurde.
Sieh dir den Inhalt der einzelnen Module an, die ich in diesem Thread vorab bereit gestellt habe. Du kannst aber gerne dein Modul für alle Online bringen.

[Nobbynews]

@Nobbynews

Das bisherige Modul 98_ModbusSDM72DMV2.pm habe ich 2022 erstellt.

Hast du das für FHEM bereitgestellt! Ich denke nicht, sonst wäre das bei den FHEM-Updates bei allen aufgetaucht.

Ansonsten wäre es zur Abgrenzug aus meiner Sicht wünschenswert, hier für Deine Entwicklung einen anderen Namen zu wählen

Sorry, aber so wird das nichts. Wenn du es nur für dich verwendest, kann kein Entwickler darauf Rücksicht nehmen.

Daher würde mich jetzt mal interessieren, was daran noch nicht ganz fertiggestellt sein soll.

Ich habe angefangen alle EASTRON-Energiezähler zu vereinheitlichen, und den Meter_Code Register mit definiert, damit auch wirklich unter FHEM ersichtlich ist, ob der richtige Energiezähler ausgewählt wurde. Den Meter_Code Register gibt es nicht bei allen EASTRON-Energiezähler, speziell bei den Älteren nicht.

Na ja, im Forum habe ich es zur Verfügung gestellt. Link auf Beitrag habe ich geschickt. Im SVN nicht.
Lt. Statistik scheint das ja funktioniert zu haben.
Das Modul liest das Register jedenfalls als Reading "System_Meter_Code" aus.
Meine Frage zu "nicht ganz fertiggestellt" bleibt aber unbeantwortet.

[Burny4600]

Meine Frage zu "nicht ganz fertiggestellt" bleibt aber unbeantwortet.

Den SDM230M und SDM72M muss ich noch verkabeln um diese Module im Betrieb zu testen.
Zudem möchte ich die Module betreffend der Readings wegen den Timeings noch optimieren, weil es manchmal zu Lesefehlern kommt, wie du sicher in diesem Thread lesen konntest.

[Nobbynews]

weil es manchmal zu Lesefehlern kommt, wie du sicher in diesem Thread lesen konntest.

Das habe ich gelesen, natürlich.
Allerdings kann ich diese mit dem SDM72 und einem SDM120 am Bus nicht bestätigen.
Beide Zähler laufen mit den jeweiligen Modulen sehr gut.
Geschwindigkeit habe ich auf 9600Bd eingestellt. Der SDM120 kann nicht schneller.
Bei einem User gab es mal erhebliche Probleme mit dem SDM120 alle Register auszulesen. Das war aber nach einem Wechsel von 1200Bd (oder 2400Bd ?) auf 9600Bd. behoben.

[holle75]

Du hast das IO ModbusRS485_SDM220M anscheind nicht angelegt?

hatte ich, da das angelegte  IO Device mit der Hardware aber belegt ist, hat fhem es scheinbar ignoriert.

Deaktiviere einfach in meinem Modul die drei Readings zB.

war zu deiner Info

Verwende immer nur eines der drei Readings und gib mir Bescheid ob diese Reeadings dann auftauchen. Wenn sie nicht auftauchen entferne ich diese aus dem Modul.

hatte ich. Alle drei Register, jeweils separat angelegt, werfen den Error -> ich vermute, die Register gibts im SDM220m nicht.

[Nobbynews]

Readings wegen den Timeings noch optimieren, weil es manchmal zu Lesefehlern kommt

Seit Wechsel auf einen Pi 4 habe ich jetzt erstmalig wieder einen Timeout gehabt.
Dürfte aber an den vorherigen Meldungen von FreezeMon liegen.

Code Auswählen Erweitern

2025.04.03 14:35:24 1: [Freezemon] myFreezeMon: possible freeze starting at 14:35:23, delay is 1.864 possibly caused by: tmr-CODE(0x55d86c1820)(ProcessRequestQueue) tmr-Shelly_status(Shelly11) tmr-CUL_MAX_SQH(cm)
2025.04.03 14:37:25 1: [Freezemon] myFreezeMon: possible freeze starting at 14:37:23, delay is 2.859 possibly caused by: tmr-CODE(0x55d86c1820)(ProcessRequestQueue) tmr-Shelly_status(Shelly11) tmr-Shelly_status(Shelly7)
2025.04.03 14:37:25 3: ModBusLine: Timeout waiting for a modbus response, read buffer empty,
request: id 1, read fc 4 i6, len 24, master device SDM72, reading Current_L1__A (getUpdate for combined i6 len 2 Current_L1__A with i8 len 2 Current_L2__A and i10 len 2 Current_L3__A and i12 len 2 Power_L1__W and i14 len 2 Power_L2__W and i16 len 2 Power_L3__W and i18 len 2 Power_L1__VA and i20 len 2 Power_L2__VA and i22 len 2 Power_L3__VA and i24 len 2 Power_L1__VAr and i26 len 2 Power_L2__VAr and i28 len 2 Power_L3__VAr), queued 4.22 secs ago, sent 3.36 secs ago
2025.04.03 14:37:26 3: ModBusLine: readfn got data while EXPECT was set to idle: 010430000000003c911b3c3cb08eb00000000040181f5f4020250d0000000040181f5f408996ba0000000000000000405fc7090de9


[Burny4600]

Seit Wechsel auf einen Pi 4 habe ich jetzt erstmalig wieder einen Timeout gehabt.

Hast du erst jetzt auf den Pi4 gewechselt?
Welche Pi OS verwendest du?
Wieviele RS485 Schnittstellen hast du im Einsatz?

Ich verwende eine Pi4 mit Bullseye Lite 32Bit und werde jetzt auf Bookworm Lite 32Bit wechseln um weiter den Ausfall der RS485 zu testen.
Ich vermute das Problem lieg bei mir an der Kombination der eingesetzten Komponenten.
Die vierfach WaveShare RS485/USB hängt an einem Pi3+. Darauf ist ser2net im Einsatz mit der Version 4.3.11.
ser2net.yaml

Code Auswählen Erweitern


%YAML 1.1
---
# This is a ser2net configuration file, tailored to be rather
# simple.
#
# Find detailed documentation in ser2net.yaml(5)
# A fully featured configuration file is in
# /usr/share/doc/ser2net/examples/ser2net.yaml.gz
#
# If you find your configuration more useful than this very simple
# one, please submit it as a bugreport

define: &banner \r\nser2net port \p device \d [\B] (Debian GNU/Linux)\r\n\r\n

### Set all baud rates to 115200n81 by default.
# default:
#       name: speed
#       value: 9600n81
#       class: serialdev

### RS485 Port1
connection: &con4851
    accepter: tcp,44851
    enable: on
    options:
            max-connections: 1
            kickolduser: true
            telnet-brk-on-sync: true
    connector: serialdev,
               /dev/serial/by-id/usb-WCH.CN_USB_Quad_Serial_BCD697ABCD-if00,
               38400n81,local

### RS485 Port2
connection: &con4852
    accepter: tcp,44852
    enable: on
    options:
            max-connections: 1
            kickolduser: true
            telnet-brk-on-sync: true
    connector: serialdev,
               /dev/serial/by-id/usb-WCH.CN_USB_Quad_Serial_BCD697ABCD-if02,
               38400n81,local

### RS485 Port3
connection: &con4853
    accepter: tcp,44853
    enable: on
    options:
            max-connections: 1
            kickolduser: true
            telnet-brk-on-sync: true
    connector: serialdev,
               /dev/serial/by-id/usb-WCH.CN_USB_Quad_Serial_BCD697ABCD-if04,
               38400n81,local

### RS485 Port4
connection: &con4854
    accepter: tcp,44854
    enable: on
    options:
            max-connections: 1
            kickolduser: true
            telnet-brk-on-sync: true
    connector: serialdev,
               /dev/serial/by-id/usb-WCH.CN_USB_Quad_Serial_BCD697ABCD-if06,
               38400n81,local

Der Pi4 greift auf die ser2net Schnittstellte.
list ModbusRS485_1WS_EG_VR

Code Auswählen Erweitern

Internals:
   CFGFN      /media/hdd/fhem/mycfg/schnittstellen_rasp02.cfg
   DEF        192.168.17.185:44851
   DeviceName 192.168.17.185:44851
   EXPECT     idle
   FD         51
   FUUID      67b5c89b-f33f-f4d2-7223-f064a5307ca304fc
   IODev      ModbusRS485_1WS_EG_VR
   LASTOPEN   1743870609.31686
   MODE       master
   NAME       ModbusRS485_1WS_EG_VR
   NOTIFYDEV  global
   NR         501
   NTFY_ORDER 50-ModbusRS485_1WS_EG_VR
   PARTIAL   
   PROTOCOL   RTU
   STATE      opened
   TCPConn    1
   TYPE       Modbus
   devioLoglevel 3
   devioNoSTATE 1
   eventCount 103277
   nextOpenDelay 60
   QUEUE:
   READ:
     BUFFER     
   READINGS:
     2025-04-05 15:43:43   LAST_ERROR      timeout waiting for reply to fc 4 to id 1, i374, len 8
     2025-04-06 08:13:39   Profiler_Delay_sum 7.268
     2025-04-06 08:13:39   Profiler_Fhem_sum 0.389
     2025-04-06 08:13:39   Profiler_Idle_sum 21.992
     2025-04-06 08:13:39   Profiler_Read_sum 0.017
     2025-04-06 08:13:39   Profiler_Send_sum 0.026
     2025-04-06 08:13:39   Profiler_Wait_sum 0.308
     2025-04-06 08:13:42   QueueLength     0
     2025-04-06 08:13:39   Statistics_Requests 17
     2025-04-06 08:13:39   Statistics_Timeouts 0
     2025-04-05 18:30:12   state           opened
   REMEMBER:
     lid        1
     lname      HTZ_SDM630M_01
     lrecv      1743920022.50826
     lsend      1743920022.49221
   defptr:
     HTZ_SDM630M_01 1
   profiler:
     lastKey    Idle
     lastPeriod 58130667
     start:
       Delay      1743920022.0121
       Fhem       1743920022.50918
       Idle       1743920022.52256
       Read       1743920022.50828
       Send       1743920022.49074
       Wait       1743920022.49223
     sums:
       Delay      2.93966031074524
       Fhem       0.166212320327759
       Idle       9.29115962982178
       Read       0.00713086128234863
       Send       0.0110230445861816
       Wait       0.107370853424072
   statistics:
     lastPeriod 58130667
     sums:
       Requests   7
       Timeouts   0
Attributes:
   alias      ModBus RS485 1 | WaveShare USB - EG Vorraum HV
   busDelay   0.5
   devStateIcon opened:lan_rs485@0CFB0C Open:lan_rs485@red disconnected:lan_rs485@red disabled:lan_rs485@orange
   devStateStyle style="text-align:left;font-weight:bold;"
   disable    0
   dropQueueDoubles 1
   enableQueueLengthReading 1
   group      Schnittstellen Modbus
   icon       lan_rs485
   profileInterval 30
   queueDelay 1
   queueMax   100
   queueTimeout 5
   room       _RxTx
   showError  1
   skipGarbage 1
   sortby     02.01
FHEM hat jedenfalls ein Problem mit der Schnittstellenbezeichnung usb-WCH.CN_USB_Quad_Serial_BCD697ABCD-if00. Unter FHEM funktioniert als Ersatz nur /dev/ttyACM0, was aber ein Nachteil ist. Vertauscht man das USB-Gerät, passen mit /dev/ttyACM0 unter Umständen die Schnittstellen nicht mehr.

Was bei mir auffällig ist, dass alle vier Verbindungen sich abmelden und nur mehr ein timeout waiting for reply to.... über alle Register produzieren. Setzte ich unter FHEM am Pi4 die 4 Schnittstelle auf disable 1 und anschließend wieder auf disable 0 ist die Schnittstelle wieder OK. Irritierend ist, dass FHEM am Pi4 die RS485/IP Verbindung trotz Fehler immer mit STATE opened definert. An diesen 4 RS485 Schnittstellen sind drei unterschiedliche SDM630-Modbus Energiezähler angeschlossen, wobei der alte SDM630 B&G mit dem FHEM bereitgestellten Modul die meisten Timeouts liefert. Ich habe für diesen das Modul geändert. Es gibt zwar weniger Timeouts damit, dennoch sind die Timeouts zu viel. Auf diesem System tauchen bei mir keine Freezemon Einträge im LOG auf, sondern nur die Timeouts auf.

Code Auswählen Erweitern

2025.04.05 18:56:07.372 3: ModbusRS485_2WS_EG_VR: Timeout waiting for a modbus response, read buffer empty,
request: id 4, read fc 4 i10, len 8, master device PVA1_SDM630M_04, reading Current_L3__A (getUpdate for combined i10 len 2 Current_L3__A with i12 len 2 Active_Power_L1__W and i14 len 2 Active_Power_L2__W and i16 len 2 Active_Power_L3__W), queued 2.26 secs ago, sent 0.65 secs ago
2025.04.05 18:56:07.478 3: ModbusRS485_2WS_EG_VR: readfn got data while EXPECT was set to idle: 0404103fd14556c3c8e600c3a5b400c3a9600007bf
2025.04.05 21:05:43.853 3: ModbusRS485_2WS_EG_VR: Timeout waiting for a modbus response, read buffer empty,
request: id 4, read fc 4 i10, len 8, master device PVA1_SDM630M_04, reading Current_L3__A (getUpdate for combined i10 len 2 Current_L3__A with i12 len 2 Active_Power_L1__W and i14 len 2 Active_Power_L2__W and i16 len 2 Active_Power_L3__W), queued 1.12 secs ago, sent 0.50 secs ago
2025.04.06 00:23:40.131 3: ModbusRS485_2WS_EG_VR: Timeout waiting for a modbus response, read buffer empty,
request: id 4, read fc 4 i104, len 2, master device PVA1_SDM630M_04, reading Current_N_Demand__A (getUpdate for Current_N_Demand__A len 2), queued 2.75 secs ago, sent 0.50 secs ago
2025.04.06 02:50:07.876 3: ModbusRS485_2WS_EG_VR: Timeout waiting for a modbus response, read buffer empty,
request: id 4, read fc 4 i342, len 2, master device PVA1_SDM630M_04, reading Active_Energy_Total__kWh (getUpdate for Active_Energy_Total__kWh len 2), queued 4.09 secs ago, sent 0.50 secs ago
2025.04.06 05:48:50.364 3: ModbusRS485_2WS_EG_VR: Timeout waiting for a modbus response, read buffer empty,
request: id 4, read fc 4 i200, len 8, master device PVA1_SDM630M_04, reading Voltage_L1_L2__V (getUpdate for combined i200 len 2 Voltage_L1_L2__V with i202 len 2 Voltage_L2_L3__V and i204 len 2 Voltage_L3_L1__V and i206 len 2 Voltage_L_L_Avr__V), queued 4.01 secs ago, sent 0.50 secs ago
2025.04.06 05:48:50.364 3: ModbusRS485_2WS_EG_VR: Timeout waiting for a modbus response, read buffer empty,
request: id 4, read fc 4 i200, len 8, master device PVA1_SDM630M_04, reading Voltage_L1_L2__V (getUpdate for combined i200 len 2 Voltage_L1_L2__V with i202 len 2 Voltage_L2_L3__V and i204 len 2 Voltage_L3_L1__V and i206 len 2 Voltage_L_L_Avr__V), queued 4.01 secs ago, sent 0.50 secs ago
2025.04.06 07:39:31.421 3: ModbusRS485_2WS_EG_VR: Timeout waiting for a modbus response, read buffer empty,
request: id 4, read fc 4 i200, len 6, master device PVA1_SDM630M_04, reading Voltage_L1_L2__V (getUpdate for combined i200 len 2 Voltage_L1_L2__V with i202 len 2 Voltage_L2_L3__V and i204 len 2 Voltage_L3_L1__V), queued 3.82 secs ago, sent 0.50 secs ago

Diese LOG Einträge sehe ich mir nach der Neuinstallation des Pi4 mit Bookworm noch genauer an.

[Nobbynews]

Seit Wechsel auf einen Pi 4 habe ich jetzt erstmalig wieder einen Timeout gehabt.

Hast du erst jetzt auf den Pi4 gewechselt?
Welche Pi OS verwendest du?
Wieviele RS485 Schnittstellen hast du im Einsatz?

Das ist ein Pi4 mit 8GB Ram. Umzug erfolgte  Anfang Oktober 2024.
OS ist 64bit Bookworm-Lite.
System komplett auf SSD mit aktivem USB-SATA-Adapter installiert
Schnittstelle ist ein einfacher USB-Adapter:
https://www.makershop.de/module/kommunikation-module/rs485-adapter/
Weiterhin sind am USB, teilweise über aktiven USB-Hub, angeschlossen:
- CUL für MAX!
- EnOcean USB 300
- ZMEEUZB1 für Z-Wave
Alle USB-Geräte sind über /serial/by-id in FHEM eingebunden.

Ich habe das die letzten Tage mal genauer beobachtet und dabei festgestellt, dass doch immer mal wieder (1x pro Tag) timeouts auftreten. Hatte ich vorher wg. nicht aktiviertem attr ShowError gar nicht mitbekommen.
Allerdings gab es diese Meldung im Log immer nur im Zusammenhang mit Einträgen von FreezeMon.
Habe FreezeMon jetzt mal testweise wieder gelöscht um zu sehen, ob dann immer noch Log-Einträge kommen. (Naive Vorstellung von mir??)

Edit:
Aus irgendeinem Grund/Quelle habe ich noch gesetzt:

Code Auswählen Erweitern

attr ModBusLine clientSwitchDelay 0.4
Hintergrund dazu ist mir entfallen.

[Nobbynews]

Ich verwende eine Pi4 mit Bullseye Lite 32Bit und werde jetzt auf Bookworm Lite 32Bit wechseln um weiter den Ausfall der

Ich habe noch einen Pi unter Bullseye am Start, mit dem ich über ser2net einen CUL zur Verfügung stelle.
Die Version 4.3.3 ist lt. Paketverwaltung die aktuelle Version für Bullseye.
Den habe ich allerdings nur zum LAufen bekommen, in dem ich in der device-config ein NOBREAK angefügt habe.

Code Auswählen Erweitern

connector: serialdev,/dev/serial/by-id/usb-busware.de_CUL868-if00,9600n81,local,NOBREAKFrag'  mich jetzt aber bitte nicht, wo ich das gefunden habe.

[Burny4600]

Den habe ich allerdings nur zum LAufen bekommen, in dem ich in der device-config ein NOBREAK angefügt habe...........

Hast du daran einen EASTRON-Energiezähler angeschlossen?

Grundsätzlich spielt die ser2net Version nicht die große Rolle. Die RS485 läuft genauso mit der ser2net V4.3.3.

Unter Bookworm wird die ser2net Version 4.3.11 installiert. Es läuft unter Bookworm auch die aktuelle ser2net Version V4.6.4.
Ich habe alle drei ser2net Versionen mit allen EASTRON-Energiezähler getestet. An den ser2net Versionen liegt es nicht warum es zu den Timeout-Fehler kommt.

Hast du deine RS485 Schnittstelle mit dem EASTRON-Energiezähler einmal mit dem Attribut showError über einen längeren Zeitraum getestet?


Ich habe die EASTRON-Module nochmals überarbeitet was das interne Modul-Timing betrifft. Die Anleitung habe ich zusätzlich auch ins deutsche übersetzt und angepasst.

Im original SDM630M-Modul waren die Attribute

Code Auswählen Erweitern

timeout      =>    2
commDelay    =>    0.7
sendDelay    =>    0.7verbaut die ich in den Modulen belassen habe. Diese Attribute können auch ausserhalb des Moduls abgeändert werden.

Aktuell habe ich einen Test am laufen und mit den Attribut-Einstellungen

Code Auswählen Erweitern

dev-timing-timeout 0.5
dev-timing-commDelay 0.2
dev-timing-sendDelay 0.2
bisher gute Erfahrungen bei mir gemacht.

Zusätzlich habe ich in der RS485-Schnittstelle das Attribut

Code Auswählen Erweitern

clientSwitchDelay 0.1aktiviert.

list ModbusRS485_7WS_EG_VR

Code Auswählen Erweitern

Internals:
   CFGFN      /media/hdd/fhem/mycfg/schnittstellen_rasp02.cfg
   DEF        192.168.17.185:44857
   DeviceName 192.168.17.185:44857
   EXPECT     idle
   FD         59
   FUUID      67b89efd-f33f-f4d2-7f9c-01b443882202b3f3
   IODev      ModbusRS485_7WS_EG_VR
   LASTOPEN   1744024765.38338
   MODE       master
   NAME       ModbusRS485_7WS_EG_VR
   NOTIFYDEV  global
   NR         514
   NTFY_ORDER 50-ModbusRS485_7WS_EG_VR
   PARTIAL   
   PROTOCOL   RTU
   STATE      opened
   TCPConn    1
   TYPE       Modbus
   devioLoglevel 3
   devioNoSTATE 1
   eventCount 2867
   nextOpenDelay 60
   QUEUE:
   READ:
     BUFFER    
   READINGS:
     2025-04-03 18:23:05   LAST_ERROR      timeout waiting for reply to fc 4 to id 2, i12, len 2
     2025-04-07 14:36:00   Profiler_Delay_sum 0.677
     2025-04-07 14:36:00   Profiler_Fhem_sum 0.059
     2025-04-07 14:36:00   Profiler_Idle_sum 29.017
     2025-04-07 14:36:00   Profiler_Read_sum 0.004
     2025-04-07 14:36:00   Profiler_Send_sum 0.006
     2025-04-07 14:36:00   Profiler_Wait_sum 0.237
     2025-04-07 14:36:28   QueueLength     0
     2025-04-07 14:36:00   Statistics_Requests 4
     2025-04-07 14:36:00   Statistics_Timeouts 0
     2025-04-07 13:19:28   state           opened
   REMEMBER:
     lid        1
     lname      OG1_SDM120M_02
     lrecv      1744029388.84825
     lsend      1744029388.81772
   defptr:
     OG1_SDM120M_02 1
     OG1_SDM120M_03 2
   profiler:
     lastKey    Idle
     lastPeriod 58134312
     start:
       Delay      1744029388.60861
       Fhem       1744029388.84958
       Idle       1744029388.86232
       Read       1744029388.84829
       Send       1744029388.81606
       Wait       1744029388.81776
     sums:
       Delay      0.901864290237427
       Fhem       0.113309860229492
       Idle       27.7010283470154
       Read       0.00590896606445312
       Send       0.0092008113861084
       Wait       0.131011724472046
   statistics:
     lastPeriod 58134312
     sums:
       Requests   6
       Timeouts   0
Attributes:
   alias      ModBus RS485 7 | WaveShare USB - EG Vorraum HV
   clientSwitchDelay 0.1
   devStateIcon opened:lan_rs485@0CFB0C Open:lan_rs485@red disconnected:lan_rs485@red disabled:lan_rs485@orange
   devStateStyle style="text-align:left;font-weight:bold;"
   disable    0
   dropQueueDoubles 1
   enableQueueLengthReading 1
   group      Schnittstellen Modbus
   icon       lan_rs485
   profileInterval 30
   room       _RxTx
   showError  1
   skipGarbage 1
   sortby     02.07
Es kommen zwar beim alten Energiezähler B&G - EASTRON 630 Modbus immer noch vereinzelt Timeout-Fehler, aber diese stören nicht mehr. Die Eastron-Energiezähler jüngerer Baureihe laufen jetzt ohne Timeout-Fehler.

Das sind die aktuellen EASTRON-Energiezähler-Module.
Wenn jemanden ein Fehler auffällt, bitte Rückmelden.

[Nobbynews]

Den habe ich allerdings nur zum LAufen bekommen, in dem ich in der device-config ein NOBREAK angefügt habe...........

Hast du daran einen EASTRON-Energiezähler angeschlossen?

Nein, da hängt ein SignalDuino dran.