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

[darkstorm]

Hallo, erstmal ein richtig geiles Modul. Hab den Fehler jetzt nicht mehr so oft. Dieses Problem konnte ich lösen. Jetzt Funktioniert es erstmal soweit habe jetzt zum Test einen Digitalen Ausgang definiert an dem eine Lampe hängt diesen konnte ich mit manuellem Schreiben von 0 und 1 auch schalten. Jetzt wäre meine Frage wie kann ich es definieren das ich sage es ist eine Lampe mit on und off Funktion so dass ich zb sagen kann set lampe on / off bzw es als Button darstelle im fhem und nicht von Hand eine 0 und 1 mit set schreibe?

[pc1246]

Moin
Dummy, notify, at, DOIF. AnfaengerPDF lesen, eine kleine Einfuehrung gibt es im Wiki glaube ich auch!
Wenn Du es nicht selbst machst, verstehst Du nichts, und hier wird Dir keiner Deine komplette config vorkauen!
Gruss Christoph

[pc1246]

@ChrisD
Willst Du nicht mal einen neuen thread aufmachen? Da koennte man dann die wichtigsten Essenzen aus diesem thread, insbesondere der Umschwenk, der gut mittendrin versteckt ist, nochmal kurz verlinken, oder notfalls auch beschreiben. Zudem haettest Du, der Du ja eigentlich der maintainer bist, die Moeglichkeit einiges ueber den 1. thread zu steuern. Eigentlich bist du ja auch Developer, und wenn Du Hilfe brauchst, Deine Module offiziell zu machen, dann biete ich mich auch an, die notwendigen Dokumente zu erstellen. Habe ich fuer Playbulb auch schon mal gemacht. Fuer die Squeezebox Module hast du ja eigentlich schon jemanden, der das bestimmt sofort machen wuerde!?
Gruss Christoph

[ChrisD]

Hallo,

@darkstorm: Kannst du die Definition des digitalen Ausgangs in FHEM posten ? Wenn du ModbusCoil verwendest hast sollte im UI von FHEM automatisch das Lampensymbol sowie die Befehle on und off angezeigt werden.

@Christoph: Ich will die Modbus-Module nicht offiziell machen weil inzwischen Stefan Strobel eigene Module für Modbus entwickelt hat und diese auch offiziell verteilt werden. Ich finde es nicht gut wenn für ein System 2 unterschiedliche offizielle Module existieren, auch wenn das Konzept der Module völlig unterschiedlich ist.

Bei den SB-Modulen ist es etwas anders, diese sind eigentlich komplett fertig um aufgenommen zu werden, ich weiß hier nur nicht wie ich die Entwicklungsversion auf Github und die offizielle Version parallel weiterführen soll.

Grüße,

ChrisD

[pc1246]

Ok
Da kann ich Dir nicht helfen, da ich zu wenig davon verstehe! Deine Hemmungen in allen Ehren, aber es sind ja genuegend Anwender mit Deinem Modul unterwegs. Das von Stefan hatte ich damals erst gar nicht gefunden!
Gruss Christoph

[bitvilla]

Hallo,

kann der Aussage von Christoph nur zustimmen.
Das belegen auch die Zahlen von FHEM statistics:

module name	installations	definitions
ModbusAttr	49	97
Modbus	38	42
ModbusTCPServer	36	36
ModbusRegister	33	338
ModbusCoil	11	135

Da es bereits weitere Modbus-Module für spezielle Anwendungen (Heizung, ... ) gibt, wäre es vielleicht sinnvoll dieses Modul für die SPS-Anbindung (Wago/Beckhoff) zu platzieren. In der Art SPSModbusRegister, SPSModbusCoil, ... .

Ist aber nur so ein Gedanke, kann den Aufwand der damit verbunden wäre leider nicht abschätzen!

Gruß
bitvilla

[darkstorm]

