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

Begonnen von lechez, 05 Mai 2013, 10:50:13

Vorheriges Thema - Nächstes Thema

qwikser

Hi Leute,

hab jetzt mein ganzes MAX! Heizungssystem via diesem Modul an meine SPS geleitet, funktioniert soweit super.
Bin jetzt mit einem Funk-Modul und ein paar ELRO Steckdosen am rumspielen, prinzipiell funktioniert es schon das ich von meiner SPS an die Steckdosen sende über fhem.
Hab das Auslesen der SPS aber als zyklischen Befehl, hätte es aber lieber als Notify, weiß aber nicht so recht wie ich das hin bekomme.  :(

Hier mal mein Befehl zur Zeit:

define Steckdose_A_wago_EIN dummy
attr Steckdose_A_wago_EIN room Funker-Sender
define at_read_Steckdose_A_wago_EIN at +*00:00:05 {fhem("set Steckdose_A_wago_EIN ".((read_modbus_coil(13088) eq "on")?"AKTIV":"INAKTIV"))}
define NSteckdose_A_wago_EIN notify Steckdose_A_wago_EIN { if ( Value("Steckdose_A_wago_EIN") eq "AKTIV" ) {system("sudo /home/pi/pilight/pilight-send -p elro_he -s 31 -u 1 -t");;} }


Wäre cool wenn mir einer mit dem Notiy auf die Sprünge helfen könnte.  ;D

MfG.
Daniel

ChrisD

Hallo,

Das zyklische Lesen der Daten kannst du bei der aktuellen Modbus-Implementierung nicht umgehen. FHEM muss als Client die Daten beim Server pollen da Modbus keine Möglichkeit vorsieht dass der Server von sich aus z.B. Ereignisse an den Client überträgt.

Eine Möglichkeit wäre auf der SPS zusätzlich einen Modbus-Client zu verwenden. Den gibt es als Bibliothek bei Wago (ModbusEthernet_04.lib) oder für verschiedene Steuerungen auf oscat.de. Für FHEM muss ein Modbus-Server-Modul geschrieben werden welches die von der SPS kommenden Daten z.B. in Dummys ablegt. Dies hätte den großen Vorteil dass das Pollen und die damit verbundene Zeitverzögerung entfällt. Nachteil ist der zusätzliche Aufwand im SPS-Programm und das (noch) nicht existierende Modul für FHEM.

Grüße,

ChrisD

Christian77

Hallo,

nach dem ich schon erfolgreich meine Luftwärmepumpe an einen Raspberry PI mit FHEM anschließen konnte möchte ich nun ebenfalls meine Wago 750-881 SPS mit FHEM über Modbus/TCP ansteuern bzw. Daten auslesen.

Gibt es hierzu schon einen Wiki-Artikel der dieses genauer beschreibt?

Ich habe versucht anhand dieses Threads schon einmal auszuprobieren, habe aber hierbei noch Probleme.
Die Module MBClient.pm, 36_ModbusRTU.pm, 36_ModbusTCPServer.pm, 37_ModbusRegister.pm, 99_modbus.pm habe ich in das FHEM Verzeichnis kopiert (gibt es die aktuellen Versionen auch üer FHEM Update bzw. auf Sourceforge?).

Anschließend habe ich in fhem.cfg die Wago und ein paar Testregister definiert (diese Register benutze ich bereits in einem anderen Setup mit der Wago und OpenHub):


define wago ModbusTCPServer 192.168.2.10
attr wago pollIntervall 0.1
define MBTest01 ModbusRegister 0 16288
define MBC01 ModbusRegister 0 16289
define MBTest02 ModbusRegister 0 16383


Das Log sagt mir, dass die Wago konnektiert wird. Allerdings werden bei Änderung die Register scheinbar in FHEM nicht richtig ausgelesen,  FHEM zeigt statisch "0" an.


2014.08.16 21:08:34 3: MBTest01: I/O device is wago
2014.08.16 21:08:34 3: MBC01: I/O device is wago
2014.08.16 21:08:34 3: MBTest02: I/O device is wago
2014.08.16 21:08:34 1: Including ./log/fhem.save
[...]
2014.08.16 21:08:36 3: Opening wago device 192.168.2.10:502
2014.08.16 21:08:36 3: wago device opened


Hat jemand eine Idee, wie ich das Problem lösen kann und hier weiter komme?

Vielen Dank,

Christian

ChrisD

Hallo,

Es gibt noch keinen Wiki-Artikel zur Modbus-Anbindung. Die aktuellen Versionen gibt es im Moment auch nur in diesem Thread verteilt auf diverse Artikel.

Mit der beschriebenen Konfiguration sollte das Lesen der Daten funktionieren. Kannst du überprüfen welche Version der Modbus-Bausteine du hast ? Wenn du in der FHEM-Kommandozeile
versioneingibst sollte da
Zitat# $Id: 37_ModbusRegister.pm 0006 $
# $Id: 36_ModbusTCPServer.pm 0004 $
stehen.

Wenn dies der Fall ist kannst du versuchen den Loglevel mitattr wago verbose 5zu erhöhen und schauen was in der FHEM-Logdatei steht. Dort sollten solche Einträge zu finden sein:
Zitat2014.08.17 18:07:35.324 5: SimpleWrite [3F A0 00 00 00 06] 00 03 3F A0 00 01
2014.08.17 18:07:35.325 5: Received [3F A0 00 00 00 05] 00 03 02 00 00
2014.08.17 18:07:35.325 5: wago dispatch ModbusRegister:0:16288:3:1:0
2014.08.17 18:07:35.325 5: ModbusRegister_Parse: 3 0 16288

Grüße,

ChrisD

Christian77

Hallo,

vielen Dank für den Tipp.


# $Id: 37_ModbusRegister.pm 0006 $
# $Id: 36_ModbusTCPServer.pm 0002 $


Da scheine ich wohl nicht die aktuelle Version 36_ModbusTCPServer erwischt zu haben.
Wo bekomme ich den diese?

Ich glaube ein Wiki Artikel mit den aktuellsten Versionen wäre hilfreich. Ich muss gestehen, das ich diesen Thread nicht sehr übersichtlich finde.

Vielen Dank,

Christian

ChrisD

Hallo,

Die aktuelle Version befindet sich in Beitrag 151.

Der Thread ist in der Tat unübersichtlich geworden, ich werde versuchen die aktuellen Versionen in einem Wiki-Artikel abzulegen.

Grüße,

ChrisD

Christian77

Zitat von: ChrisD am 17 August 2014, 18:11:47
Wenn dies der Fall ist kannst du versuchen den Loglevel mitattr wago verbose 5zu erhöhen und schauen was in der FHEM-Logdatei steht. Dort sollten solche Einträge zu finden sein:

2014.08.17 18:07:35.324 5: SimpleWrite [3F A0 00 00 00 06] 00 03 3F A0 00 01
2014.08.17 18:07:35.325 5: Received [3F A0 00 00 00 05] 00 03 02 00 00
2014.08.17 18:07:35.325 5: wago dispatch ModbusRegister:0:16288:3:1:0
2014.08.17 18:07:35.325 5: ModbusRegister_Parse: 3 0 16288



Das Modul habe ich nun durch das neuere ausgetauscht. Verbose 5 liefert:

2014.08.18 20:26:21 5: Received [3F FF 00 00 00 05] 00 03 02 00 00
2014.08.18 20:26:21 5: wago dispatch ModbusRegister:0:16383:3:1:0
2014.08.18 20:26:21 5: ModbusRegister_Parse: 3 0 16383
2014.08.18 20:26:21 4: RQUEUE: 1
2014.08.18 20:26:21 5: SimpleWrite [30 36 00 00 00 06] 00 03 30 36 00 01
2014.08.18 20:26:21 5: Received [30 36 00 00 00 05] 00 03 02 00 00
2014.08.18 20:26:21 5: wago dispatch ModbusRegister:0:12342:3:1:0
2014.08.18 20:26:21 5: ModbusRegister_Parse: 3 0 12342
2014.08.18 20:26:22 5: AddRQueue [3F A1 00 00 00 06] 00 03 3F A1 00 01
2014.08.18 20:26:22 5: SimpleWrite [3F A1 00 00 00 06] 00 03 3F A1 00 01
2014.08.18 20:26:22 5: AddRQueue [3F A0 00 00 00 06] 00 03 3F A0 00 01
2014.08.18 20:26:22 5: adding to RQUEUE - 1
2014.08.18 20:26:22 5: AddRQueue [3F FF 00 00 00 06] 00 03 3F FF 00 01
2014.08.18 20:26:22 5: adding to RQUEUE - 2
2014.08.18 20:26:22 5: AddRQueue [30 36 00 00 00 06] 00 03 30 36 00 01
2014.08.18 20:26:22 5: adding to RQUEUE - 3
2014.08.18 20:26:22 5: Received [3F A1 00 00 00 05] 00 03 02 00 00
2014.08.18 20:26:22 5: wago dispatch ModbusRegister:0:16289:3:1:0
2014.08.18 20:26:22 5: ModbusRegister_Parse: 3 0 16289
2014.08.18 20:26:22 4: RQUEUE: 3
2014.08.18 20:26:22 5: SimpleWrite [3F A0 00 00 00 06] 00 03 3F A0 00 01
2014.08.18 20:26:22 5: Received [3F A0 00 00 00 05] 00 03 02 00 00
2014.08.18 20:26:22 5: wago dispatch ModbusRegister:0:16288:3:1:0
2014.08.18 20:26:22 5: ModbusRegister_Parse: 3 0 16288
2014.08.18 20:26:22 4: RQUEUE: 2


Ist das gut?

Viele Grüße,

Christian

Christian77

Hallo,

mir kommt gerade noch eine Idee: Wie kann man die Modbus Slave ID einstellen?

Viele Grüße,

Christian

ChrisD

Hallo,

Die Daten sehen gut aus, die SPS liefert bei den 4 Adressen den Wert 0 zurück. Der Wert befindet sich in den letzten 2 Bytes in der Zeile
ZitatReceived [30 36 00 00 00 05] 00 03 02 00 00
im Big Endian-Format. Die Modbus-Adressen sollten den SPS-Speicheradressen %MW54, %MW4000, %MW4001 und %MW4095 entsprechen.

Die Slave-ID (resp. Unit-ID) wird auf FHEM-Seite in der Definition von Modbusregister festgelegt:
define <name> ModbusRegister <UnitID> <Register>

Bei Wago wird die UnitID nicht ausgewertet so dass sie auf 0 gesetzt werden kann, bei anderen Steuerungen muss der Wert an die SPS-Konfiguration angepasst werden.

Um zu testen ob überhaupt Daten (außer der 0) übertragen werden kannst du folgendes Register anlegen:
define MBTest1234 ModbusRegister 0 8194Wenn die Kommunikation funktioniert muss bei Wago-Steuerungen der Wert 4660 (hex 1234) gelesen werden. Alternativ kannst du auch Register 8210 auslesen lassen, dieses enthält den SPS-Typ (881 in deinem Fall).

Grüße,

ChrisD

Christian77

Hallo,

define MBTest1234 ModbusRegister 0 8194

liefert den Wert 4660, die Kommunikation scheint also zu funktionieren.

Zitat
Die Modbus-Adressen sollten den SPS-Speicheradressen %MW54, %MW4000, %MW4001 und %MW4095 entsprechen.

Vielleicht habe ich hier einen Denkfehler. Ich hatte mir seinerzeit eine Art Übersetzungstabelle gemacht, welcher Merker welche Adresse hat. Demnach sollten 16288 und 16289 die Merker MX250.0 und MX250.1 sein. Wenn ich mit einem anderen Modbus Monitoring Programm diese Register anschauen, so sehe ich auch die Änderungen unter diesen dezimalen Adressen.
Kann es sein, dass die Adressierung in dem FHEM Modul anders ist? Was wäre das korrekte Define für MX250.0 und MX250.1?

Vielen Dank,

Christian

ChrisD

#175
Hallo,

Die Adressen 16288 und 16289 sind die Merker MX250.0 und .1, allerdings nur wenn über die Bit-Funktionen darauf zugegriffen wird. Ich hatte nicht gesehen dass du versuchst einzelne Bits auszulesen. Mit dem ModbusRegister-Modul kannst du nicht darauf zugreifen.

Anbei findest du ein Modul zum Lesen von Bits (37_ModbusCoil.pm) sowie eine erweiterte Version des Server-Moduls welche auch das Lesen von Bits unterstützt.

Hiermit sollte das Lesen der Bits funktionieren:
reload 37_ModbusCoil
reload 36_ModbusTCPServer

delete MBTest01
delete MBC01
delete MBTest02

define MBTest01 ModbusCoil 0 16288
attr MBTest01 disableRegisterMapping 1
define MBC01 ModbusCoil 0 16289
attr MBC01 disableRegisterMapping 1
define MBTest02 ModbusCoil 0 16383
attr MBTest02 disableRegisterMapping 1


Das Attribut 'disableRegisterMapping' muss bei Wago gesetzt werden damit die Umrechnung der Adressen korrekt funktioniert.

Grüße,

ChrisD

Edit: Die aktuellen Versionen der Module sind unter https://github.com/ChrisD70/FHEM-Modules zu finden.

Christian77

Hey super, funktioniert! Vielen Dank!  ;D

Schritt für Schritt komme ich hier weiter  ;)

