Neue Versionen und Support zum Modbus-Modul

[Nobbynews]

Guten Morgen,

ich habe für meinen SDM72DM-V2 MID basierend auf dem Modul für den SDM630 ein Modul 98_ModbusSDM72DMV2.pm erstellt.
Bei den Holding Registers habe ich aber noch ein paar Verständnisprobleme.
Wenn ich z.B. die Pulskonstante, Register 40023, ändern möchte, bekomme ich eine Fehlermeldung und zwar:

set value 1 did not match defined map

Auch klappt das Auslesen der Seriennummer im Register 464513 nicht.
Vielleicht kann sich das mal einer der Spezialisten ansehen?

Norbert

7.4.22  Dateianhang entfernt und neue Version eingstellt
neue Version hier: https://forum.fhem.de/index.php/topic,75638.msg1217182.html#msg1217182

[StefanStrobel]

Hallo Norbert,

mit der Map, die Du für h22 angegeben hast, wird der Wert im Register für die Ein- und Ausgabe umgewandelt.
1:100imp/kWh gibt statt dem Registerwert 1 ein 100imp/kWh aus. Bei der Benutzereingabe läuft es genau anders herum. Statt 1 verwendet man beim set 100imp/kWh. Das Modul übersetzt das dann in 1.

Gruß
    Stefan

[Nobbynews]

Hallo Stefan,

soweit ist mir das schon klar. Aber woher kommt die Fehlermeldung?
Syntaxfehler im Modul?
Ich steh' ein wenig auf dem Schlauch.

Norbert

[Nobbynews]

Ich habe noch ein wenig rumprobiert.
Dabei ist mir folgende Fehlermeldung aufgefallen:

Code Auswählen Erweitern

2022.03.27 21:44:52 3: ModBusLine: Send function code 10 not yet implemented
2022.03.27 21:44:52 1: PERL WARNING: Use of uninitialized value $pdu in concatenation (.) or string at ./FHEM/98_Modbus.pm line 3616.
2022.03.27 21:44:52 1: stacktrace:
2022.03.27 21:44:52 1:     main::__ANON__                      called by ./FHEM/98_Modbus.pm (3616)
2022.03.27 21:44:52 1:     Modbus::PackFrame                   called by ./FHEM/98_Modbus.pm (3364)
2022.03.27 21:44:52 1:     Modbus::ProcessRequestQueue         called by ./FHEM/98_Modbus.pm (3193)
2022.03.27 21:44:52 1:     Modbus::QueueRequest                called by ./FHEM/98_Modbus.pm (3133)
2022.03.27 21:44:52 1:     Modbus::DoRequest                   called by ./FHEM/98_Modbus.pm (1099)
2022.03.27 21:44:52 1:     Modbus::SetLDFn                     called by fhem.pl (3926)
2022.03.27 21:44:52 1:     main::CallFn                        called by fhem.pl (1955)
2022.03.27 21:44:52 1:     main::DoSet                         called by fhem.pl (1987)
2022.03.27 21:44:52 1:     main::CommandSet                    called by fhem.pl (1272)
2022.03.27 21:44:52 1:     main::AnalyzeCommand                called by ./FHEM/01_FHEMWEB.pm (2801)
2022.03.27 21:44:52 1:     main::FW_fC                         called by ./FHEM/01_FHEMWEB.pm (981)
2022.03.27 21:44:52 1:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (608)
2022.03.27 21:44:52 1:     main::FW_Read                       called by fhem.pl (3931)
2022.03.27 21:44:52 1:     main::CallFn                        called by fhem.pl (780)
2022.03.27 21:44:52 1: PERL WARNING: Use of uninitialized value $pdu in concatenation (.) or string at ./FHEM/98_Modbus.pm line 3617.
2022.03.27 21:44:52 1: stacktrace:
2022.03.27 21:44:52 1:     main::__ANON__                      called by ./FHEM/98_Modbus.pm (3617)
2022.03.27 21:44:52 1:     Modbus::PackFrame                   called by ./FHEM/98_Modbus.pm (3364)
2022.03.27 21:44:52 1:     Modbus::ProcessRequestQueue         called by ./FHEM/98_Modbus.pm (3193)
2022.03.27 21:44:52 1:     Modbus::QueueRequest                called by ./FHEM/98_Modbus.pm (3133)
2022.03.27 21:44:52 1:     Modbus::DoRequest                   called by ./FHEM/98_Modbus.pm (1099)
2022.03.27 21:44:52 1:     Modbus::SetLDFn                     called by fhem.pl (3926)
2022.03.27 21:44:52 1:     main::CallFn                        called by fhem.pl (1955)
2022.03.27 21:44:52 1:     main::DoSet                         called by fhem.pl (1987)
2022.03.27 21:44:52 1:     main::CommandSet                    called by fhem.pl (1272)
2022.03.27 21:44:52 1:     main::AnalyzeCommand                called by ./FHEM/01_FHEMWEB.pm (2801)
2022.03.27 21:44:52 1:     main::FW_fC                         called by ./FHEM/01_FHEMWEB.pm (981)
2022.03.27 21:44:52 1:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (608)
2022.03.27 21:44:52 1:     main::FW_Read                       called by fhem.pl (3931)
2022.03.27 21:44:52 1:     main::CallFn                        called by fhem.pl (780)
2022.03.27 21:44:54 3: ModBusLine: Timeout in Readanswer, read buffer empty,
request: id 1, write fc 10 h58, len 2, value 41200000, master device SDM72, reading scrollDisplaytime (set scrollDisplaytime), queued 2.00 secs ago, sent 2.00 secs ago   

