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

[ChrisD]

Hallo,

Der Fehler liegt (wie so oft) bei mir, kannst du versuchen ob Version 0014 das Problem löst ?

Grüße,

ChrisD

[der-Lolo]

Hallo Zusammen,
ich bastel gerade gedanklich an einem recht grossem Projekt...
Diesen thread hier habe ich durchgeackert, aber Informationen zum zusammenspiel zwischen Wago und FHEM fehlen mir noch.
Sagen wir mal ein Taster schaltet ganz simpel einen ausgang an der Wago - wann bekommt FHEM das mit? Ich möchte gerne mit FHEM ein Frontend haben in dem z.b. die Zustände der ausgänge bekannt sind. Wenn FHEM eine zustansaktualisierung nur z.b. jede minute bekommt wäre das nicht schnell genug.

[ChrisD]

Hallo,

Bei Modbus werden die Daten zyklisch von FHEM gelesen. Wie schnell dies geht hängt hauptsächlich von der eingesetzten Hardware und der FHEM-Konfiguration ab. Bei einer 'einfachen' FHEM-Installation und einem kleinen SPS-Programm kann ich 10 Pakete/s übertragen. Da FHEM alles sequentiell abarbeitet kann allerdings ein Modul alle anderen ausbremsen. Auf der SPS-Seite hängt die maximale Geschwindigkeit von der Taskzeit und der Auslastung ab. Reaktionszeiten im einstelligen Sekundenbereich sollten aber kein Problem sein.

Grüße,

ChrisD

[der-Lolo]

Danke für deine Antwort - werden wir mal etwas konkreter, im moment schwärme ich für eine Beckhoff BC9020 dazu die notwendigen ein / ausgangsklemmen und DMX.
Wir reden über etwa 80 Ein und etwa 60 Ausgänge - zusätzlich um die 40 DMX Kanäle.

Wie würde das abfragen ausschauen? wie schnell hätte FHEM eine Info über Änderungen?

[ChrisD]

Hallo,

Zu der Geschwindigkeit kann ich keine genaue Aussage machen da ich den Controller nicht verwende. Da der BC9020 keine Coil (Bit)-Zugriffe unterstützt, müssen die Daten über Register gelesen werden. Wenn du 80 digitale Eingänge und 60 digitale Ausgänge lesen möchtest kann dies in einem Paket erfolgen wenn sie aufeinanderfolgend im Speicher liegen. Die 40 DMX-Kanäle könnten im gleichen Paket mit übertragen werden wenn sie passend im Speicher abgelegt werden. Insgesamt würden so 29 Register auf einmal gelesen werden was für den Controller eine geringe Belastung darstellt.

Wie schnell die Daten dann von FHEM verarbeitet werden hängt von deiner Hardware ab. Wenn 1 Paket/s übertragen wird müssen von FHEM 180 Readings/s verarbeitet werden (inkl. notify, Filelog, ...).

Grüße,

ChrisD

[bk9050]

Hallo der-Loio,

wenn Du den relevanten Code in der BC9020 SPS sehr kompakt schreibst, sind die Zustände der EIngänge bzw. Ausgänge in wenigen Millisekunden im Merker-Bereich sichtbar. Es hängt natürlich auch davon ab, welchen zusätzlichen Code Du auf der BC9020 noch am laufen hast.

FHEM ist prinzipiell schon in der Lage, sich den entsprechenden Teil des Merker-Bereiches der SPS mehrmals pro Sekunde reinzuziehen. Dann hängt es davon ab, wie ChrisD schon anmerkte, was mit den eingelesenen Bits alles so passieren soll.

Ich empfehle auch, den Merker-Bereich seitens FHEM auch in einem Rutsch einzulesen, also alles zu cachen und dann auf den lokalen Speicher zuzugreifen.  Schreiboperation zur SPS habe ich in meiner Implementierung jedoch sofort ausgeführt, sprich sie haben Modbus-Aktivitäten angetriggert.

Gruß
Hermann-Josef (bk9050)

[der-Lolo]

Danke für eure Hilfe, in diesem Hardware durcheinander blickt man ja erstmal gar nicht durch.

In erster Linie wäre FHEM dazu gedacht die Visualisierung zu realisieren und weitere Komponenten ansprechen zu können. So könnte z.b. ein Serientaster die Lautstärke Kontrolle für Sonos sein. Ausserdem soll FHEM die Dimmer Einstellungen vornehmen beim drücken am Schalter wird die letzte Einstellung abgerufen.