Die nächste "Herausforderung" ist, dass ich zwei Arten von Bits haben. Die erste Art ist eine Art Schalter mit zwei Zuständen 0 oder 1 (z.B. sollen Rolladen automatisch hochgefahren werden => 0=nein/1=ja?). Dieses funktioniert ja bereits so wie es soll mit dem Modul.
Die zweite Art soll eine Tasterfunktion sein (vgl. Stromstoßschalter). Das heißt über die Weboberfläche soll das Modbus Registerbit kurzzeitig auf 1 gesetzt werden (z.B. 1 Sekunde) und dann wieder automatisch zurück auf 0.
Ich habe gelesen, dass es so etwas wie ein "on-for-timer 1" gibt und gebe ich das über die Kommandozeile oder in den Details ein, macht es genau das was es soll. Ich bekomme es jedoch nicht hin, daraus einen Button in der Weboberfläche zu machen.

Habt ihr hierzu einen Tipp, wie ich dieses konfigurieren kann?

Vielen Dank,

Christian

ChrisD

Hallo,

Du kannst über das Attribut webCmd festlegen was auf der Weboberfläche angezeigt wird. So zeigt z.B.attr MBC01 webCmd on:off:on-for-timer 1eine zusätzliche Schaltfläche für on-for-timer 1 an.

Grüße,

ChrisD

Christian77

Hallo,

super, funktioniert! Ich habe jetzt nur "on-for-timer 1" hereingesetzt. Kann ich diesen Link-Text in der GUI auch umbennen oder das Icon anklickbar machen?

Vielen Dank für all die Tipps!

Christian

ChrisD

Hallo,

Du kannst den Namen 'umbenennen' indem du webCmd mit eventMap verbindest:
attr MBC01 webCmd Impuls
attr MBC01 eventMap /on-for-timer 1:Impuls/


Das Icon sollte bereits ohne Attribute anklickbar sein, allerdings wird beim Draufklicken kein Impuls geschickt sondern nur der Zustand umgeschaltet. Wenn beim Klick auf das Icon ein Impuls gesendet werden soll geht das über devStateIcon und eventMap :
attr MBC01 devStateIcon .*::Impuls
attr MBC01 eventMap /on-for-timer 1:Impuls/


devStateIcon bietet noch eine Reihe an weiteren Möglichkeiten, Details dazu kannst du in der Commandref finden.

Grüße,

ChrisD