Die Angabe zum function code für das Schreiben der Holdings habe ich aus der Doku.
https://xn--stromzhler-v5a.eu/media/pdf/93/17/d7/SDM72DM-V2.pdf

Beim SDM630 ist dafür der code 16 angegeben.

[StefanStrobel]

Hallo Norbert,

So wie Du die Map definiert hast, erwartet das Modul beim set einen Wert wie "100imp/kWh" und möchte den dann in eine 1 übersetzen. Wenn Du aber beim set eine 1 angeben möchtest, dann darfst Du keine Map verwenden. Oder eben beim set den Wert 100imp/kWh und nicht 1 angeben.
Die Meldung besagt genau das: Du hast einen Wert angegeben, der nicht zur Map passt.

Was den zweiten Fehler angeht, so hast Du scheinbar statt function code 16 fälschlicherweise function code 10 definiert. Die Meldung weist darauf hin dass der nicht implementiert ist. Den (Dezimal 10 bzw. Hex 0x0A) gibt es übrigens auch im Standard nicht.

Gruß
    Stefan

[Nobbynews]

Was den zweiten Fehler angeht, so hast Du scheinbar statt function code 16 fälschlicherweise function code 10 definiert. Die Meldung weist darauf hin dass der nicht implementiert ist. Den (Dezimal 10 bzw. Hex 0x0A) gibt es übrigens auch im Standard nicht.

Ahh, dann ist die Angabe für den code als Hex-Wert zu verstehen.
Das mit dem mapping schaue ich mir noch enmal an.

Norbert

[Nobbynews]

So wie Du die Map definiert hast, erwartet das Modul beim set einen Wert wie "100imp/kWh" und möchte den dann in eine 1 übersetzen. Wenn Du aber beim set eine 1 angeben möchtest, dann darfst Du tatt

Die Kombination aus map und hint habe ich so aus dem Modul SDM630 übernommen.
Daher hatte ich die Kombi daraus nicht weiter betrachtet und es verhält sich anders, als ich erwartet hatte.
Ich habe es geändert und jetzt funktioniert es.
Das Schreiben der holdings klappt jetzt auch.
Die Datei im Post#900 habe ich ausgetauscht.

[Nobbynews]

Hallo zusammen,

ich habe am meinem Modul zum SDM72DMv2 noch ein paar Änderungen vorgenommen.
Weiterhin habe ich noch ein Modul für den SDM120 erstellt.

[der-Lolo]

Guten Abend Zusammen,
es hat nun über ein Jahr gedauert um den Optidrive FU endlich anzuschliessen...
Ich habe im letztem Jahr einfach nicht mehr die Zeit gehabt - und brauchte ja die Pumpe des Pools um die Wasserqualität aufrecht zu erhalten.
Ausserdem musste ich ja auch noch den Pool benutzen.
Hier mein Beitrag vom letztem Jahr nochmal:

Hallo Stefan - und mitleser,
ich habe mir einen Invertek Optidrive E3 Frequenzumrichter gekauft - und möchte diesen mit dem Modbus/RTU Modul in FHEM einbinden.
Aus den gegebenen Daten werde ich allerdings nicht richtig schlau.

Ich benutze den USB-RS485 Adapter von IN-Circuit und bin schon unsicher was die Stellungen der DIP-Switches angeht.
Ich habe es auch noch nicht geschafft eine vernünftige Antwort des FUs zu bekommen.

Ich habe zwar vor etwa 5 Jahren schon eine Modbus/RTU definition für meinen Wärmemengenzähler erstellt, diese läuft aber so problemlos das ich da nie wieder ran musste und ich über die Jahre natürlich die vorgehensweise vergessen habe.

Als Anhang mal die Seite der BA des FUs auf der es um den Modbus geht...

Fühlt sich jemand in der lage mir zu helfen - sodass ich z.b. mal ein Beispiel Reading habe?
Das wäre toll!

Wir haben damals noch Beispielhaft ein erstes reading erstellt ung geschaut ob der Datentransfer funktioniert.

Heute habe ich nun den Pool wieder ausgewintert und die Pumpe diesesmal direkt mit FU in Betrieb genommen. Grundsätzlich bin ich begeistert wie gut die Pumpe mit dem FU funktioniert, auch darüber das das alles deutlich leider geworden ist.

