Neue Versionen und Support zum Modbus-Modul

[Mike-Sbg]

Hat irgendwer sonst ein Tipp für mich, wie ich das Problem lösen kann?

[tobmaster1985]

Über die ID 200 kann ich auch die Min- und Max-Werte der Spannungen der einzelnen Blöcke auslesen. ID 200 geht aber bei WiNet-S nicht, und mit ID 2 kennt er die Register wohl nicht. Hast Du dazu eine Idee?

Mein SBR128 mit FW SBRBCU-S_22011.01.13 liefert weder über den WiNet-S (ID2), noch über den SH10RT (ID 200) die Werte zu den Zellspannungen.
Daher macht es für mich keinen Unterschied, ob ich über WiNet-S oder den Wechselrichter auslese.

ein Gerät mit ModbusAttr per TCP mit dem Slave verbindet und dann bei mehreren anderen ModbusAttr-Geräten das erste als IODev angeben kann.
[...]
bin mir aber nicht sicher ob es schon funktioniert ...

Aktuell tut es das nicht, oder ich hab was falsch konfiguriert.

ModbusAttr als RTU:
"SH10RT can not be used as IODev, see log for details"
ModbusAttr als TCP:
"Attr IODev is not allowed for devices connected through TCP"

Habe danach nicht weiter getestet.

Hat irgendwer sonst ein Tipp für mich, wie ich das Problem lösen kann?

Vielleicht Verbose Level erhöhen und logfile lesen. Evtl lässt sich dort ein Hinweis finden. So habe ich das Problem beim Registerscan gefunden.

Kannst du die Werte denn von anderen Geräten bzw mit anderen Tools abfragen?

[Mike-Sbg]

Danke für den Hinweis ... gibt es eine Möglichkeit irgendwo die Parameter die das Modus-Modul ausliest in ein Log-File zu dumpen ... ich habe den Verdacht, daß sich die Register verschoben haben:

2024-11-25_18:05:50 SolarEdge M_AC_POWER: 2.1062
2024-11-25_18:05:50 SolarEdge M_AC_POWER_A: 4.22
2024-11-25_18:05:50 SolarEdge M_AC_POWER_B: 10.924
2024-11-25_18:05:50 SolarEdge M_AC_POWER_C: 5.918
2024-11-25_18:05:50 SolarEdge M_AC_POWER_SF: -3

So als wären die Register für z.B. M_AC_Power nicht mehr in den Registern obj-h40206-expr zu finden.
Merkwürdig ist, wenn ich manuell eingreife und den M_AC_Power Wert den Divisor manchmal auf /10000 bzw. /100000 stelle stimmt es - so als würde die Umrechnung des Skalierungsfaktors manchmal nicht stimmen.

Kann mir da keinen Reim darauf machen ... und suche daher die noch unverarbeiteten Werte ...

(Als "richtigen" Wert verstehe ich die Werte die ich im Webfront-End der SolarEdgle-Cloud mir anzeigen lassen kann)

[Mike-Sbg]

Also sorry, ich habe den Fehler gefunden, hatte einen Groß-Kleinschreibfehler im Skalierungsfaktor ... jetzt schaut es soweit gut aus

[Rampler]

Hat jemand eine Idee, wie ich folgende Event Meldungen unterdrücken kann:

Code Auswählen Erweitern

2024-12-23 09:15:39 ModbusAttr GoodWe DISCONNECTED
2024-12-23 09:15:39 ModbusAttr GoodWe CONNECTED
Das Gerät trennt sich automatisch alle 90 Sekunden, wenn ich zu selten Abfrage. (Interval > 60 Sekunden)

silentReconnet und event-on-change (?!CONNECTED|DISCONNECTED).* führten nicht zum Erfolg.

[300P]

Ist zwar schon etwas her........

Hat jemand eine Idee, wie ich folgende Event Meldungen unterdrücken kann:

Code Auswählen Erweitern

2024-12-23 09:15:39 ModbusAttr GoodWe DISCONNECTED
2024-12-23 09:15:39 ModbusAttr GoodWe CONNECTED
Das Gerät trennt sich automatisch alle 90 Sekunden, wenn ich zu selten Abfrage. (Interval > 60 Sekunden)