So habe es jetzt mit dem Wiki geschafft und dem Forum das ich einen DO schalten kann. Habe es mit ModbusCoil gemacht. Das funktioniert auch nur jetzt noch mal eine kleine Frage wenn der DO geschalten ist zb über einen Taster und es ist an. Dann registriert das FHEM es nicht und zeigt mir die Lampe trotzdem als OFF an. (Bitte verzeiht mir diese Frage aber ich versuche mir das alles anzueignen durch Lesen und Probieren.) Benutzen tu ich folgendes.

defmod l_gaeste ModbusCoil wago MX3.6
attr l_gaeste IODev wago
attr l_gaeste event-on-change-reading .*
attr l_gaeste room HausAutomation
attr l_gaeste webCmd on:off
attr l_gaeste writeCondition Impulse:QX3.6
setstate l_gaeste off
setstate l_gaeste 2017-12-07 20:24:11 state off

[ChrisD]

Hallo,

Verwendest du einen Stromstoßschalter am Ausgang QX3.6 ? Wenn ja, musst du über einen Eingang dafür sorgen dass die SPS auch den aktuellen Schaltzustand kennt. Wenn du diesen Eingang nach MX3.6 kopierst wird auch der Zustand in FHEM angezeigt.

Grüße,

ChrisD

[der-Lolo]

Hallo ChrisD,
lange hat sich nichts bewegt hier im Thread - liegt daran das es im großen und ganzem stabil läuft...

In den letzten Tagen ist mir aufgefallen das es nun doch zu meldungen im Log kommt -

2018.02.03 00:00:10 3: TelegramBot_Callback Eichenheim_Bot: Digest: Number of poll failures on 2018-02-02 is :0:
2018.02.02 21:13:07 3: ModbusTCPServer_Timeout, request: SimpleWrite [FB EE 00 00 00 06] 00 01 30 00 00 48
2018.02.02 21:12:52 3: ModbusTCPServer_Timeout, request: SimpleWrite [FB DD 00 00 00 06] 00 01 30 00 00 48
2018.02.02 21:12:04 3: HarmonyHub: new config
2018.02.02 21:12:03 3: HarmonyHub: connected
2018.02.02 21:12:01 2: HarmonyHub: disconnect
2018.02.02 21:12:00 3: ModbusTCPServer_Timeout, request: SimpleWrite [FB 92 00 00 00 06] 00 01 30 00 00 48
2018.02.02 21:12:00 2: myDeparture: error https://transport.stefan-biermann.de/publictransportapi/rest/departure?from=xxxxxxxxx&provider=Bvg&limit=10: Can't connect(2) to https://transport.stefan-biermann.de:443:  SSL wants a read first retriving departure
2018.02.02 00:00:24 3: TelegramBot_Callback Eichenheim_Bot: Digest: Number of poll failures on 2018-02-01 is :0:
2018.02.01 09:20:12 3: ModbusTCPServer_Timeout, request: SimpleWrite [FB 0B 00 00 00 06] 00 01 30 00 00 48
2018.02.01 06:43:54 3: harmony: IODev for device 48222063 is HarmonyHub

bisher konnte ich dieses verhalten nur im falle eines FHEM neustart sehen - kannst Du mir erklären was hier geschiet?
Zuletzt hatte ich vor etwa 14 Tagen die Waschküchen Beleuchtung hinzugefügt im Wago Projekt. Der vollständigkeit halber noch ein Screenshot vom gebastel. Der Trigger von FHEM und dessen rückmeldung habe ich noch nicht implementiert (bzw. noch keine merkerbereiche hierfür deklariert) Das geht auch sicher eleganter - über hinweise würde ich mich freuen.

[ChrisD]

Hallo,

Für die Timeout-Meldungen kann es mehrere Gründe geben. Entweder kommt die Anfrage nicht bei der SPS an, sie antwortet nicht oder die Antwort kommt zu spät weil FHEM mit etwas anderem beschäftigt ist.

Du kannst versuchen das Attribut 'timeout' zu setzen, Default ist 3 (Sekunden).