Ich habe jetzt das Modbus Modul wieder auf den FU losgelassen, und erste readings hinzugefügt. Mir stellt sich aber noch die dringende frage wie ich den FU schalten kann. Ich könnte dem Ding einfach den Saft abdrehen, das ist aber nicht ganz in meinem Sinn...

Im FHEM Log habe ich nun einige eigenartige einträge die ich noch nicht verstehe, vielleicht könnt ihr mir was dazu sagen.

Code Auswählen Erweitern

2022.05.07 20:55:56 1: OWXTHERM_BinValues:  PoolTemp: invalid CRC,  15.625  0xfa 0x00 0x4b 0x46 0x7f 0x7f 0x03 0x08 0xd2
2022.05.07 20:55:54 1: OWXTHERM_BinValues:  AbsorberTemp: invalid CRC,  -113.3125  0xeb 0x80 0x25 0xa3 0xbf 0xff 0x02 0x08 0xf3
2022.05.07 20:55:13 1: OWXTHERM_BinValues:  SolarRLTemp: invalid CRC,  18.875  0x2e 0x01 0x4b 0xa6 0xbf 0x7f 0x01 0x08 0x9c
2022.05.07 20:54:47 1: OWXTHERM_BinValues:  AbsorberTemp: invalid CRC,  14.75  0xec 0x00 0x4b 0x46 0x7f 0xff 0x04 0x08 0xf9
2022.05.07 20:54:40 3: modbusRTU: readfn got data while EXPECT was set to idle: 0103020000b844
2022.05.07 20:54:36 1: OWXTHERM_BinValues:  AbsorberTemp: invalid CRC,  14.75  0xec 0x00 0x4b 0x46 0x7f 0xff 0x04 0x10 0xf9
2022.05.07 20:54:29 3: modbusRTU: readfn got data while EXPECT was set to idle: 0103020029799abfbfbf
2022.05.07 20:54:18 3: modbusRTU: readfn got data while EXPECT was set to idle: 0103020000b844
2022.05.07 20:54:17 1: OWXTHERM_BinValues:  SolarRLTemp: invalid CRC,  -109.125  0x2e 0x81 0x25 0xa3 0xbf 0x7f 0x01 0x08 0x9c
2022.05.07 20:54:02 1: OWXTHERM_BinValues:  AbsorberTemp: invalid CRC,  14.875  0xee 0x00 0x4b 0x46 0x7f 0xff 0x02 0x08 0xef
2022.05.07 20:53:55 3: modbusRTU: readfn got data while EXPECT was set to idle: 0103020029799a
2022.05.07 20:53:53 1: OWXTHERM_BinValues:  PoolTemp: invalid CRC,  15.625  0xfa 0x00 0x4b 0xa3 0xbf 0x7f 0x03 0x08 0xd2
2022.05.07 20:53:44 3: modbusRTU: readfn got data while EXPECT was set to idle: 0103020000b844
2022.05.07 20:53:40 1: OWXTHERM_BinValues:  AbsorberTemp: invalid CRC,  14.75  0xec 0x00 0x4b 0x46 0x7f 0xff 0x04 0x10 0xf9
2022.05.07 20:53:22 3: modbusRTU: readfn got data while EXPECT was set to idle: 0103020029799a
2022.05.07 20:53:11 3: modbusRTU: readfn got data while EXPECT was set to idle: 0103020000b844
2022.05.07 20:53:00 3: modbusRTU: readfn got data while EXPECT was set to idle: 0103020000b844
2022.05.07 20:52:55 1: OWXTHERM_BinValues:  AbsorberTemp: invalid CRC,  14.9375  0xef 0x00 0x4b 0x46 0x7f 0xff 0x01 0x10 0xe4
2022.05.07 20:52:48 3: modbusRTU: readfn got data while EXPECT was set to idle: 0103020028b85abfbfbfbfbfbfbfbfbfbfbfbfffbfbfbfbfbfbfbfbfbfbfbfbfbfbfbf
2022.05.07 20:52:37 3: modbusRTU: readfn got data while EXPECT was set to idle: 0103020000b844
2022.05.07 20:52:26 3: modbusRTU: readfn got data while EXPECT was set to idle: 0103020000b844bfbf
2022.05.07 20:51:41 3: modbusRTU: readfn got data while EXPECT was set to idle: 0103020028b85a
2022.05.07 20:51:37 1: OWXTHERM_BinValues:  AbsorberTemp: invalid CRC,  15  0xf0 0x00 0x4b 0x46 0x7f 0x7f 0x08 0x88 0xd3
2022.05.07 20:51:30 3: modbusRTU: readfn got data while EXPECT was set to idle: 0103020000b844
2022.05.07 20:50:57 3: modbusRTU: readfn got data while EXPECT was set to idle: 0103020000b844
2022.05.07 20:50:43 1: OWXTHERM_BinValues:  PoolTemp: invalid CRC,  15.625  0xfa 0x00 0x4b 0x46 0x7f 0xff 0x06 0x10 0xd4
2022.05.07 20:50:35 3: modbusRTU: readfn got data while EXPECT was set to idle: 0103020028b85abfbfbfbfbfbfbfbfbfbf
2022.05.07 20:50:26 3: modbusRTU: readfn got data while EXPECT was set to idle: 0103020000b844
2022.05.07 20:50:24 3: modbusRTU: readfn got data while EXPECT was set to idle: 0103020000b844
2022.05.07 20:50:01 3: modbusRTU: readfn got data while EXPECT was set to idle: 0103020028b85a
2022.05.07 20:49:50 3: modbusRTU: readfn got data while EXPECT was set to idle: 0103020000b844
2022.05.07 20:49:38 1: OWXTHERM_BinValues:  SolarRLTemp: invalid data,  18.875  0x2e 0x01 0x4b 0x46 0x7f 0xff 0x02 0x00 0x9c
2022.05.07 20:49:28 3: modbusRTU: readfn got data while EXPECT was set to idle: 0103020027f85e
2022.05.07 20:49:28 1: OWXTHERM_BinValues:  SolarRLTemp: invalid CRC,  18.875  0x2e 0x01 0x4b 0x46 0x7f 0xff 0x02 0x10 0xce
2022.05.07 20:49:23 1: OWXTHERM_BinValues:  AbsorberTemp: invalid CRC,  14.9375  0xef 0x00 0x4b 0xa2 0xbf 0xff 0x00 0x08 0xe4
2022.05.07 20:49:12 1: OWXTHERM_BinValues:  AbsorberTemp: invalid CRC,  -0.0625  0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2022.05.07 20:49:01 1: OWXTHERM_BinValues:  AbsorberTemp: invalid CRC,  15.0625  0xf1 0x00 0x4b 0x46 0x7f 0xff 0x07 0x88 0xfc
2022.05.07 20:48:54 3: modbusRTU: readfn got data while EXPECT was set to idle: 0103020027f85e
2022.05.07 20:48:46 3: modbusRTU: readfn got data while EXPECT was set to idle: 0103020000b844
2022.05.07 20:48:43 3: modbusRTU: readfn got data while EXPECT was set to idle: 0103020000b844
2022.05.07 20:48:32 3: modbusRTU: readfn got data while EXPECT was set to idle: 0103020000b844
2022.05.07 20:47:03 3: modbusRTU: readfn got data while EXPECT was set to idle: 0103020000b844
2022.05.07 20:46:52 3: modbusRTU: readfn got data while EXPECT was set to idle: 0103020000b844
2022.05.07 20:46:18 3: modbusRTU: readfn got data while EXPECT was set to idle: 0103020000b844
2022.05.07 20:45:56 3: modbusRTU: readfn got data while EXPECT was set to idle: 0103020000b844
2022.05.07 20:45:51 1: OWXTHERM_BinValues:  AbsorberTemp: invalid data,  15  0xf0 0x00 0x4b 0x46 0x7f 0xff 0x10 0x00 0xa7
2022.05.07 20:45:18 1: OWXTHERM_BinValues:  AbsorberTemp: invalid CRC,  15.125  0xf2 0x00 0x4b 0xa2 0xbf 0x7f 0x07 0x08 0xfc