silentReconnet und event-on-change (?!CONNECTED|DISCONNECTED).* führten nicht zum Erfolg.

Schau einmal welchen globalen "verbose-level" du gesetzt hast ??
Wenn der >=3 ist setzte bitte zuerst explizit den "verbose-level" im Modus-Device auf 2.
Falls dann weg - war es aus dem Modbus-Device heraus und gut ist..

Code Auswählen Erweitern

verbose
Setzt den Schwellwert für die Logfile-Meldungen. Mögliche Werte sind:
0 - Server start/stop
1 - Fehlermeldungen oder unbekannte Pakete
2 - bedeutende Ereigbisse/Alarme.
3 - ausgesendete Kommandos werden gelogged.
4 - von den einzelnen Geräten empfangene Daten.
5 - Fehlersuche.
Der für die global Instanz gesetzte Wert gilt als Voreinstellung für die Instanzen, die dieses Attribut nicht gesetzt haben
Falls das nicht hilft:
 
Bei eine globalen "verbose-level" von 3 kommt diese Meldung evtl. nicht vom Modbus-Device, sondern von einem anderen ??FHEM-Systemdevice??.
=>> Ich meine ich hatte so etwas ähnliches im VCONTROL300 auch mit einem IO-"System-Device" vor Jahren - nach dem Ändern auf 2 war es damit dann vorbei.


Gruß und ein "Frohes Neues Jahr" an Alle!
300P

[holle75]

Hello Ihr, ich habe seit letztem Update kleine Probleme mit freezes und disconnects. laut perfmon und apptime könnte da auch modbus RTU eine Rolle spielen (neben WOL). Da mir das apptime Protokoll nur grob was sagt .... : kann modbus überhaupt blockierend wirken?

list modbus Device (Eastron):

Code Auswählen Erweitern

Internals:
   DEF        /dev/ttyUSB1@9600,8,E,1
   DeviceName /dev/ttyUSB1@9600,8,E,1
   EXPECT     idle
   FD         31
   FUUID      5c86875c-f33f-6bb4-1f39-cb90bbe94b053f1b
   LASTOPEN   1742284950.86081
   MODE       master
   NAME       Eastron
   NOTIFYDEV  global
   NR         667
   NTFY_ORDER 50-Eastron
   PARTIAL   
   PROTOCOL   RTU
   STATE      opened
   SerialConn 1
   TYPE       Modbus
   devioLoglevel 3
   devioNoSTATE 1
   eventCount 15
   nextOpenDelay 60
   nextQueueRun 1742317449.38364
   QUEUE:
     HASH(0x950fa58)
     HASH(0x94f6d38)
     HASH(0x950fd58)
     HASH(0x94ab768)
     HASH(0x9516f18)
     HASH(0x950f9e0)
     HASH(0x94ea238)
     HASH(0x9516330)
     HASH(0x8fd6008)
     HASH(0x94faa88)
     HASH(0x951a9d8)
     HASH(0x950f158)
     HASH(0x939a738)
     HASH(0x94ccdc0)
     HASH(0x94e6fa0)
     HASH(0x94d6b10)
     HASH(0x94de908)
     HASH(0x94ee0c8)
     HASH(0x94cfc58)
     HASH(0x9372b08)
     HASH(0x939c578)
     HASH(0x93a69c8)
   READ:
     BUFFER     
   READINGS:
     2025-03-18 18:04:00   Profiler_Delay_sum 99.449
     2025-03-18 18:04:00   Profiler_Fhem_sum 2.716
     2025-03-18 18:04:00   Profiler_Idle_sum 8.427
     2025-03-18 18:04:00   Profiler_Read_sum 2.687
     2025-03-18 18:04:00   Profiler_Send_sum 0.378
     2025-03-18 18:04:00   Profiler_Wait_sum 6.344
     2025-03-18 18:04:00   Statistics_Requests 200
     2025-03-18 18:04:00   Statistics_Timeouts 0
     2025-03-18 09:02:31   state           opened
   REMEMBER:
     lid        93
     lname      Studer485_CAN
     lrecv      1742317449.38101
     lsend      1742317449.33566
   defptr:
     Studer485_CAN 93
     Studer485_Gateway 33
     Studer485_VT 53
     Studer485_XTM 43
     Xtender_AC_in 1
     Xtender_AC_out 2
   helper:
     bm:
       CODE(0x3279a60):
         cnt        87127
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        18.03. 15:46:42
         max        1.77820301055908
         tot        618.669062614441
         mAr:
           HASH(Eastron)
   profiler:
     lastKey    Idle
     lastPeriod 14519312
     start:
       Delay      1742317448.81364
       Fhem       1742317449.38224
       Idle       1742317449.38284
       Read       1742317449.38105
       Send       1742317449.33414
       Wait       1742317449.3357
     sums:
       Delay      8.16764879226685
       Fhem       0.198657751083374
       Idle       0.171351671218872
       Read       0.269441366195679
       Send       0.0335478782653809
       Wait       0.542197465896606
   statistics:
     lastPeriod 14519312
     sums:
       Requests   17
       Timeouts   0