Die Steuerung des Lichts müsste auch ohne Trig_2 und Trig_5 funktionieren. Es gibt verschiedene Möglichkeiten den Code etwas kompakter zu schreiben, ob dies aber eleganter und später noch verständlich ist, ist eine andere Frage.

Grüße,

ChrisD

[bitvilla]

Hallo ChrisD,

bekomme ebenfalls diese Timeout Meldungen, aber nur ca. einmal am Tag.
Anbei ein kleiner Auszug aus meinem Log-File, vielleicht hilft es ja bei der Fehlersuche.

2018.02.04 12:32:10 3: Opening wago device 192.168.13.240:502
2018.02.04 12:32:13 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/36_ModbusTCPServer.pm line 909.
2018.02.04 12:32:13 3: ModbusTCPServer_Timeout, request:
2018.02.04 12:32:16 3: ModbusTCPServer_Timeout, request: SimpleWrite [20 10 00 00 00 06] 00 03 20 10 00 05
....
2018.02.05 02:32:41 3: ModbusTCPServer_Timeout, request: SimpleWrite [FE 7B 00 00 00 06] 00 03 30 C8 00 08
2018.02.05 02:32:44 3: ModbusTCPServer_Timeout, request: SimpleWrite [FE 7C 00 00 00 06] 00 03 31 90 00 24
2018.02.05 02:32:47 3: ModbusTCPServer_Timeout, request: SimpleWrite [FB 26 00 00 00 06] 00 01 00 20 00 20
2018.02.05 02:32:50 3: ModbusTCPServer_Timeout, request: SimpleWrite [FB 27 00 00 00 06] 00 01 02 28 00 18
2018.02.05 02:32:53 3: ModbusTCPServer_Timeout, request: SimpleWrite [FB 28 00 00 00 06] 00 01 10 00 00 50
2018.02.05 02:32:56 3: ModbusTCPServer_Timeout, request: SimpleWrite [FB 29 00 00 00 06] 00 01 36 40 00 30
2018.02.05 02:33:00 3: ModbusTCPServer_Timeout, request: SimpleWrite [FE 7D 00 00 00 06] 00 03 30 C8 00 08
2018.02.05 02:33:03 3: ModbusTCPServer_Timeout, request: SimpleWrite [FE 7E 00 00 00 06] 00 03 31 90 00 28
2018.02.05 02:33:06 3: ModbusTCPServer_Timeout, request: SimpleWrite [FB 2A 00 00 00 06] 00 01 00 20 00 20
2018.02.05 02:33:09 3: ModbusTCPServer_Timeout, request: SimpleWrite [FB 2B 00 00 00 06] 00 01 02 28 00 18
2018.02.05 02:33:12 3: ModbusTCPServer_Timeout, request: SimpleWrite [FB 2C 00 00 00 06] 00 01 10 00 00 50
2018.02.05 02:33:15 3: ModbusTCPServer_Timeout, request: SimpleWrite [FB 2D 00 00 00 06] 00 01 36 40 00 30
2018.02.05 02:33:19 3: ModbusTCPServer_Timeout, request: SimpleWrite [FE 7F 00 00 00 06] 00 03 30 C8 00 08
2018.02.05 02:33:22 3: ModbusTCPServer_Timeout, request: SimpleWrite [FE 80 00 00 00 06] 00 03 31 90 00 26
2018.02.05 02:33:25 3: ModbusTCPServer_Timeout, request: SimpleWrite [FB 2E 00 00 00 06] 00 01 00 20 00 20
2018.02.05 02:33:28 3: ModbusTCPServer_Timeout, request: SimpleWrite [FB 2F 00 00 00 06] 00 01 02 28 00 18
2018.02.05 02:33:31 3: ModbusTCPServer_Timeout, request: SimpleWrite [FB 30 00 00 00 06] 00 01 10 00 00 50
2018.02.05 02:33:34 3: ModbusTCPServer_Timeout, request: SimpleWrite [FB 31 00 00 00 06] 00 01 36 40 00 30
2018.02.05 02:33:36 1: 192.168.13.240:502 disconnected, waiting to reappear (wago)
2018.02.05 02:33:36 1: 192.168.13.240:502 reappeared (wago)
2018.02.05 02:33:37 2: ModbusTCPServer_Parse: except (code 2)
....
2018.02.06 07:32:27 3: UWZ Unwetterzentrale: Run.1043 Done fetching data
2018.02.06 07:33:19 2: SUSV: invalid Voltage In: 513 mV <- 208 1 2
2018.02.06 08:22:42 3: ModbusTCPServer_Timeout, request: SimpleWrite [FE 92 00 00 00 06] 00 03 30 C8 00 08
2018.02.06 08:22:45 3: ModbusTCPServer_Timeout, request: SimpleWrite [FE 93 00 00 00 06] 00 03 31 90 00 24
2018.02.06 08:22:48 3: ModbusTCPServer_Timeout, request: SimpleWrite [FB 54 00 00 00 06] 00 01 00 20 00 20
2018.02.06 08:22:51 3: ModbusTCPServer_Timeout, request: SimpleWrite [FB 55 00 00 00 06] 00 01 02 28 00 18
2018.02.06 08:22:54 3: ModbusTCPServer_Timeout, request: SimpleWrite [FB 56 00 00 00 06] 00 01 10 00 00 50
2018.02.06 08:22:57 3: ModbusTCPServer_Timeout, request: SimpleWrite [FB 57 00 00 00 06] 00 01 36 40 00 30
2018.02.06 08:23:01 3: ModbusTCPServer_Timeout, request: SimpleWrite [FE 94 00 00 00 06] 00 03 30 C8 00 08
2018.02.06 08:23:04 3: ModbusTCPServer_Timeout, request: SimpleWrite [FE 95 00 00 00 06] 00 03 31 90 00 26
2018.02.06 08:23:07 3: ModbusTCPServer_Timeout, request: SimpleWrite [FB 58 00 00 00 06] 00 01 00 20 00 20
2018.02.06 08:23:10 3: ModbusTCPServer_Timeout, request: SimpleWrite [FB 59 00 00 00 06] 00 01 02 28 00 18
2018.02.06 08:23:13 3: ModbusTCPServer_Timeout, request: SimpleWrite [FB 5A 00 00 00 06] 00 01 10 00 00 50
2018.02.06 08:23:16 3: ModbusTCPServer_Timeout, request: SimpleWrite [FB 5B 00 00 00 06] 00 01 36 40 00 30
2018.02.06 08:23:20 3: ModbusTCPServer_Timeout, request: SimpleWrite [FE 96 00 00 00 06] 00 03 30 C8 00 08
2018.02.06 08:23:23 3: ModbusTCPServer_Timeout, request: SimpleWrite [FE 97 00 00 00 06] 00 03 31 90 00 26
2018.02.06 08:23:26 3: ModbusTCPServer_Timeout, request: SimpleWrite [FB 5C 00 00 00 06] 00 01 00 20 00 20
2018.02.06 08:23:29 3: ModbusTCPServer_Timeout, request: SimpleWrite [FB 5D 00 00 00 06] 00 01 02 28 00 18
2018.02.06 08:23:32 3: ModbusTCPServer_Timeout, request: SimpleWrite [FB 5E 00 00 00 06] 00 01 10 00 00 50
2018.02.06 08:23:34 1: ModbusTCPServer_Parse: bad frame, sent: SimpleWrite [FB 5F 00 00 00 06] 00 01 36 40 00 30
2018.02.06 08:23:34 1: ModbusTCPServer_Parse: bad frame, received:  [FE 92 00 00 00 13] 00 03 10 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 78 00 05
2018.02.06 08:23:34 1: ModbusTCPServer_Parse: bad frame, sent: SimpleWrite [FB 5F 00 00 00 06] 00 01 36 40 00 30
2018.02.06 08:23:34 1: ModbusTCPServer_Parse: bad frame, received:  [FE 93 00 00 00 4B] 00 03 48 C8 7C 01 AC 9E 3C 03 BD C8 7C 01 AC 15 7C 03 D9 4F 80 00 12 9F 00 00 24 9F 00 00 24 77 40 00 1B 77 40 00 1B 77 40 00 1B 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 77 40 00 1B FB 54 00 00 00 07 00 01 04 10 00 00 00 FB 55 00 00 00 06 00 01 03 00 00 00 FB 56 00 00 00 0D 00 01 0A 00 00 00 00 00 00 00 00 00 01
2018.02.06 08:32:27 3: UWZ Unwetterzentrale: Run.1043 Done fetching data

