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

[belu]

Hi ChrisD,

ich habe das mal gerade mit einer Real Zahl versucht, irgendwie bekomme ich da nichts angezeigt.

define wago ModbusTCPServer 192.168.178.23:502

define MR_MD100 ModbusRegister wago MD100
attr MR_MD100 stateAlias TemperaturHBK

define MR_MW601 ModbusRegister wago MW601
attr MR_MW601 stateAlias SollFrequenzKaltL

Mit dem Merkerword läuft es mit dem Merkerdoppelwort nicht.

Bekomme einfach ne 0 Angezeigt.

LG

[ChrisD]

Hallo,

Wie sieht die Definition der Variable in der SPS aus ?

Wenn du als Datentyp REAL verwendest musst du bei der Definition statt MD MF verwenden:

Code Auswählen Erweitern

define MR_MD100 ModbusRegister wago MF100

Grüße,

ChrisD

[belu]

Hi ChrisD,


In der Wago:

   ADAM8090 AT %MD100: REAL;      (*Temperatur HBK*)

Mit MF wird es auch nicht besser ich bekomme irgendwie keinen Wert gelesen, egal was

In FHEM:

define MR_MD100 ModbusRegister wago MF100
attr MR_MD100 stateAlias TemperaturHBK
attr MR_MD100 updateInterval 5


Parse verbose 5:

2016.01.28 15:05:46 5: AddRQueue [30 64 00 00 00 06] 00 03 30 64 00 02
2016.01.28 15:05:46 5: SimpleWrite [30 64 00 00 00 06] 00 03 30 64 00 02
2016.01.28 15:05:46 5: AddRQueue [32 59 00 00 00 06] 00 03 32 59 00 01
2016.01.28 15:05:46 5: adding to RQUEUE - 1
2016.01.28 15:05:46 5: ModbusTCPServer_Parse: received [30 64 00 00 00 07] 00 03 04 00 00 00 00
2016.01.28 15:05:46 5: wago dispatch ModbusRegister:0:12388:3:2:0:0
2016.01.28 15:05:46 5: ModbusRegister_Parse: 3 0 12388
2016.01.28 15:05:46 4: RQUEUE: 1
2016.01.28 15:05:46 5: SimpleWrite [32 59 00 00 00 06] 00 03 32 59 00 01
2016.01.28 15:05:46 5: ModbusTCPServer_Parse: received [32 59 00 00 00 05] 00 03 02 04 7E
2016.01.28 15:05:46 5: wago dispatch ModbusRegister:0:12889:3:1:1150
2016.01.28 15:05:46 5: ModbusRegister_Parse: 3 0 12889

Das letztere ist das MW601 da kommen Daten.


attr plcDataType REAL oder REAL_B bringt auch nix.

LG

[ChrisD]

Hallo,

Die Adressberechnung für MF und MD war falsch, kannst du die Module mit

Code Auswählen Erweitern

update force https://raw.githubusercontent.com/ChrisD70/FHEM-Modules/master/autoupdate/mb/controls_modbus.txt
aktualisieren, FHEM neu starten und erneut testen ?

Grüße,

ChrisD

[belu]

die Checksum stimmen nicht, irgendwie macht er nicht alles

UPD FHEM/36_ModbusRTU.pm
UPD FHEM/36_ModbusTCPServer.pm
Got 39338 bytes for FHEM/36_ModbusTCPServer.pm, expected 34814
aborting.

Habe es von hand geuppdatet per wget.

es läuft nun mit dem Real. Klasse und vielen Dank!!

LG

[belu]

Moin,

ich habe so bisschen Probleme mit dem aufkommenden Daten. Ich hab so knapp 50 Daten die kommen und die als Real gezählt werden.
Ich rufe aktuelle Jedes MF der Wago auf und schreib es mit einem einzelnen Timestamp in die Log. Das Problem ist aber bei 50 Werten habe ich auch 50 Timestamps zur gleichen Zeit. Hat einer ne Idee wie ich das zusammenfassen kann?

