Ich habe einige RS485 Verbindungen mit unterschiedlichen Geräten im Einsatz.
Aber egal ob ich das RS485 Pi-Shield, WaveShare oder andere RS485 Schnittstellen im Einsatz habe, werden immer wieder Fehlermeldungen generiert.
Endgeräte sind EP-EVER PV-Komponeten, Deye PV-Komponenten und Eastron Energiezähler.
Bei den kurzen RS485 Verbindungen, maximale Länge 1,5m, ist nur ein 120E Widerstand am Endgerät angeschlossen. An den FHEM Schnittstellen ist kein Widerstand auf A+ und B- angeschlossen.
Bei den längeren RS485 Verbindungen ist sowohl an der Geräteseite als auch bei der FHEM Schnittstelle ein 120E Widerstand zwischen A+ und B- angeschlossen.
Ebenfalls ist der GND an der Geräteseite und an der FHEM Schnittstelle angeschlossen.
Einge Schnittstellen sind zudem über ser2net verlinkt, was aber die gleichen Fehlermeldungen bringen als eine direkte Verbindung.
Grundsätzlich kommen die Daten unter FHEM auch an, dennoch möchte ich diese Fehlermeldungen verhindern.
AUSZUG der LAST_ERROR Readings
EASTRON WaveShare M1 timeout waiting for reply to fc 4 to id 1, i200, len 26
EASTRON WaveShare M1 timeout waiting for reply to fc 4 to id 1, i200, len 26
EASTRON WaveShare M2 timeout waiting for reply to fc 4 to id 4, i0, len 18
EASTRON WaveShare M2 timeout waiting for reply to fc 4 to id 4, i200, len 26
EASTRON WaveShare M3 timeout waiting for reply to fc 4 to id 5, i342, len 32
EASTRON WaveShare M3 timeout waiting for reply to fc 4 to id 5, i104, len 2
EASTRON WaveShare M4 timeout waiting for reply to fc 4 to id 1, i104, len 2
EASTRON WaveShare M5 timeout waiting for reply to fc 4 to id 1, i374, len 8
EASTRON WaveShare M5 timeout waiting for reply to fc 4 to id 1, i0, len 18
EASTRON WaveShare M6 timeout waiting for reply to fc 4 to id 2, i0, len 32
EASTRON WaveShare M6 timeout waiting for reply to fc 4 to id 1, i0, len 14
EASTRON WaveShare M7 timeout waiting for reply to fc 4 to id 1, i0, len 32
EASTRON WaveShare M7 timeout waiting for reply to fc 4 to id 2, i0, len 14
M8 Reserve
Deye PV1 WaveShare timeout waiting for reply to fc 3 to id 12, h500, len 1
Deye PV1 WaveShare timeout waiting for reply to fc 3 to id 12, h666, len 2
Deye PV2 WaveShare timeout waiting for reply to fc 3 to id 15, h514, len 5
Deye PV2 WaveShare timeout waiting for reply to fc 3 to id 15, h591, len 5
EP-EVER Pi-Shild PV3 slave replied with error code 83 / 02, illegal data address
EP-EVER NoNameRS485 PV4 slave replied with error code 83 / 02, illegal data address
list ModbusRS485_2WS_OG2_HZR
Internals:
CFGFN /media/hdd/fhem/mycfg/schnittstellen_rasp02.cfg
DEF /dev/ttyACM1@9600
DeviceName /dev/ttyACM1@9600
EXPECT idle
FD 52
FUUID 66881de9-f33f-f4d2-da3e-4cedc2ffd91c9e75
LASTOPEN 1742211635.67558
MODE master
NAME ModbusRS485_2WS_OG2_HZR
NOTIFYDEV global
NR 493
NTFY_ORDER 50-ModbusRS485_2WS_OG2_HZR
PARTIAL
PROTOCOL RTU
STATE opened
SerialConn 1
TYPE Modbus
devioLoglevel 3
devioNoSTATE 1
eventCount 9
nextOpenDelay 60
nextQueueRun 1742557062.73234
QUEUE:
HASH(0x5571ffca68)
HASH(0x5571e891d8)
HASH(0x5571ed46e8)
HASH(0x5571cfcbc0)
HASH(0x5571e20008)
HASH(0x5571e82fe0)
HASH(0x5571bb40a0)
HASH(0x5571bf0218)
HASH(0x5571e24a40)
HASH(0x5571f123b8)
HASH(0x5571634b88)
HASH(0x55717c76f0)
HASH(0x5571d830d0)
HASH(0x55719527b0)
HASH(0x5571bcbf80)
HASH(0x5572197088)
HASH(0x5571dd2648)
HASH(0x5571c7a6e0)
HASH(0x5571c93d70)
HASH(0x557133df98)
HASH(0x5571d5a640)
HASH(0x5570a190e8)
HASH(0x5571bc4f00)
READ:
BUFFER
READINGS:
2025-03-21 10:05:22 LAST_ERROR timeout waiting for reply to fc 3 to id 15, h591, len 5
2025-03-17 12:40:35 state opened
REMEMBER:
lid 15
lname Deye_15k
lrecv 1742557062.63206
lsend 1742557062.60082
defptr:
Deye_15k 15
Attributes:
alias ModBus RS485 2 | WaveShare USB - OG2 Heizraum
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
group Schnittstellen Modbus
icon lan_rs485
queueDelay 1
queueMax 200
queueTimeout 20
room _RxTx
showError 1
sortby 01.02
list ModbusRS485_1WS_EG_VR
Internals:
CFGFN /media/hdd/fhem/mycfg/schnittstellen_rasp02.cfg
DEF 192.168.17.185:44851
DeviceName 192.168.17.185:44851
EXPECT idle
FD 10
FUUID 67b5c89b-f33f-f4d2-7223-f064a5307ca304fc
IODev ModbusRS485_1WS_EG_VR
LASTOPEN 1742495828.10091
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 3
nextOpenDelay 60
QUEUE:
READ:
BUFFER
READINGS:
2025-03-18 13:38:37 LAST_ERROR timeout waiting for reply to fc 4 to id 1, i200, len 26
2025-03-20 19:37:08 state opened
REMEMBER:
lid 1
lname HTZ_SDM630M_01
lrecv 1742557124.31934
lsend 1742557124.29492
defptr:
HTZ_SDM630M_01 1
Attributes:
alias ModBus RS485 1 | WaveShare USB - EG Vorraum HV
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
group Schnittstellen Modbus
icon lan_rs485
queueDelay 1
queueMax 200
queueTimeout 20
room _RxTx
showError 1
sortby 02.01
list ModbusRS485_AB_WS
Internals:
CFGFN /media/hdd/fhem/mycfg/schnittstellen_rasp02.cfg
DEF 192.168.17.184:40401
DeviceName 192.168.17.184:40401
EXPECT idle
FD 58
FUUID 6245d473-f33f-f4d2-401a-8391e63bf0d11667
IODev ModbusRS485_AB_WS
LASTOPEN 1742211635.70036
MODE master
NAME ModbusRS485_AB_WS
NOTIFYDEV global
NR 520
NTFY_ORDER 50-ModbusRS485_AB_WS
PARTIAL
PROTOCOL RTU
STATE opened
TCPConn 1
TYPE Modbus
devioLoglevel 3
devioNoSTATE 1
eventCount 11902
nextOpenDelay 60
QUEUE:
READ:
BUFFER
READINGS:
2025-03-21 12:39:30 LAST_ERROR slave replied with error code 83 / 02, illegal data address
2025-03-17 12:40:37 state opened
REMEMBER:
lid 1
lname EPEVER_T3210AN_PV3
lrecv 1742557171.13546
lsend 1742557171.108
defptr:
EPEVER_T3210AN_PV3 1
Attributes:
alias ModBus RS485 | Pi Shield - AB Wetterstation
devStateIcon opened:lan_rs485@0CFB0C Open:lan_rs485@red disconnected:lan_rs485@red
devStateStyle style="text-align:left;;font-weight:bold;;"
disable 0
dropQueueDoubles 1
group Schnittstellen Modbus
icon lan_rs485
queueDelay 1
queueMax 200
queueTimeout 20
room _RxTx
showError 1
Ich vermute ich habe bei den Schnittstellen etwas vergessen. Hardware mäßig passt jedenfalls alles.
Ich klinke mich hier mal ein. Selbes Problem, viel an verschiedenen Einstellungen von modbus Devices rumgespielt, keine Verbesserung.
Ich bekomme die Fehler nur so halbstündlich.
Verstehe die Fehlermeldung auch nicht im Detail, also welches Device zB
timeout waiting for reply to fc 4 to id 2, i0, len 38
genau ist. Ich habe kein Device mit der ID 2.
EDIT: Ich referenziere den Thread mal im großen "modbus thread". Vielleicht findet Stefan die Zeit auch hier mal vorbeizuschauen.
Ha, hoppala, ich habe sehr wohl eine ID 1 und ID 2. Komplett die Eaton Stromzähler die mit am Modbus hängen vergessen.
Von denen kommen wohl die Fehler.
Die sind über Rogers Template eingebunden. Längere Beobachtung bzgl Fehler dieser zwei:
Mo - 24.03.2025 - 08:41:51 Eastron LAST_ERROR: timeout waiting for reply to fc 4 to id 43, i98, len 2
Mo - 24.03.2025 - 08:04:25 Eastron LAST_ERROR: timeout waiting for reply to fc 4 to id 2, i0, len 14
Mo - 24.03.2025 - 07:59:16 Eastron LAST_ERROR: timeout waiting for reply to fc 4 to id 1, i0, len 14
Mo - 24.03.2025 - 07:56:41 Eastron LAST_ERROR: timeout waiting for reply to fc 4 to id 1, i0, len 26
Mo - 24.03.2025 - 07:23:56 Eastron LAST_ERROR: timeout waiting for reply to fc 4 to id 1, i0, len 14
Mo - 24.03.2025 - 06:47:24 Eastron LAST_ERROR: timeout waiting for reply to fc 4 to id 2, i0, len 14
Mo - 24.03.2025 - 06:24:41 Eastron LAST_ERROR: timeout waiting for reply to fc 4 to id 2, i0, len 14
Mo - 24.03.2025 - 06:16:41 Eastron LAST_ERROR: timeout waiting for reply to fc 4 to id 2, i0, len 32
Mo - 24.03.2025 - 05:42:04 Eastron LAST_ERROR: timeout waiting for reply to fc 4 to id 2, i0, len 38
Mo - 24.03.2025 - 05:24:55 Eastron LAST_ERROR: timeout waiting for reply to fc 4 to id 1, i0, len 14
Mo - 24.03.2025 - 05:18:31 Eastron LAST_ERROR: timeout waiting for reply to fc 4 to id 1, i0, len 26
Mo - 24.03.2025 - 04:53:41 Eastron LAST_ERROR: timeout waiting for reply to fc 4 to id 2, i0, len 26
Mo - 24.03.2025 - 04:50:09 Eastron LAST_ERROR: timeout waiting for reply to fc 4 to id 2, i0, len 14
Mo - 24.03.2025 - 04:49:51 Eastron LAST_ERROR: timeout waiting for reply to fc 4 to id 1, i0, len 14
Mo - 24.03.2025 - 04:27:16 Eastron LAST_ERROR: timeout waiting for reply to fc 4 to id 2, i0, len 14
Mo - 24.03.2025 - 04:24:37 Eastron LAST_ERROR: timeout waiting for reply to fc 4 to id 1, i0, len 14
Mo - 24.03.2025 - 03:36:57 Eastron LAST_ERROR: timeout waiting for reply to fc 4 to id 2, i0, len 14
Mo - 24.03.2025 - 03:29:56 Eastron LAST_ERROR: timeout waiting for reply to fc 4 to id 1, i0, len 14
Mo - 24.03.2025 - 03:23:01 Eastron LAST_ERROR: timeout waiting for reply to fc 4 to id 2, i0, len 14
Mo - 24.03.2025 - 02:43:50 Eastron LAST_ERROR: timeout waiting for reply to fc 4 to id 1, i0, len 14
Mo - 24.03.2025 - 02:21:52 Eastron LAST_ERROR: timeout waiting for reply to fc 4 to id 1, i72, len 4
Mo - 24.03.2025 - 02:21:31 Eastron LAST_ERROR: timeout waiting for reply to fc 4 to id 2, i0, len 26
Mo - 24.03.2025 - 02:21:01 Eastron LAST_ERROR: timeout waiting for reply to fc 4 to id 2, i0, len 14
Mo - 24.03.2025 - 02:09:56 Eastron LAST_ERROR: timeout waiting for reply to fc 4 to id 1, i0, len 32
Mo - 24.03.2025 - 01:59:35 Eastron LAST_ERROR: timeout waiting for reply to fc 4 to id 2, i0, len 14
Da ich dazu keine attr gesetzt habe, gerade keine Idee, wo man da ansetzen muss.
Da bei Burny4600 das IO Device auch Eastron (das kommt noch von der damaligen Implementation Rogers Beschreibung folgend) heißt, tippe ich mal auf das selbe Problem.
List von einem der Zwei:
Internals:
DEF 2 5
FUUID 5c86875c-f33f-6bb4-786b-47c84d97f6c46b6d
IODev Eastron
Interval 5
MODBUSID 2
MODE master
MODULEVERSION Modbus 4.5.6 - 7.11.2023
NAME Xtender_AC_out
NOTIFYDEV global
NR 675
NTFY_ORDER 50-Xtender_AC_out
PROTOCOL RTU
STATE opened
TYPE ModbusSDM220M
devioNoSTATE 1
eventCount 1808
DICACHE:
3:
UNPACK
EXPRS:
EXTRAS:
FNAMES:
4:
UNPACK
EXPRS:
EXTRAS:
FNAMES:
FRAME:
PICACHE:
h12:
bswapRegs
decode
encode
expr
format %.f
ignoreExpr
map
mapDefault
revRegs
rmapDefault
h18:
bswapRegs
decode
encode
expr
format %s
ignoreExpr
map 0:1stop.bit_no.parity, 1:1stop.bit_even.parity, 2:1stop.bit_odd.parity, 3:2stop.bits_no.parity
mapDefault
revRegs
rmapDefault
h20:
bswapRegs
decode
encode
expr
format %u
ignoreExpr
map
mapDefault
revRegs
rmapDefault
h28:
bswapRegs
decode
encode
expr
format %s
ignoreExpr
map 0:2400, 1:4800, 2:9600, 5:1200
mapDefault
revRegs
rmapDefault
h62720:
bswapRegs
decode
encode
expr
format %s
ignoreExpr
map
mapDefault
revRegs
rmapDefault
h63760:
bswapRegs
decode
encode
expr
format %s
ignoreExpr
map 0:0.001/imp, 1:0.01/imp, 2:0.1/imp, 3:1/imp
mapDefault
revRegs
rmapDefault
h63776:
bswapRegs
decode
encode
expr
format %s
ignoreExpr
map 1:import, 2:import+export, 3:import-export
mapDefault
revRegs
rmapDefault
h86:
bswapRegs
decode
encode
expr
format %s
ignoreExpr
map 1:import.active.energy, 2:import+export.active.energy, 4:export.active.energy, 6:import+export.reactive.energy, 8:export.reactive.energy
mapDefault
revRegs
rmapDefault
i0:
bswapRegs
decode
encode
expr
format %.1f
ignoreExpr
map
mapDefault
revRegs
rmapDefault
i12:
bswapRegs
decode
encode
expr
format %.f
ignoreExpr
map
mapDefault
revRegs
rmapDefault
i18:
bswapRegs
decode
encode
expr
format %.1f
ignoreExpr
map
mapDefault
revRegs
rmapDefault
i24:
bswapRegs
decode
encode
expr
format %.1f
ignoreExpr
map
mapDefault
revRegs
rmapDefault
i30:
bswapRegs
decode
encode
expr
format %.1f
ignoreExpr
map
mapDefault
revRegs
rmapDefault
i342:
bswapRegs
decode
encode
expr
format %.3f
ignoreExpr
map
mapDefault
revRegs
rmapDefault
i344:
bswapRegs
decode
encode
expr
format %.3f
ignoreExpr
map
mapDefault
revRegs
rmapDefault
i36:
bswapRegs
decode
encode
expr
format %.1f
ignoreExpr
map
mapDefault
revRegs
rmapDefault
i6:
bswapRegs
decode
encode
expr
format %.2f
ignoreExpr
map
mapDefault
revRegs
rmapDefault
i70:
bswapRegs
decode
encode
expr
format %.1f
ignoreExpr
map
mapDefault
revRegs
rmapDefault
i72:
bswapRegs
decode
encode
expr
format %.3f
ignoreExpr
map
mapDefault
revRegs
rmapDefault
i74:
bswapRegs
decode
encode
expr
format %.3f
ignoreExpr
map
mapDefault
revRegs
rmapDefault
i76:
bswapRegs
decode
encode
expr
format %.3f
ignoreExpr
map
mapDefault
revRegs
rmapDefault
i78:
bswapRegs
decode
encode
expr
format %.3f
ignoreExpr
map
mapDefault
revRegs
rmapDefault
READ:
READINGS:
2017-05-02 02:59:20 CosPhi -21.0 %
2025-03-24 08:54:35 CosPhi__grd -10.4
2025-03-24 08:55:35 Current__A 2.41
2025-03-24 08:55:36 Energy_export__kVArh 6759.252
2025-03-24 08:55:16 Energy_export__kWh 0.000
2025-03-24 08:55:36 Energy_import__kVArh 829.841
2025-03-24 08:55:16 Energy_import__kWh 26687.801
2025-03-24 08:55:00 Energy_total__kVArh 7589.092
2025-03-24 08:55:10 Energy_total__kWh 26687.801
2025-03-24 08:54:36 Frequency__Hz 50.0
2025-03-22 18:02:11 Modbus_Node_adr 2
2025-03-22 18:02:11 Modbus_Parity_Stop 1stop.bit_even.parity
2025-03-22 18:02:19 Modbus_Speed__baud 9600
2025-03-24 08:54:35 PowerFactor 1.0
2025-03-24 08:55:35 Power__VA 530.9
2025-03-24 08:55:35 Power__VAr -103.1
2025-03-24 08:55:35 Power__W 521
2025-03-22 18:02:19 Relay1_Energy_Type import+export.active.energy
2025-03-22 18:02:21 System_Measurement_mode import+export
2025-03-22 18:02:11 System_Pulse_Width__ms 100
2025-03-22 18:02:20 System_Pulse_constant 0.001/imp
2025-03-24 08:55:35 Voltage__V 220.1
2025-03-24 08:54:10 statEnergy_total__kWh Hour: 0.535 Day: 2.443 Month: 207.107 Year: 771.086
2025-03-24 08:54:10 statEnergy_total__kWhDay 2.443
2025-03-23 23:59:55 statEnergy_total__kWhDayLast 8.901
2025-03-24 08:54:10 statEnergy_total__kWhHour 0.535
2025-03-24 07:59:55 statEnergy_total__kWhHourLast 0.240
2025-03-24 07:59:55 statEnergy_total__kWhLast Hour: 0.240 Day: 8.901 Month: 263.010 Year: 3980.814
2025-03-24 08:54:10 statEnergy_total__kWhMonth 207.107
2025-02-28 23:59:55 statEnergy_total__kWhMonthLast 263.010
2025-03-24 08:54:10 statEnergy_total__kWhYear 771.086
2024-12-31 23:59:55 statEnergy_total__kWhYearLast 3980.814
2025-03-22 18:01:45 state opened
2025-03-22 18:02:11 system_demand_interval 352387168
REMEMBER:
lrecv 1742802936.33466
lsend 1742802936.2913
UPDATECACHE:
i0:
adr 0
combine i0 len 2 Voltage__V with i12 len 2 Power__W
len 2
objCombi i0
reading Voltage__V
span 14
type i
i342:
adr 342
combine i342 len 2 Energy_total__kWh with i344 len 2 Energy_total__kVArh
len 2
objCombi i342
reading Energy_total__kWh
span 4
type i
gotReadings:
Energy_export__kVArh 6759.252
Energy_import__kVArh 829.841
helper:
_98_statistics Xtender_AC_in_statistic
bm:
CODE(0x38138f8):
cnt 15
dmx -1000
dtot 0
dtotcnt 0
mTS 23.03. 18:41:25
max 0.00027918815612793
tot 0.00210332870483398
mAr:
HASH(0x388a7e8)
HASH(0xcae7e8)
CODE(0x3892488):
cnt 2
dmx -1000
dtot 0
dtotcnt 0
mTS 24.03. 08:55:04
max 5.19752502441406e-05
tot 9.98973846435547e-05
mAr:
HASH(0x388a7e8)
Xtender_AC_out
?
CODE(0x3894910):
cnt 430
dmx -1000
dtot 0
dtotcnt 0
mTS 23.03. 20:04:18
max 0.000394105911254883
tot 0.0636627674102783
mAr:
HASH(0x388a7e8)
Xtender_AC_out
?
lastRead:
h12 1742662931.03238
h18 1742662931.03509
h20 1742662931.03752
h28 1742662939.19501
h62720 1742662931.77808
h63760 1742662940.69999
h63776 1742662941.44721
h86 1742662939.94919
i0 1742802935.58866
i12 1742802935.59173
i18 1742802935.59304
i24 1742802935.59432
i30 1742802875.52344
i342 1742802910.96322
i344 1742802900.98834
i36 1742802875.52612
i6 1742802935.59027
i70 1742802876.24851
i72 1742802916.01277
i74 1742802916.01538
i76 1742802936.34115
i78 1742802936.34391
Attributes:
event-min-interval Power__W:900,Voltage__V:900,statEnergy_total__kWhDay:900
event-on-change-reading Power__W:20,Voltage__V:4,Energy_total__kWh:0.1,statEnergy_total__kWhDay:0.1,statEnergy_total__kWhMonth:0.1,.*Last.*
event-on-update-reading Power__W,Voltage__V,statEnergy_total__kWhDay
group Xtender
polldelay-Voltage__V 1
Ok, man muss direkt in 98_ModbusSDM220M.pm schauen
Auszug bzgl i0 (Spannung)
my %SDM220MparseInfo = (
# Spannung, nur bei jedem 11. Zyklus: 10s --> 1min 50s
"i0" => { # input register 0x0000
name => "Line to neutral volts", # internal name of this register in the hardware doc
reading => "Voltage__V", # name of the reading for this value
# format => '%.1f V', # format string for sprintf
format => '%.1f', # format string for sprintf
polldelay => "x11", # only poll this Value if last read is older than 11*Iteration, otherwiese getUpdate will skip it
},
# Strom, nur bei jedem 3. Zyklus: 10s --> 30s
"i6" => { # input register 0x0006
name => "current", # internal name of this register in the hardware doc
reading => "Current__A", # name of the reading for this value
# format => '%.2f A', # format string for sprintf
format => '%.2f', # format string for sprintf
polldelay => "x3", # only poll this Value if last read is older than 3*Iteration, otherwiese getUpdate will skip it
},
# Leistung, bei jedem Zyklus: 10s
"i12" => { # input register 0x000C, Phase 1: Leistung
name => "Active power", # internal name of this register in the hardware doc
reading => "Power__W", # name of the reading for this value
# format => '%.f W', # format string for sprintf
format => '%.f', # format string for sprintf
},
was daran jetzt falsch ist, keine Ahnung ...
mal als halbe Zwischenlösung/verbesserung: Ein
attr Eastron busDelay 0.5
am IO Device hat die Error-Häufigkeit auf 1/10 reduziert. Ich nehme an, die Stromzähler antworten ab und zu nicht schnell genug.
In 98_ModbusSDM220M.pm
gibt es ein
combine => 40,
vielleicht ist das ein wenig üppig? Falls mal jemand eine Testreihe fahren möchte mit reduziertem Wert ;)
Ich habe für die Eastron Zähler einige Anpassungen durchführen müssen, weil einiges nicht vollständig war, oder am Zähler selbst Fehler verursacht wurden.
Wenn ein Register nicht passte, verursachte dieser bei manchen Zähler einen ständigen Neustart. Ich hatte von Eastron die Registerlisten angefordert um die Modusmodule zu ergänzen, und zusätzlich ist in den Modulen nun ersichtlich um welchen Zähler es sich handelt der per Modul verbunden ist, sollte man irtümlich den falschen Zähler ausgewählt zu haben.
"h64514" => { # holding register 0xFC02
# SDM120M-V2 = 00 04 01 05, SDM630M-V2 = 00 70 00 00, SDM630M-CT-V1 = 00 79 00 00, SDM72D-M-2 = 00 89 00 00
name => "Meter Code", # internal name of this $
reading => "Meter_Code", # name of the reading for this v$
map => "00040105:SDM120M-V2, 00700000:SDM630M-V2, 00790000:SDM630M-CT-V1, 00890000:SDM72D-M-2", # map to convert visible values to internal numbers (for reading and writing)
unpack => "H*", # hex pack / unpack code to convert raw values
format => '%s', # format string $
poll => "once", # only poll once$
},
Das
combine => 40, probiere ich gleich mal bei dem älteren Eastron Zähler der die meisten Fehlermeldungen verursacht.
Bei den anderen Zähler teste ich
attr Eastron busDelay 0.5.
Einige Änderungen der Modbus-Schnittstelle habe ich schon durchgeführt und Verbesserungen erreicht. Nun das
busDelay 0.5ergänzt.
list ModbusRS485_2WS_EG_VR
Internals:
CFGFN /media/hdd/fhem/mycfg/schnittstellen_rasp02.cfg
DEF 192.168.17.185:44852
DeviceName 192.168.17.185:44852
EXPECT idle
FD 53
FUUID 67b5c89b-f33f-f4d2-6e0b-86099244c659eb22
IODev ModbusRS485_2WS_EG_VR
LASTOPEN 1743062364.37974
MODE master
NAME ModbusRS485_2WS_EG_VR
NOTIFYDEV global
NR 503
NTFY_ORDER 50-ModbusRS485_2WS_EG_VR
PARTIAL
PROTOCOL RTU
STATE opened
TCPConn 1
TYPE Modbus
devioLoglevel 3
devioNoSTATE 1
eventCount 105
nextOpenDelay 60
nextQueueRun 1743062427.5914
QUEUE:
HASH(0x559a8dce60)
HASH(0x559a525560)
HASH(0x559b243988)
READ:
BUFFER
READINGS:
2025-03-27 07:33:34 LAST_ERROR timeout waiting for reply to fc 4 to id 4, i104, len 4
2025-03-27 09:00:11 Profiler_Delay_sum 9.409
2025-03-27 09:00:11 Profiler_Fhem_sum 0.249
2025-03-27 09:00:11 Profiler_Idle_sum 18.762
2025-03-27 09:00:11 Profiler_Read_sum 0.027
2025-03-27 09:00:11 Profiler_Send_sum 0.031
2025-03-27 09:00:11 Profiler_Wait_sum 1.521
2025-03-27 09:00:26 QueueLength 3
2025-03-27 09:00:11 Statistics_Requests 16
2025-03-27 09:00:11 Statistics_Timeouts 0
2025-03-27 08:59:27 state opened
REMEMBER:
lid 4
lname PVA1_SDM630M_04
lrecv 1743062426.89085
lsend 1743062426.79539
defptr:
PVA1_SDM630M_04 4
profiler:
lastKey Delay
lastPeriod 58102080
start:
Delay 1743062426.93012
Fhem 1743062426.89186
Idle 1743062426.90664
Read 1743062426.89087
Send 1743062426.79391
Wait 1743062426.79541
sums:
Delay 2.07396411895752
Fhem 0.120440006256104
Idle 24.1214258670807
Read 0.0044252872467041
Send 0.00740170478820801
Wait 0.602463960647583
statistics:
lastPeriod 58102080
sums:
Requests 5
Timeouts 0
Attributes:
alias ModBus RS485 2 | 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
frameGap 1.0
group Schnittstellen Modbus
icon lan_rs485
profileInterval 30
queueDelay 5
queueMax 100
queueTimeout 5
retriesAfterTimeout 0
room _RxTx
showError 1
skipGarbage 1
sortby 02.02
EDIT 27-03-2025: Das Modul 98_ModbusSDM72DMV2.pm ist noch nicht ganz fertiggestellt.
Moinsen, schaue ich mir mal an.
Der BusDelay ist am IO Device. EDIT: Ah, hast du gesehen.
Für die EP-EVER PV-Komponeten habe ich keine vorgesetzte Modbus-Schnittstelle, sondern die DEF 1 60 192.168.17.184:40401 RTU verwendet. Somit sind für die EP-EVER Solarregler die Fehlermeldungen entfernt.
Bei den Deye Hybrid-Invertern teste ich das BusDelay.
Bei dem älteren Eastron Energiezähler (98_ModbusSDM630M_BG.pm) habe ich sowohl das Attribut busDelay 0.5 als auch im Modul das combine => 30, definiert. Dennoch kommt immer wieder ein timeout waiting for reply to......
... hast du mal auf ganz blöd das Bus-Kabel kontrolliert und neu festgezogen? Hatte ich letzthin auf HM-wired Probleme nach 10 Jahren. Ich weiß, unwahrscheinlich aber ....
Wechsel mal die ID´s der Stromzähler oder die Anschlüsse um einen Defekt des einen Zählers auzuschließen?
Die IDs der Energiezähler brauche ich nicht wechseln.
Alle SDM630 Energiezähler besitzen einen eigenen RS485 Anschluss am WaveShare-Gerät.
Die Leitungen sind zudem sehr kurz. Die Anschlüsse sind geprüft, weil ich einen kompletten Umbau im Hauptverteiler wegen der Solaranlagen erst vor kurzem vorgenommen habe.
Der ältere Eastron-BG SDM630 Energiezähler ist der einzige der keinen GND Anschluss hat. Das ist eigentlich der einzige Unterschied zu den anderen Eastron Energiezähler.
Mit den vorgenommen Änderungen sind die Fehlerhäufigkeiten zumindest stark zurückgegangen, und kommen zwischen 5 und 10 Mal am Tag vor.
Die Fehlerhäfigkeit stört zumindest die Haustechnik nicht mehr. Vorher kam es sogar vor, dass sich die RS485-Schnittstelle unter FHEM sogar aufgehängt hatte und manuell wieder gestartet werden musste. Das ist zumindest jetzt bisher nicht mehr vorgekommen.
Ein Wechsel der WaveShare Schnittstelle des betroffenen Zählers hat nichts gebracht. Es ist wieder der gleiche Eastron-BG Energiezähler ohne GND-Anschluss der die timeout waiting for reply to fc.... Fehler verursacht.
Ich denke das dieser Energiezähler immer schon diese Timeout-Fehler verursacht hatte, nur jetzt aktivierte ich das Attribut showError wegen des Aufhängens der Schnittstelle.
Auch bei anderen RS485-Geräten gabe es Timeout Fehlermeldungen, die aber jetzt mit den Anpassungen an den Schnittstellen fast alle verschwunden sind.
Ich werde noch einige Anpassungen testen um die restlichen Timeouts zu verhindern.
Ja, das Busdelay hat auch bei mir deutlich geholfen. Lass wissen, wenn du noch mehr rausfindest.
Ohne das Busdelay und den dann sehr häufigen Fehlern hatte ich freezes in fhem die dann ZB den HMLAN-Funk rausgehauen haben. Um drei Ecken dann erst bei der Fehlersuche bei Modbus gelandet.
Stefan sagt, sein Modbus Modul sollte prinzipiell (ohne dedizierte Get Set Befehle) nicht blockierend wirken können. Ich bin auch zu wenig in der Materie drinnen um die Beobachtungen sinnvoll zu interpretieren. Auf die fhem performance wirken sich (zu viele) Fehler auf dem Bus aber definitiv aus. Bei dir und bei mir.
Ich bleibe jedenfalls dran noch Verbesserungen herauszufinden.
Ich denke ich werde in meinen Eastron-Modulen noch einige Änderungen für Tests vornehmen um die Performance zu verbesseren. Ein Modul für den SDM72 muss ich ohnehin noch fertigstellen.
Ich werde dann die Eastron-Module hier nochmals bereitstellen. Vielleicht sind dann meine Module soweit fertig um diese für FHEM nutzbar zu machen.
Die Vorabversionen sind ja schon in diesme Thread vorhanden. Wenn Fehler gefunden werden, bin ich natürlich dankbar auf jeden Hinweis.
kannst du bei deinen Modulen gleich den SDM230M-V2 (meiner ist so alt, das wird wohl V1 sein. Obs da Unterschiede im Protokoll hat?) mit einbauen? im mapping ... https://www.eastroneurope.com/products/view/sdm230modbus
Zitat von: Burny4600 am 27 März 2025, 08:45:24Ich habe für die Eastron Zähler einige Anpassungen durchführen müssen, weil einiges nicht vollständig war, oder am Zähler selbst Fehler verursacht wurden.
Wenn ein Register nicht passte, verursachte dieser bei manchen Zähler einen ständigen Neustart. Ich hatte von Eastron die Registerlisten angefordert um die Modusmodule zu ergänzen, und zusätzlich ist in den Modulen nun ersichtlich um welchen Zähler es sich handelt der per Modul verbunden ist, sollte man irtümlich den falschen Zähler ausgewählt zu haben.
"h64514" => { # holding register 0xFC02
# SDM120M-V2 = 00 04 01 05, SDM630M-V2 = 00 70 00 00, SDM630M-CT-V1 = 00 79 00 00, SDM72D-M-2 = 00 89 00 00
name => "Meter Code", # internal name of this $
reading => "Meter_Code", # name of the reading for this v$
map => "00040105:SDM120M-V2, 00700000:SDM630M-V2, 00790000:SDM630M-CT-V1, 00890000:SDM72D-M-2", # map to convert visible values to internal numbers (for reading and writing)
unpack => "H*", # hex pack / unpack code to convert raw values
format => '%s', # format string $
poll => "once", # only poll once$
},
Zitat von: Burny4600 am 28 März 2025, 17:34:46Ein Modul für den SDM72 muss ich ohnehin noch fertigstellen.
https://forum.fhem.de/index.php?topic=75638.msg1217182#msg1217182 (https://forum.fhem.de/index.php?topic=75638.msg1217182#msg1217182)
Mmh, gerade nochmal geschaut ... und meine Uraltdinger heißen tatsächlich SDM220modbus
Zitathttps://forum.fhem.de/index.php?topic=75638.msg1217182#msg1217182
Danke für den Hinweis, aber ich vereinheitliche meine Module für die EASTRON.
ZitatMmh, gerade nochmal geschaut ... und meine Uraltdinger heißen tatsächlich SDM220modbus
Ich habe mir die Modbusregister des SDM220 angesehen, und da gibt es doch einen großen Unterschied. Da ich den SDM220 nicht habe müsstest du mir einige Register überprüfen welchen Inhalt diese haben.
Diese Register gibt es beim SDM220 laut meiner Liste nicht.
System_Power_Demand_Import_Maximum__W
System_Power_Demand_Export__W
System_Power_Demand_Export_Maximum__W
Current_Demand__A
Current_Demand_Maximum__A
Total_Active_Energy__kWh
Total_Reactive_Energy__kVArh
Resettable_Current_Total_Active_Energy__kWh
Resettable_Current_Total_Reactive_Energy__kVArh
Demand_Time__min
Demand_Periode__min
System_Voltage__V
System_Current__A
System_Password_Lock
System_Password
System_Power__W
Relay1_Energy_Type
Relay2_Energy_Type
Serial_Number
Meter_Code
Software_VersionWenn bei Verwendung des SDM230 bei dir eine 0 in diesne Registern angeführt wird, gibt es diese Register nicht.
Diese kann ich dann entsprechend entfernen für ein 98_ModbusSDM220MV1.pm Modul.
Die Readings Serial_Number, Meter_Code und Software_Version werden meistens in den Registerlisten nicht angeführt, sind aber unter Umständen doch vorhanden. Bei dir wird wahrscheinlich der Meter_Code eine Nummer zur Identifikation enthalten. Diese benötige ich um sie bei allen Modulen zu ergänzen, um einen Vergleich mit dem SDM Energiezähler auszuführen ob man wirklich das richtige Modul verwendet.
Schick mir die Ergebnisse dieser Readings und ich kann das 98_ModbusSDM220MV1.pm für dich erstellen.
in der 98_ModbusSDM220M.pm sind meines Wissens nach alle verfügbaren Register hinterlegt.
Ich habe eben versucht zusätzlich über
attr Xtender_AC_in obj-h64512-reading aaaSerial Number
attr Xtender_AC_in obj-h64514-reading aaaMeterCode
attr Xtender_AC_in obj-h64515-reading aaaSoftware Version
attr Xtender_AC_in dev-defLen 2
attr Xtender_AC_in dev-defShowGet 1
attr Xtender_AC_in dev-defUnpack f>
attr Xtender_AC_in dev-h-read 3
attr Xtender_AC_in dev-h-write 16
die anderen Register auch auszulesen, ohne Ergebnis. Weiss aber auch nicht, ob ich die zusätzlich zum Template so abfragen kann.
Das SDM230 template anstatt zu verwenden macht mir gerade ein wenig Angst. An den Zählern hängen recht viele Automatiken, Statistics, etc.
EDIT: Allerdings im IO Device gerade den Error "timeout waiting for reply to fc 3 to id 1, h64512, len 5" gefangen. Ob das jetzt bedeutet die Parameter sind falsch, oder das Register existiert nicht .... ?
Das du schon ein SDM220 Modul hast wusste ich nicht. Somit ist das hinfällig.
Was mir in deinem Modul aufgefallen ist, ist ein Register den es laut Liste nicht geben sollte.
"h86" => { # holding register 0x0056
reading => "Relay1_Energy_Type", # name of the reading for this value
Alle anderen Register sind in deinem Modul vorhanden.
Was gibt der Regsiter Relay1_Energy_Type aus? Wenn es diesen nicht gibt müsste eine 0 im Reading stehen. Ansonsten am Energiezähler umstellen und vergleichen ob sich das Reading geändert hat. Wenn dieser Parameter am Energiezähler nicht vorhanden ist, dann gibts auch kein Reading dazu.
Du kannst dann diesen Parameter in deinem Modul deaktivieren oder entfernen.
Was ich feststellen musste, sind leider nicht immer die Registerlisten vollständig.
Wenn du möchtest kannst du testweise diese Readings in deinem Modul hinzufügen um zu sehen was die Ausgabe ist.
"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)
},
"h64514" => { # holding register 0xFC02
# SDM630M-V2 = 00 70, SDM630M-CT = 00 79, SDM72D-M-2 = 00 89
name => "Meter Code", # internal name of this $
reading => "Meter_Code", # name of the reading for this v$
map => "00700000:SDM630M-V2, 00790000:SDM630M-CT, 00890000:SDM72D-M-2", # map to convert visible values to internal numbers (for reading and writing)
unpack => "H*", # hex pack / unpack code to convert raw values
format => '%s', # format string $
poll => "once", # only poll once$
},
"h64515" => { # holding register 0xFC03
# Software Version
name => "Software Version", # internal name of this $
reading => "Software_Version", # name of the reading for this v$
unpack => "H*", # hex pack / unpack code to convert raw values
format => '%s', # format string $
poll => "once", # only poll once$
},
Bei diesen Änderungen in deinem Modul verlierst du deine Statistikwerte nicht.
Du musst nur FHEM neustarten damit diese Readingänderung im Modul übernommen werden.
Wenn bei dir dann ein Wert für den Meter_Code ausgegben wird, würde ich diesen mit der genauen Bezeichnung deines Energiezählers gerne in meinen Modulen ergänzen.
Das ist das Modul/template was Roger vor hundert Jahren gebaut hatte. Ich hatte es nur mal mit Stefans Hilfe angepasst als es Fehler gab.
2025-03-25 12:43:40 Relay1_Energy_Type export.active.energy
ist das Reading für "h86 => Relay1_Energy_Type". Was einem "export.active.energy" sagen soll ....?
Ich baue deine genannten Readings mal ins template ein. Wobei ich nicht weiss, ob das zu meinem obigen Weg einen Unterschied machen wird.
keine Readings für die neuen Register. Schade.
Was mich wundert, der Error "timeout waiting for reply to fc 3 to id 2, h64512, len 5" kommt trotz "poll once" regelmäßig in jedem cycle. Zu "h64514" und "h64515" weder Readings noch Errors.
Sicher, dass die Parameter stimmen?
mal ein List nach den implementierten Änderungen
Internals:
DEF 1 6
FUUID 5c86875c-f33f-6bb4-b2c8-727efd671087a220
IODev Eastron
Interval 6
MODBUSID 1
MODE master
MODULEVERSION Modbus 4.5.6 - 7.11.2023
NAME Xtender_AC_in
NOTIFYDEV global
NR 670
NTFY_ORDER 50-Xtender_AC_in
PROTOCOL RTU
STATE opened
TYPE ModbusSDM220M
devioNoSTATE 1
eventCount 12
DICACHE:
3:
UNPACK
EXPRS:
EXTRAS:
FNAMES:
4:
UNPACK
EXPRS:
EXTRAS:
FNAMES:
FRAME:
PICACHE:
h12:
bswapRegs
decode
encode
expr
format %.f
ignoreExpr
map
mapDefault
revRegs
rmapDefault
h18:
bswapRegs
decode
encode
expr
format %s
ignoreExpr
map 0:1stop.bit_no.parity, 1:1stop.bit_even.parity, 2:1stop.bit_odd.parity, 3:2stop.bits_no.parity
mapDefault
revRegs
rmapDefault
h20:
bswapRegs
decode
encode
expr
format %u
ignoreExpr
map
mapDefault
revRegs
rmapDefault
h28:
bswapRegs
decode
encode
expr
format %s
ignoreExpr
map 0:2400, 1:4800, 2:9600, 5:1200
mapDefault
revRegs
rmapDefault
h62720:
bswapRegs
decode
encode
expr
format %s
ignoreExpr
map
mapDefault
revRegs
rmapDefault
h63760:
bswapRegs
decode
encode
expr
format %s
ignoreExpr
map 0:0.001/imp, 1:0.01/imp, 2:0.1/imp, 3:1/imp
mapDefault
revRegs
rmapDefault
h63776:
bswapRegs
decode
encode
expr
format %s
ignoreExpr
map 1:import, 2:import+export, 3:import-export
mapDefault
revRegs
rmapDefault
i0:
bswapRegs
decode
encode
expr
format %.1f
ignoreExpr
map
mapDefault
revRegs
rmapDefault
i12:
bswapRegs
decode
encode
expr
format %.f
ignoreExpr
map
mapDefault
revRegs
rmapDefault
i18:
bswapRegs
decode
encode
expr
format %.1f
ignoreExpr
map
mapDefault
revRegs
rmapDefault
i24:
bswapRegs
decode
encode
expr
format %.1f
ignoreExpr
map
mapDefault
revRegs
rmapDefault
i30:
bswapRegs
decode
encode
expr
format %.1f
ignoreExpr
map
mapDefault
revRegs
rmapDefault
i342:
bswapRegs
decode
encode
expr
format %.3f
ignoreExpr
map
mapDefault
revRegs
rmapDefault
i344:
bswapRegs
decode
encode
expr
format %.3f
ignoreExpr
map
mapDefault
revRegs
rmapDefault
i36:
bswapRegs
decode
encode
expr
format %.1f
ignoreExpr
map
mapDefault
revRegs
rmapDefault
i6:
bswapRegs
decode
encode
expr
format %.2f
ignoreExpr
map
mapDefault
revRegs
rmapDefault
i70:
bswapRegs
decode
encode
expr
format %.1f
ignoreExpr
map
mapDefault
revRegs
rmapDefault
i72:
bswapRegs
decode
encode
expr
format %.3f
ignoreExpr
map
mapDefault
revRegs
rmapDefault
i74:
bswapRegs
decode
encode
expr
format %.3f
ignoreExpr
map
mapDefault
revRegs
rmapDefault
i76:
bswapRegs
decode
encode
expr
format %.3f
ignoreExpr
map
mapDefault
revRegs
rmapDefault
i78:
bswapRegs
decode
encode
expr
format %.3f
ignoreExpr
map
mapDefault
revRegs
rmapDefault
READ:
READINGS:
2017-05-02 02:59:32 CosPhi -35.6 %
2025-03-29 14:29:47 CosPhi__grd -43.8
2025-03-29 14:30:05 Current__A 0.35
2025-03-29 14:30:21 Energy_export__kVArh 6186.158
2025-03-29 14:30:21 Energy_export__kWh 1.068
2025-03-29 14:30:21 Energy_import__kVArh 211.125
2025-03-29 14:30:21 Energy_import__kWh 12638.029
2025-03-29 14:30:15 Energy_total__kVArh 6397.283
2025-03-29 14:29:56 Energy_total__kWh 12639.097
2025-03-29 14:29:55 Frequency__Hz 50.0
2025-03-29 14:24:42 Modbus_Node_adr 1
2025-03-29 14:24:42 Modbus_Parity_Stop 1stop.bit_even.parity
2025-03-29 14:24:43 Modbus_Speed__baud 9600
2025-03-29 14:29:47 PowerFactor 0.7
2025-03-29 14:29:47 Power__VA 74.2
2025-03-29 14:29:47 Power__VAr -51.4
2025-03-29 14:30:05 Power__W 55
2025-03-25 12:43:40 Relay1_Energy_Type export.active.energy
2025-03-29 14:24:45 System_Measurement_mode import+export
2025-03-29 14:24:42 System_Pulse_Width__ms 100
2025-03-29 14:24:44 System_Pulse_constant 0.001/imp
2025-03-29 14:30:05 Voltage__V 217.9
2025-03-29 14:29:47 statEnergy_total__kWh Hour: 0.025 Day: 2.467 Month: 101.747 Year: 498.202
2025-03-29 14:29:47 statEnergy_total__kWhDay 2.467
2025-03-28 23:59:55 statEnergy_total__kWhDayLast 8.636
2025-03-29 14:29:47 statEnergy_total__kWhHour 0.025
2025-03-29 13:59:55 statEnergy_total__kWhHourLast 0.037
2025-03-29 13:59:55 statEnergy_total__kWhLast Hour: 0.037 Day: 8.636 Month: 173.054 Year: 1890.035
2025-03-29 14:29:47 statEnergy_total__kWhMonth 101.747
2025-02-28 23:59:55 statEnergy_total__kWhMonthLast 173.054
2025-03-29 14:29:47 statEnergy_total__kWhYear 498.202
2024-12-31 23:59:55 statEnergy_total__kWhYearLast 1890.035
2025-03-29 14:24:24 state opened
2025-03-29 14:24:44 system_demand_interval 352387168
REMEMBER:
lrecv 1743255021.40429
lsend 1743255021.33074
UPDATECACHE:
h64512:
adr 64512
combine h64512 len 2 Serial_Number with h64514 len 2 Meter_Code and h64515 len 2 Software_Version
len 2
objCombi h64512
reading Serial_Number
span 5
type h
i0:
adr 0
combine i0 len 2 Voltage__V with i12 len 2 Power__W
len 2
objCombi i0
reading Voltage__V
span 14
type i
i72:
adr 72
combine i72 len 2 Energy_import__kWh with i74 len 2 Energy_export__kWh
len 2
objCombi i72
reading Energy_import__kWh
span 4
type i
gotReadings:
Energy_export__kVArh 6186.158
Energy_export__kWh 1.068
Energy_import__kVArh 211.125
Energy_import__kWh 12638.029
helper:
_98_statistics Xtender_AC_in_statistic
lastRead:
h12 1743254682.61217
h18 1743254682.61365
h20 1743254682.61484
h28 1743254683.36159
h62720 1743254684.12509
h63760 1743254684.8857
h63776 1743254685.6298
i0 1743255005.39782
i12 1743255005.4036
i18 1743254987.01807
i24 1743254987.02068
i30 1743254987.02333
i342 1743254996.66584
i344 1743255015.54323
i36 1743254987.02631
i6 1743255005.40054
i70 1743254995.80467
i72 1743255021.4112
i74 1743255021.4137
i76 1743255021.41604
i78 1743255021.41838
Attributes:
event-min-interval Power__W:900,Voltage__V:900,statEnergy_total__kWhDay:900
event-on-change-reading Power__W:20,Voltage__V:4,Energy_total__kWh:0.1,statEnergy_total__kWhDay:0.1,statEnergy_total__kWhMonth:0.1,.*Last.*
event-on-update-reading Power__W,Voltage__V,statEnergy_total__kWhDay
group Xtender
polldelay-Voltage__V 1
Die Parameter stimmen. Es kann nur sein, dass dein SDM220 diese doch nicht implementiert hat.
Beim h86 ist mir ein Fehler in deinem Modul aufgefallen.
# 0001: Import active energy
# 0002: Import + export active energy
# 0004: Export active energy, (default)
# 0005: Import reactive energy
# 0006: Import + export reactive energy
# 0008: Export reactive energy
map => "1:import.active.energy, 2:import+export.active.energy, 4:export.active.energy, 5:import.reactive.energy, 6:import+export.reactive.energy, 8:export.reactive.energy", # map to convert visible values to internal numbers (for reading and writing)
hint => "1,2,4,5,6,8", # string for fhemweb to create a selection or slider
Noch besser wäre es das hint so abzuändern.
map => "1:import.active.energy, 2:import.export.active.energy, 4:export.active.energy, 5:import.reactive.energy, 6:import.export.reactive.energy, 8:export.reactive.energy", # map to convert visible values to internal numbers (for reading and writing)
hint => "import.active.energy,import.export.active.energy,export.active.energy,import.reactive.energy,import.export.reactive.energy,export.reactive.energy", # string for fhemweb to create a selection or slider
Damit weist du unter FHEM gleich welchen Parameter du auswählst.
Vergleiche dies mit deinem Modul. Du müstest diese Parameter mit deinem Zähler noch abgleichen ob es zusammenpasst. Grundsätzlich tritt kein Fehler auf, es kommt nur unter Umständen zu einer falschen Anzeige unter FHEM, oder es wird der falsche Parameter unter FHEM am Energiezähler gesetzt.
Mit
event-on-change-reading Power__W:20,Voltage__V:4,Energy_total__kWh:0.1,statEnergy_total__kWhDay:0.1,statEnergy_total__kWhMonth:0.1,.*Last.*grenzt du die neuen Readings aus.
Du müsstest dies in dieser Form definieren.
event-on-change-reading Power__W:20,Voltage__V:4,Energy_total__kWh:0.1,statEnergy_total__kWhDay:0.1,statEnergy_total__kWhMonth:0.1,.*Last.*,.*
Dein Interval mit 6 ist schon heftig.
Ah, komplett event-on.... übersehen. Ich probier gleich nochmal. Danke
Zitat von: Burny4600 am 29 März 2025, 14:50:34Dein Interval mit 6 ist schon heftig.
Ja, könnte man mal überdenken, aber ich brauche die Spannungen recht zügig.
Ich bastel und bin gleich zurück.
h86 gefixt. Danke dafür
Aber auch mit allen Event Blockings raus und Neustart keine Readings für die drei. Der Error bleibt auch gleich. Denke, das/die Register gibts tatsächlich nicht.
Ich bin mir nicht sicher wie schnell dein Energiezähler die Spannungsänderung erfasst, aber du wertest die Spannung ohnehin erst aus, wenn diese eine Änderung von 4V hat, und das ist eine sehr hohe Spannungsänderung die es eigentlich so im EVU-Netz nicht gibt, ausser es ist etwas faul.
Zudem hast du ein Mininterval von 900 für die Spannung definiert. Somit wird die Spannung ohnehin erst mach 900 Sekunden ausgewertet.
Nimm jeweils nur einen der drei Register raus, und starte FHEM neu. Den Register mit dem Fehler als erstes.
Check nochmals den h86. Ich habe noch etwas geändert und einen kleinen Fehler behoben.
map => "1:import.active.energy, 2:import.export.active.energy, 4:export.active.energy, 5:import.reactive.energy, 6:import.export.reactive.energy, 8:export.reactive.energy", # map to convert visible values to internal numbers (for reading and writing)
hint => "import.active.energy,import.export.active.energy,export.active.energy,import.reactive.energy,import.export.reactive.energy,export.reactive.energy", # string for fhemweb to create a selection or slider
Ich denke da hat sich unser Schreiben überschnitten.
Hast du auch das event-on-change-reading geändert?
event-on-change-reading Power__W:20,Voltage__V:4,Energy_total__kWh:0.1,statEnergy_total__kWhDay:0.1,statEnergy_total__kWhMonth:0.1,.*Last.*,.*
sorry, meinte Watt brauche ich recht zügig.
h86 angepasst.
Alle event-on ... rausgenommen. komplett offen.
probiere jetzt nochmal die Register einzeln
jetzt mal nur "h64515" drinnengelassen. kein Reading, Error "timeout waiting for reply to fc 3 to id 1, h64515, len 2"
event-on-change-reading solltest du schon lassen, nur am Ende der Zeile eine Änderung mit ,.* ergänzen, damit andere Readings ersichtlich werden.
event-on.... nur für den Test rausgenommen. Packst du deine fertigen Templates ins contrib? und hier deutlicher Hinweis?
Das mit contrib muss ich mir erst einmal genauer ansehen, und werde ich nachdem ich diese Module fertig getestet habe unter contrib veröffentlichen, sofern es nicht zu doppelten Einträgen mit EASTRON Energiezähler kommt. Unter FHEM-Wiki werde ich Fotos der EASTRON Energiezähler mit den passenden Modulen ergänzen. Wie gesagt, wenn ich mir soweit sicher bin nichts vergessen zu haben.
Hast du bestreffend Meter_Code noch etwas bei dir herausgefunden?
Könntest du mein SDM220 Modul bei dir testen? Du müsstest nur einen weiteren Energiezähler mit meinem Modul anlegen der auf deinen Energiezähler Zugriff hat.
Das wären die Konfigurationen die du in dein fhem.cfg kopieren müsstest.
define SDM220M ModbusSDM220MV1 1 10
attr SDM220M IODev ModbusRS485_SDM220M
attr SDM220M userattr IODev alias devStateStyle event-min-interval event-on-change-reading group icon room sortby stateFormat userReadings
attr SDM220M alias Energieverbrauch
attr SDM220M devStateStyle style="text-align:left;;;;font-weight:bold;;;;"
attr SDM220M event-min-interval .*:60
attr SDM220M event-on-change-reading .*
attr SDM220M icon measure_power
attr SDM220M group SDM220Test
attr SDM220M stateFormat {\
my $vln=ReadingsNum($name,'Line_to_Neutral__V',0);;\
\
my $il=ReadingsNum($name,'Current__A',0);;\
\
my $pl=ReadingsNum($name,'Active_Power__W',0);;\
\
"\
<b>\
<br>\
<span style='color:#FFDD00'>Spannung L1<span style='color:transparent'>....<span style='color:#FFDD00'>$vln V\
<span style='color:transparent'>.............\
<span style='color:#AAFF00'>Strom L1<span style='color:transparent'>....<span style='color:#AAFF00'>$il A\
<span style='color:transparent'>.............\
<span style='color:#00FFFF'>Leistung L1<span style='color:transparent'>....<span style='color:#00FFFF'>$pl W\
<br>\
<br>\
</b></span>\
"\
}
Für das ModbusRS485_SDM220M ist deine Schnittstelle einzutragen.
define ModbusRS485_SDM220M Modbus /dev/serial/by-id/.....................@9600,8,N,1
attr ModbusRS485_SDM220M alias ModBus RS485 SDM220
attr ModbusRS485_SDM220M busDelay 0.5
attr ModbusRS485_SDM220M devStateIcon opened:lan_rs485@0CFB0C Open:lan_rs485@red disconnected:lan_rs485@red disabled:lan_rs485@orange
attr ModbusRS485_SDM220M devStateStyle style="text-align:left;;font-weight:bold;;"
attr ModbusRS485_SDM220M dropQueueDoubles 1
attr ModbusRS485_SDM220M enableQueueLengthReading 1
attr ModbusRS485_SDM220M frameGap 1.5
attr ModbusRS485_SDM220M group SDM220Test
attr ModbusRS485_SDM220M icon lan_rs485
attr ModbusRS485_SDM220M profileInterval 30
attr ModbusRS485_SDM220M queueDelay 1
attr ModbusRS485_SDM220M queueMax 100
attr ModbusRS485_SDM220M queueTimeout 5
attr ModbusRS485_SDM220M showError 1
attr ModbusRS485_SDM220M skipGarbage 1
Damit bleibt dann deine Energiezählerkonfiguration unangetastet.
auch das Register "h64514" wirft nur den Error. Kein Reading.
Ich schau heute Abend mit deiner .pm was geht
wollte es schnell aktivieren, bekomme ein
ModbusRS485_SDM220M can not be used as IODev, see log for details
im log
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.
.... 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
da du noch die 3 Readings drinnen hast, kommt wieder im IO Device als Error
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.
Zitat von: Burny4600 am 27 März 2025, 08:45:24EDIT 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
Zitatwollte es schnell aktivieren, bekomme ein
ModbusRS485_SDM220M can not be used as IODev, see log for details
Du hast das IO ModbusRS485_SDM220M anscheind nicht angelegt?
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.
Zitatda du noch die 3 Readings drinnen hast, kommt wieder im IO Device als Error
Deaktiviere einfach in meinem Modul die drei Readings zB.
# "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.
@NobbynewsZitatDas 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.
ZitatAnsonsten 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.
ZitatDaher 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.
Zitat von: Burny4600 am 30 März 2025, 13:36:24@Nobbynews
ZitatDas 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.
ZitatAnsonsten 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.
ZitatDaher 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.
ZitatMeine 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.
Zitat von: Burny4600 am 30 März 2025, 17:57:29weil 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.
Zitat von: Burny4600 am 30 März 2025, 13:36:24Du 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.
Zitat von: Burny4600 am 30 März 2025, 13:36:24Deaktiviere einfach in meinem Modul die drei Readings zB.
war zu deiner Info
Zitat von: Burny4600 am 30 März 2025, 13:36:24Verwende 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.
Zitat von: Burny4600 am 30 März 2025, 17:57:29Readings 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.
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
ZitatSeit 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
%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_VRInternals:
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.01FHEM 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.
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.
Zitat von: Burny4600 am 06 April 2025, 08:36:20ZitatSeit 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/ (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:
attr ModBusLine clientSwitchDelay 0.4
Hintergrund dazu ist mir entfallen.
Zitat von: Burny4600 am 06 April 2025, 08:36:20Ich 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.
connector: serialdev,/dev/serial/by-id/usb-busware.de_CUL868-if00,9600n81,local,NOBREAKFrag' mich jetzt aber bitte nicht, wo ich das gefunden habe.
ZitatDen 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
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
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
clientSwitchDelay 0.1aktiviert.
list ModbusRS485_7WS_EG_VRInternals:
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.07Es 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.
Zitat von: Burny4600 am 07 April 2025, 14:19:00ZitatDen 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.