Attributes:
   busDelay   0.5
   dropQueueDoubles 1
   event-on-change-reading Statistics_Timeouts
   group      Xtender
   profileInterval 120
   skipGarbage 1
   timeoutLogLevel 4
   verbose    2
und der spannendere obere Teil vom Apptime Log (nach maxDly sortiert):

Code Auswählen Erweitern

name                                     function                               max    count      total  average   maxDly   avgDly TS Max call     param Max call
 tmr-ProcessRequestQueue                  queue                                   36   125247  570587.92     4.56 37635.20    10.94 18.03. 10:28:14 queue:Eastron
 tmr-perfmon_ProcessTimer                 HASH_unnamed                             3    30649    4968.85     0.16 37440.75    20.88 18.03. 16:35:41 HASH(0xa3aa20)
 tmr-WOL_UpdateReadings                   HASH(0x32d2470)                         46      510   12586.05    24.68 37422.40    88.71 18.03. 15:56:08 HASH(Synology_WOL)
 tmr-WOL_UpdateReadings                   HASH(0x3269600)                         45      510   14255.66    27.95 37413.81    93.71 18.03. 17:59:30 HASH(NUC_WOL)
 tmr-FHEM2FHEM_keepalive                  HASH(0xa05ac8)                           8     3064    6711.60     2.19 37326.22    26.60 18.03. 12:09:27 HASH(fhem2fhemZurich)
 tmr-GetUpdate                            update                                  52    30118  544011.84    18.06 37062.54    26.94 18.03. 13:59:22 update:Studer485_CAN
 tmr-HMLAN_KeepAlive                      keepAlive                                5     1231    1870.59     1.52 33627.58    49.80 18.03. 10:35:19 keepAlive:HM_LAN_FUNK
 tmr-MQTT2_SERVER_keepaliveChecker        HASH(0x4b90e50)                         42     3066     762.46     0.25 32120.22    23.78 18.03. 13:57:49 HASH(MQTT2_FHEM_Server)
 tmr-NUT_PollTimer                        pollTimer                               13     3065    7183.60     2.34 32118.20    24.85 18.03. 14:28:20 pollTimer:EatonUSV
 tmr-HM485_LAN_KeepAlive                  keepAlive                                7     1492    4643.93     3.11 25134.19    34.67 18.03. 13:50:43 keepAlive:HM_LAN_WIRED
 tmr-SYSMON_Update                        HASH(0x383a008)                         65      512   16399.31    32.03 21007.03    51.29 18.03. 17:08:51 HASH(sysmon)
 tmr-FRITZBOX_Readout_Start               FritzBox.Readout                        42      512   11812.95    23.07 19381.89    51.87 18.03. 15:09:50 FritzBox.Readout
 tmr-FW_closeInactiveClients              0                                       23      512    2732.20     5.34 19318.78    52.95 18.03. 17:23:52 0
 tmr-at_Exec                              HASH(0x3278768)                        209      559    8996.03    16.09 16216.96    53.70 18.03. 10:24:53 HASH(Studer485_Gateway_Trigger_AT)
 tmr-PRESENCE_StartLocalScan              HASH(0x4a898b8)                         41      924   21739.70    23.53 15954.34    40.13 18.03. 16:56:17 HASH(InternetOnPresence)
 tmr-PRESENCE_StartLocalScan              HASH(0x21c2328)                         41      291    7170.56    24.64  7238.69    41.57 18.03. 17:29:10 HASH(Nicole_iPhonePing)
 tmr-PRESENCE_StartLocalScan              HASH(0x2e099b0)                         40      330    7790.19    23.61  5088.28    30.88 18.03. 14:00:57 HASH(SqueezeBoxServerPresence)
 tmr-dnsQuery                             HASH(0x8ce4418)                          0        1       0.17     0.17  3165.03  3165.03 18.03. 17:02:37 HASH(DNS)
 tmr-ResponseTimeout                      timeout                                  0        3       2.02     0.67  2526.46  1646.96 18.03. 15:02:37 timeout:Eastron
 tmr-HMLAN_KeepAliveCheck                 keepAliveCk                              0     1228     105.79     0.09  1584.09    24.94 18.03. 10:28:14 keepAliveCk:HM_LAN_FUNK
 tmr-PRESENCE_StartLocalScan              HASH(0x12493b0)                         34      669   15834.12    23.67   766.16    17.70 18.03. 17:42:08 HASH(Holger_iPhonePing)
 tmr-BlockingKill                         HASH_unnamed                             0      212      11.39     0.05   448.75    13.33 18.03. 10:10:44 HASH(0x6301648)
 tmr-CUL_HM_ActCheck                      ActionDetector                          26       51     248.39     4.87   391.87    13.34 18.03. 15:02:31 ActionDetector