Aktuell sieht es so aus:

2016-01-29_13:03:58 MR_MD100 TempHBK: 691.208679199219
2016-01-29_13:03:58 MR_MD101 TempKanalVor: 574.456787109375
2016-01-29_13:03:58 MR_MD102 TempHinterTNV: 577.697021484375

Schöne wäre natürlich:

2016-01-29_13:03:58 MR_MD100 TempHBK: 691.208679199219, TempKanalVor: 574.456787109375, TempHinterTNV: 577.697021484375

Noch Besser und schöner wäre die Datenlast in der Log vorher gerundet zu haben:

2016-01-29_13:03:58 MR_MD100 TempHBK: 691.21, TempKanalVor: 574.46, TempHinterTNV: 577.70

Hab da schon was gelesen von stateFormat {sprintf("%.2f °C")} aber irgendwie will das nicht so.

Hat jemand ne idee?

Ich möchte die 2 Nachkommerstellen haben und wollte es nicht als INT übertragen und devidieren. Ihr seht ja die Temperaturen gehen von 0 bis 1200 Grad.

LG

[ChrisD]

Hallo,

Wenn du die Daten zusammenfassen möchtest könntest du so vorgehen:

- Nachkommastellen auf 2 festlegen:

Code Auswählen Erweitern

attr MR_MD100 stateFormat {sprintf("%.2f",ReadingsVal($name,"state",0))}
attr MR_MD101 stateFormat {sprintf("%.2f",ReadingsVal($name,"state",0))}
attr MR_MD102 stateFormat {sprintf("%.2f",ReadingsVal($name,"state",0))}

- Dummy anlegen für die zusammengefassten Daten und verhindern dass automatisch bei Änderung geloggt wird:

Code Auswählen Erweitern

define MB_Log dummy
attr MB_Log event-on-change-reading x

- bei Änderung der Modbusdaten Dummy aktualisieren (als Beispiel nur für 3 Werte):

Code Auswählen Erweitern

define n_MB_Log MR_MD10.* {fhem "set MB_Log TempHBK: ".Value("MR_MD100")." TempKanalVor: ".Value("MR_MD101")." TempHinterTNV: ".Value("MR_MD102")}

- Filelog anlegen:

Code Auswählen Erweitern

define fl_MB FileLog ./log/FL_MB.log MB_Log.*

- regelmäßig ins Filelog schreiben:

Code Auswählen Erweitern

define a_MB_log at +*00:01:00 {fhem "trigger MB_Log ".Value("MB_Log")}

Das Komma hinter den Zahlen würde ich weglassen da es die Erstellung von Plots in FHEM unnötig erschwert.

Grüße,

ChrisD

[belu]

Guten Morgen Chris,

also das mit dem Stateformat hab ich verstanden, das läuft auch als Anzeigwert, das ändert aber nur im Geräte den "STATE", das lässt sich aber nicht so einfach loggen.

Ich hab es bisher mit einem userreading gelöst.

Code Auswählen Erweitern

attr MR_MD100 userReadings TempHBK { int ( 10 * ReadingsVal("MR_MD100","state",0) + 0.5 ) / 10 }

So hab ich ein Reading erzeugt das den Namen TempHBK hatte das ich mit Filelog verarbeiten kann.

Problem ist halt aber das ich immer einen Timestamp hab.

Zu der anderen Geschichte, Daten zusammenfassen.

Code Auswählen Erweitern

define n_MB_Log MR_MD10.* {fhem "set MB_Log TempHBK: ".Value("MR_MD100")." TempKanalVor: ".Value("MR_MD101")." TempHinterTNV: ".Value("MR_MD102")}

Das klappt leider nicht. Unknown module MR_MD10.*

Sonst hätte ich es mal getestet, habe auch keine Idee was es für ein Modul sein könnte.

LG

[belu]

Habe es,

es war ein

Code Auswählen Erweitern