Bevor ich den FU benutzt habe hatte ich keine CRC Fehler beim OWX - damit könnte ich aber wohl noch leben, ich vermute hier vielleicht einen zusammenhang mit den Frequenzen des Umrichters, obwohl natürlich ein abgeschirmtes Kabel zum Einsatz kommt.

Eigenartig sind aber auch die Meldungen des modbusRTU Moduls. Was haben die zu sagen?

Der vollständigkeit halber noch ein List des FUs bisher:

Code Auswählen Erweitern

Internals:
   DEF        1 15
   FUUID      605728c9-f33f-cc16-22a8-16628e1f3a34f255
   IODev      modbusRTU
   Interval   15
   LeadingZeros 1
   MODBUSID   1
   MODE       master
   MODULEVERSION Modbus 4.4.04 - 17.7.2021
   NAME       Optidrive
   NOTIFYDEV  global
   NR         25
   NTFY_ORDER 50-Optidrive
   PROTOCOL   RTU
   STATE      opened
   TYPE       ModbusAttr
   FRAME:
   OLDREADINGS:
   READ:
   READINGS:
     2022-05-07 21:35:36   Frequenz        20
     2022-05-07 21:35:36   UmrichterTemperatur 30.8
     2022-05-07 21:35:47   Verzoegerungszeit 0
     2022-05-07 21:35:46   scan-h00001     0
     2022-05-07 21:35:47   scan-h00002     0
     2022-05-07 21:35:47   scan-h00005     0
     2022-05-07 21:35:47   scan-h00006     0
     2022-05-07 21:35:47   scan-h00007     0
     2022-05-07 21:35:47   scan-h00008     0
     2022-05-07 21:35:47   scan-h00010     0
     2022-05-07 21:35:47   scan-h00011     8769
     2022-05-07 21:35:47   scan-h00012     110
     2022-05-07 21:35:34   scan-h00013     230
     2022-05-07 21:35:34   scan-h00014     305
     2022-05-07 21:35:34   scan-h00015     305
     2022-05-07 21:35:34   scan-h00017     0
     2022-05-07 21:35:35   scan-h00018     0
     2022-05-07 21:35:35   scan-h00019     0
     2022-05-07 21:35:36   scan-h00020     0
     2022-05-07 21:35:36   scan-h00021     20
     2022-05-07 21:35:36   scan-h00023     30
     2022-05-07 21:35:36   scan-h00024     1
     2022-05-07 21:35:36   scan-h00025     2
     2022-05-07 21:35:36   scan-h00026     8762
     2022-05-07 21:35:36   scan-h00027     60
     2022-05-07 21:35:37   scan-h00028     0
     2022-05-07 21:35:37   scan-h00029     0
     2022-05-07 21:35:37   scan-h00030     0
     2022-05-07 21:35:37   scan-h00031     169
     2022-05-07 21:35:37   scan-h00032     0
     2022-05-07 21:35:37   scan-h00033     344
     2022-05-07 21:35:40   scan-h00035     6
     2022-05-07 21:35:43   scan-h00037     0
     2022-05-07 21:35:44   scan-h00038     39
     2022-05-07 17:22:45   state           opened
   REMEMBER:
     lrecv      1651952149.07814
     lsend      1651952149.0718
   gotReadings:
     scan-h00012 110
   lastRead:
     h00001     1651952146.95708
     h00002     1651952147.06438
     h00005     1651952147.17662
     h00006     1651952147.39997
     h00007     1651952147.51164
     h00008     1651952147.62375
     h00010     1651952147.73539
     h00011     1651952147.84935
     h00012     1651952147.95884
     h00013     1651952134.39338
     h00014     1651952134.50547
     h00015     1651952134.61772
     h00017     1651952134.72984
     h00018     1651952135.85269
     h00019     1651952135.95616
     h00020     1651952136.07154
     h00021     1651952136.18413
     h00023     1651952136.51883
     h00024     1651952136.63094
     h00025     1651952136.74303
     h00026     1651952136.85512
     h00027     1651952136.96732
     h00028     1651952137.08324
     h00029     1651952137.1903
     h00030     1651952137.30238
     h00031     1651952137.41448
     h00032     1651952137.52791
     h00033     1651952137.63758
     h00035     1651952140.85418
     h00037     1651952143.06529
     h00038     1651952144.26827
     h1         1651935531.60758
     h10        1651935551.37809
     h11        1651935551.48418
     h12        1651935552.43417
     h13        1651935554.05189
     h14        1651935555.04006
     h15        1651935561.21311
     h17        1651935562.53435
     h18        1651935563.43625
     h19        1651935565.03555
     h2         1651935532.59896
     h20        1651935566.04808
     h21        1651952136.29673
     h22        1651952136.40846
     h23        1651935573.87173
     h24        1651935574.89272
     h25        1651935575.88447
     h26        1651935577.69951
     h27        1651935584.91814
     h28        1651935585.01575
     h29        1651935585.1649
     h30        1651935585.99413
     h31        1651935587.56223
     h32        1651935588.55449
     h33        1651935593.71163
     h35        1651935596.0538
     h37        1651935598.5601
     h38        1651935599.57278
     h5         1651935540.41586
     h6         1651952147.29162
     h7         1651935542.38923
     h8         1651935544.21082