[StefanStrobel]

Hallo Holle75,

eigentlich wüsste ich nicht wie das Modbus-Modul blockieren sollte. Im letzten Jahr gab es auch keine größeren Änderungen.

Gruss
    Stefan

[holle75]

Hallo Stefan, kann es sein, dass die Abfrage des Buses einfach ab und zu länger dauert und das Modul dann als Übeltäter geloggt wird? Ich verstehe apptime nicht so ganz.

Ich tippe auf ein Zusammenspiel von mehreren Faktoren (habe zB im selben Zeitraum fhem2fhem implementiert), kann aber apptime nicht interpretieren. Deswegen stochere ich in allen Eventualitäten rum.

Kann ich modbus irgendeine MaxZeit vorgeben, die es auf Antwort wartet? Oder ist das nicht sowieso schon so?

[holle75]

Habe noch einen Fehler in meiner DEF von einem Device gefunden.

Schreiben tue ich nur ins RAM vom Wechselrichter. Um nicht in die Holding-Register direkt zu schreiben muss man der jeweiligen Adresse 6000 dazuaddieren.

Jetzt hatte ich aber ein

Code Auswählen Erweitern

attr Studer485_CAN dev-defPoll 1
anstatt jetzt

Code Auswählen Erweitern

attr Studer485_CAN dev-i-defPoll 1
gesetzt. Modbus hat versucht die (nicht wirklich vorhandenen) Holding Register auszulesen und scheinbar dabei verzögert/blockiert.

Ich weiß es nicht genau, aber seit der Änderung (24h) keine Freezes mehr.

Kann das sein?! ... oder Zufall?

EDIT: und eine weitere Frage. Warum auch immer, habe ich das IO Device "Eastron" benannt. Wahrscheinlich, als noch gar keinen Plan, Rogers template/anleitung für die Stromzähler vor hundert Jahren gefolgt. Jetzt wollte ich das Device umbennenen, geht aber nicht. Ist das aufgrund der Verknüpfungen mit den eigentlichen Devices nicht möglich?

[Jewe]

Hi,
leider komme ich nicht weiter...ich habe einen Waveshare Modbus TCP to RTU Gateway. An dem ist ein Feuchtesensor mir rs485 angeschlossen. Wenn ich in der Konsole die Verbindung teste und ein Resgister lese bekomme ich das:

Code Auswählen Erweitern

mbpoll -a 1 -r 4 192.168.6.33 -p 5000

mbpoll 1.0-0 - FieldTalk(tm) Modbus(R) Master Simulator
Copyright © 2015-2019 Pascal JEAN, https://github.com/epsilonrt/mbpoll
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions; type 'mbpoll -w' for details.