define n_MB_Log notify MR_MD10.* {fhem "set MB_Log TempHBK: ".Value("MR_MD100")." TempKanalVor: ".Value("MR_MD101")." TempHinterTNV: ".Value("MR_MD102")}

danke, es läuft, mal schauen wie ich das noch etwas optmiere

[PEPITO82]

Ich benutze das Modul für das Auslesen bzw. Steuern meiner Waterkotte Wärmepumpe sowie um meinen Solar-Log Datenlogger auszulesen.
Das lief bis vor ca. 2 oder 3 Monaten absolut zuverlässig - ohne Logeinträge. Seit dieser Zeit habe ich immer mal wieder kurzzeitig solche Logeinträge:

Code Auswählen Erweitern

2016.02.28 20:09:46 1: ModbusTCPServer_Parse: bad frame, sent: SimpleWrite [00 1A 00 00 00 06] 00 03 00 1A 00 01
2016.02.28 20:09:46 1: ModbusTCPServer_Parse: bad frame, received:  [00 04 00 00 00 05] 00 03 02 00 B9
2016.02.28 20:09:54 1: ModbusTCPServer_Parse: bad frame, sent: SimpleWrite [00 34 00 00 00 06] 00 03 00 34 00 01
2016.02.28 20:09:54 1: ModbusTCPServer_Parse: bad frame, received:  [00 1C 00 00 00 05] 00 03 02 00 00
2016.02.28 20:09:54 1: 192.168.178.10:502 disconnected, waiting to reappear (myWaterkotte)
2016.02.28 20:09:56 1: 192.168.178.10:502 reappeared (myWaterkotte)
2016.02.28 20:10:08 1: ModbusTCPServer_Parse: bad frame, sent: SimpleWrite [00 06 00 00 00 06] 00 03 00 06 00 01
2016.02.28 20:10:08 1: ModbusTCPServer_Parse: bad frame, received:  [00 0E 00 00 00 05] 00 03 02 00 DF
2016.02.28 20:10:16 1: 192.168.178.10:502 disconnected, waiting to reappear (myWaterkotte)
2016.02.28 20:10:16 1: 192.168.178.10:502 reappeared (myWaterkotte)
2016.02.28 20:10:53 1: ModbusTCPServer_Parse: bad frame, sent: SimpleWrite [00 04 00 00 00 06] 00 03 00 04 00 01
2016.02.28 20:10:53 1: ModbusTCPServer_Parse: bad frame, received:  [00 13 00 00 00 05] 00 03 02 01 AE
2016.02.28 20:10:54 1: ModbusTCPServer_Parse: bad frame, sent: SimpleWrite [00 04 00 00 00 06] 00 03 00 04 00 01
2016.02.28 20:10:54 1: ModbusTCPServer_Parse: bad frame, received:  [00 0C 00 00 00 05] 00 03 02 01 0E 13 A8 00 00 00 05 00 03 02 00 00 00 19 00 00 00 05 00 03 02 00 00 00 25 00 00 00 05 00 03 02 01 C2 00 0F 00 00 00 05 00 03 02 00 91 00 08 00 00 00 05 00 03 02 00 85 00 04 00 00 00 05 00 03 02 00 BA
2016.02.28 20:11:22 1: ModbusTCPServer_Parse: bad frame, sent: SimpleWrite [00 3A 00 00 00 06] 00 03 00 3A 00 01
2016.02.28 20:11:22 1: ModbusTCPServer_Parse: bad frame, received:  [00 34 00 00 00 05] 00 03 02 00 00
2016.02.28 20:11:47 1: ModbusTCPServer_Parse: bad frame, sent: SimpleWrite [00 19 00 00 00 06] 00 03 00 19 00 01
2016.02.28 20:11:47 1: ModbusTCPServer_Parse: bad frame, received:  [00 0E 00 00 00 05] 00 03 02 00 DF
2016.02.28 20:11:48 1: ModbusTCPServer_Parse: bad frame, sent: SimpleWrite [00 19 00 00 00 06] 00 03 00 19 00 01
2016.02.28 20:11:48 1: ModbusTCPServer_Parse: bad frame, received:  [00 07 00 00 00 05] 00 03 02 01 0F 00 06 00 00 00 05 00 03 02 00 C6 00 13 00 00 00 05 00 03 02 01 AE 00 0C 00 00 00 05 00 03 02 01 0E 13 A8 00 00 00 05 00 03 02 00 00 00 19 00 00 00 05 00 03 02 00 00
2016.02.28 20:12:03 1: ModbusTCPServer_Parse: bad frame, sent: SimpleWrite [00 05 00 00 00 06] 00 03 00 05 00 01
2016.02.28 20:12:03 1: ModbusTCPServer_Parse: bad frame, received:  [00 08 00 00 00 05] 00 03 02 00 85
2016.02.28 20:12:07 1: ModbusTCPServer_Parse: bad frame, sent: SimpleWrite [00 1C 00 00 00 06] 00 03 00 1C 00 01
2016.02.28 20:12:07 1: ModbusTCPServer_Parse: bad frame, received:  [00 04 00 00 00 05] 00 03 02 00 BA 00 05 00 00 00 05 00 03 02 00 95
2016.02.28 20:12:18 1: ModbusTCPServer_Parse: bad frame, sent: SimpleWrite [13 A6 00 00 00 06] 00 03 13 A6 00 01
2016.02.28 20:12:18 1: ModbusTCPServer_Parse: bad frame, received:  [00 1A 00 00 00 05] 00 03 02 00 00
2016.02.28 20:12:18 1: ModbusTCPServer_Parse: bad frame, sent: SimpleWrite [00 3A 00 00 00 06] 00 03 00 3A 00 01
2016.02.28 20:12:18 1: ModbusTCPServer_Parse: bad frame, received:  [00 1C 00 00 00 05] 00 03 02 00 00 00 33 00 00 00 05 00 03 02 00 00 00 34 00 00 00 05 00 03 02 00 00 13 A6 00 00 00 05 00 03 02 00 00
2016.02.28 20:12:43 1: ModbusTCPServer_Parse: bad frame, sent: SimpleWrite [00 0E 00 00 00 06] 00 03 00 0E 00 01
2016.02.28 20:12:43 1: ModbusTCPServer_Parse: bad frame, received:  [00 0A 00 00 00 05] 00 03 02 01 C2
2016.02.28 20:12:44 1: ModbusTCPServer_Parse: bad frame, sent: SimpleWrite [00 07 00 00 00 06] 00 03 00 07 00 01
2016.02.28 20:12:44 1: ModbusTCPServer_Parse: bad frame, received:  [00 26 00 00 00 05] 00 03 02 01 C2
2016.02.28 20:12:44 1: 192.168.178.10:502 disconnected, waiting to reappear (myWaterkotte)
2016.02.28 20:12:44 1: 192.168.178.10:502 reappeared (myWaterkotte)
2016.02.28 20:12:52 1: ModbusTCPServer_Parse: bad frame, sent: SimpleWrite [13 A8 00 00 00 06] 00 03 13 A8 00 01
2016.02.28 20:12:52 1: ModbusTCPServer_Parse: bad frame, received:  [00 13 00 00 00 05] 00 03 02 01 AE
2016.02.28 20:12:54 1: 192.168.178.10:502 disconnected, waiting to reappear (myWaterkotte)
2016.02.28 20:16:04 1: 192.168.178.10:502 reappeared (myWaterkotte)