Ich schwanke nun ein wenig in Richtung Wago weil ich gesehen habe das hier auch eine 1-Wire Integration möglich ist. Die Wago kann dieses Coil übertragen ja - welche Vorteile entstehen dadurch konkret?

[oniT]

Hallo ChrisD,

kannst du versuchen ob Version 0014 das Problem löst ?

ja, getestet und es funktioniert. Danke.

Jetzt noch eine weitere Frage zu timeout. Dies kommt bei mir inzwischen auch.

Zum Beispiel:

Code Auswählen Erweitern


2015.03.07 15:24:23.416 1: ModbusTCPServer_Timeout, request: SimpleWrite [0D AE 00 00 00 06] 00 03 0D AE 00 01
2015.03.07 15:24:23.567 1: ModbusTCPServer_Timeout, request: AddRQueue [00 7E 00 00 00 06] 00 03 00 7E 00 01
2015.03.07 14:48:31.465 1: ModbusTCPServer_Timeout, request: SimpleWrite [0D AE 00 00 00 06] 00 03 0D AE 00 01
2015.03.07 14:48:31.558 1: ModbusTCPServer_Timeout, request: AddRQueue [13 AA 00 00 00 06] 00 03 13 AA 00 01


Ich habe dann wie weiter vorher beschrieben die Zeit gesetzt:

Code Auswählen Erweitern


Internals:
   DEF        192.168.1.160
   DeviceName 192.168.1.160:502
   FD         18
   NAME       SolarLogServer
   NR         87
   NTFY_ORDER 50-SolarLogServer
   PARTIAL
   STATE      ok
   TYPE       ModbusTCPServer
   statistics 8834 / 8839 / 99819 / 106068
   Readings:
     2015-03-07 17:09:36   state           opened
   Helper:
     hd_tr_id   3502
     hd_unit_id 0
     lastFrame  Received [0D AE 00 00 00 05] 00 03 02 00 00
     state      idle
     Statistics:
       bytesIn    99819
       bytesOut   106068
       pktIn      8834
       pktOut     8839
Attributes:
   pollInterval 10
   timeout    6
   verbose    3


Code Auswählen Erweitern


Internals:
   DEF        192.168.1.150
   DeviceName 192.168.1.150:502
   FD         4
   NAME       HeatPumpServer
   NR         49
   NTFY_ORDER 50-HeatPumpServer
   PARTIAL
   STATE      ok
   TYPE       ModbusTCPServer
   statistics 25712 / 25715 / 272801 / 308580
   Readings:
     2015-03-06 21:33:36   state           opened
   Helper:
     hd_tr_id   43
     hd_unit_id 0
     lastFrame  Received [00 2B 00 00 00 04] 00 01 01 45
     state      idle
     Statistics:
       bytesIn    272801
       bytesOut   308580
       pktIn      25712
       pktOut     25715
Attributes:
   pollInterval 10
   timeout    6
   verbose    3


Hat aber nichts gebracht bisher. Hast Du da noch eine Idee?

Danke

Gruß,
Tino

[ChrisD]

Hallo,

@der-Lolo:
Coils stellen einzelne Bits dar. Damit lassen sich z.B. digitale Ein- und Ausgänge direkt von FHEM aus ansprechen. Das Fehlen der Coil-Funktionen sollte aber nicht ausschlaggebend sein für die Auswahl der Hardware da sich die Funktionalität auch über Registerzugriffe nachbilden lässt.

@Tino:
Ich befürchte dass der Timeout durch Pakete kommt die so aussehen wie im Logauszug in Beitrag 229. Kannst du Version 0012 von ModbusTCPServer ausprobieren, diese versucht Pakete mit mehr als einer Antwort aufzuteilen und Pakete die zu spät kommen trotzdem zu verarbeiten ? Zum Testen bitte verbose bei den Server-Modulen auf 3 setzen.

Grüße,

ChrisD

[oniT]

Hallo ChrisD,

hier der Logauszug mit der TCP Server Version 0012.

Code Auswählen Erweitern