Attributes:
   dev-h-defPoll 1
   obj-h00001-reading scan-h00001
   obj-h00002-reading scan-h00002
   obj-h00005-reading scan-h00005
   obj-h00006-reading scan-h00006
   obj-h00007-reading scan-h00007
   obj-h00008-reading scan-h00008
   obj-h00010-reading scan-h00010
   obj-h00011-reading scan-h00011
   obj-h00012-reading scan-h00012
   obj-h00013-reading scan-h00013
   obj-h00014-reading scan-h00014
   obj-h00015-reading scan-h00015
   obj-h00017-reading scan-h00017
   obj-h00018-reading scan-h00018
   obj-h00019-reading scan-h00019
   obj-h00020-reading scan-h00020
   obj-h00021-reading scan-h00021
   obj-h00023-reading scan-h00023
   obj-h00024-reading scan-h00024
   obj-h00025-reading scan-h00025
   obj-h00026-reading scan-h00026
   obj-h00027-reading scan-h00027
   obj-h00028-reading scan-h00028
   obj-h00029-reading scan-h00029
   obj-h00030-reading scan-h00030
   obj-h00031-reading scan-h00031
   obj-h00032-reading scan-h00032
   obj-h00033-reading scan-h00033
   obj-h00035-reading scan-h00035
   obj-h00037-reading scan-h00037
   obj-h00038-reading scan-h00038
   obj-h21-expr $val / 10
   obj-h21-reading Frequenz
   obj-h21-unpack n
   obj-h22-expr $val / 10
   obj-h22-reading UmrichterTemperatur
   obj-h22-unpack n
   obj-h6-expr $val / 10
   obj-h6-reading Verzoegerungszeit
   obj-h6-unpack n

