Wago /SPS über Modbus(TCP/IP) in FHEM steuern

[ChrisD]

Hallo,

Das ist die Meldung, allerdings nicht ganz so wie ich es mir vorgestellt hatte.

Die Id des erhaltenen Datenpaketes (3) passt nicht zu dem angefragten (8 ), weiterhin passt die Länge im Header (5) nicht zu der wirklichen Länge der Nutzdaten (27).

Ich habe eine neue Version erstellt welche keine Perl-Warnung mehr ausgibt und versucht das komplette Paket auszugeben. Kannst du damit testen ?

Was den Startzeitpunkt von updateInterval betrifft könnte ich ein Attribut hinzufügen (z.B. alignUpdateInterval).

Grüße,

ChrisD

[ChrisD]

Hallo,

Ich habe ein Attribut alignUpdateInterval in der Version 0012 hinzugefügt. Damit lässt sich der Startzeitpunkt im Format hh:mm[:ss] angeben ab dem updateInterval startet. Bei updateInterval ist es jetzt auch möglich die Zeiten im Format hh:mm[:ss] anzugeben. Zusätzlich wird 36_ModbusTCPServer in der Version 0009 benötigt.

Um einen Wert zur vollen Stunde auslesen kann man

Code Auswählen Erweitern

attr myRegister updateInterval 01:00
attr myRegister alignUpdateInterval 00:00verwenden, für tägliches Lesen

Code Auswählen Erweitern

attr myRegister updateInterval 24:00
attr myRegister alignUpdateInterval 00:00

Im Moment ist die Funktion nur für Register per ModbusTCP aktiv, wenn es funktioniert werde ich es auf die anderen Module übertragen.

Grüße,

ChrisD

[oniT]

Hallo ChrisD,

Um einen Wert zur vollen Stunde auslesen kann man

Code Auswählen Erweitern

attr myRegister updateInterval 01:00
attr myRegister alignUpdateInterval 00:00verwenden, für tägliches Lesen

Code Auswählen Erweitern

attr myRegister updateInterval 24:00
attr myRegister alignUpdateInterval 00:00

ok werde ich testen.

Ich habe eine neue Version erstellt welche keine Perl-Warnung mehr ausgibt und versucht das komplette Paket auszugeben. Kannst du damit testen ?

Jetzt kommt folgende Meldung

Code Auswählen Erweitern


2015.02.23 19:09:53 1: PERL WARNING: Argument "ModbusTCPServer: bad frame: 3512 - 3516, 0, 7 - 24" isn't numeric in subtraction (-) at ./FHEM/36_ModbusTCPServer.pm line 253.
2015.02.23 19:09:53 1: -6
2015.02.23 19:09:53 1: PERL WARNING: Argument "ModbusTCPServer: bad frame: 1 - 104, 0, 5 - 11" isn't numeric in subtraction (-) at ./FHEM/36_ModbusTCPServer.pm line 253.
2015.02.23 19:09:53 1: -6
2015.02.23 19:09:53 1: PERL WARNING: Argument "ModbusTCPServer: bad frame: 75 - 1, 0, 5 - 11" isn't numeric in subtraction (-) at ./FHEM/36_ModbusTCPServer.pm line 253.
2015.02.23 19:09:53 1: -6


Obwohl, diese sieht ja noch genauso aus. Hätte ich fhem nach dem Upload der ModbusTCPServer.pm auch hier wieder neustarten müssen? Ich werde es zur Vorsicht nochmals tun, es muss ja eh nach dem Upload der ModbusRegister.pm ein Neustart durchgeführt werden.

Danke

Gruß,
Tino

[ChrisD]

Hallo,

Wenn du die Datei ersetzt musst du entweder FHEM neu starten oder das Modul mit

Code Auswählen Erweitern

reload 36_ModbusTCPServerneu laden.

Grüße,

ChrisD

[oniT]

Hallo ChrisD,

hier ein Auszug der Meldungen aus dem Logfile

Code Auswählen Erweitern