Protocol configuration: Modbus TCP
Slave configuration...: address = [1]
                        start reference = 4, count = 1
Communication.........: 192.168.6.33, port 5000, t/o 1.00 s, poll rate 1000 ms
Data type.............: 16-bit register, output (holding) register table

-- Polling slave 1... Ctrl-C to stop)
[4]:    77
-- Polling slave 1... Ctrl-C to stop)
[4]:    82
-- Polling slave 1... Ctrl-C to stop)
[4]:    82
Also der Sensor gibt Werte raus, huer das register 4.

In Fhem habe ich folgendes definiert:

Code Auswählen Erweitern

define myModbus Modbus 192.168.6.33:5000 TCP
attr myModbus DbLogExclude .*
attr myModbus group Sticks
attr myModbus icon it_net
attr myModbus room Soil
attr myModbus verbose 5
#  DEF        192.168.6.33:5000 TCP
#  DeviceName 192.168.6.33:5000
#  EXPECT    idle
#  FD        4
#  FUUID      67e0124b-f33f-2563-eacf-23e2222ab7888b89
#  IODev      myModbus
#  LASTOPEN  1742738741.4696
#  MODE      master
#  NAME      myModbus
#  NOTIFYDEV  global
#  NR        61
#  NTFY_ORDER 50-myModbus
#  PARTIAL   
#  PROTOCOL  RTU
#  STATE      opened
#  TCPConn    1
#  TIMEOUTS  412
#  TYPE      Modbus
#  devioLoglevel 3
#  devioNoSTATE 1
#  eventCount 1
#  nextOpenDelay 60
#  FRAME:
#  QUEUE:
#  READ:
#  READINGS:
#    2025-03-23 15:05:41  state          opened
#  REMEMBER:
#    lid        1
#    lname      myModbus
#    lsend      1742741789.25838
#  defptr:
#    SoilSensor 1
#
setstate myModbus opened
setstate myModbus 2025-03-23 15:05:41 state opened

und der Sensor:

Code Auswählen Erweitern

define SoilSensor ModbusAttr 1 10
attr SoilSensor IODev myModbus
attr SoilSensor obj-h0-expr $val * 0.1
attr SoilSensor obj-h0-format %.1f
attr SoilSensor obj-h0-reading Bodenfeuchte
attr SoilSensor obj-h1-expr $val * 0.1
attr SoilSensor obj-h1-format %.1f
attr SoilSensor obj-h1-reading Bodentemperatur
attr SoilSensor obj-h2-expr $val
attr SoilSensor obj-h2-reading Leitfaehigkeit
attr SoilSensor obj-h3-expr $val * 0.1
attr SoilSensor obj-h3-format %.1f
attr SoilSensor obj-h3-reading PH-Wert
attr SoilSensor obj-h4-expr $val
attr SoilSensor obj-h4-reading Stickstoff
attr SoilSensor obj-h5-expr $val
attr SoilSensor obj-h5-reading Phosphor
attr SoilSensor obj-h6-expr $val
attr SoilSensor obj-h6-reading Kalium
attr SoilSensor room Soil
attr SoilSensor verbose 5
#  CFGFN     
#  DEF        1 10
#  FUUID      67e01b0b-f33f-2563-39b7-ec7fcac307671d32
#  IODev      myModbus
#  Interval  10
#  MODBUSID  1
#  MODE      master
#  MODULEVERSION Modbus 4.5.6 - 7.11.2023
#  NAME      SoilSensor
#  NOTIFYDEV  global
#  NR        62
#  NTFY_ORDER 50-SoilSensor
#  PROTOCOL  RTU
#  STATE      active
#  TYPE      ModbusAttr
#  devioNoSTATE 1
#  eventCount 16
#  FRAME:
#  READ:
#  READINGS:
#    2025-03-23 16:37:47  IODev          myModbus
#    2025-03-23 16:37:47  state          opened
#  REMEMBER:
#    lsend      1742741789.25838
#  UPDATECACHE:
#  lastRead:
#
setstate SoilSensor active
setstate SoilSensor 2025-03-23 16:37:47 IODev myModbus
setstate SoilSensor 2025-03-23 16:37:47 state opened