Könnt Ihr mir helfen den FU vollständig zu integrieren?

[hugomckinley]

Hallo Lolo,
ich kann dir zwar bei deinem eigentlichen Problem nicht helfen, aber bezüglich CRC Fehler des 1wire-Buses, hatte ich das "selbe" Problem.
Ich trau mich das als "Fachperson" fast nicht sagen, aber ich habe aus Faulheit versucht, den 1wire-Bus und den RS485-Bus auf dem selben CAT5 Kabel zu betreiben. Hat ja genug Adern
Ergbnis war, dass ich mich irrsinnig gefreut habe, dass der RS485 Bus auf Anhieb funktioniert hat, aber ich bin dann später draufgekommen, dass ich auch diese CRC Fehler habe.
Nachdem ich für den RS485 ein eigenes Kabel gezogen habe, waren die CRC-Fehler wieder weg. Ich konnte definitv nicht damit leben, denn mein 1wire-Bus hat nur mehr sporadisch funktioniert. (Obwohl auf dem RS485 eigentlich nichts los war, aber das habe ich dann nicht hinterfragt)
Ich nehme an, dass du deine Busse in getrennten Kabeln hast, aber ich bin mir ziemlich sicher, dass es auch an den Störungen eines der zusätzlichen Systemen (FU oder Bus) liegt.

Gruß,
Hugo

[StefanStrobel]

Hallo,

die Meldungen von modbusRTU deuten darauf hin, dass ein anderer Modbus-Master auf dem gleichen Kabel aktiv ist.
Das geht bei Modbus nicht. Es darf nur einen Master geben.

Um dem FU Befehle schicken zu können, brauchst Du die Registerbelegung des FU. Da wird es eines für die Frequenz bzw. für an / aus geben.

Gruss
   Stefan

[der-Lolo]

Danke hugomckinley, Danke Stefan....
Am Sonntag habe ich den FU wieder abgeklemmt - es gab ein paar Seiteneffekte die offensichtlich vom FU verursacht wurden.
Da die Pumpe eh nicht "überdimensioniert" ist und somit wahrscheinlich meistens mit 50Hz laufen müsste, wir noch dazu kurz davor sind eine Solaranlage aufzubauen glaube ich das es besser ist auf den FU zu verzichten.

Schade, es hätte mir gefallen die Pumpe mit dem FU passend zur Spreizung der Durchlauf Solar-Warm-Wasser anlage zu regeln...

Aktuell kann ich den Fu wahrscheinlich sogar Gewinn bringend weiter verkaufen, es ist unglaublich was auf dem Markt bei solchem Material los ist.

[FhemPiUser]

Hi,
ich habe eine Frage zum Modul ModbusAttr, welches ich zum Abfragen meines Sungrow Wechselrichters verwende:

Gibt es eine Obergrenze zu der Anzahl von Readings? Es werden offenbar nicht alle Register abgefragt, die ich konfiguriert habe und ich frage mich, woran das liegt bzw. ob das an einer Obergrenze liegt.

Ich habe ca. 250 Readings / Abfragen für Input Register / Holding Register mit Modbus TCP konfiguriert.
Das Intervall ist 30s. Von den 250 Readings sind 20 ohne polldelay, also mit Intervall 30s.
30 Readings sind mit poll-delay / Intervall 5min, 190 mit Intervall 8 Stunden definiert.

Beispiel:

Code Auswählen Erweitern


defmod SH10rt_1 ModbusAttr 1 30 192.168.x.x:502 TCP
attr SH10rt_1 closeAfterResponse 0
attr SH10rt_1 dev-type-S16-len 1
attr SH10rt_1 dev-type-S16-unpack s>
attr SH10rt_1 dev-type-S32-len 2
attr SH10rt_1 dev-type-S32-revRegs 1
attr SH10rt_1 dev-type-S32-unpack l>
attr SH10rt_1 dev-type-SL_R2-len 2
attr SH10rt_1 dev-type-SL_R2-unpack l
attr SH10rt_1 dev-type-U16-len 1
attr SH10rt_1 dev-type-U16-unpack N
attr SH10rt_1 dev-type-U32-len 2
attr SH10rt_1 dev-type-U32-revRegs 1
attr SH10rt_1 dev-type-U32-unpack Na
attr SH10rt_1 dev-type-UL_R2-len 2
attr SH10rt_1 dev-type-UL_R2-revRegs 1
attr SH10rt_1 dev-type-UL_R2-unpack N
attr SH10rt_1 disable 0
attr SH10rt_1 event-on-change-reading .*
attr SH10rt_1 icon solar_icon
attr SH10rt_1 obj-i12999-poll 1
attr SH10rt_1 obj-i12999-reading 98_System_State
attr SH10rt_1 obj-i13000-poll 1
attr SH10rt_1 obj-i13000-reading 99_Running_State
attr SH10rt_1 obj-i13001-expr $val/10
attr SH10rt_1 obj-i13001-poll 1
attr SH10rt_1 obj-i13001-polldelay x10
attr SH10rt_1 obj-i13001-reading Daily_PV_Generation
attr SH10rt_1 obj-i13002-expr $val/10
...
attr SH10rt_1 obj-i6640-type U32
attr SH10rt_1 obj-i6642-expr $val/10
attr SH10rt_1 obj-i6642-polldelay x1000
attr SH10rt_1 obj-i6642-reading Yearly_Export_Energy_PV_18
attr SH10rt_1 obj-i6642-type U32
attr SH10rt_1 obj-i6644-expr $val/10
attr SH10rt_1 obj-i6644-polldelay x1000
attr SH10rt_1 obj-i6644-reading Yearly_Export_Energy_PV_19
attr SH10rt_1 obj-i6644-type U32
attr SH10rt_1 obj-i6646-expr $val/10
attr SH10rt_1 obj-i6646-polldelay x1000
attr SH10rt_1 obj-i6646-reading Yearly_Export_Energy_PV_20
attr SH10rt_1 obj-i6646-type U32