2015.02.24 14:26:04 1: ModbusTCPServer: bad frame, sent: SimpleWrite [0D AE 00 00 00 06] 00 03 0D AE 00 01
2015.02.24 14:26:04 1: ModbusTCPServer: bad frame, received:  [0D AE 00 00 00 05] 00 03 02 02 85 0D AE 00 00 00 05 00 03 02 02 85
2015.02.24 14:26:03 1: ModbusTCPServer: bad frame, sent: SimpleWrite [00 69 00 00 00 06] 00 03 00 69 00 01
2015.02.24 14:26:03 1: ModbusTCPServer: bad frame, received:  [00 03 00 00 00 05] 00 03 02 01 2B
2015.02.24 14:26:03 1: ModbusTCPServer: bad frame, sent: SimpleWrite [00 03 00 00 00 06] 00 03 00 03 00 01
2015.02.24 14:26:03 1: ModbusTCPServer: bad frame, received:  [00 18 00 00 00 05] 00 03 02 00 6E
2015.02.24 14:26:03 1: ModbusTCPServer: bad frame, sent: SimpleWrite [00 18 00 00 00 06] 00 03 00 18 00 01
2015.02.24 14:26:03 1: ModbusTCPServer: bad frame, received:  [00 68 00 00 00 05] 00 03 02 00 00


Ich hoffe diese helfen weiter.


Der Test mit alignUpdateInterval läuft bei dieser Einstellung erfolgreich:

Code Auswählen Erweitern


Internals:
   CHANGED
   DEF        0 72
   HeatPumpServer_MSGCNT 25
   HeatPumpServer_TIME 2015-02-24 21:01:00
   IODev      HeatPumpServer
   LASTInputDev HeatPumpServer
   MSGCNT     25
   ModbusRegister_lastRcv 2015-02-24 21:01:00
   NAME       dim_compressor_history
   NR         68
   NTFY_ORDER 50-dim_compressor_history
   STATE      8199
   TYPE       ModbusRegister
   nextUpdate Tue Feb 24 22:01:00 2015
   Readings:
     2015-02-24 21:01:00   RAW             2007
     2015-02-24 21:01:00   state           8199
   Helper:
     addr       3 0 72
     address    72
     alignUpdateInterval 3660
     disableRegisterMapping 0
     nextUpdate 1424811660
     nread      1
     readCmd    H

     register   72
     registerType 3
     unitId     0
     updateIntervall 3600
     Cnv:
       a          1
       b          0
       max        32767
       min        -32768
       step       100
Attributes:
   IODev      HeatPumpServer
   alignUpdateInterval 01:01:00
   event-on-change-reading .*
   plcDataType INT
   registerType Holding
   room       Dimplex
   updateInterval 01:00:00


Jedoch mit u.a. hier nicht:

Code Auswählen Erweitern


Internals:
   CFGFN
   CHANGED
   DEF        0 3508
   IODev      SolarLogServer
   LASTInputDev SolarLogServer
   MSGCNT     1560
   ModbusRegister_lastRcv 2015-02-24 21:52:07
   NAME       solarlog_dailyyield_summary
   NR         248
   NTFY_ORDER 50-solarlog_dailyyield_summary
   STATE      3.47
   SolarLogServer_MSGCNT 1560
   SolarLogServer_TIME 2015-02-24 21:52:07
   TYPE       ModbusRegister
   nextUpdate Tue Feb 24 21:55:00 2015
   Readings:
     2015-02-24 21:52:07   RAW             0d8c0000
     2015-02-24 21:52:07   state           3.468
   Helper:
     addr       3 0 3508
     address    3508
     alignUpdateInterval 600
     disableRegisterMapping 0
     nextUpdate 1424811300
     nread      2
     readCmd    
�
     register   3508
     registerType 3
     unitId     0
     updateIntervall 300
     Cnv:
       a          0.001
       b          0
       max        4294967.295
       min        0
       step       10000
Attributes:
   IODev      SolarLogServer
   alignUpdateInterval 00:10:00
   conversion 0.001:0
   event-on-change-reading .*
   plcDataType DWORD
   updateInterval 00:05:00


Kannst Du erkennen an was das liegt?

Danke

Gruß,
Tino

[ChrisD]

Hallo,

Im Auszug vom Log scheinen die Anfragen und Rückmeldungen teilweise durcheinander. Kannst du die Zeiten im Log mit

Code Auswählen Erweitern

attr global mseclog 1 in ms ausgeben lassen ?

alignUpdateInterval legt den 'Startzeitpunkt' fest ab dem etwas passiert. In deinem 1. Beispiel wird zum 1. Mal um 01:01:00 gelesen, danach um 02:01:00, 03:01:00, 04:01:00 ... (um 00:01:00 wird übrigens nichts gelesen)