2015.03.07 22:46:57.439 1: ModbusTCPServer_Timeout, request: SimpleWrite [00 68 00 00 00 06] 00 03 00 68 00 01
2015.03.07 22:46:57.934 3: ModbusTCPServer_Parse: got frame for previous request:  [00 68 00 00 00 05] 00 03 02 00 00
2015.03.07 23:16:20.564 1: ModbusTCPServer_Timeout, request: SimpleWrite [0D AE 00 00 00 06] 00 03 0D AE 00 01
2015.03.07 23:47:51.624 1: ModbusTCPServer_Timeout, request: SimpleWrite [0D B4 00 00 00 06] 00 03 0D B4 00 02
2015.03.07 23:47:52.120 3: ModbusTCPServer_Parse: got frame for previous request:  [0D B4 00 00 00 07] 00 03 04 2B B5 00 00

2015.03.08 04:35:45.453 1: ModbusTCPServer_Timeout, request: SimpleWrite [0D AE 00 00 00 06] 00 03 0D AE 00 01
2015.03.08 04:35:45.893 3: ModbusTCPServer_Parse: got frame for previous request:  [0D AE 00 00 00 05] 00 03 02 00 00 0D BC 00 00 00 07 00 03 04 DA 6A 00 7C
2015.03.08 05:04:57.388 1: ModbusTCPServer_Timeout, request: SimpleWrite [0D AE 00 00 00 06] 00 03 0D AE 00 01
2015.03.08 06:09:41.076 1: ModbusTCPServer_Timeout, request: SimpleWrite [0D B4 00 00 00 06] 00 03 0D B4 00 02
2015.03.08 06:09:41.131 1: ModbusTCPServer_Timeout, request: SimpleWrite [00 68 00 00 00 06] 00 03 00 68 00 01
2015.03.08 06:09:41.570 3: ModbusTCPServer_Parse: got frame for previous request:  [0D B4 00 00 00 07] 00 03 04 00 00 00 00 0D AE 00 00 00 05 00 03 02 00 00
2015.03.08 06:09:41.629 3: ModbusTCPServer_Parse: got frame for previous request:  [00 68 00 00 00 05] 00 03 02 00 00
2015.03.08 06:21:21.736 1: ModbusTCPServer_Timeout, request: SimpleWrite [0D AE 00 00 00 06] 00 03 0D AE 00 01

2015.03.08 07:44:17.662 1: ModbusTCPServer_Timeout, request: SimpleWrite [0D AE 00 00 00 06] 00 03 0D AE 00 01
2015.03.08 07:44:17.936 1: ModbusTCPServer_Timeout, request: SimpleWrite [00 29 00 00 00 06] 00 01 00 29 00 08
2015.03.08 07:44:18.435 3: ModbusTCPServer_Parse: got frame for previous request:  [00 29 00 00 00 04] 00 01 01 10

2015.03.08 09:04:42.287 1: ModbusTCPServer_Timeout, request: SimpleWrite [0D AE 00 00 00 06] 00 03 0D AE 00 01
2015.03.08 09:38:24.773 1: ModbusTCPServer_Timeout, request: SimpleWrite [00 32 00 00 00 06] 00 01 00 32 00 08
2015.03.08 09:38:25.261 3: ModbusTCPServer_Parse: got frame for previous request:  [00 32 00 00 00 04] 00 01 01 0A


Ich hoffe damit kannst Du was anfangen. Ich weiß nicht mehr ab welcher Version diese Meldung kommen, zu Anfangs waren diese jedenfalls nicht da.

Danke

Gruß,
Tino

[der-Lolo]

Darf ich nochmal kurz zu den Coils was fragen?
Wie kann ich mir das vorstellen? Definiere ich welche Ein bzw. Ausgänge übertragen werden um diese dann ab Eventmonitor in FHEM verarbeiten zu können? Verstehe ich das richtig das ich zyklisch diese Coils abfrage oder werden die irgendwie gepusht? Auf welchen Zyklus könnte ich einstellen? Wäre es auch möglich verschiedene abfragen zu haben, also schnelle Coil Übertragung wenn z.b. ein Ausgang seinen Status ändert - langsame Übertragung wenn z.b. eine Temperatur sich ändert?
Wenn ich von FHEM aus einen Slider als Dimmer bediene, wird dann schon während dem Schieben übertragen - oder erst wenn die Einstellung abgeschlossen ist?

[ChrisD]

Hallo,