[StefanStrobel]

Hallo FhemPiUser,

eigentlich gibt es keine Obergrenze.
Setz doch mal Verbose auf 5 und poste einen langen Auszug aus dem Log.
Da müsste man sehen was passiert.

Gruss
   Stefan

[FhemPiUser]

Habe auf verbose 5 gesetzt und "tail -f ... | grep "i63" gemacht und die einzige Meldung die z.B. von Register i63xx bekomme ist immer wieder Folgende:

Code Auswählen Erweitern


SH10rt_1: CreateUpdateList full object list: i12999 i13000 i13001 i13002 i13004 i13005 i13007 i13008 i13009 i13010 i13011 i13012 i13016 i13017 i13019 i13020 i13021 i13022 i13023 i13024 i13025 i13026 i13028 i13029 i13033 i13035 i13036 i13039 i13040 i13044 i13045 i13049 i13051 i13053 i13055 i13057 i13059 i13061 i13063 i13065 i13067 i13069 i13071 i13073 i13075 i13077 i5002 i5003 i5007 i5010 i5011 i5012 i5013 i5016 i5035 i6196 i6197 i6198 i6199 i6200 i6201 i6202 i6203 i6204 i6205 i6206 i6207 i6208 i6209 i6210 i6211 i6212 i6213 i6214 i6215 i6216 i6217 i6218 i6219 i6220 i6221 i6222 i6223 i6224 i6225 i6226 i6250 i6252 i6254 i6256 i6258 i6260 i6262 i6264 i6266 i6268 i6270 i6272 i6274 i6276 i6278 i6280 i6282 i6284 i6286 i6288 i6386 i6387 i6388 i6389 i6390 i6391 i6392 i6393 i6394 i6395 i6396 i6397 i6398 i6399 i6400 i6401 i6402 i6403 i6404 i6405 i6406 i6407 i6408 i6409 i6410 i6411 i6412 i6413 i6414 i6415 i6416 i6417 i6418 i6419 i6420 i6421 i6422 i6423 i6424 i6425 i6426 i6427 i6429 i6430 i6431 i6432 i6433 i6434 i6435 i6436 i6437 i6438 i6439 i6440 i6441 i6442 i6443 i6444 i6445 i6446 i6447 i6448 i6449 i6451 i6453 i6455 i6457 i6459 i6461 i6463 i6465 i6467 i6468 i6469 i6565 i6566 i6567 i6568 i6569 i6570 i6571 i6572 i6573 i6574 i6575 i6576 i6577 i6578 i6579 i6580 i6581 i6582 i6583 i6584 i6585 i6586 i6587 i6588 i6589 i6590 i6591 i6592 i6593 i6594 i6595 i6596 i6597 i6598 i6599 i6600 i6601 i6602 i6603 i6604 i6605 i6606 i6608 i6610 i6612 i6614 i6616 i6618 i6620 i6622 i6624 i6626 i6627 i6628 i6629 i6630 i6631 i6632 i6633 i6634 i6635 i6636 i6637 i6638 i6640 i6642 i6644 i6646


Er liest einfach nur bestimmte Register, das sieht dann z.B. für i13022 so aus:

Code Auswählen Erweitern