Bei deinem 2. Beispiel steht alignUpdateInterval  auf 10 min und updateInterval auf 5 min. Das führt dazu dass das Lesen alle 5 Minuten ausgehend von 00:10 stattfindet (also um 00:10, 00:15, 00:20, ...).

Zu welchen Zeitpunkten hast du das Lesen mit den verwendeten Parametern erwartet ?

Grüße,

ChrisD

[oniT]

Hallo ChrisD,

also meines erachtens nach erfolgt das Intervall nicht alle 5 Minuten. Der Unterschied ist hier zu erkennen. Es sind alle Zeiten gleich.

Code Auswählen Erweitern


   HeatPumpServer_TIME 2015-02-24 21:01:00
   IODev      HeatPumpServer
   ModbusRegister_lastRcv 2015-02-24 21:01:00
  nextUpdate 2015-02-24 21:01:00

Bei diesem steht die Zeit richtig.

Hier jedoch sind die Zeiten zum nextUpdate nicht gleich.

Code Auswählen Erweitern


   IODev      SolarLogServer
   ModbusRegister_lastRcv 2015-02-24 21:52:07
   SolarLogServer_TIME 2015-02-24 21:52:07
   nextUpdate Tue Feb 24 21:55:00 2015

Auch ist dies zu erkennen am TimeStamp vom Reading. Dieses hat im ersten Fall immer nach dem Update die letzte Update Zeit. Bei zweiterem Beispiel nimmt das Reading immer die Server_TIME bzw. die lastRcv Zeit an. Ok, diese beiden Zeiten sind ja immer gleich.

Ok, ich habe eben das Problem eingrenzen können. Sobald ein plcDataType angegeben ist, wird das alignUpdateInterval ignoriert.

Gruß,
Tino

[oniT]

Hallo ChrisD,

hier ein Auschnitt aus dem erweiterten Logauszug. Ich hoffe diese Daten helfen weiter.

Code Auswählen Erweitern


2015.02.25 19:10:26.189 1: ModbusTCPServer: bad frame, sent: SimpleWrite [00 7D 00 00 00 06] 00 03 00 7D 00 01
2015.02.25 19:10:26.190 1: ModbusTCPServer: bad frame, received:  [00 79 00 00 00 05] 00 03 02 00 A9 00 7D 00 00 00 05 00 03 02 06 24
2015.02.25 20:04:06.912 1: ModbusTCPServer: bad frame, sent: SimpleWrite [00 18 00 00 00 06] 00 03 00 18 00 01
2015.02.25 20:04:06.913 1: ModbusTCPServer: bad frame, received:  [00 68 00 00 00 05] 00 03 02 00 00 00 18 00 00 00 05 00 03 02 00 41
2015.02.25 20:12:25.203 1: ModbusTCPServer: bad frame, sent: SimpleWrite [0D AE 00 00 00 06] 00 03 0D AE 00 01
2015.02.25 20:12:25.205 1: ModbusTCPServer: bad frame, received:  [0D AE 00 00 00 05] 00 03 02 00 00 0D AE 00 00 00 05 00 03 02 00 00


Danke

Gruß,
Tino

[ChrisD]

Hallo,

Kannst du die neuen Version von ModbusTCPServer und ModbusRegister testen? Ich habe alignUpdateInterval überarbeitet.

Das Problem mit den bad frames ist noch nicht behoben, mit deinen Daten weiß ich aber wo ich suchen muss.

Grüße,

ChrisD

[Dieter1]

Hallo ChrisD,

ich frage jede Minute 6 Werte über den Modbus ab. Alles funktioniert prima, nur ca. 1mal am Tag verschluckt sich die Queue. Heute ist es um 7:20 passiert.
Wenn das Problem auftritt wird der erste Messwert "verschluckt" und die folgenden dann immer falsch zugeordnet. Denn Effekt kann man gut in den Bildern sehen.
Ich habe in den Logs immer einen funktionierenden Messvorgang vorher und hinterher mit drin. Das erste Log zeigt das Ergebnis, im Anhang hängt ein kommentierter Modbus Log mit Loglevel 5.
Auffallend bei beim Auftreten des Problems ein Delay von 3-4s, sieht für mich wie ein Timeoutproblem aus. Der könnte auch von meinem Strommesser SDM630 kommen, dann sollte das Modul den Messwert aber komplett verwerfen.

Code Auswählen Erweitern