Die hinterlegten Attribute sind:
verbose 3
pollInterval 1.6
combineReads 20:80

FHEM läuft bei mir aktuell auf einem Raspi3, zusammen mit volkszaehler.org zur Erfassung meiner Zählermesswerte.


Hätte da aber noch eine andere Bitte bzw. Anfrage.
Wäre es möglich ModbusRegister noch um den plcDataType DATE (yyyy-mm-dd) zu erweitern, da ich diesen in der SPS verwende und an FHEM übertragen möchte. Bisher kann ich diesem Datentyp aber nur an FHEM mit dem plcDataType DT übermitteln und es wird dann immer yyyy.mm.dd 00:00:00 angezeigt.

Ist das ein große Sache? Habe zwar die Definitionen im Quellcode entdeckt, bin aber leider kein Experte auf dem Gebiet.

Vorab schon mal herzlichen Dank für die Unterstützung.

Grüße,
bitvilla

[ChrisD]

Hallo,

Um 08:22:42 kommt es zum Timeout für die Anfrage 92, die Antwort darauf kommt dann um 08:23:34, also nach 55 Sekunden und wird verworfen.

Wo die Verzögerung herkommt ist schwer zu sagen, mit Hilfe von apptime und perfmon oder freezemon kannst du eventuell herausfinden ob es von FHEM selbst kommt.