Du kannst jeden Ein- oder Ausgang als einzelnes Element definieren, so wie z.B. bei FS20 oder Homematic. Die Daten werden bei Modbus aber nicht ereignisgesteuert übertragen sondern müssen zyklisch abgefragt werden. Dazu gibt es bei den Modulen 2 Parameter:
- pollInterval legt fest wie häufig FHEM überprüft ob überhaupt Daten zu lesen sind, je kleiner der Wert desto öfter ist FHEM beschäftigt. Auf leistungsfähiger Hardware kann dieser Wert auf 50ms gesetzt werden. Standard ist 500ms
- updateInterval legt für jedes Bit (Coil) und Register getrennt fest wie häufig gelesen wird, bei Temperaturwerten könnte dieser Wert z.B. auf 60s gestellt werden, bei einem Taster dagegen auf 100ms

Der FHEM-Slider überträgt den Wert immer erst wenn Maus oder Finger losgelassen werden, der Wert wird nicht während der Bewegung aktualisiert.

Grüße,

ChrisD

[der-Lolo]

Das klingt vielversprechend - als FHEM Hardware setze ich aktuell einen Cubietruck ein, das muss aber nicht so bleiben. Die vielzahl meiner geplantem Eingänge brauche ich gar nicht in FHEM, nur die die z.b. die Sonos Lautstärken regeln sollten in FHEM landen -  die ausgänge die z.b. das Licht schalten sind mir wichtiger es  wäre mir schon wichtig "Zeitnah" eine aktualisierung dafür zu haben.
Vielleicht geht dafür auch noch ein anderer weg, ich habe mich mangels Informationen noch nicht endgültig entschlossen, zur Zeit schaut es aber so aus als ob DMX für nahezu alle Lampen zum einsatz kommt. Hast Du oder vielleicht jemand anderes der hier mitliest Wago und DMX im Einsatz? Im netz findet man nicht viel darüber...

[ChrisD]

Hallo,

@Tino:
Die Timeouts wurden bis vor einigen Versionen nicht angezeigt sondern einfach ignoriert. Für die Fehlersuche habe ich das Loggen nachträglich eingebaut.

Ich habe in der Version 0013 das Timeout-Verhalten geändert. Kannst du mit der Version nochmal testen ? Du kannst die Meldungen jetzt auch abstellen wenn du verbose auf 2 oder kleiner setzt.

@der-Lolo:
Zu DMX kann ich dir nicht weiterhelfen, bei Wago scheint es 2 Bibliotheken zu geben um DMX anzubinden. Die eine verwendet die serielle Schnittstelle 750-652 die ich bereits für andere Anwendungen verwendet habe, die andere einen Ethernet-RS485-Umsetzer von DMX4all. Das Gerät von DMX4all hat den Vorteil dass es flexibler ist und im Prinzip auch direkt von FHEM angesprochen werden könnte.

Grüße,

ChrisD

[PEPITO82]

Ich habe gestern Abend versucht, meinen Solar Log als ModbusTCPServer zu definieren:

Code Auswählen Erweitern

define mySolarlog ModbusTCPServer 192.168.178.49

Leider erhalte ich dann die Meldung, dass das Modul nicht geladen werden konnte.
Im Logfile steht folgendes:

Code Auswählen Erweitern

2015.03.10 20:30:40 1: PERL WARNING: Bareword found where operator expected at ./FHEM/36_ModbusTCPServer.pm line 5, near ""en" class"
2015.03.10 20:30:40 1: PERL WARNING: (Missing operator before class?)
2015.03.10 20:30:40 1: PERL WARNING: Bareword found where operator expected at ./FHEM/36_ModbusTCPServer.pm line 12, near "<title>FHEM"
2015.03.10 20:30:40 1: PERL WARNING: (Missing operator before FHEM?)
2015.03.10 20:30:40 1: PERL WARNING: Bareword found where operator expected at ./FHEM/36_ModbusTCPServer.pm line 12, near "36_ModbusTCPServer"
2015.03.10 20:30:40 1: PERL WARNING: (Missing operator before ModbusTCPServer?)
2015.03.10 20:30:40 1: reload: Error:Modul 36_ModbusTCPServer deactivated:
Unrecognized character \xC2; marked by <-- HERE after at master <-- HERE near column 57 at ./FHEM/36_ModbusTCPServer.pm line 12.

2015.03.10 20:30:40 0: Unrecognized character \xC2; marked by <-- HERE after at master <-- HERE near column 57 at ./FHEM/36_ModbusTCPServer.pm line 12.

Woran könnte das liegen?