2015-02-26_07:18:25 EVU_IS_E kWh: 268.695
2015-02-26_07:18:25 EVU_P1_P W: 12
2015-02-26_07:18:25 EVU_P2_P W: 143
2015-02-26_07:18:25 EVU_P3_P W: 8
2015-02-26_07:18:25 EVU_PS_P W: 164
2015-02-26_07:19:25 EVU_IS_E kWh: 268.698
2015-02-26_07:19:25 EVU_P1_P W: 7
2015-02-26_07:19:25 EVU_P2_P W: 142
2015-02-26_07:19:25 EVU_PS_P W: 158
2015-02-26_07:20:28 EVU_IS_E kWh: 304.683     # 3 sec zu spät, Wert ist von ES_E, wird aber IS zugewiesen
2015-02-26_07:20:28 EVU_P1_P W: 268           # jetzt alle Werte verschoben. das ist jetzt der IS_E Messwert
2015-02-26_07:20:28 EVU_P2_P W: 15            # usw. das ist also der Messwert von P1
2015-02-26_07:20:28 EVU_P3_P W: 99            #
2015-02-26_07:20:28 EVU_PS_P W: 7             #
2015-02-26_07:21:25 EVU_IS_E kWh: 268.703     # nächster Messzyklus, wieder alles ok
2015-02-26_07:21:25 EVU_P1_P W: 15
2015-02-26_07:21:25 EVU_P2_P W: 148
2015-02-26_07:21:25 EVU_P3_P W: 8
2015-02-26_07:21:25 EVU_PS_P W: 169
2015-02-26_07:22:25 EVU_IS_E kWh: 268.706


Hast du eine Idee?
Hinweis: Ich verwende deine Modbus Module mit Stand 17.02.

Dieter

[ChrisD]

Hallo,

Der Timeout von ModbusRTU steht normalerweise bei 3s was zu deinem Log passt. Wenn es zum Timeout kommt schickt das Modul die nächste Anfrage. Bei Modbus RTU gibt es im Gegensatz zu Modbus TCP keine Möglichkeit eine Id mitzuschicken anhand derer das Antwortpaket eindeutig zuzuordnen wäre. Das Modul geht daher davon aus dass das empfangene Paket zur letzten Anfrage gehört.

Du kannst versuchen den Wert vom Timeout höher zu setzen:

Code Auswählen Erweitern

attr EVU_Meter timeout 6

Wenn dies nicht weiterhilft kann ich das Modul so ändern dass die Queue bei einem Fehler komplett gelöscht wird.

Grüße,

ChrisD

[Dieter1]

Hallo Chris,
habe den timeout auf 6 erhöht. Seither (30h) ist das Problem nicht mehr aufgetreten. Sieht gut aus, werde es die nächsten Tage weiter beobachten.
Danke für den Tip

Dieter

[oniT]

Hallo ChrisD,

Kannst du die neuen Version von ModbusTCPServer und ModbusRegister testen? Ich habe alignUpdateInterval überarbeitet.

Habe es getestet und bisher läuft das alignUpdateInterval nun ohne Probleme.

Kurzer Hinweis noch, im Dorpdownfeld der Attribute steht noch zusätzlich die Auswahl "UpdateIntervall", also mit den beiden "ll". Ist nicht schlimm, nur als Hinweis zu verstehen.

Eine weitere Frage, wenn ich einen Digitalwert schreiben möchte, steht im Logfile diese Meldung.

Code Auswählen Erweitern


2015.03.02 22:25:57.457 3: HeatPumpServer: Unknown code ModbusCoil:0:102:5:1:65280, help me!


Schreibe ich eine 1 kommt diese Meldung. Ich weiß nur nicht wo die 65280 herkommen. Schreibe ich eine 0, kommt ebenfalls diese Meldung, jedoch tatsächlich mit einer 0.

Code Auswählen Erweitern


2015.03.02 22:35:51.811 3: HeatPumpServer: Unknown code ModbusCoil:0:102:5:1:0, help me!


Ein weiterer Test mit einem anderen Coil:

Code Auswählen Erweitern


2015.03.02 22:40:27.721 3: HeatPumpServer: Unknown code ModbusCoil:0:108:5:1:65280, help me!
2015.03.02 22:40:27.697 2: ModbusCoil_Parse: invalid address 1 0 108
2015.03.02 22:40:27.696 2: ModbusCoil_Parse: invalid address 1 0 108
2015.03.02 22:40:03.079 3: HeatPumpServer: Unknown code ModbusCoil:0:108:5:1:0, help me!
2015.03.02 22:40:03.034 2: ModbusCoil_Parse: invalid address 1 0 108
2015.03.02 22:40:03.031 2: ModbusCoil_Parse: invalid address 1 0 108