Das Problem erledigte sich bisher immer von alleine. Hat aber auch schon mal einige Stunden gedauert.
Woran kann das liegen? Gibt es hier eine Abhilfe?

Viele Grüße

Peter

[ChrisD]

Hallo,

Die Meldungen mit 'bad frame' kommen wahrscheinlich daher dass FHEM ein Anfrage schickt und diese innerhalb einer gewissen Zeit nicht beantwortet wird. FHEM schickt dann die nächste Anfrage und erhält die Antwort auf die vorherige Anfrage. Da die Anfragen 'nummeriert' sind passt die Antwort nicht zur aktuellen Anfrage und wird verworfen. Tino hatte vor einem Jahr schon ähnliche Probleme und ich dachte mit der aktuellen Version von ModbusTCPServer seien sie behoben.

Kannst du mit

Code Auswählen Erweitern

versionüberprüfen welche Version von ModbusTCPServer du verwendest ?

Du kannst versuchen mit

Code Auswählen Erweitern

attr myWaterkotte timeout 10den Timeout auf 10 s zu setzen (Default ist 3 s).

Die 'disconnected'-Eintrage entstehen wenn die TCP-Verbindung abbricht, das Modul hat keinen direkten Einfluss darauf und schließt die Verbindung auch nicht von sich aus. Es versucht aber in regelmäßigen Abständen sie wieder aufzubauen.