Wäre es möglich ModbusRegister noch um den plcDataType DATE (yyyy-mm-dd) zu erweitern, da ich diesen in der SPS verwende und an FHEM übertragen möchte.

Ich habe den Datentyp in der neuen Version 24 hinzugefügt. Du kannst sie von Github installieren.

Grüße,

ChrisD

[bitvilla]

Hallo ChrisD,

Danke für die schnelle Bereitstellung des plcDataType DATE.
Habe ModbusRegister gleich aktualisiert und den Datentyp in FHEM angepasst.
Funktioniert wunderbar!

Die Sache mit der Verzögerung werde ich im Auge behalten.
Habe aber auch schon bei verschiedenen anderen FHEM Funktionen (z.B. Prüfen auf Updates, ...) bemerkt, dass die "neue" Installation unter Rasbian9 + Raspi3 komischerweise träger reagiert wie die "alte" Installation unter Raspian8 + Raspi2.
Evtl. liegt es an volkszaehler.org, denn die Middleware vzlogger fragt alle Minute die Zählerwerte von zwei Zählern per USB-Schnittstelle ab.
Werde dieses Thema weiterverfolgen und Rückinfo geben, wenn ich etwas eingrenzen konnte.

Bis dahin vielen Dank!

Gruß
bitvilla

[der-Lolo]

Der Raspi hat einen meiner meinung nach großen nachteil...
USB und Netzwerkschnittstelle werden auf demselben Bus zum Controller geführt.

[der-Lolo]

Hallo ChrisD,
Du hast natürlich recht, das funktioniert auch ohne trig 2 und 5, danke dir...

Ich habe noch was versucht:
mit switchOn wird das Licht auf den F_preset gesetzt.
ein weiteres switchOn soll dazu führen das der max wert 255 gesetzt wird - leider funktioniert das so nicht...