Steht diese Meldung im Logfile, der Wert wird allerdings übernommen.

Was mache ich da falsch?

Code Auswählen Erweitern


Internals:
   DEF        0 102
   HeatPumpServer_MSGCNT 72
   HeatPumpServer_TIME 2015-03-02 22:19:53
   IODev      HeatPumpServer
   LASTInputDev HeatPumpServer
   MSGCNT     72
   ModbusCoil_lastRcv 2015-03-02 22:19:53
   NAME       dim_modbus_coil_102
   NR         217
   NTFY_ORDER 50-dim_modbus_coil_102
   STATE      off
   TYPE       ModbusCoil
   Readings:
     2015-03-02 22:19:53   state           off
   Helper:
     addr       Coil 0 102
     address    102
     disableRegisterMapping 1
     nextUpdate 1425334950.77646
     nread      8
     readCmd    f
     register   102
     registerType Coil
     unitId     0
     updateIntervall 3600
Attributes:
   IODev      HeatPumpServer
   disableRegisterMapping 1
   group      Dimplex
   room       Administration
   source     Coil
   updateInterval 3600
   verbose    1


Danke

Gruß,
Tino

[ChrisD]

Hallo,

Die Meldungen im Log kommen durch einen Fehler im Modul 37_ModbusCoil den ich in der Version 0004 am 15.02. nach einem Hinweis von Dieter1 behoben habe. Kannst du 37_ModbusCoil auf die aktuelle Version 0005 aktualisieren ?

Wenn du FHEM nicht neu starten möchtest musst du nach einem reload das Attribut 'source' löschen und neu setzen damit die interne Adresse korrekt ist:

Code Auswählen Erweitern

deleteattr dim_modbus_coil_102 source
attr dim_modbus_coil_102 source Coil

Die Ausgabe von 'list' sollte danach so aussehen:

Helper:
     addr       1 0 102

Das Attribut updateIntervall ist noch im Modul enthalten da ansonsten beim Upgrade das Attribut nicht von der alten Version übernommen würde. Ich habe in den aktuellen Versionen aber Code hinzugefügt der nach dem Start von FHEM die alte Schreibweise aus der Auswahlliste entfernt. Dies funktioniert aber nicht bei einem reload der Module da dabei kein Event getriggert wird auf den ich reagieren könnte.

Grüße,

ChrisD

[oniT]

Hallo ChrisD,

spitze, funktioniert. Die Version hatte ich schon, aber nicht wie von Dir beschrieben den Code neu eingelesen.

Jetzt habe ich ein Register beschrieben und auch da kommt die Fehlermeldung:

Code Auswählen Erweitern


2015.03.04 21:45:01.421 3: HeatPumpServer: Unknown code ModbusRegister:0:5007:6:1:35, help me!


Auch hier wird allerdings der Wert in das Register geschrieben.

Code Auswählen Erweitern


Internals:
   DEF        0 5007
   HeatPumpServer_MSGCNT 219
   HeatPumpServer_TIME 2015-03-04 21:37:12
   IODev      HeatPumpServer
   LASTInputDev HeatPumpServer
   MSGCNT     219
   ModbusRegister_lastRcv 2015-03-04 21:37:12
   NAME       dim_modbus_register_min_5007
   NR         220
   NTFY_ORDER 50-dim_modbus_register_min_5007
   STATE      30
   TYPE       ModbusRegister
   lastUpdate Wed Mar  4 21:36:34 2015
   nextUpdate Wed Mar  4 22:37:11 2015
   Readings:
     2015-03-04 21:37:12   RAW             001e
     2015-03-04 21:37:12   state           30
   Helper:
     addr       3 0 5007
     address    5007
     disableRegisterMapping 0
     lastUpdate 0
     nextUpdate 1425505031.74428
     nread      1
     readCmd    �

     register   5007
     registerType 3
     unitId     0
     updateIntervall 3600
     Cnv:
       a          1
       b          0
       max        65535
       min        0
       step       100
Attributes:
   IODev      HeatPumpServer
   event-on-change-reading .*
   group      Dimplex
   registerType Input
   room       Administration
   updateInterval 3600


Kannst Du bitte auch hier einmal nachsehen ob ich da einen Fehler mache oder wo der Fehler liegt?

37_ModbusRegister.pm ist die Version 0013

Danke

Gruß,
Tino