2022.05.22 19:30:13.680 5: SH10rt_1: ProcessRequestQueue called from Fhem internal timer as queue:SH10rt_1, qlen 1, request: request: id 1, read fc 4 i13022, len 1, tid 172, master device SH10rt_1, reading Battery_Level (getUpdate for Battery_Level len 1), queued 2.04 secs ago
2022.05.22 19:30:13.680 5: SH10rt_1: checkDelays sendDelay, last send to same device was 0.021 secs ago, required delay is 0.1
2022.05.22 19:30:13.680 5: SH10rt_1: checkDelays commDelay, last communication with same device was 0.012 secs ago, required delay is 0.1
2022.05.22 19:30:13.680 5: SH10rt_1: checkDelays clientSwitchDelay is not relevant
2022.05.22 19:30:13.681 5: SH10rt_1: checkDelays busDelayRead, last activity on bus was 0.012 secs ago, required delay is 0
2022.05.22 19:30:13.681 4: SH10rt_1: checkDelays found commDelay not over, set timer to try again in 0.088
2022.05.22 19:30:13.774 5: SH10rt_1: ProcessRequestQueue called from Fhem internal timer as queue:SH10rt_1, qlen 1, request: request: id 1, read fc 4 i13022, len 1, tid 172, master device SH10rt_1, reading Battery_Level (getUpdate for Battery_Level len 1), queued 2.13 secs ago
2022.05.22 19:30:13.775 5: SH10rt_1: checkDelays clientSwitchDelay is not relevant
2022.05.22 19:30:13.775 5: SH10rt_1: checkDelays busDelayRead, last activity on bus was 0.106 secs ago, required delay is 0
2022.05.22 19:30:13.775 5: SH10rt_1: checkDelays commDelay, last communication with same device was 0.106 secs ago, required delay is 0.1
2022.05.22 19:30:13.775 5: SH10rt_1: checkDelays sendDelay, last send to same device was 0.116 secs ago, required delay is 0.1
2022.05.22 19:30:13.776 4: SH10rt_1: ProcessRequestQueue (V4.4.02 - 31.3.2021) qlen 1, sending 00ac00000006010432de0001 via 192.168.3.160:502, read buffer empty,
request: id 1, read fc 4 i13022, len 1, tid 172, master device SH10rt_1, reading Battery_Level (getUpdate for Battery_Level len 1), queued 2.13 secs ago
2022.05.22 19:30:13.776 5: SH10rt_1: Send called from ProcessRequestQueue
2022.05.22 19:30:13.776 5: DevIo_SimpleWrite SH10rt_1: 00ac00000006010432de0001
2022.05.22 19:30:13.781 5: SH10rt_1: readFn buffer: 00ac0000000501040203e8
2022.05.22 19:30:13.781 5: SH10rt_1: ParseFrameStart called from ReadFn protocol TCP expecting id 1
2022.05.22 19:30:13.781 4: SH10rt_1: ParseFrameStart (TCP, master) extracted id 1, fCode 4, tid 172, dlen 5 and potential data 0203e8
2022.05.22 19:30:13.782 5: SH10rt_1: HandleResponse called from ReadFn
2022.05.22 19:30:13.782 5: SH10rt_1: ParseResponse called from HandleResponse
2022.05.22 19:30:13.783 5: SH10rt_1: now parsing response data objects, master is SH10rt_1 relay is undefined
2022.05.22 19:30:13.783 5: SH10rt_1: ParseDataString called from HandleResponse with data hex 03e8, type i, adr 13022, op read
2022.05.22 19:30:13.783 5: SH10rt_1: SplitDataString called from ParseDataString with data hex 03e8, type i, adr 13022, valuesLen 1, op read
2022.05.22 19:30:13.784 5: SH10rt_1: CreateDataObjects called from ParseDataString with objList i13022
2022.05.22 19:30:13.785 5: SH10rt_1: CreateDataObjects sortedList i13022
2022.05.22 19:30:13.785 5: SH10rt_1: CreateDataObjects unpacked 03e8 with n to 1000
2022.05.22 19:30:13.787 5: SH10rt_1: perl expression eval evaluated package main; my @val = @{$oRef->{'%val'}};$val/10 to 100
2022.05.22 19:30:13.788 4: SH10rt_1: CreateDataObjects assigns value 100 to Battery_Level
2022.05.22 19:30:13.789 5: SH10rt_1: ParseDataString created 1 readings
2022.05.22 19:30:13.789 4: SH10rt_1: HandleResponse done, current frame / read buffer: 00ac0000000501040203e8, id 1, fCode 4, tid 172,
request: id 1, read fc 4 i13022, len 1, tid 172, master device SH10rt_1, reading Battery_Level (getUpdate for Battery_Level len 1), queued 2.14 secs ago, sent 0.02 secs ago,
response: id 1, fc 4, i13022, len 1, values 03e8
2022.05.22 19:30:13.790 5: SH10rt_1: ResetExpect for HandleResponse from response to idle
2022.05.22 19:30:13.794 5: SH10rt_1: DropFrame called from ReadFn - drop 00ac0000000501040203e8


Für andere Register wie z.B. i6389 kommt garnichts außer das "CreateUpdateList full object list" von oben.

Meine Config für das Register i6389 sieht wie folgt aus:

Code Auswählen Erweitern


attr SH10rt_1 obj-i6389-expr $val/10
attr SH10rt_1 obj-i6389-polldelay x2
attr SH10rt_1 obj-i6389-reading Daily_Direct_Energy_Consumption_PV_4


Jemand eine Idee, woran das liegen kann?

Ich kann auch die ganze Config mal posten, aber die ist mit 250 Registern ziemlich lang...