Aus der Doku des Sensors:

Code Auswählen Erweitern

Default device address is 1, RS485
Default parameters 48 00,n,8,1
Register map:
Read status registers, read function code: 0x30
Register
address
(Hex)
P
LC
A
dd ress
(
decimal
meaning
Number
of bytes
c
ontent remark
0000
40001
2
0.1
%RH r
ead
000
1 4000
2 T
e mperature 2
0.1
0.1℃
r
ead
000
2 4000
3 Conductivity
2
1
r
ead
000
3 4000
4 P
H 2
0.
1 r
ead
000
4 4000
5 Nitrogen
( 2
1 mg/kg
read / write
000
5 4000
6 Phosphorus
( 2
1 mg/kg
read / write
000
6 4000
7 Potassium
( 2
1 mg/kg
read / write
000
7 4000
8 S
alinity 2
1
mg/L r
ead
000
8 4000
9 T
DS 2
1
mg/L r
ead
0022
40035
Conductivity
factor 2
0
100 correspond
to 0.0% 10.0%
Default
0.0%
read / write
Ich bekomme keinerlei readings. Habe es auch schon mit z.B. h40004 probiert.

Im Log bekomme ich das:

Code Auswählen Erweitern

2025.03.23 16:49:53 5: SoilSensor: CreateUpdateHash full object list: h0 h1 h2 h3 h4 h5 h6
2025.03.23 16:49:53 4: SoilSensor: CombineUpdateHash objHash keys before combine:
2025.03.23 16:49:53 5: SoilSensor: CombineUpdateHash tries to combine read commands
2025.03.23 16:49:53 5: SoilSensor: CombineUpdateHash keys are now
2025.03.23 16:49:53 4: SoilSensor: GetUpdate will now create requests for
2025.03.23 16:50:03 4: SoilSensor: GetUpdate (V4.5.6 - 7.11.2023) called from Fhem internal timer
2025.03.23 16:50:03 4: SoilSensor: UpdateTimer called from GetUpdate with cmd next sets timer to call update function in 10.0 sec at 16:50:13.056, interval 10

Wo ist der Fehler? Da ich in der Konsole eine Antwort bekomme sollte es bis dahin ja funktionieren, also ist in Fhem was faul?

LG, Jens

[StefanStrobel]

Hallo holle75,

Hallo Stefan, kann es sein, dass die Abfrage des Buses einfach ab und zu länger dauert und das Modul dann als Übeltäter geloggt wird? Ich verstehe apptime nicht so ganz.
...
Kann ich modbus irgendeine MaxZeit vorgeben, die es auf Antwort wartet? Oder ist das nicht sowieso schon so?

Die normalen Update-Zyklen von ModbusAttr laufen asynchron.
Ein Request wird gesendet und Fhem ruft das Modul wieder auf wenn eine Antwort oder ein Fehler kommt.
Dabei kann per Attribut ein Timeout gesetzt werden. Per Default sind das 2 Sekunden.

Nur bei den Fhem-Befehlen get oder set wird ja das Ergebnis benötigt und dann läuft das synchron (außer wenn das Attribut nonPrioritizedGet auf 1 gesetzt wird)

Gruss
  Stefan

[StefanStrobel]

Hallo Jewe,

es fehlt das Attribut poll bzw. defPoll...

Gruss
   Stefan

[holle75]

Danke Stefan. Mmh, dann sollte das nicht blockieren ..... ich beobachte weiter, ob die Umstellung wirklich die Freezes eliminiert hat.

Falls du Muse hast, hier noch eine Beobachtung im Zuge der Fehlersuche -> https://forum.fhem.de/index.php?topic=141167.msg1337683#msg1337683

[Jewe]

Hallo Jewe,

es fehlt das Attribut poll bzw. defPoll...

Gruss
  Stefan

In der tat, das fehlt, habe es nun eingefügt, aber es werden trotzdem keine Readings erzeugt.
Wenn ich mir im myModbus Master den LAST_ERROR anzeigen lasse kommt ständig ein timeout.
   timeout waiting for reply to fc 3 to id 3, h0, len 7

Was heisst darin FC3 ?