Grüße,

ChrisD

[PEPITO82]

Hallo ChrisD,

danke für Deine Antwort.
Vermutlich nutze ich noch eine ältere Version:

Code Auswählen Erweitern

version
spuckt Folgendes aus:

Code Auswählen Erweitern

# $Id: 36_ModbusTCPServer.pm 0015 $
# $Id: 37_ModbusRegister.pm 0016 $

Den Timeout habe ich nun auf 10s hochgesetzt.
Ich könnte mir mittlerweile vorstellen, dass die Aussetzer seitdem auftreten als ich an meinem Unipi-Board die analogen Eingänge mit zwei Luftgütesensoren verwende.
Hier kann ich in den Graphen auch immer mal wieder Aussetzer feststellen, in denen keine Werte geschrieben wurden.
An der Konfiguration des Moduls habe ich nämlich nichts verändert.

Nach:

Code Auswählen Erweitern

update force https://raw.githubusercontent.com/ChrisD70/FHEM-Modules/master/autoupdate/mb/controls_modbus.txt

sehen die Versionen nun so aus:

Code Auswählen Erweitern

# $Id: 36_ModbusTCPServer.pm 0018 $
# $Id: 37_ModbusRegister.pm 0020 $

Da die Aussetzer nicht regelmäßig vorkommen, werde ich das in der nächsten Zeit mal beobachten und mich nochmal melden.

Viele Grüße und Danke,

Peter

[PEPITO82]

Gestern kam es leider wieder zu Timeouts:

Code Auswählen Erweitern

2016.03.16 20:45:48 1: ModbusTCPServer_Parse: bad frame, sent: SimpleWrite [13 A6 00 00 00 06] 00 03 13 A6 00 01
2016.03.16 20:45:48 1: ModbusTCPServer_Parse: bad frame, received:  [00 33 00 00 00 05] 00 03 02 00 00
2016.03.16 20:46:10 1: 192.168.178.10:502 disconnected, waiting to reappear (myWaterkotte)
2016.03.16 20:48:20 1: 192.168.178.10:502 reappeared (myWaterkotte)
2016.03.16 20:49:58 1: ModbusTCPServer_Parse: bad frame, sent: SimpleWrite [00 0E 00 00 00 06] 00 03 00 0E 00 01
2016.03.16 20:49:58 1: ModbusTCPServer_Parse: bad frame, received:  [00 0A 00 00 00 05] 00 03 02 01 F4
2016.03.16 20:49:58 1: 192.168.178.10:502 disconnected, waiting to reappear (myWaterkotte)
2016.03.16 20:52:08 1: 192.168.178.10:502 reappeared (myWaterkotte)
2016.03.16 20:53:09 1: 192.168.178.10:502 disconnected, waiting to reappear (myWaterkotte)
2016.03.16 20:53:09 1: 192.168.178.10:502 reappeared (myWaterkotte)
2016.03.16 20:55:30 1: ModbusTCPServer_Parse: bad frame, sent: SimpleWrite [00 34 00 00 00 06] 00 03 00 34 00 01
2016.03.16 20:55:30 1: ModbusTCPServer_Parse: bad frame, received:  [00 08 00 00 00 05] 00 03 02 00 8B
2016.03.16 20:55:36 1: ModbusTCPServer_Parse: bad frame, sent: SimpleWrite [13 A6 00 00 00 06] 00 03 13 A6 00 01
2016.03.16 20:55:36 1: ModbusTCPServer_Parse: bad frame, received:  [00 04 00 00 00 05] 00 03 02 00 F3 00 05 00 00 00 05 00 03 02 00 87
2016.03.16 20:55:38 1: 192.168.178.10:502 disconnected, waiting to reappear (myWaterkotte)
2016.03.16 20:55:38 1: 192.168.178.10:502 reappeared (myWaterkotte)
2016.03.16 20:56:34 1: ModbusTCPServer_Parse: bad frame, sent: SimpleWrite [00 02 00 00 00 06] 00 03 00 02 00 01
2016.03.16 20:56:34 1: ModbusTCPServer_Parse: bad frame, received:  [00 0A 00 00 00 05] 00 03 02 01 F4
2016.03.16 20:57:44 1: 192.168.178.10:502 disconnected, waiting to reappear (myWaterkotte)
2016.03.16 20:57:45 1: 192.168.178.10:502 reappeared (myWaterkotte)
2016.03.16 21:01:28 1: ModbusTCPServer_Parse: bad frame, sent: SimpleWrite [00 13 00 00 00 06] 00 03 00 13 00 01
2016.03.16 21:01:28 1: ModbusTCPServer_Parse: bad frame, received:  [00 1C 00 00 00 05] 00 03 02 00 00
2016.03.16 21:02:23 1: 192.168.178.10:502 disconnected, waiting to reappear (myWaterkotte)
2016.03.16 21:03:26 1: 192.168.178.10:502 reappeared (myWaterkotte)

Davor passierte es zuletzt am 6.3. - also 10 Tage vorher.
Mit meinem Solar-Log passiert das nicht. Bei dem habe ich täglich nur Einträge im Log, da dieser sich täglich um 3h neustartet.

[UlliM]

Ich verwende auch eine Wago.  InputRegister lesen %IWn geht. Aber wenn ich ein Coil der Form %IXn.1 lesen will kommt immer eine 0.  An der Wago wir aber 1 angezeigt. Mit Coils %QXn.1 geht es. Nur IX Coils gehen nicht. Warum?


Gelöst: Wago rechnet komplexe Busklemmen nicht mit. Bitzugriff fängt immer bei IX0.0 an der ersten Digitalklemme an!

[ChrisD]

Hallo,

Wenn analoge Eingänge verwendet werden stimmt die Adressierung nicht mehr. In der aktuellen Version von 36_ModbusTCPServer (0019) habe ich dafür ein zusätzliches Attribut serverType hinzugefügt. Wenn dieses auf 'Wago' steht versucht das Modul die I/O-Konfiguration der SPS auszulesen und die Adressen automatisch anzupassen.

Die aktuelle Version kannst du mit

Code Auswählen Erweitern

update force https://raw.githubusercontent.com/ChrisD70/FHEM-Modules/master/autoupdate/mb/controls_modbus.txt
installieren.

Nach einem FHEM-Neustart kannst du, wenn dein Gerät WagoSPS heißt, das Attribut mit

Code Auswählen Erweitern

attr WagoSPS serverType Wago setzen und anschließend mit

Code Auswählen Erweitern

list WagoSPSüberprüfen ob die Konfiguration ausgelesen wurde.

Wenn es funktioniert sollte die Ausgabe so ähnlich aussehen:

WagoSPS:
       AI         12
       AO         10
       DI         8
       DIOffset   192
       DO         4
       DOOffset   160
       INFO_ITEM  880
       INFO_MAJOR 2
       INFO_MINOR 3
       INFO_REVISION 5
       INFO_SERIES 750
       initDone   1
       x          1

Danach sollten sich die DI (und DO) mit den gleichen Adressen wie in CoDeSys anlegen lassen.

Grüße,

ChrisD