FHEM Forum

FHEM => Automatisierung => Thema gestartet von: lechez am 05 Mai 2013, 10:50:13

Titel: Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: lechez am 05 Mai 2013, 10:50:13
Hallo,

besitze eine Wago SPS die momentan die Rolläden etc. steuert.
Würde gerne diese mit FHEM verbinden.
1. FHEM ggf. steuert SPS.
2. FHEM setzt und liest Werte in SPS.
3. FHEM visualisiert die Werte der SPS.

Am besten über Modbus TCP/IP.
Habe dazu nur "alte" beträge gefunden.
z.B. https://groups.google.com/forum/?fromgroups=#!topic/fhem-users/npNHGLIO4Hs (//groups.google.com/forum/?fromgroups=#!topic/fhem-users/npNHGLIO4Hs)

Hat jemand über Modbus seine SPS an FHEM angeschlossen? Wenn ja wie?

Gruß
lechez
Titel: Aw: Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: BennyRPI am 10 Mai 2013, 21:20:54
Hallo lechez!

Ich bin selbst Programmierer in der Automationswelt, in meiner Firma nutzen wir ein sehr komplexes System.
Privat spiele ich gerne mit solchen Sachen rum....
Wago kenne ich gut, wir benutzen hauptsächlich den 750-352 mit denn benötigten Klemmen aus der 750er Serie.
Ich hätte auch großes interesse daran ob Fhem auch mit der Wago Hardware funktioniert.
Titel: Aw: Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: Mopedpaul am 18 Mai 2013, 06:54:43
Hallo,
auch ich bin an einer Modbus Anbindung sehr interessiert. Bei mir geht es nicht um die Wago Technik sondern um eine Solaranlage die über einen Solarlog visualisiert wird. Auch hier können Daten aus dem Solarlog direkt über MOdbus TCP/IP ausgelesen werden. Dieses Modbus Protokoll scheint ja sehr vielseitig zu sein - Warum ist es noch nicht in FHEM ?
Titel: Aw: Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: oniT am 18 Mai 2013, 07:57:57
Hallo Mopedpaul,

passt zwar jetzt nicht ganz zum Thema Wago, aber darf ich fragen welchen Solar-Log Du hast? Ich dachte da gibts es Modbus über RS485 und nicht Modbus TCP/IP.


Danke
TinoB
Titel: Aw: Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: lechez am 18 Mai 2013, 10:09:48
Hallo zusammen,

ich habe jetzt Modbus Anbindung hinbekommen.
@oniT: Es gibt Modbus über TCP und auch über RS485.
Zitat Wiki: Mittels Modbus können ein Master (z. B. ein PC) und mehrere Slaves (z. B. Mess- und Regelsysteme) verbunden werden. Es gibt zwei Versionen: Eine für die serielle Schnittstelle (EIA-232 und EIA-485) und eine für Ethernet.
Für die Anbindung an die Solaranlage, wenn der Logger nur einer RS485 hat bekommst du einen umsetzer aufs LAN.
Infos was man machen kann findest du unter anderem im Forum http://www.photovoltaikforum.com/solarview-f104/ (//www.photovoltaikforum.com/solarview-f104/)
Ich habe eine Netzwerkschnittstelle bei meinem Wechselrichter, über die ich auslese und in FHEM darstelle.

@BenyPRI:
Habe jetzt geschaft meine Homematic Türgriff erfolgreich mit der Wago SPS zu koppeln.
Ich habe in der Wago jetzt globale Variable definiert. Diese werden über ein Modbus Befehl von FHEM gesetzt oder von Wago SPS gesetzt.
Mein SPS Programm überprüft diese Variable. Wenn ich jetzt also im Garten bin, fährt meine SPS die Rollade von der Tür nicht mehr runter.
-Ich frage auch mein PERI Bewegungsmelder über die Helligkeit im Raum ab. Er steuert dann die Wago in die Beschattungsposition.
-Wago meldet auch die Position der Rolläden. Diese werden/sollen dann in FHEM angezeigt. (Muss ich noch machen).

Habe über das Projekt Modbus TCP mit Martin (NFC etc..) gesprochen. Ich soll ein Wiki und ein Modul schreiben. Bin gerade dran erstmal ein Modul zu schreiben, dass benutzt werden kann. Bis jetzt ist viel hardcoded. Dann folgt was Wiki.

Modbus habe ich natürlich nicht neu erfunden  siehe https://github.com/sourceperl/MBclient (//github.com/sourceperl/MBclient)
Habe dazu ein FHEM Modul geschrieben, dass die Funktionen mit den richtigen Adressen aufruft bzw abfragt.

Vielleicht konnte es weiter helfen.

Gruß
lechez

Titel: Aw: Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: oniT am 18 Mai 2013, 13:04:40
Hallo lechez,

ich möchte das Thema Wago jetzt nicht zerstören, aber weil gerade das Thema Modbus hier enthalten ist, das mit Modbus TCP kenne ich. Mich hat es nur gewundert das Solar-Log eine Modbus TCP Anbindung hat. Somit habe ich das nur falsch verstanden uns es geht um einen extra Konverter.

Ok, sollte man nicht zum Thema PV ein eigene Rubrik eröffnen? Ich finde dies ist sehr interessant. Ich werde dies mal im "FHEM Forum" anfragen.

Gruß
TinoB
Titel: Aw: Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: Mopedpaul am 18 Mai 2013, 14:18:57
Hallo Timo,
ich habe den Solarlog 200. Aber das können alle Solarlog und hat nichts mit der Anbindung der Wechselrichter zu tun. Das ist ein TCP/IP Zugriff über Port 502 der Solarlog Netzwerkschnittstelle.

Im Anhang die Beschreibung zun Solarlog Modbus. Wird wohl nicht groß auf der Solarlog Seite darüber berichtet, ist halt nur was für Leute, die die Solarlog Daten für weitere Anwendungen auswerten wollen - so wie wir halt. Habe diese Infos auch erst auf spezieller Nachfrage per Mail erhalten.

Es gibt verschiedene Versionen bezüglich des Umfangs der Infos (abrufbare Register) über dem Modbus. In der Modbus Free Version sind zumindest die Wichtigsten Parameter enthalten - Power AC+DC, Spannung AC+DC, Ertrag gestern,Tag,Mon,Jahr, (Verbrauch Momentan-am Tag-gestern - nur mit S0 Zähler für den Verbrauch im Haus).
Vor allem Interessant für die intelligente Schaltung von Verbrauchern die Parameter P-AC momentane AC Leistung und ggf aktueller Verbrauch. Vor allem bei weicher 70 % Regelung. Da kann man ggf Verbraucher zuschalten, wenn der Wechselrichter andernfalls in die 70% Begrenzung geht, und somit die volle Leistung der Anlage nutzen.

Wer mehr braucht (MPP Tracker, Temperaturen usw. muss dann eine Lizenz für den erweiterten Zugriff erwerben (Siehe PI_ModbusTCP_Interface_de.

Ich habe bereits erfolgreich die Daten von Adresse 3500 bis 3528 ausgelesen (das hier beschriebene Script vom Modbus (2010) mit den entsprechenden Netzwerk und Registeradressen. Allerdings nicht unter FHEM sondern direkt als Perl Script vom PC aus.
Komme jetzt aber nicht weiter bei der Einbindung in 99_myutils. Habe die 99_myutils mal angehängt. Vielleicht kann ja jemand weiter helfen. So wie es jetzt ist, hängt sich FHEM auf wenn die Sub Solarlog aufgerufen wird.

Ich stelle mir das so vor
Die Subroutine Solarlog in 99_myutils einbinden, dann über define die Routine aufrufen, hier die Registernummer übergeben und als Rückantwort den Registerinhalt zurück. Solarlog Adresse, Port (fest-502),Werte für Lesen (04), Schreiben (06).. usw können ja fest unter 99_myutils eingetragen werden.

FHEM
define SolarTimer at +*00:02:00 {Solarlog(Register,Wert)}
attr SolarTimer group Workflow
attr SolarTimer room Solaranlage
   

MfG Uwe
Titel: Aw: Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: Puschel74 am 27 Mai 2013, 19:07:35
Hallo,

ich hab grad eine Wago 750-880 (die mit den 2 Ethernet-Ports) hier "rumliegen" und wollte mal fragen ob es jemand geschafft hat per TCP/IP eine Wago-SPS in fhem ein zu binden.
Wäre genial wenn das ginge da ich auch ein Dali-Modul dafür hab und dann evtl. sogar Dali-Geräte ansteuern könnte (Digital-In/Out, Analog-In/Out versteht sich selbst ;-) ).

Grüße
Titel: Aw: Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: mcbain2k am 30 Mai 2013, 16:44:42
Hallo,
 ich schließe mich an, seit dem Umstieg auf fhem langweilt sich meine WagoSPS auch zu tode.

MFG
 McBain
Titel: Aw: Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: mcbain2k am 30 Mai 2013, 16:45:02
:-)
Titel: Aw: Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: lechez am 06 Juni 2013, 22:21:46
Hallo,

habe es erstmal quick and dirty implementiert:

Erst in Wago globale Variable definiert. Diese ist erreichbar als Modbusadresse 12288

VAR_GLOBAL
   SPS_Bit1_IPS_Adresse_12288  AT %MX0.0:BOOL;   
END_VAR

in /opt/fhem/FHEM

mbclient.pm (Hab ich im Internet gefundeng)
99_modbus.pm hier ist eine Funktion, die die Modbusadresse den Wert setzt.

Ich schreibe hier die Stellung vom Türgriff:
define tuer_griff_open_close notify CUL_HM_HM_SEC_RHS_1F135D { if (Value("CUL_HM_HM_SEC_RHS_1F135D") eq "closed") {write_modbus("0")} else {write_modbus("1")} }

In der Wago wird dann dieser Wert abgefragt, so dass mir die Rolladen an der Terrassentür nicht runterfährt wenn ich draussen bin.

Wir irgendwann auch mal erweitert.
Vielleicht hilft das jemand

Gruß
lechez




Titel: Aw: Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: Puschel74 am 06 Juni 2013, 22:27:34
Hallo,

wow, es geht also doch was.
Genial.
Zum Glück hab ich bald 2 1/2 Wochen frei - da werd ich meine Wago-SPS mal ans Netz hängen.

Aber in der 99_modbus.pm müsste doch diese Zeile
Zitat$m->host("192.168.2.5");
angepasst werden oder täusch ich mich da?
Das sollte doch die IP der Wago sein oder nicht?

Grüße
Titel: Aw: Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: lechez am 06 Juni 2013, 23:15:11
Hallo,

ja die IP muss angepasst werden.

auch ggf die Modbus Adresse muss angepasst werden.

Hier mal alle Adressen in der Wago die ich gesetzt habe.

VAR_GLOBAL
   SPS_Bit1_IPS_Adresse_12288  AT %MX0.0:BOOL;   (*Modbusadresse 12288*)
        SPS_Bit17_IPS_Adresse_12304  AT %MX1.0:BOOL;   (*Modbusadresse 12304*)
   SPS_Bit33_IPS_Adresse_12320  AT %MX2.0:BOOL;   (*Modbusadresse 12320*)
   SPS_Bit49_IPS_Adresse_12336  AT %MX3.0:BOOL;   (*Modbusadresse 12336*)
   SPS_BYTE101_IPS_Adresse_12338 AT %MB101 :BYTE;   (*Modbusadresse 12338*)
   SPS_Word100_IPS_Adresse_12388 AT %MW100 :WORD;   (*Modbusadresse 12388*)
   SPS_INT200_IPS_Adresse_12488 AT %MW200 :INT;   (*Modbusadresse 12488*)
   SPS_SINT400_IPS_Adresse_12688 AT %MW400 :SINT;   (*Modbusadresse 12688*)
   SPS_SINT416_IPS_Adresse_12704 AT %MW416 :SINT;   (*Modbusadresse 12704*)
   SPS_REAL500_IPS_Adresse_13288 AT %MD500 :REAL;   (*Modbusadresse 13288*)
END_VAR

Gruß
Titel: Aw: Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ParkerLouis am 07 August 2013, 23:09:55
Hallo Leute,

das ist mein erster Post hier im Forum. Ich bin zu FHEM gekommen wie die Jungfrau zum Kind, als ich festgestellt habe, dass es da "sowas" für die neue FritzBox gibt.

Ich steuere unser Haus komplett mit einer Wago. Alle Taster im Haus laufen zu einer zentralen Wago. Von da aus wird alles über Relais angesteuert. Das ganze System läuft super. Einzig das Einstellen der Jalousiezeiten über die JAVA-Visu ist recht bescheiden und läuft auch nicht auf mobilen Geräten.

Jetzt bin ich über diesen Thread gestolpert, weil ich die Wago gerne über Modbus an Fhem ankoppeln will.

Ich bin einfach mal der "Anleitung" gefolgt und habe versucht, die angehängten Module auf die FritzBox zu laden.

Die Verzeichnisstruktur auf meiner FB sieht allerdings etwas anders aus. Sämtliche Dateien scheinen in /fhem/usr/share/fhem/FHEM zu liegen. Dort habe ich 99_Modbus.pm und MBClient.pm abgelegt.

Kann mit jemand helfen, wie ich eine Modbusadresse nun auslesen und darstellen kann?

Vielen Dank!
Titel: Aw: Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: lechez am 08 August 2013, 08:53:37
Hallo ParkerLouis,

Ich habe ein Update der Datei 99_modbus vorgenommen. Anbei die neue Datei

1. MBclient und 99_modbus.pm in das Verzeichnis ..FHEM/ kopieren.
2. In MBClient die IP-Adresse deine Wago eintragen. $m->host("192.168.2.5");


3. in Wago globale Variable eintragen. Und laden.
z.B.
SPS_Bit_IPS_Adresse_12288  AT %MX0.0:BOOL;   (*Modbusadresse 12288 Tuergruff*)
SPS_INT212_IPS_Adresse_12500 AT %MW212 :INT;   (*Modbusadresse 12500*)

3. FHEM neu starten.

4.Hier ein Beispiel wie ich die Stellung des Türgriffs (Homematic) an die Wago weiterleite, so dass die Rolladen nicht runter fahren, wenn die Tür nicht geschlossen ist. in fhem.cfg:
 define tuer_griff_open_close notify CUL_HM_HM_SEC_RHS_1F135D { if (Value("CUL_HM_HM_SEC_RHS_1F135D") eq "closed") {write_modbus(12288,0)} else {write_modbus(12288,1)} }

5. Ich habe auch den Impulausgang S0 meines Stromzählers (Vom EVU geliefert ITZR) auf Eingänge der Wago gelegt.
Da ich ein Zweirichtungszähler, Solarzähler habe super Sache.
Ich habe mal Qick and Dirty ein Modul dafür gemacht. Wird aber noch schöner. Habe mir mal erlaubt von einem Modul für KOSTAL.pm abzuleiten. Muss das Modbul noch variabler gestalten aber das kommt noch...

in fhem.cfg
define S0_Zaehler S0
attr S0_Zaehler delay 60
attr S0_Zaehler delayCounter 4
attr S0_Zaehler loglevel 6
attr S0_Zaehler room Hausanschlussraum
define log_S0_Zaehler FileLog ./log/S0_Zaehler-%Y-%m.log S0_Zaehler:(Zaehler-EVU|Zaehler-Solar|Zaehler-Solar-Einspeisung|Zaehler-Solar-Eigenverbrauch).*
attr log_S0_Zaehler room Hausanschlussraum
define wl_log_S0_Zaehler_1 weblink fileplot log_S0_Zaehler:wl_log_S0_Zaehler_1:CURRENT
attr wl_log_S0_Zaehler_1 room Hausanschlussraum

Ich hoffe ich konnte dir weiter helfen.

Gruß

lechez
Titel: Aw: Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ParkerLouis am 08 August 2013, 09:53:03
Wow,
Danke für die schnelle Antwort.

Ich freue mich schon drauf, das auszuprobieren.

Auch die Geschichte mit dem S0 Bus interessiert mich sehr. Hast Du dazu auch noch weitere Informationen? Welche Eingangsklemme brauche ich dafür und wie sieht die Verkabelung am Zähler aus?

Nochmal Danke!
Titel: Aw: Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: Wiliam am 11 Oktober 2013, 18:22:29
Hallo Lechez

Super Projekt was Du hier eingestellt hast, bin schon etwas neidisch.
Habe Versuch das Projekt abzukupfern jedoch leider ohne Erfolg, eventuell kannst Du mir ja ein wenig Hilfestellung geben.
Zu meiner Hardware, ich Besitze eine Wago 881 mit einem seriellen 1wire Buskoppler und ein paar Temperatursensoren.
Auf der Fritzbox läuft FHEM. Jetzt würde ich gerne meine Temperaturverläuft über FHEM Plot´s darstellen.

als erste habe ich wie beschrieben Deine 3*.pm´s in den ../FHEM Ordner kopiert und die IP Adresse angepasst.
danach habe ich in den Globalen Variablen den Befehl "SPS_INT212_IPS_Adresse_12500 AT %MW212 :REAL; (*Modbusadresse 12500*)" kopiert.
die Temperaturen sind REAL Werte, muß ich diese erst umwandel, oder kann ich INT wie oben einfach in REAL ändern?
habe dann die Temperatur mit %MW212 verbunden.

danach habe ich Deine Befehlszeile

define S0_Zaehler S0
attr S0_Zaehler delay 60
attr S0_Zaehler delayCounter 4
attr S0_Zaehler loglevel 6
attr S0_Zaehler room Hausanschlussraum
define log_S0_Zaehler FileLog ./log/S0_Zaehler-%Y-%m.log S0_Zaehler:(Zaehler-EVU|Zaehler-Solar|Zaehler-Solar-Einspeisung|Zaehler-Solar-Eigenverbrauch).*
attr log_S0_Zaehler room Hausanschlussraum
define wl_log_S0_Zaehler_1 weblink fileplot log_S0_Zaehler:wl_log_S0_Zaehler_1:CURRENT
attr wl_log_S0_Zaehler_1 room Hausanschlussraum


in meine fhem.cfg kopiert, da bekam ich leider immer die Fehlermeldung "Unknown module S0"

bin leider noch sehr unerfahren was FHEM angeht, aber Versuch macht kluch :-)

danke schonmal

Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: bytebold am 25 Oktober 2013, 19:49:51
Hallo,

ich habe Fhem über USB- Stick auf meiner FritzBox 7270 laufen. Jetzt wollte ich testen, ob ich Zugriff auf meine Wagos 750-881 habe.
In vorliegender Doku wird aber immer nur die automatische Einbindung über Funktelegramme beschrieben. Die Modbus Treiber habe
ich auch auf dem USB- Stick. Ich weiß jetzt aber nicht, wie ich vorgehen muß, um Schaltzustände nur von der Weboberfläche auf die
Wago zu bekommen, bzw. Wago- Variablen auf der Weboberfläche anzuzeigen.
Bin absoluter Neuling mit Fhem und finde leider noch keine passende Beschreibung dafür. Kann mir vielleicht jemand ein paar Code-
schnipsel posten, wie ich Variable auslesen und anzeigen kann ? Bzw. in Variable schreiben kann ?
In der Modbus -Datei habe ich IP-Adresse und Modbus-Adresse eingetragen.
Gruß und Vielen Dank, bytebold
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: bytebold am 26 Oktober 2013, 19:26:21
So, erster Test hat funktioniert.

define Garten_Steckdose41 dummy
attr Garten_Steckdose41 room Garten
attr Garten_Steckdose41 setList On Off
attr Garten_Steckdose41 webCmd On:Off

define act_Garten_Steckdose41 notify Garten_Steckdose41 { if (Value("Garten_Steckdose41") eq "Off") {write_modbus(12292,0)} else {write_modbus(12292,1)}}

define Garten_Steckdose42 dummy
attr Garten_Steckdose42 room Garten
attr Garten_Steckdose42 setList On Off
attr Garten_Steckdose42 webCmd On:Off

define act_Garten_Steckdose42 notify Garten_Steckdose42 { if (Value("Garten_Steckdose42") eq "Off") {write_modbus(12293,0)} else {write_modbus(12293,1)}}


Damit lassen sich bits in der Wago schalten.

Deklaration in der Wago:

* Modbus Adresse 12292 *)

Dummy0_0 AT %MX4.0: BOOL;
Dummy0_1 AT %MX5.0: BOOL;
Dummy0_2 AT %MX6.0: BOOL;
Dummy0_3 AT %MX7.0: BOOL;
Dummy0_4 AT %MX8.0: BOOL;
Dummy0_5 AT %MX9.0: BOOL;
Dummy0_6 AT %MX10.0: BOOL;
Dummy0_7 AT %MX11.0: BOOL;
Dummy0_8 AT %MX12.0: BOOL;
Dummy0_9 AT %MX13.0: BOOL;
Dummy0_10 AT %MX14.0: BOOL;
Dummy0_11 AT %MX15.0: BOOL;
Dummy0_12 AT %MX16.0: BOOL;
Dummy0_13 AT %MX17.0: BOOL;
Dummy0_14 AT %MX18.0: BOOL;
Dummy0_15 AT %MX19.0: BOOL;


%MX4.0 ist also Modbus- Adresse 12292, %MX5.0 Adresse 12293.
Problem: normalerweise liegen die bits in einem Wort, also %MX4.0 bis %MX4.15

Die Deklaration sollte so erfolgen:


(* Modbus Adresse 12288

Dummy0_0 AT %MX0.0: BOOL;
Dummy0_1 AT %MX0.1: BOOL;
Dummy0_2 AT %MX0.2: BOOL;
Dummy0_3 AT %MX0.3: BOOL;
Dummy0_4 AT %MX0.4: BOOL;
Dummy0_5 AT %MX0.5: BOOL;
Dummy0_6 AT %MX0.6: BOOL;
Dummy0_7 AT %MX0.7: BOOL;
Dummy0_8 AT %MX0.8: BOOL;
Dummy0_9 AT %MX0.9: BOOL;
Dummy0_10 AT %MX0.10: BOOL;
Dummy0_11 AT %MX0.11: BOOL;
Dummy0_12 AT %MX0.12: BOOL;
Dummy0_13 AT %MX0.13: BOOL;
Dummy0_14 AT %MX0.14: BOOL;
Dummy0_15 AT %MX0.15: BOOL;

Also muß erst der Wert der Adresse eingelesen werden, dann das entsprechende bit oder der Wert des Bits addiert bzw subtrahiert werden,
und dann wieder in die Wago geschrieben werden. Die Lösung über %MX4.0 bis %MX19.0 befriedigt mich nicht und ist Verschwendung von Resourcen.
Werde bald weiter testen, über Kommentare und Hilfe wäre ich sehr erfreut.

Gruß, bytebold
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: bytebold am 27 Oktober 2013, 13:28:45
Wieder ein Stückchen weiter.
Lesen der Modbusadresse und bits setzen und rücksetzen funktioniert nun.

in der Fhem.cfg:

define Garten_Steckdose41 dummy
attr Garten_Steckdose41 room Garten
attr Garten_Steckdose41 setList On Off
attr Garten_Steckdose41 webCmd On:Off

define act_Garten_Steckdose41 notify Garten_Steckdose41 { my $test  = read_modbus_zaehler(12292);; if (Value("Garten_Steckdose41") eq "Off") {write_modbus(12292,$test-1)} else {write_modbus(12292,$test+1)}}

define Garten_Steckdose42 dummy
attr Garten_Steckdose42 room Garten
attr Garten_Steckdose42 setList On Off
attr Garten_Steckdose42 webCmd On:Off

define act_Garten_Steckdose42 notify Garten_Steckdose42 { my $test  = read_modbus_zaehler(12292);; if (Value("Garten_Steckdose42") eq "Off") {write_modbus(12292,$test-2)} else {write_modbus(12292,$test+2)}}

define Garten_Steckdose43 dummy
attr Garten_Steckdose43 room Garten
attr Garten_Steckdose43 setList On Off
attr Garten_Steckdose43 webCmd On:Off

define act_Garten_Steckdose43 notify Garten_Steckdose43 { my $test  = read_modbus_zaehler(12292);; if (Value("Garten_Steckdose43") eq "Off") {write_modbus(12292,$test-4)} else {write_modbus(12292,$test+4)}}

define Garten_Steckdose44 dummy
attr Garten_Steckdose44 room Garten
attr Garten_Steckdose44 setList On Off
attr Garten_Steckdose44 webCmd On:Off

define act_Garten_Steckdose44 notify Garten_Steckdose44 { my $test  = read_modbus_zaehler(12292);; if (Value("Garten_Steckdose44") eq "Off") {write_modbus(12292,$test-8)} else {write_modbus(12292,$test+8)}}

define Garten_Steckdose45 dummy
attr Garten_Steckdose45 room Garten
attr Garten_Steckdose45 setList On Off
attr Garten_Steckdose45 webCmd On:Off

define act_Garten_Steckdose45 notify Garten_Steckdose45 { my $test  = read_modbus_zaehler(12292);; if (Value("Garten_Steckdose45") eq "Off") {write_modbus(12292,$test-16)} else {write_modbus(12292,$test+16)}}


Die nächsten bits haben dann die Werte 32,64,128 usw.

Dazu folgende Deklaration in der Wago:


(* Modbus Adresse 12292 *)
Dummy4_0 AT %MX4.0: BOOL;
Dummy4_1 AT %MX4.1: BOOL;
Dummy4_2 AT %MX4.2: BOOL;
Dummy4_3 AT %MX4.3: BOOL;
Dummy4_4 AT %MX4.4: BOOL;
Dummy4_5 AT %MX4.5: BOOL;
Dummy4_6 AT %MX4.6: BOOL;
Dummy4_7 AT %MX4.7: BOOL;
Dummy4_8 AT %MX4.8: BOOL;
Dummy4_9 AT %MX4.9: BOOL;
Dummy4_10 AT %MX4.10: BOOL;
Dummy4_11 AT %MX4.11: BOOL;
Dummy4_12 AT %MX4.12: BOOL;
Dummy4_13 AT %MX4.13: BOOL;
Dummy4_14 AT %MX4.14: BOOL;
Dummy4_15 AT %MX4.15: BOOL;


So lassen sich nun die bits über Fhem steuern.

Das nächste Problem wird das zyklische Auslesen von Adressen sein. Z.B. Wetterdaten, die die Wago
sammelt müßten nun in Fhem aktualisiert werde. Kann man das irgendwie zyklisch machen ?
Hat da jemand einen Lösungsansatz für mich.
Ich weiß ja nicht, ob hier noch jemand mitliest oder ob ich Einzelkämpfer bin, aber über Kommentare
und Hilfe wäre ich sehr dankbar. Ist schon alles recht mühsam, wenn man keine Ahnung von Perl hat
und mit Fhem anfängt.

Gruß, bytebold
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: bytebold am 27 Oktober 2013, 20:44:25
Habe leider einen Fehler festgestellt.

define Garten_Steckdose41 dummy
attr Garten_Steckdose41 room Garten
attr Garten_Steckdose41 setList On Off
attr Garten_Steckdose41 webCmd On:Off

define act_Garten_Steckdose41 notify Garten_Steckdose41 { my $test  = read_modbus_zaehler(12292);; if (Value("Garten_Steckdose41") eq "Off") {write_modbus(12292,$test-1)} else {write_modbus(12292,$test+1)}}


funktioniert eigentlich, jedoch wenn man öfters auf on oder off drückt wird immer der Wert addiert bzw. subtrahiert, also im obigen Beispiel +1, nochmal on drücken wieder +1.
Das ist Mist. Kann man irgendwie den Zustand des Wertes von Garten_Steckdose41 vor dem Ereignis feststellen ?

Gruß, bytebold
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 27 Oktober 2013, 21:35:36
Hallo,

Du kannst nicht mit Addition oder Subtraktion arbeiten um einzelne Bits zu setzen oder zu löschen. Du musst dazu UND (&) und ODER (|) verwenden:

define act_Garten_Steckdose41 notify Garten_Steckdose41 { my $test  = read_modbus_zaehler(12292);; if (Value("Garten_Steckdose41") eq "Off") {write_modbus(12292,$test & 65534)} else {write_modbus(12292,$test | 1)}}
define act_Garten_Steckdose42 notify Garten_Steckdose42 { my $test  = read_modbus_zaehler(12292);; if (Value("Garten_Steckdose42") eq "Off") {write_modbus(12292,$test & 65533)} else {write_modbus(12292,$test | 2)}}


Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: bytebold am 27 Oktober 2013, 22:36:29
Sehr gut, danke, funktioniert einwandfrei.
Bestimmt gibt's auch eine Möglichkeit, die & Verknüpfung als Dual- Wert anzugeben.
Aber ich will gar nicht so sehr in Perl einsteigen, danke für die konstruktive Hilfe.

Gruß, bytebold
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: lechez am 31 Oktober 2013, 09:35:28
Hallo bytebold,

Entschuldigung das ich bei deinem Thema nicht so mitgeholfen habe. Warum auch immer sind die FHEM E-Mails in einen SPAM Ordner gelandet, den ich nicht mehr so auf dem Radar hatte.

Habe daher deine Fragen nicht mitbekommen. Es hat sich ja schon viel geklärt. Zu deiner Frage:

Das nächste Problem wird das zyklische Auslesen von Adressen sein. Z.B. Wetterdaten, die die Wago
sammelt müßten nun in Fhem aktualisiert werde. Kann man das irgendwie zyklisch machen ?
Hat da jemand einen Lösungsansatz für mich.
Ich weiß ja nicht, ob hier noch jemand mitliest oder ob ich Einzelkämpfer bin, aber über Kommentare
und Hilfe wäre ich sehr dankbar. Ist schon alles recht mühsam, wenn man keine Ahnung von Perl hat
und mit Fhem anfängt.


Ich habe einen Stromzaehler von Count and Care ITZR Zweirichtungszähler. Diesen habe ich mit dem S0 Implusausgang auf die Wago gelegt.
Fhem fragt jetzt zyklisch alle 60 sekunden die Werte aus der Wago ab. Kann man auch einstellen wie oft.

Habe ein Modul umgeschrieben heißt 99_S0.pm (siehe Anhang):

Dies habe ich in fhem.cfg so implementiert:

define S0_Zaehler S0
attr S0_Zaehler delay 60
attr S0_Zaehler delayCounter 4
attr S0_Zaehler loglevel 6
attr S0_Zaehler room Hausanschlussraum
define log_S0_Zaehler FileLog ./log/S0_Zaehler-%Y-%m.log S0_Zaehler:(Zaehler-EVU|Zaehler-Solar|Zaehler-Solar-Einspeisung|Zaehler-Solar-Eigenverbrauch).*
attr log_S0_Zaehler room Plots
define wl_log_Wechselrichter_1 SVG log_Wechselrichter:wl_log_Wechselrichter_1:CURRENT

Somit sehe ich immer aktuell wieviel ich produziere (Zaehler EVU), meinen Eigenverbrauch und vieviel ich einspeise.

Vielleicht hilft dir es weiter. 8)

Gruß
lechez
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: bytebold am 31 Oktober 2013, 11:54:59
Hallo,
danke für Deine Antwort. Aber muß das so kompliziert sein ? Ich glaube, ich fange an, Perl zu hassen.
Gibt es nicht einfach einen Timer, wo man zyklisch was anschmeißen kann ?

define act_Garten_Steckdose41 notify Garten_Steckdose41 { my $test  = read_modbus_zaehler(12292)};

Das Auslesen funktioniert ja, ich müßte das nur irgendwie jede Sekunde anschmeißen und dann in ein Dummy schreiben,
so stelle ich mir das vor. Ich bräuchte ein notify auf einen Timer oder so.

Gruß, bytebold
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 31 Oktober 2013, 14:47:39
Hallo,

Damit wird alle 5 Sekunden der Wert gelesen:

define mw12292 dummy
define at_read_mw12292 at +*00:00:05 {fhem("set mw12292 ".read_modbus_zaehler(12292))}


Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: bytebold am 31 Oktober 2013, 15:37:49
Super, danke.
Das hat mir eine Menge googelei und Zeit erspart. Das macht genau, was ich wollte.


define Temperatur_aussen dummy
attr Temperatur_aussen room Wetter

define at_read_Temperatur_aussen at +*00:00:05 {fhem("set Temperatur_aussen ".read_modbus_zaehler(256)/10)}


Vielen Dank, nochmal.
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: bytebold am 08 November 2013, 15:00:21
Hallo zusammen,

kann mir jemand sagen, wie ich Einheiten z.B. % oder Grad Celsius hinter die Werte bekomme, die ich als Dummy deklariert habe ?

Vieln Dank, Gruß, bytebold.
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 08 November 2013, 18:48:23
Hallo,

Das Attribut stateFormat sollte dabei helfen, z.B.:

attr Temperatur_aussen stateFormat state °C

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: bytebold am 08 November 2013, 19:10:41
Vielen Dank.

Ich denke, Fhem ist eine klasse Sache, aber für Beginner doch sehr schwer zu überschauen.
Das Problem mit den Einheiten z.B. für °C hat mich viel Zeit gekostet, um danach zu googeln
und Foren zu durchsuchen, hab aber nichts gefunden und dennoch ist die Lösung so einfach.

Vielleicht war ich ja auch nur blind......

Gruß, bytebold.
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: Puschel74 am 08 November 2013, 19:22:07
Hallo,

ZitatIch denke, Fhem ist eine klasse Sache, aber für Beginner doch sehr schwer zu überschauen.

Naja. Wenn man gleich eine Wago-SPS in fhem einbinden will trifft das sicher zu  :D
Ich hab meine Wago noch in der Ecke liegen werde sie aber dank Eurer tatkräftigen Arbeit evtl. diesen Winter noch versuchen in FHEM ein zu binden.

Also nicht entmutigen lassen.
Dafür das fhem gratis ist finde ich den Funktionsumfang im Vergleich zu anderen Hausautomatisierungssystemen einfach gigantisch.
Die Menge an Devices die sich einbinden/ansprechen/verwenden lassen ist doch enorm.

Grüße
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: bytebold am 08 November 2013, 22:46:44
Zitat
Naja. Wenn man gleich eine Wago-SPS in fhem einbinden will trifft das sicher zu  :D

Das Problem ist wahrscheinlich, daß nicht alles dokumentiert bzw. zu finden  ist. Einem Dummy eine Einheit zuzuweisen habe ich nicht gefunden.

Aber egal, ich werde weiter mit Fhem testen und hoffen, das ich damit ein System gefunden habe, mit dem ich leben kann.
Bei mir laufen 2 Wagos, eine für Garten, Wetter usw. eine für innen mit Stromverbrauch, Datenbank auf einer NAS usw. Problem ist immer nur die Visualisierung.
Die Wago- Visualisierung könnte man benutzen, man braucht aber Java... und das läuft nicht auf Smartphones. Alternative wäre Microbrowser von
SpiderControl, aber pro Gerät eine Lizenz für 80 € kaufen ist völlig daneben.
WinCCflexible habe ich auch schon mal auf dem PC getestet, läuft aber nur auf PC und nicht auf Smartphones.
Also weiter suchen und testen.

Gruß, bytebold
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: Puschel74 am 08 November 2013, 23:11:27
Hallo,

ZitatWinCCflexible

Siemens weiß wie man Geld verdient  8)
Ok Wer weiß das nicht - nix gegen Siemens.
Jeder muss Leben und sein Geld verdienen.
Ebenso auch Wago und alle Distributoren.

Mit FHEM kannst du alles visualisieren was FHEM empfangen und darstellen kann.
Egal ob das FS20, HM, IT, ... Wago,S7? ist (behaupte ich mal).

Grüße
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: bytebold am 11 November 2013, 21:36:56
ZitatNaja. Wenn man gleich eine Wago-SPS in fhem einbinden will trifft das sicher zu  :D

Naja, ich hab noch anderes vor...... ich habe 2 Wagos laufen, versuch gerade aus beiden auszulesen....
und dann ist da ja noch die MySql- Datenbank, aus der ich gerne Daten  abholen würde.
Aber alles zu seiner Zeit, im Moment habe ich keinen Druck, werde mich bei Problemen rechtzeitig melden,
wenn es nicht nervt.

Gruß, bytebold
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: @MosWare am 12 November 2013, 21:00:45
Hallo zusammen,

ist ja super interessant!

Ich wollte "mal eben" ein Bit in der Wago setzen, scheitere aber schon daran die 99_modbus.pm und MBclient.pm in fhem.cfg einzubinden.
Habe 99_modbus.pm und den MBclient.pm nach /opt/fhem/FHEM kopiert und fhem neu gestartet.
Dann in fhem.cfg folgende Zeilen reingehauen:
define myModbus modbus
attr myModbus write_modbus(12288, 1)


Beim Abspeichern habe ich dann folgende Fehlermeldung:

Cannot load module modbus

Sieht für mich so aus, dass die Definition nicht korrekt ist, oder was mache ich falsch?

Gruß
@MosWare

Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: bytebold am 12 November 2013, 22:17:44
warum versuchst Du das nicht so, wie ich es gemacht habe:

define Garten_Steckdose41 dummy
attr Garten_Steckdose41 room Garten
attr Garten_Steckdose41 setList On Off
attr Garten_Steckdose41 webCmd On:Off

define act_Garten_Steckdose41 notify Garten_Steckdose41 { if (Value("Garten_Steckdose41") eq "Off") {write_modbus(12292,0)} else {write_modbus(12292,1)}}


Kannst ja für Garten_Steckdose41 was anderes eintragen, aber so sollte es funktionieren.

Gruß, bytebold

Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: lechez am 13 November 2013, 07:47:34
[quote author >:(=@MosWare link=topic=12655.msg106906#msg106906 date=1384286445]
Hallo zusammen,

ist ja super interessant!

Ich wollte "mal eben" ein Bit in der Wago setzen, scheitere aber schon daran die 99_modbus.pm und MBclient.pm in fhem.cfg einzubinden.
Habe 99_modbus.pm und den MBclient.pm nach /opt/fhem/FHEM kopiert und fhem neu gestartet.
Dann in fhem.cfg folgende Zeilen reingehauen:
define myModbus modbus
attr myModbus write_modbus(12288, 1)


Beim Abspeichern habe ich dann folgende Fehlermeldung:

Cannot load module modbus

Sieht für mich so aus, dass die Definition nicht korrekt ist, oder was mache ich falsch?

Gruß
@MosWare
[/quote]
Hallo,

Sind die rechte richtig gesetzt?
Gruß
Andre
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: @MosWare am 13 November 2013, 16:52:20
Hallo,

habe unter /opt folgendes eingegeben

sudo chmod -R a+w fhem && sudo usermod -a -G tty pi && sudo usermod -a -G tty fhem

Reichen die Rechte nicht?

Gruß
@MosWare

Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: Puschel74 am 13 November 2013, 17:28:44
Hallo,

was steht im Fhem-LogFile?

Auf welcher Hardware läuft bei dir FHEM? Evtl. fehlt ja ein Perl-Modul.

Grüße
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: @MosWare am 13 November 2013, 17:42:36
Hallo,

fhem läuft bei mir auf dem Raspberry Pi

Im Logfile steht u.a.

2013.11.12 21:13:47 0: Undefined subroutine &main::modbus_Initialize called at fhem.pl line 1777, <$fh> line 68.

die *.pm habe ich hier aus dem Topic.


Gruß
@MosWare
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: @MosWare am 13 November 2013, 20:59:20
Hallo,

habe noch festgestellt, dass nach einem Fhem restart folgendes im Terminal steht.

Subroutine init_modbus redefined at ./FHEM/99_modbus.pm line 16, <$fh> line 68.
Subroutine write_modbus redefined at ./FHEM/99_modbus.pm line 33, <$fh> line 68.
Subroutine read_modbus redefined at ./FHEM/99_modbus.pm line 49, <$fh> line 68.


Unklar ist mir, wo die Definitionen zuvor stattfinden. Im /opt Verzeichnis ist 99_modbus.pm die einzige Datei in der die Definition steht.

Merkwürdig oder?

Gruß
@MosWare
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: bytebold am 13 November 2013, 21:32:57
Ihr scheint ja doch schon mehr Erfahrung mit Fhem zu haben........
aber, wenn ich

define myModbus modbus
attr myModbus write_modbus(12288, 1)


in die Fhem.cfg eingebe, bekomme ich auch die Fehlermeldung:

ERROR:
Cannot load module modbus Please define myModbus first

Wie schon geschrieben, mit den Codezeilen als Dummy funzt das.

Gruß, bytebold
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 13 November 2013, 22:47:59
Hallo,

Das Modbus-Modul kann nicht über define eingebunden werden, es fehlen die nötigen Funktionen. Das Modul wird beim Start von FHEM auch automatisch geladen da sein Name mit 99_ beginnt. Die Funktionen write_modbus und read_modbus müssen direkt über at oder notify aufgerufen werden.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: @MosWare am 13 November 2013, 22:57:31
Hallo,

danke für Deine Antwort.

Da ist ja gut zu wissen. Werd es mal ausprobieren

Gruß
@MosWare
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: bytebold am 13 November 2013, 23:08:55
ZitatDa ist ja gut zu wissen. Werd es mal ausprobieren

Ich weiß nicht, warum Du mich ignorierst, @MosWare, aber das habe ich Dir schon vor 8 Posts vorgeschlagen.

Gruß, bytebold
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: @MosWare am 13 November 2013, 23:16:37
Ich ignoriere Dich nicht.
Sorry, wenn ich was übersehen oder missverstanden habe.
Für Deine Antworten bin ich dankbar.
Habe es ausprobiert und keine Fehlermeldung mehr! Aber das Bit wird nicht gesetzt.

Kann leider Morgen erst weitertesten (habe Frühschicht)

Beste Grüße und vielen Dank
@MosWare


Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: lechez am 14 November 2013, 17:35:33
Hallo,

ich habe schon festgestellt, dass der erste Befehl verschluckt wird nach einem Reststart von Wago oder fhem.

Ich gebe zu das die Implementierung sehr quick and dirty ist.

Vielleicht komme ich ja irgendwann dazu es ordentlich zu machen.

Du kannst den Fehler einkreisen, indem du mit einen Modbus TCP/IP TOOL (Freeware oder 30 Tage Testversion einfach mal googeln) an die Adresse einen Schreibbefehl absetzt. Mit der Wago auf die Adressen schauen, ob diese gesetzt werden.
Wenn das schon nicht geht liegt es nicht an fhem.

Wenn das geht mal Wireshark auf das Protokoll schauen, ob fhem was raussendet.
So habe ich mich auch herangetastet.

Gruß

lechez
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: @MosWare am 14 November 2013, 17:40:29
Hallo zusammen,

wie gesagt habe ich das Beispiel von bytebold getestet und keine Fehlermeldung mehr beim Speichern.
Das Bit wird aber nicht ins Merkerwort geschrieben. (12288 in fhem.cfg angeasst)
Habe dann einen Port-Sniffer (SmartSniff) gestartet und festgestellt, dass der Modbusport 502 von Fhem garnicht geöffnet wird.
99_modbus.pm und den MBclient.pm habe ich zuvor nach /opt/fhem/FHEM kopiert, die IPs angepasst und fhem neu gestartet.

Es scheint nur noch eine Kleinigkeit nicht zu stimmen. kann aber nicht sagen warum der Port nicht geöffnet wird.

Hat da vielleicht noch jemand eine Idee?
Mein Einsteigerwissen ist da völlig am Ende!

Grüße
@MosWare
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: @MosWare am 14 November 2013, 18:00:37
Hallo lechez,

ups, hast ja zwischenzitlich geantwortet.
Auf die Wago kann ich ja mit CoDeSys zugreifen und mir den Merker anschauen.
Aber wie gesagt; der Port wird erst garnicht geöffnet.
Werde mal mit einem VC++ ModBusTestTool von Wago testen.

Gruß
@MosWare
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: bytebold am 18 November 2013, 23:38:02
Ich habe zwischenzeitlich Probleme mit meiner 7270 Fritzbox gehabt, Fhem wurde stetig langsamer.
Nach Restart ging's eine zeitlang, aber die Bedienung wurde immer langsamer, Probleme gab's auch
mit eingehenden Telefongesprächen. Also......Umzug auf die Synology Diskstation 112+.....
und was soll ich sagen, das ist wie ein Unterschied zwischen Tag und Nacht, läuft bis jetzt super flüssig
und sauschnell. Mal schaun, wie das weiter geht.

Gruß, bytebold
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: leibi am 30 November 2013, 20:21:52
Hallo,

ich habes es auch mal probiert, es kommt bei mir dieses im Logfile:
act_Garten_Steckdose41 return value: Too many arguments for main::write_modbus at (eval 32) line 1, near "0)"
Too many arguments for main::write_modbus at (eval 32) line 1, near "1)"

Was bedeutet da?
Wie kann ich die die ModBus-Funktionen (siehe MBclient z.b. write Single coil "funktion5")nutzen, wahrscheinlich in die 99 eintragen.

Währe nett, wenn mir jemand helfen könnte.

Gruß
Markus
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: bytebold am 03 Dezember 2013, 22:19:11
Hallo,

kannst Du bitte mal die Deklarationen für modbus in der fhem.cfg posten ?
Vielen Dank.

Gruß, bytebold
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: leibi am 04 Dezember 2013, 19:42:22
Hallo,

hier noch meine fehm.cfg

define Garten_Steckdose41 dummy
attr Garten_Steckdose41 fp_Grundriss 351,305,2,
attr Garten_Steckdose41 icon black_Steckdose.on
attr Garten_Steckdose41 room Garten
attr Garten_Steckdose41 setList On Off
attr Garten_Steckdose41 webCmd On:Offdefine act_Garten_Steckdose41 notify Garten_Steckdose41 { if (Value("Garten_Steckdose41") eq "Off") {write_modbus(0,0)} else {write_modbus(0,1)}}

Habe schon einiges probiert, es kommt aber, die obige Fehlermeldung.

Gruß
Markus
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: lechez am 05 Dezember 2013, 05:52:44
Hi leibi,

In den runden Klammern kommt als erstes die Modbusadresse. Ist es richtig das die Adresse 0 ist? Die Adresse sollte mit der von der Wago identisch sein.

Gruß
Lechez
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: bytebold am 05 Dezember 2013, 09:19:22
Hallo,

zum Testen würd ich Dir vorschlagen, folgende globale Variablen in der Wago anzulegen:

(* Modbus Adresse 12292 *)
Dummy4_0 AT %MX4.0: BOOL;
Dummy4_1 AT %MX4.1: BOOL;
Dummy4_2 AT %MX4.2: BOOL;
Dummy4_3 AT %MX4.3: BOOL;
Dummy4_4 AT %MX4.4: BOOL;
Dummy4_5 AT %MX4.5: BOOL;
Dummy4_6 AT %MX4.6: BOOL;
Dummy4_7 AT %MX4.7: BOOL;
Dummy4_8 AT %MX4.8: BOOL;


Dann schreibst Du den Wert mit:

define act_Garten_Steckdose41 notify Garten_Steckdose41 { if (Value("Garten_Steckdose41") eq "Off") {write_modbus(12292,0)} else {write_modbus(12292,1)}}


Gruß, bytebold
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: leibi am 05 Dezember 2013, 12:11:03
Hallo,

die Adresse 0 ist schon richtig,(ich verwende keine Wago, sondern eine B&R Sps).
Die Adressen sind von der SPS sowie von der Modbusfunktion(3,4,5,15,16,23) abhängig, ist auch bei Wago so.

Mein Problem ist ja die Fehlermeldung von fhem.

MFG
Marklus
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: bytebold am 05 Dezember 2013, 21:36:51
Hi,

in MBclient.pm wird die Routine

## Modbus function WRITE_SINGLE_REGISTER (0x06).
##   write_single_register(reg_addr, reg_value)
##   return 1 if write success
##          or undef if error


aufgerufen.

Du solltest mal prüfen, ob Du auf Adresse 0 mit FC6 schreiben kannst.

Gruß, bytebold
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: leibi am 06 Dezember 2013, 22:50:47
Hallo,

hab bei mir sogar alles frisch installiert(rasperry+fhem), wieder der gleiche Fehler, funktioniert bei mir nicht.
Mit dem Program Modbus-Poll, geht es.

MFG
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: lechez am 07 Dezember 2013, 05:53:54
Hallo,
überprüfe bitte in 99_Modbus.pm, ob die IP und Port gleich ist mit der in Mobus Poll?
Wie hast du die Register beschrieben 0x05, 0x06 etc...
Gruß
Lechez
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: leibi am 07 Dezember 2013, 11:55:22
Hallo,

egal was ich mache, ich bekomme immer folgende Meldung:
act_Garten_Steckdose41 return value: Too many arguments for main::write_modbus at (eval 16) line 1, near "0)"

Ich denke da fehlt mir was, in der Fhem installation.

Gruß
Markus
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 07 Dezember 2013, 13:33:47
Hallo,

Ich denke du verwendest die ältere Version von 99_modbus.pm aus Beitrag 9 die nur einen Parameter annimmt, nämlich den zu schreibenden Wert. Im Anhang von Beitrag 14 befindet sich eine erweiterte Version in der write_modbus 2 Parameter entgegennimmt, nämlich Adresse und Wert. Damit sollte dein notify nach einem 'reload 99_modbus' dann funktionieren.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: leibi am 08 Dezember 2013, 14:12:49
Hallo,

war wirklich die alte 99_modbus.pm, vielen dank für den Tipp.
Das lesen von analogen PT100 Eingängen funktioniert problemlos.
Nur kann ich keine Ausgänge setzen(mit Funktion 5 und 6), weiß jemand wieviele Parameter ich bei Funktion 16 übergeben muss?
Ich habe mal in der MB_client geschaut, so wie ich das sehe muss ich doch das Register, Byte, Bit, Wert angeben.
Weiß da jemand weiter?

Das mit dem Modbus über fhem, ist echt top.

Gruß
Markus
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 08 Dezember 2013, 18:18:07
Hallo,

Die Funktion 6 (Register schreiben) ist bereits in 99_modbus.pm als write_modbus implementiert. Ein Aufruf von {write_modbus(2,99)} schreibt den Wert 99 ins Register 2.

Die Funktion 5 (Coil schreiben) ist nicht implementiert, sie könnte z.B. so aussehen:
sub
write_modbus_coil($$)
{
  if ($m->write_single_coil($_[0], $_[1])) {
    $m->close();
  } else {
    Log 1, "write error\n $_[0] Wert $_[1]";
    $m = MBclient->new();
    # define server target
    $m->host("192.168.0.250");
    $m->unit_id(1);
  }
}


Der Aufruf {write_modbus_coil(2,1)}setzt das Bit in Coil 2.

Zum Schreiben mehrerer Register (Funktion 16) könnte diese Funktion verwendet werden:
sub
write_modbus_multi($$)
{
  my @data = split(/:/,$_[1]);
 
  if ($m->write_multiple_registers($_[0], \@data)) {
    $m->close();
  } else {
    Log 1, "write error\n $_[0] Wert $_[1]";
    $m = MBclient->new();
    # define server target
    $m->host("192.168.0.250");
    $m->unit_id(1);
  }
}


Der Aufruf von{write_modbus_multi(1,"21:22:23")} schreibt 21 ins Register 1, 22 in 2 und 23 in 3.

Grüße,

ChrisD

Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: leibi am 08 Dezember 2013, 21:40:50
Hallo,

danke für deine Codeschnipsel.
Leider bekomme ich wieder Fehlermeldungen:

act_Garten_Steckdose41 return value: Missing right curly or square bracket at (eval 16) line 2, at end of line
syntax error at (eval 16) line 2, at EOF

Ist bei dem Aufruf: {write_modbus_multi(1,"21:22:23")}, die 1 die Registeradresse?

MFG
Markus
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 08 Dezember 2013, 21:51:08
Hallo,

Kannst du die aktuelle Definition von act_Garten_Steckdose41 posten ? Aus der Fehlermeldung geht nicht hervor wodurch der Fehler auftritt.

Beim Beispiel {write_modbus_multi(1,"21:22:23")} ist 1 die Adresse des ersten Registers welches beschrieben wird (mit 21), die restlichen Werte werden automatisch in die folgenden Register (hier also 2 und 3) geschrieben. Die Syntax ist allgemein: write_modbus_multi(Startregister,"Wert1:Wert2:...:Wertn") wobei der Wert von n vom Server abhängt (maximal 125).

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: leibi am 10 Dezember 2013, 07:01:04
Hallo ChrisD,

vielen dank für deine Hilfe, geht soweit alles.
Nur wenn ich die mehrere Modbus-Funktionen nacheinander benutze, gehen vorherige nicht mehr.
Wie kann ich bei der Funktion 16, im Register einzelne Bits ansprechen?
Kann ich meine eingelesenen Temperaturwerte, auch mit dem PID-Regler verwenden?

Gruß
Markus
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: oniT am 10 Dezember 2013, 20:19:18
Hallo ChrisD,

ich hätte zu diesem Thema auch noch eine Frage. Wenn ich zum Beispiel mit read_modbus_zaehler einen Wert abfrage, dann ist dieser ja ohne Vorzeichen, also ein unit16bit. Ist es auch möglich einen mit Vorzeichen int16bit abzufragen?

Danke,
Gruß
Tino
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 10 Dezember 2013, 22:37:08
@oniT: Beim Modbus sind Register 16 Bit breit, wie diese 16 Bits zu interpretieren sind ist Sache der Anwendung. Beim Lesen von Daten mittels read_modbus_zaehler wird der negative Wert der SPS im 2-Komplement übertragen, aus -1 wird 65535. Mit dieser Funktion kannst du den Wert zurückrechnen:
sub WORD_TO_INT($)
{
  my ($w)=@_;
  $w -= 65536 if $w>32767;
  return $w;
}

z.B.:
{WORD_TO_INT(read_modbus_zaehler(1))}

@leibi: Ich habe den Satz
ZitatNur wenn ich die mehrere Modbus-Funktionen nacheinander benutze, gehen vorherige nicht mehr.
nicht verstanden, kannst du bitte erklären was genau nicht funktioniert ? Hast du Fehlermeldungen im Log ?

Die Funktion 16 ist zum Schreiben mehrerer Register mit jeweils 16 Bit. Unter Perl gibt es keine direkte Möglichkeit Bits anzusprechen, du musst das mittels Masken mit & und | machen:$w |=1<<3; setzt Bit 3 in der Variable $w (die vorher deklariert sein muss),$w &=~(1<<3);löscht Bit 3. Wenn du einzelne Bits übertragen möchtest kannst du die Modbus-Funktionen 5 und 15 benutzen (wenn sie von deinem Modbus-Server unterstützt werden).

ZitatKann ich meine eingelesenen Temperaturwerte, auch mit dem PID-Regler verwenden?
Ja, dazu musst du ein Dummy definieren, die Daten der SPS regelmäßig mittels at einlesen und dem PID das Dummy als Istwert übergeben, z.B.:
define istW dummy
define stellW dummy
define at_read_istW at +*00:01:00 {fhem "set istW ".read_modbus_zaehler(1)}
define PID PID20 istW:state stellW
attr PID desired 25


Grüße,

ChrisD


Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: leibi am 11 Dezember 2013, 07:18:00
Hallo ChrisD,

danke mal wieder für deine Hilfe.
Mein Problem ist wenn ich mit Funktion 5, ein Coil beschreibe(funktioniert), und danach mit Funktion 16 ein anderes Register, funktioniert danach das erste(mit Funktion 5), nicht mehr.
Aber für meine Anwendung reicht eigentlich auch die Funktion 5, also kein Problem.

Gruß
Markus
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: leibi am 11 Dezember 2013, 22:35:01
Hallo,

kann sowas funktionieren?

define temp dummy
attr temp room Garten
define at_read_temp at +*00:00:10 {fhem "set temp ".read_modbus_zaehler(0000)/10}
define act_Garten_temp notify temp {if (Value("temp") < "21") {write_modbus_multi(9216,"0:0:0") else {write_modbus_multi(9216,"4:0:0")}}

Bin halt ein blutiger Anfänger
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 11 Dezember 2013, 22:51:51
Ja, sollte funktionieren, die Zeile
define act_Garten_temp notify temp {if (Value("temp") < "21") {write_modbus_multi(9216,"0:0:0") else {write_modbus_multi(9216,"4:0:0")}}muss von der Syntax her nur leicht geändert werden:
define act_Garten_temp notify temp {if (Value("temp") < 21) {write_modbus_multi(9216,"0:0:0")} else {write_modbus_multi(9216,"4:0:0")}}

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: oniT am 12 Dezember 2013, 15:50:46
Hallo ChrisD,

ok Danke, das habe ich so nicht gewusst. Ich dachte man kann diese Werte direkt abfragen.

Jetzt habe ich jedoch noch ein Problem, wie bekomme diesen dann richtig in ein Device?

Ich dache dies geht dann so:


define dummy_test
define test_abfrage at +*00:01:00 {fhem "set dummy_test ".WORD_TO_INT(read_modbus_zaehler(1))/10}


allerdings geht das nicht. Das wäre dann wohl doch zu einfach ;-)

Danke
Gruß
Tino
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 12 Dezember 2013, 19:50:34
Hallo,

In der Zeiledefine dummy_testfehlt der Typ, so sollte es gehen:define dummy_test dummy

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: oniT am 12 Dezember 2013, 20:57:25
Hallo,

das hatte ich schon mit eingetragen nur nicht mit hier in den Code kopiert. Au weh, mein Fehler. Das war's nicht. Allerdings hatte ich irgendwo eine Klammer zu viel oder zu wenig gesetzt. Jetzt klappt es.


define test_abfrage at +*00:01:00 {fhem "set dummy_test ".WORD_TO_INT(read_modbus_zaehler(1))}


Das ist halt das Problem wenn man dies direkt in fhem einträgt und nicht über einen Editor. Der hätte mir die fehlende Klammer angezeigt ;-)

Danke
Gruß,
Tino
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: leibi am 14 Dezember 2013, 18:05:00
Hallo,

was kann das sein, das nach ein paar Schaltspielen mit der Funktion 5, nichts mehr geht(im  log steht write error?
Lesen von Temperaturwerten funktioniert völlig stabil, nur Ausgänge schreiben macht Probleme.

Hätte jemand einen Tipp? Ich habe einen Raspberry.

MFG
Markus
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 14 Dezember 2013, 19:23:07
Hallo,

Du kannst versuchen den Fehlercode im Log mit auszugeben um so vielleicht herauszufinden was passiert. Dazu kannst du in der Funktion write_modbus_coil die ZeileLog 1, "write error\n $_[0] Wert $_[1]";durchLog 1, "write error $_[0] Wert $_[1], er ".$m->last_error()." ex ".$m->last_except();ersetzen. Bei Schreibfehlern sollte im FHEM-Log Zeilen wie diese auftreten:
Zitat2013.12.14 19:16:17.169 1: write error 1 Wert 1, er 7 ex 1

Ein Liste der Fehler (Wert hinter 'er') und Exceptions (Wert hinter 'ex') findest du im Quellcode von MBclient.pm.

Grüße,

ChrisD

Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: leibi am 14 Dezember 2013, 19:57:55
Hallo,

was bedeutet das:
                                  2013.12.14 19:55:31 1: write error 0 Wert 0, er 7 ex 3

Bin mir da in der MBclient nicht ganz schlüssig.

Markus
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 14 Dezember 2013, 20:56:21
Beim Schreiben des Wertes 0 auf das Coil 0 tratt eine Exception auf, laut der Modbus-Spezifikation bedeutet Exception 3:
ZitatA value contained in the query data field is not an allowable value for the slave.  This indicates a fault in the structure of remainder of a complex request, such as that the implied length is incorrect. It specifically does NOT mean that a data item submitted for storage in a register has a value outside the expectation of the application program, since the MODBUS protocol is unaware of the significance of any particular value of any particular register.
Entweder hat MBclient ein ungültiges Paket zusammengebaut oder dein Server hat es nicht korrekt verstanden. Du kannst die Pakete auf der Console ausgeben lassen, dazu muss du am Anfang von write_modbus_coil (nach dem ersten {)$m->{debug}=1;und am Ende (vor dem letzten })$m->{debug}=0; hinzufügen. Auf der Console sollte dann beim Schreiben u.a. dies stehen:
ZitatTx
[xx xx 00 00 00 05] 01 05 00 00 00
Rx
...
Von Interesse ist hier was nach Rx als Antwort erscheint.

Grüße,

ChrisD

Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: leibi am 15 Dezember 2013, 16:49:40
Hallo,

wenn ich das einfüge geht gar nichts mehr, leider.

Ist der MBClient eigentlich ein Modbus-Slave oder Master, da ja meine SPS sowie die Wago als Slave laufen.
Die Wago kann aber mit dem Baustein Modbus-Master von Codesys auch als solcher betrieben werden.
Falls beide als Slave laufen, kann ich mir vorstellen das das lesen(bei mir z.b. Temperaturwerte) gut klappt, aber das gegenseitige Schreiben wird Probleme machen. Funktioniert bei mir hin und wieder, aber nicht stabil, leider.

Gruß
Markus
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 15 Dezember 2013, 19:26:58
Hallo,

Der Baustein sollte so aussehen:
sub
write_modbus_coil($$)
{
  $m->{debug}=1;
  if ($m->write_single_coil($_[0], $_[1])) {
    $m->close();
  } else {
    Log 1, "write error $_[0] Wert $_[1], er ".$m->last_error()." ex ".$m->last_except();
    $m = MBclient->new();
    # define server target
    $m->host("x.x.x.x");  # hier die IP-Adresse des Servers eintragen
    $m->unit_id(1);
  }
  $m->{debug}=0;
}

Die Begriffe Master und Slave gibt es bei Modbus TCP eigentlich nicht, sie sind für Modbus RTU. Bei Modbus TCP spricht man von Client und Server, dabei entspricht der Client dem Master (!) und der Server dem Slave. Server/Slave sind diejenigen die abgefragt werden, Client/Master sind diejenigen die die Anfragen stellen. Wenn FHEM mit der SPS kommuniziert ist FHEM Client (Master) und die SPS ist Server (Slave).

Ich habe mir nochmal die Modbus-Spzifikation durchgesehen und glaube dass MBclient das Paket falsch zusammengebaut hat. In meinem Beispielpaket (Schreiben von 0 auf Adresse 0) sind nur 5 Bytes Nutzdaten enthalten, es müssten aber 6 sein. Das Feld für den Datenwert muss laut Spezifikation 2 Bytes lang sein, MBclient sendet aber nur 1 Byte. Es ist möglich dass der Server-Baustein in der Wago die Länge nicht auswertet und nur das Datenfeld (muss 0x000 oder 0xff00 sein) überprüft. Dadurch funktioniert das Schreiben abhängig davon was im vorherigen Paket enthalten war.

Versuch mal die Zeile 373 in MBclient von
my $tx_buffer = $self->_mbus_frame(WRITE_SINGLE_COIL, pack("nC", $bit_addr, $bit_value));
in
my $tx_buffer = $self->_mbus_frame(WRITE_SINGLE_COIL, pack("nn", $bit_addr, $bit_value));
zu ändern.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: leibi am 15 Dezember 2013, 20:02:57
Hallo ChrisD,

danke für deine Hilfe, machst du sowas eigentlich beruflich?

Es kommt leider immer noch:
2013.12.15 20:00:38 3: act_Garten_temp return value: 1
2013.12.15 20:00:39 3: act_Garten_Steckdose41 return value: 1
2013.12.15 20:00:39 1: write error 0 Wert 1, er 7 ex 3

MFG
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 15 Dezember 2013, 20:12:52
Hallo,

Die Byte-Order beim Schreiben der 1 ist noch falsch, dazu muss die Zeile 372 in MBclient von
$bit_value = ($bit_value) ? 0xFF : 0;in$bit_value = ($bit_value) ? 0xFF00 : 0;geändert werden. Nach einem reload MBclient sollte es funktionieren.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: leibi am 15 Dezember 2013, 20:35:27
Hi,

jetzt habe ich das :
2013.12.15 20:33:08 3: act_EG_Ausgang1 return value: Undefined subroutine &main::write_single_coil called at (eval 34) line 1.

Wie kann das sein das mir fhem immer selber die Zeile mit webCmd ON:OFF meines Schalters selber löscht?
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 15 Dezember 2013, 20:53:22
Ich habe meinen letzten Post editiert da ich übersehen hatte dass der Byte-Order falsch war. Die Meldung
Zitat2013.12.15 20:33:08 3: act_EG_Ausgang1 return value: Undefined subroutine &main::write_single_coil called at (eval 34) line 1.
kommt wahrscheinlich daher dass beim reload von 99_modbus (oder FHEM Neustart) ein Fehler aufgetreten ist und dadurch alle Funktionen aus der Datei nicht mehr verfügbar sind. In der Logdatei müsste eine entsprechende Meldung zu finden sein (Error:Modul 99_modbus deactivated). In der folgenden Zeile müsste der Fehler stehen.

Wann verschwindet die Zeile mit webCmd ?

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: leibi am 15 Dezember 2013, 21:38:35
Hallo,

die WebCmd wird immer wieder mal gelöscht, beim ausprobieren.

Jetzt geht wieder gar nichts mehr:
2013.12.15 21:35:12 3: at_read_EGTemperatur1: Undefined subroutine &main::read_holding_zaehler called at (eval 53) line 1.

2013.12.15 21:35:15 3: act_EG_Ausgang1 return value: Undefined subroutine &main::write_single_coil called at (eval 54) line 1.

Ich weiss nicht mehr was das sein kann, das Fhem hat bei mir irgendwie ein Eigenleben, es funktioniert erst alles, dann gar nichts mehr.
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 15 Dezember 2013, 21:55:15
Hallo,

Hast du die Meldung 'Error:Modul 99_modbus deactivated' nicht in der Logdatei stehen ? Ich habe meine aktuellen Versionen von 99_modbus und MBclient mal angehängt damit du sie mit deinen vergleichen kannst.

Bei webCmd würde ich den Wert erneut eintragen, Save config anklicken und mit einem Editor überprüfen ob der Wert in fhem.cfg geschrieben wurde.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: leibi am 16 Dezember 2013, 20:33:32
Hallo,

ich gebe es auf, danke für eure Hilfe, es funktioniert bei mir leider nichts.
Habe den Raspberry unf fhem schon zweimal komplett frisch aufgesetzt, Modbus geht dann kurz, dann gar nicht mehr.

Ich steige jetzt auf IP-Symcon um.

Gruß
Markus
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: leibi am 19 Dezember 2013, 07:20:56
Hallo,

ich habe mich nochmals selbst motiviert, und habs nochmal probiert.
Wie ich vermutet habe lags in der WebCmd( groß/klein Schreibung, Kopierfehler), jetzt funktioniert das Schreiben/Lesen über Modbus auf Wago sowie B&R SPS.
Wie kann ich am einfachsten den Schaltzustand über Icon's darstellen, bei meinen Versuchen blieben die SPS Ausgänge ständig gesetzt.?
Kann ich das Ereigniss/Ergebnis von der Modbus Komunikation, einer Variablen(z.b.FS20) übergeben, damit ich hier mit Codeschniebsel aus dem Board weiterkomme?

Gruß
Markus
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 19 Dezember 2013, 22:41:50
Hallo,

Zur Darstellung des Zustandes kannst du ein Dummy verwenden. Den Zustand des digitalen Ausganges kannst du bei Wago direkt über Modbus auslesen, die Ausgänge belegen die Adressen 512 bis 1023. Zum Auslesen der Coils sollte dieser Code funktionieren:
sub
read_modbus_coil($) {
  my $coils = $m->read_coils($_[0], 1) ;
  my $ret="???";
 
  if(defined($coils)) {
    foreach my $coil (@$coils) {
      if ($coil==0) {
        $ret="off";
      } else {
        $ret="on";
      }
    }
    $m->close();
  } else {
    Log 2, "read error address $_[0], er ".$m->last_error()." ex ".$m->last_except();
    $m = MBclient->new();
    # define server target
    $m->host('hier IP-Adresse des Servers eintragen');
    $m->unit_id('hier unit_id eintragen');
  }
  return $ret;
}


Ausgang %Q0.0 sollte sich mit{read_modbus_coil(512)} auslesen lassen. Der Rückgabewert ist on oder off und sollte in FHEM direkt als Glühbirne angezeigt werden. Zum regelmäßigen Auslesen kannst du wieder ein 'at' verwenden, z.B.:
define q0 dummy
define at_read_q0 at +*00:00:05 {fhem "set q0 ".read_modbus_coil(512)}


Zum Schalten des Ausganges kannst du WebCmd verwenden wobei du 1 notify benötigst welches beim Ein- und Ausschalten den Befehl über Modbus sendet, z.B.:
attr q0 webCmd set_off:set_on
define n_set_q0 notify q0:set_. {if($EVENT eq 'set_off') {write_modbus(512,0)} else {write_modbus(512,1)}}
Falls das SPS-Programm den Ausgang jeden Zyklus selbst beschreibt wird dies natürlich nicht funktionieren, in dem Fall musst du über einen Merker fahren.

Wenn du eigene Icons verwenden möchtest kannst du das Attribut devStateIcon verwenden, Informationen dazu gibt es in der Commandref.

Wie die Vorgehensweise bei B&R ist kann ich dir nicht sagen, da ich diese nicht kenne.

Die meisten Codeschnipsel funktionieren auch mit einem Dummy. Du kannst aber auch FS20 anlegen:
define i0 FS20 0000 01
attr i0 dummy 1
define at_read_i0 at +*00:00:05 {fhem "set i0 ".read_modbus_coil(0)}
Die Zahlen hinter FS20 sollten eindeutig sein, Details sind in der Commandref. Schreiben ist mit FS20 schwieriger da set_on/off nicht verwendet werden können.

Damit FHEM sich nicht über ein fehlendes IODev beschwert solltest du zuerst noch einen virtuellen CUL anlegen:
define CUL CUL none 0000
attr CUL dummy 1


Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: leibi am 21 Dezember 2013, 21:30:21
Hallo,

wie kann ich am einfachsten einen Sliderwert, auf ein Modbusregister schreiben?

Ich habe immernoch Probleme die Modbus Befehle mit anderen fehm Befehlen zu kombinieren?

Gruß
Markus
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 22 Dezember 2013, 09:28:41
Hallo,

So könntest du den Slider mit dem Modbus verbinden:
define sl_10 dummy
attr sl_10 setList state:slider,10,1,30
attr sl_10 webCmd state
define n_sl_10 notify sl_10:.* {write_modbus(10,$EVENT)}


Wenn ein Element aus FHEM Daten auf den Modbus schreiben soll musst du dies mit einem notify machen. Das Lesen von Daten muss zyklisch über at gemacht werden.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: leibi am 22 Dezember 2013, 11:06:33
Hallo,

danke genau das hat mir gefehlt, $Event ist eigentlich SPS mässig gesehen, die Übergabe-Variable.

gruß
Markus
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: leibi am 22 Dezember 2013, 17:52:28
Hallo,

kann ich Event auch verwenden, wenn ich ein Log, der "Modbus_Temperatur" erstellen will?

MFG
Markus
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 23 Dezember 2013, 20:46:11
Hallo,

Im Beispiel mit dem Slider enthält $EVENT die ausgewählte Zahl, bei anderen Geräten musst du teilweise $EVTPARTx verwenden. Details dazu gibt es in der CommandRef.

Zum Loggen brauchst du nur ein FileLog zu definieren, $EVENT ist hierbei nicht nötig. Gelesene Daten kannst du, wenn Modbus_Temperatur ein Dummy ist welches über modbus_Read_Zaehler gesetzt wird, z.B. so in ein Filelog bekommen :
define FL_Modbus_Temperatur FileLog ./log/Log_Modbus_Temperatur-%Y%m.log Modbus_Temperatur

Wichtig ist hierbei der letzte Teil (Modbus_Temperatur), dieser legt fest was geloggt werden soll, Details gibt es auch hier in der CommandRef. Bei jedem Setzen von Modbus_Temperatur über at wird ein Wert in der Logdatei abgspeichert. Wenn du nur Werte bei Änderung speichern möchtest musst du das Attribut event-on-change-reading bei Modbus_Temperatur verwenden.

Grüße,

ChrisD

Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: oniT am 29 Dezember 2013, 20:43:35
Hi ChrisD,

seitdem ich die 99_modbus.pm einsetze, habe ich keine disconnects vom HMLan mehr. Mit der Abfrage welche ich zuvor nutzte war dies ständig der Fall. Da ich nun nicht ganz so der Perl Spezi bin hätte ich dazu eine Frage, ob man dieses Modul nicht erweitern kann und die darin bereits eingetragene IP Adresse auslagern könnte und in den Code in die fhem.cfg einfügen kann. Wie man es zum Beispiel mit dem Modul vom Solarview macht. Dies hätte den Vorteil, dass man die 99_modbus.pm für weitere angeschlossene Geräte verwenden könnte.

Danke
Gruß,
Tino
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: lechez am 30 Dezember 2013, 09:13:25
Hallo ChrisD,

ja man kann die IP adresse Port etc. auslagern und dies einbinden. Ich habe das Modul 99_Modbus.pm "quick and dirty" geschrieben, da noch nichts vorhanden war und es erstmal für mich gemacht habe. Da es so aussieht, dass die Nachfrage groß ist. Man kann dazu übergehen das Modul mal "sauber" zu machen. Auch ein Wiki wäre ja nicht schlecht oder?
Vielleicht komme ich noch dazu.

Gruß

lechez. 
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: Blockmove am 30 Dezember 2013, 09:52:45
Ein eigenes Modul für Modbus-Communication wär klasse.
Bin auch gerade in den Anfängen meine Wago mit fhem zu verheiraten.

Gruß und guten Rutsch
Dieter
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 30 Dezember 2013, 10:48:30
Hallo,

Ein eigenes Modul für Modbus-TCP (und UDP ?) wäre sicher die schönste Lösung. Der Aufwand für ein solches Modul ist allerdings ziemlich hoch da die Daten u.a. zyklisch gepollt werden müssen. Da TCP-Verbindungen zu Hängern führen können, die dann z.B. die HMLAN-Kommunikation stören wäre zu überlegen für das Modul Non-Blocking-Aufrufe, ähnlich wie in http://forum.fhem.de/index.php/topic,17804.0.html (http://forum.fhem.de/index.php/topic,17804.0.html) für httputils zu verwenden.

Kurzfristig könnte man das aktuelle Modul leicht überarbeiten und jeder Funktion einen weiteren optionalen Parameter anhängen der entweder die IP-Adresse oder den Namen eines Dummys enthält, z.B.:
define MBMaster_1 dummy
attr MBMaster_1 comment 192.168.123.45:502:1


Aus{read_modbus_zaehler(12288)}würde dann{read_modbus_zaehler(12288,"MBMaster_1")}

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: oniT am 30 Dezember 2013, 13:06:07
Hallo,

grundsätzlich wäre ein komplett eigenes Modul (mit allem drum und dran ;-)) auch nicht schlecht. Mir würde zunächst schon einmal eine solche Umsetzung ausreichen.

Zitat von: ChrisD am 30 Dezember 2013, 10:48:30

define MBMaster_1 dummy
attr MBMaster_1 comment 192.168.123.45:502:1



{read_modbus_zaehler(12288,"MBMaster_1")}


Gruß,
Tino
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 31 Dezember 2013, 12:20:31
Hallo,

Anbei eine neue Version von 99_modbus.pm mit folgenden Änderungen:

- die Parameter des Servers sind nur noch an einer Stelle im Code anzupassen
- die Funktion read_modbus gibt den gelesenen Wert zurück
- die Funktion read_modbus_zaehler fordert die Daten nicht mehr doppelt vom Server an
- die rollade-Funktionen sind entfernt
- write_modbus_coil wandelt intern die Werte on und off in 1 und 0 um, damit funktioniert auch
write_modbus_coil(512,"on")
- alle read und write Funktionen nehmen einen optionalen Parameter an der entweder:
    - die IP-Adresse des Servers enthält, z.B.
      read_modbus(12288,"192.168.12.34")
    - den Namen eines Dummys enthält, in diesem Fall werden im Dummy verschiedene Informationen zur Kommunikation angezeigt, z.B.
      define MBMaster_1 dummy
      attr MBMaster_1 comment 192.168.123.45:502:1
      read_modbus_zaehler(12288,"MBMaster_1")

Das Kommentarfeld hat dabei den Aufbau IP-Adresse:Port:UnitID, wenn einer der Werte fehlt wird er durch den im Code vorgegebenen Wert ersetzt.

Der Code sollte abwärtskompatibel sein.

Grüße,

ChrisD

Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: bk9050 am 01 Januar 2014, 12:48:57
Hallo,

zunächst mal ein Gutes Neues Jahr an alle.

Dann ein sehr großes Dankeschön an ChrisD für die geleistete Arbeit, es erspart mir sehr viel (vor allem in Perl tiefer einzusteigen). Bin erst seit wenigen Tagen hier Mitglied und Besitzer eines Raspberry mit FHEM 5.5. Der Plan ist, die Modbus-Geschichten zur Kommunikation mit meiner Beckhoff BC9000 SPS einzusetzen... wir sind im Geschäft mehr mit Beckhoff als mit WAGO 'verbandelt'. Der BC ist gegenwärtig  für die Licht-, Steckdosen- und Rollo-Steuerung von 3 Räumen zuständig, die Programmierung in ST ist noch nicht ganz abgeschlossen.

Sollte es einen Wiki-Artikel zur Modbus-Kopplung geben, wäre ich bereit mich parallel zu den eigenen Erfolgen (hoffentlich?) da auch einzubringen (Beckhoff-spezifisch).

Frage: Gibt es irgendwann ein Performance-Problem, wenn man viele Einzelbits (bei mir ca. 20-22 Inputs bzw. Outputs) jeweils als getrennte Modbus-Kommunikationsanfragen ausführt? Könnte man das irgendwie cachen (so wie es eine SPS intern auch macht) ?

Danke
Hermann-Josef
(Alias bk9050, von meinem ersten SPS-Projekt)
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 01 Januar 2014, 15:40:31
Hallo,

Einen Wiki-Artikel gibt es noch nicht, lechez hatte dies aber bereits vorgeschlagen.

Das aktuelle Modul ist was die Performance betrifft nicht optimal. Bei jedem Aufruf wird die TCP-Verbindung zum Server aufgebaut, die Anfrage geschickt, auf die Antwort gewartet und die TCP-Verbindung wieder geschlossen. Je nachdem wie schnell deine SPS ist dauert ein solcher Zyklus ein paar 100 ms. Wenn du also 20 Eingänge einzeln einliest wird FHEM für längere Zeit blockiert sein.

Ein Cachen wie bei der SPS ist nicht so einfach da diese am Zyklusanfang alle Eingänge liest und am Zyklusende alle Ausgänge schreibt, bei FHEM gibt es aber keinen Zyklusanfang und Zyklusende.

Wenn die Eingänge aufeinanderfolgend sind kannst du mehrere Eingänge mit dem FC1 auslesen, im Moment gibt es dafür aber keine fertige Funktion in 99_modbus.pm. Das Schreiben mehrere Coils ist über FC15 möglich, dieser ist aber noch nicht einmal in der zugrundeliegenden Datei MBClient.pm implementiert.

Die Kommunikation könntest du in einer getrennten Funktion in 99_myUtils.pm machen, der Ablauf wäre dann z.B.
- aufeinanderfolgende Eingangsdaten mit einer Anfrage lesen (FC1)
- gelesene Daten FHEM-Variablen (dummies) zuweisen und verarbeiten
- Ausgänge schreiben (FC15)

Alternativ kannst du 16 Bits in der SPS in ein Wort zusammenkopieren und dieses mit 'read_modbus' auslesen. Die Daten für die Ausgänge kannst du analog in FHEM in ein Wort packen, mit 'write_modbus' schreiben und im SPS-Programm die einzelnen Bits des Wortes den Ausgängen zuweisen.

Grüße,

ChrisD


Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: leibi am 01 Januar 2014, 21:12:07
Hallo, ein gutes neues Jahr euch allen zusammen!!!

bei mir läuft dank ChrisD die Modbus Geschichte mit Wago sowie B&R SPSen einwandfrei, die meisten werden wie ich wahrscheinlich hauptsächlich an der Visualisierung über Fhem interessiert sein, für die Logik ist die SPS stabiler.
Könnte man zum Anfang mit dem Frontend verstärkt beginnen?

Gruß
Markus
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: oniT am 03 Januar 2014, 18:24:53
Hallo ChrisD,

wenn für die Abfrage jeden Wertes die TCP Verbindung geöffnet und wieder geschlossen werden muss, ist es bei Modbus dann möglich mehrere Register nach öffnen auf einmal abzufragen? Bisher Frage ich fast minütlich ca. 20 Werte ab und habe keine Probleme mit der Performance. Dies merke ich immer daran, wenn der HMLan disconnects bringt ;-) So lange dies nicht der Fall ist gibt es auch keine Probleme.

Ansonsten gutes Modul. Ich habe es zum Testen nun auch mit der neuen Version (IP Adresse über dummy) am Laufen. Bisher ohne Einschränkungen. Ich werde es mal in den kommenden Tagen auf weitere Geräte erweitern und schauen was dabei rauskommt.

Danke

Gruß,
Tino
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: bk9050 am 04 Januar 2014, 08:43:30
Hallo ChrisD,

Danke für Deine Überlegungen und Vorschläge.

Zitat von: ChrisD am 01 Januar 2014, 15:40:31
Wenn die Eingänge aufeinanderfolgend sind kannst du mehrere Eingänge mit dem FC1 auslesen, im Moment gibt es dafür aber keine fertige Funktion in 99_modbus.pm. Das Schreiben mehrere Coils ist über FC15 möglich, dieser ist aber noch nicht einmal in der zugrundeliegenden Datei MBClient.pm implementiert.

Die Kommunikation könntest du in einer getrennten Funktion in 99_myUtils.pm machen, der Ablauf wäre dann z.B.
- aufeinanderfolgende Eingangsdaten mit einer Anfrage lesen (FC1)
- gelesene Daten FHEM-Variablen (dummies) zuweisen und verarbeiten
- Ausgänge schreiben (FC15)

Alternativ kannst du 16 Bits in der SPS in ein Wort zusammenkopieren und dieses mit 'read_modbus' auslesen. Die Daten für die Ausgänge kannst du analog in FHEM in ein Wort packen, mit 'write_modbus' schreiben und im SPS-Programm die einzelnen Bits des Wortes den Ausgängen zuweisen.

OK, mehrere Werte lesen (hier über FC3) habe ich hinbekommen und auch den Zugriff darauf.

Wenn ich es richtig verstanden habe, kann ich mit read_coil() etc. nicht auf den Merker-Bereich zugreifen. Da alle DI/DO der SPS zugeordnet sind, kann ich mit den coil-Funktionen nichts anfangen (korrigiere mich, wenn ich falsch liege).
Ein/Ausmaskieren eines Bits, das geht auch.

Wie mache ich es, dass die vorgeschlagene 99_myUtils.pm die Funktionen in 99_modbus.pm nutzen kann?

use 99_modbus.pm;

verletzt scheinbar wohl Namens-Konventionen für Perl-Module?
Aus irgendwelchen Gründen wird ein minimales (= entsprechend des Template) 99_myUtils.pm bei FHEM zum Editieren angezeigt, 99_modbus.pm taucht da bei mir nicht auf.

Zu guter Letzt, ist es normal, dass sich fhem.pl aufhängt, wenn man einen Perl-Fehler gemacht hat? Es lässt sich dann auch nicht mehr via /etc/init.d/fhem stop stoppen?

Momentan wühle ich mich wieder durch die Beispiele, um eine Art toggle hinzukriegen. Damit soll dem FB in der SPS ein Taster simuliert werden, wenn man das Lampensymbol in FHEM betätigt (ähnlich Eltako Stossstromrelais).

Danke und Grüße
Hermann-Josef
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 04 Januar 2014, 13:58:13
Hallo,

Ich habe das Modul 99_modbus nicht geschrieben sondern lechez. Ihm ist es zu verdanken dass die Kommunikation mit den SPSen möglich ist. Ich habe lediglich einige Änderungen und Ergänzungen vorgenommen.

@Markus: Was meintest du mit
ZitatKönnte man zum Anfang mit dem Frontend verstärkt beginnen?
?

@Tino: Solange es ohne Probleme funktioniert würde ich es nicht ändern. Wenn du die 20 Werte in einer Funktion ausliest und ein Aufruf z.B. 100ms dauert, ist FHEM 2s 'blockiert'. Dies reicht nicht für den Disconnect des HMLAN. Wenn du das Dummy verwendest wird in den Internals des Dummys eine Zeile mit 'packets' angezeigt in der Zeiten stehen.  Wenn alle Werte auf 0 stehen musst du ein 'reload 99_modbus' machen, den Grund dafür habe ich noch nicht gefunden.

Es ist bei ModbusTCP möglich (und laut Spezifikation sogar erwünscht) die Verbindung zu öffnen und bis zum Ende des Clients (FHEM) offen zu lassen. Weiterhin ist es auch erlaubt mehrere Anfragen parallel abzuschicken, ob dies allerdings von den unterschiedlichen SPSen korrekt unterstützt ist weiß ich nicht. Das aktuelle Modul müsste dazu umgebaut werden.

Ich habe das Ganze zu Testzwecken mal als Modul umgebaut das über define deklariert wird. Dies hat verschiedene Vorteile (nur ein Verbindungsaufbau, automatisches Pollen, FHEM wird nicht blockiert bei Timeouts, ...) muss allerdings nach ausgiebig getestet werden.

@Hermann-Josef: Ob und wie du Coils und Register lesen kannst hängt von der Implementierung des Servers ab, wobei hier jeder SPS-Hersteller seine eigene Variante verwendet. Beim BC9000 sollte das Lesen über die Coil-Funktionen aber funktionieren, mit read_coil(16384) würde %M0.0 gelesen.

Um die Modbus-Funktionen in 99_myUtils zu verwenden brauchst du nichts zu tun. FHEM lädt 99_modbus automatisch und damit stehen die Funktioen auch in 99_myUtils zur Verfügung, 'use' ist nicht nötig.

ZitatAus irgendwelchen Gründen wird ein minimales (= entsprechend des Template) 99_myUtils.pm bei FHEM zum Editieren angezeigt, 99_modbus.pm taucht da bei mir nicht auf.
Unter 'Edit Files', 'Own modules and helper files' werden nur Dateien angezeigt die das Wort 'Util' im Namen haben, dies ist bei 99_modbus nicht der Fall.

ZitatZu guter Letzt, ist es normal, dass sich fhem.pl aufhängt, wenn man einen Perl-Fehler gemacht hat? Es lässt sich dann auch nicht mehr via /etc/init.d/fhem stop stoppen?
FHEM hängt sich dabei nicht auf sondern wird vom Perl-Interpreter beendet, dadurch kannst du es auch nicht mehr stoppen. Wenn du 'ps ax' aufrufst sollte der Perl-Prozess nicht mehr laufen. Mittels '/etc/init.d/fhem start' sollte FHEM aber wieder laufen (nachdem der Fehler behoben wurde).

Wenn du einen Taster in FHEM mit einem Dummy simulieren möchtest wäre on-for-timer optimal, nur leider funktioniert dies nicht mit Dummies (vielleicht ein weiterer Grund für ein Modul). Manuell könnte es so gehen:
define T1 dummy
attr T1 webCmd on
define n_T1 notify T1:on {write_modbus_coil(16384,1);;fhem("define a_T1_off at +00:00:01 {write_modbus_coil(16384,0);;;;fhem(\"set T1 off\")}")}

Das Stromstoßrelais würde ich im SPS-Code realisieren (mit z.B. R_TRIG und XOR).

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: Wiliam am 14 Januar 2014, 14:38:43
Hallo,

Versuche schon seit längerem einen Temperaturwert aus der Wago SPS über Modbus in Fhem anzuzeigen.

Die Kommunikation zwischen Wago und Fhem funktioniert mittlerweile und ich bekomme Werte unter Fhem. Jedoch habe ich einige Probleme mit der der Darstellung, bei REAL Werten zeigt mir Fhem nur in der darauffolgenden Modbusadresse einen Wert an (sollte wahrscheinlich am Doppelwort liegen). Wie muß ich diesen Wert abfragen um ihn richtig Darstellen zu können?

Habe mir in der Not eine zweite Lösung überlegt in der ich aus dem REAL ein Integer in der SPS Wandel. Dieser wird nun unter Fhem richtig angezeigt, nur die negativen Werte fangen dann bei 32.767 an und laufen rückwärts.

Um dies zu umgehen, habe ich in der SPS einfach den gemessenen Wert um 100 addiert, so bleibe ich bei der Modebusübergabe im positiven Bereich, nur wie kann man die 100 unter Fhem wieder abziehen?? (habe zusätzlich die Temperatur in der SPS noch mit 100 multipliziert und unter Fhem wieder dividiert (damit ich zwei Nachkommerstellen bekomme), das dividieren Funktioniert wunderbar)

Bin wahrscheinlich mal wieder mit der Kirche um ganze Landkreise gezogen und man hätte das Ganze auch etwas einfacher realisieren können doch die Programmierung unter Fhem ist für eine ungeübten echt schwer.

Hier ist mein Eintrag in der Config:

define Temperatur_aussen dummy
attr Temperatur_aussen room Wetter
define at_read_Temperatur_aussen at +*00:00:05 {fhem("set Temperatur_aussen ".read_modbus_zaehler(12388)/100)}
define FileLog_Temperatur_aussen FileLog ./log/Tes/Temperatur_aussen-%Y.log FileLog_Temperatur_aussen:.*
attr FileLog_Temperatur_aussen logtype temp4:Plot,Temperatur_aussen
attr FileLog_Temperatur_aussen room Temperatur_aussen
define wlTemperatur_aussen SVG FileLog_Temperatur_aussen:temp4:CURRENT
attr wlTemperatur_aussen room Temperatur_aussen


Ich hoffe das meine Beschreibung einigermaßen verständlich ist.


Eventuell kann mir ja jemand weiterhelfen und mir sagen, wo ich die "-100" einsetzen muss damit mein Temperaturwert nicht mehr 100° bei 0° anzeigt.

Gruß
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 14 Januar 2014, 19:13:32
Hallo,

Es gibt 2 Möglichkeiten die REAL-Werte zu übertragen:

- du liest 2 aufeinanderfolgende Modbus-Register und verwandelst diese wieder in REAL, z.B. in der SPS (Wago):
fTest AT %MD0 : REAL;und in FHEM:
define at_read_Temperatur_aussen at +*00:00:05 {fhem("set Temperatur_aussen ".(unpack "f", pack "L", ((read_modbus_zaehler(12289)<<16)+read_modbus_zaehler(12288)))}


- du benutzt Fixpunktzahlen, wie in deinem Beitrag beschrieben. Das Problem mit negativen Zahlen kommt daher dass über Modbus Worte ohne Vorzeichen übertragen werden, umwandeln geht mit:
define at_read_Temperatur_aussen at +*00:00:05 {fhem("set Temperatur_aussen ".(unpack "s", pack "S", read_modbus_zaehler(12388))/100)}wobei die Addition von 100 im SPS-Programm entfernt werden muss.

Wenn du nur die 100 wieder abziehen möchtest geht das mit:
define at_read_Temperatur_aussen at +*00:00:05 {fhem("set Temperatur_aussen ".(read_modbus_zaehler(12388)/100)-100)}

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: Wiliam am 16 Januar 2014, 19:59:45
Juchuuu!!

vielen Dank, für die Mühe, es funktioniert!

Danke Danke Danke,      tolle Sache :) :) :)
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: bytebold am 05 Februar 2014, 16:21:35
Hallo zusammen,

ich bekomme es igendwie nicht hin, abhängig von Bits eines eingelesenen Merkerwortes fhem- Dummies zu setzen.

Ich hole mir einen Wert aus der Wago ab:

fhem("set Wago12293 ".read_modbus_zaehler_indoor(12293))}

Jetzt möchte ich abhängig von bit 3 und bit 4, also Wert 8 und 16 zwei Dummys Kontakt_Gartentor und Kontakt_Garagentor setzen.
Habe jetzt auch schon Stunden damit verbracht, aber mir gelingt es nicht........ mir fehlt leider immer noch ein wenig das Verständnis
fhem- und Perl- Befehle zu mischen.

Sowas geht nicht:
fhem("set Kontakt_Gartentor ".(read_modbus_zaehler_outdoor(12293) && 8))

Sowas habe ich auch mal probiert:

define act_Wago12293 notify Wago12293 {
my $r1 == $value{"Wago12293"};;
my $r2 == 8;;
if ($r1 && $r2 == 8) {
   fhem "set Zustand_Garagentor closed"
} else {
   fhem "set Zustand_Garagentor open"
}
}

 

Hat jemand eine Idee ?

Gruß, bytebold
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 05 Februar 2014, 17:08:51
Hallo,

So könnte es gehen:
fhem("set Kontakt_Gartentor ".((read_modbus_zaehler_outdoor(12293) & 8)?"on":"off"))

Statt 'on' und 'off' kannst du natürlich beliebige andere Texte einsetzen.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: bytebold am 05 Februar 2014, 17:40:12
Hallo,

danke für den Vorschlag, werde ich noch ausprobieren. Ich habe gerade auch noch eine Lösung gefunden. Ist zwar komplizierter, klappt aber.

define Wago12293 dummy

define act_Wago12293 notify Wago12293 {\
my $zahl = Value("Wago12293");;\
my $bitmaske = 0b00001000;;\
if ($zahl & $bitmaske) { fhem ("set Zustand_Garagentor closed") }\
else {fhem ("set Zustand_Garagentor open")}}


Gruß, bytebold
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: bytebold am 08 Februar 2014, 23:18:24
Hallo Chris,

habe Deine Lösung genommen, klappt wunderbar, danke.

Ich würde gerne verstehen, was das "?" macht, habe aber in der Doku nichts gefunden.
Entweder war ich blind oder es ist wirklich nicht dokumentiert.

Gruß, bytebold

Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 09 Februar 2014, 08:30:47
Hallo,

? ist ein Standard-Perl Befehl und wird ternärer Operator genannt. Informationen dazu gibt es u.a. unter http://perldoc.perl.org/perlop.html#Conditional-Operator (http://perldoc.perl.org/perlop.html#Conditional-Operator).

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: qwikser am 25 Februar 2014, 15:55:02
Hi,

erstmal möchte ich danke sagen für dieses Modul und die Funktionen!
Da ich totaler Anfänger im Bereich fhem und 0 Kenntnisse in Perl besitze hänge ich nun ein wenig.
Was ich im Grunde möchte, ist lediglich fhem als Schnittstelle zwischen meiner Wago SPS und Systemen wie zB. MAX!, XBMC, ... nutzen.
SPS seitig habe ich keinerlei Probleme. FHEM rennt auf meinem Syno NAS, MAXLAN funktioniert auch schon.
Das Modbus Modul habe ich auch schon erfolgreich eingebunden. Und Funktionen wie z.B.

define myModbus modbus

define Temperatur_Soll_mw0 dummy
attr Temperatur_Soll_mw0 room Wago
attr Temperatur_Soll_mw0 stateFormat state °C
define at_read_Temperatur_Soll_mw0 at +*00:00:05 {fhem("set Temperatur_Soll_mw0 ".read_modbus_zaehler(12288)/10)}

define Dummy4_0 dummy
attr Dummy4_0 room Wago
attr Dummy4_0 setList On Off
attr Dummy4_0 webCmd On:Off
define act_Dummy4_0 notify Dummy4_0 { my $test  = read_modbus_zaehler(12292);; if (Value("Dummy4_0") eq "Off") {write_modbus(12292,$test & 65534)} else {write_modbus(12292,$test | 1)}}


laufen schon. Kann also einzelne bit`s in die SPS schreiben und word`s aus der SPS lesen.

Wo ich nun hänge ist, was muss ich noch bei dem Dummy4_0 einfügen damit er auch stätig das einzelne Bit`s ausließt?
Wenn ich die Variable in der SPC "umschalte" aktualisiert sich fhem nämlich nicht.

Auch brauche ich noch ein Beispiel wie man ein WORD von fhem in die SPS schreibt.

Vielen Dank im voraus.
MfG.
Daniel
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 25 Februar 2014, 22:14:30
Hallo,

Das Auslesen des Bits ist nicht so einfach. Du kannst zwar mit einem at den Zustand regelmässig lesen:
define at_read_Dummy4_0 at +*00:00:05 {fhem("set Dummy4_0 ".((read_modbus_zaehler(12292) & 1)?"on":"off"))}dies führt aber dazu dass dein notify anschließend ausgeführt wird und der eben gelesene Wert sofort wieder geschrieben wird. Ein Möglichkeit dies zu umgehen ist jedes Mal das notify abzuschalten, den Wert zu lesen und das notify wieder einzuschalten:
define at_read_Dummy4_0 at +*00:00:05 {fhem("attr act_Dummy4_0 disable 1;set Dummy4_0 ".((read_modbus_zaehler(12292) & 1)?"on":"off").";attr act_Dummy4_0 disable 0")}

Die Alternative wäre ein eigenständiges Modul welches das Lesen und Schreiben implementiert.

In fhem gibt es den Datentyp WORD nicht, du kannst aber wie beim Schreiben des Bits auch Zahlen mit write_modbus schreiben.

Grüße,

ChrisD



Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: qwikser am 26 Februar 2014, 09:09:30
Hallo Chris,

danke schon mal für diesen Gedanken anstoß!
Habe nun 2 Dummys angelegt pro BIT. Das genügt mir so um nur Daten hin und her zu schaufeln. :)

define Dummy4_3 dummy
attr Dummy4_3 room Wago
attr Dummy4_3 setList On Off
attr Dummy4_3 webCmd On:Off
define act_Dummy4_3 notify Dummy4_3 { my $test  = read_modbus_zaehler(12292);; if (Value("Dummy4_3") eq "Off") {write_modbus(12292,$test & 65527)} else {write_modbus(12292,$test | 8)}}
define Dummy4_3_x dummy
attr Dummy4_3_x room Wago
define at_read_Dummy4_3_x at +*00:00:02 {fhem("set Dummy4_3_x ".((read_modbus_zaehler(12292) & 8)?"on":"off"))}


Was ich mit dem WORD meinte war folgendes.
So sehen die Sollwerte aus in der Wago:

Temperatur_Soll_mw0 AT %MW0 : WORD;
Temperatur_Soll_mw1 AT %MW1 : WORD;

Und so in der fhem cfg:

define Temperatur_Soll_mw0 dummy
attr Temperatur_Soll_mw0 room Wago
attr Temperatur_Soll_mw0 stateFormat state °C
define at_read_Temperatur_Soll_mw0 at +*00:00:05 {fhem("set Temperatur_Soll_mw0 ".read_modbus_zaehler(12288)/10)}

define Temperatur_Soll_mw1 dummy
attr Temperatur_Soll_mw1 room Wago
attr Temperatur_Soll_mw1 stateFormat state °C
define at_read_Temperatur_Soll_mw1 at +*00:00:05 {fhem("set Temperatur_Soll_mw1 ".read_modbus_zaehler(12289)/10)}


Das funktioniert soweit schon super. Was ich nun noch brauch, ist der Weg zurück. Quasi die IST Temp. von meinem MAX! System in die SPS.

MFG.
Daniel
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: qwikser am 26 Februar 2014, 13:32:53
Hallo,

habe direkt noch eine frage. Habe ich hier vll. einen Fehler drin? ..oder könnte das so funktionieren?

define haustuer_zu_wago dummy
attr haustuer_zu_wago room Wago
define act_haustuer_zu_wago notify MAX_0850c2 { if (Value("STATE") eq "opened") { my $test  = read_modbus_zaehler(12292);; if (Value("haustuer_zu_wago") eq "Off") {write_modbus(12292,$test & 65519)} else {write_modbus(12292,$test | 16)}}}


Landen wollte ich auf diesem BIT in meiner SPS:

Dummy4_4 AT %MX4.4 : BOOL;


Das ist der Magnetkontakt meines MAX! Systems:

define MAX_0850c2 MAX ShutterContact 0850c2
attr MAX_0850c2 alias Flur Haustür
attr MAX_0850c2 icon fts_door_right_open
attr MAX_0850c2 room MAX


Als State gibt dieser die Meldung "closed" oder "opened"

MfG.
Daniel
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 27 Februar 2014, 16:17:13
Hallo,

Die Ist-Temperatur könntest du entweder regelmässig mit
define at_write_Temperatur_Ist_mw10 at +*00:01:00 {write_modbus(12298,ReadingsVal("MAX_Thermostat_1","temperature",0)*10)}
oder über notify übertragen
define n_write_Temperatur_Ist_mw10 notify MAX_Thermostat_1:temperature.* {write_modbus(12298,$EVTPART1*10)}
Die Temperatur wird mit 10 multipliziert an die SPS übertragen so dass das Format deinen SPS-Sollwerten entspricht.

Das notify für den Türkontakt habe ich nicht verstanden. MAX_0850c2 ist der Magnetkontakt und liefert "opened" oder "closed". Die Funktion des Dummys "haustuer_zu_wago" ist mir aber nicht klar.

Wenn du nur den Magnetkontakt übertragen willst reicht
define act_haustuer_zu_wago notify MAX_0850c2:onoff.* {my $test  = read_modbus_zaehler(12292);; if ($EVTPART1 eq "0") {write_modbus(12292,$test & 65519)} else {write_modbus(12292,$test | 16)}}
oder wenn du dir Funktion "write_modbus_coil" verwendest
define act_haustuer_zu_wago notify MAX_0850c2:onoff.* {write_modbus_coil(12356,$EVTPART1)}
12356 ist die Coil-Adresse von MX4.4 (12288+4*16+4).

Du kannst generell das Schreiben (und Lesen) der Bits mit write_modbus_coil (und read_modbus_coil) machen, dadurch entfällt beim Schreiben der Lesevorgang und Maskieren des ganzen Wortes. Die Coil-Adressen bei Wago ergeben sich aus 12288+Wortadresse*16+Bit. Die höchste so ansprechbare Adresse ist %MX1279.15 (=Coil 32767).

Da ich keine MAX-Geräte habe musst du den Code eventuell anpassen.

Grüße,

ChrisD


Edit 01.03.2014 Funktionsaufruf 'write_modbus_zaehler' in 'write_modbus' geändert
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: qwikser am 28 Februar 2014, 22:09:15
Hi,

das mit dem Magnetkontakt funktioniert schon wie eine 1. Danke! ..habe nun auch alles in der fhem.cfg mit Coils gemacht, das finde ich persönlich etwas übersichtlicher.  :)
Anbei nochmal der Code für die, die nach mir das nochmal benötigen:

define Dummy4_3 dummy
attr Dummy4_3 room Wago
define act_Dummy4_3 notify MAX_0850c2:onoff.* {write_modbus_coil(12355,$EVTPART1)}
define Dummy4_3_x dummy
attr Dummy4_3_x room Wago
define at_read_Dummy4_3_x at +*00:00:05 {fhem("set Dummy4_3_x ".((read_modbus_zaehler(12292) & 8)?"on":"off"))}


Das setzten der Ist-Temp funktioniert leider noch nicht. Habe nun schon 2 Stunden rum experimentiert, nur leider ohne Erfolg. :(
Aktuell sieht mein versuch so aus:

define Temperatur_Ist_mw3 dummy
attr Temperatur_Ist_mw3 room Wago
define at_write_Temperatur_Ist_mw3 at +*00:00:05 {write_modbus_zaehler(12291,ReadingsVal("MAX_07e1ea","temperature")*10)}


Auch habe ich versucht, einen Dummy anzulegen um einfach nur so einen Wert zu senden, ging aber auch nicht.

define act_write_Temperatur_Ist_mw3 {write_modbus_zaehler(12291)*10}


Anbei auch mal ein Screenshot (thermo.png) von dem Thermostat in fhem, vll. hilft das ja.

Anbei auch ein Screenshot vom Magnetkontakt (magnet.png). Wollte hierzu fragen, ob es auch möglich ist, den Battery Zustand übertragen wie die Auf/zu Meldung?

Vielen Dank nochmal für die bisherigen Antworten
An alle Karnevals Jecken noch, ALLAF!!  ;D ;D
Daniel
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 01 März 2014, 13:39:44
Hallo,

Das Schreiben funktioniert nicht weil ich einen falschen Funktionsnamen verwendet habe, die Funktion zum Schreiben heißt 'write_modbus' und nicht 'write_modbus_zaehler'. So sollte es funktionieren:
define at_write_Temperatur_Ist_mw3 at +*00:00:05 {write_modbus(12291,ReadingsVal("MAX_07e1ea","temperature",0)*10)}
Bei der Funktion 'ReadingsVal' muss übrigens ein 3. Parameter (Default-Wert wenn Reading nicht existiert) mit angegeben werden.

Den Batteriestatus könntest du so übertragen:
define act_Dummy4_4 notify MAX_0850c2:battery.* {write_modbus_coil(12356,$EVTPART1 eq "ok"?1:0)}
Wenn die Batterie ok ist wird eine 1 übertragen, wenn nicht eine 0.

Grüße,

ChrisD

Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: oniT am 16 März 2014, 21:07:51
Hallo Chris,

mich würde einmal den Ausgang des Tests interessieren. Läuft es mit dem Modul? Würdest Du dieses mir auch zu Testzwecken zur Verfügung stellen?

Zitat von: ChrisD am 04 Januar 2014, 13:58:13

@Tino: Solange es ohne Probleme funktioniert würde ich es nicht ändern. Wenn du die 20 Werte in einer Funktion ausliest und ein Aufruf z.B. 100ms dauert, ist FHEM 2s 'blockiert'. Dies reicht nicht für den Disconnect des HMLAN. Wenn du das Dummy verwendest wird in den Internals des Dummys eine Zeile mit 'packets' angezeigt in der Zeiten stehen.  Wenn alle Werte auf 0 stehen musst du ein 'reload 99_modbus' machen, den Grund dafür habe ich noch nicht gefunden.

Es ist bei ModbusTCP möglich (und laut Spezifikation sogar erwünscht) die Verbindung zu öffnen und bis zum Ende des Clients (FHEM) offen zu lassen. Weiterhin ist es auch erlaubt mehrere Anfragen parallel abzuschicken, ob dies allerdings von den unterschiedlichen SPSen korrekt unterstützt ist weiß ich nicht. Das aktuelle Modul müsste dazu umgebaut werden.

Ich habe das Ganze zu Testzwecken mal als Modul umgebaut das über define deklariert wird. Dies hat verschiedene Vorteile (nur ein Verbindungsaufbau, automatisches Pollen, FHEM wird nicht blockiert bei Timeouts, ...) muss allerdings nach ausgiebig getestet werden.


Danke
Gruß,
Tino
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: Hollo am 18 März 2014, 13:49:55
Ich hänge mich mal hier dran, um nicht gleich einen neuen Thread zu starten.
Natürlich auch auf die Gefahr hin, als Dummuser gleich gesteinigt zu werden...

Ich habe seit Kurzem FHEM als "gemeinsame Oberfläche" für verschiedene "Einzelsachen" installiert; dafür ist es meines Erachtens auch gedacht.

Jetzt möchte ich gerne einen Wago 750-342 (Ethernet-Koppler, Modbus, keine programmierbare SPS) einbinden.
Dafür benötige ich doch auch die Modbus-Einbindung... wer kann mir da weiterhelfen?
Ziel soll es sein, dass ich digitale und analoge I/Os bidirectional setzen, lesen, auswerten kann; und diese dann im FHEM entsprechend verknüpfen kann.

Gruß,
Hollo
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 18 März 2014, 19:50:18
Hallo,

@Tino: Ich habe das Modul (in Wirklichkeit 2) seit längerem mit dem was ich benötige am Laufen. Es fehlen allerdings noch einige Sachen (Dokumentation, Coils, Leseaufträge zusammenfassen). Anbei mein aktueller Stand. Zum Testen sollte dies mit Wago-SPSen funktionieren:
define MB_Test ModbusTCPServer 192.168.78.250
attr MB_Test pollIntervall 0.1
define MW0 ModbusRegister 0 12288

Bei der Definition des Registers muss zuerst die UnitID (bei Wago immer 0) und dann die Adresse (hier 12288 für MW0) angegeben werden.

Eine kurze Erklärung der Attribute:

IODev - legt fest welcher ModbusTCPServer verwendet wird, wenn nur einer definiert ist, wird er automatisch gesetzt, wenn es bereits mehrere gibt muss überprüft werden ob der richtige zugewiesen wurde

plcDataType - gibt den Datentyp auf der SPS an und konvertiert die gelesenen Daten automatisch (getestet mit diversen Codesys Steuerungen, zumindest INT sollte aber mit allen Steuerungen funktionieren)

updateIntervall - wie häufig der Wert gelesen wird, Angabe in s, wenn das Attribut nicht existiert wird 100ms (=0.1) verwendet

conversion - Umrechnungsfaktoren für den gelesenen (und von plcDataType angepassten) Wert, Format: a:b, mit state = a * gelesener Wert + b, z.B. 0.1:0 für die Umrechnung von Fixpunktwerten (SPS) in Fliesskomazahlen (FHEM)

@Hollo: Du kannst den Koppler mit den Funktionen aus 99_Modbus.pm verwenden, die aktuelle Version hängt an Beitrag 99. Die Anbindung an FHEM musst du dir aber damit selbst zusammenbauen da es keine fertigen Module gibt. Die beigefügten Test-Module könntest du verwenden um analoge I/Os zu lesen und schreiben.

Grüße,

ChrisD

Edit: Die aktuellen Versionen der Module sind unter https://github.com/ChrisD70/FHEM-Modules (https://github.com/ChrisD70/FHEM-Modules) zu finden.
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: qwikser am 18 März 2014, 21:02:05
Hi Chris,

danke nochmals für deine bisherigen Antworten!! :) Habe nun mein gesamtes MAX! Heizungssystem über fhem an meine Wago SPS weitergeleitet, funktioniert tadellos.
Habe aber noch eine kurze Frage.

Das hier ist die Übertragung der Batterie Meldung an die SPS, mit auslesen des Wertes.

define stellmotor_battery_buero dummy
attr stellmotor_battery_buero group Büro
attr stellmotor_battery_buero room Wago
attr stellmotor_battery_buero setList On Off
define act_stellmotor_battery_buero notify MAX_0850c2:battery.* {write_modbus_coil(12768,$EVTPART1 eq "ok"?1:0)}
define at_read_stellmotor_battery_buero at +*00:00:30 {fhem("set stellmotor_battery_buero ".((read_modbus_zaehler(12318) & 1)?"on":"off"))}

..das funktioniert auch ohne Probleme.

Was ich nun wissen wollte, gibt es auch den Befehl "read_modbus_coil" ???
Und wäre das hier dann richtig?

define at_read_stellmotor_battery_buero at +*00:00:30 {fhem("set stellmotor_battery_buero ".((read_modbus_coil(12768))?"on":"off"))}


Vielen Dank nochmal!  ;D
MfG.
Daniel
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 18 März 2014, 21:49:53
Hallo,

Es gibt in 99_modbus die Funktion read_modbus_coil. Diese wandelt von sich aus bereits 0 in off und 1 in on um, das Lesen sollte also so funktionieren:

define at_read_stellmotor_battery_buero at +*00:00:30 {fhem("set stellmotor_battery_buero ".read_modbus_coil(12768))}

In der Funktion ist aber noch ein Log-Aufruf enthalten der dazu führt dass bei jedem Aufruf von read_modbus_coil eine Zeile in die FHEM-Logdatei geschrieben wird. Um dies abzuschalten muss in der Datei 99_modbus.pm die Zeile 164 mit
    Log 0,"Modbus read from coil $reg, value @$coils[0]";
entfernt werden.

Grüße,

ChrisD

Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: qwikser am 19 März 2014, 18:32:16
Hi,

das funktioniert ja wunderbar mit den Coils. :) Wenn ich nun dem Status z.B. ein Offen/Geschlossen mitgeben möchte anstatt dem On/Off. Dachte ich mir das das so funktionieren würde, leider steht im Status immer nur "Offen".

define at_read_fenster_aufzu_schlafzimmer at +*00:00:30 {fhem("set fenster_aufzu_schlafzimmer ".((read_modbus_coil(12955))?"Offen":"Geschlossen"))}

Meine Idee war es, es aus dieser Zeile abzuleiten.

define at_read_fenster_battery_schlafzimmer at +*00:00:30 {fhem("set fenster_battery_schlafzimmer ".((read_modbus_zaehler(12329) & 4096)?"Batterie_OK":"Batterie_Leer"))}


MfG.
Daniel
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 19 März 2014, 19:13:53
Hallo,

Da read_modbus_coil 'on' und 'off' zurückgibt funktioniert die Abfrage so leider nicht. Folgendes sollte aber gehen:
define at_read_fenster_aufzu_schlafzimmer at +*00:00:30 {fhem("set fenster_aufzu_schlafzimmer ".((read_modbus_coil(12955) eq "on")?"Offen":"Geschlossen"))}

Ich könnte read_modbus_coil so erweitern dass beliebige Werte für 0 und 1 zurückgegeben werden, der Aufruf könnte dann z.B. so aussehen:

define at_read_fenster_aufzu_schlafzimmer at +*00:00:30 {fhem("set fenster_aufzu_schlafzimmer ".read_modbus_coil(12955,"Geschlossen","Offen"))}

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: oniT am 02 April 2014, 21:23:34
Hallo Chris,

ah ok. Danke für die Antwort. Ich hätte gehofft das Du schon dazu gekommen bist es so umzubauen, dass man bei einer Anfrage nur einmal die Verbindung öffnen muss. Ist dann wohl noch nicht der Fall.

Bitte melde Dich doch hierzu wenn Du irgendwann dies so umsetzen konntest.

Danke und Grüße,
Tino
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 02 April 2014, 23:01:35
Hallo,

Die Verbindung zum Server wird nur einmalig aufgebaut und dann offengehalten. Alle Lese- und Schreibaufträge werden dann über die offene Verbindung gesendet. Im Gegensatz zu 99_modbus.pm wird also nicht mehr bei jedem Lese-/Schreibauftrag die Verbindung geöffnet und geschlossen. Weiterhin wird auch nicht mehr gewartet bis die Antwort des Servers eintrifft (und FHEM damit blockiert). Sobald ein Antwort eintrifft wird dies von FHEM über DevIO dem Modul signalisiert und die empfangenen Daten werden verarbeitet. Was im Moment nicht implementiert ist ist das Zusammenfassen von mehrere Aufträgen, wenn du z.B. MW0 und MW1 lesen möchtest werden 2 Anfragen geschickt statt nur einer. Dies wäre besonders für Coils interessant, ich bin aber noch nicht dazu gekommen dies umzusetzen. Ich weiß auch nicht ob es überhaupt Bedarf an Coils und einer solchen Optimierung gibt.

Das Lesen von Daten mit den neuen Modulen erfolgt automatisch, zusätzliche 'at's o.ä. Konstrukte sind nicht mehr nötig. Die 3 Zeilen aus Beitrag vom 18.03. reichen aus. Zum Schreiben reicht einset MW0 1234

Grüße,

ChrisD

Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: fischle am 02 Mai 2014, 09:56:20
Hallo Chris,
wie viel Aufwand ist es denn, die Funktion so zu erweitern, dass ich damit auch über die serielle Schnittstelle (RS485) Geräte auslesen kann? Ich habe hier einen Stromzähler, der sich über Modbus (RS485) auslesen lässt. Den würde ich sehr gerne mit Hilfe deines Moduls auslesen. Meinst du, du kannst soetwas noch ergänzen oder mir ggf. gute Tipps geben, welche Funktionen ich bearbeiten muss?

Gruß

Fabian
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: golem am 02 Mai 2014, 14:59:52
Hallo Chris,


so einen Stromzähler habe ich auch noch.  Interesse also auch von mir.
Tcp und seriell sollten sich ja mit dem IODev lecht realisieren lassen.
Gruß Denis
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 03 Mai 2014, 15:50:23
Hallo,

Ich hatte ursprünglich die Funktionen auf 2 Module aufgeteilt um so auch Modbus RTU unterstützen zu können. Ich habe mir jetzt die Spezifikation zu Modbus RTU nochmal genauer angesehen und versucht sie im beiliegenden Modul umzusetzen. Das Modul habe ich allerdings lediglich mit einem Simulator testen können da ich im Moment keine Hardware mit Modbus RTU habe. Im Modul fehlen auch noch verschiedene Sachen um die Spezifikation einzuhalten:
- die Parität wird nicht überprüft
- das Timing wird nicht überwacht, hierbei müssen Zeiten im 1-stelligen ms-Bereich eingehalten werden was mit FHEM nicht ganz einfach ist
- Diagnosefunktionen

Zusätzlich zu diesem Modul wird noch das Modul 37_ModbusRegister.pm aus Beitrag 123 benötigt.

Die Definition sieht so aus:
define MB_RTU ModbusRTU /dev/ttyACM0
attr MB_RTU pollIntervall 0.1


Optional kann die Geschwindigkeit mit angegeben werden:
define MB_RTU ModbusRTU /dev/ttyACM0@19200

Die Schnittstelle wird mit 8E1 geöffnet, falls die Slaves andere Parameter benötigen können diese über ein Attribut gesetzt werden:
attr MB_RTU charformat 8N2
Wenn an einem Bus mehrere Slaves hängen müssen diese mit der gleichen Geschwindigkeit und den gleichen Parametern betrieben werden.

Anschließend können die Register definiert werden (z.B. für Slave 1):
define Reg0 ModbusRegister 1 0
define Reg20 ModbusRegister 1 20
define Reg25 ModbusRegister 1 25


Das IODev wird dabei automatisch zugewiesen. Wenn mehrere ModbusRTU oder ModbusTCP-Geräte definiert sind muss aber überprüft werden ob die Zuordnung passt.

Wichtig: Im Gegensatz zum ModbusTCP-Modul ist dieses Modul nur kurz getestet worden (und das auch nur unter Windows).

Grüße,

ChrisD

Edit 05.05.2014, Anhang gelöscht, aktuelle Version in folgenden Beiträgen
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: fischle am 04 Mai 2014, 21:47:41
Hallo Chris,
ich habe mich nun mal daran gemacht, das Modul zu testen, auch erst mal unter Windows .

Hier meine Config define MB_RTU ModbusRTU com9@9600
attr MB_RTU pollIntervall 20
attr MB_RTU charformat 8N1

define Reg0 ModbusRegister 1 30001


Was ich nun noch nicht gefunden habe ist, wie ich andere Registertypen auslesen kann? Ich würde gerne die Adresse 30001 (Adresse 0 im Input register bereich lesen). Was muss ich machen um den Funktionscode von 03 auf 04 zu ändern. Ist der fest hinterlegt oder kann der per define geändert werden?

Vielen Dank für die schnelle Reaktion.

Fabian
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 04 Mai 2014, 22:54:03
Hallo,

Das Modul aus Beitrag 123 kann nur FC 3 verwenden und macht auch keinen Unterschied zwischen Input und Holding da es ursprünglich für Wago-SPSen entwickelt wurde. Ich habe das Modul jetzt so erweitert dass es folgendes Mapping von Registern zu Adressen und Bereichen vornimmt:

Register 0-30000 -> Adresse 0-29999 im Holdingbereich
Register 30001-39999 -> Adresse 0-9998 im Inputbereich
Register 40000 -> Adresse 39999 im Holdingbereich
Register 40001-49999 -> Adresse 0-9998 im Holdingbereich
Register 50000-65535 -> Adresse 50000-65535 im Holdingbereich

Dieses Verhalten kann über das Attribut 'disableRegisterMapping' abgeschaltet werden. In dem Fall werden die Register 1:1 auf die Adressen im Holdingbereich abgebildet (wie bisher). Zusätzlich ist es dann möglich über das Attribut 'registerType' alle Zugriffe 1:1 auf den Inputbereich umzuleiten. Das Attribut 'registerType' wird nur ausgewertet wenn 'disableRegisterMapping' auf 1 steht.

Grüße,

ChrisD

Edit 05.05.2014, Anhang gelöscht, aktuelle Version in folgenden Beiträgen
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: golem am 05 Mai 2014, 10:34:40
Hallo,

Modbus TCP scheint zu funktionieren, habe aber noch das Problem, das im den PAC3200 von Siemens die Werte als BigEndian übertragen werden sind.

Wenn ich über RTU versuche ein Register zu lesen mit Folgender Config:

define MB_RTU ModbusRTU com6@9600
attr MB_RTU charformat 8N1
attr MB_RTU pollIntervall 5
attr MB_RTU verbose 5

define MB_RTU_L1_Volt ModbusRegister 1 30026
attr MB_RTU_L1_Volt IODev MB_RTU
attr MB_RTU_L1_Volt plcDataType REAL
attr MB_RTU_L1_Volt verbose 5


erhalte ich an der Kommandozeile die Ausgabe:
perl fhem.pl fhem.cfg
Use of uninitialized value $found[0] in string eq at fhem.pl line 2955.
Use of uninitialized value $dump[5] in concatenation (.) or string at ./FHEM/36_
ModbusRTU.pm line 587.
Use of uninitialized value within @dump in join or string at ./FHEM/36_ModbusRTU
.pm line 589.
Use of uninitialized value within @dump in join or string at ./FHEM/36_ModbusRTU
.pm line 589.
Use of uninitialized value within @dump in join or string at ./FHEM/36_ModbusRTU
.pm line 589.
Use of uninitialized value $found[0] in string eq at fhem.pl line 2955.
Use of uninitialized value $dump[5] in concatenation (.) or string at ./FHEM/36_
ModbusRTU.pm line 587.
Use of uninitialized value within @dump in join or string at ./FHEM/36_ModbusRTU
.pm line 589.
Use of uninitialized value within @dump in join or string at ./FHEM/36_ModbusRTU
.pm line 589.
Use of uninitialized value within @dump in join or string at ./FHEM/36_ModbusRTU
.pm line 589.
Use of uninitialized value within @dump in join or string at ./FHEM/36_ModbusRTU
.pm line 589.
Use of uninitialized value $found[0] in string eq at fhem.pl line 2955.
Use of uninitialized value $found[0] in string eq at fhem.pl line 2955.
Use of uninitialized value $found[0] in string eq at fhem.pl line 2955.
Use of uninitialized value $found[0] in string eq at fhem.pl line 2955.
Use of uninitialized value $found[0] in string eq at fhem.pl line 2955.
Use of uninitialized value $found[0] in string eq at fhem.pl line 2955.
Use of uninitialized value $found[0] in string eq at fhem.pl line 2955.


und im Log folgendes:
2014.05.05 10:29:57 1: starting in console mode
2014.05.05 10:29:57 1: Including fhem.cfg
2014.05.05 10:29:57 3: telnetPort: port 7072 opened
2014.05.05 10:29:58 3: WEB: port 8083 opened
2014.05.05 10:29:58 3: WEBphone: port 8084 opened
2014.05.05 10:29:58 3: WEBtablet: port 8085 opened
2014.05.05 10:29:58 2: eventTypes: loaded 0 events from ./log/eventTypes.txt
2014.05.05 10:29:58 3: MB_RTU_L1_Volt: I/O device is MB_RTU
2014.05.05 10:29:58 1: Including ./log/fhem.save
2014.05.05 10:29:58 1: statefile: Please define MB_TCP first
Please define MB_TCP_L1_Volt first
Please define MB_TCP_L1_Volt first
2014.05.05 10:29:58 3: Opening MB_RTU device com6
2014.05.05 10:29:58 3: Setting MB_RTU baudrate to 9600
2014.05.05 10:29:58 3: MB_RTU device opened
2014.05.05 10:29:58 2: SecurityCheck:  WEB,WEBphone,WEBtablet has no basicAuth attribute. telnetPort has no password/globalpassword attribute.  Restart fhem for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2014.05.05 10:29:58 0: Server started with 10 defined entities (version $Id: fhem.pl 5238 2014-03-16 16:23:31Z rudolfkoenig $, os MSWin32, user denis.goletz, pid 5528)
2014.05.05 10:29:58 5: AddRQueue [01 04 00 19 00 02] A0 0C
2014.05.05 10:29:58 5: SimpleWrite [01 04 00 19 00 02] A0 0C
2014.05.05 10:29:58 5: Read [01 04 04 00 00 00] 00 FB 84
2014.05.05 10:29:58 5: Received [01 04 04 00 00 00] 00 FB 84
2014.05.05 10:29:58 5: MB_RTU dispatch ModbusRegister:1:25:4:2:0:0
2014.05.05 10:29:58 5: ModbusRegister_Parse: 1 25
2014.05.05 10:29:58 2: ModbusRegister_Parse: invalid address 1 25
2014.05.05 10:30:03 5: AddRQueue [01 04 00 19 00 02] A0 0C
2014.05.05 10:30:03 5: SimpleWrite [01 04 00 19 00 02] A0 0C
2014.05.05 10:30:03 5: Read [01 04 04 00 00 00] 00
2014.05.05 10:30:03 5: Read [FB 84    ]
2014.05.05 10:30:08 5: AddRQueue [01 04 00 19 00 02] A0 0C
2014.05.05 10:30:08 5: SimpleWrite [01 04 00 19 00 02] A0 0C
2014.05.05 10:30:08 5: Read [01 04 04 00 00 00] 00 FB 84
2014.05.05 10:30:08 5: Received [01 04 04 00 00 00] 00 FB 84
2014.05.05 10:30:08 5: MB_RTU dispatch ModbusRegister:1:25:4:2:0:0
2014.05.05 10:30:08 5: ModbusRegister_Parse: 1 25
2014.05.05 10:30:08 2: ModbusRegister_Parse: invalid address 1 25
2014.05.05 10:30:13 5: AddRQueue [01 04 00 19 00 02] A0 0C
2014.05.05 10:30:13 5: SimpleWrite [01 04 00 19 00 02] A0 0C
2014.05.05 10:30:13 5: Read [01 04 04 00 00 00] 00 FB
2014.05.05 10:30:13 5: Read [84     ]
2014.05.05 10:30:18 5: AddRQueue [01 04 00 19 00 02] A0 0C
2014.05.05 10:30:18 5: SimpleWrite [01 04 00 19 00 02] A0 0C
2014.05.05 10:30:18 5: Read [01 04 04 00 00 00] 00 FB 84
2014.05.05 10:30:18 5: Received [01 04 04 00 00 00] 00 FB 84
2014.05.05 10:30:18 5: MB_RTU dispatch ModbusRegister:1:25:4:2:0:0
2014.05.05 10:30:18 5: ModbusRegister_Parse: 1 25
2014.05.05 10:30:18 2: ModbusRegister_Parse: invalid address 1 25
2014.05.05 10:30:23 5: AddRQueue [01 04 00 19 00 02] A0 0C
2014.05.05 10:30:23 5: SimpleWrite [01 04 00 19 00 02] A0 0C
2014.05.05 10:30:23 5: Read [01 04 04 00 00 00] 00 FB 84
2014.05.05 10:30:23 5: Received [01 04 04 00 00 00] 00 FB 84
2014.05.05 10:30:23 5: MB_RTU dispatch ModbusRegister:1:25:4:2:0:0
2014.05.05 10:30:23 5: ModbusRegister_Parse: 1 25
2014.05.05 10:30:23 2: ModbusRegister_Parse: invalid address 1 25
2014.05.05 10:30:28 5: AddRQueue [01 04 00 19 00 02] A0 0C
2014.05.05 10:30:28 5: SimpleWrite [01 04 00 19 00 02] A0 0C
2014.05.05 10:30:28 5: Read [01 04 04 00 00 00] 00 FB 84
2014.05.05 10:30:28 5: Received [01 04 04 00 00 00] 00 FB 84
2014.05.05 10:30:28 5: MB_RTU dispatch ModbusRegister:1:25:4:2:0:0
2014.05.05 10:30:28 5: ModbusRegister_Parse: 1 25
2014.05.05 10:30:28 2: ModbusRegister_Parse: invalid address 1 25
2014.05.05 10:30:33 5: AddRQueue [01 04 00 19 00 02] A0 0C
2014.05.05 10:30:33 5: SimpleWrite [01 04 00 19 00 02] A0 0C
2014.05.05 10:30:33 5: Read [01 04 04 00 00 00] 00 FB 84
2014.05.05 10:30:33 5: Received [01 04 04 00 00 00] 00 FB 84
2014.05.05 10:30:33 5: MB_RTU dispatch ModbusRegister:1:25:4:2:0:0
2014.05.05 10:30:33 5: ModbusRegister_Parse: 1 25
2014.05.05 10:30:33 2: ModbusRegister_Parse: invalid address 1 25
2014.05.05 10:30:38 5: AddRQueue [01 04 00 19 00 02] A0 0C
2014.05.05 10:30:38 5: SimpleWrite [01 04 00 19 00 02] A0 0C
2014.05.05 10:30:38 5: Read [01 04 04 00 00 00] 00 FB 84
2014.05.05 10:30:38 5: Received [01 04 04 00 00 00] 00 FB 84
2014.05.05 10:30:38 5: MB_RTU dispatch ModbusRegister:1:25:4:2:0:0
2014.05.05 10:30:38 5: ModbusRegister_Parse: 1 25
2014.05.05 10:30:38 2: ModbusRegister_Parse: invalid address 1 25
2014.05.05 10:30:43 5: AddRQueue [01 04 00 19 00 02] A0 0C
2014.05.05 10:30:43 5: SimpleWrite [01 04 00 19 00 02] A0 0C
2014.05.05 10:30:43 5: Read [01 04 04 00 00 00] 00 FB 84
2014.05.05 10:30:43 5: Received [01 04 04 00 00 00] 00 FB 84
2014.05.05 10:30:43 5: MB_RTU dispatch ModbusRegister:1:25:4:2:0:0
2014.05.05 10:30:43 5: ModbusRegister_Parse: 1 25
2014.05.05 10:30:43 2: ModbusRegister_Parse: invalid address 1 25
2014.05.05 10:30:48 5: AddRQueue [01 04 00 19 00 02] A0 0C
2014.05.05 10:30:48 5: SimpleWrite [01 04 00 19 00 02] A0 0C
2014.05.05 10:30:48 5: Read [01 04 04 00 00 00] 00 FB 84
2014.05.05 10:30:48 5: Received [01 04 04 00 00 00] 00 FB 84
2014.05.05 10:30:48 5: MB_RTU dispatch ModbusRegister:1:25:4:2:0:0
2014.05.05 10:30:48 5: ModbusRegister_Parse: 1 25
2014.05.05 10:30:48 2: ModbusRegister_Parse: invalid address 1 25


Gruß Denis
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 05 Mai 2014, 21:21:37
Hallo,

@Denis

Danke für deine Tests.

Ich hatte die neue Version leider nur mit Modbus TCP getestet so dass mir nicht aufgefallen war dass meine Änderungen mit Modbus RTU zu Fehlern führen. Ich habe jetzt die 3 Module aneinander angepasst so dass wieder alles funktionieren sollte. Kannst du sie bitte ausprobieren?

Was das Problem mit Little/BigEndian betrifft bräuchte ich weitere Informationen:
Tritt das Problem auch bei einzelnen Worten (plcDataType nicht definiert oder WORD) auf ?
Falls dem nicht so ist kann ich FLOAT, DWORD und DINT erweiteren so dass Lo-Word und Hi-Word getauscht werden. Ich habe ein zusätzliches Reading 'RAW' hinzugefügt, kannst du mir dieses bei 'verdrehten' Zahlen mit angeben ?

Der plcDataType FLOAT ist im Moment nur mit CoDeSys-Steuerungen getestet und setzt voraus dass die Zahl SPS-intern im IEEE754-Single-Format vorliegt.

@Alle

Ich habe die alten Versionen aus den vorherigen Posts entfernt da sie u.U. nicht korrekt funktionieren.

Grüße,

ChrisD

Edit: Die aktuellen Versionen der Module sind unter https://github.com/ChrisD70/FHEM-Modules (https://github.com/ChrisD70/FHEM-Modules) zu finden.
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: fischle am 05 Mai 2014, 23:44:29
Hallo,
ich hab das Modul mal weiter getestet.

Ich habe immer die Fehlermeldung erhalten, "Undefined subroutine &bytes::length called at ./FHEM/36_ModbusRTU.pm line 618." Ein "use bytes;" vor dem Aufruf hat das Problem behoben.


sub _ModbusRTU_crc($) {
  use bytes;
  my ($frame) =@_;
  my $crc = 0xFFFF;
  my ($chr, $lsb);
  for my $i (0..bytes::length($frame)-1) {
    $chr = ord(bytes::substr($frame, $i, 1));
    $crc ^= $chr;
    for (1..8) {
      $lsb = $crc & 1;
      $crc >>= 1;
      $crc ^= 0xA001 if $lsb;
      }
    }
  return $crc;
}



Bei der Umrechnung habe ich high und low vertauschen müssen.Ich lese die Netzspannung von meinem Stromzähler aus. Die werte werden lt. beschreibung als 32 Bit Float ausgegeben. Vorher haben die Werte so ausgesehen:


2014.05.05 23:31:53 5: AddRQueue 01 04 00 00 00 02 71 CB
2014.05.05 23:31:53 5: SimpleWrite 01 04 00 00 00 02 71 CB
2014.05.05 23:31:53 5: Read 01 04 04 43 6E 0A EE 09 31
2014.05.05 23:31:53 5: Received 01 04 04 43 6E 0A EE 09 31
2014.05.05 23:31:53 5: MB_RTU dispatch ModbusRegister:1:0:4:2:17262:2798
2014.05.05 23:31:53 5: ModbusRegister_Parse: 4 1 0
2014.05.05 23:31:53 5: Triggering Reg0 (2 changes)
2014.05.05 23:31:53 5: Notify loop for Reg0 2.2943930567563e-032
2014.05.05 23:31:53 4: eventTypes: ModbusRegister Reg0 2.2943930567563e-032 -> .*.2943930567563e.*
2014.05.05 23:31:53 4: eventTypes: ModbusRegister Reg0 RAW: 0000436e -> RAW: 0000436e


jetzt habe ich die Umrechnung geändert auf


        if($plcDataType eq "REAL"){
          $v=unpack "f", pack "L", ($vals[0]<<16)+$vals[1];


und nun stimmt die Umrechnung:


2014.05.05 23:40:59 5: AddRQueue 01 04 00 00 00 02 71 CB
2014.05.05 23:40:59 5: SimpleWrite 01 04 00 00 00 02 71 CB
2014.05.05 23:40:59 5: Read 01 04 04 43 6E 2F 9D 52 44
2014.05.05 23:40:59 5: Received 01 04 04 43 6E 2F 9D 52 44
2014.05.05 23:40:59 5: MB_RTU dispatch ModbusRegister:1:0:4:2:17262:12189
2014.05.05 23:40:59 5: ModbusRegister_Parse: 4 1 0
2014.05.05 23:40:59 5: Triggering Reg0 (2 changes)
2014.05.05 23:40:59 5: Notify loop for Reg0 238.185989379883
2014.05.05 23:40:59 4: eventTypes: ModbusRegister Reg0 238.185989379883 -> .*
2014.05.05 23:40:59 4: eventTypes: ModbusRegister Reg0 RAW: 0000436e -> RAW: 0000436e


Vielen Dank noch mal für die Erstellung des Moduls, ich werde nun mal fleissig die Register meines Stromzählers definieren.

[Edit]
Was mir gerade aufgefallen ist: Ich brauche immer einen neustart von FHEM um geänderte Register usw. wirksam werden zu lassen. Ist das so gewünscht?
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: golem am 06 Mai 2014, 07:55:55
Hallo,

:) Super jetzt funktionierts. Mit der Änderung von fischle werden jetzt auch die richtigen Werte angezeigt.
Mach mich jetzt mal an einen Test mit mehreren Werten.

@ChrisD kannst du das tauschen noch mit in die Attribute aufnehmen?

Gruß Denis

Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 06 Mai 2014, 08:51:43
Hallo,

Danke für die Tests. Ich werde das 'use bytes;' in 36_ModbusRTU hinzufügen.

Die Änderung in der Umrechnung führt dazu dass es jetzt mit BigEndian-Zahlen funktioniert, allerdings nicht mehr mit LittleEndian. Solange alle Slaves/Server das gleiche Format verwenden ist dies kein Problem, ein Mischbetrieb ist aber so nicht mehr möglich.

Ich sehe folgende Möglichkeiten das Ganze parametrierbar zu machen:
- Festlegung in 36_Modbus*, Attribut wordOrder, Werte LE oder BE (pro Slave/UnitID), Vorteil: nur eine Definition pro Slave/Unit, Nachteil: Programmieraufwand, die 36er Module haben keine Ahnung von Datentypen
- Festlegung in 37_ModbusRegister über Attribut wordOrder, Vorteil: flexibel, Nachteil: Attribut muss ggfs. für jedes Register gesetzt werden
- Festlegung in 37_ModbusRegister über plcDataType, FLOAT_BE, DINT_BE, DWORD_BE

Welche würdet ihr bevorzugen ?

Grüße,

ChrisD



Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: golem am 06 Mai 2014, 10:21:19
Zitat von: ChrisD am 06 Mai 2014, 08:51:43
- Festlegung in 37_ModbusRegister über plcDataType, FLOAT_BE, DINT_BE, DWORD_BE

Würde ich bevorzugen.

ist es richtig, das das State reading wird nicht automatisch aktualisiert?
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 06 Mai 2014, 12:38:48
Hallo,

@Denis:
Zitatist es richtig, das das State reading wird nicht automatisch aktualisiert?
state und RAW werden in 2 aufeinanderfolgenden Zeilen aktualisiert. Ich weiß nicht wieso nur die Aktualisierung von RAW angezeigt wird. Was passiert wenn du die Seite neu lädst ? Steht dann noch immer der alte Wert und Zeitstempel bei state ?

@fischle:
ZitatWas mir gerade aufgefallen ist: Ich brauche immer einen neustart von FHEM um geänderte Register usw. wirksam werden zu lassen. Ist das so gewünscht?
Das ist nicht so gewünscht und auch nicht richtig. Kannst du kurz beschreiben bei welcher Änderung es passiert ist ?

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: golem am 06 Mai 2014, 14:30:57
beim neuladen werden die aktuellen Werte angezeigt.
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 06 Mai 2014, 22:42:48
Hallo,

Anbei eine neue Version von 37_ModbusRegister zum Testen. Ich habe 3 Datentypen für Big Endian hinzugefügt, das Update der Readings geändert (bulkUpdate statt SingleUpdate) und die Darstellung des RAW-Readings korrigiert.

@Denis: Kannst du bitte testen ob sich die Anzeige der Aktualisierung der Readings damit ändert ?

Grüße,

ChrisD

Edit 07.05.2014, Anhang gelöscht, aktuelle Version in folgenden Beiträgen
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: golem am 07 Mai 2014, 07:40:06
Hallo Chris,

Ich werde erst morgen zum testen kommen, da ich heute den ganzen Tag unterwegs bin. Melde mich morgen do schnell wie möglich.
Gruß Denis
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: fischle am 07 Mai 2014, 21:28:04
Hallo Chris,
danke für den supper Support mit den Modulen. Habe heute das Modul mal getestet.  Die sache mit den nicht übernommenen Werten konnte ich nicht ganz nachstellen, vielleicht habe ich auch nicht lange genug gewartet. Eine Sache ist mir noch aufgefallen:

Wenn beim Lesen der seriellen Schnittstelle nicht alle Daten im Puffer sind, kommt das Modul damit noch nicht ganz zurecht. Hier mal ein Auszug aus meinem Log. Man sieht, das Werte z.T. komplett gelesen werden, dann werden sie geparst. Werden die Werte nicht komplett gelesen, dann werden sie auch nicht geparst.


2014.05.07 21:23:54 5: SimpleWrite 01 04 00 0C 00 02 B1 C8
2014.05.07 21:23:54 5: Read 01 04 04 00 00 00 00 FB 84
2014.05.07 21:23:54 5: Received 01 04 04 00 00 00 00 FB 84
2014.05.07 21:23:54 5: MB_RTU dispatch ModbusRegister:1:12:4:2:0:0
2014.05.07 21:23:54 5: ModbusRegister_Parse: 4 1 12
2014.05.07 21:23:54 5: Triggering P_L1 (2 changes)
2014.05.07 21:23:54 5: Notify loop for P_L1 0
2014.05.07 21:23:54 4: eventTypes: ModbusRegister P_L1 0 -> .*
2014.05.07 21:23:54 4: eventTypes: ModbusRegister P_L1 RAW: 00000000 -> RAW: .*
2014.05.07 21:23:54 4: RQUEUE: 5
2014.05.07 21:23:54 5: SimpleWrite 01 04 00 0E 00 02 10 08
2014.05.07 21:23:54 5: Read 01 04 04 00 00
2014.05.07 21:23:54 5: Read 00 00 FB 84
2014.05.07 21:24:02 4: RQUEUE: 4
2014.05.07 21:24:02 5: SimpleWrite 01 04 00 10 00 02 70 0E
2014.05.07 21:24:02 5: Read 01
2014.05.07 21:24:02 5: Read 04 04 00 00 00 00 FB 84
2014.05.07 21:24:10 4: RQUEUE: 3
2014.05.07 21:24:10 5: SimpleWrite 01 04 00 00 00 02 71 CB
2014.05.07 21:24:10 5: Read 01 04 04
2014.05.07 21:24:10 5: Read 43 6D D4 AB 61 62
2014.05.07 21:24:18 4: RQUEUE: 2
2014.05.07 21:24:18 5: SimpleWrite 01 04 00 02 00 02 D0 0B
2014.05.07 21:24:18 5: Read 01 04 04 00 00 00 00 FB 84
2014.05.07 21:24:18 5: Received 01 04 04 00 00 00 00 FB 84
2014.05.07 21:24:18 5: MB_RTU dispatch ModbusRegister:1:2:4:2:0:0
2014.05.07 21:24:18 5: ModbusRegister_Parse: 4 1 2
2014.05.07 21:24:18 5: Triggering U_L2 (2 changes)
2014.05.07 21:24:18 5: Notify loop for U_L2 0
2014.05.07 21:24:18 4: eventTypes: ModbusRegister U_L2 0 -> .*
2014.05.07 21:24:18 4: eventTypes: ModbusRegister U_L2 RAW: 00000000 -> RAW: .*
2014.05.07 21:24:18 4: RQUEUE: 1


Im Viessmann-Thread gab es mal ein ähnliches Problem (http://forum.fhem.de/index.php/topic,20280.270.html), vielleicht kannst du dir dort abschauen, wie es gelöst wurde.

Weiterhin würde mich noch interessieren, was es zu bedeuten hat, wenn im modul "timeout" steht? Was genau bedeutet das, bzw. ab wann wird ein Timeout gezählt? Falls es hilft, hier noch meine Config:


define MB_RTU ModbusRTU COM9@9600
attr MB_RTU charformat 8N1
attr MB_RTU pollIntervall 5
attr MB_RTU timeout 8

define U_L1 ModbusRegister 1 30001
attr U_L1 group Stromzaehler
attr U_L1 plcDataType REAL_BE
define U_L2 ModbusRegister 1 30001
attr U_L2 group Stromzaehler
attr U_L2 plcDataType REAL_BE
define U_L3 ModbusRegister 1 30005
attr U_L3 group Stromzaehler
attr U_L3 plcDataType REAL_BE

define I_L1 ModbusRegister 1 30007
attr I_L1 group Stromzaehler
attr I_L1 plcDataType REAL_BE
define I_L2 ModbusRegister 1 30009
attr I_L2 group Stromzaehler
attr I_L2 plcDataType REAL_BE
define I_L3 ModbusRegister 1 30011
attr I_L3 group Stromzaehler
attr I_L3 plcDataType REAL_BE

define P_L1 ModbusRegister 1 30013
attr P_L1 group Stromzaehler
attr P_L1 plcDataType REAL_BE
define P_L2 ModbusRegister 1 30015
attr P_L2 group Stromzaehler
attr P_L2 plcDataType REAL_BE
define P_L3 ModbusRegister 1 30017
attr P_L3 group Stromzaehler
attr P_L3 plcDataType REAL_BE

Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 07 Mai 2014, 22:24:02
Hallo,

Das Handling des Puffers der seriellen Schnittstelle habe ich zum Teil aus einem anderen Modul (Jeelink) übernommen. Leider habe ich dabei eine Zeile vergessen. Anbei eine neue Version von 36_ModbusRTU (0003) die den Fehler beheben sollte.

Die Meldung Timeout erscheint wenn nach dem Absenden der Anfrage (SimpleWrite) innerhalb der eingestellten Zeit (bei dir 8 s) keine korrekte Antwort kommt. Dies ist in deinem Log z.B. der Fall bei 21:23:54/21:24:02. Durch den Fehler in 36_ModbusRTU wurde das Antwortpaket nicht korrekt zusammengebaut und verworfen. Danach wird das nächste Paket abgeschickt und der Timer wird neu gestartet.

Anbei ebenfalls eine neue Version von 37_ModbusRegister (0005) welche einen Fehler im Define bei den plcDataTypes WORD und INT korrigiert.

Ich bin mir nicht sicher ob in deiner Config das Register für die Spannung von L2 stimmt. Müsste es nicht 30003 statt 30001 sein ?

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: fischle am 07 Mai 2014, 22:33:45
Hallo Chris,
danke für die schnelle Antwort, werde ich gleich mal testen.

Du hast recht, das Config ist noch falsch, da wollte ich noch die Probleme beim Umstellen der Regsiter nachstellen. Jetzt habe ich ein anderes Phänomen gefunden. Ich habe FHEM mit der geposteten config gestartet und dann die Adresse von U_L2 von 30001 auf 30003 geändert. Jetzt parst er mir das Ergebniss von U_L1 aber dennoch auch bei U_L2 rein:


014.05.07 22:25:21 5: SimpleWrite 01 04 00 00 00 02 71 CB
2014.05.07 22:25:21 5: Read 01 04 04 43 6F B1 9B EB E6
2014.05.07 22:25:21 5: Received 01 04 04 43 6F B1 9B EB E6
2014.05.07 22:25:21 5: MB_RTU dispatch ModbusRegister:1:0:4:2:17263:45467
2014.05.07 22:25:21 5: ModbusRegister_Parse: 4 1 0
2014.05.07 22:25:21 5: Triggering U_L2 (2 changes)
2014.05.07 22:25:21 5: Notify loop for U_L2 239.693771362305
2014.05.07 22:25:21 4: eventTypes: ModbusRegister U_L2 239.693771362305 -> .*
2014.05.07 22:25:21 4: eventTypes: ModbusRegister U_L2 RAW: 436fb19b -> RAW: 436fb19b
2014.05.07 22:25:21 5: Triggering U_L1 (2 changes)
2014.05.07 22:25:21 5: Notify loop for U_L1 239.693771362305
2014.05.07 22:25:21 4: eventTypes: ModbusRegister U_L1 239.693771362305 -> .*
2014.05.07 22:25:21 4: eventTypes: ModbusRegister U_L1 RAW: 436fb19b -> RAW: 436fb19b


Ich spiel jetzt mal das neue Modul ein, dann schau ich, ob sich der fehler immer noch nachstellen lässt.

[Edit]
Habe das Modul nun mal getestet, das mit dem zusammensetzen funktioniert wohl noch nicht ganz: Er setzt die Message unter "Read" dann voll korrekt zusammen, unter "Received" steht aber nur der 2. Teil und es kommt kein Parsing-Ergebniss.

2014.05.07 22:41:55 5: SimpleWrite 01 04 00 10 00 02 70 0E
2014.05.07 22:41:55 5: Read 01 04 04
2014.05.07 22:41:55 5: Read 01 04 04 00 00 00 00 FB 84
2014.05.07 22:41:55 5: Received 00 00 00 00 FB 84
2014.05.07 22:41:55 4: RQUEUE: 3
2014.05.07 22:41:55 5: SimpleWrite 01 04 00 00 00 02 71 CB
2014.05.07 22:41:55 5: Read 01 04 04 43 70 33 D4 FB 74
2014.05.07 22:41:55 5: Received 01 04 04 43 70 33 D4 FB 74
2014.05.07 22:41:55 5: MB_RTU dispatch ModbusRegister:1:0:4:2:17264:13268
2014.05.07 22:41:55 5: ModbusRegister_Parse: 4 1 0
2014.05.07 22:41:55 5: Triggering U_L1 (2 changes)
2014.05.07 22:41:55 5: Notify loop for U_L1 240.202453613281
2014.05.07 22:41:55 4: eventTypes: ModbusRegister U_L1 240.202453613281 -> .*
2014.05.07 22:41:55 4: eventTypes: ModbusRegister U_L1 RAW: 437033d4 -> RAW: 437033d4


Weiterhin konnte ich den Fehler mit dem Zurücklesen nachstellen: In der Konfig 2x das gleiche Register für unterschiedliche Variablen eintragen. Dann FHEM neu starten. Dann Register über Frontend anpssen und "Save Config". Ist für mich aber kein echtes Problem, ich weiß ja, das ein Neustart hilft..
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 07 Mai 2014, 23:01:34
Hallo,

Noch ein Versuch für heute Abend:

- 36_ModbusRTU (0004) sollte das zusammengesetzte Paket jetzt korrekt an Parse übergeben
- in 37_ModbusRegister (0006) habe ich die Define-Funktion geändert und Log-Aufrufe hinzugefügt um dem Problem beim ändern auf die Spur zu kommen

Grüße,

ChrisD

Edit: Die aktuellen Versionen der Module sind unter https://github.com/ChrisD70/FHEM-Modules (https://github.com/ChrisD70/FHEM-Modules) zu finden.
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: fischle am 07 Mai 2014, 23:07:37
Hallo Chris,
ich habe weiter mit dem Modul gespielt und folgendes festgestellt:

- Ich habe weitere Readings über "edit files" hinzugefügt - dannach hat er gar nichts mehr über modbus ausgelesen. im Logfile sind keine Einträge von dem Modul mehr zu sehen.

- Ich starte FHEM über Kommandozeile, folgende Meldungen erscheinen da noch regelmäßig:


Use of uninitialized value $exp_code in concatenation (.) or string at ./FHEM/36
_ModbusRTU.pm line 327.
Use of uninitialized value $found[0] in string eq at fhem.pl line 2788.
Argument "" isn't numeric in numeric gt (>) at ./FHEM/36_ModbusRTU.pm line 322.
Use of uninitialized value $found[0] in string eq at fhem.pl line 2788.
Argument "" isn't numeric in numeric gt (>) at ./FHEM/36_ModbusRTU.pm line 322.


Sind jetzt beides keine Sachen, die ein echtes Problem darstellen, wollte dir nur das Feedback geben.

Grüße

Fabian

[EDIT]
Gerade deinen Post gelesen, gibt gleich noch mal ein Feedback.
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: fischle am 07 Mai 2014, 23:15:56
Hallo,
ich habe den ersten Test durchgeführt. Die Fehlermeldungen in der Kommandozeile sind auf jeden Fall schon mal weg.  :)

Das Zusammensetzen scheint auch zu funktionieren:


2014.05.07 23:11:47 5: SimpleWrite 01 04 00 08 00 02 F0 09
2014.05.07 23:11:47 5: Read 01 04 04 00 00
2014.05.07 23:11:47 5: Read 01 04 04 00 00 00 00 FB 84
2014.05.07 23:11:47 5: Received 01 04 04 00 00 00 00 FB 84
2014.05.07 23:11:47 5: MB_RTU dispatch ModbusRegister:1:8:4:2:0:0
2014.05.07 23:11:47 5: ModbusRegister_Parse: 4 1 8
2014.05.07 23:11:47 5: Triggering I_L2 (2 changes)
2014.05.07 23:11:47 5: Notify loop for I_L2 0
2014.05.07 23:11:47 4: eventTypes: ModbusRegister I_L2 0 -> .*
2014.05.07 23:11:47 4: eventTypes: ModbusRegister I_L2 RAW: 00000000 -> RAW: .*


Dann habe ich mal ein neues Device konfiguriert, danach steht das ganze wieder. Hier mal das (umfangreiche) log, begonnen mit den letzten Einträgen wo es noch funktioniert hat. Dannach kommt nichts mehr.


014.05.07 23:09:36 5: SimpleWrite 01 04 00 02 00 02 D0 0B
2014.05.07 23:09:37 5: Read 01 04 04 00 00 00 00 FB 84
2014.05.07 23:09:37 5: Received 01 04 04 00 00 00 00 FB 84
2014.05.07 23:09:37 5: MB_RTU dispatch ModbusRegister:1:2:4:2:0:0
2014.05.07 23:09:37 5: ModbusRegister_Parse: 4 1 2
2014.05.07 23:09:37 5: Triggering U_L2 (2 changes)
2014.05.07 23:09:37 5: Notify loop for U_L2 0
2014.05.07 23:09:37 4: eventTypes: ModbusRegister U_L2 0 -> .*
2014.05.07 23:09:37 4: eventTypes: ModbusRegister U_L2 RAW: 00000000 -> RAW: .*
2014.05.07 23:09:37 4: RQUEUE: 2
2014.05.07 23:09:37 5: SimpleWrite 01 04 00 04 00 02 30 0A
2014.05.07 23:09:37 5: Read 01 04 04 00 00 00
2014.05.07 23:09:37 5: Read 01 04 04 00 00 00 00 FB 84
2014.05.07 23:09:37 5: Received 01 04 04 00 00 00 00 FB 84
2014.05.07 23:09:37 5: MB_RTU dispatch ModbusRegister:1:4:4:2:0:0
2014.05.07 23:09:37 5: ModbusRegister_Parse: 4 1 4
2014.05.07 23:09:37 5: Triggering U_L3 (2 changes)
2014.05.07 23:09:37 5: Notify loop for U_L3 0
2014.05.07 23:09:37 4: eventTypes: ModbusRegister U_L3 0 -> .*
2014.05.07 23:09:37 4: eventTypes: ModbusRegister U_L3 RAW: 00000000 -> RAW: .*
2014.05.07 23:09:37 4: RQUEUE: 1
2014.05.07 23:09:37 5: SimpleWrite 01 04 00 48 00 02 F1 DD
2014.05.07 23:09:37 5: Read 01 04 04 3A 83 12 6F 4A 38
2014.05.07 23:09:37 5: Received 01 04 04 3A 83 12 6F 4A 38
2014.05.07 23:09:37 5: MB_RTU dispatch ModbusRegister:1:72:4:2:14979:4719
2014.05.07 23:09:37 5: ModbusRegister_Parse: 4 1 72
2014.05.07 23:09:37 5: Triggering kWh (2 changes)
2014.05.07 23:09:37 5: Notify loop for kWh 0.00100000004749745
2014.05.07 23:09:37 4: eventTypes: ModbusRegister kWh 0.00100000004749745 -> .*
2014.05.07 23:09:37 4: eventTypes: ModbusRegister kWh RAW: 3a83126f -> RAW: 3a83126f
2014.05.07 23:09:41 4: Connection closed for FHEMWEB:127.0.0.1:2769
2014.05.07 23:09:41 4: HTTP FHEMWEB:127.0.0.1:2768 GET /fhem?cmd=style%20edit%20fhem.cfg&save=Save+fhem.cfg&saveName=fhem.cfg&cmd=style+save+fhem.cfg&data=attr+global+autoload_undefined_devices+1%0D%0Aattr+global+logfile+.%2Flog%2Ffhem-%25Y-%25m-%25d.log%0D%0Aattr+global+modpath+.%0D%0Aattr+global+motd+SecurityCheck%3A%5C%0D%0A%5C%0D%0AWEB%2CWEBphone%2CWEBtablet+has+no+basicAuth+attribute.%5C%0D%0AtelnetPort+has+no+password%2Fglobalpassword+attribute.%5C%0D%0A%5C%0D%0ARestart+fhem+for+a+new+check+if+the+problem+is+fixed%2C%5C%0D%0Aor+set+the+global+attribute+motd+to+none+to+supress+this+message.%5C%0D%0A%0D%0Aattr+global+nofork+1%0D%0Aattr+global+statefile+.%2Flog%2Ffhem.save%0D%0Aattr+global+updateInBackground+1%0D%0Aattr+global+userattr+devStateIcon+devStateStyle+icon+sortby+webCmd%0D%0Aattr+global+verbose+5%0D%0A%0D%0Adefine+telnetPort+telnet+7072+global%0D%0A%0D%0Adefine+WEB+FHEMWEB+8083+global%0D%0A%0D%0Adefine+WEBphone+FHEMWEB+8084+global%0D%0Aattr+WEBphone+stylesheetPrefix+smallscreen%0D%0A%0D%0Adefine+WEBtablet+FHEMWEB+8085+global%0D%0Aattr+WEBtablet+stylesheetPrefix+touchpad%0D%0A%0D%0A%23+Fake+FileLog+entry%2C+to+access+the+fhem+log+from+FHEMWEB+%0D%0Adefine+Logfile+FileLog+.%2Flog%2Ffhem-%25Y-%25m-%25d.log+fakelog%0D%0A%0D%0Adefine+autocreate+autocreate%0D%0Aattr+autocreate+filelog+.%2Flog%2F%25NAME-%25Y.log%0D%0A%0D%0Adefine+eventTypes+eventTypes+.%2Flog%2FeventTypes.txt%0D%0A%0D%0A%23+Disable+this+to+avoid+looking+for+new+USB+devices+on+startup%0D%0Adefine+initialUsbCheck+notify+global%3AINITIALIZED+usb+create%0D%0A%0D%0Adefine+MB_RTU+ModbusRTU+COM9%409600%0D%0Aattr+MB_RTU+charformat+8N1%0D%0Aattr+MB_RTU+pollIntervall+5%0D%0Aattr+MB_RTU+timeout+8%0D%0A%0D%0Adefine+U_L1+ModbusRegister+1+30001%0D%0Aattr+U_L1+group+Stromzaehler%0D%0Aattr+U_L1+plcDataType+REAL_BE%0D%0Adefine+U_L2+ModbusRegister+1+30003%0D%0Aattr+U_L2+group+Stromzaehler%0D%0Aattr+U_L2+plcDataType+REAL_BE%0D%0Adefine+U_L3+ModbusRegister+1+30005%0D%0Aattr+U_L3+group+Stromzaehler%0D%0Aattr+U_L3+plcDataType+REAL_BE%0D%0A%0D%0Adefine+I_L1+ModbusRegister+1+30007%0D%0Aattr+I_L1+group+Stromzaehler%0D%0Aattr+I_L1+plcDataType+REAL_BE%0D%0Adefine+I_L2+ModbusRegister+1+30009%0D%0Aattr+I_L2+group+Stromzaehler%0D%0Aattr+I_L2+plcDataType+REAL_BE%0D%0Adefine+I_L3+ModbusRegister+1+30011%0D%0Aattr+I_L3+group+Stromzaehler%0D%0Aattr+I_L3+plcDataType+REAL_BE%0D%0A%0D%0Adefine+P_L1+ModbusRegister+1+30013%0D%0Aattr+P_L1+group+Stromzaehler%0D%0Aattr+P_L1+plcDataType+REAL_BE%0D%0Adefine+P_L2+ModbusRegister+1+30015%0D%0Aattr+P_L2+group+Stromzaehler%0D%0Aattr+P_L2+plcDataType+REAL_BE%0D%0Adefine+P_L3+ModbusRegister+1+30017%0D%0Aattr+P_L3+group+Stromzaehler%0D%0Aattr+P_L3+plcDataType+REAL_BE%0D%0A%0D%0Adefine+P_Ges+ModbusRegister+1+30053%0D%0Aattr+P_Ges+group+Stromzaehler%0D%0Aattr+P_Ges+plcDataType+REAL_BE%0D%0A%0D%0Adefine+Freq+ModbusRegister+1+30071%0D%0Aattr+Freq+group+Stromzaehler%0D%0Aattr+Freq+plcDataType+REAL_BE%0D%0A%0D%0Adefine+kWh+ModbusRegister+1+30073%0D%0Aattr+kWh+group+Stromzaehler%0D%0Aattr+kWh+plcDataType+REAL_BE%0D%0A%0D%0Adefine+kVar+ModbusRegister+1+30077%0D%0Aattr+kVar+group+Stromzaehler%0D%0Aattr+kVar+plcDataType+REAL_BE
2014.05.07 23:09:41 5: Cmd: >rereadcfg<
2014.05.07 23:09:41 5: Undef 4 1 72 kWh
2014.05.07 23:09:41 5: Undef 4 1 70 Freq
2014.05.07 23:09:41 5: Undef 4 1 52 P_Ges
2014.05.07 23:09:41 5: Undef 4 1 16 P_L3
2014.05.07 23:09:41 5: Undef 4 1 14 P_L2
2014.05.07 23:09:41 5: Undef 4 1 12 P_L1
2014.05.07 23:09:41 5: Undef 4 1 10 I_L3
2014.05.07 23:09:41 5: Undef 4 1 8 I_L2
2014.05.07 23:09:41 5: Undef 4 1 6 I_L1
2014.05.07 23:09:41 5: Undef 4 1 4 U_L3
2014.05.07 23:09:41 5: Undef 4 1 2 U_L2
2014.05.07 23:09:41 5: Undef 4 1 0 U_L1
2014.05.07 23:09:41 1: Including fhem.cfg
2014.05.07 23:09:41 5: Cmd: >attr global autoload_undefined_devices 1<
2014.05.07 23:09:41 5: Cmd: >attr global logfile ./log/fhem-%Y-%m-%d.log<
2014.05.07 23:09:41 5: Cmd: >attr global modpath .<
2014.05.07 23:09:41 5: Cmd: >attr global motd SecurityCheck:\
\
WEB,WEBphone,WEBtablet has no basicAuth attribute.\
telnetPort has no password/globalpassword attribute.\
\
Restart fhem for a new check if the problem is fixed,\
or set the global attribute motd to none to supress this message.\
<
2014.05.07 23:09:41 5: Cmd: >attr global nofork 1<
2014.05.07 23:09:41 5: Cmd: >attr global statefile ./log/fhem.save<
2014.05.07 23:09:41 5: Cmd: >attr global updateInBackground 1<
2014.05.07 23:09:41 5: Cmd: >attr global userattr devStateIcon devStateStyle icon sortby webCmd<
2014.05.07 23:09:41 5: Cmd: >attr global verbose 5<
2014.05.07 23:09:41 5: Cmd: >define telnetPort telnet 7072 global<
2014.05.07 23:09:41 3: telnetPort: port 7072 opened
2014.05.07 23:09:41 5: Cmd: >define WEB FHEMWEB 8083 global<
2014.05.07 23:09:41 3: WEB: port 8083 opened
2014.05.07 23:09:41 5: Cmd: >define WEBphone FHEMWEB 8084 global<
2014.05.07 23:09:41 3: WEBphone: port 8084 opened
2014.05.07 23:09:41 5: Cmd: >attr WEBphone stylesheetPrefix smallscreen<
2014.05.07 23:09:41 5: Cmd: >define WEBtablet FHEMWEB 8085 global<
2014.05.07 23:09:41 3: WEBtablet: port 8085 opened
2014.05.07 23:09:41 5: Cmd: >attr WEBtablet stylesheetPrefix touchpad<
2014.05.07 23:09:41 5: Cmd: >define Logfile FileLog ./log/fhem-%Y-%m-%d.log fakelog<
2014.05.07 23:09:41 5: Cmd: >define autocreate autocreate<
2014.05.07 23:09:41 5: Cmd: >attr autocreate filelog ./log/%NAME-%Y.log<
2014.05.07 23:09:41 5: Cmd: >define eventTypes eventTypes ./log/eventTypes.txt<
2014.05.07 23:09:41 5: Cmd: >define initialUsbCheck notify global:INITIALIZED usb create<
2014.05.07 23:09:41 5: Cmd: >define MB_RTU ModbusRTU COM9@9600<
2014.05.07 23:09:41 5: t35: 4.0625 ms, t15: 1.77083333333333 ms
2014.05.07 23:09:41 5: Cmd: >attr MB_RTU charformat 8N1<
2014.05.07 23:09:41 5: Cmd: >attr MB_RTU pollIntervall 5<
2014.05.07 23:09:41 5: Cmd: >attr MB_RTU timeout 8<
2014.05.07 23:09:41 5: Cmd: >define U_L1 ModbusRegister 1 30001<
2014.05.07 23:09:41 3: U_L1: I/O device is MB_RTU
2014.05.07 23:09:41 5: Def 4 1 0 U_L1
2014.05.07 23:09:41 5: Cmd: >attr U_L1 group Stromzaehler<
2014.05.07 23:09:41 5: Cmd: >attr U_L1 plcDataType REAL_BE<
2014.05.07 23:09:41 5: Cmd: >define U_L2 ModbusRegister 1 30003<
2014.05.07 23:09:41 3: U_L2: I/O device is MB_RTU
2014.05.07 23:09:41 5: Def 4 1 2 U_L2
2014.05.07 23:09:41 5: Cmd: >attr U_L2 group Stromzaehler<
2014.05.07 23:09:41 5: Cmd: >attr U_L2 plcDataType REAL_BE<
2014.05.07 23:09:41 5: Cmd: >define U_L3 ModbusRegister 1 30005<
2014.05.07 23:09:41 3: U_L3: I/O device is MB_RTU
2014.05.07 23:09:41 5: Def 4 1 4 U_L3
2014.05.07 23:09:41 5: Cmd: >attr U_L3 group Stromzaehler<
2014.05.07 23:09:41 5: Cmd: >attr U_L3 plcDataType REAL_BE<
2014.05.07 23:09:41 5: Cmd: >define I_L1 ModbusRegister 1 30007<
2014.05.07 23:09:41 3: I_L1: I/O device is MB_RTU
2014.05.07 23:09:41 5: Def 4 1 6 I_L1
2014.05.07 23:09:41 5: Cmd: >attr I_L1 group Stromzaehler<
2014.05.07 23:09:41 5: Cmd: >attr I_L1 plcDataType REAL_BE<
2014.05.07 23:09:41 5: Cmd: >define I_L2 ModbusRegister 1 30009<
2014.05.07 23:09:41 3: I_L2: I/O device is MB_RTU
2014.05.07 23:09:41 5: Def 4 1 8 I_L2
2014.05.07 23:09:41 5: Cmd: >attr I_L2 group Stromzaehler<
2014.05.07 23:09:41 5: Cmd: >attr I_L2 plcDataType REAL_BE<
2014.05.07 23:09:41 5: Cmd: >define I_L3 ModbusRegister 1 30011<
2014.05.07 23:09:41 3: I_L3: I/O device is MB_RTU
2014.05.07 23:09:41 5: Def 4 1 10 I_L3
2014.05.07 23:09:41 5: Cmd: >attr I_L3 group Stromzaehler<
2014.05.07 23:09:41 5: Cmd: >attr I_L3 plcDataType REAL_BE<
2014.05.07 23:09:41 5: Cmd: >define P_L1 ModbusRegister 1 30013<
2014.05.07 23:09:41 3: P_L1: I/O device is MB_RTU
2014.05.07 23:09:41 5: Def 4 1 12 P_L1
2014.05.07 23:09:41 5: Cmd: >attr P_L1 group Stromzaehler<
2014.05.07 23:09:41 5: Cmd: >attr P_L1 plcDataType REAL_BE<
2014.05.07 23:09:41 5: Cmd: >define P_L2 ModbusRegister 1 30015<
2014.05.07 23:09:41 3: P_L2: I/O device is MB_RTU
2014.05.07 23:09:41 5: Def 4 1 14 P_L2
2014.05.07 23:09:41 5: Cmd: >attr P_L2 group Stromzaehler<
2014.05.07 23:09:41 5: Cmd: >attr P_L2 plcDataType REAL_BE<
2014.05.07 23:09:41 5: Cmd: >define P_L3 ModbusRegister 1 30017<
2014.05.07 23:09:41 3: P_L3: I/O device is MB_RTU
2014.05.07 23:09:41 5: Def 4 1 16 P_L3
2014.05.07 23:09:41 5: Cmd: >attr P_L3 group Stromzaehler<
2014.05.07 23:09:41 5: Cmd: >attr P_L3 plcDataType REAL_BE<
2014.05.07 23:09:41 5: Cmd: >define P_Ges ModbusRegister 1 30053<
2014.05.07 23:09:41 3: P_Ges: I/O device is MB_RTU
2014.05.07 23:09:41 5: Def 4 1 52 P_Ges
2014.05.07 23:09:41 5: Cmd: >attr P_Ges group Stromzaehler<
2014.05.07 23:09:41 5: Cmd: >attr P_Ges plcDataType REAL_BE<
2014.05.07 23:09:41 5: Cmd: >define Freq ModbusRegister 1 30071<
2014.05.07 23:09:41 3: Freq: I/O device is MB_RTU
2014.05.07 23:09:41 5: Def 4 1 70 Freq
2014.05.07 23:09:41 5: Cmd: >attr Freq group Stromzaehler<
2014.05.07 23:09:41 5: Cmd: >attr Freq plcDataType REAL_BE<
2014.05.07 23:09:41 5: Cmd: >define kWh ModbusRegister 1 30073<
2014.05.07 23:09:41 3: kWh: I/O device is MB_RTU
2014.05.07 23:09:41 5: Def 4 1 72 kWh
2014.05.07 23:09:41 5: Cmd: >attr kWh group Stromzaehler<
2014.05.07 23:09:41 5: Cmd: >attr kWh plcDataType REAL_BE<
2014.05.07 23:09:41 5: Cmd: >define kVar ModbusRegister 1 30077<
2014.05.07 23:09:41 3: kVar: I/O device is MB_RTU
2014.05.07 23:09:41 5: Def 4 1 76 kVar
2014.05.07 23:09:41 5: Cmd: >attr kVar group Stromzaehler<
2014.05.07 23:09:41 5: Cmd: >attr kVar plcDataType REAL_BE<
2014.05.07 23:09:41 1: Including ./log/fhem.save
2014.05.07 23:09:41 5: Cmd: >setstate Freq 50.0143623352051<
2014.05.07 23:09:41 5: Cmd: >setstate Freq 2014-05-07 23:09:36 RAW 42480eb5<
2014.05.07 23:09:41 5: Cmd: >setstate Freq 2014-05-07 23:09:36 state 50.0143623352051<
2014.05.07 23:09:41 5: Cmd: >setstate I_L1 0<
2014.05.07 23:09:41 5: Cmd: >setstate I_L1 2014-05-07 23:09:36 RAW 00000000<
2014.05.07 23:09:41 5: Cmd: >setstate I_L1 2014-05-07 23:09:36 state 0<
2014.05.07 23:09:41 5: Cmd: >setstate I_L2 0<
2014.05.07 23:09:41 5: Cmd: >setstate I_L2 2014-05-07 23:09:36 RAW 00000000<
2014.05.07 23:09:41 5: Cmd: >setstate I_L2 2014-05-07 23:09:36 state 0<
2014.05.07 23:09:41 5: Cmd: >setstate I_L3 0<
2014.05.07 23:09:41 5: Cmd: >setstate I_L3 2014-05-07 23:09:36 RAW 00000000<
2014.05.07 23:09:41 5: Cmd: >setstate I_L3 2014-05-07 23:09:36 state 0<
2014.05.07 23:09:41 5: Cmd: >setstate Logfile active<
2014.05.07 23:09:41 5: Cmd: >setstate MB_RTU ok<
2014.05.07 23:09:41 5: Cmd: >setstate P_Ges 0<
2014.05.07 23:09:41 5: Cmd: >setstate P_Ges 2014-05-07 23:09:36 RAW 00000000<
2014.05.07 23:09:41 5: Cmd: >setstate P_Ges 2014-05-07 23:09:36 state 0<
2014.05.07 23:09:41 5: Cmd: >setstate P_L1 0<
2014.05.07 23:09:41 5: Cmd: >setstate P_L1 2014-05-07 23:09:36 RAW 00000000<
2014.05.07 23:09:41 5: Cmd: >setstate P_L1 2014-05-07 23:09:36 state 0<
2014.05.07 23:09:41 5: Cmd: >setstate P_L2 0<
2014.05.07 23:09:41 5: Cmd: >setstate P_L2 2014-05-07 23:09:36 RAW 00000000<
2014.05.07 23:09:41 5: Cmd: >setstate P_L2 2014-05-07 23:09:36 state 0<
2014.05.07 23:09:41 5: Cmd: >setstate P_L3 0<
2014.05.07 23:09:41 5: Cmd: >setstate P_L3 2014-05-07 23:09:36 RAW 00000000<
2014.05.07 23:09:41 5: Cmd: >setstate P_L3 2014-05-07 23:09:36 state 0<
2014.05.07 23:09:41 5: Cmd: >setstate U_L1 236.793640136719<
2014.05.07 23:09:41 5: Cmd: >setstate U_L1 2014-05-07 23:09:36 RAW 436ccb2c<
2014.05.07 23:09:41 5: Cmd: >setstate U_L1 2014-05-07 23:09:36 state 236.793640136719<
2014.05.07 23:09:41 5: Cmd: >setstate U_L2 0<
2014.05.07 23:09:41 5: Cmd: >setstate U_L2 2014-05-07 23:09:37 RAW 00000000<
2014.05.07 23:09:41 5: Cmd: >setstate U_L2 2014-05-07 23:09:37 state 0<
2014.05.07 23:09:41 5: Cmd: >setstate U_L3 0<
2014.05.07 23:09:41 5: Cmd: >setstate U_L3 2014-05-07 23:09:37 RAW 00000000<
2014.05.07 23:09:41 5: Cmd: >setstate U_L3 2014-05-07 23:09:37 state 0<
2014.05.07 23:09:41 5: Cmd: >setstate autocreate active<
2014.05.07 23:09:41 5: Cmd: >setstate eventTypes active<
2014.05.07 23:09:41 5: Cmd: >setstate global <no definition><
2014.05.07 23:09:41 5: Cmd: >setstate initialUsbCheck active<
2014.05.07 23:09:41 5: Cmd: >setstate kWh 0.00100000004749745<
2014.05.07 23:09:41 5: Cmd: >setstate kWh 2014-05-07 23:09:37 RAW 3a83126f<
2014.05.07 23:09:41 5: Cmd: >setstate kWh 2014-05-07 23:09:37 state 0.00100000004749745<
2014.05.07 23:09:41 5: Triggering global (1 changes)
2014.05.07 23:09:41 5: Notify loop for global REREADCFG
2014.05.07 23:09:41 4: eventTypes: Global global REREADCFG -> REREADCFG
2014.05.07 23:09:41 4: /fhem?cmd=style%20edit%20fhem.cfg&save=Save+fhem.cfg&saveName=fhem.cfg&cmd=style+save+fhem.cfg&data=attr+global+autoload_undefined_devices+1%0D%0Aattr+global+logfile+.%2Flog%2Ffhem-%25Y-%25m-%25d.log%0D%0Aattr+global+modpath+.%0D%0Aattr+global+motd+SecurityCheck%3A%5C%0D%0A%5C%0D%0AWEB%2CWEBphone%2CWEBtablet+has+no+basicAuth+attribute.%5C%0D%0AtelnetPort+has+no+password%2Fglobalpassword+attribute.%5C%0D%0A%5C%0D%0ARestart+fhem+for+a+new+check+if+the+problem+is+fixed%2C%5C%0D%0Aor+set+the+global+attribute+motd+to+none+to+supress+this+message.%5C%0D%0A%0D%0Aattr+global+nofork+1%0D%0Aattr+global+statefile+.%2Flog%2Ffhem.save%0D%0Aattr+global+updateInBackground+1%0D%0Aattr+global+userattr+devStateIcon+devStateStyle+icon+sortby+webCmd%0D%0Aattr+global+verbose+5%0D%0A%0D%0Adefine+telnetPort+telnet+7072+global%0D%0A%0D%0Adefine+WEB+FHEMWEB+8083+global%0D%0A%0D%0Adefine+WEBphone+FHEMWEB+8084+global%0D%0Aattr+WEBphone+stylesheetPrefix+smallscreen%0D%0A%0D%0Adefine+WEBtablet+FHEMWEB+8085+global%0D%0Aattr+WEBtablet+stylesheetPrefix+touchpad%0D%0A%0D%0A%23+Fake+FileLog+entry%2C+to+access+the+fhem+log+from+FHEMWEB+%0D%0Adefine+Logfile+FileLog+.%2Flog%2Ffhem-%25Y-%25m-%25d.log+fakelog%0D%0A%0D%0Adefine+autocreate+autocreate%0D%0Aattr+autocreate+filelog+.%2Flog%2F%25NAME-%25Y.log%0D%0A%0D%0Adefine+eventTypes+eventTypes+.%2Flog%2FeventTypes.txt%0D%0A%0D%0A%23+Disable+this+to+avoid+looking+for+new+USB+devices+on+startup%0D%0Adefine+initialUsbCheck+notify+global%3AINITIALIZED+usb+create%0D%0A%0D%0Adefine+MB_RTU+ModbusRTU+COM9%409600%0D%0Aattr+MB_RTU+charformat+8N1%0D%0Aattr+MB_RTU+pollIntervall+5%0D%0Aattr+MB_RTU+timeout+8%0D%0A%0D%0Adefine+U_L1+ModbusRegister+1+30001%0D%0Aattr+U_L1+group+Stromzaehler%0D%0Aattr+U_L1+plcDataType+REAL_BE%0D%0Adefine+U_L2+ModbusRegister+1+30003%0D%0Aattr+U_L2+group+Stromzaehler%0D%0Aattr+U_L2+plcDataType+REAL_BE%0D%0Adefine+U_L3+ModbusRegister+1+30005%0D%0Aattr+U_L3+group+Stromzaehler%0D%0Aattr+U_L3+plcDataType+REAL_BE%0D%0A%0D%0Adefine+I_L1+ModbusRegister+1+30007%0D%0Aattr+I_L1+group+Stromzaehler%0D%0Aattr+I_L1+plcDataType+REAL_BE%0D%0Adefine+I_L2+ModbusRegister+1+30009%0D%0Aattr+I_L2+group+Stromzaehler%0D%0Aattr+I_L2+plcDataType+REAL_BE%0D%0Adefine+I_L3+ModbusRegister+1+30011%0D%0Aattr+I_L3+group+Stromzaehler%0D%0Aattr+I_L3+plcDataType+REAL_BE%0D%0A%0D%0Adefine+P_L1+ModbusRegister+1+30013%0D%0Aattr+P_L1+group+Stromzaehler%0D%0Aattr+P_L1+plcDataType+REAL_BE%0D%0Adefine+P_L2+ModbusRegister+1+30015%0D%0Aattr+P_L2+group+Stromzaehler%0D%0Aattr+P_L2+plcDataType+REAL_BE%0D%0Adefine+P_L3+ModbusRegister+1+30017%0D%0Aattr+P_L3+group+Stromzaehler%0D%0Aattr+P_L3+plcDataType+REAL_BE%0D%0A%0D%0Adefine+P_Ges+ModbusRegister+1+30053%0D%0Aattr+P_Ges+group+Stromzaehler%0D%0Aattr+P_Ges+plcDataType+REAL_BE%0D%0A%0D%0Adefine+Freq+ModbusRegister+1+30071%0D%0Aattr+Freq+group+Stromzaehler%0D%0Aattr+Freq+plcDataType+REAL_BE%0D%0A%0D%0Adefine+kWh+ModbusRegister+1+30073%0D%0Aattr+kWh+group+Stromzaehler%0D%0Aattr+kWh+plcDataType+REAL_BE%0D%0A%0D%0Adefine+kVar+ModbusRegister+1+30077%0D%0Aattr+kVar+group+Stromzaehler%0D%0Aattr+kVar+plcDataType+REAL_BE / RL:1627 / text/html; charset=UTF-8 / Content-Encoding: gzip

Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 08 Mai 2014, 10:55:18
Hallo,

Danke für deine Hilfe und die Logs. Bei einem rereadcfg (erfolgt automatisch beim Speichern in 'Edit files') wurde die Schnittstelle nicht neu geöffnet da ich nicht auf das zugehörige Event geachtet habe. Ich habe dies jetzt geändert. Das ModbusTCPServer-Modul ist ebenfalls davon betroffen.

Grüße,

ChrisD

Edit: Die aktuellen Versionen der Module sind unter https://github.com/ChrisD70/FHEM-Modules (https://github.com/ChrisD70/FHEM-Modules) zu finden.
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: golem am 08 Mai 2014, 11:33:58
Hallo Chris,

habe gerade getestet, im Webinterface werden die state readings nicht akualisiert, nur wenn ich die Seite neu lade bekomme ich eine Anzeige der aktuellen Werte.

gruß Denis
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 08 Mai 2014, 13:45:57
Hallo,

Welchen Browser verwendest du ?

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: golem am 08 Mai 2014, 14:41:53
Firefox 29.0
Internet Explorer 10

Bei beiden wird state nicht aktualisiert nur nach neu laden der Seite.
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 08 Mai 2014, 16:26:08
Hast du das Attribut longpoll in der WEB-Instanz gesetzt (auf 0 oder 1) ?
Welche Version von 01_FHEMWEB hast du ?

Mit FF29 sollte longpoll funktionieren, in IE10/11 geht es nur wenn der Kompatibilitätsmodus nicht aktiv ist.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: fischle am 08 Mai 2014, 21:05:09
Hallo,
habe es getestet, jetzt werden Änderungen sofort übernommen.
Vielen Dank, jetzt tut erst mal alles wie ich will.

Gruß

Fabian
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: golem am 09 Mai 2014, 07:24:05
Hallo Chris,

attr WEB longpoll 1

# $Id: 01_FHEMWEB.pm 5080 2014-03-01 08:02:45Z rudolfkoenig $


Das RAW reading wird ja auch immer schön aktualisiert, nur state wird nicht aktualisiert. Im EventMonitor sieht man jede Aktualisiertung.
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 09 Mai 2014, 09:28:58
Hallo,

Mit der Version 5080 habe ich das gleiche Verhalten, state wird nicht aktualisiert. Das betrifft aber nicht nur ModbusRegister sondern alle Bausteine. Du kannst es mit einem Dummy testen:

define d1 dummy
define at_d1 at +*00:00:01 {fhem "set d1 ".(ReadingsVal("d1","state",0)+1)}


Wenn du auf d1 gehst wird state nicht mehr aktualisiert.

In r5452 vom 6.4.2014 wurde dies geändert. Entweder musst du ein Update machen oder 01_FHEMWEB ändern. Details dazu gibt es hier:
http://forum.fhem.de/index.php/topic,22029.msg156430.html#msg156430 (http://forum.fhem.de/index.php/topic,22029.msg156430.html#msg156430), Beiträge 5 und 12.

Grüße,

ChrisD

Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: oniT am 21 Juli 2014, 21:50:49
Hallo ChrisD,

würdest Du mir hier bitte helfen? Warum kann ich kein Coil schreiben?

Ich gebe in die Befehlszeile ein:
{write_modbus_coil(161,1)}


und bekomme im Logfile zurück:


2014.07.21 21:33:58 1: write error 161 Wert 1, er 7 ex 3


An was kann das liegen? Mit dem Modbus Scanner kann ich den Wert auf Coil 161 schreiben. Aber nicht über fhem. Im Code steht immer noch:


write_modbus_coil($$)
{
  if ($m->write_single_coil($_[0], $_[1])) {
    $m->close();
  } else {
    Log 1, Log 1, "write error $_[0] Wert $_[1], er ".$m->last_error()." ex ".$m->last_except();
    $m = MBclient->new();
    # define server target
    $m->host("192.168.1.150");
    $m->unit_id(1);
  }
}


Danke,

Gruß
Tino
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 21 Juli 2014, 22:37:35
Hallo,

Die Meldung kann auftreten wenn du die ursprüngliche MBClient.pm-Datei verwendest. Diese enthält 2 Fehler durch die das Schreiben von Coils je nach Gerät nicht oder fehlerhaft funktioniert. Schau dir die Zeilen 372 und 373 von MBClient.pm an, wenn da
  $bit_value = ($bit_value) ? 0xFF : 0;
  my $tx_buffer = $self->_mbus_frame(WRITE_SINGLE_COIL, pack("nC", $bit_addr, $bit_value));
steht, kann es nicht gehen. Richtig muss es so sein:
  $bit_value = ($bit_value) ? 0xFF00 : 0;
  my $tx_buffer = $self->_mbus_frame(WRITE_SINGLE_COIL, pack("nn", $bit_addr, $bit_value));

Du kannst die beiden Zeilen entweder selbst ändern oder deine MBClient durch die angehängte Version ersetzen (ist die Gleiche wie in Beitrag 85) und mit 'reload MBClient' aktivieren.

Falls deine MBClient bereits auf dem aktuellen Stand ist kann ich dir eine Version mit erweiterten Debug-Ausgaben schicken um den Fehler einzugrenzen.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: oniT am 22 Juli 2014, 20:26:35
Hallo ChrisD,

es funktioniert jetzt. Die betreffende Zeile korrekt, es scheint am nicht durchgeführten Reload gelegen zu haben. Nach diesem ist es nun möglich ein Coil zu schreiben.

Danke nochmals,

Gruß
Tino
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: oniT am 22 Juli 2014, 21:27:28
Hallo ChrisD,

jetzt habe ich doch eben im Logfile diese Meldung gesehen:


2014.07.22 20:41:57 1: write error 107 Wert 1, er 0 ex 0


Diese Meeldung kommt nur wenn ich den Wert 1 schreibe. Der Wert 1 wird aber trotzdem übernommen. Wird eine 0 geschrieben wird auch diese übernommen und keine Meldung im Logfile ausgegeben.

Dies zur Info.

Gruß
Tino
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 23 Juli 2014, 22:00:42
Hallo,

Die Antwort auf den Schreibbefehl wird nicht korrekt ausgewertet, in MBClient.pm muss dafür die Zeile 383 von
  my ($rx_bit_addr, $rx_bit_value) = unpack 'nC', $f_body;
in  my ($rx_bit_addr, $rx_bit_value) = unpack 'nn', $f_body;

geändert werden.

Anbei eine korrigierte Version von MBClient.pm.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: oniT am 25 Juli 2014, 18:17:41
Hallo ChrisD,

vielen Dank, es funktioniert.

Gruß
Tino
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: qwikser am 02 August 2014, 22:16:58
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
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 03 August 2014, 21:59:08
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
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: Christian77 am 17 August 2014, 09:20:52
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
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 17 August 2014, 18:11:47
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
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: Christian77 am 18 August 2014, 08:29:51
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
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 18 August 2014, 09:51:48
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
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: Christian77 am 18 August 2014, 20:36:20
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
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: Christian77 am 18 August 2014, 21:03:25
Hallo,

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

Viele Grüße,

Christian
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 18 August 2014, 22:23:28
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
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: Christian77 am 19 August 2014, 08:10:10
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
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 19 August 2014, 18:19:04
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 (https://github.com/ChrisD70/FHEM-Modules) zu finden.
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: Christian77 am 20 August 2014, 22:48:58
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
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 21 August 2014, 09:04:27
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
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: Christian77 am 21 August 2014, 21:43:13
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
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 21 August 2014, 22:14:38
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
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: pc1246 am 22 August 2014, 13:03:53
Hallo ChrisD

Mir fehlt irgendwo eine Info!? Ich habe allerdings auch nicht das Modbus-Diplom! Wo definiere ich, welche Daten (Ich benutze extra nicht Variablen) abgeholt/geschrieben werden. Ich moechte eine S7 anbinden, habe auch die passenden Bausteine, aber finde noch nicht so ganz den Weg zwischen den Beiden! Lege ich einfach nur einen Bereich fest, in dem ich dann auf beiden Seiten fuer das richtige Versorgen der Informationen sorgen muss? Kann ich dann mehrere Bereiche definieren, um einmal Ausgaenge einmal Eingaenge einmal Merker usw. zu kommunizieren? Bei Wago, kenne ich ein bisschen, ist das ja etwas anders, da liegt das doch alles irgendwie hintereinander, oder?
Sorry fuer soviel Unwissenheit, aber mir fehlt wirklich nur derAnsatz!

Danke und Gruss

Christoph
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 22 August 2014, 15:52:51
Hallo,

Welche S7 (1200, 300/400 mit/ohne CP) möchtest du wie (seriell, Ethernet) anbinden ?

Bei der 1200 kannst du MB_SERVER über die PN-Schnittstelle verwenden, der Datenaustausch erfolgt für Register entweder über einen DB oder über Merker. Bitzugriffe sind nicht auf DBs möglich, nur direkt auf Ein- und Ausgänge. Beim Aufruf von MB_SERVER übergibst du in MB_HOLD_REG die Adresse wo die Daten sind, aus FHEM kannst du dann über das Register 40001 auf das erste Wort zugreifen.

Grüße,

ChrisD


Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: pc1246 am 22 August 2014, 16:27:55
Zitat von: ChrisD am 22 August 2014, 15:52:51
Hallo,

Welche S7 (1200, 300/400 mit/ohne CP) möchtest du wie (seriell, Ethernet) anbinden ?


Grüße,

ChrisD

Ne noch S7-300 mit Ethernet!
Register 40001 ??? Ich muss noch mal alles durchlesen!

Danke
Christoph
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 22 August 2014, 16:55:39
Hallo,

Bei der 300 ist die Konfiguration es etwas aufwendiger, es gibt aber von Siemens einen Modbus TCP Wizard der bei der Erstellung der Konfiguration hilft. In diesem kannst du die Modbus-Daten einzelnen DBs zuordnen. Coils werden von FHEM aus ab 1, Inputs ab 10001, Input Registers ab 30001 und Holding Registers ab 40001 angesprochen.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: pc1246 am 01 Oktober 2014, 00:22:07
Hallo ChrisD

Rein theoretisch funktioniert die Kommunikation mit der S7-300! Praktisch kann ich auch auf die S7 schreiben und von Ihr lesen! Du schreibst in http://forum.fhem.de/index.php/topic,12655.msg193450.html#msg193450 , dass mit "attr MBC01 webCmd on:off:on-for-timer 1" eine Schaltflaeche angezeigt wird.
Das funktioniert natuerlich auch, aber man kann ja die Schaltflaeche nicht betaetigen, da es ja ein Input ist! Wo ist jetzt mein Problem!
Mein define sieht so aus: define MBTest01 ModbusCoil 0 16288
Ich wuerde gerne auch coils schreiben, oder geht das nicht?

Gruss Christoph
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: pc1246 am 01 Oktober 2014, 10:02:29
Hallo
Schreiben geht, wenn dann das Register kleiner als 10000 gewaehlt wird! Dafuer habe ich aber ein anderes Problem. Lege ich mehrere Coils an, so werden diese nicht richtig gelesen. Ist das auf anderen Steuerungen auch so? Ich habe heute morgen dann um 1:38Uhr aufgegeben, da ja um 5:45 der Wecker schon wieder klingelt! Ich vermute es wird nicht wirklich ein Bit geholt, sondern ein Wort, und auf das Bit wird gefiltert! Wenn ich jetzt 5 hintereinander liegende Bits abfrage, so sehe ich anscheinend nur das zuletzt abgefragte! Im S7 sehe ich auch nur, dass fuenfmal ein Bit geholt wird, nicht einmal fuenf Bit!
Meine Bits:
define A_5_0 ModbusCoil 0 10041
define A_5_1 ModbusCoil 0 10042
define A_5_2 ModbusCoil 0 10043
define A_5_3 ModbusCoil 0 10044
define A_5_4 ModbusCoil 0 10045

Gruss Christoph
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 01 Oktober 2014, 17:46:19
Hallo,

In der ursprünglichen Modbus-Implemtierung waren verschiedene Bereiche für den Datenzugriff vorgesehen:
Coilnummern 1-9999 : Output-Bereich, lesen & schreiben
Coilnummern 10001-19999 : Input-Bereich, nur lesen
Registernummern 30001-39999 : Input-Bereich, nur lesen
Registernummern 40001-49999 : Output-Bereich, lesen & schreiben

Dabei wurden die einzelnen Bereiche über unterschiedliche FCs und den Adressen 0-9998 angesprochen.

Ich habe diese Bereiche in den Modulen integriert da auch heute noch diverse Geräte darüber angesprochen werden. Wie du aber beobachtet hast kannst du nicht auf die Input-Bereiche schreiben. Es gibt keinen FC der dies erlauben würde.

Du kannst diese Bereiche zwar über das Attribut disableRegisterMapping abschalten, allerdings werden dann die Coil/Registernummern direkt als Adressen durchgereicht (muss z.B bei Steuerungen von Wago so gemacht werden).

Im Moment werden fortlaufende Zugriffe nicht zusammengefasst, bei deinem Beispiel werden deshalb 5 Aufträge für jeweils ein einzelnes Bit ausgeführt. Die SPS muss dafür sorgen dass das korrekte Bit aus dem Byte/Wort entnommen und übertragen wird, auf FHEM-Seite kommt nur 0 oder 1 an. Um zu sehen was genau übertragen wird kannst du im ModbusTCPServer das Attribut 'verbose' für kurze Zeit auf 5 setzen. In der FHEM-Logdatei sollten dann solche Einträge auftauchen:

Zitat2014.10.01 17:34:22.257 5: SimpleWrite [00 29 00 00 00 06] 00 02 00 29 00 01
2014.10.01 17:34:22.258 5: Received [00 29 00 00 00 04] 00 02 01 00
2014.10.01 17:34:22.258 5: wago dispatch ModbusCoil:0:41:2:1:0
2014.10.01 17:34:22.258 5: ModbusCoil_Parse: 2 0 41 1 0

Kannst du einen Auszug davon posten ?

Das Zusammenfassen von Leseaufträgen steht noch immer auf meiner Todo-Liste, ich hatte bis jetzt aber noch nicht die Zeit es zu implementieren und zu testen.

Grüße,
ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: pc1246 am 05 Oktober 2014, 14:38:53
Hallo Chris

Ja mache ich gleich! War jetzt ein paar Tage nicht online, und habe Deinen Post gerade erst gelesen! Die VM startet gerade neu, dauert dummerweise 10 Minuten, dann kann ich Dir einen Log-Auszug posten!
Gruss Christoph
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: pc1246 am 05 Oktober 2014, 14:53:16
Hallo Chris

2014.10.05 14:47:01 5: SimpleWrite [00 2C 00 00 00 06] 00 02 00 2C 00 01
2014.10.05 14:47:01 5: Received [00 2C 00 00 00 04] 00 02 01 00
2014.10.05 14:47:01 5: MB_S7 dispatch ModbusCoil:0:44:2:1:0
2014.10.05 14:47:01 5: ModbusCoil_Parse: 2 0 44 1 0
2014.10.05 14:47:02 5: AddRQueue [27 0E 00 00 00 06] 00 04 27 0E 00 01
2014.10.05 14:47:02 5: SimpleWrite [27 0E 00 00 00 06] 00 04 27 0E 00 01
2014.10.05 14:47:02 5: AddRQueue [00 28 00 00 00 06] 00 02 00 28 00 01
2014.10.05 14:47:02 5: adding to RQUEUE - 1
2014.10.05 14:47:02 5: AddRQueue [00 29 00 00 00 06] 00 02 00 29 00 01
2014.10.05 14:47:02 5: adding to RQUEUE - 2
2014.10.05 14:47:02 5: AddRQueue [00 2A 00 00 00 06] 00 02 00 2A 00 01
2014.10.05 14:47:02 5: adding to RQUEUE - 3
2014.10.05 14:47:02 5: AddRQueue [00 2B 00 00 00 06] 00 02 00 2B 00 01
2014.10.05 14:47:02 5: adding to RQUEUE - 4
2014.10.05 14:47:02 5: AddRQueue [00 2C 00 00 00 06] 00 02 00 2C 00 01
2014.10.05 14:47:02 5: adding to RQUEUE - 5
2014.10.05 14:47:02 5: Received [27 0E 00 00 00 05] 00 04 02 00 00
2014.10.05 14:47:02 5: MB_S7 dispatch ModbusRegister:0:9998:4:1:0
2014.10.05 14:47:02 5: ModbusRegister_Parse: 4 0 9998
2014.10.05 14:47:02 4: RQUEUE: 5
2014.10.05 14:47:02 5: SimpleWrite [00 28 00 00 00 06] 00 02 00 28 00 01
2014.10.05 14:47:02 5: Received [00 28 00 00 00 04] 00 02 01 03
2014.10.05 14:47:02 5: MB_S7 dispatch ModbusCoil:0:40:2:1:3
2014.10.05 14:47:02 5: ModbusCoil_Parse: 2 0 40 1 3
2014.10.05 14:47:02 4: RQUEUE: 4
2014.10.05 14:47:02 5: SimpleWrite [00 29 00 00 00 06] 00 02 00 29 00 01
2014.10.05 14:47:02 5: Received [00 29 00 00 00 04] 00 02 01 01
2014.10.05 14:47:02 5: MB_S7 dispatch ModbusCoil:0:41:2:1:1
2014.10.05 14:47:02 5: ModbusCoil_Parse: 2 0 41 1 1
2014.10.05 14:47:02 4: RQUEUE: 3
2014.10.05 14:47:02 5: SimpleWrite [00 2A 00 00 00 06] 00 02 00 2A 00 01
2014.10.05 14:47:02 5: Received [00 2A 00 00 00 04] 00 02 01 00
2014.10.05 14:47:02 5: MB_S7 dispatch ModbusCoil:0:42:2:1:0
2014.10.05 14:47:02 5: ModbusCoil_Parse: 2 0 42 1 0
2014.10.05 14:47:02 4: RQUEUE: 2
2014.10.05 14:47:02 5: SimpleWrite [00 2B 00 00 00 06] 00 02 00 2B 00 01
2014.10.05 14:47:02 5: Received [00 2B 00 00 00 04] 00 02 01 00
2014.10.05 14:47:02 5: MB_S7 dispatch ModbusCoil:0:43:2:1:0
2014.10.05 14:47:02 5: ModbusCoil_Parse: 2 0 43 1 0
2014.10.05 14:47:02 4: RQUEUE: 1
2014.10.05 14:47:02 5: SimpleWrite [00 2C 00 00 00 06] 00 02 00 2C 00 01
2014.10.05 14:47:02 5: Received [00 2C 00 00 00 04] 00 02 01 00
2014.10.05 14:47:02 5: MB_S7 dispatch ModbusCoil:0:44:2:1:0
2014.10.05 14:47:02 5: ModbusCoil_Parse: 2 0 44 1 0
2014.10.05 14:47:03 5: AddRQueue [27 0E 00 00 00 06] 00 04 27 0E 00 01
2014.10.05 14:47:03 5: SimpleWrite [27 0E 00 00 00 06] 00 04 27 0E 00 01
2014.10.05 14:47:03 5: AddRQueue [00 28 00 00 00 06] 00 02 00 28 00 01
2014.10.05 14:47:03 5: adding to RQUEUE - 1
2014.10.05 14:47:03 5: AddRQueue [00 29 00 00 00 06] 00 02 00 29 00 01
2014.10.05 14:47:03 5: adding to RQUEUE - 2
2014.10.05 14:47:03 5: AddRQueue [00 2A 00 00 00 06] 00 02 00 2A 00 01
2014.10.05 14:47:03 5: adding to RQUEUE - 3
2014.10.05 14:47:03 5: AddRQueue [00 2B 00 00 00 06] 00 02 00 2B 00 01
2014.10.05 14:47:03 5: adding to RQUEUE - 4
2014.10.05 14:47:03 5: AddRQueue [00 2C 00 00 00 06] 00 02 00 2C 00 01
2014.10.05 14:47:03 5: adding to RQUEUE - 5


Ich hoffe das reicht so!? Der Anhang enthaelt ein Bild von dem tatsaechlichen Zustand der Ausgaenge!

Gruss Christoph
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 05 Oktober 2014, 19:06:44
Hallo,

Der Auszug aus dem Log ist perfekt. Ich habe aber ein Problem bei der Interpretation der Daten.

Hast du den Modbus-TCP Wizard von Siemens verwendet ?

Wenn ja, kannst du noch einen Screenshot vom Fenster 'Modbus TCP Adressen Abbildung' posten.

Danke,
ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: pc1246 am 06 Oktober 2014, 12:32:13
Hallo ChrisD

Nein ich habe den Wizard nicht benutzt! Ich habe aus dem SPS-Forum einen Modbus Server, den ich etwas modifizieren musste, da meine CPU etwas klein ist! Grundsaetzlich liegen meine Daten aber nur in einem DB155! Im S7 Code werden dann die entsprechenden Daten hin und herkopiert!
Natuerlich ist es Quatsch, dass ich die Ausgaenge direkt als schreibend angelegt habe, aber das lag einfach an der Uhrzeit! Ich habe im S7 auch die Abfrage der einzelnen Bits gesehen, aber irgendwie kommen die in fhem nicht richtig an! Heute abend kann ich das gerne noch mal schoen machen, so dass ich Dir dann alle Daten zur Verfuegung stellen kann!
Grundsaetzlich soll es aber so werden, dass ich zumindest die digitalen Ausgaenge direkt auf 10000ff legen wollte, so dass A 0.0 dann 10000 entspricht. Die "echten" Eingaenge analog dazu von 1-200, und danach dann Merker- bzw Datenbits!
Gruss Christoph
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 06 Oktober 2014, 22:55:32
Hallo,

Ich habe mir die Logs nochmal angesehen. Die Definition von A_5_0 führt durch das Mapping zum Lesen der Adresse 40 mit FC2. Als Antwort kommt der Wert 3 zurück, was bei einem Einzelbit-Zugriff nicht sein sollte.

Wenn du den Modbus-Baustein von L. Weiß verwendest sollte Adresse 40 DB155.DBX5.0 entsprechen. Kannst du ein Bild vom DB155 machen ? Der Rückgabewert von 3 wäre dann auch erklärbar da die Kopierschleife im FB ein Mal zuviel durchlaufen wird.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: pc1246 am 07 Oktober 2014, 07:40:10
Hallo

Ja das íst die Adresse und der Baustein! Heute abend klappt es dann wirklich, aber verstehen will ich das nicht! 5_1 wird ja richtig angezeigt, und die 5_0 gibt eine 3 zurueck, obwohl das eigene Bit gar nicht gesetzt ist. und was ist mit 5_3? Der ist voellig unter den Tisch gefallen! Wenn Du meinst, dass es an dem Baustein von L.Weiss liegt, dann setze ich mich erstmal an den ran, da der von mir eh umgebaut werden muss, da er ja so nicht in meine Steuerung passt (Lokaldatenspeicher)!
Danke fuer Deine Hilfe
Gruss Christoph
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: pc1246 am 07 Oktober 2014, 20:18:04
Hallo ChrisD
Der Hinweis mit der Kopierschleife war auch Gold wert! Schon geht es, da kann ich den Umbau erstmal hintenan stellen!
Danke nochmals
Christoph
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: lechez am 23 Oktober 2014, 04:58:21
Hallo,

vielleicht kann mir jemand helfen mit MODBUS RTU.

Mein Stromzähler hat die Adresse 60 und das erste Holding Register möchte ich auslesen.

Habe es so gemacht:

define MB_RTU ModbusRTU /dev/ttyUSB1@9600
attr MB_RTU charformat 8E1
attr MB_RTU pollIntervall 5
attr MB_RTU verbose 5

define U_L1 ModbusRegister 60 30001
attr U_L1 plcDataType REAL_BE
attr U_L1 registerType Holding


als Antwort kommt:

2014.10.23 04:54:36 5: AddRQueue 3C 04 00 01 00 02 24 E6
2014.10.23 04:54:36 5: SimpleWrite 3C 04 00 01 00 02 24 E6
2014.10.23 04:54:36 5: Read 3C
2014.10.23 04:54:36 5: Read 3C 84 01
2014.10.23 04:54:36 5: Read 3C 84 01 13 0C
2014.10.23 04:54:36 5: Received 3C 84 01 13 0C
2014.10.23 04:54:36 2: ModbusRTU: except (code 1)

Es ich glaube er scheibt was (04) und liest nicht.

Vielleicht kann mir remand sagen wie ich ein Holding Register mit dem Modul auslese?

Gruß
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: lechez am 23 Oktober 2014, 05:32:42
Selber gelöst :)

Ich sollte so früh nicht schon anfangen  ;D.

Ich hab ja das flasche Register angesprochen mit 40001  geht es. .:)

Danke ChrisD für die tolle Weiterentwicklung!

Gruß
lechez
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: qwikser am 07 November 2014, 20:07:46
Hallo,

wie bereits erwähnt hatte ich ja mein MAX! System mit der "99_modbus.pm & MBclient.pm" an meine  Wago weiter geleitet.
Da dies aber fhem beim "Update" der Daten so arg strapaziert, wollte ich es jetzt auch mal mit dem "36_ModbusTCPServer.pm" probieren.
Einzelne Bits mit "37_ModbusCoil.pm" und auch ganze bytes mit "37_ModbusRegister.pm" funktioniert wunderbar.

Nur habe ich jetzt das Problem, dass ich nicht so recht weiß wie ich das jetzt mit den MAX! Daten in fhem verknüpfen soll.  ???

Hier mal ein Beispiel vom "MBclient.pm"
1.

define stellmotor_temp_soll_kueche dummy
attr stellmotor_temp_soll_kueche group Küche
attr stellmotor_temp_soll_kueche room Wago
attr stellmotor_temp_soll_kueche stateFormat state °C
define at_write_stellmotor_temp_soll_kueche at +*00:01:00 {write_modbus(12300,ReadingsVal("MAX_008695","state", 0)*10)}
define at_read_stellmotor_temp_soll_kueche at +*00:05:05 {fhem("set stellmotor_temp_soll_kueche ".read_modbus_zaehler(12300)/10)}

2.

define haustuer_aufzu_flur dummy
attr haustuer_aufzu_flur group Flur
attr haustuer_aufzu_flur room Wago
define act_haustuer_aufzu_flur notify MAX_0850c2:onoff.* {write_modbus_coil(12943,$EVTPART1)}
define at_read_haustuer_aufzu_flur at +*00:05:05 {fhem("set haustuer_aufzu_flur ".((read_modbus_coil(12943) eq "on")?"Offen":"Geschlossen"))}

3.

define Steckdose_A_wago_EIN dummy
attr Steckdose_A_wago_EIN group Ventilator Schlafzimmer
attr Steckdose_A_wago_EIN room Funker-Sender
define at_read_Steckdose_A_wago_EIN at +*00:00:03 {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");;} }



.. mit dem 3ten Beispiel schalte ich mit einem Funkmodul am Raspberry eine Funksteckdose aus dem Baumarkt.

Vielen dank schon mal im voraus
MfG.
Daniel
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 07 November 2014, 21:45:37
Hallo,

Hier ein möglicher (aber nicht ganz ausgetesteter) Vorschlag für die Übertragung:

1.
define stellmotor_temp_soll_kueche ModbusRegister 0 12300
attr stellmotor_temp_soll_kueche conversion 0.1:0
attr stellmotor_temp_soll_kueche group Küche
attr stellmotor_temp_soll_kueche room Wago
attr stellmotor_temp_soll_kueche stateFormat state °C
attr stellmotor_temp_soll_kueche disableRegisterMapping 1
define NMAX_008695_to_Wago notify MAX_008695 set stellmotor_temp_soll_kueche $EVTPART1


2.
define haustuer_aufzu_flur ModbusCoil 0 12943
attr haustuer_aufzu_flur disableRegisterMapping 1
attr haustuer_aufzu_flur group Flur
attr haustuer_aufzu_flur room Wago
define act_haustuer_aufzu_flur notify MAX_0850c2:onoff.* set haustuer_aufzu_flur $EVTPART1


3.
define Steckdose_A_wago_EIN ModbusCoil 0 13088
attr Steckdose_A_wago_EIN disableRegisterMapping 1
attr Steckdose_A_wago_EIN event-on-change-reading state
attr Steckdose_A_wago_EIN eventMap off:INAKTIV on:AKTIV
attr Steckdose_A_wago_EIN group Ventilator Schlafzimmer
attr Steckdose_A_wago_EIN room Funker-Sender
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");;} }


Die Übertragung unterscheidet sich nicht allzuviel von deiner bisherigen Version, lediglich die Syntax ändert sich. Du musst weiterhin die Zuweisung über notify machen.

Wie häufig ein Wert von der SPS gelesen wird kann über das Attribut updateIntervall in Sekunden eingestellt werden, z.B.
attr stellmotor_temp_soll_kueche updateIntervall 305 für 5:05. Default ist 0.1 (also 100 ms). Falls dieser Wert kleiner ist als das Attribut pollIntervall des Serverbausteines, hat der Wert des Serverbausteines Vorrang. Default beim Serverbaustein ist 3 s.

Ich habe eine experimentelle Version von 36_ModbusTCPServer welche ohne externes notify auskommt, allerdings ist sie noch nicht ganz ausgereift und die Konfiguration ist etwas komplizierter.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: qwikser am 07 November 2014, 22:11:19
Hallo ChrisD,

einfach der Wahnsinn wie du immer direkt zur Stelle bist wenn jemand Hilfe braucht, HUT AB!

Habe mal einfach alles ins fhem kopiert. Zum ersten "Paket", der Sollwert Übertragung ist es jetzt so, dass ich in der SPS kurz sehe das er was schreibt, es aber dann direkt wieder auf 0 geschrieben wird.

Der Stellmotor im MAX! liefert mir diese Readings die ich weiterleiten will:
"battery - ok" "desiredTemperature - 17.0" "temperature - 20.1"
Ich denke das in deinem Code

define NMAX_008695_to_Wago notify MAX_008695 set stellmotor_temp_soll_kueche $EVTPART1

noch irgendwo der Aufruf zu einem der oben genannten Readings fehlt.
Vielleicht so?

define NMAX_008695_to_Wago notify MAX_008695 set stellmotor_temp_soll_kueche:(temperature)


Das 2te "Packet" mit dem Magnetkontakt geht leider auch nicht. Als Reading lieftert dieser mir übrigens "onoff - 1"  Also 1 für offen 0 für zu.
Das 3te "Packet" mit der Steckdose funktionierte auf Anhieb. ;D

MfG.
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 08 November 2014, 09:09:15
Hallo,

Im notify für den Sollwert fehlt das Reading das weitergeleitet werden soll. So sollte es gehen:

define NMAX_008695_to_Wago notify MAX_008695:desiredTemperature.* set stellmotor_temp_soll_kueche $EVTPART1

Das Reading (desiredTemperature) welches übertragen werden soll kommt nach dem Namen des Devices (MAX_008695).

ModbusCoil unterstützt die Werte 0 und 1 nicht, deshalb funktioniert der Türkontakt nicht. Ich werde dies nachrüsten. Bis dahin sollte dies funktionieren:
define act_haustuer_aufzu_flur notify MAX_0850c2:onoff.* {fhem "set haustuer_aufzu_flur ".($EVTPART1==1?"on":"off")}


Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: qwikser am 25 November 2014, 18:55:16
Hi Chris,

danke, deine Tipps haben prima funktioniert!!
..habe jetzt (gestern und heute) soweit fast  ::) alles mit dem "neuen" Modul angepasst, und es läuft um längen besser als das "alte".. auch Fhem lässt sich jetzt wieder im WebInterface bedienen.  :P

Habe jetzt nur noch das Problemchen mit der Lautstärke Anpassung eines StreamRadios von meiner Wago aus.
Der alte Code sah so aus:

define radio_volume dummy
attr radio_volume group Radio via Wago
attr radio_volume room Media
attr radio_volume stateFormat state %
define at_read_radio_volume at +*00:00:05 {fhem("set radio_volume ".read_modbus_zaehler(12343))}
define Nradio_volume notify radio_volume {\
my $vol = Value("radio_volume");;\
fhem "set SRadio VOLUME $vol";;\
}


Aktuell sieht mein Versuch so aus:

define radio_volume ModbusRegister 0 12343
attr radio_volume disableRegisterMapping 1
attr radio_volume room Media
attr radio_volume group Radio
attr radio_volume alias Volume
attr radio_volume stateFormat state %
define Nradio_volume notify radio_volume $EVTPART1 {my $vol = ( Value("radio_volume") ) {fhem ("set SRadio VOLUME $vol");;} }


Der Wert wird auch schon richtig aus der SPS gelesen, nur wird der Befehl zur Anpassung der Lautstärke nicht ausgeführt.  :-\

Danke schon mal im Voraus!
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 25 November 2014, 20:49:24
Hallo,

Versuch mal das notify so zu ändern:
define Nradio_volume notify radio_volume set SRadio VOLUME $EVTPART0

Zusätzlich musst du noch das Attribut event-on-change-reading von radio_volume setzen:
attr radio_volume event-on-change-reading state

Damit sollte die Lautstärke wie gewünscht übertragen werden.

Da die Werte vom Modbus regelmäßig gelesen werden sollte das Attribut event-on-change-reading bei allen Registern und Coils gesetzt sein. Dadurch werden nur Ereignisse erzeugt wenn sich der Wert ändert.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: qwikser am 03 Dezember 2014, 17:51:16
Hallo Chris,

vielen Dank!! ..dein Tipp hat wie gewöhnlich super geklappt!  ;D
Wollte jetzt noch ein paar IP Adressen im Netzwerk abfragen und auf einzelne Coils in meine SPS bringen, nur scheitere Ich wie gewöhnlich auch dadran..  ::)

Aktuell sieht es so aus:

#-------------------------------------------------------------------------------------------------------------------------------------------------------- Wago <-> iPs Netzwerk
define HandyDina PRESENCE lan-ping 192.168.178.13 10
attr HandyDina alias iPhone Carina
attr HandyDina eventMap absent:INAKTIV present:AKTIV
attr HandyDina group Smartphones
attr HandyDina room IP Überwachung
#----------------------------------------------------------------------------------------------
define HandyDina_WAGO ModbusCoil 0 13216
attr HandyDina_WAGO disableRegisterMapping 1
attr HandyDina_WAGO event-on-change-reading state
attr HandyDina_WAGO group Smartphones
attr HandyDina_WAGO room IP Überwachung
define act_HandyDina_WAGO notify HandyDina { if ( Value("HandyDina") eq "AKTIV" ) {fhem "set HandyDina_WAGO ".($EVTPART1==1?"on":"off")} }
#----------------------------------------------------------------------------------------------

Der obere Bereich funktioniert auch. Nur hapert es jetzt noch an der Übertragung.

Hatte es auch schon so versucht, auch ohne Erfolg.

define NHandyDina_WAGO notify HandyDina_WAGO { if ( Value("HandyDina") eq "AKTIV" ) {fhem "set HandyDina_WAGO ".($EVTPART1==1?"on":"off");;} }



Was Ich das letzte mal noch schreiben wollte, falls du mal eine kleine Doku zu dem Modbus Modul erstellen wolltest, kann ich dir gerne ein paar Auszüge aus meiner CFG zukommen lassen.  :)

MfG.
Daniel
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 03 Dezember 2014, 19:18:34
Hallo,

Du kannst versuchen das notify so zu ändern:
define act_HandyDina_WAGO notify HandyDina { fhem "set HandyDina_WAGO ".($EVTPART0 eq "AKTIV"?"on":"off") }


Die if-Abfrage ist nicht nötig da du bereits auf $EVTPART1 prüfst.

Kurze Erklärung zu meinem Vorschlag:
Bei einem notify auf 'state' steht der Wert in $EVTPART0 da beim Ereignis das Reading weggelassen wird (wieso weiß ich nicht). Im Ausdruck
($EVTPART0 eq "AKTIV"?"on":"off")
prüfe ich auf den vom Ereignis gelieferten Wert, hier also "AKTIV". Da es sich um eine Zeichenkette handelt verwende ich zum Vergleich 'eq' statt '=='.

Ich habe noch immer vor einen Wiki-Eintrag für die Module zu erstellen da der Thread ziemlich unübersichtlich geworden ist. Darin wollte ich einige Beispiele übernehmen. Wenn es soweit ist bin ich dankbar für jede Hilfe.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: qwikser am 03 Dezember 2014, 21:21:53
Und wie immer, dickes DANKE!  ;)
Jetzt geht das Licht auch nur noch nach Zeit Programm an wenn ich oder meine Freundin auch wirklich zu Hause sind, super Sache.
Wie gesagt, wenn du paar Beispiele brauchst, einfach fragen.

MfG.
Daniel
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: oniT am 10 Januar 2015, 23:10:46
Hallo ChrisD,

ich habe nun auch einmal die ModbusTCPServer, ModbusRegister und ModbusCoil Dateien zum Testen auf den BBB eingespielt. Dabei ist mir folgendes aufgefallen und ich habe eine Frage dazu.

Wenn ich beim Solar-Log über Modbus die Werte abhole, dann scheint dies immer nur möglich zu sein, wenn auch eine Verbindung zum Wechselrichter besteht. Sobald dies nicht mehr der Fall ist kommen disconnects.

2015.01.10 17:41:23 1: 192.168.1.160:502 reappeared (SolarLogServer)
2015.01.10 17:41:23 1: 192.168.1.160:502 disconnected, waiting to reappear (SolarLogServer)


Dies konnte ich bisher auch auf meiner FritzBox festellen. Dort frage ich bisher noch mit der zu Beginn zur Verfügung gestellten 99_UtilsModbus.pm ab. Diese Abfragen mache ich dort mit einem at jede Minute. Bei Sonnenuntergang disable ich dies bis zum Sonnenaufgang. In dieser Zeit erfolgen dann keine Abfragen und entsprechend keine Fehlermeldungen.

In den Attributen von ModbusTCPServer finde ich dort keine Möglichkeit das Öffnen der Verbindung zu unterbrechen. Übersehe ich da etwas? Gibt es eine Möglichkeit? Wenn nicht, würdest Du dies bitte bei Gelegenheit noch einbauen?

Danke

Gruß
Tino
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 11 Januar 2015, 12:57:47
Hallo,

Du kannst das Attribut 'dummy' verwenden um die Verbindung zu schließen. Bei Sonnenuntergang z.B.:
attr SolarLogServer dummy 1

Die Meldung
Zitat192.168.1.160:502 reappeared (SolarLogServer)
wird allerdings beim Löschen des Attributes bei Sonnenaufgang weiterhin im Log erschienen da sie nicht vom Modul selbst sondern von DevIO kommt.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: oniT am 11 Januar 2015, 15:54:50
Hallo ChrisD,

ok Danke. Dann setze ich dies auf dummy 1.

Jetzt ist mir ja etwas aufgefallen. Diese Meldung scheint zu kommen, wenn ich mehrere Zugriffe über Modbus auf das selbe Device geöffnet habe. Nun habe ich den Zugriff von der FritzBox disabled und schon sind die Meldungen verschwunden und der Server Status ist OK.

Somit wäre dies Problem scheinbar gelöst.

Jetzt noch zwei Dinge.

1. Da die Abfrage zur Wärmepumpe mit den Dateien aus Deinem git funktioniert, würde ich den Wikieintrag anpassen. Darf ich dort auf Dein git verweisen?

2. Für was steht die erste Zahl, in diesem Fall die 0, vor der Registeradresse?

define radio_volume ModbusRegister 0 12343


Danke

Grüße,
Tino
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 11 Januar 2015, 16:31:39
Hallo,

ZitatJetzt ist mir ja etwas aufgefallen. Diese Meldung scheint zu kommen, wenn ich mehrere Zugriffe über Modbus auf das selbe Device geöffnet habe. Nun habe ich den Zugriff von der FritzBox disabled und schon sind die Meldungen verschwunden und der Server Status ist OK.
Dein Server erlaubt wahrscheinlich nur 1 Verbindung, wenn ein 2. sich verbindet wird der 1. getrennt.

Zitat1. Da die Abfrage zur Wärmepumpe mit den Dateien aus Deinem git funktioniert, würde ich den Wikieintrag anpassen. Darf ich dort auf Dein git verweisen?
Ja, gerne.

Zitat2. Für was steht die erste Zahl, in diesem Fall die 0, vor der Registeradresse?
Die Zahl steht bei ModbusTCP für die Unit ID (0-255). Diese erlaubt es z.B. unterschiedliche Teilnehmer die an einem ModbusTCP-Gateway angeschlossen sind anzusprechen. Diese Gateways stellen die Verbindung zwischen einem seriellen Modbus und dem Ethernet her (z.B. Moxa MGate MB3170). Bei vielen 'echten' ModbusTCP-Servern wird die Unit ID ignoriert da sie eigentlich nicht mehr nötig ist. Es gibt aber auch Geräte die eine bestimmte Unit ID voraussetzen damit die Kommunikation möglich ist, meistens 0, 1 oder 255.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: oniT am 11 Januar 2015, 17:14:56
Hallo,

Zitat
Dein Server erlaubt wahrscheinlich nur 1 Verbindung, wenn ein 2. sich verbindet wird der 1. getrennt.
Das habe ich mir auch gedacht. Ich war wohl etwas zu euphorisch, die Meldungen kommen jetzt auch unabhängig ob ich die andere Verbindung geöffnet habe. Mir scheint, als kommt diese wenn ich das Abfrageintervall zu kurz halte. Ich habe im TCPServer sowie bei einem Register gelöscht, so dass die Standardeinstellungen greifen. Im Moment kommt die Meldung opened und der Logeintrag nicht.

Zitat
Ja, gerne.
Ok, danke. Da werde ich bei Gelegenheit einmal den Eintrag anpassen.

Zitat
Die Zahl steht bei ModbusTCP für die Unit ID (0-255).
Ja ok, habe ich mir fast gedacht. Es hätte allerdings auch für den FC stehen können ;-) Habe allerdings eben gelesen, dass man INPUT bzw. HOLDING Register im Attribut einstellen kann.

Gruß,

Tino
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: Tho-Gra am 15 Januar 2015, 11:06:14
Zitat von: ChrisD am 18 August 2014, 09:51:48
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

Hallo alle zusammen,

Bin gerade dabei meine Beckoff mittels Modbus mit FHEM zu verbinden.
Einen Wiki Artikel habe ich noch nicht gefunden - gibt es diesen mittlerweile?
Ist die aktuellste Version noch die von Beitrag 151?

Vielen Dank für die bereits getane Mühe.

Grüße

Tho-Gra
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: bk9050 am 15 Januar 2015, 12:52:19
Hallo Tho-Gra,

welche Beckhoff-Steuerung setzt Du ein?

Ich benutze BC9000 und habe die auch mal testweise mit FHEM via Modbus verbunden. Hier gibt es auch noch etwas dazu:

http://www.mikrocontroller.net/topic/325144#new

Code-Example bei Bedarf (für den Testaufbau).

Endgültig ist meine Steuerung noch nicht völlig fertig, aber im Prinzip fuktionierte das mit dem FHEM schon ganz gut.

Viel Erfolg
Hermann-Josef (bk9050)
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: Tho-Gra am 15 Januar 2015, 12:55:58
Hi bk9050,

Ich habe eine BX9000. Muss gestehen das ich bisher noch sehr verwirrt bin. Habe noch nie mit Modbus gearbeitet.

Könntest du mir einen Auszug aus deinen Programmen zukommen lassen?


Eine weitere Frage hätte ich da noch.
Was genau ist ein Coil?

Vielen Dank

Grüße

Tho-Gra

PS: Ich lese mich nun durch dein Link durch :) - Danke nochmal dafür
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: bk9050 am 15 Januar 2015, 13:03:15
Hi Tho-gra,

ein coil ist ein schaltbares Bit. Siehe hier:

http://en.wikipedia.org/wiki/Modbus

"Many of the data types are named from its use in driving relays: a single-bit physical output is called a coil, and a single-bit physical input is called a discrete input or a contact."

Ja, ich versuche Dir das zu schicken. Du solltest das Projekt in das Beckhoff-Tool einlesen (importieren können), denke ich.

Gruß
Hermann-Josef (bk9050)
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 18 Januar 2015, 19:19:27
Hallo,

Der Link (https://github.com/ChrisD70/FHEM-Modules) in Beitrag 151 verweist noch immer auf die aktuelle Version. Einen Wiki-Artikel gibt es noch immer nicht, ich bin aber dabei die Dokumentation der Module fertigzustellen und werde mich danach ums Wiki kümmern.

Grüße,

ChrisD
Titel: Modbus/RS485 über TCPIP, Beispiel Stromzähler SDM630
Beitrag von: Dieter1 am 15 Februar 2015, 10:36:25
Hallo ChrisD,

danke für deine Modbus Module. Super.

Ich habe einen Stromzähler SDM630 mit RS485/Modbus Anschluss.
Da ich noch weitere RS485 Messstellen plane, meine seriellen Anchlüsse begrenzt sind und neue serielle Leitungen mir ein Greuel sind  :-) wollte ich auf das setzen, was ich überall verfügbar habe: TCPIP over LAN, WLAN oder dLAN.
Lösung: Modbus über TCPIP schicken und vorort in RS485 wandeln. TCPIP<->RS485 Wandler (TCP232-24, ca. 20,- € bei ebay)

Ich benötige als Protokoll also nicht ModbusTCP, sondern schicke nur ModbusRTU über TCP.

Da dein Modul 36_ModbusRTU.pm auf DevIO.pm aufsetzt war das kein Problem. 2 kleine Erweiterungen sind erforderlich:
1. Akzeptieren von TCPIP:Port Adressen:
    ModbusRTU_Define fügt in Init bei fehlender Baudrate "@9600" an. Damit ist eine IP:Port Adresse für DevIO nicht mehr erkennbar.
    Die Zeile "$dev .= "\@9600" if( $dev !~ m/\@/ );" habe ich bei mir auskommentiert. Bitte erweitere die Erkennung auf TCPIP:Port Adressen und füge dann keine Baudrate hinzu.
2. In ModbusRTU_SimpleWrite neben USB und DIO auch die Option TCP hinzufügen:
    $hash->{USBDev}->write($msg)    if($hash->{USBDev});
    syswrite($hash->{DIODev}, $msg) if($hash->{DIODev});
   syswrite($hash->{TCPDev}, $msg) if($hash->{TCPDev});

Mit diesen beiden Änderungen funktioniert ModbusRTU über TCPIP prima. Bitte baue das in dein Modul ein, ist sicher auch für andere interessant und ich möchte dein Standardmodul nutzen.

Hier als Beispiel meine Definition mit Abfrage der Phase 1 des Stromzählers in W.
1 ist die ModbusAdresse des Stromzählers, 12 das Register im Stromzähler für P1.


define EVU_Meter ModbusRTU 192.168.178.101:20108

define EVU_P1_P ModbusRegister 1 12
   attr EVU_P1_P IODev EVU_Meter
   attr EVU_P1_P plcDataType REAL_BE
#   attr EVU_P1_P registerType Holding
   attr EVU_P1_P registerType 4   # Input
   attr EVU_P1_P disableRegisterMapping 1
   attr EVU_P1_P stateFormat {sprintf("%d", ReadingsVal($name,"state",0))}
   attr EVU_P1_P updateIntervall 60
   attr EVU_P1_P userReadings W {sprintf("%d", ReadingsVal($name,"state",0))}
#   attr EVU_P1_P verbose 5


Mehrere Geräte an einem "lokalen" Modbus sollten kein Problem sein, habe ich aber noch nicht ausprobiert. Jedenfalls kann ich damit orts- und portunabhängig viele Modbusse ansprechen.

Danke noch einmal für deine Modbus Implementierung

Dieter
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: Dieter1 am 15 Februar 2015, 18:47:06
Hallo ChrisD,

auf ein Problem bin ich in den Modbus Modulen gestossen:
Attribute "registerType Input" funktioniert nicht, da musste ich "registerType 4" verwenden, ansonsten ist das Ergebnis immer "3" (=Holdung).
Gleiches gilt, wenn "disableRegisterMapping 1" vor "registerType 4" angegeben wird, dann ist das Ergebnis "registerType 3".

Es wird also  "SimpleWrite 01 03 00 0C 00 02 04 08"
anstelle von  "SimpleWrite 01 04 00 0C 00 02 B1 C8" gesendet.

Diese Definition unten funktioniert zwar, aber so hattest du das bestimmt nicht gedacht:

define EVU_P1_P ModbusRegister 1 12
   attr EVU_P1_P IODev EVU_Meter
   attr EVU_P1_P plcDataType REAL_BE
#   attr EVU_P1_P registerType Holding
   attr EVU_P1_P registerType 4   # Input
   attr EVU_P1_P disableRegisterMapping 1

Grüsse

Dieter
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 15 Februar 2015, 20:30:02
Hallo,

Danke für den Hinweis für die Verbindung über TCP/IP, ich werde das Modul dementsprechend anpassen.

Was die Funktion von registerType und disableRegisterMapping angeht ist es etwas komplizierter. Das Attribut disableRegisterMapping wurde eingeführt für die Kommunikation mit Wago-Steuerungen da bei diesen mit Adressen (0-basiert) und nicht mir Registernummern (1-basiert) gearbeitet wird. Wenn registerType auf 4 gesetzt wird sollte dies das gleiche bewirken wie wenn registerType nicht auf 'Input' steht da nur dies abgefragt wird. Ich werde mir den Code nochmal ansehen.

Für deine Anwendung sollte disableRegisterMapping auch nicht nötig sein, in der Dokumentation des SDM630 sind 'normale' Registernummern angegeben, kannst du versuchen die Definition so zu ändern:

define EVU_P1_P ModbusRegister 1 30013
   attr EVU_P1_P IODev EVU_Meter
   attr EVU_P1_P plcDataType REAL_BE


Dadurch sollte automatisch FC4 zum Lesen des Eingangsregisters auf Adresse 12 verwendet werden.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 15 Februar 2015, 21:29:39
Hallo,

Ich habe den Fehler mit disableRegisterMapping und registerType gefunden und behoben (https://github.com/ChrisD70/FHEM-Modules). Kannst du es bitte nochmal mit deiner ursprünglichen Konfiguration testen ?

Grüße,

ChrisD

Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: Dieter1 am 17 Februar 2015, 07:40:06
Hallo ChrisD,

jetzt funktioniert alles.

- Die IP Adressierung funktioniert:   define EVU_Meter ModbusRTU 192.168.178.101:20108
- disableRegisterMapping und registerType funktionieren jetzt in beliebiger Reihenfolge. Bei Registertype geht es nicht mehr mit der "4", aber mit "Input" geht es. So soll es sein :-)

Hier meine Definitionen und das Ergebnis:
define EVU_ES_E ModbusRegister 1 74    # Export Power Summe in kWh
attr EVU_ES_E IODev EVU_Meter
attr EVU_ES_E event-on-change-reading .*
attr EVU_ES_E plcDataType REAL_BE
attr EVU_ES_E disableRegisterMapping 1
attr EVU_ES_E registerType Input

2015.02.17 06:58:20 5: AddRQueue 01 04 00 4A 00 02 50 1D
2015.02.17 06:58:20 5: SimpleWrite 01 04 00 4A 00 02 50 1D
2015.02.17 06:58:20 5: Read 01 04 04 43 68 FC EE AE 90
2015.02.17 06:58:20 5: Received 01 04 04 43 68 FC EE AE 90
2015.02.17 06:58:20 5: EVU_Meter dispatch ModbusRegister:1:74:4:2:17256:64750
2015.02.17 06:58:20 5: ModbusRegister_Parse: 4 1 74

Danke noch einmal, ich hoffe deine Module gibt es bald als FHEM Standardmodule.

Jetzt werde ich mich in die Tiefen von "statistics" stürzen. Falls da jemand eine funktionierende Beispieldefinition incl. schreiben in ein Log kennt wäre ich für einen Tip dankbar, bisher finde ich nur kleine unvollständige Schnipsel.

Grüsse

Dieter
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 18 Februar 2015, 21:37:31
Hallo,

Für den Einsatz von 'statistics' und ähnlichem Code der über 'notify' funktioniert gibt es das Attribut stateAlias. Damit wird ein zusätzliches Reading erzeugt:

attr EVU_ES_E stateAlias energy
attr EVU_P1_P stateAlias power


Die zusätzlichen Readings sind jeweils eine Kopie von 'state', sie können aber direkt von 'statistics' ausgewertet werden.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: oniT am 21 Februar 2015, 19:37:13
Hallo ChrisD,

Pah hat im Wiki (http://www.fhemwiki.de/wiki/Dimplex_W%C3%A4rmepumpenmanager#Modbus-Register.2FCoil_Adressen_definieren) darauf hingewiesen das "updateIntervall " im Englischen ja "updateInterval" heißt. Ist ja nichts schlimmes und ich weiß auch nicht ob man dies im Nachhinein überhaupt noch ändern kann, ohne die bisherigen angelegten Definitionen zu beeinflussen.

Dies mal so am Rande.

Und noch etwas, bei mir kommt im Logfile immer mal "ModbusTCPServer: bad frame". Was sagt dies aus?

Danke

Gruß,
Tino
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 21 Februar 2015, 22:21:17
Hallo,

Ich habe das Attribut in der Version 0011 (Register) und 0005 (Coil) geändert (https://github.com/ChrisD70/FHEM-Modules). Damit es übernommen wird muss FHEM neu gestartet werden, die alte Schreibweise wird dann automatisch konvertiert.

Die Meldung 'bad frame' besagt dass ein Paket empfangen wurde das entweder nicht erwartet wurde oder aber nicht vollständig ist. Ich habe die Ausgabe von 36_ModbusTCPServer (https://github.com/ChrisD70/FHEM-Modules) etwas erweitert, kannst du den Loginhalt beim nächsten Fehler posten ?

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: oniT am 22 Februar 2015, 11:28:04
Hallo ChrisD,

danke, ich habe es eingespielt.

Noch eine Frage dazu, hast Du den Loginhalt erweitert oder muss ich das Loglevel ändern?

Und gibt es eine Möglichkeit den Startzeitpunkt für das updateInterval zu bestimmen? Also wie zum Beispiel bei einem at mit alignTime. Hintegrund ist, es gibt Abfragen welche nur stündlich (z.B. zur vollen Stunde) oder täglich (z.B. bei Tageswechsel) stattfinden sollen. Wenn man dies direkt anlegen könnte, muss nicht den Umweg über ein at und notify gehen.

Danke

Gruß,
Tino
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: oniT am 22 Februar 2015, 17:09:56
Hallo ChrisD,

ich nehme an, Du meinst diese Meldung im Logfile


2015.02.22 16:11:32 1: -6
2015.02.22 16:11:32 1: PERL WARNING: Argument "ModbusTCPServer: bad frame: 3 - 8, 0, 5 - 33" isn't numeric in subtraction (-) at ./FHEM/36_ModbusTCPServer.pm line 253.


Diese Meldung kommt nun seit dem einspielen der neuen ModbusTCPServer.pm.

Gruß,
Tino
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 22 Februar 2015, 18:59:41
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 (https://github.com/ChrisD70/FHEM-Modules/blob/master/36_ModbusTCPServer.pm) 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
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 22 Februar 2015, 22:29:12
Hallo,

Ich habe ein Attribut alignUpdateInterval in der Version 0012 (https://github.com/ChrisD70/FHEM-Modules/blob/master/37_ModbusRegister.pm) 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 (https://github.com/ChrisD70/FHEM-Modules/blob/master/36_ModbusTCPServer.pm) benötigt.

Um einen Wert zur vollen Stunde auslesen kann man
attr myRegister updateInterval 01:00
attr myRegister alignUpdateInterval 00:00
verwenden, für tägliches Lesen
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
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: oniT am 23 Februar 2015, 19:20:26
Hallo ChrisD,

Zitat von: ChrisD am 22 Februar 2015, 22:29:12
Um einen Wert zur vollen Stunde auslesen kann man
attr myRegister updateInterval 01:00
attr myRegister alignUpdateInterval 00:00
verwenden, für tägliches Lesen
attr myRegister updateInterval 24:00
attr myRegister alignUpdateInterval 00:00


ok werde ich testen.

Zitat von: ChrisD am 22 Februar 2015, 18:59:41
Ich habe eine neue Version (https://github.com/ChrisD70/FHEM-Modules/blob/master/36_ModbusTCPServer.pm) erstellt welche keine Perl-Warnung mehr ausgibt und versucht das komplette Paket auszugeben. Kannst du damit testen ?

Jetzt kommt folgende Meldung


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
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 23 Februar 2015, 19:22:48
Hallo,

Wenn du die Datei ersetzt musst du entweder FHEM neu starten oder das Modul mit
reload 36_ModbusTCPServerneu laden.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: oniT am 24 Februar 2015, 21:55:38
Hallo ChrisD,

hier ein Auszug der Meldungen aus dem Logfile

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:


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:


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
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 24 Februar 2015, 22:33:37
Hallo,

Im Auszug vom Log scheinen die Anfragen und Rückmeldungen teilweise durcheinander. Kannst du die Zeiten im Log mit
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
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: oniT am 24 Februar 2015, 23:17:28
Hallo ChrisD,

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


   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.

   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
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: oniT am 25 Februar 2015, 20:25:30
Hallo ChrisD,

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


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
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 26 Februar 2015, 17:31:41
Hallo,

Kannst du die neuen Version von ModbusTCPServer (https://github.com/ChrisD70/FHEM-Modules/blob/master/36_ModbusTCPServer.pm) und ModbusRegister (https://github.com/ChrisD70/FHEM-Modules/blob/master/37_ModbusRegister.pm) 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
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: Dieter1 am 26 Februar 2015, 18:33:28
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.


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
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 26 Februar 2015, 19:41:33
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:
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

Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: Dieter1 am 28 Februar 2015, 08:54:20
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
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: oniT am 02 März 2015, 22:39:29
Hallo ChrisD,

Zitat von: ChrisD am 26 Februar 2015, 17:31:41
Kannst du die neuen Version von ModbusTCPServer (https://github.com/ChrisD70/FHEM-Modules/blob/master/36_ModbusTCPServer.pm) und ModbusRegister (https://github.com/ChrisD70/FHEM-Modules/blob/master/37_ModbusRegister.pm) 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.

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.


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:


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?


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
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 03 März 2015, 21:32:48
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 (https://github.com/ChrisD70/FHEM-Modules/raw/master/37_ModbusCoil.pm) 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:
deleteattr dim_modbus_coil_102 source
attr dim_modbus_coil_102 source Coil


Die Ausgabe von 'list' sollte danach so aussehen:
ZitatHelper:
     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
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: oniT am 04 März 2015, 21:59:06
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:


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.


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
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 04 März 2015, 22:47:02
Hallo,

Der Fehler liegt (wie so oft) bei mir, kannst du versuchen ob Version 0014 (https://raw.githubusercontent.com/ChrisD70/FHEM-Modules/master/37_ModbusRegister.pm) das Problem löst ?

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 06 März 2015, 13:54:44
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.
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 06 März 2015, 19:14:59
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
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 06 März 2015, 19:36:54
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?
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 06 März 2015, 21:50:24
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
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: bk9050 am 07 März 2015, 09:16:53
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)
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 07 März 2015, 09:29:55
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?
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: oniT am 07 März 2015, 18:32:59
Hallo ChrisD,

Zitat von: ChrisD am 04 März 2015, 22:47:02
kannst du versuchen ob Version 0014 (https://raw.githubusercontent.com/ChrisD70/FHEM-Modules/master/37_ModbusRegister.pm) 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:

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:

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


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
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 07 März 2015, 21:14:21
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 (https://raw.githubusercontent.com/ChrisD70/FHEM-Modules/master/36_ModbusTCPServer.pm) 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

Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: oniT am 08 März 2015, 10:25:24
Hallo ChrisD,

hier der Logauszug mit der TCP Server Version 0012.


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



Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 08 März 2015, 11:42:18
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?
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 08 März 2015, 17:53:08
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
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 08 März 2015, 18:14:16
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...
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 10 März 2015, 22:09:09
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 (https://raw.githubusercontent.com/ChrisD70/FHEM-Modules/master/36_ModbusTCPServer.pm) 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

Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: PEPITO82 am 11 März 2015, 07:50:43
Ich habe gestern Abend versucht, meinen Solar Log als ModbusTCPServer zu definieren:
define mySolarlog ModbusTCPServer 192.168.178.49

Leider erhalte ich dann die Meldung, dass das Modul nicht geladen werden konnte.
Im Logfile steht folgendes:
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?
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 11 März 2015, 11:22:24
Vielen Dank ChrisD, diese beiden Möglichkeiten habe ich auch gefunden - man findet nur im Netz nicht viel darüber.
Entweder funktioniert das Konstrukt so relativ problemlos, oder es gibt kaum menschen die sich daran versuchen.

Ich habe soeben ein 750-880 Starterkit bestellt und werde sobald es eingetroffen ist einen ersten Testaufbau machen.

Ich bin gespannt - und hoffe auf das richtige Pferd zu setzen.
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: maxritti am 11 März 2015, 17:14:04
Zitat von: PEPITO82 am 11 März 2015, 07:50:43
Ich habe gestern Abend versucht, meinen Solar Log als ModbusTCPServer zu definieren:
define mySolarlog ModbusTCPServer 192.168.178.49

Leider erhalte ich dann die Meldung, dass das Modul nicht geladen werden konnte.
Im Logfile steht folgendes:
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?

Da fällt mir gerade etwas zu ein.
Schau doch mal auf Deinem PI die 36_ModbusTCPServer.pm mit einem Editor an.
Steht da am Ende HTML Code?
Das wäre nämlich falsch.
Enden muss die Datei mMn so:

sub ModbusTCPServer_UpdateStatistics($$$$$) {############################################################
  my ($hash,$pi,$po,$bi,$bo)=@_;

  $hash->{helper}{statistics}{pktIn}=0 if (!defined($hash->{helper}{statistics}{pktIn}));
  $hash->{helper}{statistics}{pktOut}=0 if (!defined($hash->{helper}{statistics}{pktOut}));
  $hash->{helper}{statistics}{bytesIn}=0 if (!defined($hash->{helper}{statistics}{bytesIn}));
  $hash->{helper}{statistics}{bytesOut}=0 if (!defined($hash->{helper}{statistics}{bytesOut}));

  $hash->{helper}{statistics}{pktIn}+=$pi;
  $hash->{helper}{statistics}{pktOut}+=$po;
  $hash->{helper}{statistics}{bytesIn}+=$bi;
  $hash->{helper}{statistics}{bytesOut}+=$bo;
  $hash->{statistics} =$hash->{helper}{statistics}{pktIn} ." / " . $hash->{helper}{statistics}{pktOut} ." / " . $hash->{helper}{statistics}{bytesIn} ." / " . $hash->{helper}{statistics}{byt$
}
1;


Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: PEPITO82 am 11 März 2015, 18:52:29
Danke! Genau daran lag es. Die Datei, die ich gespeichert hatte, enthielt nur HTML Code.
Jetzt hab ich nochmal alle Dateien von github heruntergeladen und nun passt es.  :D
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 11 März 2015, 22:11:46
Hallo,

Ich habe eine alternative Möglichkeit eingerichtet die Module unter FHEM zu installieren. Durch Eingabe von
update force https://raw.githubusercontent.com/ChrisD70/FHEM-Modules/master/autoupdate/mb/controls_modbus.txtim Webinterface von FHEM wird die aktuelle Version heruntergeladen. Danach muss entweder FHEM neu gestartet werden oder die benötigten Module mit reload neu geladen werden.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: bmwfan am 12 März 2015, 12:21:58
Hallo,
ich lese meinen SolarLog 200 mit dem Modul von MopedPaul und der Änderung von OniT aus. Klappt auch alles sehr gut bis auf die Anzahl der gelesenen Messwerte. Ich bekomme jeden Wert in kW (alle ausser den Wert Pac, den ich in W abfrage) doppelt ausgelesen und kann den Fehler, trotz Vergleich mit den hier beschriebenen ModBus-Modulen nicht lokalisieren. Das liegt sicher daran, dass das Niveau der Programmierung der Module für meinen Kenntnisstand eindeutig zu hoch ist. Hat vielleicht jemand eine Tip für mich?
Anbei mein Modul und der Aufruf

###### SOLARLOG auslesen ##################################
define Pac dummy
attr Pac alias Ertrag Aktuell
attr Pac group PV
attr Pac room Photovoltaik

define Today dummy
attr Today alias Ertrag Heute
attr Today room Photovoltaik

define Yesterday dummy
attr Yesterday alias Ertrag Gestern
attr Yesterday room Photovoltaik

define Month dummy
attr Month alias Ertrag Monat
attr Month room Photovoltaik

define Year dummy
attr Year alias Ertrag Jahr
attr Year room Photovoltaik

define Total dummy
attr Total alias Ertrag Gesamt
attr Total room Photovoltaik

# Solarlog nur am Tag abfragen (isday). 00:01:00: Jede Minute wird abgefragt
define SolarLogValues at +*00:05:00 {if(isday()) {{Solarlog ("3502","1","Pac")};;{Solarlog ("3508","2","Today")};;{Solarlog ("3510","2","Yesterday")};;{Solarlog ("3512","2","Month")};;{Solarlog ("3514","2","Year")};;{Solarlog ("3516","2","Total")}}}
attr SolarLogValues group PV
attr SolarLogValues room Photovoltaik

# --- Filelog Definition
define FileLog_SolarLogValues FileLog ./log/SolarLogValues-%Y-%m.log Month:.*|Pac:.*|Today:.*|Year:.*
attr FileLog_SolarLogValues group PV
attr FileLog_SolarLogValues room Photovoltaik

Grüße Jürgen
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: oniT am 13 März 2015, 01:04:17
Hallo Jürgen,

Ich habe inzwischen einen Wiki-Artikel erstellt. Sieh dort bitte nach und richte es wie beschrieben ein.

Gruß
Tino
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 13 März 2015, 17:56:19
Heute war das Ding in der Post - der Wago 750-880 starterkit liegt vor mir, ich bin schon gespannt wie ein flitzebogen. Stehe aber auch quasi schon vor dem ersten problemchen, ich hatte gehofft einfach Codesys installieren und loslegen zu können - jetzt ist erstens codesys nicht dabei, und zweitens ist die Software nicht für OSX gedacht... Erste google befragungen ergaben das es diese programmierumgebungen nicht für den Mac gibt.
Hm...
Muss ich jetzt wirklich das alte parallels wieder installieren? Und wird das überhaupt funktionieren, oder bekomm ich probleme mit parallels?

Hat jemand ähnliches am laufen?
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: oniT am 13 März 2015, 21:02:47
Hallo ChrisD,

hier wie gewünscht ein Logauszug zum Timeout mit der Version 0013:


2015.03.13 16:24:23.695 3: ModbusTCPServer_Timeout, request: SimpleWrite [0D AE 00 00 00 06] 00 03 0D AE 00 01
2015.03.13 16:24:27.068 3: ModbusTCPServer_Timeout, request: SimpleWrite [00 2C 00 00 00 06] 00 01 00 2C 00 08
2015.03.13 16:24:33.099 3: ModbusTCPServer_Timeout, request: SimpleWrite [00 31 00 00 00 06] 00 01 00 31 00 08
2015.03.13 16:24:33.711 3: ModbusTCPServer_Timeout, request: SimpleWrite [0D AE 00 00 00 06] 00 03 0D AE 00 01

2015.03.13 16:43:35.549 3: ModbusTCPServer_Timeout, request: SimpleWrite [0D AE 00 00 00 06] 00 03 0D AE 00 01
2015.03.13 17:47:09.643 3: ModbusTCPServer_Timeout, request: SimpleWrite [0D B4 00 00 00 06] 00 03 0D B4 00 02
2015.03.13 17:47:10.853 3: ModbusTCPServer_Timeout, request: SimpleWrite [00 02 00 00 00 06] 00 03 00 02 00 01
2015.03.13 17:47:15.664 3: ModbusTCPServer_Timeout, request: SimpleWrite [0D AE 00 00 00 06] 00 03 0D AE 00 01
2015.03.13 17:47:16.861 3: ModbusTCPServer_Timeout, request: SimpleWrite [00 67 00 00 00 06] 00 03 00 67 00 01


Gruß
Tino
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: Dieter1 am 14 März 2015, 10:38:08
Hallo ChrisD,
ich habe mit den neueren Versionen von ModbusRegister das gleiche Problem wie oniT:

2015.03.14 09:56:06.127 3: EVU_Meter: Unknown code ModbusRegister:1:74:4:2:17429:24871, help me!

Der erste Einlesezyklus mit mehreren Werten hintereinander funktioniert. Wenn 60s später die gleichen Parameter noch einmal ausgelesen werden wird ab da ModbusRegister_Parse kurz hintereinander 2* aufgerufen und die "Unknown code" Fehlermeldung kommt:

2015.03.14 09:56:06.117 5: ModbusRegister_Parse: 4 1 74
2015.03.14 09:56:06.119 5: ModbusRegister_Parse: 4 1 74
2015.03.14 09:56:06.127 3: EVU_Meter: Unknown code ModbusRegister:1:74:4:2:17429:24871, help me!

Hier meine Konfig und die Logs. Ich hoffe, du kannst erkennen, woran das liegt. Mit den Versionen vom 2015-02-15 funktioniert es.


fhem> list EVU_Meter
Internals:
   DEF        192.168.178.101:20108
   DeviceName 192.168.178.101:20108
   FD         62
   NAME       EVU_Meter
   NR         48
   NTFY_ORDER 50-EVU_Meter
   PARTIAL
   STATE      ok
   TYPE       ModbusRTU
   dummy      0
   Readings:
     2015-03-14 09:55:00   state           opened
   Helper:
     PARTIAL
     databits   8
     hd_tr_id   52
     hd_unit_id 0
     parity     even
     state      idle
     stopbits   1
Attributes:
   room       Power
   timeout    6
   verbose    5

fhem> list EVU_ES_E
Internals:
   DEF        1 74
   EVU_Meter_MSGCNT 1
   EVU_Meter_TIME 2015-03-14 09:55:03
   IODev      EVU_Meter
   LASTInputDev EVU_Meter
   MSGCNT     1
   ModbusRegister_lastRcv 2015-03-14 09:55:03
   NAME       EVU_ES_E
   NR         69
   NTFY_ORDER 50-EVU_ES_E
   STATE      597.509
   TYPE       ModbusRegister
   Readings:
     2015-03-14 09:55:03   RAW             44156093
     2015-03-14 09:55:03   kWh             597.509
     2015-03-14 09:55:03   statKWh         Hour: 0.963 Day: 1.853 Month: 246.450                       Year: 355.947 (since: 2015-02-19 )
     2015-03-14 09:55:03   statKWhDay      1.853
     2015-03-13 23:59:55   statKWhDayLast  26.390
     2015-03-14 09:55:03   statKWhHour     0.963
     2015-03-14 08:59:57   statKWhHourLast 0.836
     2015-03-14 08:59:57   statKWhLast     Hour: 0.836 Day: 26.390 Month: 109.49                      7 Year: - (since: 2015-02-19 )
     2015-03-14 09:55:03   statKWhMonth    246.450
     2015-02-28 23:59:55   statKWhMonthLast 109.497
     2015-03-14 09:55:03   statKWhYear     355.947
     2015-03-14 09:55:03   state           597.508972167969
   Helper:
     _98_statistics Statistik
     addr       4 1 74
     address    74
     disableRegisterMapping 1
     lastUpdate 0
     nextUpdate 1426323607.43166
     nread      2
     readCmd    J
     register   74
     registerType 4
     unitId     1
     updateIntervall 60
     Cnv:
       a          1
       b          0
       max        3.403e+38
       min        -3.403e+38
       step       1e+36
Attributes:
   IODev      EVU_Meter
   disableRegisterMapping 1
   event-on-change-reading .*
   plcDataType REAL_BE
   registerType Input
   room       Power
   stateFormat {sprintf("%0.3f", ReadingsVal($name,"state",0))}
   updateInterval 60
   userReadings kWh {sprintf("%0.3f", ReadingsVal($name,"state",0))}




2015.03.14 09:55:00.341 1: 192.168.178.101:20108 reappeared (EVU_Meter)
2015.03.14 09:55:03.368 5: AddRQueue 01 04 00 4A 00 02 50 1D
2015.03.14 09:55:03.370 5: SimpleWrite 01 04 00 4A 00 02 50 1D
2015.03.14 09:55:03.383 5: AddRQueue 01 04 00 48 00 02 F1 DD
2015.03.14 09:55:03.384 5: adding to RQUEUE - 1
2015.03.14 09:55:03.386 5: AddRQueue 01 04 00 0C 00 02 B1 C8
2015.03.14 09:55:03.387 5: adding to RQUEUE - 2
2015.03.14 09:55:03.388 5: AddRQueue 01 04 00 0E 00 02 10 08
2015.03.14 09:55:03.389 5: adding to RQUEUE - 3
2015.03.14 09:55:03.391 5: AddRQueue 01 04 00 10 00 02 70 0E
2015.03.14 09:55:03.392 5: adding to RQUEUE - 4
2015.03.14 09:55:03.394 5: AddRQueue 01 04 00 34 00 02 30 05
2015.03.14 09:55:03.395 5: adding to RQUEUE - 5
2015.03.14 09:55:03.425 5: Read 01 04 04 44 15 60 93 96 DD
2015.03.14 09:55:03.427 5: Received 01 04 04 44 15 60 93 96 DD
2015.03.14 09:55:03.428 5: EVU_Meter dispatch ModbusRegister:1:74:4:2:17429:24723
2015.03.14 09:55:03.557 5: ModbusRegister_Parse: 4 1 74
2015.03.14 09:55:03.627 4: RQUEUE: 5
2015.03.14 09:55:03.629 5: SimpleWrite 01 04 00 48 00 02 F1 DD
2015.03.14 09:55:03.671 5: Read 01 04 04 43 A1 F7 4C F8 27
2015.03.14 09:55:03.673 5: Received 01 04 04 43 A1 F7 4C F8 27
2015.03.14 09:55:03.674 5: EVU_Meter dispatch ModbusRegister:1:72:4:2:17313:63308
2015.03.14 09:55:03.675 5: ModbusRegister_Parse: 4 1 72
2015.03.14 09:55:03.722 4: RQUEUE: 4
2015.03.14 09:55:03.723 5: SimpleWrite 01 04 00 0C 00 02 B1 C8
2015.03.14 09:55:03.768 5: Read 01 04 04 C3 85 A6 30 AD 9D
2015.03.14 09:55:03.770 5: Received 01 04 04 C3 85 A6 30 AD 9D
2015.03.14 09:55:03.771 5: EVU_Meter dispatch ModbusRegister:1:12:4:2:50053:42544
2015.03.14 09:55:03.773 5: ModbusRegister_Parse: 4 1 12
2015.03.14 09:55:03.792 4: RQUEUE: 3
2015.03.14 09:55:03.793 5: SimpleWrite 01 04 00 0E 00 02 10 08
2015.03.14 09:55:03.855 5: Read 01 04 04 C2 7E 90 D8 CA 7E
2015.03.14 09:55:03.857 5: Received 01 04 04 C2 7E 90 D8 CA 7E
2015.03.14 09:55:03.858 5: EVU_Meter dispatch ModbusRegister:1:14:4:2:49790:37080
2015.03.14 09:55:03.860 5: ModbusRegister_Parse: 4 1 14
2015.03.14 09:55:03.878 4: RQUEUE: 2
2015.03.14 09:55:03.880 5: SimpleWrite 01 04 00 10 00 02 70 0E
2015.03.14 09:55:03.934 5: Read 01 04 04 C3 87 01 2B 36 66
2015.03.14 09:55:03.936 5: Received 01 04 04 C3 87 01 2B 36 66
2015.03.14 09:55:03.937 5: EVU_Meter dispatch ModbusRegister:1:16:4:2:50055:299
2015.03.14 09:55:03.939 5: ModbusRegister_Parse: 4 1 16
2015.03.14 09:55:03.957 4: RQUEUE: 1
2015.03.14 09:55:03.958 5: SimpleWrite 01 04 00 34 00 02 30 05
2015.03.14 09:55:04.014 5: Read 01 04 04 C4 16 3C BB 76 03
2015.03.14 09:55:04.016 5: Received 01 04 04 C4 16 3C BB 76 03
2015.03.14 09:55:04.017 5: EVU_Meter dispatch ModbusRegister:1:52:4:2:50198:15547
2015.03.14 09:55:04.019 5: ModbusRegister_Parse: 4 1 52
2015.03.14 09:56:06.021 5: AddRQueue 01 04 00 4A 00 02 50 1D
2015.03.14 09:56:06.023 5: SimpleWrite 01 04 00 4A 00 02 50 1D
2015.03.14 09:56:06.036 5: AddRQueue 01 04 00 48 00 02 F1 DD
2015.03.14 09:56:06.037 5: adding to RQUEUE - 1
2015.03.14 09:56:06.039 5: AddRQueue 01 04 00 0C 00 02 B1 C8
2015.03.14 09:56:06.039 5: adding to RQUEUE - 2
2015.03.14 09:56:06.041 5: AddRQueue 01 04 00 0E 00 02 10 08
2015.03.14 09:56:06.042 5: adding to RQUEUE - 3
2015.03.14 09:56:06.044 5: AddRQueue 01 04 00 10 00 02 70 0E
2015.03.14 09:56:06.045 5: adding to RQUEUE - 4
2015.03.14 09:56:06.047 5: AddRQueue 01 04 00 34 00 02 30 05
2015.03.14 09:56:06.048 5: adding to RQUEUE - 5
2015.03.14 09:56:06.112 5: Read 01 04 04 44 15 61 27 97 3A
2015.03.14 09:56:06.114 5: Received 01 04 04 44 15 61 27 97 3A
2015.03.14 09:56:06.115 5: EVU_Meter dispatch ModbusRegister:1:74:4:2:17429:24871
2015.03.14 09:56:06.117 5: ModbusRegister_Parse: 4 1 74
2015.03.14 09:56:06.119 5: ModbusRegister_Parse: 4 1 74
2015.03.14 09:56:06.127 3: EVU_Meter: Unknown code ModbusRegister:1:74:4:2:17429:24871, help me!
2015.03.14 09:56:06.130 4: RQUEUE: 5
2015.03.14 09:56:06.132 5: SimpleWrite 01 04 00 48 00 02 F1 DD
2015.03.14 09:56:06.193 5: Read 01 04 04 43 A1 F7 6D 38 3F
2015.03.14 09:56:06.195 5: Received 01 04 04 43 A1 F7 6D 38 3F
2015.03.14 09:56:06.196 5: EVU_Meter dispatch ModbusRegister:1:72:4:2:17313:63341
2015.03.14 09:56:06.198 5: ModbusRegister_Parse: 4 1 72
2015.03.14 09:56:06.200 5: ModbusRegister_Parse: 4 1 72
2015.03.14 09:56:06.208 3: EVU_Meter: Unknown code ModbusRegister:1:72:4:2:17313:63341, help me!
2015.03.14 09:56:06.214 4: RQUEUE: 4
2015.03.14 09:56:06.215 5: SimpleWrite 01 04 00 0C 00 02 B1 C8
2015.03.14 09:56:06.261 5: Read 01 04 04 C3 87 87 AC 14 64
2015.03.14 09:56:06.263 5: Received 01 04 04 C3 87 87 AC 14 64
2015.03.14 09:56:06.264 5: EVU_Meter dispatch ModbusRegister:1:12:4:2:50055:34732
2015.03.14 09:56:06.266 5: ModbusRegister_Parse: 4 1 12
2015.03.14 09:56:06.267 5: ModbusRegister_Parse: 4 1 12
2015.03.14 09:56:06.276 3: EVU_Meter: Unknown code ModbusRegister:1:12:4:2:50055:34732, help me!


Danke

Dieter
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 14 März 2015, 21:14:54
Hallo,

@Dieter:
Das Problem bei dir kommt daher dass ich ModbusRTU noch nicht an verschiedene Änderungen in ModbusRegister angepasst hatte. Kannst du bitte mit der Version 0008 (https://raw.githubusercontent.com/ChrisD70/FHEM-Modules/master/36_ModbusRTU.pm) von ModbusRTU testen ?

In der Version werden jetzt bei Timeouts auch Meldungen ins Log geschrieben wenn verbose auf 3 oder höher steht.

Zum Installieren kannst du in FHEM dies eingeben:
update 36_ModbusRTU https://raw.githubusercontent.com/ChrisD70/FHEM-Modules/master/autoupdate/mb/controls_modbus.txt

@Tino:
Dass im Log Timeouts auftreten kann manchmal passieren, allerdings müssten sie immer um mindestens den Wert des Attributes timeout auseinanderliegen was bei deinem Log nicht der Fall ist. Ich muss mir den Code nochmal ansehen.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: PEPITO82 am 15 März 2015, 11:18:28
Edit: hat sich erledigt. Hab die betroffenen Defines gelöscht und nochmal mit dem korrekten Register angelegt. Hab zuvor wahrscheinlich zu Testzwecken eine andere Registernummer eingetragen gehabt...


Der Solar-Log läuft sehr gut über das Modul.
Meine Wärmepumpe von Waterkotte ansich auch.

Nur mit zwei Registern habe ich ein Problem. Die fluten das Logfile:

2015.03.15 11:06:28 2: ModbusRegister_Parse: invalid address 3 0 5030


Ich bekomme aus dem Register keinen sinnvollen Wert gelesen.
Dort sollte nur 0 oder 1 stehen (lt. Config-Seite von Carel, dem Hersteller des Wärmepumpenreglers).

Mit den Attributen habe ich ein wenig herumgespielt, aber leider bisher erfolglos:


IODev myWaterkotte
event-on-change-reading .*
plcDataType WORD
registerType Input
room Waterkotte
updateInterval 3600


Das updateIterval habe ich gepflegt, damit das Logfile nicht überläuft...

Wenn ich manuell einen Wert setze, dann wird in der Wärmepumpe selbst auch das Heizen ausgeschaltet.
Von dem her sollte das Register eigentlich passen.

Kann jemand helfen?
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: Dieter1 am 15 März 2015, 11:37:10
Hallo ChrisD,

mit den aktuellen Versionen einschl. Version 0008 von ModbusRTU sieht alles gut aus.  Danke.
Wenn ich einen Timeout sehe (was leider sicher kommen wird  :(  ) gebe ich dir über das Verhalten Bescheid.
Es sollte ja jetzt ein Logeintrag zu sehen sein. Hat sich sonst im Verhalten nach einem Timeout noch etwas geändert?

Grüße
Dieter
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 15 März 2015, 13:32:48
Hallo,

@Dieter:
Es hat sich nichts am Verhalten beim Timeout geändert. Eine Möglichkeit wäre bei Timeout die Anfrage erneut zu senden, allerdings gibt es bei Modbus RTU immer noch das Problem dass es schwierig zu erkennen ist zu welcher Anfrage die ankommenden Daten gehören.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: oniT am 15 März 2015, 18:33:47
Zitat von: PEPITO82 am 15 März 2015, 11:18:28
Nur mit zwei Registern habe ich ein Problem. Die fluten das Logfile:

2015.03.15 11:06:28 2: ModbusRegister_Parse: invalid address 3 0 5030


Ich bekomme aus dem Register keinen sinnvollen Wert gelesen.
Dort sollte nur 0 oder 1 stehen (lt. Config-Seite von Carel, dem Hersteller des Wärmepumpenreglers).

Mit den Attributen habe ich ein wenig herumgespielt, aber leider bisher erfolglos:


IODev myWaterkotte
event-on-change-reading .*
plcDataType WORD
registerType Input
room Waterkotte
updateInterval 3600


Das updateIterval habe ich gepflegt, damit das Logfile nicht überläuft...

Wenn ich manuell einen Wert setze, dann wird in der Wärmepumpe selbst auch das Heizen ausgeschaltet.
Von dem her sollte das Register eigentlich passen.

Kann jemand helfen?

Hallo,

sicher das es sich dabei um ein Register handelt? Wenn nur 0 oder 1 kommen, würde ich von einem Coil und somit Digitalwert ausgehen. Was steht zu diesem Wert in der Dokumentation?

Gruß
Tino
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: PEPITO82 am 16 März 2015, 08:13:03
Ich habe bisher leider nur diese Doku: https://drive.google.com/file/d/0Bzg6eY-tNsw3cnRCc0xGUDFPNmc/view?usp=sharing (https://drive.google.com/file/d/0Bzg6eY-tNsw3cnRCc0xGUDFPNmc/view?usp=sharing).

Interessant sind für mich die Handabschaltung Heizung auf Seite 190: BMS-Index I30 / Typ WORD / Einstellbereich 0 ... 1 (0= Aus, 1 = Ein)
Sowie die Handabschaltung Warmwasser auf Seite 192: BMS-Index I32 / Typ WORD / Einstellbereich 0 ... 1 (0= Aus, 1 = Ein)

Auf der Konfigurationsseite von Carel sehe ich auch, dass sich bei Integer Variable 30 der Wert von 1 auf 0 bzw. 0 auf 1 ändert:
(https://lh3.googleusercontent.com/-W_HjS00z9M8/VQZ7q68FcCI/AAAAAAAAA-M/kl0hOHDMGhc/s1440/pcoweb_2.jpg)

Das Register ist aber scheinbar Nr. 5030 (Heizung) bzw. 5032.

Vermutlich gehen die analogen Variablen von Register 1 - 1000 und die Integer Variablen von 5000 - 7000.

Ist es korrekt eingestellt?
Seitdem ich Register 5030 nochmal neu definiert habe, gab es keine Logeinträge mehr.
Zuvor hatte ich es wahrscheinlich zuerst mit Register 158 probiert (lt. der beigefügten Doku) und anschließend auf 5030 geändert.
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: PEPITO82 am 16 März 2015, 19:39:00
Ich habe gerade noch versucht die Modbus Adresse meiner Waterkotte Wärmepumpe als ModbusCoil zu definieren.
Dort erhalte ich dann aber folgende Meldungen:

2015.03.16 19:34:55 3: wp_WW_Handabschaltung_Test: I/O device is myWaterkotte
2015.03.16 19:34:57 1: ModbusTCPServer_Parse: bad frame, sent: SimpleWrite [13 A7 00 00 00 06] 00 01 13 A7 00 08
2015.03.16 19:34:57 1: ModbusTCPServer_Parse: bad frame, received:  [13 A7 00 00 00 03] 00 81 02


Ansich wäre das über einen Coil schöner gelöst, weil es dann ja direkt ein Schalter wäre...
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 16 März 2015, 21:24:21
Hallo,

Die Rückmeldung 81 02 bedeutet dass die Adresse ungültig ist. Aus der Dokumentation ist nur schwer ersichtlich welche Adressen wie angesprochen werden sollen. Die Adressen scheinen bei 1 zu beginnen, dies könnte darauf hinweisen dass es nicht Adressen sondern Registernummern sind. Du könntest versuchen ob mit
define wp_WW_Handabschaltung_Test ModbusRegister 0 40158ein Zugriff möglich ist (ohne irgendwelche anderen Attribute außer IODev).

Über das Attribut eventMap kannst du das Register in einen Schalter umfunktionieren:
attr wp_WW_Handabschaltung_Test eventMap 0:off 1:on

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: oniT am 16 März 2015, 21:41:11
Zitat von: PEPITO82 am 16 März 2015, 08:13:03
Das Register ist aber scheinbar Nr. 5030 (Heizung) bzw. 5032.

Vermutlich gehen die analogen Variablen von Register 1 - 1000 und die Integer Variablen von 5000 - 7000.

Ist es korrekt eingestellt?
Seitdem ich Register 5030 nochmal neu definiert habe, gab es keine Logeinträge mehr.
Zuvor hatte ich es wahrscheinlich zuerst mit Register 158 probiert (lt. der beigefügten Doku) und anschließend auf 5030 geändert.

Hallo,

ja das ist korrekt. Register welche Analogwerte enthalten werden 1 zu 1 umgesetzt, zum Lesen oder Schreiben eines Integer muss ein Offset von 5000 oder ich meine sogar je nach Firmware auf der pCOWeb 5001 gesetzt werden.

Gruß
Tino
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: oniT am 16 März 2015, 21:59:53
Zitat von: ChrisD am 14 März 2015, 21:14:54
Zum Installieren kannst du in FHEM dies eingeben:
update 36_ModbusRTU https://raw.githubusercontent.com/ChrisD70/FHEM-Modules/master/autoupdate/mb/controls_modbus.txt

Hallo ChrisD,

verstehe ich das richtig, dass man diesen Befehl nicht nur für ein Update sondern wie Du schreibst auch zum Installieren des Moduls nutzen kann? Wenn dies so ist, dann erweitere ich den Wiki-Artikel. Dann tut man sich schon wieder leichter und muss die Dateie nicht erst downloaden und mittels FTP übertragen.

Gruß
Tino
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 16 März 2015, 22:43:10
Hallo,

Ich habe die Möglichkeit die Module über 'update' herunterzuladen hinzugefügt da es umständlich und fehleranfällig ist sie manuell zu installieren.

Du kannst mit
update all https://raw.githubusercontent.com/ChrisD70/FHEM-Modules/master/autoupdate/mb/controls_modbus.txtalle Module herunterladen resp. updaten. Es werden dabei nur die Module heruntergeladen die aktualisiert werden müssen.

Die Module können auch einzeln installiert werden:
update 36_ModbusRTU https://raw.githubusercontent.com/ChrisD70/FHEM-Modules/master/autoupdate/mb/controls_modbus.txt
update 36_ModbusTCPServer https://raw.githubusercontent.com/ChrisD70/FHEM-Modules/master/autoupdate/mb/controls_modbus.txt
update 37_ModbusCoil https://raw.githubusercontent.com/ChrisD70/FHEM-Modules/master/autoupdate/mb/controls_modbus.txt
update 37_ModbusRegister https://raw.githubusercontent.com/ChrisD70/FHEM-Modules/master/autoupdate/mb/controls_modbus.txt

In dem Fall wird aber nicht überprüft ob eine neuere Version vorliegt, die bestehende wird immer mit der Serverversion überschrieben.

Wenn nach den Aufrufen ein Update von FHEM gemacht wird, wird die Dokumentation der Modbus-Module automatisch in die Commandref mit übernommen.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: PEPITO82 am 17 März 2015, 11:21:56
Zitat von: oniT am 16 März 2015, 21:41:11
Hallo,

ja das ist korrekt. Register welche Analogwerte enthalten werden 1 zu 1 umgesetzt, zum Lesen oder Schreiben eines Integer muss ein Offset von 5000 oder ich meine sogar je nach Firmware auf der pCOWeb 5001 gesetzt werden.

Gruß
Tino

Im Handbuch von Carel steht zu pCOWeb noch das Folgende:

The ranges of variables for version 1.4.2 (when pCO communicates using Modbus extended protocol) have been extended as explained here below:

Digital variables: coils from 1 up to 2048
Analogue variables: registers from 1 up to 5000
Integer variables: registers from 5001 to 10000

Variable types: Signed Integers
(mandatory in some software to
correctly read/write the variables)

Danke für die Hilfe.  :)

@ChrisD: Danke für den Tipp mit dem Attribut eventMap. Jetzt habe ich endlich einen Schalter. Es fehlt mir dann nur noch die Zeitsteuerung.
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 30 März 2015, 15:05:32
Hallo ChrisD,
ich habe heute morgen endlich das letzte von Dir empfohlene Update eingespielt
( set_on - set on )
die Wago SPS war und ist zur Zeit ausgeschaltet, es kommen ein paar Perl Meldungen im Log an...

Zitat2015.03.30 10:14:59 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/36_ModbusTCPServer.pm line 740.
2015.03.30 10:14:59 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/36_ModbusTCPServer.pm line 722.
Vielleicht schaust Du bei Gelegenheit mal danach...

BTW - was muss eigentlich noch getan werden um das Modul Offiziell einzuchecken?
Wäre toll wenn es irgendwann über den FHEM Mechanismus seine updates bekommt.
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 31 März 2015, 19:21:39
Hallo,

Ich habe den Fehler behoben, kannst du die aktuelle (https://raw.githubusercontent.com/ChrisD70/FHEM-Modules/master/36_ModbusTCPServer.pm) Version (nach einem FHEM-Neustart) testen ?

ZitatBTW - was muss eigentlich noch getan werden um das Modul Offiziell einzuchecken?
Wäre toll wenn es irgendwann über den FHEM Mechanismus seine updates bekommt.
Die Module sind eigentlich fertig um eingecheckt zu werden. Da Stefan Strobel aber kürzlich seine Modbus-Module eingecheckt hat und ich es nicht gut finde wenn es 2 unterschiedliche offizielle Modulfamilien für den gleichen Anwendungszweck gibt werde ich meine Module im Moment weiterhin über Github bereitstellen.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 31 März 2015, 19:31:12
Stefan hat aber doch kein TCP Modbus, oder?
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 31 März 2015, 20:31:26
Doch, die aktuelle Version kann TCP und RTU, TCP hat er erst vor Kurzem hinzugefügt.
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 31 März 2015, 20:47:11
Mir war noch gar nicht klar das es weitere Module gibt... Ich schaue mir das mal an - du hast ja nun noch eine handvoll sonder sachen für Wago eingebaut, vielleicht ist eine Idee ein eigenes Wago_modbus modul daraus zu machen...
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: oniT am 01 April 2015, 21:23:20
Hallo,

ich habe das Modul von Stefan Strobel auch gesehen. Ich muss jedoch sagen ich komme damit nicht zurecht. Dies von Dir ist für bestimmte Anwendungen, zumindest aus meiner Sicht, besser geeignet.

Gruß
Tino
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: oniT am 06 April 2015, 15:55:31
Zitat von: Dieter1 am 15 Februar 2015, 10:36:25
Ich habe einen Stromzähler SDM630 mit RS485/Modbus Anschluss.
Da ich noch weitere RS485 Messstellen plane, meine seriellen Anchlüsse begrenzt sind und neue serielle Leitungen mir ein Greuel sind  :-) wollte ich auf das setzen, was ich überall verfügbar habe: TCPIP over LAN, WLAN oder dLAN.
Lösung: Modbus über TCPIP schicken und vorort in RS485 wandeln. TCPIP<->RS485 Wandler (TCP232-24, ca. 20,- € bei ebay)

Halllo Dieter,

würdest Du hierüber noch ein wenig genauere Ausführungen machen. Da ich leider nicht an die Messungen vom Haushaltstromzählers komme, finde ich die Lösung ziemlich elegant. Muss bei dem TCP IP<->RS485 Converter noch etwas beachtet werden? Welches 5V Netzteil setzt Du für die Spannungsversorgung ein? ... ect. pp. ...

Danke,

Gruß
Tino
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: lixilian am 19 Mai 2015, 12:22:00
Hallo zusammen,

ich hab ein kleines Verständnisproblem. Ich habe eine Wago SPS, welche ich über
define Wago ModbusTCPServer 192.168.x.x:502
auch wunderbar bekanntmachen kann. Nun möchte ich auf bestimmte Merkeradressen in der Wago zugreifen (Bit und Byte-Format). Also gebe ich z.B.
define SPS_Bit1 ModbusRegister 0 12297
ein und hoffe, das in der Wago gesetzte Bit zu sehen. Geht aber nicht. Das Attribut plcDataType lässt ja auch kein Bit zu. Ok. Aber selbst beim Zugriff auf Byte-Werte bekomme ich komische Ergebnisse (z.B. 3200 statt 50). Was mache ich falsch?

Danke schon mal für die Hilfe!
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: pc1246 am 19 Mai 2015, 12:40:50
Hallo lixilian

3200 ist doch 50! Zumindest wenn Du nur den linken Teil betrachtest und das als Hexwert nimmst! (3*16 + 2)
Ich habe das Modbus- Projekt aufgegeben, da ich Speicherplatzprobleme in der SPS hatte, deswegen kann ich Dir nicht so richtig weiterhelfen! Da war, wenn ich mich recht erinnere was mit den Registern!
Aber ChrisD wird dir bestimmt weiterhelfen!

Gruss und viel Spass noch mit fhem
Christoph
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: lixilian am 19 Mai 2015, 12:50:35
Klar! Danke Christoph!
Da bin ich wohl blind gewesen.  :o

Bleibt nur noch die Frage mit dem auszulesenden Bit. Wie mache ich das? Leider läuft bei mir schon vieles über einfache Bitregister (z.B. Taster und einfache Status).

EDIT:
Ich denke, ich hab es hinbekommen. Statt ModbusRegister hab ich nun (danke nochmal Christoph für den Hinweis) ModbusCoil genommen und außerdem das Attribut disableRegisterMapping auf 1 statt 0 gesetzt. Was ich da gemacht habe, weiß ich nicht so genau, aber es funktioniert - ich bekomme die Status der Bitwerte ausgelesen. Sehr schön!
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: pc1246 am 19 Mai 2015, 12:59:37
Hallo lixilian

Wie gesagt ich bin lange raus aus dem Thema! Ich denke aber du musst das als Coil definieren. Ich weiss auch nicht wieweit es einen Wiki-Eintrag gibt! Warte einfach bis ChrisD online ist, der hilft Dir schnell und absolut kompetent!

Gruss Christoph
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 19 Mai 2015, 18:55:22
Hallo,

Es gibt bei Modbus 2 Datentypen die unterschiedlich angesprochen werden müssen:
- Coils (Bits)
- Register (Words)

Dafür gibt es auch die 2 unterschiedlichen Module. Wenn du einzelne Bits lesen/steuern möchtest musst du ModbusCoil verwenden, bei Zahlen dagegen ModbusRegister.

Bei der aktuellen Version der Module kannst du auch direkt die Adressierung aus der SPS verwenden, wenn du z.B. auf das Bit MX0.9 zugreifen möchtest kannst du folgende Definition verwenden:
define SPS_Bit1 ModbusCoil wago MX0.9
Weitere Attribute sind in dem Fall nicht nötig.

Analog dazu kannst du auch WORD, REAL und DWORD anlegen:
define SPS_Word ModbusRegister wago MW20
define SPS_Real ModbusRegister wago MF20
define SPS_DWord ModbusRegister wago MD24


Das Attribut disableRegisterMapping schaltet die Umrechnung von Register- und Coilnummern zu Adressen ab. Bei Wago und einer Reihe anderer SPSen muss es auf 1 gesetzt werden da diese direkt die Adressen verwenden (was nicht ganz der Spezifikation entspricht), bei den meisten anderen Geräten dagegen braucht es nicht gesetzt zu werden. Das Attribut ist ohne Funktion wenn du die Definition mit der Wago-Adressierung, wie oben beschrieben, verwendest.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: lixilian am 21 Mai 2015, 06:49:09
Vielen Dank, Chris, für die ausführliche Antwort! Ich teste Fhem gerade. Die Anbindung an die Wago war das entscheidende Kriterium für den Einsatz und das funktioniert nun. Prima!
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: th1984 am 24 Mai 2015, 18:19:29
Hallo Allerseits,

ich bin echt begeistert was hier abgeht und wie hier Herausforderungen gelöst werden. Ich bin auch an einem etwas kniffligen Fall dran. Ich habe eine Helios Wohnraumlüftungsanlage. Soweit so gut, nur möchte ich diese nun auch an den FHEM der bei mir auf einem Raspberry läuft draufhängen. Das ganze stelle ich mir über die Ethernetschnittstelle und Modbus ganz einfach vor. Das Problem bei der Geschichte ist jetzt aber folgendes:

Um an die heiß begehrten Daten in der KWL zu kommen, muss ich zwei Dinge tun: zum einen einen Wert in eine Variable schreiben und dann erst auslesen. Das heißt im Klartext ich muss erst auf dem Bus einen Variablennamen senden den ich lesen möchte und diesen dann in dem "Standardregister" lesen.

Beispiel: ich sende folgendes: 0x7630 0x3030 0x3034 0x0000 (was nichts anderes als ein Variablenname ist)
Danach kann ich das Register ab Startadresse 1 mit einer fest vorgegebenen Länge auslesen.

Nun meine Frage, hat jemand sowas ähnliches schon mal umgesetzt? Hat irgendjemand einen Tipp für mich wo ich ähnliches evtl schon finde? Bzw wie ich sowas am einfachsten in FHEM umsetzten kann? Bin für jeden Hinweis dankbar!

Viele Grüße
Thomas

Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 25 Mai 2015, 20:43:35
Hallo,

Ich sehe 2 Möglichkeiten es in FHEM umzusetzen:
- ein eigenes Modul welches das Lesen und Schreiben 'kapselt', aufbauend auf 36_ModbusTCPServer
- mit den Funktionen aus 99_Modbus.pm und MBclient.pm sowie etwas Handarbeit, Erklärungen zu den Modulen gibt es u.a. im Beitrag 99 (http://forum.fhem.de/index.php/topic,12655.msg120397.html#msg120397).

Die 2. Möglichkeit könntest du so umsetzen:
- die im Anhang befindlichen Dateien im FHEM-Modulverzeichnis speichern
- FHEM neu starten
- einen dummy für die Modbus-Kommunikation anlegen (IP-Adresse anpassen):
define KWL dummy
attr KWL comment 192.168.78.99:502:1

- mit der Funktion write_modbus_multi zuerst die gewünschte Variable anfragen
- mit der Funktion read_modbus_multi das Ergebnis auslesen

Im Modul 99_myUtilsKWL findest du ein Beispiel wie dies funktionieren könnte. Die Funktion myUtilsKWL_Read erwartet 2 Parameter:
- die Anfrage (z.B v0004)
- die Länge der Antwort (für v0004 z.b. 9)
und gibt das Ergebnis aus (z.B. v00004=11.12.0013)

Zum Testen kannst du
{myUtilsKWL_Read("v00004",9)}in der FHEM-Befehlszeile eingeben.

Aus der Dokumentation ist leider nicht klar ersichtlich in welcher Reihenfolge die Bytes in die Words verpackt werden müssen. Hier musst du eventuell mit dem Beispielcode experimentieren. Du kannst die Datei 99_myUtilsKWL direkt in FHEM editieren (unter 'Edit files').

Wenn die Kommunikation bis funktioniert kannst du das Lesen über 'at' regelmäßig ausführen lassen.

Grüße,

ChrisD

Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: th1984 am 27 Mai 2015, 13:42:11
Hallo ChrisD,

vielen Dank für deine Ausführliche Antwort. Ich werde mich mit den beiden Vorgeschlagenen Möglichkeiten auseinandersetzten. Am besten gefallen würde mir ja die Variante 1. Mal sehen ob meine Kenntnisse dafür ausreichend sind.

Die zweite Variante erscheint mir irgendwie einfacher, darum werde ich diese auch gleich als erstes Versuchen wenn ich mal ein zwei ruhige Tage habe. Wenn das dann läuft werde ich Variante 1 gänzlich außen vor lassen.

Ich muss auf jeden Fall schon mal ein großes DANKE loswerden. Freue mich schon jetzt aufs experimentieren ;-)

vg
Thomas
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: qwikser am 30 Mai 2015, 16:53:53
Hallo nochmals,

hat sich ja einiges getan seit ich das letzte mal hier reingeschaut habe.   ;) :D
Und bei dem ganzen Fach Chinesisch was man so auf dem letzten paar Seiten liesst traue ich mich fast nicht meine, eher einfachen Fragen, zu stellen.  ::)

Zum einen wollte ich jetzt noch meine Batterie Meldung der MAX! Heizungssysteme an meine WAGO SPS senden, da mittlerweile meine Batterien den Geist aufgeben.

Versucht habe ich es wie folgt:

define fenster_battery_bad ModbusCoil 0 12950
attr fenster_battery_bad disableRegisterMapping 1
attr fenster_battery_bad event-on-change-reading state
attr fenster_battery_bad group Bad
attr fenster_battery_bad room Wago-MAX
define act_fenster_battery_bad notify MAX_01b046:battery.* { fhem "set fenster_battery_bad ".($EVTPART0 eq "low"?"on":"off")
#--------------------------------------------------------------------------------------------------------------------------- Bad Fenster Batterie


Anbei auch ein Bild der Readings von diesem Gerät. Das Reading "battery" ändert seinen Zustand von "ok" zu "low".

Auch habe ich festgestellt, wenn ich die neuste Version der Modbus Module benutze, dass fhem keine Daten mehr in meine Wago SPS schreibt.
Hier ein Beispiel was ich meine:

define fenster_aufzu_bad ModbusCoil 0 12949
attr fenster_aufzu_bad disableRegisterMapping 1
attr fenster_aufzu_bad event-on-change-reading state
attr fenster_aufzu_bad group Bad
attr fenster_aufzu_bad room Wago-MAX
define act_fenster_aufzu_bad notify MAX_01b046:onoff.* {fhem "set fenster_aufzu_bad ".($EVTPART1==1?"on":"off")}
#--------------------------------------------------------------------------------------------------------------------------- Bad Fenster Auf/Zu

Dies funktioniert nur mit den "alten" Modbus Modulen, mit den "neueren" von hier https://github.com/ChrisD70/FHEM-Modules (https://github.com/ChrisD70/FHEM-Modules) funktioniert das Schreiben auf die SPS nicht mehr.

MfG.
Daniel
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 30 Mai 2015, 23:29:42
Hallo,

Kannst du versuchen im notify $EVTPART1 statt $EVTPART0 zu verwenden und am Ende ein '}' hinzuzufügen:
define act_fenster_battery_bad notify MAX_01b046:battery.* { fhem "set fenster_battery_bad ".($EVTPART1 eq "low"?"on":"off")}
Damit sollte der Batteriezustand übertragen werden.

Das Problem beim Schreiben konnte ich nicht reproduzieren, ich verwende im Moment folgende Versionen:
Zitat# $Id: 37_ModbusCoil.pm 0008 $
# $Id: 37_ModbusRegister.pm 0016 $
# $Id: 36_ModbusTCPServer.pm 0015 $
Damit wird der Batteriezustand nach MX41.6 geschrieben.

Wenn du ein Update der Module machst solltest du die 3 Module gleichzeitig aktualisieren und danach FHEM neu starten.

Bei der aktuellen Version brauchst du nicht mehr die Adressen der Wago umzurechnen, du kannst statt
define fenster_battery_bad ModbusCoil 0 12950
attr fenster_battery_bad disableRegisterMapping 1


define fenster_battery_bad ModbusCoil wago MX41.6
verwenden.

Falls du es nochmal mit den neuen Modulen versuchst und das Schreiben weiterhin nicht funktioniert, kannst du die Ausgabe von
list fenster_battery_badposten ?

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: qwikser am 21 Oktober 2015, 20:00:41
Hallo Chris,

es ist zwar schon ein Paar Tage her, ...aber das mit dem Evtpart1 hat wunderbar funktioniert.
Bin in der zwischen  Zeit umgezogen und habe alles jetzt soweit durch Homematic Komponenten ausgetauscht. Funktioniert wie eine eins.
Auch nutze ich dieses Modul jetzt als Verbindung zwischen meiner IP-Symcon und FHEM - funtzt auch prima.

Vielen Dank nochmals
Daniel  ;D 8)
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: Smartissimo am 04 Januar 2016, 16:29:21
Halli Hallo,

ich muss das Thema mal wieder ein wenig aufrühren und benötige dringend Hilfe.

Ich habe einen Raspberry Pi mit FHEM ausgestattet und Ihn mit den neusten Versionen der 99_modbus und dem MBClien versehen. In der 99_modbus Datei von ChrisD wurde die my $modbusIP="192.168.10.2"; angepasst. In der fhem.cfg habe ich meine Befehle aufgeführt. Nachfolgend ein Beispiel:

#Definition Testbefehl
define Testcoil dummy
attr Testcoil devStateIcon On:Restart Off:Shutdown
attr Testcoil icon time_manual_mode
attr Testcoil room Handbetrieb
attr Testcoil setList On Off
attr Testcoil webCmd On:Off
define act_Testcoil notify Test { if (Value("Testcoil") eq "Off") {write_modbus_coil(160,"off")} else {write_modbus_coil(160,"on")}}


Schalten möchte ich ein Coil - also ein Modbus BIT - übersetzt wird das Ganze dann später auf eine Phoenix Contact SPS und entspricht dort dem Wort 109 Bit 15.

Nun mein Problem.
Ich bekomme keine Verbindung zu Stande. Mein Paspberry Pi gibt beim betätigen des Testcoils auch keinen Befehl aus (beobachtet über Wireshark - einzig und allein ein Keep Alive und Ack wird vom Raspi ausgesendet)
Die 99_modbus datei muss ja nicht aufgerufen werden in der cfg da sie ja eine System Kennung hat. Über den Start des Clients finde ich aber auch nichts in meinem Log File:
2015.02.12 12:01:04 0: Server shutdown
2015.02.12 12:01:08 1: Including fhem.cfg
2015.02.12 12:01:09 3: telnetPort: port 7072 opened
2015.02.12 12:01:09 3: WEB: port 8083 opened
2015.02.12 12:01:09 3: WEBphone: port 8084 opened
2015.02.12 12:01:09 3: WEBtablet: port 8085 opened
2015.02.12 12:01:10 2: eventTypes: loaded 52 events from ./log/eventTypes.txt
2015.02.12 12:01:10 1: Including ./log/fhem.save
2015.02.12 12:01:10 1: usb create starting
2015.02.12 12:01:12 3: Probing CUL device /dev/ttyAMA0
2015.02.12 12:01:12 3: Probing TCM_ESP3 device /dev/ttyAMA0
2015.02.12 12:01:12 3: Probing FRM device /dev/ttyAMA0
2015.02.12 12:01:18 1: usb create end
2015.02.12 12:01:18 2: SecurityCheck:  WEB,WEBtablet has no basicAuth attribute. telnetPort has no password/globalpassword attribute.  Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2015.02.12 12:01:18 0: Server started with 51 defined entities (version $Id: fhem.pl 6913 2014-11-08 10:32:44Z rudolfkoenig $, os linux, user fhem, pid 2266)
2015.02.12 12:22:15 1: Including fhem.cfg
2015.02.12 12:22:15 3: telnetPort: port 7072 opened
2015.02.12 12:22:15 3: WEB: port 8083 opened
2015.02.12 12:22:15 3: WEBphone: port 8084 opened
2015.02.12 12:22:15 3: WEBtablet: port 8085 opened
2015.02.12 12:22:15 2: eventTypes: loaded 52 events from ./log/eventTypes.txt
2015.02.12 12:22:16 1: Including ./log/fhem.save


Beim Schalten der Coils steht nur folgendes im Logfile:
015.02.12 12:31:14 2: write error address 161 value 1, er 2 ex 0
2015.02.12 12:31:17 2: write error address 162 value 1, er 2 ex 0
2015.02.12 12:31:21 2: write error address 163 value 1, er 2 ex 0
2015.02.12 12:31:41 2: write error address 164 value 1, er 2 ex 0
2015.02.12 12:31:44 2: write error address 165 value 1, er 2 ex 0
2015.02.12 12:31:47 2: write error address 166 value 1, er 2 ex 0
2015.02.12 12:32:29 2: write error address 161 value 0, er 2 ex 0
2015.02.12 12:32:32 2: write error address 162 value 0, er 2 ex 0
2015.02.12 12:32:35 2: write error address 164 value 0, er 2 ex 0
2015.02.12 12:32:38 2: write error address 165 value 0, er 2 ex 0
2015.02.12 12:32:41 2: write error address 166 value 0, er 2 ex 0
2015.02.12 12:35:24 2: write error address 163 value 0, er 2 ex 0


Wo liegt mein Fehler ?
Ich bitte um Hilfe ☺
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 04 Januar 2016, 17:49:04
Hallo,

Fehlercode 2 bedeutet dass die Gegenseite die Adresse als ungültig ansieht. Was benutzt du im Moment als Gegenstelle für den Raspberry Pi ?

99_modbus wird automatisch geladen und es gibt beim Start auch keine Meldungen im Log.

Für ein neues Projekt würde ich aber die Module 99_modbus und MBClient nicht mehr verwenden. Stattdessen würde ich die Module 36_ModbusTCPServer, 37_ModbusRegister und 37_ModbusCoil benutzen. Diese kannst du mit
update force https://raw.githubusercontent.com/ChrisD70/FHEM-Modules/master/autoupdate/mb/controls_modbus.txt
in FHEM auf dem Raspberry installieren.

Nach einem Neustart von FHEM kannst du dann die Verbindung mit
define SPS ModbusTCPServer 192.168.10.2:502anlegen.

Einzelne Coils kannst du mit
define Testcoil ModbusCoil 0 160
attr Testcoil event-on-change-reading .*
definieren.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: Smartissimo am 04 Januar 2016, 19:45:48
Hallo Chris,

vielen Dank für deine schnelle und kompetente Antwort.

Beim lesen des Beitrages ist mir im Vorfeld bereits der Verweis auf die Fehler IDs aufgefallen.
Ich habe jetzt die Kommunikation auf die neuen Dateien umgestellt.

Damit ist jetzt der erste Teilerfolg gekommen:

Zitat2015.02.12 14:17:25 3: Opening SPS device 192.168.10.2:502
2015.02.12 14:17:25 3: SPS device opened

Meine Gegenstelle sieht wie folgt aus:

http://imgur.com/FbBGxDJ (http://imgur.com/FbBGxDJ)

Das ist der ModBus Master Baustein von Phoenix Contact.
Die ModBus Coils verschiebe ich dann nach dem umrechnen auf Wort und Bit auf ein internes Bit.
Beispiel: Coil 160 = Wort 109 Bit 16

Jetzt habe ich noch eine Frage zu FHEM.

Ich muss ja jetzt das alte define zum event-on-change-reading umwandeln ? Ist das richtig ?

Zitat#Definition Testbefehl
define Testcoil ModbusCoil 0 160
attr Testcoil devStateIcon On:Restart Off:Shutdown
attr Testcoil icon time_manual_mode
attr Testcoil room Handbetrieb
attr Testcoil setList On Off
attr Testcoil webCmd On:Off

attr Testcoil event-on-change-reading .*
define act_Testcoil notify Testcoil  { if (Value("Testcoil ") eq "Off") {write_modbus_coil(160,"off")} else {write_modbus_coil(160,"on")}}

Viele Grüße,

Sven ;)
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 04 Januar 2016, 20:05:59
Hallo,

Das notify benötigst du nicht mehr, das Modul ModbusCoil kümmert sich intern um das Schreiben.
Das Attribut event-on-change-reading solltest du verwenden damit nicht bei jedem Lesen ein Eintrag ins Log oder die Datenbank gemacht wird. Die Attribute setList und webCmd können entfallen.

Zum Testen sollte
define Testcoil ModbusCoil 0 160
attr Testcoil devStateIcon On:Restart Off:Shutdown
attr Testcoil icon time_manual_mode
attr Testcoil room Handbetrieb
attr Testcoil event-on-change-reading .*

reichen.

Je nach SPS und Hersteller gibt es 2 unterschiedliche Zählweisen für die Coils und Register, wenn du ab 0 zählst musst du zusätzlich
attr Testcoil disableRegisterMapping 1verwenden. In dem Fall liegt bei deiner Konfiguration Coil 160 auf Wort 110, Bit 0, wenn du das Attribut disableRegisterMapping nicht verwendest liegt Coil 160 auf Wort 109, Bit 15.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: Smartissimo am 04 Januar 2016, 21:03:08
Hey,

Schritt für Schritt in Richtung Ziel.
Also umgesetzt habe ich es jetzt genau so. Die Verbindung steht nur sehe ich aktuell noch keine Ereignisse die normalerweise auf das Betätigen von On / Off beim Testcoil kommen.
Nachfolgend der Mitschnitt von Wireshark:

http://imgur.com/7NzgTSF (http://imgur.com/7NzgTSF)

Normalerweise sollte doch das ModBus TCP Paket mit der Quelle Raspberry Pi [192.168.10.62] und dem Ziel [192.168.10.2] zu sehen sein, oder bin ich da falscher Annahme. Bis jetzt juckt das Betätigen des Buttons auch meine SPS recht wenig.
Hast du eine Idee woran das liegen kann ?

Grüße,

Sven
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 04 Januar 2016, 21:28:33
Hallo,

Der Wireshark-Auszug sieht so aus als ob du Wireshark nicht auf dem Raspberry laufen hast sondern auf dem Rechner 192.168.10.25. Dadurch siehst du die Daten zwischen Raspberry und SPS nicht. Du kannst aber das Logging in FHEM mit
attr SPS verbose 5aktivieren und schauen was sich im Logfile von FHEM befindet. Alternativ könntest du auch tcpdump auf dem Raspberry benutzen um den Netzwerkverkehr mitzuschneiden.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: Smartissimo am 04 Januar 2016, 21:29:58
Gott ja klar  ::) das war dumm von mir :D ich probier es direkt mal aus und melde mich wieder ;D
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: Smartissimo am 04 Januar 2016, 21:39:44
Okay :D Nach kurzem Überblick verschaffen meine folgende Einschätzung

PS dispatch ModbusCoil:0:160:1:1:0
2015.02.12 16:20:48 5: AddRQueue [00 A1 00 00 00 06] 00 01 00 A1 00 08
2015.02.12 16:20:48 5: SimpleWrite [00 A1 00 00 00 06] 00 01 00 A1 00 08
2015.02.12 16:20:48 5: AddRQueue [00 A7 00 00 00 06] 00 01 00 A7 00 08
2015.02.12 16:20:48 5: adding to RQUEUE - 1
2015.02.12 16:20:48 5: AddRQueue [00 A0 00 00 00 06] 00 01 00 A0 00 08
2015.02.12 16:20:48 5: adding to RQUEUE - 2
2015.02.12 16:20:48 5: ModbusTCPServer_Parse: received [00 A1 00 00 00 04] 00 01 01 00
2015.02.12 16:20:48 5: SPS dispatch ModbusCoil:0:161:1:1:0
2015.02.12 16:20:48 4: RQUEUE: 2
2015.02.12 16:20:48 5: SimpleWrite [00 A7 00 00 00 06] 00 01 00 A7 00 08
2015.02.12 16:20:48 5: ModbusTCPServer_Parse: received [00 A7 00 00 00 04] 00 01 01 00
2015.02.12 16:20:48 5: SPS dispatch ModbusCoil:0:167:1:1:0
2015.02.12 16:20:48 4: RQUEUE: 1
2015.02.12 16:20:48 5: SimpleWrite [00 A0 00 00 00 06] 00 01 00 A0 00 08
2015.02.12 16:20:48 5: ModbusTCPServer_Parse: received [00 A0 00 00 00 04] 00 01 01 00


Es sieht für mich so aus das meine drei Beispiel Coils 160, 161 und 167 durch ModbusTCPServer_Parse: received bestätigt werden und somit von FHEM erzeugt / gesendet werden.

Interpretation korrekt ?  :o

Gruß,

Sven
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 04 Januar 2016, 21:51:00
Hallo,

Die 3 Coils wurden von der SPS gelesen. Wenn du den Wert auf der SPS änderst sollte er auch in FHEM angezeigt werden.

Wenn du in FHEM auf On oder Off klickst sollte auch der Wert geschrieben werden.

Du kannst über das Attribut pollInterval festlegen wie häufig die Werte von der SPS gelesen werden sollen,
attr SPS pollInterval 5führt dazu dass alle 5 Sekunden gelesen wird. Geschrieben wird immer bei Bedarf unabhängig von der eingestellten Zeit.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: Smartissimo am 05 Januar 2016, 21:16:58
Hallo Chris,

also nachdem ich mich heute mit ein paar anderen Sachen rumärgern musste bin ich wieder back to the roots.
Also die Bestätigung kommt im Logfile. Das Problem momentan ist aber leider, das der Zustand zwar von off auf set on (Glühbirne mit rotem Ausrufezeichen) geht, nach kurzer Zeit aber wieder zurück springt. Muss man den Zustand in der SPS speichern ?

In der SPS ist neber dem besagten Server
http://imgur.com/FbBGxDJ (http://imgur.com/FbBGxDJ)

die Verwendungsstelle wie folgt belegt
http://imgur.com/kJodb5i (http://imgur.com/kJodb5i)

normalerweise sollte es funktionieren :D Normalerweise ... Ich glaube ich habe irgendwo noch einen Denkfehler oder eine Wissenslücke  :o

Gruß,

Sven
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 05 Januar 2016, 21:39:57
Hallo,

Kannst du verbose beim Server wieder auf 5 setzen (attr SPS verbose 5) und die Logeinträge beim Schreiben posten.

Dass die Glühbirne auf set_on hängen bleibt könnte auch bedeuten dass die SPS das Schreiben abgelehnt hat, Details sollten auf jedem Fall im Log sein.

Setzt du das Bit 109.15 im SPS-Code wieder auf 0 ?

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: Smartissimo am 12 Januar 2016, 20:03:30
Hallo Chris,

hier nachfolgend der Log.
2015.02.14 14:26:16 1: Including fhem.cfg
2015.02.14 14:26:16 3: telnetPort: port 7072 opened
2015.02.14 14:26:16 3: WEB: port 8083 opened
2015.02.14 14:26:16 3: WEBphone: port 8084 opened
2015.02.14 14:26:16 3: WEBtablet: port 8085 opened
2015.02.14 14:26:16 2: eventTypes: loaded 62 events from ./log/eventTypes.txt
2015.02.14 14:26:16 3: Testcoil: I/O device is SPS
2015.02.14 14:26:16 3: 03_Uhr: I/O device is SPS
2015.02.14 14:26:16 3: Fernseher: I/O device is SPS
2015.02.14 14:26:16 1: Including ./log/fhem.save
2015.02.14 14:26:16 3: Opening SPS device 192.168.10.2:502
2015.02.14 14:26:16 3: SPS device opened
2015.02.14 14:26:18 5: AddWQueue [DD 08 00 00 00 06] 00 05 00 A1 FF 00
2015.02.14 14:26:21 5: AddWQueue [88 C9 00 00 00 06] 00 05 00 A1 FF 00
2015.02.14 14:26:21 5: AddRQueue [00 A1 00 00 00 06] 00 01 00 A1 00 08
2015.02.14 14:26:21 5: SimpleWrite [00 A1 00 00 00 06] 00 01 00 A1 00 08
2015.02.14 14:26:21 5: AddRQueue [00 A7 00 00 00 06] 00 01 00 A7 00 08
2015.02.14 14:26:21 5: adding to RQUEUE - 1
2015.02.14 14:26:21 5: AddRQueue [00 A0 00 00 00 06] 00 01 00 A0 00 08
2015.02.14 14:26:21 5: adding to RQUEUE - 2
2015.02.14 14:26:21 5: ModbusTCPServer_Parse: received [00 A1 00 00 00 04] 00 01 01 00
2015.02.14 14:26:21 5: SPS dispatch ModbusCoil:0:161:1:1:0
2015.02.14 14:26:21 4: RQUEUE: 2
2015.02.14 14:26:21 5: SimpleWrite [00 A7 00 00 00 06] 00 01 00 A7 00 08
2015.02.14 14:26:21 5: ModbusTCPServer_Parse: received [00 A7 00 00 00 04] 00 01 01 00
2015.02.14 14:26:21 5: SPS dispatch ModbusCoil:0:167:1:1:0
2015.02.14 14:26:21 4: RQUEUE: 1
2015.02.14 14:26:21 5: SimpleWrite [00 A0 00 00 00 06] 00 01 00 A0 00 08
2015.02.14 14:26:21 5: ModbusTCPServer_Parse: received [00 A0 00 00 00 04] 00 01 01 00
2015.02.14 14:26:21 5: SPS dispatch ModbusCoil:0:160:1:1:0
2015.02.14 14:26:26 5: AddWQueue [F7 1D 00 00 00 06] 00 05 00 A1 FF 00
2015.02.14 14:26:26 5: AddRQueue [00 A1 00 00 00 06] 00 01 00 A1 00 08
2015.02.14 14:26:26 5: SimpleWrite [00 A1 00 00 00 06] 00 01 00 A1 00 08
2015.02.14 14:26:26 5: AddRQueue [00 A7 00 00 00 06] 00 01 00 A7 00 08
2015.02.14 14:26:26 5: adding to RQUEUE - 1
2015.02.14 14:26:26 5: AddRQueue [00 A0 00 00 00 06] 00 01 00 A0 00 08
2015.02.14 14:26:26 5: adding to RQUEUE - 2
2015.02.14 14:26:26 5: ModbusTCPServer_Parse: received [00 A1 00 00 00 04] 00 01 01 00
2015.02.14 14:26:26 5: SPS dispatch ModbusCoil:0:161:1:1:0
2015.02.14 14:26:26 4: RQUEUE: 2
2015.02.14 14:26:26 5: SimpleWrite [00 A7 00 00 00 06] 00 01 00 A7 00 08
2015.02.14 14:26:26 5: ModbusTCPServer_Parse: received [00 A7 00 00 00 04] 00 01 01 00
2015.02.14 14:26:26 5: SPS dispatch ModbusCoil:0:167:1:1:0
2015.02.14 14:26:26 4: RQUEUE: 1
2015.02.14 14:26:26 5: SimpleWrite [00 A0 00 00 00 06] 00 01 00 A0 00 08
2015.02.14 14:26:26 5: ModbusTCPServer_Parse: received [00 A0 00 00 00 04] 00 01 01 00
2015.02.14 14:26:26 5: SPS dispatch ModbusCoil:0:160:1:1:0
2015.02.14 14:26:28 5: AddWQueue [5A D2 00 00 00 06] 00 05 00 A1 FF 00
2015.02.14 14:26:31 5: AddRQueue [00 A1 00 00 00 06] 00 01 00 A1 00 08
2015.02.14 14:26:31 5: SimpleWrite [00 A1 00 00 00 06] 00 01 00 A1 00 08
2015.02.14 14:26:31 5: AddRQueue [00 A7 00 00 00 06] 00 01 00 A7 00 08
2015.02.14 14:26:31 5: adding to RQUEUE - 1
2015.02.14 14:26:31 5: AddRQueue [00 A0 00 00 00 06] 00 01 00 A0 00 08
2015.02.14 14:26:31 5: adding to RQUEUE - 2
2015.02.14 14:26:31 5: ModbusTCPServer_Parse: received [00 A1 00 00 00 04] 00 01 01 00
2015.02.14 14:26:31 5: SPS dispatch ModbusCoil:0:161:1:1:0
2015.02.14 14:26:31 4: RQUEUE: 2
2015.02.14 14:26:31 5: SimpleWrite [00 A7 00 00 00 06] 00 01 00 A7 00 08
2015.02.14 14:26:31 5: ModbusTCPServer_Parse: received [00 A7 00 00 00 04] 00 01 01 00
2015.02.14 14:26:31 5: SPS dispatch ModbusCoil:0:167:1:1:0
2015.02.14 14:26:31 4: RQUEUE: 1
2015.02.14 14:26:31 5: SimpleWrite [00 A0 00 00 00 06] 00 01 00 A0 00 08
2015.02.14 14:26:31 5: ModbusTCPServer_Parse: received [00 A0 00 00 00 04] 00 01 01 00
2015.02.14 14:26:31 5: SPS dispatch ModbusCoil:0:160:1:1:0
2015.02.14 14:26:33 5: AddWQueue [CE 6D 00 00 00 06] 00 05 00 A1 FF 00
2015.02.14 14:26:36 5: AddRQueue [00 A1 00 00 00 06] 00 01 00 A1 00 08
2015.02.14 14:26:36 5: SimpleWrite [00 A1 00 00 00 06] 00 01 00 A1 00 08
2015.02.14 14:26:36 5: AddRQueue [00 A7 00 00 00 06] 00 01 00 A7 00 08
2015.02.14 14:26:36 5: adding to RQUEUE - 1
2015.02.14 14:26:36 5: AddRQueue [00 A0 00 00 00 06] 00 01 00 A0 00 08
2015.02.14 14:26:36 5: adding to RQUEUE - 2
2015.02.14 14:26:36 5: ModbusTCPServer_Parse: received [00 A1 00 00 00 04] 00 01 01 00
2015.02.14 14:26:36 5: SPS dispatch ModbusCoil:0:161:1:1:0
2015.02.14 14:26:36 4: RQUEUE: 2
2015.02.14 14:26:36 5: SimpleWrite [00 A7 00 00 00 06] 00 01 00 A7 00 08
2015.02.14 14:26:36 5: ModbusTCPServer_Parse: received [00 A7 00 00 00 04] 00 01 01 00
2015.02.14 14:26:36 5: SPS dispatch ModbusCoil:0:167:1:1:0
2015.02.14 14:26:36 4: RQUEUE: 1
2015.02.14 14:26:36 5: SimpleWrite [00 A0 00 00 00 06] 00 01 00 A0 00 08
2015.02.14 14:26:36 5: ModbusTCPServer_Parse: received [00 A0 00 00 00 04] 00 01 01 00
2015.02.14 14:26:36 5: SPS dispatch ModbusCoil:0:160:1:1:0
2015.02.14 14:26:39 5: AddWQueue [17 C3 00 00 00 06] 00 05 00 A1 FF 00
2015.02.14 14:26:41 5: AddRQueue [00 A1 00 00 00 06] 00 01 00 A1 00 08
2015.02.14 14:26:41 5: SimpleWrite [00 A1 00 00 00 06] 00 01 00 A1 00 08
2015.02.14 14:26:41 5: AddRQueue [00 A7 00 00 00 06] 00 01 00 A7 00 08
2015.02.14 14:26:41 5: adding to RQUEUE - 1
2015.02.14 14:26:41 5: AddRQueue [00 A0 00 00 00 06] 00 01 00 A0 00 08
2015.02.14 14:26:41 5: adding to RQUEUE - 2
2015.02.14 14:26:41 5: ModbusTCPServer_Parse: received [00 A1 00 00 00 04] 00 01 01 00
2015.02.14 14:26:41 5: SPS dispatch ModbusCoil:0:161:1:1:0
2015.02.14 14:26:41 4: RQUEUE: 2
2015.02.14 14:26:41 5: SimpleWrite [00 A7 00 00 00 06] 00 01 00 A7 00 08
2015.02.14 14:26:41 5: ModbusTCPServer_Parse: received [00 A7 00 00 00 04] 00 01 01 00
2015.02.14 14:26:41 5: SPS dispatch ModbusCoil:0:167:1:1:0
2015.02.14 14:26:41 4: RQUEUE: 1
2015.02.14 14:26:41 5: SimpleWrite [00 A0 00 00 00 06] 00 01 00 A0 00 08
2015.02.14 14:26:41 5: ModbusTCPServer_Parse: received [00 A0 00 00 00 04] 00 01 01 00
2015.02.14 14:26:41 5: SPS dispatch ModbusCoil:0:160:1:1:0
2015.02.14 14:26:46 5: AddWQueue [59 57 00 00 00 06] 00 05 00 A1 FF 00
2015.02.14 14:26:46 5: AddRQueue [00 A1 00 00 00 06] 00 01 00 A1 00 08
2015.02.14 14:26:46 5: SimpleWrite [00 A1 00 00 00 06] 00 01 00 A1 00 08
2015.02.14 14:26:46 5: AddRQueue [00 A7 00 00 00 06] 00 01 00 A7 00 08
2015.02.14 14:26:46 5: adding to RQUEUE - 1
2015.02.14 14:26:46 5: AddRQueue [00 A0 00 00 00 06] 00 01 00 A0 00 08
2015.02.14 14:26:46 5: adding to RQUEUE - 2
2015.02.14 14:26:46 5: ModbusTCPServer_Parse: received [00 A1 00 00 00 04] 00 01 01 00
2015.02.14 14:26:46 5: SPS dispatch ModbusCoil:0:161:1:1:0
2015.02.14 14:26:46 4: RQUEUE: 2
2015.02.14 14:26:46 5: SimpleWrite [00 A7 00 00 00 06] 00 01 00 A7 00 08
2015.02.14 14:26:46 5: ModbusTCPServer_Parse: received [00 A7 00 00 00 04] 00 01 01 00
2015.02.14 14:26:46 5: SPS dispatch ModbusCoil:0:167:1:1:0
2015.02.14 14:26:46 4: RQUEUE: 1
2015.02.14 14:26:46 5: SimpleWrite [00 A0 00 00 00 06] 00 01 00 A0 00 08
2015.02.14 14:26:46 5: ModbusTCPServer_Parse: received [00 A0 00 00 00 04] 00 01 01 00
2015.02.14 14:26:46 5: SPS dispatch ModbusCoil:0:160:1:1:0
2015.02.14 14:26:47 5: AddWQueue [99 E2 00 00 00 06] 00 05 00 A1 FF 00
2015.02.14 14:26:51 5: AddRQueue [00 A1 00 00 00 06] 00 01 00 A1 00 08
2015.02.14 14:26:51 5: SimpleWrite [00 A1 00 00 00 06] 00 01 00 A1 00 08
2015.02.14 14:26:51 5: AddRQueue [00 A7 00 00 00 06] 00 01 00 A7 00 08
2015.02.14 14:26:51 5: adding to RQUEUE - 1
2015.02.14 14:26:51 5: AddRQueue [00 A0 00 00 00 06] 00 01 00 A0 00 08
2015.02.14 14:26:51 5: adding to RQUEUE - 2
2015.02.14 14:26:51 5: ModbusTCPServer_Parse: received [00 A1 00 00 00 04] 00 01 01 00
2015.02.14 14:26:51 5: SPS dispatch ModbusCoil:0:161:1:1:0
2015.02.14 14:26:51 4: RQUEUE: 2
2015.02.14 14:26:51 5: SimpleWrite [00 A7 00 00 00 06] 00 01 00 A7 00 08
2015.02.14 14:26:51 5: ModbusTCPServer_Parse: received [00 A7 00 00 00 04] 00 01 01 00
2015.02.14 14:26:51 5: SPS dispatch ModbusCoil:0:167:1:1:0
2015.02.14 14:26:51 4: RQUEUE: 1
2015.02.14 14:26:51 5: SimpleWrite [00 A0 00 00 00 06] 00 01 00 A0 00 08
2015.02.14 14:26:51 5: ModbusTCPServer_Parse: received [00 A0 00 00 00 04] 00 01 01 00
2015.02.14 14:26:51 5: SPS dispatch ModbusCoil:0:160:1:1:0
2015.02.14 14:26:52 5: AddWQueue [B0 A7 00 00 00 06] 00 05 00 A1 FF 00
2015.02.14 14:26:56 5: AddRQueue [00 A1 00 00 00 06] 00 01 00 A1 00 08
2015.02.14 14:26:56 5: SimpleWrite [00 A1 00 00 00 06] 00 01 00 A1 00 08
2015.02.14 14:26:56 5: AddRQueue [00 A7 00 00 00 06] 00 01 00 A7 00 08
2015.02.14 14:26:56 5: adding to RQUEUE - 1
2015.02.14 14:26:56 5: AddRQueue [00 A0 00 00 00 06] 00 01 00 A0 00 08
2015.02.14 14:26:56 5: adding to RQUEUE - 2
2015.02.14 14:26:56 5: ModbusTCPServer_Parse: received [00 A1 00 00 00 04] 00 01 01 00
2015.02.14 14:26:56 5: SPS dispatch ModbusCoil:0:161:1:1:0
2015.02.14 14:26:56 4: RQUEUE: 2
2015.02.14 14:26:56 5: SimpleWrite [00 A7 00 00 00 06] 00 01 00 A7 00 08
2015.02.14 14:26:56 5: ModbusTCPServer_Parse: received [00 A7 00 00 00 04] 00 01 01 00
2015.02.14 14:26:56 5: SPS dispatch ModbusCoil:0:167:1:1:0
2015.02.14 14:26:56 4: RQUEUE: 1
2015.02.14 14:26:56 5: SimpleWrite [00 A0 00 00 00 06] 00 01 00 A0 00 08
2015.02.14 14:26:56 5: ModbusTCPServer_Parse: received [00 A0 00 00 00 04] 00 01 01 00
2015.02.14 14:26:56 5: SPS dispatch ModbusCoil:0:160:1:1:0
2015.02.14 14:26:57 5: AddWQueue [E6 B5 00 00 00 06] 00 05 00 A1 FF 00
2015.02.14 14:27:01 5: AddRQueue [00 A1 00 00 00 06] 00 01 00 A1 00 08
2015.02.14 14:27:01 5: SimpleWrite [00 A1 00 00 00 06] 00 01 00 A1 00 08
2015.02.14 14:27:01 5: AddRQueue [00 A7 00 00 00 06] 00 01 00 A7 00 08
2015.02.14 14:27:01 5: adding to RQUEUE - 1
2015.02.14 14:27:01 5: AddRQueue [00 A0 00 00 00 06] 00 01 00 A0 00 08
2015.02.14 14:27:01 5: adding to RQUEUE - 2
2015.02.14 14:27:01 5: ModbusTCPServer_Parse: received [00 A1 00 00 00 04] 00 01 01 00
2015.02.14 14:27:01 5: SPS dispatch ModbusCoil:0:161:1:1:0
2015.02.14 14:27:01 4: RQUEUE: 2
2015.02.14 14:27:01 5: SimpleWrite [00 A7 00 00 00 06] 00 01 00 A7 00 08
2015.02.14 14:27:01 5: ModbusTCPServer_Parse: received [00 A7 00 00 00 04] 00 01 01 00
2015.02.14 14:27:01 5: SPS dispatch ModbusCoil:0:167:1:1:0
2015.02.14 14:27:01 4: RQUEUE: 1
2015.02.14 14:27:01 5: SimpleWrite [00 A0 00 00 00 06] 00 01 00 A0 00 08
2015.02.14 14:27:01 5: ModbusTCPServer_Parse: received [00 A0 00 00 00 04] 00 01 01 00
2015.02.14 14:27:01 5: SPS dispatch ModbusCoil:0:160:1:1:0
2015.02.14 14:27:06 5: AddRQueue [00 A1 00 00 00 06] 00 01 00 A1 00 08
2015.02.14 14:27:06 5: SimpleWrite [00 A1 00 00 00 06] 00 01 00 A1 00 08
2015.02.14 14:27:06 5: AddRQueue [00 A7 00 00 00 06] 00 01 00 A7 00 08
2015.02.14 14:27:06 5: adding to RQUEUE - 1
2015.02.14 14:27:06 5: AddRQueue [00 A0 00 00 00 06] 00 01 00 A0 00 08
2015.02.14 14:27:06 5: adding to RQUEUE - 2
2015.02.14 14:27:06 5: ModbusTCPServer_Parse: received [00 A1 00 00 00 04] 00 01 01 00
2015.02.14 14:27:06 5: SPS dispatch ModbusCoil:0:161:1:1:0
2015.02.14 14:27:06 4: RQUEUE: 2
2015.02.14 14:27:06 5: SimpleWrite [00 A7 00 00 00 06] 00 01 00 A7 00 08
2015.02.14 14:27:06 5: ModbusTCPServer_Parse: received [00 A7 00 00 00 04] 00 01 01 00
2015.02.14 14:27:06 5: SPS dispatch ModbusCoil:0:167:1:1:0
2015.02.14 14:27:06 4: RQUEUE: 1
2015.02.14 14:27:06 5: SimpleWrite [00 A0 00 00 00 06] 00 01 00 A0 00 08
2015.02.14 14:27:06 5: ModbusTCPServer_Parse: received [00 A0 00 00 00 04] 00 01 01 00
2015.02.14 14:27:06 5: SPS dispatch ModbusCoil:0:160:1:1:0


Versucht wurde das Coil 160 zu schalten.
Zurückgesetzt wird das Coil nicht in der SPS. Ich gebe den Zustand direkt weiter in die logische Verknüpfung mittels MOVE Baustein bei Phoenix.

Gruß,

Sven
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 12 Januar 2016, 20:45:42
Hallo,

Die Daten werden von FHEM nicht geschrieben, was steht im Reading 'state' (nicht STATE) beim Server (SPS) ?

Welche Version von FHEM hast du (steht im Logfile, z.B. Server started with x defined entities (fhem.pl:10462/2016-01-11...) ?

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: Smartissimo am 16 Januar 2016, 10:33:30
Heyhoo,

also Version ist
2016.01.16 10:28:19 0: Server started with 44 defined entities (fhem.pl:10462/2016-01-11 perl:5.014002 os:linux user:fhem pid:2297)

der Modbus Server Baustein bietet nicht die Möglichkeit eines reading state, soweit ich das jetzt herausgefunden habe.

Ich dachte dispatch bedeutet das fhem sendet ? Startet die Modbus Adresse eigentlich bei 0 ?

//EDIT: On und Off bleiben übrigens nicht mehr hängen sondern schalten ordnungsgemäß um.

Grüße,

Sven
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: Smartissimo am 17 Januar 2016, 18:06:09
Der Wurm ist raus  :D

Der Fehler ist gefunden. Es war so unfassbar simpel das es umso ärgerlicher ist. Bei Verwenden der Modbus FC5 wurde zwar wie immer testweise in FHEM das Testcoil 160 geschaltet, in der Phoenix SPS wird aber das Coil 159 empfangen und gesetzt. Ich kann mir den OffSet nicht erklären. Ich bin heilfroh das die Kommunikation steht und die Daten wie vorgesehen gesendet und empfangen werden. Danke nochmal an ChrisD für den schnellen und kompetenten Support.
Vielleicht kann ich durch mein Problem ein paar kommenden Lesern die Fehlersuche erleichtern.

Beste Grüße,

Sven
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 17 Januar 2016, 18:16:30
Hallo,

ZitatStartet die Modbus Adresse eigentlich bei 0 ?
Die Adressen starten bei 0, aber (!) die Nummerierung der Register/Coils startet laut Spezifikation bei 1. Coil 160 liegt damit auf Adresse 159 (wie du feststellen musstest)

Leider ist es aber so dass verschiedene Hersteller Adressen und Coils/Registernummern in ihrer Dokumentation gleichsetzen. Aus diesem Grund gibt es das Attribut 'disableRegisterMapping'. Wenn dieses auf true steht sind Register/Coilnummern und Adressen identisch, andernfalls wird umgerechnet.

Bei der Anbindung an eine (rezente) SPS sollte disableRegisterMapping auf true gesetzt werden so dass keine Umrechnung nötig ist.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: belu am 17 Januar 2016, 18:20:55
Hi,

vorhin mal ausprobiert, läuft sehr gut! Verbinde ne Loxone Hausautomatisierung mit FHEM über eine Wago, die Wago is Slave und die anderen Beiden schreiben in die Adressregister der Wago. Problem ist nur bin mit FHEM nicht so vertraut.

Ich hab also FHEM nur mit diesem 00_THZ.pm am laufen weil ich diese Wärmepumpe habe, nun versuche ich die Infos weiter zu geben an meine Hausautomatisierung.

Ich hab nun also in der Wago und in FHEM 40 Wörter erstellt auf die ich schreibe bzw 20 Bit auf die ich etwas schreiben möchte.

Was rein soll sind die Readings aus dem THZ Modul. Da sind Istwerte die halt alle 60 Sekunden ausgelesen werden. Bzw möchte eich auch vereinzelnt auf Werte schreiben.

Hat jemand einen Tipp?

LG

Belu
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 17 Januar 2016, 20:32:30
Hallo,

Du kannst die Daten mit Hilfe von 'notify' übertragen. Wenn sich ein Wert der Wärmepumpe ändert wird er automatisch übertragen, z.B.:
define n_wp_heatTemp notify meinePumpe:heatTemp.* set mbregister1 $EVTPART1
define n_wp_returnTemp notify meinePumpe:returnTemp.* set mbregister2 $EVTPART1

Die passenden Reading-Namen musst du bei der Pumpe über userReadings bilden.

Wenn du Befehle an die Pumpe schicken möchtest, kannst du den umgekehrten Weg nehmen:
attr mbregister3 stateAlias p07FanStageDay
define n_wp_p07FanStageDay notify mbregister3:p07FanStageDay.* set meinePumpe p07FanStageDay $EVTPART1


Damit nur bei Änderung geschrieben wird solltest du zusätzlich event-on-change-reading setzen:
attr meinePumpe event-on-change-reading .*
attr mbregister3 event-on-change-reading .*


Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: belu am 26 Januar 2016, 20:38:05
Hallo ChrisD,

danke für deine Antwort,

hast du vielleicht noch ein Beispiel wie ich ein %MW oder %MD aufrufe, über einen Zyklus von 1 Minute und diesen in einer File Logge um ihn dann später Plotten und auswerten zu können?

LG
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 26 Januar 2016, 21:44:22
Hallo,

Wenn du einen Wert pro Minute loggen möchtest kannst du dies verwenden:

define MR_MW20 ModbusRegister wago MW20
attr MR_MW20 stateAlias measured-temp
attr MR_MW20 updateInterval 60


MW20 wird alle 60s gelesen und der Wert wird in das Reading measured-temp geschrieben.

define filelog_MW20 FileLog ./log/FL_MW20.log MR_MW20:measured-temp.*

Legt eine Datei im Verzeichnis ./log an (musst du eventuell anpassen) und speichert den gelesenen Wert ab.

Analog kannst du auch einen 32-Bit-Wert speichern:
define MR_MD40 ModbusRegister wago MD40
attr MR_MD40 stateAlias energy
attr MR_MD40 updateInterval 60
define filelog_MD40 FileLog ./log/FL_MD40.log MR_MD40:energy.*


Grüße,

ChrisD

Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: belu am 28 Januar 2016, 14:44:35
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
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 28 Januar 2016, 14:58:28
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:
define MR_MD100 ModbusRegister wago MF100

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: belu am 28 Januar 2016, 15:03:20
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

Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 28 Januar 2016, 17:29:06
Hallo,

Die Adressberechnung für MF und MD war falsch, kannst du die Module mit
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
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: belu am 28 Januar 2016, 17:37:20
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
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: belu am 29 Januar 2016, 13:10:20
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




Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 29 Januar 2016, 22:57:46
Hallo,

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

- Nachkommastellen auf 2 festlegen:
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:
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):
define n_MB_Log MR_MD10.* {fhem "set MB_Log TempHBK: ".Value("MR_MD100")." TempKanalVor: ".Value("MR_MD101")." TempHinterTNV: ".Value("MR_MD102")}

- Filelog anlegen:
define fl_MB FileLog ./log/FL_MB.log MB_Log.*

- regelmäßig ins Filelog schreiben:
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

Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: belu am 30 Januar 2016, 10:46:14
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.
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.

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
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: belu am 30 Januar 2016, 11:29:53
Habe es,

es war ein


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
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: PEPITO82 am 01 März 2016, 10:30:06
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:

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

Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 01 März 2016, 21:43:11
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 mitversionüberprüfen welche Version von ModbusTCPServer du verwendest ?

Du kannst versuchen mitattr 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

Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: PEPITO82 am 02 März 2016, 08:36:06
Hallo ChrisD,

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

version
spuckt Folgendes aus:

# $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:
update force https://raw.githubusercontent.com/ChrisD70/FHEM-Modules/master/autoupdate/mb/controls_modbus.txt

sehen die Versionen nun so aus:
# $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

Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: PEPITO82 am 17 März 2016, 08:19:34
Gestern kam es leider wieder zu Timeouts:

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.
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: UlliM am 06 April 2016, 17:26:27
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!
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 07 April 2016, 21:31:06
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
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
attr WagoSPS serverType Wago setzen und anschließend mit
list WagoSPSüberprüfen ob die Konfiguration ausgelesen wurde.

Wenn es funktioniert sollte die Ausgabe so ähnlich aussehen:
ZitatWagoSPS:
       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
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 08 April 2016, 14:22:09
Hallo ChrisD,
wow - die Version 19 scheint eine Anpassung speziell für mich zu enthalten - vielen Dank!

Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 14 April 2016, 22:02:59
Hallo ChrisD,
ich richte gerade ein neues Test-System ein, dabei installiere ich auch TabletUI, ich gehe nach der Anleitung im Fhemwiki vor und stosse dabei auf folgendes...
ZitatÜber update add https://raw.githubusercontent.com/knowthelist/fhem-tablet-ui/master/controls_fhemtabletui.txt kann seit dem 24.12.2015 die URL zum normalen Updatebefehl von FHEM hinzugefügt werden. Mit einen "update check" sieht man dann gleich alle Updates aus beiden "Welten".

Funktioniert das auch für Dein Modul?
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 14 April 2016, 23:01:35
Hallo,

Ja, mit dem Befehl
update add https://raw.githubusercontent.com/ChrisD70/FHEM-Modules/master/autoupdate/mb/controls_modbus.txt
kannst du die Module in das FHEM-Update einbinden.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 15 April 2016, 13:52:02
Danke für den Hinweis, das ist toll das es funktioniert mit dem update Mechanismus.

Ich habe noch ein problemchen.
Ich habe nun erstmalig zwei DMX Kanäle belegt und in FHEM zwei Slider definiert. ( MW200 & MW201 )
Die Slider beeinflussen sich in der FHEM Visu gegenseitig ( wenn ich einen bewege wird der Wert des anderen auch verändert ) das was in Wago ankommt und auch über DMX ausgegeben wird ist korrekt.

Hast Du eine Idee was da falsch läuft? Habe ich was falsch konfiguriert?
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: oniT am 16 April 2016, 13:14:45
Hallo ChrisD,

ich hätte auch mal noch ein Anliegen bei der nächsten Änderung der 37_ModbusCoil.pm. Und zwar kommt bei Attribute updateInterval eine Fehlermeldung

2016.03.08 21:34:32 3: dim_dhwpump_output: I/O device is HeatPumpServer
Argument "00:01:00" isn't numeric in addition (+) at ./FHEM/37_ModbusCoil.pm line 381, <> line 240.
2016.03.08 21:34:32 0: HourCounter hourcounter_dhwpump_output Define.228 parameters: hourcounter_dhwpump_output HourCounter dim_dhwpump_output:on dim_dhwpump_output:off
2016.03.08 21:34:32 3: dim_auxiliarypump_output: I/O device is HeatPumpServer
Argument "00:01:00" isn't numeric in addition (+) at ./FHEM/37_ModbusCoil.pm line 381, <> line 262.
2016.03.08 21:34:32 0: HourCounter hourcounter_auxiliarypump_output Define.228 parameters: hourcounter_auxiliarypump_output HourCounter dim_auxiliarypump_output:on dim_auxiliarypump_output:off


Bei ModbusCoil müssen die Zeiten noch in Sekunden eingetragen werden. Bei ModbusRegister hattest Du dies ja schon geändert. Würdest Du das bei Gelegenheit auch noch in der ModbusCoil mit anpassen und wäre es auch möglich bei ModbusCoil ebenfalls ein alignUpdateInterval wie bei ModbusRegister mit anzulegen. Dann sind diese Attribute bei beiden gleich.

Danke

Gruß,
Tino
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 16 April 2016, 22:23:39
Hallo,

@der-Lolo: Ich kann den Fehler nicht reproduzieren, kannst du die Definition und Attribute der beiden Slider posten ?

@Tino: Ich habe versucht das Attribut alignUpdateInterval einzubauen und die Zeitangabe geändert. Kannst du die Version 0012 (https://raw.githubusercontent.com/ChrisD70/FHEM-Modules/master/37_ModbusCoil.pm) testen ?

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 17 April 2016, 00:06:11
gerne jeweils ein list:

Internals:
   DEF        wago MW201
   IODev      wago
   NAME       Kaltlicht
   NR         81
   NTFY_ORDER 50-Kaltlicht
   STATE      255
   TYPE       ModbusRegister
   Readings:
     2015-03-02 02:10:10   Helligkeit      255
     2015-03-02 02:10:10   RAW             00ff
     2015-03-02 02:10:10   state           255
   Helper:
     addr       3 0 12489
     address    12489
     disableRegisterMapping 1
     nextUpdate 1425253101.94898
     nread      1
     readCmd    0�
     register   12489
     registerType 3
     unitId     0
     updateIntervall 0.1
     wago       1
     wagoDataType W
     Cnv:
       a          1
       b          0
       max        65535
       min        0
       step       100
Attributes:
   IODev      wago
   event-on-change-reading .*
   room       Wago
   setList    Helligkeit:slider,0,1,255
   stateAlias Helligkeit
   webCmd     Helligkeit


Internals:
   DEF        wago MW200
   IODev      wago
   NAME       Warmlicht
   NR         79
   NTFY_ORDER 50-Warmlicht
   STATE      255
   TYPE       ModbusRegister
   Readings:
     2015-03-02 02:10:10   Helligkeit      255
     2015-03-02 02:10:10   RAW             00ff
     2015-03-02 02:10:10   state           255
   Helper:
     addr       3 0 12488
     address    12488
     disableRegisterMapping 1
     nextUpdate 1425253101.92657
     nread      1
     readCmd    0�
     register   12488
     registerType 3
     unitId     0
     updateIntervall 0.1
     wago       1
     wagoDataType W
     Cnv:
       a          1
       b          0
       max        65535
       min        0
       step       100
Attributes:
   IODev      wago
   event-on-change-reading .*
   room       Wago
   setList    Helligkeit:slider,0,1,255
   stateAlias Helligkeit
   webCmd     Helligkeit


Noch ein eventmonitor auszug - ich betätige nur den Slider "Kaltlicht"

2016-04-17 12:21:20 ModbusRegister Kaltlicht Helligkeit 179
2016-04-17 12:21:20 ModbusRegister Kaltlicht 179
2016-04-17 12:21:20 ModbusRegister Kaltlicht RAW: 00b3
2016-04-17 12:21:20 ModbusRegister Kaltlicht Helligkeit: 179
2016-04-17 12:21:20 ModbusRegister Warmlicht 45824
2016-04-17 12:21:20 ModbusRegister Warmlicht RAW: b300
2016-04-17 12:21:20 ModbusRegister Warmlicht Helligkeit: 45824



Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 18 April 2016, 21:51:39
Hallo,

Ich kann den Effekt leider nicht nachvollziehen. Kannst du verbose beim Server auf 5 setzen und den Slider von Kaltlicht nochmal bewegen ?

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 18 April 2016, 23:36:51
ja, aber leider erst morgen abend im Hotel - aber ich wollte den krempel eh mitnehmen ;-)
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: opio am 19 April 2016, 23:07:56
Hallo,

ich habe einige Probleme mit der Kommunikation zu meiner SPS. Ich wäre sehr dankbar, wenn jemand mal ins Log schauen kann.
Das Problem: Tastendruck braucht ca. 1.5-3sec bis er auf der SPS ankommt.

2016.04.19 22:52:10 3: ModbusTCPServer_Timeout, request: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:52:14 3: ModbusTCPServer_Timeout, request: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:52:17 3: ModbusTCPServer_Timeout, request: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:52:21 3: ModbusTCPServer_Timeout, request: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:52:24 3: ModbusTCPServer_Timeout, request: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:52:28 3: ModbusTCPServer_Timeout, request: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:52:31 3: ModbusTCPServer_Timeout, request: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:52:35 3: ModbusTCPServer_Timeout, request: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:52:38 3: ModbusTCPServer_Timeout, request: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:52:42 3: ModbusTCPServer_Timeout, request: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:52:45 3: ModbusTCPServer_Timeout, request: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:52:49 3: ModbusTCPServer_Timeout, request: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:52:52 3: ModbusTCPServer_Timeout, request: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:52:56 3: ModbusTCPServer_Timeout, request: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:52:59 3: ModbusTCPServer_Timeout, request: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:53:02 3: ModbusTCPServer_Timeout, request: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:53:06 3: ModbusTCPServer_Timeout, request: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:53:09 3: ModbusTCPServer_Timeout, request: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:53:13 3: ModbusTCPServer_Timeout, request: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:53:16 3: ModbusTCPServer_Timeout, request: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:53:20 3: ModbusTCPServer_Timeout, request: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:53:23 3: ModbusTCPServer_Timeout, request: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:53:27 3: ModbusTCPServer_Timeout, request: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:53:30 3: ModbusTCPServer_Timeout, request: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:53:34 3: ModbusTCPServer_Timeout, request: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:53:37 3: ModbusTCPServer_Timeout, request: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:53:41 3: ModbusTCPServer_Timeout, request: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:53:42 3: ModbusTCPServer_Timeout, request: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:53:44 3: ModbusTCPServer_Timeout, request: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:53:45 3: ModbusTCPServer_Timeout, request: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:53:47 3: ModbusTCPServer_Timeout, request: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:53:48 3: ModbusTCPServer_Timeout, request: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:53:50 3: ModbusTCPServer_Timeout, request: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:53:51 3: ModbusTCPServer_Timeout, request: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:53:53 3: ModbusTCPServer_Timeout, request: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:53:54 3: ModbusTCPServer_Timeout, request: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:53:58 3: ModbusTCPServer_Timeout, request: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:54:01 3: ModbusTCPServer_Timeout, request: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:54:05 3: ModbusTCPServer_Timeout, request: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:54:08 3: ModbusTCPServer_Timeout, request: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:54:12 3: ModbusTCPServer_Timeout, request: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:54:15 3: ModbusTCPServer_Timeout, request: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:54:19 3: ModbusTCPServer_Timeout, request: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:54:22 3: ModbusTCPServer_Timeout, request: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:54:26 3: ModbusTCPServer_Timeout, request: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:54:29 3: ModbusTCPServer_Timeout, request: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:54:29 4: RQUEUE: 1
2016.04.19 22:54:29 5: SimpleWrite [08 00 00 00 00 06] 01 01 08 00 00 08
2016.04.19 22:54:29 5: ModbusTCPServer_Parse: received [08 00 00 00 00 04] 01 01 01 01
2016.04.19 22:54:29 5: sps dispatch ModbusCoil:1:2048:1:1:1
2016.04.19 22:54:30 5: AddRQueue [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:54:30 5: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:54:30 5: AddRQueue [08 00 00 00 00 06] 01 01 08 00 00 08
2016.04.19 22:54:30 5: adding to RQUEUE - 1
2016.04.19 22:54:31 5: AddWQueue [FD F1 00 00 00 06] 01 05 08 00 FF 00
2016.04.19 22:54:33 5: AddWQueue [49 07 00 00 00 06] 01 05 08 00 00 00
2016.04.19 22:54:33 5: adding to WQUEUE - 2
2016.04.19 22:54:33 3: ModbusTCPServer_Timeout, request: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:54:33 4: WQUEUE: ��� I
2016.04.19 22:54:33 5: SimpleWrite [FD F1 00 00 00 06] 01 05 08 00 FF 00
2016.04.19 22:54:33 5: ModbusTCPServer_Parse: received [FD F1 00 00 00 06] 01 05 08 00 FF 00
2016.04.19 22:54:33 5: sps dispatch ModbusCoil:1:2048:5:1:65280
2016.04.19 22:54:33 4: WQUEUE: I
2016.04.19 22:54:33 5: SimpleWrite [49 07 00 00 00 06] 01 05 08 00 00 00
2016.04.19 22:54:33 5: ModbusTCPServer_Parse: received [49 07 00 00 00 06] 01 05 08 00 00 00
2016.04.19 22:54:33 5: sps dispatch ModbusCoil:1:2048:5:1:0
2016.04.19 22:54:33 4: RQUEUE: 1
2016.04.19 22:54:33 5: SimpleWrite [08 00 00 00 00 06] 01 01 08 00 00 08
2016.04.19 22:54:33 5: ModbusTCPServer_Parse: received [08 00 00 00 00 04] 01 01 01 00
2016.04.19 22:54:33 5: sps dispatch ModbusCoil:1:2048:1:1:0
2016.04.19 22:54:33 5: AddRQueue [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:54:33 5: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:54:33 5: AddRQueue [08 00 00 00 00 06] 01 01 08 00 00 08
2016.04.19 22:54:33 5: adding to RQUEUE - 1
2016.04.19 22:54:34 5: AddWQueue [53 F0 00 00 00 06] 01 05 08 00 FF 00
2016.04.19 22:54:36 3: ModbusTCPServer_Timeout, request: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:54:36 4: WQUEUE: S��
2016.04.19 22:54:36 5: SimpleWrite [53 F0 00 00 00 06] 01 05 08 00 FF 00
2016.04.19 22:54:36 5: ModbusTCPServer_Parse: received [53 F0 00 00 00 06] 01 05 08 00 FF 00
2016.04.19 22:54:36 5: sps dispatch ModbusCoil:1:2048:5:1:65280
2016.04.19 22:54:36 4: RQUEUE: 1
2016.04.19 22:54:36 5: SimpleWrite [08 00 00 00 00 06] 01 01 08 00 00 08
2016.04.19 22:54:36 5: ModbusTCPServer_Parse: received [08 00 00 00 00 04] 01 01 01 01
2016.04.19 22:54:36 5: sps dispatch ModbusCoil:1:2048:1:1:1
2016.04.19 22:54:37 5: AddRQueue [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:54:37 5: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:54:37 5: AddRQueue [08 00 00 00 00 06] 01 01 08 00 00 08
2016.04.19 22:54:37 5: adding to RQUEUE - 1
2016.04.19 22:54:37 5: AddWQueue [17 EE 00 00 00 06] 01 05 08 00 00 00
2016.04.19 22:54:40 3: ModbusTCPServer_Timeout, request: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:54:40 4: WQUEUE: �
2016.04.19 22:54:40 5: SimpleWrite [17 EE 00 00 00 06] 01 05 08 00 00 00
2016.04.19 22:54:40 5: ModbusTCPServer_Parse: received [17 EE 00 00 00 06] 01 05 08 00 00 00
2016.04.19 22:54:40 5: sps dispatch ModbusCoil:1:2048:5:1:0
2016.04.19 22:54:40 4: RQUEUE: 1
2016.04.19 22:54:40 5: SimpleWrite [08 00 00 00 00 06] 01 01 08 00 00 08
2016.04.19 22:54:40 5: ModbusTCPServer_Parse: received [08 00 00 00 00 04] 01 01 01 00
2016.04.19 22:54:40 5: sps dispatch ModbusCoil:1:2048:1:1:0
2016.04.19 22:54:40 5: AddRQueue [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:54:40 5: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:54:40 5: AddRQueue [08 00 00 00 00 06] 01 01 08 00 00 08
2016.04.19 22:54:40 5: adding to RQUEUE - 1
2016.04.19 22:54:40 5: AddWQueue [39 85 00 00 00 06] 01 05 08 00 FF 00
2016.04.19 22:54:43 3: ModbusTCPServer_Timeout, request: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:54:43 4: WQUEUE: 9��
2016.04.19 22:54:43 5: SimpleWrite [39 85 00 00 00 06] 01 05 08 00 FF 00
2016.04.19 22:54:43 5: ModbusTCPServer_Parse: received [39 85 00 00 00 06] 01 05 08 00 FF 00
2016.04.19 22:54:43 5: sps dispatch ModbusCoil:1:2048:5:1:65280
2016.04.19 22:54:43 4: RQUEUE: 1
2016.04.19 22:54:43 5: SimpleWrite [08 00 00 00 00 06] 01 01 08 00 00 08
2016.04.19 22:54:43 5: ModbusTCPServer_Parse: received [08 00 00 00 00 04] 01 01 01 01
2016.04.19 22:54:43 5: sps dispatch ModbusCoil:1:2048:1:1:1
2016.04.19 22:54:44 5: AddWQueue [EF 67 00 00 00 06] 01 05 08 00 00 00
2016.04.19 22:54:44 5: SimpleWrite [EF 67 00 00 00 06] 01 05 08 00 00 00
2016.04.19 22:54:44 5: AddRQueue [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:54:44 5: AddRQueue [08 00 00 00 00 06] 01 01 08 00 00 08
2016.04.19 22:54:44 5: adding to RQUEUE - 2
2016.04.19 22:54:44 5: ModbusTCPServer_Parse: received [EF 67 00 00 00 06] 01 05 08 00 00 00
2016.04.19 22:54:44 5: sps dispatch ModbusCoil:1:2048:5:1:0
2016.04.19 22:54:44 4: RQUEUE: 2
2016.04.19 22:54:44 5: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:54:46 5: AddWQueue [71 A7 00 00 00 06] 01 05 08 00 FF 00
2016.04.19 22:54:47 3: ModbusTCPServer_Timeout, request: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:54:47 4: WQUEUE: q��
2016.04.19 22:54:47 5: SimpleWrite [71 A7 00 00 00 06] 01 05 08 00 FF 00
2016.04.19 22:54:47 5: ModbusTCPServer_Parse: received [71 A7 00 00 00 06] 01 05 08 00 FF 00
2016.04.19 22:54:47 5: sps dispatch ModbusCoil:1:2048:5:1:65280
2016.04.19 22:54:47 4: RQUEUE: 1
2016.04.19 22:54:47 5: SimpleWrite [08 00 00 00 00 06] 01 01 08 00 00 08
2016.04.19 22:54:47 5: ModbusTCPServer_Parse: received [08 00 00 00 00 04] 01 01 01 01
2016.04.19 22:54:47 5: sps dispatch ModbusCoil:1:2048:1:1:1
2016.04.19 22:54:47 5: AddRQueue [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:54:47 5: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:54:47 5: AddRQueue [08 00 00 00 00 06] 01 01 08 00 00 08
2016.04.19 22:54:47 5: adding to RQUEUE - 1
2016.04.19 22:54:47 5: AddWQueue [BC CC 00 00 00 06] 01 05 08 00 00 00
2016.04.19 22:54:50 3: ModbusTCPServer_Timeout, request: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:54:50 4: WQUEUE: ��
2016.04.19 22:54:50 5: SimpleWrite [BC CC 00 00 00 06] 01 05 08 00 00 00
2016.04.19 22:54:50 5: ModbusTCPServer_Parse: received [BC CC 00 00 00 06] 01 05 08 00 00 00
2016.04.19 22:54:50 5: sps dispatch ModbusCoil:1:2048:5:1:0
2016.04.19 22:54:50 4: RQUEUE: 1
2016.04.19 22:54:50 5: SimpleWrite [08 00 00 00 00 06] 01 01 08 00 00 08
2016.04.19 22:54:50 5: ModbusTCPServer_Parse: received [08 00 00 00 00 04] 01 01 01 00
2016.04.19 22:54:50 5: sps dispatch ModbusCoil:1:2048:1:1:0
2016.04.19 22:54:51 5: AddRQueue [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:54:51 5: SimpleWrite [00 00 00 00 00 06] 00 03 00 00 00 01
2016.04.19 22:54:51 5: AddRQueue [08 00 00 00 00 06] 01 01 08 00 00 08
2016.04.19 22:54:51 5: adding to RQUEUE - 1
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 20 April 2016, 19:41:32
Hallo,

Im Log ist regelmäßig ein Timeout zu sehen der dazu führt dass nachfolgende Befehle um bis zu 3 Sekunden verzögert werden. Der Timeout kommt von einem ModbusRegister für Unit 0 und Adresse 0. Deine SPS scheint diese Anfrage zu ignorieren was zum Timeout führt.

Wenn du das Register löschst (oder anpasst) sollte der Timeout verschwinden und die Schreibzugriffe sofort erfolgen.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 20 April 2016, 22:17:49
Hallo ChrisD,
jetzt nun endlich der Log mit verbose5

2016.04.20 22:10:12 3: Opening wago device 192.168.178.7:502
2016.04.20 22:10:12 3: wago device opened
2016.04.20 22:10:12 4: AddRQueue [20 10 00 00 00 06] 00 03 20 10 00 05
2016.04.20 22:10:12 5: SimpleWrite [20 10 00 00 00 06] 00 03 20 10 00 05
2016.04.20 22:10:12 4: AddRQueue [10 22 00 00 00 06] 00 03 10 22 00 04
2016.04.20 22:10:12 5: adding to RQUEUE - 1
2016.04.20 22:10:12 2: SecurityCheck:  WEB,WEBphone,WEBtablet has no associated allowed device with basicAuth. telnetPort has no associated allowed device with password/globalpassword.  Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2016.04.20 22:10:12 0: Featurelevel: 5.7
2016.04.20 22:10:12 0: Server started with 53 defined entities (fhem.pl:11267/2016-04-17 perl:5.014002 os:linux user:fhem pid:642)
2016.04.20 22:10:12 5: ModbusTCPServer_Parse: received [20 10 00 00 00 03] 00 83 02
2016.04.20 22:10:12 1: PERL WARNING: Use of uninitialized value in numeric eq (==) at ./FHEM/36_ModbusTCPServer.pm line 336.
2016.04.20 22:10:12 1: ModbusTCPServer_Parse: bad frame, sent: SimpleWrite [20 10 00 00 00 06] 00 03 20 10 00 05
2016.04.20 22:10:12 1: ModbusTCPServer_Parse: bad frame, received:  [20 10 00 00 00 03] 00 83 02
2016.04.20 22:10:15 3: ModbusTCPServer_Timeout, request: SimpleWrite [20 10 00 00 00 06] 00 03 20 10 00 05
2016.04.20 22:10:15 4: RQUEUE: 1
2016.04.20 22:10:15 5: SimpleWrite [10 22 00 00 00 06] 00 03 10 22 00 04
2016.04.20 22:10:15 5: ModbusTCPServer_Parse: received [10 22 00 00 00 0B] 00 03 08 00 C0 00 C0 00 18 00 10
2016.04.20 22:10:15 5: AddRQueue [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:15 5: SimpleWrite [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:15 5: AddRQueue [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:15 5: adding to RQUEUE - 1
2016.04.20 22:10:15 5: AddRQueue [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:15 5: adding to RQUEUE - 2
2016.04.20 22:10:15 5: ModbusTCPServer_Parse: received [30 C9 00 00 00 05] 00 03 02 00 9E
2016.04.20 22:10:15 5: wago dispatch ModbusRegister:0:12489:3:1:158
2016.04.20 22:10:15 5: ModbusRegister_Parse: 3 0 12489
2016.04.20 22:10:15 4: RQUEUE: 2
2016.04.20 22:10:15 5: SimpleWrite [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:15 5: ModbusTCPServer_Parse: received [30 C8 00 00 00 05] 00 03 02 9E C8
2016.04.20 22:10:15 5: wago dispatch ModbusRegister:0:12488:3:1:40648
2016.04.20 22:10:15 5: ModbusRegister_Parse: 3 0 12488
2016.04.20 22:10:15 4: RQUEUE: 1
2016.04.20 22:10:15 5: SimpleWrite [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:15 5: ModbusTCPServer_Parse: received [30 00 00 00 00 04] 00 01 01 01
2016.04.20 22:10:15 5: wago dispatch ModbusCoil:0:12288:1:1:1
2016.04.20 22:10:15 5: AddRQueue [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:15 5: SimpleWrite [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:15 5: AddRQueue [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:15 5: adding to RQUEUE - 1
2016.04.20 22:10:15 5: AddRQueue [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:15 5: adding to RQUEUE - 2
2016.04.20 22:10:15 5: ModbusTCPServer_Parse: received [30 C9 00 00 00 05] 00 03 02 00 9E
2016.04.20 22:10:15 5: wago dispatch ModbusRegister:0:12489:3:1:158
2016.04.20 22:10:15 5: ModbusRegister_Parse: 3 0 12489
2016.04.20 22:10:15 4: RQUEUE: 2
2016.04.20 22:10:15 5: SimpleWrite [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:15 5: ModbusTCPServer_Parse: received [30 C8 00 00 00 05] 00 03 02 9E C8
2016.04.20 22:10:15 5: wago dispatch ModbusRegister:0:12488:3:1:40648
2016.04.20 22:10:15 5: ModbusRegister_Parse: 3 0 12488
2016.04.20 22:10:15 4: RQUEUE: 1
2016.04.20 22:10:15 5: SimpleWrite [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:15 5: ModbusTCPServer_Parse: received [30 00 00 00 00 04] 00 01 01 01
2016.04.20 22:10:15 5: wago dispatch ModbusCoil:0:12288:1:1:1
2016.04.20 22:10:15 5: AddRQueue [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:15 5: SimpleWrite [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:15 5: AddRQueue [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:15 5: adding to RQUEUE - 1
2016.04.20 22:10:15 5: AddRQueue [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:15 5: adding to RQUEUE - 2
2016.04.20 22:10:15 5: ModbusTCPServer_Parse: received [30 C9 00 00 00 05] 00 03 02 00 9E
2016.04.20 22:10:15 5: wago dispatch ModbusRegister:0:12489:3:1:158
2016.04.20 22:10:15 5: ModbusRegister_Parse: 3 0 12489
2016.04.20 22:10:15 4: RQUEUE: 2
2016.04.20 22:10:15 5: SimpleWrite [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:15 5: ModbusTCPServer_Parse: received [30 C8 00 00 00 05] 00 03 02 9E C8
2016.04.20 22:10:15 5: wago dispatch ModbusRegister:0:12488:3:1:40648
2016.04.20 22:10:15 5: ModbusRegister_Parse: 3 0 12488
2016.04.20 22:10:15 4: RQUEUE: 1
2016.04.20 22:10:15 5: SimpleWrite [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:15 5: ModbusTCPServer_Parse: received [30 00 00 00 00 04] 00 01 01 01
2016.04.20 22:10:15 5: wago dispatch ModbusCoil:0:12288:1:1:1
2016.04.20 22:10:15 5: AddRQueue [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:15 5: SimpleWrite [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:15 5: AddRQueue [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:15 5: adding to RQUEUE - 1
2016.04.20 22:10:15 5: AddRQueue [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:15 5: adding to RQUEUE - 2
2016.04.20 22:10:15 5: ModbusTCPServer_Parse: received [30 C9 00 00 00 05] 00 03 02 00 9E
2016.04.20 22:10:15 5: wago dispatch ModbusRegister:0:12489:3:1:158
2016.04.20 22:10:15 5: ModbusRegister_Parse: 3 0 12489
2016.04.20 22:10:15 4: RQUEUE: 2
2016.04.20 22:10:15 5: SimpleWrite [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:15 5: ModbusTCPServer_Parse: received [30 C8 00 00 00 05] 00 03 02 9E C8
2016.04.20 22:10:15 5: wago dispatch ModbusRegister:0:12488:3:1:40648
2016.04.20 22:10:15 5: ModbusRegister_Parse: 3 0 12488
2016.04.20 22:10:15 4: RQUEUE: 1
2016.04.20 22:10:15 5: SimpleWrite [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:15 5: ModbusTCPServer_Parse: received [30 00 00 00 00 04] 00 01 01 01
2016.04.20 22:10:15 5: wago dispatch ModbusCoil:0:12288:1:1:1
2016.04.20 22:10:16 5: AddRQueue [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:16 5: SimpleWrite [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:16 5: AddRQueue [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:16 5: adding to RQUEUE - 1
2016.04.20 22:10:16 5: AddRQueue [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:16 5: adding to RQUEUE - 2
2016.04.20 22:10:16 5: ModbusTCPServer_Parse: received [30 C9 00 00 00 05] 00 03 02 00 9E
2016.04.20 22:10:16 5: wago dispatch ModbusRegister:0:12489:3:1:158
2016.04.20 22:10:16 5: ModbusRegister_Parse: 3 0 12489
2016.04.20 22:10:16 4: RQUEUE: 2
2016.04.20 22:10:16 5: SimpleWrite [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:16 5: ModbusTCPServer_Parse: received [30 C8 00 00 00 05] 00 03 02 9E C8
2016.04.20 22:10:16 5: wago dispatch ModbusRegister:0:12488:3:1:40648
2016.04.20 22:10:16 5: ModbusRegister_Parse: 3 0 12488
2016.04.20 22:10:16 4: RQUEUE: 1
2016.04.20 22:10:16 5: SimpleWrite [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:16 5: ModbusTCPServer_Parse: received [30 00 00 00 00 04] 00 01 01 01
2016.04.20 22:10:16 5: wago dispatch ModbusCoil:0:12288:1:1:1
2016.04.20 22:10:16 5: AddRQueue [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:16 5: SimpleWrite [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:16 5: AddRQueue [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:16 5: adding to RQUEUE - 1
2016.04.20 22:10:16 5: AddRQueue [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:16 5: adding to RQUEUE - 2
2016.04.20 22:10:16 5: ModbusTCPServer_Parse: received [30 C9 00 00 00 05] 00 03 02 00 9E
2016.04.20 22:10:16 5: wago dispatch ModbusRegister:0:12489:3:1:158
2016.04.20 22:10:16 5: ModbusRegister_Parse: 3 0 12489
2016.04.20 22:10:16 4: RQUEUE: 2
2016.04.20 22:10:16 5: SimpleWrite [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:16 5: ModbusTCPServer_Parse: received [30 C8 00 00 00 05] 00 03 02 9E C8
2016.04.20 22:10:16 5: wago dispatch ModbusRegister:0:12488:3:1:40648
2016.04.20 22:10:16 5: ModbusRegister_Parse: 3 0 12488
2016.04.20 22:10:16 4: RQUEUE: 1
2016.04.20 22:10:16 5: SimpleWrite [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:16 5: ModbusTCPServer_Parse: received [30 00 00 00 00 04] 00 01 01 01
2016.04.20 22:10:16 5: wago dispatch ModbusCoil:0:12288:1:1:1
2016.04.20 22:10:16 5: AddRQueue [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:16 5: SimpleWrite [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:16 5: AddRQueue [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:16 5: adding to RQUEUE - 1
2016.04.20 22:10:16 5: AddRQueue [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:16 5: adding to RQUEUE - 2
2016.04.20 22:10:16 5: ModbusTCPServer_Parse: received [30 C9 00 00 00 05] 00 03 02 00 9E
2016.04.20 22:10:16 5: wago dispatch ModbusRegister:0:12489:3:1:158
2016.04.20 22:10:16 5: ModbusRegister_Parse: 3 0 12489
2016.04.20 22:10:16 4: RQUEUE: 2
2016.04.20 22:10:16 5: SimpleWrite [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:16 5: ModbusTCPServer_Parse: received [30 C8 00 00 00 05] 00 03 02 9E C8
2016.04.20 22:10:16 5: wago dispatch ModbusRegister:0:12488:3:1:40648
2016.04.20 22:10:16 5: ModbusRegister_Parse: 3 0 12488
2016.04.20 22:10:16 4: RQUEUE: 1
2016.04.20 22:10:16 5: SimpleWrite [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:16 5: ModbusTCPServer_Parse: received [30 00 00 00 00 04] 00 01 01 01
2016.04.20 22:10:16 5: wago dispatch ModbusCoil:0:12288:1:1:1
2016.04.20 22:10:16 5: AddRQueue [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:16 5: SimpleWrite [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:16 5: AddRQueue [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:16 5: adding to RQUEUE - 1
2016.04.20 22:10:16 5: AddRQueue [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:16 5: adding to RQUEUE - 2
2016.04.20 22:10:16 5: ModbusTCPServer_Parse: received [30 C9 00 00 00 05] 00 03 02 00 9E
2016.04.20 22:10:16 5: wago dispatch ModbusRegister:0:12489:3:1:158
2016.04.20 22:10:16 5: ModbusRegister_Parse: 3 0 12489
2016.04.20 22:10:16 4: RQUEUE: 2
2016.04.20 22:10:16 5: SimpleWrite [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:16 5: ModbusTCPServer_Parse: received [30 C8 00 00 00 05] 00 03 02 9E C8
2016.04.20 22:10:16 5: wago dispatch ModbusRegister:0:12488:3:1:40648
2016.04.20 22:10:16 5: ModbusRegister_Parse: 3 0 12488
2016.04.20 22:10:16 4: RQUEUE: 1
2016.04.20 22:10:16 5: SimpleWrite [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:16 5: ModbusTCPServer_Parse: received [30 00 00 00 00 04] 00 01 01 01
2016.04.20 22:10:16 5: wago dispatch ModbusCoil:0:12288:1:1:1
2016.04.20 22:10:16 5: AddRQueue [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:16 5: SimpleWrite [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:16 5: AddRQueue [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:16 5: adding to RQUEUE - 1
2016.04.20 22:10:16 5: AddRQueue [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:16 5: adding to RQUEUE - 2
2016.04.20 22:10:16 5: ModbusTCPServer_Parse: received [30 C9 00 00 00 05] 00 03 02 00 9E
2016.04.20 22:10:16 5: wago dispatch ModbusRegister:0:12489:3:1:158
2016.04.20 22:10:16 5: ModbusRegister_Parse: 3 0 12489
2016.04.20 22:10:16 4: RQUEUE: 2
2016.04.20 22:10:16 5: SimpleWrite [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:16 5: ModbusTCPServer_Parse: received [30 C8 00 00 00 05] 00 03 02 9E C8
2016.04.20 22:10:16 5: wago dispatch ModbusRegister:0:12488:3:1:40648
2016.04.20 22:10:16 5: ModbusRegister_Parse: 3 0 12488
2016.04.20 22:10:16 4: RQUEUE: 1
2016.04.20 22:10:16 5: SimpleWrite [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:16 5: ModbusTCPServer_Parse: received [30 00 00 00 00 04] 00 01 01 01
2016.04.20 22:10:16 5: wago dispatch ModbusCoil:0:12288:1:1:1
2016.04.20 22:10:17 5: AddRQueue [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:17 5: SimpleWrite [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:17 5: AddRQueue [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:17 5: adding to RQUEUE - 1
2016.04.20 22:10:17 5: AddRQueue [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:17 5: adding to RQUEUE - 2
2016.04.20 22:10:17 5: ModbusTCPServer_Parse: received [30 C9 00 00 00 05] 00 03 02 00 9E
2016.04.20 22:10:17 5: wago dispatch ModbusRegister:0:12489:3:1:158
2016.04.20 22:10:17 5: ModbusRegister_Parse: 3 0 12489
2016.04.20 22:10:17 4: RQUEUE: 2
2016.04.20 22:10:17 5: SimpleWrite [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:17 5: ModbusTCPServer_Parse: received [30 C8 00 00 00 05] 00 03 02 9E C8
2016.04.20 22:10:17 5: wago dispatch ModbusRegister:0:12488:3:1:40648
2016.04.20 22:10:17 5: ModbusRegister_Parse: 3 0 12488
2016.04.20 22:10:17 4: RQUEUE: 1
2016.04.20 22:10:17 5: SimpleWrite [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:17 5: ModbusTCPServer_Parse: received [30 00 00 00 00 04] 00 01 01 01
2016.04.20 22:10:17 5: wago dispatch ModbusCoil:0:12288:1:1:1
2016.04.20 22:10:17 5: AddRQueue [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:17 5: SimpleWrite [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:17 5: AddRQueue [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:17 5: adding to RQUEUE - 1
2016.04.20 22:10:17 5: AddRQueue [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:17 5: adding to RQUEUE - 2
2016.04.20 22:10:17 5: ModbusTCPServer_Parse: received [30 C9 00 00 00 05] 00 03 02 00 9E
2016.04.20 22:10:17 5: wago dispatch ModbusRegister:0:12489:3:1:158
2016.04.20 22:10:17 5: ModbusRegister_Parse: 3 0 12489
2016.04.20 22:10:17 4: RQUEUE: 2
2016.04.20 22:10:17 5: SimpleWrite [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:17 5: ModbusTCPServer_Parse: received [30 C8 00 00 00 05] 00 03 02 9E C8
2016.04.20 22:10:17 5: wago dispatch ModbusRegister:0:12488:3:1:40648
2016.04.20 22:10:17 5: ModbusRegister_Parse: 3 0 12488
2016.04.20 22:10:17 4: RQUEUE: 1
2016.04.20 22:10:17 5: SimpleWrite [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:17 5: ModbusTCPServer_Parse: received [30 00 00 00 00 04] 00 01 01 01
2016.04.20 22:10:17 5: wago dispatch ModbusCoil:0:12288:1:1:1
2016.04.20 22:10:17 5: AddRQueue [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:17 5: SimpleWrite [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:17 5: AddRQueue [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:17 5: adding to RQUEUE - 1
2016.04.20 22:10:17 5: AddRQueue [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:17 5: adding to RQUEUE - 2
2016.04.20 22:10:17 5: ModbusTCPServer_Parse: received [30 C9 00 00 00 05] 00 03 02 00 9E
2016.04.20 22:10:17 5: wago dispatch ModbusRegister:0:12489:3:1:158
2016.04.20 22:10:17 5: ModbusRegister_Parse: 3 0 12489
2016.04.20 22:10:17 4: RQUEUE: 2
2016.04.20 22:10:17 5: SimpleWrite [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:17 5: ModbusTCPServer_Parse: received [30 C8 00 00 00 05] 00 03 02 9E C8
2016.04.20 22:10:17 5: wago dispatch ModbusRegister:0:12488:3:1:40648
2016.04.20 22:10:17 5: ModbusRegister_Parse: 3 0 12488
2016.04.20 22:10:17 4: RQUEUE: 1
2016.04.20 22:10:17 5: SimpleWrite [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:17 5: ModbusTCPServer_Parse: received [30 00 00 00 00 04] 00 01 01 01
2016.04.20 22:10:17 5: wago dispatch ModbusCoil:0:12288:1:1:1
2016.04.20 22:10:17 5: AddRQueue [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:17 5: SimpleWrite [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:17 5: AddRQueue [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:17 5: adding to RQUEUE - 1
2016.04.20 22:10:17 5: AddRQueue [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:17 5: adding to RQUEUE - 2
2016.04.20 22:10:17 5: ModbusTCPServer_Parse: received [30 C9 00 00 00 05] 00 03 02 00 9E
2016.04.20 22:10:17 5: wago dispatch ModbusRegister:0:12489:3:1:158
2016.04.20 22:10:17 5: ModbusRegister_Parse: 3 0 12489
2016.04.20 22:10:17 4: RQUEUE: 2
2016.04.20 22:10:17 5: SimpleWrite [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:17 5: ModbusTCPServer_Parse: received [30 C8 00 00 00 05] 00 03 02 9E C8
2016.04.20 22:10:17 5: wago dispatch ModbusRegister:0:12488:3:1:40648
2016.04.20 22:10:17 5: ModbusRegister_Parse: 3 0 12488
2016.04.20 22:10:17 4: RQUEUE: 1
2016.04.20 22:10:17 5: SimpleWrite [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:17 5: ModbusTCPServer_Parse: received [30 00 00 00 00 04] 00 01 01 01
2016.04.20 22:10:17 5: wago dispatch ModbusCoil:0:12288:1:1:1
2016.04.20 22:10:17 5: AddRQueue [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:17 5: SimpleWrite [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:17 5: AddRQueue [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:17 5: adding to RQUEUE - 1
2016.04.20 22:10:17 5: AddRQueue [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:17 5: adding to RQUEUE - 2
2016.04.20 22:10:17 5: ModbusTCPServer_Parse: received [30 C9 00 00 00 05] 00 03 02 00 9E
2016.04.20 22:10:17 5: wago dispatch ModbusRegister:0:12489:3:1:158
2016.04.20 22:10:17 5: ModbusRegister_Parse: 3 0 12489
2016.04.20 22:10:17 4: RQUEUE: 2
2016.04.20 22:10:17 5: SimpleWrite [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:17 5: ModbusTCPServer_Parse: received [30 C8 00 00 00 05] 00 03 02 9E C8
2016.04.20 22:10:17 5: wago dispatch ModbusRegister:0:12488:3:1:40648
2016.04.20 22:10:17 5: ModbusRegister_Parse: 3 0 12488
2016.04.20 22:10:17 4: RQUEUE: 1
2016.04.20 22:10:17 5: SimpleWrite [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:17 5: ModbusTCPServer_Parse: received [30 00 00 00 00 04] 00 01 01 01
2016.04.20 22:10:17 5: wago dispatch ModbusCoil:0:12288:1:1:1
2016.04.20 22:10:18 5: AddRQueue [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:18 5: SimpleWrite [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:18 5: AddRQueue [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:18 5: adding to RQUEUE - 1
2016.04.20 22:10:18 5: AddRQueue [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:18 5: adding to RQUEUE - 2
2016.04.20 22:10:18 5: ModbusTCPServer_Parse: received [30 C9 00 00 00 05] 00 03 02 00 9E
2016.04.20 22:10:18 5: wago dispatch ModbusRegister:0:12489:3:1:158
2016.04.20 22:10:18 5: ModbusRegister_Parse: 3 0 12489
2016.04.20 22:10:18 4: RQUEUE: 2
2016.04.20 22:10:18 5: SimpleWrite [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:18 5: ModbusTCPServer_Parse: received [30 C8 00 00 00 05] 00 03 02 9E C8
2016.04.20 22:10:18 5: wago dispatch ModbusRegister:0:12488:3:1:40648
2016.04.20 22:10:18 5: ModbusRegister_Parse: 3 0 12488
2016.04.20 22:10:18 4: RQUEUE: 1
2016.04.20 22:10:18 5: SimpleWrite [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:18 5: ModbusTCPServer_Parse: received [30 00 00 00 00 04] 00 01 01 01
2016.04.20 22:10:18 5: wago dispatch ModbusCoil:0:12288:1:1:1
2016.04.20 22:10:18 5: AddWQueue [1C B1 00 00 00 06] 00 06 30 C9 00 E2
2016.04.20 22:10:18 5: SimpleWrite [1C B1 00 00 00 06] 00 06 30 C9 00 E2
2016.04.20 22:10:18 5: AddRQueue [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:18 5: AddRQueue [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:18 5: adding to RQUEUE - 2
2016.04.20 22:10:18 5: AddRQueue [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:18 5: adding to RQUEUE - 3
2016.04.20 22:10:18 5: ModbusTCPServer_Parse: received [1C B1 00 00 00 06] 00 06 30 C9 00 E2
2016.04.20 22:10:18 5: wago dispatch ModbusRegister:0:12489:6:1:226
2016.04.20 22:10:18 5: ModbusRegister_Parse: 6 0 12489
2016.04.20 22:10:18 4: RQUEUE: 3
2016.04.20 22:10:18 5: SimpleWrite [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:18 5: ModbusTCPServer_Parse: received [30 C9 00 00 00 05] 00 03 02 00 E2
2016.04.20 22:10:18 5: wago dispatch ModbusRegister:0:12489:3:1:226
2016.04.20 22:10:18 5: ModbusRegister_Parse: 3 0 12489
2016.04.20 22:10:18 4: RQUEUE: 2
2016.04.20 22:10:18 5: SimpleWrite [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:18 5: ModbusTCPServer_Parse: received [30 C8 00 00 00 05] 00 03 02 E2 C8
2016.04.20 22:10:18 5: wago dispatch ModbusRegister:0:12488:3:1:58056
2016.04.20 22:10:18 5: ModbusRegister_Parse: 3 0 12488
2016.04.20 22:10:18 4: RQUEUE: 1
2016.04.20 22:10:18 5: SimpleWrite [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:18 5: ModbusTCPServer_Parse: received [30 00 00 00 00 04] 00 01 01 01
2016.04.20 22:10:18 5: wago dispatch ModbusCoil:0:12288:1:1:1
2016.04.20 22:10:18 5: AddRQueue [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:18 5: SimpleWrite [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:18 5: AddRQueue [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:18 5: adding to RQUEUE - 1
2016.04.20 22:10:18 5: AddRQueue [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:18 5: adding to RQUEUE - 2
2016.04.20 22:10:18 5: ModbusTCPServer_Parse: received [30 C9 00 00 00 05] 00 03 02 00 E2
2016.04.20 22:10:18 5: wago dispatch ModbusRegister:0:12489:3:1:226
2016.04.20 22:10:18 5: ModbusRegister_Parse: 3 0 12489
2016.04.20 22:10:18 4: RQUEUE: 2
2016.04.20 22:10:18 5: SimpleWrite [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:18 5: ModbusTCPServer_Parse: received [30 C8 00 00 00 05] 00 03 02 E2 C8
2016.04.20 22:10:18 5: wago dispatch ModbusRegister:0:12488:3:1:58056
2016.04.20 22:10:18 5: ModbusRegister_Parse: 3 0 12488
2016.04.20 22:10:18 4: RQUEUE: 1
2016.04.20 22:10:18 5: SimpleWrite [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:18 5: ModbusTCPServer_Parse: received [30 00 00 00 00 04] 00 01 01 01
2016.04.20 22:10:18 5: wago dispatch ModbusCoil:0:12288:1:1:1
2016.04.20 22:10:18 5: AddRQueue [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:18 5: SimpleWrite [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:18 5: AddRQueue [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:18 5: adding to RQUEUE - 1
2016.04.20 22:10:18 5: AddRQueue [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:18 5: adding to RQUEUE - 2
2016.04.20 22:10:18 5: ModbusTCPServer_Parse: received [30 C9 00 00 00 05] 00 03 02 00 E2
2016.04.20 22:10:18 5: wago dispatch ModbusRegister:0:12489:3:1:226
2016.04.20 22:10:18 5: ModbusRegister_Parse: 3 0 12489
2016.04.20 22:10:18 4: RQUEUE: 2
2016.04.20 22:10:18 5: SimpleWrite [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:18 5: ModbusTCPServer_Parse: received [30 C8 00 00 00 05] 00 03 02 E2 C8
2016.04.20 22:10:18 5: wago dispatch ModbusRegister:0:12488:3:1:58056
2016.04.20 22:10:18 5: ModbusRegister_Parse: 3 0 12488
2016.04.20 22:10:18 4: RQUEUE: 1
2016.04.20 22:10:18 5: SimpleWrite [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:18 5: ModbusTCPServer_Parse: received [30 00 00 00 00 04] 00 01 01 01
2016.04.20 22:10:18 5: wago dispatch ModbusCoil:0:12288:1:1:1
2016.04.20 22:10:18 5: AddRQueue [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:18 5: SimpleWrite [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:18 5: AddRQueue [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:18 5: adding to RQUEUE - 1
2016.04.20 22:10:18 5: AddRQueue [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:18 5: adding to RQUEUE - 2
2016.04.20 22:10:18 5: ModbusTCPServer_Parse: received [30 C9 00 00 00 05] 00 03 02 00 E2
2016.04.20 22:10:18 5: wago dispatch ModbusRegister:0:12489:3:1:226
2016.04.20 22:10:18 5: ModbusRegister_Parse: 3 0 12489
2016.04.20 22:10:18 4: RQUEUE: 2
2016.04.20 22:10:18 5: SimpleWrite [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:18 5: ModbusTCPServer_Parse: received [30 C8 00 00 00 05] 00 03 02 E2 C8
2016.04.20 22:10:18 5: wago dispatch ModbusRegister:0:12488:3:1:58056
2016.04.20 22:10:18 5: ModbusRegister_Parse: 3 0 12488
2016.04.20 22:10:18 4: RQUEUE: 1
2016.04.20 22:10:18 5: SimpleWrite [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:18 5: ModbusTCPServer_Parse: received [30 00 00 00 00 04] 00 01 01 01
2016.04.20 22:10:18 5: wago dispatch ModbusCoil:0:12288:1:1:1
2016.04.20 22:10:18 5: AddRQueue [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:18 5: SimpleWrite [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:18 5: AddRQueue [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:18 5: adding to RQUEUE - 1
2016.04.20 22:10:18 5: AddRQueue [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:18 5: adding to RQUEUE - 2
2016.04.20 22:10:18 5: ModbusTCPServer_Parse: received [30 C9 00 00 00 05] 00 03 02 00 E2
2016.04.20 22:10:18 5: wago dispatch ModbusRegister:0:12489:3:1:226
2016.04.20 22:10:18 5: ModbusRegister_Parse: 3 0 12489
2016.04.20 22:10:18 4: RQUEUE: 2
2016.04.20 22:10:18 5: SimpleWrite [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:18 5: ModbusTCPServer_Parse: received [30 C8 00 00 00 05] 00 03 02 E2 C8
2016.04.20 22:10:18 5: wago dispatch ModbusRegister:0:12488:3:1:58056
2016.04.20 22:10:18 5: ModbusRegister_Parse: 3 0 12488
2016.04.20 22:10:18 4: RQUEUE: 1
2016.04.20 22:10:18 5: SimpleWrite [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:18 5: ModbusTCPServer_Parse: received [30 00 00 00 00 04] 00 01 01 01
2016.04.20 22:10:18 5: wago dispatch ModbusCoil:0:12288:1:1:1
2016.04.20 22:10:19 5: AddRQueue [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:19 5: SimpleWrite [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:19 5: AddRQueue [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:19 5: adding to RQUEUE - 1
2016.04.20 22:10:19 5: AddRQueue [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:19 5: adding to RQUEUE - 2
2016.04.20 22:10:19 5: ModbusTCPServer_Parse: received [30 C9 00 00 00 05] 00 03 02 00 E2
2016.04.20 22:10:19 5: wago dispatch ModbusRegister:0:12489:3:1:226
2016.04.20 22:10:19 5: ModbusRegister_Parse: 3 0 12489
2016.04.20 22:10:19 4: RQUEUE: 2
2016.04.20 22:10:19 5: SimpleWrite [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:19 5: ModbusTCPServer_Parse: received [30 C8 00 00 00 05] 00 03 02 E2 C8
2016.04.20 22:10:19 5: wago dispatch ModbusRegister:0:12488:3:1:58056
2016.04.20 22:10:19 5: ModbusRegister_Parse: 3 0 12488
2016.04.20 22:10:19 4: RQUEUE: 1
2016.04.20 22:10:19 5: SimpleWrite [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:19 5: ModbusTCPServer_Parse: received [30 00 00 00 00 04] 00 01 01 01
2016.04.20 22:10:19 5: wago dispatch ModbusCoil:0:12288:1:1:1
2016.04.20 22:10:19 5: AddRQueue [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:19 5: SimpleWrite [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:19 5: AddRQueue [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:19 5: adding to RQUEUE - 1
2016.04.20 22:10:19 5: AddRQueue [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:19 5: adding to RQUEUE - 2
2016.04.20 22:10:19 5: ModbusTCPServer_Parse: received [30 C9 00 00 00 05] 00 03 02 00 E2
2016.04.20 22:10:19 5: wago dispatch ModbusRegister:0:12489:3:1:226
2016.04.20 22:10:19 5: ModbusRegister_Parse: 3 0 12489
2016.04.20 22:10:19 4: RQUEUE: 2
2016.04.20 22:10:19 5: SimpleWrite [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:19 5: ModbusTCPServer_Parse: received [30 C8 00 00 00 05] 00 03 02 E2 C8
2016.04.20 22:10:19 5: wago dispatch ModbusRegister:0:12488:3:1:58056
2016.04.20 22:10:19 5: ModbusRegister_Parse: 3 0 12488
2016.04.20 22:10:19 4: RQUEUE: 1
2016.04.20 22:10:19 5: SimpleWrite [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:19 5: ModbusTCPServer_Parse: received [30 00 00 00 00 04] 00 01 01 01
2016.04.20 22:10:19 5: wago dispatch ModbusCoil:0:12288:1:1:1
2016.04.20 22:10:19 5: AddRQueue [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:19 5: SimpleWrite [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:19 5: AddRQueue [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:19 5: adding to RQUEUE - 1
2016.04.20 22:10:19 5: AddRQueue [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:19 5: adding to RQUEUE - 2
2016.04.20 22:10:19 5: ModbusTCPServer_Parse: received [30 C9 00 00 00 05] 00 03 02 00 E2
2016.04.20 22:10:19 5: wago dispatch ModbusRegister:0:12489:3:1:226
2016.04.20 22:10:19 5: ModbusRegister_Parse: 3 0 12489
2016.04.20 22:10:19 4: RQUEUE: 2
2016.04.20 22:10:19 5: SimpleWrite [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:19 5: ModbusTCPServer_Parse: received [30 C8 00 00 00 05] 00 03 02 E2 C8
2016.04.20 22:10:19 5: wago dispatch ModbusRegister:0:12488:3:1:58056
2016.04.20 22:10:19 5: ModbusRegister_Parse: 3 0 12488
2016.04.20 22:10:19 4: RQUEUE: 1
2016.04.20 22:10:19 5: SimpleWrite [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:19 5: ModbusTCPServer_Parse: received [30 00 00 00 00 04] 00 01 01 01
2016.04.20 22:10:19 5: wago dispatch ModbusCoil:0:12288:1:1:1
2016.04.20 22:10:19 5: AddRQueue [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:19 5: SimpleWrite [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:19 5: AddRQueue [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:19 5: adding to RQUEUE - 1
2016.04.20 22:10:19 5: AddRQueue [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:19 5: adding to RQUEUE - 2
2016.04.20 22:10:19 5: ModbusTCPServer_Parse: received [30 C9 00 00 00 05] 00 03 02 00 E2
2016.04.20 22:10:19 5: wago dispatch ModbusRegister:0:12489:3:1:226
2016.04.20 22:10:19 5: ModbusRegister_Parse: 3 0 12489
2016.04.20 22:10:19 4: RQUEUE: 2
2016.04.20 22:10:19 5: SimpleWrite [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:19 5: ModbusTCPServer_Parse: received [30 C8 00 00 00 05] 00 03 02 E2 C8
2016.04.20 22:10:19 5: wago dispatch ModbusRegister:0:12488:3:1:58056
2016.04.20 22:10:19 5: ModbusRegister_Parse: 3 0 12488
2016.04.20 22:10:19 4: RQUEUE: 1
2016.04.20 22:10:19 5: SimpleWrite [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:19 5: ModbusTCPServer_Parse: received [30 00 00 00 00 04] 00 01 01 01
2016.04.20 22:10:19 5: wago dispatch ModbusCoil:0:12288:1:1:1
2016.04.20 22:10:19 5: AddRQueue [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:19 5: SimpleWrite [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:19 5: AddRQueue [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:19 5: adding to RQUEUE - 1
2016.04.20 22:10:19 5: AddRQueue [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:19 5: adding to RQUEUE - 2
2016.04.20 22:10:19 5: ModbusTCPServer_Parse: received [30 C9 00 00 00 05] 00 03 02 00 E2
2016.04.20 22:10:19 5: wago dispatch ModbusRegister:0:12489:3:1:226
2016.04.20 22:10:19 5: ModbusRegister_Parse: 3 0 12489
2016.04.20 22:10:19 4: RQUEUE: 2
2016.04.20 22:10:19 5: SimpleWrite [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:19 5: ModbusTCPServer_Parse: received [30 C8 00 00 00 05] 00 03 02 E2 C8
2016.04.20 22:10:19 5: wago dispatch ModbusRegister:0:12488:3:1:58056
2016.04.20 22:10:19 5: ModbusRegister_Parse: 3 0 12488
2016.04.20 22:10:19 4: RQUEUE: 1
2016.04.20 22:10:19 5: SimpleWrite [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:19 5: ModbusTCPServer_Parse: received [30 00 00 00 00 04] 00 01 01 01
2016.04.20 22:10:19 5: wago dispatch ModbusCoil:0:12288:1:1:1
2016.04.20 22:10:20 5: AddRQueue [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:20 5: SimpleWrite [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:20 5: AddRQueue [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:20 5: adding to RQUEUE - 1
2016.04.20 22:10:20 5: AddRQueue [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:20 5: adding to RQUEUE - 2
2016.04.20 22:10:20 5: ModbusTCPServer_Parse: received [30 C9 00 00 00 05] 00 03 02 00 E2
2016.04.20 22:10:20 5: wago dispatch ModbusRegister:0:12489:3:1:226
2016.04.20 22:10:20 5: ModbusRegister_Parse: 3 0 12489
2016.04.20 22:10:20 4: RQUEUE: 2
2016.04.20 22:10:20 5: SimpleWrite [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:20 5: ModbusTCPServer_Parse: received [30 C8 00 00 00 05] 00 03 02 E2 C8
2016.04.20 22:10:20 5: wago dispatch ModbusRegister:0:12488:3:1:58056
2016.04.20 22:10:20 5: ModbusRegister_Parse: 3 0 12488
2016.04.20 22:10:20 4: RQUEUE: 1
2016.04.20 22:10:20 5: SimpleWrite [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:20 5: ModbusTCPServer_Parse: received [30 00 00 00 00 04] 00 01 01 01
2016.04.20 22:10:20 5: wago dispatch ModbusCoil:0:12288:1:1:1
2016.04.20 22:10:20 5: AddRQueue [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:20 5: SimpleWrite [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:20 5: AddRQueue [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:20 5: adding to RQUEUE - 1
2016.04.20 22:10:20 5: AddRQueue [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:20 5: adding to RQUEUE - 2
2016.04.20 22:10:20 5: ModbusTCPServer_Parse: received [30 C9 00 00 00 05] 00 03 02 00 E2
2016.04.20 22:10:20 5: wago dispatch ModbusRegister:0:12489:3:1:226
2016.04.20 22:10:20 5: ModbusRegister_Parse: 3 0 12489
2016.04.20 22:10:20 4: RQUEUE: 2
2016.04.20 22:10:20 5: SimpleWrite [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:20 5: ModbusTCPServer_Parse: received [30 C8 00 00 00 05] 00 03 02 E2 C8
2016.04.20 22:10:20 5: wago dispatch ModbusRegister:0:12488:3:1:58056
2016.04.20 22:10:20 5: ModbusRegister_Parse: 3 0 12488
2016.04.20 22:10:20 4: RQUEUE: 1
2016.04.20 22:10:20 5: SimpleWrite [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:20 5: ModbusTCPServer_Parse: received [30 00 00 00 00 04] 00 01 01 01
2016.04.20 22:10:20 5: wago dispatch ModbusCoil:0:12288:1:1:1
2016.04.20 22:10:20 5: AddRQueue [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:20 5: SimpleWrite [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:20 5: AddRQueue [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:20 5: adding to RQUEUE - 1
2016.04.20 22:10:20 5: AddRQueue [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:20 5: adding to RQUEUE - 2
2016.04.20 22:10:20 5: ModbusTCPServer_Parse: received [30 C9 00 00 00 05] 00 03 02 00 E2
2016.04.20 22:10:20 5: wago dispatch ModbusRegister:0:12489:3:1:226
2016.04.20 22:10:20 5: ModbusRegister_Parse: 3 0 12489
2016.04.20 22:10:20 4: RQUEUE: 2
2016.04.20 22:10:20 5: SimpleWrite [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:20 5: ModbusTCPServer_Parse: received [30 C8 00 00 00 05] 00 03 02 E2 C8
2016.04.20 22:10:20 5: wago dispatch ModbusRegister:0:12488:3:1:58056
2016.04.20 22:10:20 5: ModbusRegister_Parse: 3 0 12488
2016.04.20 22:10:20 4: RQUEUE: 1
2016.04.20 22:10:20 5: SimpleWrite [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:20 5: ModbusTCPServer_Parse: received [30 00 00 00 00 04] 00 01 01 01
2016.04.20 22:10:20 5: wago dispatch ModbusCoil:0:12288:1:1:1
2016.04.20 22:10:20 5: AddRQueue [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:20 5: SimpleWrite [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:20 5: AddRQueue [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:20 5: adding to RQUEUE - 1
2016.04.20 22:10:20 5: AddRQueue [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:20 5: adding to RQUEUE - 2
2016.04.20 22:10:20 5: ModbusTCPServer_Parse: received [30 C9 00 00 00 05] 00 03 02 00 E2
2016.04.20 22:10:20 5: wago dispatch ModbusRegister:0:12489:3:1:226
2016.04.20 22:10:20 5: ModbusRegister_Parse: 3 0 12489
2016.04.20 22:10:20 4: RQUEUE: 2
2016.04.20 22:10:20 5: SimpleWrite [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:20 5: ModbusTCPServer_Parse: received [30 C8 00 00 00 05] 00 03 02 E2 C8
2016.04.20 22:10:20 5: wago dispatch ModbusRegister:0:12488:3:1:58056
2016.04.20 22:10:20 5: ModbusRegister_Parse: 3 0 12488
2016.04.20 22:10:20 4: RQUEUE: 1
2016.04.20 22:10:20 5: SimpleWrite [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:20 5: ModbusTCPServer_Parse: received [30 00 00 00 00 04] 00 01 01 01
2016.04.20 22:10:20 5: wago dispatch ModbusCoil:0:12288:1:1:1
2016.04.20 22:10:20 5: AddRQueue [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:20 5: SimpleWrite [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:20 5: AddRQueue [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:20 5: adding to RQUEUE - 1
2016.04.20 22:10:20 5: AddRQueue [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:20 5: adding to RQUEUE - 2
2016.04.20 22:10:20 5: ModbusTCPServer_Parse: received [30 C9 00 00 00 05] 00 03 02 00 E2
2016.04.20 22:10:20 5: wago dispatch ModbusRegister:0:12489:3:1:226
2016.04.20 22:10:20 5: ModbusRegister_Parse: 3 0 12489
2016.04.20 22:10:20 4: RQUEUE: 2
2016.04.20 22:10:20 5: SimpleWrite [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:20 5: ModbusTCPServer_Parse: received [30 C8 00 00 00 05] 00 03 02 E2 C8
2016.04.20 22:10:20 5: wago dispatch ModbusRegister:0:12488:3:1:58056
2016.04.20 22:10:20 5: ModbusRegister_Parse: 3 0 12488
2016.04.20 22:10:21 4: RQUEUE: 1
2016.04.20 22:10:21 5: SimpleWrite [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:21 5: ModbusTCPServer_Parse: received [30 00 00 00 00 04] 00 01 01 01
2016.04.20 22:10:21 5: wago dispatch ModbusCoil:0:12288:1:1:1
2016.04.20 22:10:21 5: AddRQueue [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:21 5: SimpleWrite [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:21 5: AddRQueue [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:21 5: adding to RQUEUE - 1
2016.04.20 22:10:21 5: AddRQueue [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:21 5: adding to RQUEUE - 2
2016.04.20 22:10:21 5: ModbusTCPServer_Parse: received [30 C9 00 00 00 05] 00 03 02 00 E2
2016.04.20 22:10:21 5: wago dispatch ModbusRegister:0:12489:3:1:226
2016.04.20 22:10:21 5: ModbusRegister_Parse: 3 0 12489
2016.04.20 22:10:21 4: RQUEUE: 2
2016.04.20 22:10:21 5: SimpleWrite [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:21 5: ModbusTCPServer_Parse: received [30 C8 00 00 00 05] 00 03 02 E2 C8
2016.04.20 22:10:21 5: wago dispatch ModbusRegister:0:12488:3:1:58056
2016.04.20 22:10:21 5: ModbusRegister_Parse: 3 0 12488
2016.04.20 22:10:21 4: RQUEUE: 1
2016.04.20 22:10:21 5: SimpleWrite [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:21 5: ModbusTCPServer_Parse: received [30 00 00 00 00 04] 00 01 01 01
2016.04.20 22:10:21 5: wago dispatch ModbusCoil:0:12288:1:1:1
2016.04.20 22:10:21 5: AddRQueue [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:21 5: SimpleWrite [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:21 5: AddRQueue [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:21 5: adding to RQUEUE - 1
2016.04.20 22:10:21 5: AddRQueue [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:21 5: adding to RQUEUE - 2
2016.04.20 22:10:21 5: ModbusTCPServer_Parse: received [30 C9 00 00 00 05] 00 03 02 00 E2
2016.04.20 22:10:21 5: wago dispatch ModbusRegister:0:12489:3:1:226
2016.04.20 22:10:21 5: ModbusRegister_Parse: 3 0 12489
2016.04.20 22:10:21 4: RQUEUE: 2
2016.04.20 22:10:21 5: SimpleWrite [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:21 5: ModbusTCPServer_Parse: received [30 C8 00 00 00 05] 00 03 02 E2 C8
2016.04.20 22:10:21 5: wago dispatch ModbusRegister:0:12488:3:1:58056
2016.04.20 22:10:21 5: ModbusRegister_Parse: 3 0 12488
2016.04.20 22:10:21 4: RQUEUE: 1
2016.04.20 22:10:21 5: SimpleWrite [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:21 5: ModbusTCPServer_Parse: received [30 00 00 00 00 04] 00 01 01 01
2016.04.20 22:10:21 5: wago dispatch ModbusCoil:0:12288:1:1:1
2016.04.20 22:10:21 5: AddRQueue [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:21 5: SimpleWrite [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:21 5: AddRQueue [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:21 5: adding to RQUEUE - 1
2016.04.20 22:10:21 5: AddRQueue [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:21 5: adding to RQUEUE - 2
2016.04.20 22:10:21 5: ModbusTCPServer_Parse: received [30 C9 00 00 00 05] 00 03 02 00 E2
2016.04.20 22:10:21 5: wago dispatch ModbusRegister:0:12489:3:1:226
2016.04.20 22:10:21 5: ModbusRegister_Parse: 3 0 12489
2016.04.20 22:10:21 4: RQUEUE: 2
2016.04.20 22:10:21 5: SimpleWrite [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:21 5: ModbusTCPServer_Parse: received [30 C8 00 00 00 05] 00 03 02 E2 C8
2016.04.20 22:10:21 5: wago dispatch ModbusRegister:0:12488:3:1:58056
2016.04.20 22:10:21 5: ModbusRegister_Parse: 3 0 12488
2016.04.20 22:10:21 4: RQUEUE: 1
2016.04.20 22:10:21 5: SimpleWrite [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:21 5: ModbusTCPServer_Parse: received [30 00 00 00 00 04] 00 01 01 01
2016.04.20 22:10:21 5: wago dispatch ModbusCoil:0:12288:1:1:1
2016.04.20 22:10:21 5: AddRQueue [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:21 5: SimpleWrite [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:21 5: AddRQueue [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:21 5: adding to RQUEUE - 1
2016.04.20 22:10:21 5: AddRQueue [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:21 5: adding to RQUEUE - 2
2016.04.20 22:10:21 5: ModbusTCPServer_Parse: received [30 C9 00 00 00 05] 00 03 02 00 E2
2016.04.20 22:10:21 5: wago dispatch ModbusRegister:0:12489:3:1:226
2016.04.20 22:10:21 5: ModbusRegister_Parse: 3 0 12489
2016.04.20 22:10:21 4: RQUEUE: 2
2016.04.20 22:10:21 5: SimpleWrite [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:21 5: ModbusTCPServer_Parse: received [30 C8 00 00 00 05] 00 03 02 E2 C8
2016.04.20 22:10:21 5: wago dispatch ModbusRegister:0:12488:3:1:58056
2016.04.20 22:10:21 5: ModbusRegister_Parse: 3 0 12488
2016.04.20 22:10:21 4: RQUEUE: 1
2016.04.20 22:10:21 5: SimpleWrite [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:21 5: ModbusTCPServer_Parse: received [30 00 00 00 00 04] 00 01 01 01
2016.04.20 22:10:21 5: wago dispatch ModbusCoil:0:12288:1:1:1
2016.04.20 22:10:21 5: AddRQueue [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:21 5: SimpleWrite [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:21 5: AddRQueue [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:21 5: adding to RQUEUE - 1
2016.04.20 22:10:21 5: AddRQueue [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:21 5: adding to RQUEUE - 2
2016.04.20 22:10:21 5: ModbusTCPServer_Parse: received [30 C9 00 00 00 05] 00 03 02 00 E2
2016.04.20 22:10:21 5: wago dispatch ModbusRegister:0:12489:3:1:226
2016.04.20 22:10:21 5: ModbusRegister_Parse: 3 0 12489
2016.04.20 22:10:21 4: RQUEUE: 2
2016.04.20 22:10:21 5: SimpleWrite [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:21 5: ModbusTCPServer_Parse: received [30 C8 00 00 00 05] 00 03 02 E2 C8
2016.04.20 22:10:21 5: wago dispatch ModbusRegister:0:12488:3:1:58056
2016.04.20 22:10:22 5: ModbusRegister_Parse: 3 0 12488
2016.04.20 22:10:22 4: RQUEUE: 1
2016.04.20 22:10:22 5: SimpleWrite [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:22 5: ModbusTCPServer_Parse: received [30 00 00 00 00 04] 00 01 01 01
2016.04.20 22:10:22 5: wago dispatch ModbusCoil:0:12288:1:1:1
2016.04.20 22:10:22 5: AddRQueue [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:22 5: SimpleWrite [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:22 5: AddRQueue [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:22 5: adding to RQUEUE - 1
2016.04.20 22:10:22 5: AddRQueue [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:22 5: adding to RQUEUE - 2
2016.04.20 22:10:22 5: ModbusTCPServer_Parse: received [30 C9 00 00 00 05] 00 03 02 00 E2
2016.04.20 22:10:22 5: wago dispatch ModbusRegister:0:12489:3:1:226
2016.04.20 22:10:22 5: ModbusRegister_Parse: 3 0 12489
2016.04.20 22:10:22 4: RQUEUE: 2
2016.04.20 22:10:22 5: SimpleWrite [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:22 5: ModbusTCPServer_Parse: received [30 C8 00 00 00 05] 00 03 02 E2 C8
2016.04.20 22:10:22 5: wago dispatch ModbusRegister:0:12488:3:1:58056
2016.04.20 22:10:22 5: ModbusRegister_Parse: 3 0 12488
2016.04.20 22:10:22 4: RQUEUE: 1
2016.04.20 22:10:22 5: SimpleWrite [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:22 5: ModbusTCPServer_Parse: received [30 00 00 00 00 04] 00 01 01 01
2016.04.20 22:10:22 5: wago dispatch ModbusCoil:0:12288:1:1:1
2016.04.20 22:10:22 5: AddRQueue [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:22 5: SimpleWrite [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:22 5: AddRQueue [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:22 5: adding to RQUEUE - 1
2016.04.20 22:10:22 5: AddRQueue [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:22 5: adding to RQUEUE - 2
2016.04.20 22:10:22 5: ModbusTCPServer_Parse: received [30 C9 00 00 00 05] 00 03 02 00 E2
2016.04.20 22:10:22 5: wago dispatch ModbusRegister:0:12489:3:1:226
2016.04.20 22:10:22 5: ModbusRegister_Parse: 3 0 12489
2016.04.20 22:10:22 4: RQUEUE: 2
2016.04.20 22:10:22 5: SimpleWrite [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:22 5: ModbusTCPServer_Parse: received [30 C8 00 00 00 05] 00 03 02 E2 C8
2016.04.20 22:10:22 5: wago dispatch ModbusRegister:0:12488:3:1:58056
2016.04.20 22:10:22 5: ModbusRegister_Parse: 3 0 12488
2016.04.20 22:10:22 4: RQUEUE: 1
2016.04.20 22:10:22 5: SimpleWrite [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:22 5: ModbusTCPServer_Parse: received [30 00 00 00 00 04] 00 01 01 01
2016.04.20 22:10:22 5: wago dispatch ModbusCoil:0:12288:1:1:1
2016.04.20 22:10:22 5: AddRQueue [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:22 5: SimpleWrite [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:22 5: AddRQueue [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:22 5: adding to RQUEUE - 1
2016.04.20 22:10:22 5: AddRQueue [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:22 5: adding to RQUEUE - 2
2016.04.20 22:10:22 5: ModbusTCPServer_Parse: received [30 C9 00 00 00 05] 00 03 02 00 E2
2016.04.20 22:10:22 5: wago dispatch ModbusRegister:0:12489:3:1:226
2016.04.20 22:10:22 5: ModbusRegister_Parse: 3 0 12489
2016.04.20 22:10:22 4: RQUEUE: 2
2016.04.20 22:10:22 5: SimpleWrite [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:22 5: ModbusTCPServer_Parse: received [30 C8 00 00 00 05] 00 03 02 E2 C8
2016.04.20 22:10:22 5: wago dispatch ModbusRegister:0:12488:3:1:58056
2016.04.20 22:10:22 5: ModbusRegister_Parse: 3 0 12488
2016.04.20 22:10:22 4: RQUEUE: 1
2016.04.20 22:10:22 5: SimpleWrite [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:22 5: ModbusTCPServer_Parse: received [30 00 00 00 00 04] 00 01 01 01
2016.04.20 22:10:22 5: wago dispatch ModbusCoil:0:12288:1:1:1
2016.04.20 22:10:22 5: AddRQueue [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:22 5: SimpleWrite [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:22 5: AddRQueue [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:22 5: adding to RQUEUE - 1
2016.04.20 22:10:22 5: AddRQueue [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:22 5: adding to RQUEUE - 2
2016.04.20 22:10:22 5: ModbusTCPServer_Parse: received [30 C9 00 00 00 05] 00 03 02 00 E2
2016.04.20 22:10:22 5: wago dispatch ModbusRegister:0:12489:3:1:226
2016.04.20 22:10:22 5: ModbusRegister_Parse: 3 0 12489
2016.04.20 22:10:22 4: RQUEUE: 2
2016.04.20 22:10:22 5: SimpleWrite [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:22 5: ModbusTCPServer_Parse: received [30 C8 00 00 00 05] 00 03 02 E2 C8
2016.04.20 22:10:22 5: wago dispatch ModbusRegister:0:12488:3:1:58056
2016.04.20 22:10:22 5: ModbusRegister_Parse: 3 0 12488
2016.04.20 22:10:22 4: RQUEUE: 1
2016.04.20 22:10:22 5: SimpleWrite [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:22 5: ModbusTCPServer_Parse: received [30 00 00 00 00 04] 00 01 01 01
2016.04.20 22:10:22 5: wago dispatch ModbusCoil:0:12288:1:1:1
2016.04.20 22:10:22 5: AddRQueue [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:22 5: SimpleWrite [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:22 5: AddRQueue [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:22 5: adding to RQUEUE - 1
2016.04.20 22:10:22 5: AddRQueue [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:22 5: adding to RQUEUE - 2
2016.04.20 22:10:22 5: ModbusTCPServer_Parse: received [30 C9 00 00 00 05] 00 03 02 00 E2
2016.04.20 22:10:22 5: wago dispatch ModbusRegister:0:12489:3:1:226
2016.04.20 22:10:22 5: ModbusRegister_Parse: 3 0 12489
2016.04.20 22:10:23 4: RQUEUE: 2
2016.04.20 22:10:23 5: SimpleWrite [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:23 5: ModbusTCPServer_Parse: received [30 C8 00 00 00 05] 00 03 02 E2 C8
2016.04.20 22:10:23 5: wago dispatch ModbusRegister:0:12488:3:1:58056
2016.04.20 22:10:23 5: ModbusRegister_Parse: 3 0 12488
2016.04.20 22:10:23 4: RQUEUE: 1
2016.04.20 22:10:23 5: SimpleWrite [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:23 5: ModbusTCPServer_Parse: received [30 00 00 00 00 04] 00 01 01 01
2016.04.20 22:10:23 5: wago dispatch ModbusCoil:0:12288:1:1:1
2016.04.20 22:10:23 5: AddRQueue [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:23 5: SimpleWrite [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:23 5: AddRQueue [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:23 5: adding to RQUEUE - 1
2016.04.20 22:10:23 5: AddRQueue [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:23 5: adding to RQUEUE - 2
2016.04.20 22:10:23 5: ModbusTCPServer_Parse: received [30 C9 00 00 00 05] 00 03 02 00 E2
2016.04.20 22:10:23 5: wago dispatch ModbusRegister:0:12489:3:1:226
2016.04.20 22:10:23 5: ModbusRegister_Parse: 3 0 12489
2016.04.20 22:10:23 4: RQUEUE: 2
2016.04.20 22:10:23 5: SimpleWrite [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:23 5: ModbusTCPServer_Parse: received [30 C8 00 00 00 05] 00 03 02 E2 C8
2016.04.20 22:10:23 5: wago dispatch ModbusRegister:0:12488:3:1:58056
2016.04.20 22:10:23 5: ModbusRegister_Parse: 3 0 12488
2016.04.20 22:10:23 4: RQUEUE: 1
2016.04.20 22:10:23 5: SimpleWrite [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:23 5: ModbusTCPServer_Parse: received [30 00 00 00 00 04] 00 01 01 01
2016.04.20 22:10:23 5: wago dispatch ModbusCoil:0:12288:1:1:1
2016.04.20 22:10:23 5: AddRQueue [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:23 5: SimpleWrite [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:23 5: AddRQueue [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:23 5: adding to RQUEUE - 1
2016.04.20 22:10:23 5: AddRQueue [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:23 5: adding to RQUEUE - 2
2016.04.20 22:10:23 5: ModbusTCPServer_Parse: received [30 C9 00 00 00 05] 00 03 02 00 E2
2016.04.20 22:10:23 5: wago dispatch ModbusRegister:0:12489:3:1:226
2016.04.20 22:10:23 5: ModbusRegister_Parse: 3 0 12489
2016.04.20 22:10:23 4: RQUEUE: 2
2016.04.20 22:10:23 5: SimpleWrite [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:23 5: ModbusTCPServer_Parse: received [30 C8 00 00 00 05] 00 03 02 E2 C8
2016.04.20 22:10:23 5: wago dispatch ModbusRegister:0:12488:3:1:58056
2016.04.20 22:10:23 5: ModbusRegister_Parse: 3 0 12488
2016.04.20 22:10:23 4: RQUEUE: 1
2016.04.20 22:10:23 5: SimpleWrite [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:23 5: ModbusTCPServer_Parse: received [30 00 00 00 00 04] 00 01 01 01
2016.04.20 22:10:23 5: wago dispatch ModbusCoil:0:12288:1:1:1
2016.04.20 22:10:23 5: AddRQueue [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:23 5: SimpleWrite [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:23 5: AddRQueue [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:23 5: adding to RQUEUE - 1
2016.04.20 22:10:23 5: AddRQueue [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:23 5: adding to RQUEUE - 2
2016.04.20 22:10:23 5: ModbusTCPServer_Parse: received [30 C9 00 00 00 05] 00 03 02 00 E2
2016.04.20 22:10:23 5: wago dispatch ModbusRegister:0:12489:3:1:226
2016.04.20 22:10:23 5: ModbusRegister_Parse: 3 0 12489
2016.04.20 22:10:23 4: RQUEUE: 2
2016.04.20 22:10:23 5: SimpleWrite [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:23 5: ModbusTCPServer_Parse: received [30 C8 00 00 00 05] 00 03 02 E2 C8
2016.04.20 22:10:23 5: wago dispatch ModbusRegister:0:12488:3:1:58056
2016.04.20 22:10:23 5: ModbusRegister_Parse: 3 0 12488
2016.04.20 22:10:23 4: RQUEUE: 1
2016.04.20 22:10:23 5: SimpleWrite [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:23 5: ModbusTCPServer_Parse: received [30 00 00 00 00 04] 00 01 01 01
2016.04.20 22:10:23 5: wago dispatch ModbusCoil:0:12288:1:1:1
2016.04.20 22:10:23 5: AddRQueue [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:23 5: SimpleWrite [30 C9 00 00 00 06] 00 03 30 C9 00 01
2016.04.20 22:10:23 5: AddRQueue [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:23 5: adding to RQUEUE - 1
2016.04.20 22:10:23 5: AddRQueue [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:23 5: adding to RQUEUE - 2
2016.04.20 22:10:23 5: ModbusTCPServer_Parse: received [30 C9 00 00 00 05] 00 03 02 00 E2
2016.04.20 22:10:23 5: wago dispatch ModbusRegister:0:12489:3:1:226
2016.04.20 22:10:23 5: ModbusRegister_Parse: 3 0 12489
2016.04.20 22:10:23 4: RQUEUE: 2
2016.04.20 22:10:23 5: SimpleWrite [30 C8 00 00 00 06] 00 03 30 C8 00 01
2016.04.20 22:10:23 5: ModbusTCPServer_Parse: received [30 C8 00 00 00 05] 00 03 02 E2 C8
2016.04.20 22:10:23 5: wago dispatch ModbusRegister:0:12488:3:1:58056
2016.04.20 22:10:23 5: ModbusRegister_Parse: 3 0 12488
2016.04.20 22:10:23 4: RQUEUE: 1
2016.04.20 22:10:23 5: SimpleWrite [30 00 00 00 00 06] 00 01 30 00 00 08
2016.04.20 22:10:23 5: ModbusTCPServer_Parse: received [30 00 00 00 00 04] 00 01 01 01
2016.04.20 22:10:23 5: wago dispatch ModbusCoil:0:12288:1:1:1
2016.04.20 22:10:23 0: Server shutdown


dafür das es nur 10 Sekunden sind... ganz schöne Datenflut bei 0.1
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: oniT am 21 April 2016, 21:07:48
Hallo ChrisD,

ja funktioniert. Sehr schön Danke. Kannst Du von meiner Seite mit als Update zur Verfügung stellen.

Eine Frage habe ich noch dazu, als Attributauswahl kann man jetzt wieder zusätzlich updateIntervall mit zwei "l" wählen. Das war vorher anders. Da gab es nur das korrekt geschriebene :)  updateInterval. Warum ist das so? Im Quelltext steht unter Attributelist

"updateInterval updateIntervall alignUpdateInterval ".

Das stand aber vorher auch schon so, also außer natürlich alignUpdateInterval, ist ja klar.

Danke

Gruß,
Tino
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 23 April 2016, 22:32:23
Hallo,

@Toni: Im Quelltext steht aus Kompatibilitätsgründen noch immer updateIntervall drin. Nach dem Start von FHEM sollte das Attribut automatisch gelöscht werden was aber anscheinend nicht mehr funktioniert. Ich muss mir das genauer ansehen.

@der-Lolo: Ich habe versucht anhand des Logs herauszufinden wo der Fehler liegen könnte, was mir aber nicht gelungen ist.

Hier
2016.04.20 22:10:18 5: AddWQueue [1C B1 00 00 00 06] 00 06 30 C9 00 E2
wird der Wert 226 (E2h) auf MW201 (12489, 30C9h) geschrieben, die SPS meldet auch dass dies erfolgreich war:
2016.04.20 22:10:18 5: ModbusTCPServer_Parse: received [1C B1 00 00 00 06] 00 06 30 C9 00 E2

Beim nächsten Lesen wird MW201 korrekt gelesen:
2016.04.20 22:10:18 5: ModbusTCPServer_Parse: received [30 C9 00 00 00 05] 00 03 02 00 E2

Beim Lesen von MW200 wird aber das Low-Byte von MW201 als Hgh-Byte zurückgeliefert:
2016.04.20 22:10:18 5: ModbusTCPServer_Parse: received [30 C8 00 00 00 05] 00 03 02 E2 C8
wodurch der Wert von Warmlicht ändert.

Das Modul übernimmt die Daten so wie sie von der SPS kommen.

Kannst du überprüfen wo und welche Schreibzugriffe auf MD100, MW200, MW201, MB400, MB401, MB402 oder MB403 im SPS-Programm stattfinden ?

Grüße,

ChrisD


Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 23 April 2016, 22:48:29
Ok, das werde ich morgen versuchen - ich hab zwar noch keine ahnung wie, aber das klappt bestimmt.
Ich hab auch grad das gefühl es könnte ein 8 - 16 - 24 Bit problem sein, da kann man auf DMX seite was konfigurieren, vielleicht ist da ein fehler zwischen DMX Hardware und SPS.
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: oniT am 23 April 2016, 23:06:54

Zitat
Nach dem Start von FHEM sollte das Attribut automatisch gelöscht werden was aber anscheinend nicht mehr funktioniert. Ich muss mir das genauer ansehen.

Hallo ChrisD,

ah na ja, vielleicht ist es auch das. Ich habe ein Reload und keinen Neustart durchgeführt.

Gruß
Tino


Gesendet von meinem iPhone mit Tapatalk
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 24 April 2016, 09:36:04
Hm, ich glaube wir kommen der Sache näher...
Ich habe nun in FHEM alles so gelassen wie es ist (MW200 ; MW201)
In der Wago Variablen Deklaration habe ich Kaltlicht also MW201 auf MW202 gesetzt.
So funktioniert alles wie gewünscht.
Aufgefallen war mir "online" das im Array abDMX_Values beim verändern von MW201 die Kanäle abDMX_Values[2] und [3] verändert werden.
Nun mit MW202 innerhalb der Wago und MW201 innerhalb FHEM verändert sich der Wert nur noch auf abDMX_Values[3].
abDMX_Values ist in der Wago Deklaration auf abDMX_Values (%MW200) gesetzt.
Ich verstehe zwar den zusammenhang nicht, vielleicht stimmt aber auch an dieser Stelle etwas mit den Wago Bausteinen für DMX nicht.

Die Werte die Du gerne sehen möchtest - kann ich die in einen Trace packen?
Ich habe keine Ahnung wie ich die Daten bekomme die DU gerne sehen möchtest...

btw: 1000 Danke für Deine Hilfe!
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: pc1246 am 24 April 2016, 13:26:13
Hallo der-Lolo
Das MW200 beinhaltet Teile des MW201. Das ist nun mal so! Ein Wort hat 16 Bit(2 Byte), zwischen 200 und 201 sind aber nur 8 Bit(1 Byte)! Das naechste Wort ist immer 2 Byte weiter, also MW200 dann MW202 usw.!
Gruss Christoph
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 24 April 2016, 14:25:29
Hallo pc1246,
danke fürs mitdenken! Ich habe gedacht das ich in der deklaration bestimme welche Datentypen in den bereichen abgelegt werden. MW200 und MW202 sind als BYTE deklariert, das denoch ein WORD daraus gemacht wird war mir nicht klar.
Ich denke ich sollte den bereich wechseln um nur Bytes zu händeln...
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 24 April 2016, 18:43:00
Hallo,

Wago verwendet ein etwas ungewöhnliches Speicherlayout so dass MW201 keinen Teil von MW200 belegt. MW200 belegt die Bytes MB400 und MB401 während MW201 die Bytes MB402 und MB403 belegt. Den gleichen Speicherbereich belegt auch noch MD100.

Der DMX-Baustein benötigt ein Array mit Bytes was nicht so gut zu den Daten die per Modbus übertragen werden passt.

ZitatAufgefallen war mir "online" das im Array abDMX_Values beim verändern von MW201 die Kanäle abDMX_Values[2] und [3] verändert werden.

Bei deiner Deklaration belegt abDMX_Values[0] und [1] MW200 und abDMX_Values[2] und [3] MW201. Wenn du z.B. RGBW-LEDs verwendest und nur die Helligkeit ändern möchtest sollte dies über abDMX_Values[3] und abDMX_Values[7] funktionieren, also den High-Bytes von MW201 und MW203. Bei RGBW werden 4 Bytes pro Teilnehmer benötigt.

Verwendest du nur FbDMX_652_Master oder auch andere Bausteine aus der Wago-DMX-Bibliothek ? Wird nur über FHEM auf DMX zugegriffen oder auch sonst noch aus dem SPS-Programm ? Welche Art von LEDs steuerst du über DMX ?

Grüße,

ChrisD

Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 24 April 2016, 19:18:10
Hallo ChrisD,
ich verwende den masterbaustein und einen FB_ChangeChanelValues - zur Zeit bin ich auch noch nicht glücklich was das ganze angeht, ich würde gerne lieber Dimm Rampen fahren. Und vorallem direkt in der SPS ohne FHEM Leuchten einschalten. Zur zeit macht das ein DOIF - ( set warmlicht 200 ) wenn out1 on ist.
Als Dimmer kommt ein ELDOLED 180D2 zum Einsatz, Leuchmittel sind LEDs von Voltus.
RGB kommt sicher auch später mal zum Einsatz, zur zeit geht es aber nur um normales 2700K Licht. Ich wünschte ich würde diese DMX Sachen etwas besser verstehen...

Die Merkerbereiche muss ich jedenfalls noch besser verstehen sodass ich sinnvoll deklarieren und zuweisen kann...

Hast Du vielleicht noch Lesestoff Empfehlungen speziell für Wago?
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 26 April 2016, 21:46:50
Hallo,

Wenn dein Dimmer bei CCWW 4 Kanäle belegt sollte deine Konfiguration richtig sein, wahrscheinlich ist FB_ChangeChanelValues aber nicht nötig. Dadurch dass du abDMX_Values auf %MW200 gelegt hast sollten die Werte die du über FHEM auf MW200 und MW201 schreibst direkt per DMX ausgegeben werden.

Wie hast du FB_ChangeChanelValues konfiguriert ?

ZitatZur zeit macht das ein DOIF - ( set warmlicht 200 ) wenn out1 on ist.

Was ist out1 ? Wenn es von der SPS kommt kannst du den Weg über FHEM sparen und die Werte direkt zuweisen, z.B. über ein SEL.

Für Dimmrampen kannst du z.B. den Baustein RAMP_INT aus der Bibliothek util.lib verwenden, damit lassen sich Rampen ziemlich flexibel konfigurieren. Du musst dir dann aber überlegen ob und wie du die Vorgabe (Sollwert) von dem aktuellen Istwert in FHEM trennst.

ZitatDie Merkerbereiche muss ich jedenfalls noch besser verstehen sodass ich sinnvoll deklarieren und zuweisen kann...

Feste Adressen sind nur in bestimmten Fällen nötig, z.B. bei Wago bei der Modbuskommunikation. Variablen die nur intern im SPS-Programm verwendet werden benötigen keine Adresse, der Compiler kümmert sich selbst darum.

ZitatHast Du vielleicht noch Lesestoff Empfehlungen speziell für Wago?

Nein, habe ich leider nicht. Es gibt zwar die Dokumentation von Wago und CoDeSys sowie diversen Application Notes, es ist aber nicht immer einfach darin das Richtige zu finden.

Grüße,

ChrisD



Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: golli am 25 November 2016, 10:30:40
Hallo,
versuche gerade auch meine Wago 750-881 mit 192.168.115.100 per Modbus an mein FHEM auf Raspberry mit 192.168.115.52 zu koppeln.
In der 99_modbus.pm habe ich ,,$m->host("192.168.115.100");" geändert.
Hier die Globalen Variablen meiner Wago:


Wie bekomme ich jetzt z.B. die Aussentemperatur in FHEM?
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 26 November 2016, 10:00:34
Hallo,

Mit der 99_modbus.pm ist es etwas schwieriger REAL-Zahlen zu lesen.

Einfacher geht es mit den Modulen 36_ModbusTCPServer und 37_ModbusRegister. Du kannst die aktuelle Version mit
update force https://raw.githubusercontent.com/ChrisD70/FHEM-Modules/master/autoupdate/mb/controls_modbustcp.txt

installieren. Nach einem Neustart von FHEM kannst du die Verbindung zur SPS mit
define wago ModbusTCPServer 192.168.115.100anlegen.

Im SPS-Programm musst du die Variablen die ausgetauscht werden sollen in den Merkerbereich legen, z.B.
Aussentemperatur AT %MD100 : REAL;

Mit
define Aussentemperatur ModbusRegister wago MF100
wird die Temperatur von FHEM gelesen.

Da bei jedem Lesezyklus der Wert aktualisiert wird kannst du noch zusätzlich
attr Aussentemperatur event-on-change-reading .*
verwenden. Dadurch wird nur bei Änderungen ein Ereignis (z.B. für Logging) in FHEM generiert.

Die Datei 99_modbus.pm brauchst du nicht mehr.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: golli am 26 November 2016, 11:15:11
Wenn ich mit Putty : update force https://raw.githubusercontent.com/ChrisD70/FHEM-Modules/master/autoupdate/mb/controls_modbustcp.txt
eingebe erhalte ich folgende Fehlermeldung:
-bash: update: command not found
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: suppenesser am 26 November 2016, 11:55:27
Nicht in putty, im fhem comandofenster eingeben

Gesendet von meinem HUAWEI GRA-L09 mit Tapatalk

Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: golli am 26 November 2016, 20:35:05
Super das funktioniert schon mal, danke euch.
Wenn ich jetzt noch die digitalen Ein- und Ausgänge einbinden möchte, z.B.

esszimmer_taster1(%IX2.2) digitaler Eingang

schalo_esszimmer_sued_up (%QX6.0) digitaler Ausgang
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 26 November 2016, 21:49:31
Hallo,

Für das direkte Lesen/Schreiben der Ein- und Ausgänge muss FHEM die Konfiguration der SPS kennen. Dazu musst du das Attribut serverType setzen:
attr wago serverType Wago

Mit
list wagokannst du kontrollieren ob es funktioniert hat, du solltest in der Ausgabe Informationen der Art
Zitatwago:
       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
finden.

Anschließend kannst du die Eingänge mit
define esszimmer_taster1 ModbusCoil wago IX2.2
attr esszimmer_taster1 event-on-change-reading .*

definieren.
Wenn der Tastimpuls am Eingang kürzer als der Abfragezyklus ist, kann es passieren dass FHEM den Taster nicht sieht, in dem Fall kannst du auf der SPS einen TP- oder TOF-Baustein verwenden um den Tastimpuls zu verlängern.

Für die Ausgänge:
define schalo_esszimmer_sued_up ModbusCoil wago QX6.0
attr schalo_esszimmer_sued_up event-on-change-reading .*

Du kannst aber nur auf den Ausgang schreiben wenn das SPS-Programm dies nicht tut.
Falls FHEM und die SPS gleichzeitig auf den Ausgang zugreifen sollen, muss FHEM einen Merker in der SPS schreiben und du musst diesen ins SPS-Programm einbinden.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: golli am 28 November 2016, 15:56:35
Super dank dir, ich kann jetzt auf der Oberfläche von FHEM sehen, wenn ich z.B. einen Licht Taster betätige.
Problem ist jedoch, dass ich Stromstoss Schalter in der Verteilung verbaut habe. So wie auf dem Bild habe ich das in Codesys gelöst.
buero_taster1 ist der Taster im Raum, buero_unten_licht_button ist für der Lichttaster für die Visualisierung, buero_unten_licht ist der digitale Ausgang(schaltet den Stromstoss Schalter).
Für FHEM passt der Status vom Licht jedoch nicht.
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 28 November 2016, 16:44:25
Hallo,

Du könntest den Zustand von 'buero_unten_licht_feedback' in FHEM verwenden, da dieser den (wahrscheinlichen) Zustand des Stromstossschalters enthält. Wenn buero_unten_licht_feedback auf MX100.0 und buero_unten_licht_button auf MX120.0 liegen sollte dies funktionieren:

define buero_unten_licht ModbusCoil wago MX100.0
attr buero_unten_licht event-on-change-reading .*
attr buero_unten_licht writeMode Impulse:MX120.0


Dadurch wird der Zustand von MX100.0 gelesen, Befehle werden aber als Impulse an MX120.0 gesendet.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: verkel am 28 November 2016, 17:27:04
Hallo zusammen. Habe im Moment das gleiche Projekt und möchte meine Wago 750-881 mit Fhem steuern. Ich benutze es erstmal hauptsächlich für meine Jalousiesteuerung. Habe es jetzt hiermit probiert:

define Kind2_d ModbusCoil wago MX1.14
attr Kind2_d IODev SPS
attr Kind2_d writeMode Impulse:MX1.14


Der Impulse ist aber zu kurz für meinen Baustein (benutze einen von Wago). Kann man die zeit verlängern auf ca. 1 sekunde oder muss man das dann über einen anderen Mode machen?

Danke schon mal. Das alles hier hat mir sehr geholfen vor allen das von ChrisD :)
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 28 November 2016, 18:09:56
Hallo,

Du kannst bei writeMode zusätzlich die Impulslänge in Sekunden angeben, z.B.
attr Kind2_d writeMode Impulse:MX1.14:1.0
für 1 Sekunde.

Default sind 0.5 Sekunden was eigentlich ausreichen sollte.

Der writeMode ist dazu gedacht Zustand (von SPS gelesen) und Befehl zu trennen. Wenn du nur Impulse senden möchtest musst du immer 'on' verwenden, 'off' bewirkt nichts.

Alternativ kannst du in dem Fall writeMode komplett löschen und stattdessen on-for-timer benutzen:
set Kind2_d on-for-timer 1

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: golli am 28 November 2016, 18:13:07
Jetzt passt es. Wie vergebe ich denn die Merker. Gibts da spezielle Bereiche?
Würde gerne alle digitale Ein- und Ausgänge mit in FHEM einbinden.
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 28 November 2016, 19:57:52
Hallo,

Du kannst bei der Deklaration von Variablen mit angeben ob sie an einer bestimmten Adresse liegen. Den möglichen Adressbereich findest du in CoDeSys in den Zielsystemeinstellungen bei Memory. Bei der 881 sollte 16#4000 stehen, was 16384 Bytes entspricht (MB0 - 16383, MW0 - 8191, MD0 - 4095). In diesem Bereich kannst du Daten ablegen auf die z.B. per ModbusTCP zugegriffen werden soll.

Welche Variable du wohin legst ist dir überlassen, du solltest aber darauf achten dass du keine Adresse doppelt belegst. So zeigen bei Wago z.B. MB400, MW200 und MD100 auf die gleiche Adresse.

Die Ein- und Ausgänge kannst du über Modbus direkt lesen, du musst sie nicht unbedingt auf Merker umkopieren.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: verkel am 29 November 2016, 17:27:35
Sorry für die vielleicht doofe Frage aber ich bin ziemlich neu in FHEM.

Hab es mit diesem Code hinbekommen aber der status ändert sich ja dabei nicht:
define Kind2_u ModbusCoil wago MX1.13
attr Kind2_u IODev SPS
attr Kind2_u writeMode Impulse:MX1.13:1.0


Aber wollte es dann auch mit diesem hier machen:
define Wohnzimmer_Links_Hoch ModbusCoil wago MX0.1
attr Wohnzimmer_Links_Hoch IODev SPS
set Wohnzimmer_Links_Hoch on-for-timer 1


Wenn ich jetzt auf die lampe klicke, wird es nicht für 1 sekunde geschaltet sondern normal für immer.
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 29 November 2016, 19:34:06
Hallo,

Kannst du weitere Details zu MX1.13, MX0.1 und der Funktionsweise des SPS-Programmes posten ? Es ist mir im Moment nicht klar was du genau machen möchtest.

ZitatHab es mit diesem Code hinbekommen aber der status ändert sich ja dabei nicht

Der Status kann sich nicht ändern weil du nur den Zustand des Befehls zurückliest.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: verkel am 29 November 2016, 22:48:45
Sorry für das schlechte erklären. Finde es klasse das hier so schnell auf Fragen geantwortet wird.

Habe mehrere Taster im Haus die über den Baustein (Bild als Anhang) die Jalousien steuern. Möchte jetzt zusätzlich über FHEM die Jalousien hoch und runter Tasten (muss über 0,5 sekunden sein) und dann den Ausgang sehen ob es fährt. Evtl nochmal später den Ausgang der Position visualisieren.
Baustein ist als Anhang und die Deklaration.
Danke schon mal im voraus.
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 30 November 2016, 17:32:11
Hallo,

Du könntest es hiermit versuchen:

define m_a_wohn_1_u ModbusCoil wago MX2.0
attr m_a_wohn_1_u event-on-change-reading .*
attr m_a_wohn_1_u eventMap on:auf
attr m_a_wohn_1_u webCmd auf
attr m_a_wohn_1_u writeMode Impulse:MX0.1:1.0

define m_a_wohn_1_d ModbusCoil wago MX2.1
attr m_a_wohn_1_d event-on-change-reading .*
attr m_a_wohn_1_d eventMap on:ab
attr m_a_wohn_1_d webCmd ab
attr m_a_wohn_1_d writeMode Impulse:MX0.2:1.0


Im Moment hast du in der Variablendeklaration 'm_a_wohn_1_u' und 'm_a_wohn_1_d' auf der gleichen Adresse (%MX2.0) liegen, für den Vorschlag habe ich m_a_wohn_1_d auf %MX2.1 verschoben.

Im Detail:

define m_a_wohn_1_u ModbusCoil wago MX2.0
define m_a_wohn_1_d ModbusCoil wago MX2.1

legt fest wo sich der Zustand (in diesem Fall die Ansteuerung) befindet. Damit solltest du bei Verwendung der Taster sehen wenn der Ausgang schaltet

attr m_a_wohn_1_u writeMode Impulse:MX0.1:1.0
attr m_a_wohn_1_d writeMode Impulse:MX0.2:1.0

legt fest dass die Befehle als Impulse auf eine andere Adresse umgeleitet werden sollen

attr m_a_wohn_1_u webCmd auf
attr m_a_wohn_1_d webCmd ab

sorgt dafür dass im Web-Interface statt 'on' und 'off' die Texte 'auf' und 'ab' stehen.

attr m_a_wohn_1_u eventMap on:auf
attr m_a_wohn_1_d eventMap on:ab

wandelt die Befehle 'auf' und 'ab' aus dem Web-Interface intern in 'on' um damit der Impuls an die SPS geschickt wird.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: verkel am 30 November 2016, 18:09:42
Ich bin begeistert. Es klappt. Genauso wollte ich es haben. Besten dank :)
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: golli am 05 Dezember 2016, 18:24:16
Nach diesem Beispiel http://voizchat.de/gaszaehler-verbrauch-erfassen-mit-fhem-und-raspberry-gpio/
würde ich nun gerne vom digitalen Eingang der Wago über Modbus auch den Gasverbrauch loggen.

Habe das mal versucht anzupassen, aber irgendwie will es nicht.

define Gaszaehler ModbusCoil wago IX7.15

define Gasverbrauch HourCounter Gaszaehler:on Gaszaehler:off
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 05 Dezember 2016, 21:55:15
Hallo,

Kannst du die einzelnen Teile der Übertragungskette überprüfen:

- Impulse an der Klemme sichtbar ?
- Impulse im SPS-Programm sichtbar ? Wie groß ist die Impulsdauer ? Falls der Impuls zu kurz ist, kann FHEM ihn nicht sehen. In dem Fall musst du den Impuls in der SPS verlängern.
- Impulse im 'Gaszaehler' sichtbar ? Was passiert wenn du eine Brücke auf den Eingang machst, ändert der Wert in FHEM ?

Eine Alternative wäre die Impulse direkt in der SPS zu zählen (z.B. mit CTU) und nur den Zählwert an FHEM zu übertragen. Damit würdest du den Timing-Problemen aus dem Weg gehen.

Grüße,

ChrisD

Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: golli am 11 Dezember 2016, 13:49:28
So konnte den Fehler eingrenzen. Irgendwas stimmt mit meinem Bus nicht. Habe die SPS neu gestartet und es geht für ein paar Tage.
Dann wird wieder kein Gasverbrauch aufgezeichnet. Der digitale Eingang der SPS registriert den Impuls jedoch.
Über Fhem kann ich Lampen über den Bus jedoch noch schalten.
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: pc1246 am 11 Dezember 2016, 15:15:02
Moin golli
Hast Du den Rat von ChrisD befolgt? Wenn Dein Impuls nicht lang genug ist, dann laufen die SPS und fhem irgendwann auseinander. Das heisst es geht mal gut und mal nicht, Du solltest das entweder auf der SPS machen, und das Ergebnis an fhem senden, oder eben den Impuls verlaengern!
Gruss Christoph
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: golli am 15 Dezember 2016, 21:02:55
So mit dem Bus scheint eine einmalige Sache zu sein. Fhem zählt nun weiter ohne Abbrüche.
Aber wie ihr schon geschrieben habt, verschluckt er hier und da einen Impuls.
Würde das gerne mit einem CTU in der SPS lösen. Dieser zählt jedoch nur bis 32767.
Man könnte vielleicht drei hintereinander schalten, aber auf Kosten der Auflösung.
Jemand eine bessere Idee?
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 15 Dezember 2016, 22:58:56
Hallo,

Es gibt mehrere Möglichkeiten die Begrenzung des CTU zum umgehen:
- selbst zählen, z.B.:
RT_Gaszaehler(CLK:=iGaszaehler)
IF RT_Gaszaehler.Q THEN Gasverbrauch:=Gasverbrauch+0.01; END_IF;

wobei Gasverbrauch als REAL deklariert sein muss, z.B. auf MD1000.
Denn Zähler kannst du dann in FHEM mit
define Gasverbrauch ModbusRegister wago MF1000
anlegen

- 2 CTU hintereinander schalten, der 1. zählt die Nachkommastellen bis 100, der 2. zählt die Ausgangsimpulse des ersten. An FHEM kannst du dann den Wert des 2. übertragen

- 32-Bit Zähler aus einer Bibliothek verwenden, z.B. OSCAT COUNT_DR

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: pc1246 am 16 Dezember 2016, 06:54:43
Moin
Man kann auch einfach die positive Flanke des Eingangs auswerten und dann ein Merker-/Datendoppelwort um 1 inkrementieren!
Gruss Christoph
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 25 Dezember 2016, 15:12:27
Mein problem hat derzeit nicht mit dem Modul zu tun, das arbeitet super sauber in der Testumgebung.

Ich habe zwei Inputs - welche ich nach kurz und lang unterscheide.
Kurzer Schalterdruck bei test1 bedeutet Licht auf bestimmten Wert an.
Langer Schalterdruck bei test1 bedeutet "hochdimmen"
Kurzer Schalterdruck bei test2 bedeutet Licht aus.
Langer Schalterdruck bei test2 bedeutet "runterdimmen"

Das Licht auf bestimmten Wert ist derzeit so geregelt:
Fhem registriert das Schalten und setzt per DOIF den Wert 100 auf %MW200
Internals:
   DEF        ([Wago] eq "on") (set Warmlicht 100)
DOELSE (set Warmlicht 0)


Internals:
   CHANGED
   DEF        wago MW200
   IODev      wago
   LASTInputDev wago
   MSGCNT     118847
   ModbusRegister_lastRcv 2016-12-25 15:03:42
   NAME       Warmlicht
   NR         34
   NTFY_ORDER 50-Warmlicht
   STATE      100
   TYPE       ModbusRegister
   lastUpdate Sun Dec 25 15:03:42 2016
   nextUpdate Sun Dec 25 15:03:42 2016
   wago_MSGCNT 118847
   wago_TIME  2016-12-25 15:03:42
   Readings:
     2016-12-25 15:03:42   Helligkeit      100
     2016-12-25 15:03:42   RAW             0064
     2016-12-25 15:03:42   state           100
   Helper:
     addr       3 0 12488
     address    12488
     disableRegisterMapping 1
     lastUpdate 0
     nextUpdate 1482674622.80732
     nread      1
     readCmd    0�
     register   12488
     registerType 3
     unitId     0
     updateIntervall 0.1
     wago       1
     wagoDataType W
     Cnv:
       a          1
       b          0
       max        65535
       min        0
       step       100
Attributes:
   IODev      wago
   event-on-change-reading .*
   room       Wago
   setList    Helligkeit:slider,0,1,255
   stateAlias Helligkeit
   webCmd     Helligkeit


Was mir natürlich lieber wäre, ist das FHEM die Änderungen zwar mitbekommt - aber der eigentliche Vorgang auch ohne FHEM funktioniert.
Ich sehe mich vor dem Problem das ich als folge eines BOOL "shortOn" ein WORD "100" schreiben muss...
Hat jemand eine Idee wie ich das in Codesys lösen kann und später aber per FHEM auch noch den Wert beeinflussen kann?

Am Screenshot seht Ihr das ich bereits versuche das "long" auszuwerten.. Ich brauche hier ja auch später wieder ein WORD.
Ich müsste also eigentlich einen Baustein haben der ein WORD hochzählt solange wie ein BOOL Signal anliegt. In den Grenzen 0-255.

Diese Funktion ist für mich grundlegend und würde später nicht nur von Licht, sondern auch von Rolladen Schaltstellen benötigt.


Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 26 Dezember 2016, 22:24:58
Hallo,

ZitatWas mir natürlich lieber wäre, ist das FHEM die Änderungen zwar mitbekommt - aber der eigentliche Vorgang auch ohne FHEM funktioniert.
Ich sehe mich vor dem Problem das ich als folge eines BOOL "shortOn" ein WORD "100" schreiben muss...

Es gibt viele Möglichkeiten dies zu lösen, eine davon ist SEL zu verwenden.

ZitatAm Screenshot seht Ihr das ich bereits versuche das "long" auszuwerten.. Ich brauche hier ja auch später wieder ein WORD.
Ich müsste also eigentlich einen Baustein haben der ein WORD hochzählt solange wie ein BOOL Signal anliegt. In den Grenzen 0-255.

Bei Fb_KurzLang legst du eine Impulslänge von 1.5 s bei Erkennung eines langen Tastendrucks fest. Selbst wenn der Taster weiterhin gedrückt bleibt geht der Ausgang xLang nach den 1.5 s wieder auf 0. Somit kannst du darüber die Dauer des Druckes nicht feststellen.

Anbei ein Beispiel wie du beide Funktionen (SEL und Zählen) realisieren könntest. Das Zählengeschwindigkeit ist von der Zykluszeit abhängig, bei 10 ms dauert es 2.5 s von 0 bis 255. Wenn dies zu schnell ist könntest du es z.B. durch ein TON und ein AND vor den BOOL_TO_INT verlangsamen.

Über FHEM kannst du weiterhin eingreifen indem du den Wert von Warmlicht auf den gewünschten Wert setzt. Wichtig ist noch dass Warmlicht als INT und nicht aus UINT in der SPS deklariert ist.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 27 Dezember 2016, 17:08:08
Hallo - und vielen Dank ChrisD!
ich habe gerade versucht das ganze umzusetzen, FHEM ist jetzt erstmal aussen vor - an und aus funktionieren wie erwartet nach Test1 bzw Test2 short.
Wenn ich jedoch die Dimmfunktion (Netzwerk06) hinzunehme klappt es nicht mehr, ich las also nochmal Deinen Post
Da fiel mir dann auf
ZitatWichtig ist noch dass Warmlicht als INT und nicht aus UINT in der SPS deklariert ist.

Warmlicht ist aber BYTE - und ich glaube ich kann da nicht ändern, wegen DMX...
Hast Du vielleicht noch eine passende Idee wenn es um BYTE geht?

Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 27 Dezember 2016, 21:15:35
Hallo,

Es funktioniert wahrscheinlich nicht weil beim SUB die beiden Eingänge vertauscht sind, %MW200 muss nach oben und der Ausgang von BOOL_TO_INT nach unten.

Der aktuelle Code beschreibt übrigens 2 Bytes im Array abDMX_Values, ist das so gewollt ?

Anbei eine Version die nur 1 Byte beschreibt, die beiden AND am Anfang habe ich weggelassen da sie nicht nötig sind.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 27 Dezember 2016, 21:41:46
;-) Boah, das ist peinlich...
Logisch das man beim abziehen die Reihenfolge beachten muss...
Es funktioniert jetzt, mein erster Haptik Test sagt fühlt sich gut an - beim hochdimmen ist es mir zweimal passiert das bei voller Leistung ein shortOn am Ende das ganze wieder auf 100 gesetzt hat... Werde jetzt noch ein bisschen tüfteln wie ich FHEM jetzt wieder einbinde und den WAF Test machen lassen...

1000 Dank - ich bin aber auch eingerostet... 

Das mit den zwei Bytes ist nicht gewollt, ich möchte auch unbedingt versuchen beim DMX mit den Kanälen sparsam zu sein, ich las mal das man zwar beliebig viele Kanäle belegen kann - 512 ist glaub die Grenze, aber 21 scheint eine magische Zahl zu sein...
Wenn ich es richtig verstanden habe passen 21 BYTE in ein Telegram, wenn es mehr Telegrame werden ändert sich die Zykluszeit auf dem Bus.
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 27 Dezember 2016, 22:32:09
Ok, jetzt mit dem Slider in FHEM wird deutlicher was noch klemmt...
Wenn ich aufdimme - und einen STOP einlege - anschliessend bis 255 weiter hochdimme und den Taster loslasse wird die 100 wieder gesetzt.

Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 28 Dezember 2016, 21:48:33
Hallo,

Das liegt am Baustein Fb_KurzLang, wenn der Impuls xLang noch aktiv ist und erneut gedrückt wird, wird beim Loslassen immer ein xKurz-Impuls ausgegeben. Du kannst entweder den Baustein anpassen oder die Zeiten uiTL_10tel_s und uiTK_10tel_s auf 1 setzen.

Wenn du shortOn, ... in FHEM sehen möchtest musst du sie dann aber selbst verlängern.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 29 Dezember 2016, 16:39:42
Super, genauso soll es werden!
Ausschalten von FHEM aus fehlt mir jetzt noch, ich habe writeMode unter den Attributen entdeckt - in der commandRef aber nichts dazu gefunden. Ich durchforste jetzt mal diesen thread...
Wäre wenn ich writeMode nicht als Impuls nutze true oder false auf dem einem Bit angesagt?
Das Einschalten des Icons in FHEM habe ich mit dem von Dir vorgeschlagenem GT Baustein gelöst.
Es funktioniert ausgezeichnet aber wie gesagt ausschalten fehlt noch - über Slider gehts natürlich.

Ein leidiges Thema habe ich noch - in FHEM habe ich ja zwei Slider, Warmlicht und Kaltlicht
%MW200 und %MW201 in Wago kommen diese aber als abDMX_Values[1] und abDMX_Values[3] an.
[1-2] wäre mir natürlich lieber...


Schön so - würdest Du an meiner stelle nun einen FB daraus machen? Oder Spar ich mir den aufwand..?

Und - nochmal Tausend Dank!
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 31 Dezember 2016, 13:50:46
Hallo,

ZitatWäre wenn ich writeMode nicht als Impuls nutze true oder false auf dem einem Bit angesagt?

Du kannst writeMode auf der Rückmeldung für das Icon verwenden, z.B.
attr out1 writeMode Impulse:MX21.0

In Verbindung mit dem angehängten Code für die SPS solltest du ausschalten können.

ZitatEin leidiges Thema habe ich noch - in FHEM habe ich ja zwei Slider, Warmlicht und Kaltlicht
%MW200 und %MW201 in Wago kommen diese aber als abDMX_Values[1] und abDMX_Values[3] an.
[1-2] wäre mir natürlich lieber...

Ich würde die Adresse bei abDMX_Values entfernen und ganz am Ende die Daten von MW20x umkopieren (siehe Bild 2).

Zitatwürdest Du an meiner stelle nun einen FB daraus machen?

Wenn du den Code öfter (>2) benötigst, würde ich einen FB daraus machen.

Grüße,

ChrisD

Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: bitvilla am 05 Januar 2017, 16:42:15
Hallo Forum,

zuerst einmal wünsche ich allen ein gesundes und erfolgreiches neues Jahr 2017!

Ich setze dieses FHEM/ModBus-Modul bereits seit Anfang 2013 erfolgreich ein. Während der Bauphase wurden mit der SPS aber nur rudimentäre Funktionen (Eltako-Schaltung, usw.) realisiert und mit FHEM visualisiert (aktuell ca. 70 Einträge). Nun ist aber Zeit für mehr.

Die erste Anbindung an FHEM wurde über die WAGO ModBus PFC-Variablen realisiert:
In der SPS entsprechende Feldbus-Variablen konfiguriert (z.B.: fhemDO2_A -> %QX256.0) und aus FHEM über die ModBus-Adresse 4152 angesprochen. Befehle aus FHEM wurden dann automatisch über %IX256.0 -> fhemDI2_A an die SPS weitergegeben.

Nach einem Hinweis im Forum von ChrisD bin ich nun dabei die Konfiguration auf eine direkte Adressierung umzustellen:
Die Wago Adressen %IX0.0 oder %QX0.0 werden nun direkt gelesen und Befehle werden über den Merkerbereich %MX0.0 - %MX12288.15 zurückgegeben.

Die Funktionalität über WriteMode die Empfänger-Adresse anzupassen finde ich SUPER! Hatte bereits bei meiner Garagentorsteuerung den ersten Anwendungsfall.

Dabei ist mir jedoch aufgefallen, dass sich mit WriteMode nur Merker ansprechen lassen. Die o.g. WAGO ModBus PFC-Variablen %IX256.0 - %IX511.15 und %QX256.0 - %QX511.15 bringen eine entsprechende Fehlermeldung. In der Programmierung der Wago-SPS waren mir die PFC-Variablen bisher aber sehr sympathisch, denn Ihnen kann ohne großen Aufwand ein eindeutiger Name zugewiesen werden (z.B.: fhemDO2_A oder fhemDI4_B) und die Variablen-Konfiguration erfolgt durchgängig in der Steuerungskonfiguration der CODESYS.

Spricht etwas dagegen diese Funktionalität zukünftig einzubauen?


Beim letzten Update der Module ist mir aufgefallen, dass es nun den Datentyp DATE und DT gibt. Auch dafür hätte ich schon eine Anwendung, würde gerne den berechneten Sonnenaufgang bzw. Sonnenuntergang der OSCAT-Module  an FHEM übertragen. Gibt es schon jemanden der so etwas umgesetzt hat?


Des weiteren sind in letzter Zeit die möglichen Attribute in FHEM gewachsen (writeMode, writeCondition, suppressReading,...), aber ich finde keine entsprechende Dokumentation!


Gibt es nur dieses Forum oder gibt es bereits eine entsprechende Dokumentation zu dem Modul?
Wenn NEIN wäre dies sehr schade! Vielleicht kann man helfen oder Unterstützen  :)


So das waren meine ersten Gedanken und Fragen
mfg

bitvilla
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 06 Januar 2017, 22:38:21
Hallo,

ZitatDabei ist mir jedoch aufgefallen, dass sich mit WriteMode nur Merker ansprechen lassen
Es sollte auch mit IX und QX funktionieren, z.B.
attr mbc_1 writeMode Impulse:QX256.0
Wie lautet die Fehlermeldung genau ?

ZitatBeim letzten Update der Module ist mir aufgefallen, dass es nun den Datentyp DATE und DT gibt.
Ich habe diese Datentypen dazu verwendet um Sollwerte an die SPS zu übergeben, z.B.:
define MB_T_RolloAuf ModbusRegister wago MD121
attr MB_T_RolloAuf event-on-change-reading .*
attr MB_T_RolloAuf plcDataType TIME
attr MB_T_RolloAuf webCmd state
attr MB_T_RolloAuf setList state:time

In FHEM bekommt man so einen Slider mit dem die Zeit direkt eingestellt werden kann.

Manuelles setzen geht z.B. mit
set MB_T_RolloAuf 06:50
oder
set MB_T_RolloAuf 06:50:30

Du kannst aber auch Zeiten in die andere Richtung übertragen. Die Weiterverarbeitung in FHEM kannst du dann z.B. mit einem notify machen.

ZitatDes weiteren sind in letzter Zeit die möglichen Attribute in FHEM gewachsen (writeMode, writeCondition, suppressReading,...), aber ich finde keine entsprechende Dokumentation!
writeCondition ist bereits dokumentiert, writeMode habe ich in der neuen Version hinzugefügt, suppressReading stammt nicht aus den Modbus-Modulen. Es gibt aber eine Reihe an Attributen die ich noch dokumentieren muss.

ZitatGibt es nur dieses Forum oder gibt es bereits eine entsprechende Dokumentation zu dem Modul?
Das Modul ist nicht komplett dokumentiert, Details zu den meisten Funktionen sollten aber in diesem Thread zu finden sein.

Wenn du die Module mit
update force https://raw.githubusercontent.com/ChrisD70/FHEM-Modules/master/autoupdate/mb/controls_modbustcp.txtinstallierst, wird die Dokumentation der Module übrigens automatisch in die Commandref von FHEM übernommen.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: bitvilla am 13 Januar 2017, 14:02:16
Hallo ,

Zitat von: ChrisD am 06 Januar 2017, 22:38:21
Hallo,
Es sollte auch mit IX und QX funktionieren, z.B.
attr mbc_1 writeMode Impulse:QX256.0
Wie lautet die Fehlermeldung genau ?

Meine Tests ergaben folgendes (Werte angepasst über FHEM -> Edit files):
attr mbc_1 writeMode Impulse:IX256.0
wird mit der Fehlermeldung "writing to input IX256.0 is not allowed" abgelehnt.
Jedoch funktioniert
attr mbc_1 writeMode Impulse:QX256.0
weil automatisch IX256.0 für die Antwort verwendet wird.

Habe einfach mal versucht die Modbus-Kommunikation zwischen Wago und FHEM grafisch darzustellen(siehe .PNG).
Hoffe es ist nicht alles falsch  ;)

Zitat von: ChrisD am 06 Januar 2017, 22:38:21
Ich habe diese Datentypen dazu verwendet um Sollwerte an die SPS zu übergeben, z.B.:
define MB_T_RolloAuf ModbusRegister wago MD121
attr MB_T_RolloAuf event-on-change-reading .*
attr MB_T_RolloAuf plcDataType TIME
attr MB_T_RolloAuf webCmd state
attr MB_T_RolloAuf setList state:time

In FHEM bekommt man so einen Slider mit dem die Zeit direkt eingestellt werden kann.

Manuelles setzen geht z.B. mit
set MB_T_RolloAuf 06:50
oder
set MB_T_RolloAuf 06:50:30

Du kannst aber auch Zeiten in die andere Richtung übertragen. Die Weiterverarbeitung in FHEM kannst du dann z.B. mit einem notify machen.

Danke für die Code-Schnipsel, werde mich bei Gelegenheit mal auf das Thema stürzen und Rückinfo geben.


Zitat von: ChrisD am 06 Januar 2017, 22:38:21
writeCondition ist bereits dokumentiert, writeMode habe ich in der neuen Version hinzugefügt, suppressReading stammt nicht aus den Modbus-Modulen. Es gibt aber eine Reihe an Attributen die ich noch dokumentieren muss.
Das Modul ist nicht komplett dokumentiert, Details zu den meisten Funktionen sollten aber in diesem Thread zu finden sein.

Wenn du die Module mit
update force https://raw.githubusercontent.com/ChrisD70/FHEM-Modules/master/autoupdate/mb/controls_modbustcp.txtinstallierst, wird die Dokumentation der Module übrigens automatisch in die Commandref von FHEM übernommen.

Grüße,

ChrisD

Super Tipp, habe bisher immer auf der Internetseite von FHEM die commandref.html gelesen.

Grüße,

bitvilla
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 14 Januar 2017, 17:06:05
Hallo,

Ich habe die Lese- und Schreibzugriffe auf den PFC-Bereich korrigiert. Auf IX256-511 kann jetzt gelesen und geschrieben werden, auf QX256-511 nur gelesen. Nach einem Update und Neustart solltest du mit

attr mbc_1 writeMode Impulse:IX256.0

auf die richtige Adresse schreiben können.

In der neuen Version ist ebenfalls der writeMode 'SetReset' integriert, damit können 2 unterschiedliche Adressen für ein- und ausschalten angegeben werden, z.B.:

attr mbc_1 writeMode SetReset:IX256.0:IX256.1

Ein 'on'-Befehl führt zu einem Impuls auf IX256.0, ein 'off' zu einem Impuls auf IX256.1.

ZitatSuper Tipp, habe bisher immer auf der Internetseite von FHEM die commandref.html gelesen.
Auf der Internetseite ist die Dokumentation nicht enthalten da die Module nicht zur offiziellen Distribution gehören. In der lokalen commandref ist sie aber enthalten und kann z.B. mit
help ModbusCoil
auch direkt angezeigt werden.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: yogi74 am 14 Januar 2017, 22:39:03
Hallo zusammen,

möchte ebenfalls meine Wago mittels Modbus mit Fhem koppeln und hier bidirektional Daten austauschen. 
Von Fhem zur Wago hauptsächlich Sensordaten wie vom PV WR, Multisensoren und Stromsensoren, etc., also primär REAL Werte.
Von Wago zu Fhem eigentlich nur Schaltsignale für Steckdosen etc., also binär.
Folgendes habe ich mit Hilfe dieses Forums schon hinbekommen.

Werte von meinem PV WR an die Wago zu übertragen, z.b. die aktuelle Leistung.
Hierzu ein Modbusregister mittels .

define Leistung ModbusRegister wago MF102

angelegt. Auf der Wago entsprechend deklariert.

PV_Leistung AT %MD102 :REAL;

Dann mittles folgender Anweisung die Daten aus dem PV WR (Kostal) Modul ausgelesen und auf das Modbusregister geschrieben, alle 10s.

Define read.Power at +*00:00:10 { fhem "set Leistung " . ReadingsVal('Kostal','AC.Power',99) }

Funktioniert einwandfrei, auch bei weiteren Werten des WR.
Ebenso klappt es auch mit der Weitergabe der binären Schaltsignale an eine Schaltsteckdose (Aeotec Smart Switch (2nd Edition)) von der Wago über ein Modbuscoil und notify..

Hier kommt jetzt mein Problem und Frage.
Noch oben beschriebener Vorgehensweise habe ich nun versucht auch Daten des Aoetec Multisensor 6 zur Wago zu übertragen, z.b. die Temperatur

define Temperatur ModbusRegister wago MF103

In der Wago

multi_temperatur AT %MD103 :REAL;

Dann auslesen:

Define read.Temperatur at +*00:00:10 { fhem "set Temperatur " .ReadingsVal('ZWave_SENSOR_MULTILEVEL_5','temperature',99) }


So, nun passiert leider nichts mehr, das Ggleiche auch bei den anderen Werten des Sensors wie UV und Feuchte etc.
Wenn ich nun anstatt auf das Modbusregister auf einem Dummy schreibe.
Define Temperatur dummy
Dann wird der Wert eingetragen, d.h. die Funktion funktioniert, allerdings nur auf dem Dummy.
Ebenso bekomme ich folgende Fehler im Logfile eingetragen.


2017.01.14 22:25:28 3: set Temperatur 21.3 C : Unknown argument 21.3, choose one of off on  off-for-timer on-till toggle blink on-for-timer intervals off-till off-till-overnight on-till-overnight
2017.01.14 22:25:28 3: read.temperature: Unknown argument 21.3, choose one of off on  off-for-timer on-till toggle blink on-for-timer intervals off-till off-till-overnight on-till-overnight


Hab schon alles mögliche probiert, geht einfach nicht.

Wäre wirklich sehr glücklich wenn mir hier jemand nen entscheidenden Tipp geben würde. Ich vermute es hat irgendwas mit den Datentypen zu tun. Bin leider kein Fhem oder Perl Experte, daher komme ich hier nicht weiter.


Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 14 Januar 2017, 23:20:21
Hallo,

Der Temperaturwert von ZWave_SENSOR_MULTILEVEL_5 enthält nicht nur die Temperatur sondern auch die Einheit. Diese kannst du aber nicht auf ein Register schreiben. Du musst den Wert von der Einheit trennen, eine Variante ist
Define read.Power at +*00:00:10 { fhem "set Leistung " . (ReadingsVal('Kostal','AC.Power',99)+0) }
die aber zu einer Warnung im Log führt. Wenn du es 'sauber' haben möchtest kannst du z.B.
Define read.Power at +*00:00:10 {my @x=split / /,ReadingsVal('ZWave_SENSOR_MULTILEVEL_5','temperature',99);; fhem "set Temperatur ".$x[0]}verwenden.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: yogi74 am 15 Januar 2017, 10:32:19
Hey, you are the man.

Vielen Dank, funktioniert auf anhieb  ;D ;D
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: StinkyHexor am 20 Januar 2017, 21:40:55
Ich hoffe die Frage wurde nicht schon beantwortet.

Ich habe eine Variable FHEM_Schalter_WZ_Deckenlicht als BOOL auf der Wago. (MX0.0)
Warum kann ich diese Variable nicht an einem Baustein als VAR_IN_OUT benutzen?
Als Fehlermeldung kommt das der Baustein eine Variable mit Schreibzugriff benötigt.

Danke für jeden Tip.


*Edit*
Ich lass es mal stehen, aber es gibt dafür keine Lösung. Das Schreiben aus einem FB in einen Merker funktioniert nicht.
Eine Ausführliche Beschreibung habe ich hier gefunden: https://www.sps-forum.de/codesys-und-iec61131/47586-var_in_out-mit-merker.html

Dann muss ich es in der Wago doch nochmal anders machen.
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: uwe85 am 23 Januar 2017, 14:53:10
Hallo,

seit Weichnachten versuche Modbus mit B&R Steuerung komunizieren.

Bis heute schaffe ich die Register hin und herschicken  die Bit schreiben funktionierts, aber lesen nicht, ich vermute dass att fehlte/stimmte etwas nicht.

Logabzug:2017.01.23 14:36:34 5: AddRQueue [20 00 00 00 00 06] 01 03 20 00 00 01
2017.01.23 14:36:34 5: SimpleWrite [20 00 00 00 00 06] 01 03 20 00 00 01
2017.01.23 14:36:34 5: AddRQueue [60 00 00 00 00 06] 01 03 60 00 00 01
2017.01.23 14:36:34 5: adding to RQUEUE - 1
2017.01.23 14:36:34 5: AddRQueue [00 00 00 00 00 06] 01 01 00 00 00 08
2017.01.23 14:36:34 5: adding to RQUEUE - 2
2017.01.23 14:36:34 5: AddRQueue [40 00 00 00 00 06] 01 01 40 00 00 08
2017.01.23 14:36:34 5: adding to RQUEUE - 3
2017.01.23 14:36:34 5: ModbusTCPServer_Parse: received [20 00 00 00 00 05] 01 03 02 00 7B
2017.01.23 14:36:34 5: Modbus_BuR: dispatch ModbusRegister:1:8192:3:1:123
2017.01.23 14:36:34 5: ModbusRegister_Parse: 3 1 8192
2017.01.23 14:36:34 4: RQUEUE: 3
2017.01.23 14:36:34 5: SimpleWrite [60 00 00 00 00 06] 01 03 60 00 00 01
2017.01.23 14:36:34 5: ModbusTCPServer_Parse: received [60 00 00 00 00 05] 01 03 02 01 41
2017.01.23 14:36:34 5: Modbus_BuR: dispatch ModbusRegister:1:24576:3:1:321
2017.01.23 14:36:34 5: ModbusRegister_Parse: 3 1 24576
2017.01.23 14:36:34 4: RQUEUE: 2
2017.01.23 14:36:35 5: SimpleWrite [00 00 00 00 00 06] 01 01 00 00 00 08
2017.01.23 14:36:35 5: ModbusTCPServer_Parse: received [00 00 00 00 00 03] 01 81 02
2017.01.23 14:36:35 2: ModbusTCPServer_Parse: except (code 2)
2017.01.23 14:36:35 4: RQUEUE: 1
2017.01.23 14:36:35 5: SimpleWrite [40 00 00 00 00 06] 01 01 40 00 00 08
2017.01.23 14:36:35 5: ModbusTCPServer_Parse: received [40 00 00 00 00 03] 01 81 02
2017.01.23 14:36:35 2: ModbusTCPServer_Parse: except (code 2)
2017.01.23 14:36:44 5: AddRQueue [20 00 00 00 00 06] 01 03 20 00 00 01
2017.01.23 14:36:44 5: SimpleWrite [20 00 00 00 00 06] 01 03 20 00 00 01
2017.01.23 14:36:44 5: AddRQueue [60 00 00 00 00 06] 01 03 60 00 00 01
2017.01.23 14:36:44 5: adding to RQUEUE - 1
2017.01.23 14:36:44 5: AddRQueue [00 00 00 00 00 06] 01 01 00 00 00 08
2017.01.23 14:36:44 5: adding to RQUEUE - 2
2017.01.23 14:36:44 5: AddRQueue [40 00 00 00 00 06] 01 01 40 00 00 08
2017.01.23 14:36:44 5: adding to RQUEUE - 3
2017.01.23 14:36:44 5: ModbusTCPServer_Parse: received [20 00 00 00 00 05] 01 03 02 00 7B
2017.01.23 14:36:44 5: Modbus_BuR: dispatch ModbusRegister:1:8192:3:1:123
2017.01.23 14:36:44 5: ModbusRegister_Parse: 3 1 8192
2017.01.23 14:36:44 4: RQUEUE: 3
2017.01.23 14:36:44 5: SimpleWrite [60 00 00 00 00 06] 01 03 60 00 00 01
2017.01.23 14:36:44 5: ModbusTCPServer_Parse: received [60 00 00 00 00 05] 01 03 02 01 41
2017.01.23 14:36:44 5: Modbus_BuR: dispatch ModbusRegister:1:24576:3:1:321
2017.01.23 14:36:44 5: ModbusRegister_Parse: 3 1 24576
2017.01.23 14:36:44 4: RQUEUE: 2
2017.01.23 14:36:44 5: SimpleWrite [00 00 00 00 00 06] 01 01 00 00 00 08
2017.01.23 14:36:44 5: ModbusTCPServer_Parse: received [00 00 00 00 00 03] 01 81 02
2017.01.23 14:36:44 2: ModbusTCPServer_Parse: except (code 2)
2017.01.23 14:36:44 4: RQUEUE: 1
2017.01.23 14:36:44 5: SimpleWrite [40 00 00 00 00 06] 01 01 40 00 00 08
2017.01.23 14:36:44 5: ModbusTCPServer_Parse: received [40 00 00 00 00 03] 01 81 02
2017.01.23 14:36:44 2: ModbusTCPServer_Parse: except (code 2)


Attr hatte vieles ausprobiert und finde nichts zum laufen,
obrige logs steht folgende Parameter:
defmod BuRlesenBit ModbusCoil 1 1
attr BuRlesenBit IODev Modbus_BuR
attr BuRlesenBit room B und R
attr BuRlesenBit source Input
attr BuRlesenBit verbose 5


lösung und erklährung wär mir dankbar..
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 23 Januar 2017, 20:01:47
Hallo,

Der Controller liefert beim Lesen der Adressen 0 und 16384 eine Fehlermeldung. Code 2 bedeutet dass die angeforderte Adresse nicht erlaubt ist. Welche Steuerung verwendest du ?

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: uwe85 am 23 Januar 2017, 22:52:39
Hallo ChrisD,

Benütze aktuellste von B&R AS4 und die X20CP1382

Dort kann bei Konfigurator Modbus Stuktur aufbauben/ adressieren und Variablen anbinden für E/A oder Programm
ID ist sowie die 1 . Element Nummer hab ich als Standard genommen:
Coil:16384
Discrete : 0 + 1
InputReg:8192
Holding Reg:24576

wie gesagt alles funktioniert außer Discrete
und bei der SPS Seite zählt FehlerConter hoch beim abfragen.
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: pc1246 am 24 Januar 2017, 07:30:03
Moin
Ich waere vorsichtig beim benutzen von "identifiern" als Name! Benenne probehalber mal coil um!?
Gruss Christoph
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 24 Januar 2017, 11:35:06
Hallo,

Kannst du versuchen ob es mit
attr BuRlesenBit disableRegisterMapping 1
attr BuRlesenBit source Input

funktioniert ?

Wenn ja, kann es sein dass du einen Offset von 1 bekommst, in dem Fall musst du die Definition anpassen:
defmod BuRlesenBit ModbusCoil 1 0

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: uwe85 am 24 Januar 2017, 12:53:20
Hallo,

lösung gefunden: Sollte bei der SPS B&R  8 Bit für Input auflegen , anscheinend holt FHEM Byteweise ab , denk ich.

Daten austausch funktioniert nun,   so jetzt fange mit Projekt an.

Danke nochmals.

Gruss Uwe
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 26 März 2017, 20:09:39
Hallo ChrisD,
endlich bin ich dazu gekommen einen FunctionBlock aus der Taster Dimm DMX Geschichte zu machen...
Bis hierher war es ja so das der Slider sowohl auf änderungen aus der SPS heraus reagierte, als auch damit die möglichkeit bestand den Wert zu verändern.

Bei meiner jetzigen Version mit einen FB funktioniert das leider nicht mehr. Ich habe auch keine Idee mehr woran das liegt.
Vielleicht schaust Du mal darauf - ich habe ein paar Screenshots gemacht.
Würde mich freuen wenn Du mir sagen kannst wo mein Denkfehler liegt.
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 27 März 2017, 19:00:46
Hallo,

Die Verbindung zu FHEM erfolgt über die Variable F_LL_Schlafen1, diese ist aber nicht mit dem Baustein verbunden. Wenn du F_LL_Schlafen1 mit dem Ausgang F_LightLevel verbindest kannst du zwar den Wert in FHEM sehen, ihn aber nicht ändern.

Eine Möglichkeit ist die Variablendeklaration des Bausteines so zu ändern dass LightLevel as IN_OUT übergeben wird:
VAR_INPUT
OnSwitch : BOOL;
OffSwitch : BOOL;
F_Trigger : BOOL;
F_preSet : INT;
END_VAR
VAR_IN_OUT
LightLevel : INT;
END_VAR
VAR_OUTPUT
F_response : BOOL;
DMX_Value : BYTE;
END_VAR


Den Ausgang DMX_Value habe ich hinzugefügt damit der Wert direkt ins Array abDMX_Values geschrieben werden kann.

Im FB hat der Schritt 6 keine Funktion da die Ausgangsvariable im Schritt 7 überschrieben wird. Einer von beiden kann entfallen.

Schritt 8 würde ich ersetzen durch Bild_1.

Der Aufruf des Bausteines könnte dann wie in Bild_2 gezeigt erfolgen. Schritt 2 aus dem Hauptprogramm (INT_TO_BYTE) ist damit nicht mehr nötig.

Grüße,

ChrisD



Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 27 März 2017, 20:37:33
Tausend Dank!

Mal wieder funktioniert alles wie gewünscht.
Am Ende hast Du unser Haus programmiert ;-)

Jetzt kann es endlich weiter gehen...
Du hörst sicher von mir.
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: vicky am 29 April 2017, 19:47:48
Hallo zusammen,
ich bin am Versuch meinen CX1010(Beckhoff) mit dem FHEM zu verbinden und den Wert einer REAL-Variable zu lesen/schreiben.
Leider bisher ohne Erfolg.

Eine Verbindung besteht.
Das Lesen der Variable funktioniert dennoch nicht(siehe Anhang FHEM1.png).
Zumindest denke ich das, da ich nur 3 Fragezeichen sehe.
Oder bin ich da falsch? Kann ich bei der Ansicht "Everything" keine Werte sehen?


Definiert habe ich(siehe fhem.cfg):
FHEM:
define CX1010 ModbusTCPServer 172.16.17.20:801
define SPS_Real ModbusRegister CX1010 MF400
PLC:
F_400    AT %MD400 : REAL    ; (*Modbusadresse 12688*)

Kennt sich jemand von euch mit der Anbindung an Beckhoff-SPSen aus.
Gibt es da besondere Definitionen

Ich vermute, das sich das CX1010-System irgendwie anderst ansprechen lässt als WAGO-SPSen.

Folgende Anhänge:
Konifg: "fhem.cfg",
Web/PLC: FHEM1.png
Version: FHEM Version1.png


Danke schon mal im Voraus
vicky
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 29 April 2017, 20:41:25
Hallo,

Bist du dir sicher dass der Port 801 ist. Wenn ich die Dokumentation von Beckhoff richtig verstehe ist das der ADS-Port.

Die Definition
define SPS_Real ModbusRegister CX1010 MF400
kann eigentlich nur mit Wago-Steuerungen verwendet werden da das Modul das Mapping von Wago kennt. Nach ModbusRegister muss auch 'wago' stehen.

Das Default-Mapping von Beckhoff scheint aber für die Merkerbereiche ähnlich wie das von Wago zu sein, MW0 liegt wie bei Wago auf Adresse 12288. Du könntest also folgende Definition probieren:

define CX1010 ModbusTCPServer 172.16.17.20:502
define SPS_Real ModbusRegister wago MF400


Da ich das interne Speicherlayout von Beckhoff nicht kenne ist es auch möglich dass eventuell
define SPS_Real ModbusRegister wago MF200funktioniert.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: vicky am 01 Mai 2017, 12:46:08
Hallo ChrisD,

ZitatBist du dir sicher dass der Port 801 ist. Wenn ich die Dokumentation von Beckhoff richtig verstehe ist das der ADS-Port.
Nein.
Ich habe mit dem Port 502 nur keine Verbindung bekommen. Daher habe ich den mir bekannten Port benutzt. Der meldet nach dem "define cx801 ModbusTCPServer  172.16.17.20:801" auch schön "opened". Port "502" eben nicht.
Siehe Anhang (FHEM2.png).
Dort habe ich explizit nochmal 2 separate Definitionen angelegt:
1. define cx502 ModbusTCPServer  172.16.17.20:502
2. define cx801 ModbusTCPServer  172.16.17.20:801



Jetzt ist es halt so, das ich die 27 Seiten dieses Threads hier durchgegangen bin, da mit dem Suchbegriff "BECKHOFF" dieser auch auftauchte.
Darin schreiben ja der ein oder andere(bk9050, der-Lolo), daß Sie mit Beckhoff-Hardware arbeiten und es wohl funkioniert.
Oder geht's so doch nicht? Das konnte ich nirgends rauslesen.
Ich verwende einen CX1010(Windows Embedded) mit TwinCat 2.11

Evenutell sollte meine Anfrage auch in einen eigenen Thread verschoben werden, um Diesen nicht zu zerpflücken.


Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 01 Mai 2017, 12:54:18
Ich setze eine Wago SPS ein, kenne den passenden Port für die Beckhoff auch nicht - was sagt denn Tante Google?
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 01 Mai 2017, 14:06:30
Hallo,

Ist der ModbusTCP-Server auf der SPS installiert ? Nach den Infos hier (https://infosys.beckhoff.com/index.php?content=../content/1031/tcmodbussrv/html/tcmodbussrv_overview.htm&id=) muss er getrennt installiert werden.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: vicky am 01 Mai 2017, 21:50:39
Hallo,
jetzt versteh ich:
Auf den CX-Systemen muß noch ein "Modbus-TCP-Server" installiert werden.
Die BC(Buskontroller) haben das "onboard".

Zum Glück habe ich hier noch eine BC9000.
Verbindung eingerichtet: define bc9000 ModbusTCPServer 172.16.17.2
Verbindung ok(FHEM3.png)

Variable angelegt
SPS    = "bce_DG_Bad_SW AT %MB130 :INT" (MW130.png):
FHEM = "define BC9000_MW130 ModbusRegister bc9000 MW130"
Leider wird kein Value angezeigt.
Für INT ist MW ok?

Anbei das Log. Könnte weiterhelfen:
Was bedeuten die "PERL WARNING"

2017.05.01 21:26:27 1: starting in console mode
2017.05.01 21:26:27 1: Including fhem.cfg
2017.05.01 21:26:27 3: telnetPort: port 7072 opened
2017.05.01 21:26:27 3: WEB: port 8083 opened
2017.05.01 21:26:27 3: WEBphone: port 8084 opened
2017.05.01 21:26:27 3: WEBtablet: port 8085 opened
2017.05.01 21:26:27 2: eventTypes: loaded 6 events from ./log/eventTypes.txt
2017.05.01 21:26:27 1: PERL WARNING: Argument "bc9000" isn't numeric in numeric lt (<) at ./FHEM/37_ModbusRegister.pm line 135, <$fh> line 43.
2017.05.01 21:26:27 1: PERL WARNING: Argument "MW130" isn't numeric in numeric lt (<) at ./FHEM/37_ModbusRegister.pm line 135, <$fh> line 43.
2017.05.01 21:26:27 3: BC9000_MW130: I/O device is bc9000
2017.05.01 21:26:27 1: Including ./log/fhem.save
2017.05.01 21:26:27 3: Opening bc9000 device 172.16.17.2:502
2017.05.01 21:26:27 3: bc9000 device opened
2017.05.01 21:26:27 3: Opening cx502 device 172.16.17.20:502
2017.05.01 21:26:30 3: Can't connect to 172.16.17.20:502: Unknown error
2017.05.01 21:26:30 3: Opening cx801 device 172.16.17.20:801
2017.05.01 21:26:30 3: cx801 device opened
2017.05.01 21:26:30 3: initialUsbCheck return value: This command is not yet supported on windows
2017.05.01 21:26:30 2: SecurityCheck:  WEB,WEBphone,WEBtablet has no associated allowed device with basicAuth. telnetPort has no associated allowed device with password/globalpassword.  Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2017.05.01 21:26:30 0: Featurelevel: 5.8
2017.05.01 21:26:30 0: Server started with 13 defined entities (fhem.pl:13447/2017-02-19 perl:5.010001 os:MSWin32 user:xxxx pid:1234)
2017.05.01 21:26:32 2: ModbusRegister_Parse: invalid address 3 0 0
2017.05.01 21:26:32 2: ModbusRegister_Parse: invalid address 3 0 0
2017.05.01 21:26:32 3: bc9000: Unknown code ModbusRegister:0:0:3:1:0, help me!
2017.05.01 21:26:37 2: ModbusRegister_Parse: invalid address 3 0 0
2017.05.01 21:26:37 2: ModbusRegister_Parse: invalid address 3 0 0



Eine Frage zum Port 801 bleibt:
Ist eine Nutzung des ADS-Protokoll möglich?
Eine Verbindung besteht ja laut Status jedenfalls schon mal.

Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 01 Mai 2017, 22:30:47
Hallo,

Wie ich schon geschrieben hatte ist hinter ModbusRegister nur 'wago' (oder eine Modbus-Adresse) zulässig, du musst die Definition also anpassen:

define BC9000_MW130 ModbusRegister wago MW130

ZitatIst eine Nutzung des ADS-Protokoll möglich?
Mit den Modbus-Modulen kannst du kein ADS verwenden, du müsstest dafür eigene Module schreiben.

ZitatEine Verbindung besteht ja laut Status jedenfalls schon mal.
Der Status 'opened' bedeutet nur dass jemand die Verbindung angenommen hat, ob über diese Verbindung aber Daten ausgetauscht werden können ist nicht gesagt. In diesem Fall wird es nicht funktionieren.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 28 Juni 2017, 19:42:05
Hallo ChrisD,
jetzt geht die Inbetriebnahme los, hierbei fällt mir auf das ich an dem funktionsblock immer nur einen Kanal "anschliessen" kann. Hast Du eine Idee wie ich mehrere kanäle auf einem Baustein zusammenfassen kann? Toll wäre auch wenn ich die einzelnen Kanäle mit klareren namen versehen könnte. Variablen deklarieren war noch nie meine stärke...
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 30 Juni 2017, 23:11:43
Hallo,

Wenn du die Kanäle in Gruppen schalten möchtest kannst du die Arrayelemente einfach kopieren (siehe B1.png).

ZitatToll wäre auch wenn ich die einzelnen Kanäle mit klareren namen versehen könnte.
Meinst du damit die Elemente von 'abDMX_Values' ?

Wenn ja kannst du das über den Umweg des Merkerbereiches machen. Dazu musst du zuerst das Array als globale Variable auf eine feste Adresse legen, z.B.
abDMX_Values AT %MB10001 : ARRAY[1..DMX_MAX_CH] OF BYTE;

und anschließend die einzelnen Kanäle definieren, z.B.
DMX_Licht_Bad_1 AT %MB10001 : BYTE; (* Kanal 1 *)
DMX_Licht_Bad_2 AT %MB10007 : BYTE; (* Kanal 7 *)
DMX_Licht_Keller AT %MB10009 : BYTE; (* Kanal 9 *)


Beim Aufruf von FB_Schlafen_1 kannst du dann statt abDMX_Values[1]  DMX_Licht_Bad_1 verwenden (siehe B2.png).

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 02 Juli 2017, 09:10:17
Guten Morgen ChrisD,
tausend Dank, das funktioniert und ist für mich auch gut händelbar...
Ich habe ja nun in meinem FB einen wert "preSet" der von FHEM kommen soll.
Fhem soll je nach Tageszeit, oder twilight status den startwert der Dimmer beeinflussen, sodass es z.b. nachts, falls man mal zur Toilette muss nicht richtig hell wird...
Das funktioniert ja wie gedacht/geplant... Ein problem wäre es aber wenn FHEM nicht zur Verfügung steht.
Hast Du vielleicht schon eine art Watchdog parat um die Verfügbarkeit von FHEM zu checken? Ich könnte ja "preSet" bei nicht Verfügbarkeit von FHEM auf einen festen wert setzen, oder?

Der Dimmer ist mir nun wo alles montiert ist doch etwas zu schnell. Wie könnte ich das verlangsamen ohne direkt die ganze Tags langsamer zu machen?

einen schönen Sonntag wünsche ich Dir...
Michael
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 02 Juli 2017, 12:39:20
mit FHEM stelle ich nun noch mehr probleme fest - der Eventmonitor steht nicht mehr still, kann das mit dem kopieren des Arrays auf den MB10001 zusammen hängen?
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 02 Juli 2017, 13:09:00
Hallo,

Was steht im Event-Monitor ?

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 02 Juli 2017, 13:31:21
Im Eventmonitor tauchen die Preset werte die FHEM an Wago übergeben soll auf, fortlaufend, permanent obwohl event-on-change gesetzt ist. Diese liegen auf %MW200,202,204 bei MW201,203 und 205 kommen aktualisierungen nur wenn sich auch was ändert..
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 02 Juli 2017, 14:14:27
Hallo,

Kannst du einen Auszug aus dem Event-Monitor sowie ein list eines der betroffenen Presets posten ?

Schreibt FHEM auf die Presets (z.B. über notify oder DOIF) ?

Grüße,

ChrisD

Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 02 Juli 2017, 14:54:26
Fhem schreibt noch nicht auf die Presets
exemplarisch ein list auf "PAnkleide"
Internals:
   DEF        wago MW202
   IODev      WagoController
   LASTInputDev WagoController
   MSGCNT     19162
   ModbusRegister_lastRcv 2017-07-02 14:51:40
   NAME       PAnkleide
   NR         327
   NTFY_ORDER 50-PAnkleide
   STATE      0
   TYPE       ModbusRegister
   WagoController_MSGCNT 19162
   WagoController_TIME 2017-07-02 14:51:40
   lastUpdate Sun Jul  2 14:51:40 2017
   nextUpdate Sun Jul  2 14:51:40 2017
   Readings:
     2017-07-02 14:51:40   PreSet          0
     2017-07-02 14:51:40   RAW             0000
     2017-07-02 14:51:40   state           0
   Helper:
     addr       3 0 12490
     address    12490
     disableRegisterMapping 1
     lastUpdate 1498999900.78585
     nextUpdate 1498999900.98712
     nread      1
     readCmd    0�
     register   12490
     registerType 3
     unitId     0
     updateIntervall 0.1
     wago       1
     wagoDataType W
     Cnv:
       a          1
       b          0
       max        65535
       min        0
       step       100
Attributes:
   IODev      WagoController
   room       01-Schlafzimmer
   setList    PreSet:slider,0,1,255
   stateAlias PreSet
   webCmd     PreSet


Nun noch ein auszug aus dem Eventmonitor...

02 14:53:45 ModbusRegister PAnkleide 0
2017-07-02 14:53:45 ModbusRegister PAnkleide RAW: 0000
2017-07-02 14:53:45 ModbusRegister PAnkleide PreSet: 0
2017-07-02 14:53:45 ModbusRegister PSchlafbereich 0
2017-07-02 14:53:45 ModbusRegister PSchlafbereich RAW: 0000
2017-07-02 14:53:45 ModbusRegister PSchlafbereich PreSet: 0
2017-07-02 14:53:45 ModbusRegister PSchlafbereichRGB 0
2017-07-02 14:53:45 ModbusRegister PSchlafbereichRGB RAW: 0000
2017-07-02 14:53:45 ModbusRegister PSchlafbereichRGB PreSet: 0
2017-07-02 14:53:45 ModbusRegister PAnkleide 0
2017-07-02 14:53:45 ModbusRegister PAnkleide RAW: 0000
2017-07-02 14:53:45 ModbusRegister PAnkleide PreSet: 0
2017-07-02 14:53:45 ModbusRegister PSchlafbereich 0
2017-07-02 14:53:45 ModbusRegister PSchlafbereich RAW: 0000
2017-07-02 14:53:45 ModbusRegister PSchlafbereich PreSet: 0
2017-07-02 14:53:45 ModbusRegister PSchlafbereichRGB 0
2017-07-02 14:53:45 ModbusRegister PSchlafbereichRGB RAW: 0000
2017-07-02 14:53:45 ModbusRegister PSchlafbereichRGB PreSet: 0
2017-07-02 14:53:46 ModbusRegister PAnkleide 0
2017-07-02 14:53:46 ModbusRegister PAnkleide RAW: 0000
2017-07-02 14:53:46 ModbusRegister PAnkleide PreSet: 0
2017-07-02 14:53:46 ModbusRegister PSchlafbereich 0
2017-07-02 14:53:46 ModbusRegister PSchlafbereich RAW: 0000
2017-07-02 14:53:46 ModbusRegister PSchlafbereich PreSet: 0
2017-07-02 14:53:46 ModbusRegister PSchlafbereichRGB 0
2017-07-02 14:53:46 ModbusRegister PSchlafbereichRGB RAW: 0000
2017-07-02 14:53:46 ModbusRegister PSchlafbereichRGB PreSet: 0
2017-07-02 14:53:46 ModbusRegister PAnkleide 0
2017-07-02 14:53:46 ModbusRegister PAnkleide RAW: 0000
2017-07-02 14:53:46 ModbusRegister PAnkleide PreSet: 0
2017-07-02 14:53:46 ModbusRegister PSchlafbereich 0
2017-07-02 14:53:46 ModbusRegister PSchlafbereich RAW: 0000
2017-07-02 14:53:46 ModbusRegister PSchlafbereich PreSet: 0
2017-07-02 14:53:46 ModbusRegister PSchlafbereichRGB 0
2017-07-02 14:53:46 ModbusRegister PSchlafbereichRGB RAW: 0000
2017-07-02 14:53:46 ModbusRegister PSchlafbereichRGB PreSet: 0
2017-07-02 14:53:46 ModbusRegister PAnkleide 0
2017-07-02 14:53:46 ModbusRegister PAnkleide RAW: 0000
2017-07-02 14:53:46 ModbusRegister PAnkleide PreSet: 0
2017-07-02 14:53:46 ModbusRegister PSchlafbereich 0
2017-07-02 14:53:46 ModbusRegister PSchlafbereich RAW: 0000
2017-07-02 14:53:46 ModbusRegister PSchlafbereich PreSet: 0
2017-07-02 14:53:46 ModbusRegister PSchlafbereichRGB 0
2017-07-02 14:53:46 ModbusRegister PSchlafbereichRGB RAW: 0000
2017-07-02 14:53:46 ModbusRegister PSchlafbereichRGB PreSet: 0
2017-07-02 14:53:46 ModbusRegister PAnkleide 0
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 02 Juli 2017, 15:24:06
Hallo,

Bei 'PAnkleide' scheint das Attribut event-on-change-reading nicht gesetzt zu sein, kannst du es hinzufügen und bei den anderen überprüfen ob es wirklich gesetzt ist ?

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 02 Juli 2017, 15:37:51
Mäno, wieder so ein Copy&Paste fehler..
Jetzt ist es stiller im Event Monitor. Danke Dir.

Hast Du eine Idee bzgl. watchdog?
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 02 Juli 2017, 16:48:58
Hallo,

Du kannst den Watchdog über einen sich regelmäßig ändernden Wert realisieren, z.B.:

define fhemalivecheck ModbusRegister wago MD1000
attr fhemalivecheck event-on-change-reading .*
define atFhemalivecheckToPLC at +*00:01:00 {fhem "set fhemalivecheck ".time()}

Damit wird die Uhrzeit von FHEM 1x pro Minute an die SPS geschickt. In der SPS kannst du überwachen ob sich der Wert ändert, z.B. mit einem TON. Variablen in der SPS:

fhemalivecheck AT %MD1000 : DWORD;
fhemalivecheckTmp : DWORD;
xfhemdead : BOOL;
TON_fhemalivecheck : TON;


Code in B3.png

Die Variable 'xfhemdead' kannst du in der SPS anschließend verwenden um z.B. ein Notprogramm laufen zu lassen oder Werte fest vorzugeben.

ZitatDer Dimmer ist mir nun wo alles montiert ist doch etwas zu schnell. Wie könnte ich das verlangsamen ohne direkt die ganze Tags langsamer zu machen?
Im Moment hängt die Dimmgeschwindigkeit von der Zykluszeit der SPS ab. Die einfache Lösung ist die Zykluszeit zu erhöhen, was aber nicht sehr flexibel wäre. Alternativ könntest du die Geschwindigkeit mit an den Baustein FB_Dim zu übergeben.

Dazu könntest du in FB_Dim bei VAR_INPUT
DimTakt : TIME:=T#1ms;
hinzufügen und bei VAR
TON_DimTakt : TON;
taktFreigabe : BOOL;

Den Taktgeber kannst du wie in B4 gezeigt am Anfang des FBs einbauen. Den Schritt 'Hoch-Runter Dimmen' kannst du wie in B5 gezeigt ändern. Wenn du DimTakt auf T#0ms setzt, hast du das bisherige Verhalten.

Grüße,

ChrisD

Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: Gungnir am 26 September 2017, 20:56:34
Hallo,

ich verfolge und lese das Thema zu Modbus TCP jetzt schon eine ganze Weile und hab dadurch auch schon ein klein bisschen was über Modbus erfahren können. Leider habe ich jetzt mit meiner aktuellen Konfiguration einen Kampf, bei dem ich nicht ganz weiter kommen.

Mein Setup:
SPS: Beckhoff CP6707 mit Twincat 2 und installeierten Modbusserver.
        eine Merker-Varaible mBus_RainWaterLevel    AT%MB100:REAL;

FHEM: in der aktuellen Version auf einem Raspberry

Ich habe FHEM mal rebooted.
Im FHEM-Logfile finde ich leider nur immer wieder den Eintrag
2017.09.26 20:31:27 2: ModbusRegister_Parse: invalid address 3 0 0
2017.09.26 20:31:27 2: ModbusRegister_Parse: invalid address 3 0 0
2017.09.26 20:31:27 3: SPS01: Unknown code ModbusRegister:0:0:3:1:384, help me!
2017.09.26 20:31:27 2: ModbusRegister_Parse: invalid address 3 0 0
2017.09.26 20:31:27 2: ModbusRegister_Parse: invalid address 3 0 0
2017.09.26 20:31:27 3: SPS01: Unknown code ModbusRegister:0:0:3:1:384, help me!


Ich bin bei Modbus völlig neu, daher bin ich da wahrscheinlich etwas blind, was eine möglich Lösung angeht. Gibt es beim Zugriff per Modbus auf Beckhoff möglicherweise etwas zu beachten?

LG und vielen Dank im Voraus

Gungnir
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 26 September 2017, 21:19:45
Hallo,

Kannst du versuchen die Definition von
define RainWaterLevel ModbusRegister SPS01 MF100
in
define RainWaterLevel ModbusRegister wago MF100
umzuändern ?

Der Begriff 'wago' bezieht sich auf die Adressierungsart resp. das Mapping von SPS- zu Modbus-Adressen. Die Zuordnung zum ModbusTCPServer erfolgt automatisch durch FHEM (zumindest solange du nur einen hast).

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: Gungnir am 27 September 2017, 07:53:25
Hallo ChrisD,

vielen Dank für die rasche Antwort.

ich habe noch mal Google bemüht und bin dann auf eine andere Definition gestoßen.

ich hab es jetzt so gemacht:

define RainWaterLevel ModbusRegister 1 12288
attr RainWaterLevel plcDataType REAL
attr RainWaterLevel disableRegisterMapping 1


damit hat es dann auch geklappt.

Eine Frage habe ich aber noch fürs Verständnis:die 12288, was genau ist da für ein Wert? Ist das der 12288. Register im Speicherabbild.

LG Gungnir
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 27 September 2017, 08:29:55
Hallo,

Bei Wago und Beckhoff kannst du ab Modbus-Adresse 12288 auf den Speicherbereich ab MW0 zugreifen. Die Definition mit 'wago' bei ModbusRegister (und ModbusCoil) nimmt dir nur die Berechnung der korrekten Adresse ab und trägt automatisch die richtigen Datentypen ein. MF100 liegt bei Wago z.B. auf den Modbus-Adressen 12688 und 12689.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: Gungnir am 27 September 2017, 09:14:15
Hallo,

ok, verstehe. Ich habe jetzt 2 REAL-Werte von meine Beckhoff gelesen.

das sieht so aus:

define RainWaterLevel ModbusRegister 1 12288
attr RainWaterLevel plcDataType REAL
attr RainWaterLevel disableRegisterMapping 1
attr RainWaterLevel event-on-change-reading .*


define TemperaturWater ModbusRegister 1 12290
attr TemperaturWater plcDataType REAL
attr TemperaturWater disableRegisterMapping 1
attr TemperaturWater event-on-change-reading .*


Meine Varaiblendeklaration in der SPS ist so:

       
        mBus_RainWaterLevel AT%MB0:REAL; (* 12288*)
mBus_TempWater AT%MB4:REAL;    (*  12290*)

        MBus_State1                   AT%Mx8.0:BOOL;    (*  12292*)


Muss ich dann mit define State1 ModbusRegister 1 12292.0 von FHEM aus aud einen boolschen Wert zugreifen?

LG
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 27 September 2017, 16:57:42
Hallo,

Für den Zugriff auf BOOL kannst du ModbusCoil verwenden, ModbusRegister ist für 16-Bit Werte.

In der Dokumentation von Beckhoff habe ich kein Mapping für Coils auf SPS-Speicherbereiche gefunden. Du kannst versuchen ob
define state1 ModbusCoil wago MX8.0
funktioniert.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: Gungnir am 02 Oktober 2017, 11:39:47
Hallo,

danke für die Info.

eine Frage habe ich jetzt noch. Wie muss ich vorgehen, wenn ich per Modbus von FHEM aus eine Variable in der Beckhoffsteuerung schreiben möchte?

z.B. eine Zielthemperatur für eine Heizungsansteuerung.

LG
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 04 Oktober 2017, 20:43:58
Hallo,

Wenn du eine Variable in der SPS für die Solltemperatur deklarierst und auf diese über ModbusRegister zugreifst, kannst du den Wert mit dem 'set'-Befehl von FHEM setzen.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 10 Oktober 2017, 00:00:51
Hallo ChrisD,
Ich habe gerade etwas eigenartiges im Logfile meiner FHEM installation entdeckt.
Zitat
2017.10.08 18:25:35 0: Cant open FHEM/perfmon at ./FHEM/98_help.pm line 235.
2017.10.08 18:22:34 3: RBadOben: I/O device is WagoController
2017.10.08 18:21:20 3: RBadOben: I/O device is modbusRTU
2017.10.08 14:05:15 2: ROOMMATE set rr_Christin home
2017.10.08 11:04:33 2: ROOMMATE set rr_Christin absent

RBadOben ist ein
Internals:
   CFGFN
   CHANGED
   DEF        wago MX1.4
   IODev      WagoController
   LASTInputDev WagoController
   MSGCNT     106023
   ModbusCoil_lastRcv 2017-10-09 23:55:24
   NAME       RBadOben
   NR         127
   NTFY_ORDER 50-RBadOben
   STATE      off
   TYPE       ModbusCoil
   WagoController_MSGCNT 106023
   WagoController_TIME 2017-10-09 23:55:24
   lastUpdate Mon Oct  9 23:55:23 2017
   nextUpdate Mon Oct  9 23:55:24 2017
   READINGS:
     2017-10-09 23:55:24   state           off
   helper:
     addr       1 0 12308
     address    12308
     disableRegisterMapping 1
     lastUpdate 1507586123.89598
     nextUpdate 1507586124.79766
     nread      8
     readCmd    0
     register   12308
     registerType 1
     unitId     0
     updateIntervall 0.1
     wago       1
     wagoDOOffset 0
     wagoT      M
     writeMode:
       DO         0
       addr       1 0 12468
       address    12468
       impDuration 0.5
       register   MX11.4
       registerType 1
       type       IM
Attributes:
   IODev      WagoController
   alias      Rolladen Badezimmer Oben
   event-on-change-reading .*
   group      Switch
   room       90 - Testumgebung,02-BadOben
   writeMode  Impulse:MX11.4



Ich nutze Dein Modbus Modul für ModbusTCP mit meiner Wago - ausserdem habe ich Stefans Modbus Modul definiert um eine ModbusRTU linie abfragen zu können.

Hast Du eine Idee was den wechsel des I/O Devices verursachen kann?
Komisch ist ja auch das es sich um nur einen Switch handelt und nicht um 14...
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 10 Oktober 2017, 22:59:40
Hallo,

Es ist schwierig zu sagen woran es genau liegt. Ich habe versucht mir das Modul von Stefan anzusehen, ich habe aber nichts gefunden was erklären würde wieso es von FHEM überhaupt als I/O-Device ausgewählt wird.

Sind die Meldungen nach einem Neustart oder rereadcfg gekommen ? In dem Fall könnte es an der Reihenfolge der Geräte in der Konfigurationsdatei liegen.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 11 Oktober 2017, 06:32:03
Ja, die reihenfolge - das könnte es sein...
RBadOben habe ich erst kürzlich hinzugefügt, ich pass das mal an..
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 13 Oktober 2017, 14:46:13
Hallo ChrisD,
es hängt tatsächlich an der Reihenfolge - da ich aber den ModbusRTU eh erstmal nicht sauber auf der Synology DiskStation ans laufen bekomme habe ich den RTU Part wieder rausgeworfen und auf einem RPI3 am laufen.

Meine nächste Baustelle sind nun die Rolläden, wie würdest Du diese Programmieren? Ich möchte ja auch gerne von FHEM aus auf z.b. 70% fahren können. Von den Tastern aus denke ich kurz drücken fahren in Endlage, gedrückt halten fahren bis ich loslasse... 
Ich müsste also für jeden Rollo individuell die Laufzeit ermitteln und von FHEM aus sagen x sekunden in richtung y fahren....

PS: mein Hardware problem hat sich gelöst, die Karten die mir mein großhändler angedreht hat sind negativ schaltend.

Grüße aus Berlin.
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 14 Oktober 2017, 22:04:42
Hallo,

Ich würde die Steuerung der Rollläden komplett auf der SPS machen. Von FHEM aus würde ich nur eine Position vorgeben die angefahren werden soll sowie Befehle für komplett auf und komplett zu.

Für die Steuerung in der SPS gibt es mehrere Möglichkeiten:
- du schreibst alle selbst
- du baust auf dem Baustein FbJalousie von Wago auf
- du verwendest die Bausteine BLIND_CONTROL_S und BLIND_INPUT aus der Oscat-Bibliothek

Du musst auf jeden Fall die Laufzeiten ermitteln damit du ungefähr positionieren kannst.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 15 Oktober 2017, 20:10:09
Ok, ich habe heute alle Rolläden mit einem eigenem FB_Jal in betrieb genommen - über ein TOF fahre ich auf Tastendruck jeweils die Endlagen an. Ausserdem habe ich in FHEM mit ModbusCoil die Trigger für auf und ab an jedem Rollo inkl. rückmeldung integriert.
Ich habe nun 32 ModbusCoil im Einsatz x2 also jeweils mit rückmeldung. Ausserdem 13 ModbusRegister um Dimm-Werte zu übertragen.

Bilde ich mir das nur ein? Oder ist die aktualisierung der response schon langsamer geworden?


Was die möglichkeiten der Steuerung angeht könnte ich doch wieder einen VAR IN OUT benutzen - um zumindest grob auf % fahren zu können und eine Anzeige der Position zu haben. Bei jedem voll geöffnet könnte man ja einen Reset setzen, damit es nicht auseinanderdriftet...

Bei 20sekunden laufzeit käme ich ja sogar Prozentgenau von der auflösung her hin - wobei man ja auch die ModbusCoil BITS in ein Register stecken könnte.
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 15 Oktober 2017, 22:43:45
Hallo,

ZitatBilde ich mir das nur ein? Oder ist die aktualisierung der response schon langsamer geworden?
Hast du das Attribut combineReads beim Server gesetzt ?

Wenn nicht kannst du es mit
attr WagoController combineReads 20:80
versuchen. Dadurch werden die Leseaufträge so weit wie möglich zusammengefasst. So wird z.B. statt 32 Aufträgen mit 1 Coil nur 1 Auftrag mit 32 Coils erzeugt.

ZitatWas die möglichkeiten der Steuerung angeht könnte ich doch wieder einen VAR IN OUT benutzen
Ja, die Ansteuerung der Rollos unterscheidet sich im Prinzip nicht allzuviel vom DMX.

Zitatwobei man ja auch die ModbusCoil BITS in ein Register stecken könnte
Das ist zwar im Prinzip möglich, das Handling in FHEM ist aber ziemlich schwierig.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 15 Oktober 2017, 23:00:12
Wow, combineReads funktioniert auf den ersten blick super.

Solange es performant genug bleibt also keine spielereien mit Coils in Registern...

1000Dank!
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 19 Oktober 2017, 14:41:11
Hallo ChrisD,
nach einem FHEM neustart fällt mir zur Zeit die folgende Zeile auf....

Zitat2017.10.19 13:53:34 2: ModbusTCPServer_Parse: except (code 2)

Kannst Du versuchen mir zu erklären was die aussage hinter der Meldung ist?

Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 20 Oktober 2017, 22:20:13
Hallo,

Die Meldung bedeutet dass versucht wird auf eine Adresse zuzugreifen die die SPS nicht kennt. Hast du die Meldung nur einmalig beim Start oder kommt sie regelmäßig ?

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 20 Oktober 2017, 22:55:08
nur einmalig beim start...
Ich habe aber noch eine ungewöhnlich hohe Prozessorlast(70%) und Speichernutzung(2/3 von 2GB) unter htop festgestellt - die DS716+ii ist als FhemHost aber stark genug, ich kann das problem nachstellen - ich hatte den Poll Interval immer auf 0.1 stehen, ich vermute das die menge an Coils und Registern die ich abrufe mittlerweile ein problem beim pollen sind und etwas wie ein "Que" voll läuft. Ab 0.5 ist wieder alles wie zuvor, Prozessorlast unter 10% und auch der Speicher scheint wieder normal zu funktionieren.

Nochmal ein list des Controllers in FHEM damit du überblicken kannst wieviel mittlerweile kommuniziert wird.
Internals:
   DEF        192.168.1.4
   DeviceName 192.168.1.4:502
   FD         13
   LAST_ERROR 7
   LAST_EXCEPT 2
   NAME       WagoController
   NR         23
   NTFY_ORDER 50-WagoController
   PARTIAL
   STATE      ok
   TYPE       ModbusTCPServer
   statistics 110168 / 110168 / 4351418 / 1322016
   READINGS:
     2017-10-20 16:10:47   state           opened
   helper:
     delayNextRead 0
     delayNextWrite 0
     fc         1
     hd_tr_id   64190
     hd_unit_id 0
     lastFrame  SimpleWrite [FA BE 00 00 00 06] 00 01 30 00 00 48
     lastSimpleWrite ��0H
     last_fc    3
     last_hd_tr_id 65190
     seq        65191
     seqCoils   64191
     state      idle
     Wago:
       AI         12
       AO         12
       DI         96
       DIOffset   192
       DO         72
       DOOffset   192
       initDone   1
       x          1
     bm:
       ModbusTCPServer_Notify:
         cnt        16890
         dmx        0
         mAr
         mTS
         max        0
         tot        0
       ModbusTCPServer_Read:
         cnt        110168
         dmx        0
         mTS        20.10. 17:42:56
         max        90
         tot        2651455
         mAr:
           HASH(0x1b6daa8)
       ModbusTCPServer_Set:
         cnt        3
         dmx        0
         mAr
         mTS
         max        0
         tot        0
     combineReads:
       cfg:
         maxSize    80
         maxSpace   20
       coils:
         ARRAY(0x96d7740)
         ARRAY(0x7f75308)
         ARRAY(0x96d4e30)
         ARRAY(0x826cb48)
         ARRAY(0x826d110)
         ARRAY(0x968c630)
         ARRAY(0x96db5f0)
         ARRAY(0x8266838)
         ARRAY(0x82664e0)
         ARRAY(0x96d7830)
         ARRAY(0x9680600)
         ARRAY(0x9665228)
         ARRAY(0x8265c40)
         ARRAY(0x96d57a0)
         ARRAY(0x9699468)
         ARRAY(0x96d4c50)
         ARRAY(0x8266820)
         ARRAY(0x967b198)
         ARRAY(0x96d6d28)
         ARRAY(0x96db938)
         ARRAY(0x966c0a0)
         ARRAY(0x96574e8)
         ARRAY(0x9647c60)
         ARRAY(0x8267f70)
         ARRAY(0x96d77b8)
         ARRAY(0x966c100)
         ARRAY(0x9640748)
         ARRAY(0x96d41a0)
         ARRAY(0x96d6e48)
         ARRAY(0x9675cb8)
         ARRAY(0x96db470)
         ARRAY(0x96d5db8)
         ARRAY(0x96d6350)
         ARRAY(0x96d5b60)
         ARRAY(0x96d7890)
       data:
         64058:
           0
           1
           12288
           72
         64314:
           0
           1
           12288
           72
         65082:
           0
           3
           12488
           26
         65338:
           0
           3
           12488
           26
       registers:
         ARRAY(0x96d7650)
         ARRAY(0x95f87e0)
         ARRAY(0x96db488)
         ARRAY(0x96d4938)
         ARRAY(0x967b330)
         ARRAY(0x7fd89f0)
         ARRAY(0x8267e98)
         ARRAY(0x96d62c0)
         ARRAY(0x9698ca0)
         ARRAY(0x96d3db8)
         ARRAY(0x96db5d8)
         ARRAY(0x8267d78)
         ARRAY(0x96d4a88)
         ARRAY(0x96d5158)
         ARRAY(0x96d4008)
         ARRAY(0x8265ac0)
         ARRAY(0x9647408)
         ARRAY(0x96d3800)
         ARRAY(0x96d7560)
         ARRAY(0x96d7aa0)
         ARRAY(0x96d5218)
         ARRAY(0x96d7cb0)
         ARRAY(0x966aba8)
         ARRAY(0x826bff0)
         ARRAY(0x96d6c68)
         ARRAY(0x96d7da0)
     statistics:
       bytesIn    4351418
       bytesOut   1322016
       pktIn      110168
       pktOut     110168
Attributes:
   combineReads 20:80
   event-on-change-reading .*
   pollInterval 0.4
   room       99-Controller
   serverType Wago


Vielleicht hängt das problem auch mit combine reads zusammen, das habe ich aber noch nicht abgeschaltet - weil es wirklich viel hilft.

Ich gebe und nehme aber immer noch lange nicht alle Daten die ich brauche, ob ich mir auf Wago Seite auch gedanken bzgl. Tasks und Task Klassen machen muss?
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 21 Oktober 2017, 08:56:46
Hallo,

Durch das Attribut combineReads werden die Daten zwar schneller von der SPS gelesen, es kommen pro Lesezyklus aber auch wesentlich mehr Daten bei FHEM an die verarbeitet werden müssen. Ohne combineReads und mit einem Poll-Intervall von 0.1 muss FHEM alle 100 ms einen Wert verarbeiten, bei combineReads 20:80 sind es alle 100 ms bis zu 80 Werte. Du kannst die Verarbeitung durch FHEM etwas 'optimieren' indem du das Attribut event-on-change-reading bei allen Registern und Coils auf .* setzt. Das Poll-Intervall sollte auch so stehen dass die SPS genügend Zeit hat auf die Anfrage zu antworten. Es kann sein dass die 100 ms etwas zu kurz sind.

Auf der SPS sollte bei der Anzahl von I/Os keine Aufteilung in Tasks nötig sein, du kannst dir aber die Auslastung z.B. im PLC-Browser ansehen. Aktionen die länger brauchen (Zugriff auf Dateisystem oder Netzwerk) solltest du in eigene Tasks auslagern.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 21 Oktober 2017, 09:19:06
Guten Morgen ChrisD,
alle vom TYPE=Modbus.* haben bereits event-on-change-reading .*
Wie kann ich schauen ob die SPS genug Zeit zum antworten hat?
Kannst DU mir kurz erklären wie ich mir die auslastung der 880 anschauen kann?
Zugriffe auf das Dateisystem oder Netzwerk habe ich nicht, ausser ich bin mit Codesys verbunden oder eben der ModbusTCP

Ich bin ja auch alles in allem glücklich - wunderte mich nur aufgrund des Arbeitsspeicher bedarf auf der fhemHost seite. Hier stelle ich auch immer noch über die laufzeit einen meiner meinung nach hohen bedarf fest...

Nach einem FHEM neustart sind es 2-3% nach nun etwa 18Stunden bin ich bei 15% Speicherbedarf..
Hab ein bisschen bedenken das System über einen LANGEN Zeitraum unbeobachtet laufen zu lassen. Vielleicht lasse ich FHEM irgendwann nachts mal neustarten...
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 21 Oktober 2017, 09:49:33
Hallo,

Die Auslastung kannst du im PLC-Browser in CoDeSys sehen. Dazu musst du dich mit der SPS verbinden, dann unten links den Tab Ressourcen aktivieren und dort 'PLC - Browser' anklicken. Dabei sollte sich rechts ein leeres Fenster öffnen über dem sich eine Eingabezeile befindet. Dort kannst du Befehle an die SPS schicken. Mit '?' wird dir eine Liste der möglichen Befehle angezeigt. Die Auslastung kannst du dir mit 'tsk' anzeigen lassen.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 21 Oktober 2017, 10:20:58
Hm...

tsk im PLC-Browser ergibt
Zitattsk
Not authenticated.
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 21 Oktober 2017, 12:05:19
Hallo,

Du musst dich zuerst einloggen mit 'login user password'. Falls du kein Passwort gesetzt hast sollte 'login admin wago' funktionieren.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 21 Oktober 2017, 13:39:15
Ok, Danke...
Ich poste hier mal die ausgabe da ich es nicht so recht interpretieren kann...

Zitattsk
Number of Tasks: 1
Task 0: DefaultTask,  ID: 0
   Cycle count: 118409830
   Cycletime:       2 ms
   Cycletime (min): 1 ms
   Cycletime (max): 4 ms
   Cycletime (avg): 1 ms
   Status: RUN
   Mode:   UNHANDLED
   ----
   Priority:  1
   Intervall: 0 ms
   Event:     NONE
   ----
   Function pointer: 16#28C84F78
   Function index:   465

Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 21 Oktober 2017, 21:29:56
Hallo,

Der Task ist freilaufend, kann also soviel Zeit wie nötig verwenden. Bei einer mittleren Zykluszeit von 1 ms hat die SPS fast nichts zu tun, du hast also noch sehr viel Reserve. Nach jedem Programmzyklus macht die SPS automatisch ~1 ms Pause in der sie sich um andere Sachen kümmert (Verbindung zu CoDeSys, ModbusTCP, Web-Visu, ...).

Was den Speicherbedarf und die Auslastung von FHEM angeht muss ich mir ansehen wodurch dies kommen könnte.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 24 Oktober 2017, 20:35:10
Ich hab da nochmal ne frage ChrisD,
heute hatten wir einen Stromausfall - wahrscheinlich nur kurz, oder es waren nicht alle Phasen betroffen - einige Zeitanzeigen z.b. am Herd waren noch ok...

Zukunftsmusik: Die 24V werde ich noch über eine SiTop USV sichern. Somit sollte die wago bei kurzen unterbrechungen kein problem haben... 7Ah

Aber die DiskStation würde 230V benötigen...

FHEM startet also neu und verbindet sich mit dem frisch gestartetem Wago Programm. Die verbindung wird mit etwas verzögerung aufgebaut - das schiebe ich auf den ausfall der Netzwerkumgebung - Ubiquitti brauch recht lange zum Booten.

Das eigentliche problem ist glaube das die Wago den Zustand von FHEM nicht kennt, ich bin am überlegen ob ich auf
defmod startApptimeINITIAL notify global:INITIALIZED apptime
attr startApptimeINITIAL room 97-Helper

setstate startApptimeINITIAL 2017-10-24 08:54:34
setstate startApptimeINITIAL 2017-10-24 08:53:58 state active


noch die Zustände meiner PreSets setzen sollte. Sodass die Wago nach einem Neustart auch die Einstellwerte der Presets hat - und eben nicht erst wenn diese verändert werden...

Wie würdest Du dieses problem einfangen? 
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 25 Oktober 2017, 22:48:12
Hallo,

Ich würde die wichtigen Daten remanent in der SPS speichern. So behalten sie auch nach einem Stromausfall ihren Wert, unabhängig davon ob FHEM funktioniert. Dazu kannst du z.B. die Variablenkonfiguration in 'Globale_Variablen' um einen Block erweitern
VAR_GLOBAL RETAIN PERSISTENT
...
END_VAR


Sobald FHEM dann wieder läuft werden die Daten aus der SPS gelesen.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: darkstorm am 03 Dezember 2017, 17:24:24
Hallo ich habe da ein kleines Problem bei mir und der Wago ich habe die Plugins installiert und soweit auch alles konfiguriert kann auch mit dem list wago die Wago auslesen mit den ein und ausgängen jedoch bekomme ich andauernd in ca 3 minuten abstand diesen fehler.

2017.12.03 03:54:59 1: 192.168.1.254:502 disconnected, waiting to reappear (wago)
2017.12.03 03:54:59 1: 192.168.1.254:502 reappeared (wago)
2017.12.03 03:54:59 2: ModbusTCPServer_Parse: except (code 2)

könnt ihr mir vlt. nen ansatz geben wo ich da suchen könnte?
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 03 Dezember 2017, 17:56:20
Das scheint eher ein Netzwerkproblem zu sein, ModbusTCPServer_Parse: except (code 2) ist wenn ich mich richtig erinnere ein Adressierungsproblem, ich habe das auch - aber nur nach einem FHEM neustart - was ja einem verbindungsaufbau gleich zu setzen ist.
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: darkstorm am 06 Dezember 2017, 09:59:59
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?
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: pc1246 am 06 Dezember 2017, 10:26:47
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
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: pc1246 am 06 Dezember 2017, 10:38:36
@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
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 06 Dezember 2017, 21:53:42
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
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: pc1246 am 06 Dezember 2017, 22:23:23
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
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: bitvilla am 07 Dezember 2017, 11:51:03
Hallo,

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








module nameinstallationsdefinitions
ModbusAttr4997
Modbus3842
ModbusTCPServer3636
ModbusRegister33338
ModbusCoil11135

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
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: darkstorm am 07 Dezember 2017, 20:25:43
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.

Zitat
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
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 07 Dezember 2017, 21:15:32
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
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 03 Februar 2018, 14:53:45
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 -

Zitat2018.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.

Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 05 Februar 2018, 21:46:20
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
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: bitvilla am 06 Februar 2018, 14:51:14
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.

Zitat
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

Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 06 Februar 2018, 21:36:36
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.

ZitatWä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
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: bitvilla am 09 Februar 2018, 11:20:09
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
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 09 Februar 2018, 13:34:19
Der Raspi hat einen meiner meinung nach großen nachteil...
USB und Netzwerkschnittstelle werden auf demselben Bus zum Controller geführt.
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 17 Februar 2018, 12:24:55
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...

Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 17 Februar 2018, 20:56:49
Hallo,

Mit der Variante unten sollte es funktionieren. Im 1. Schritt wird der Preset nur übernommen wenn der Befehl von FHEM kommt oder der Taster gedrückt wird und noch nicht eingeschaltet ist. Wenn du möchtest dass auch FHEM nicht mehr auf das Preset umschaltet, kannst du die Position vom AND und OR tauschen.

Im 2. Schritt wird der Wert auf 255 gesetzt wenn der Taster gedrückt wird und das Licht bereits eingeschaltet ist.

Alternativ kannst du auch Variante 2 verwende, die packt alles in einen Schritt.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 19 Februar 2018, 19:30:38
Auch das funktioniert sehr gut - jetzt kann ich endlich den preset Tageszeit / Heilligkeit abhängig schieben... Das ist FHEM sache, ich denke mit Lightscene kann man da was schönes basteln.. Bin schon gespannt wie gut das funktioniert.

Tausend Dank - ich komm sicher bald mit fragen bzgl. der Rollos ;-)
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: xha1 am 07 April 2018, 16:43:45
Hallo zusammen,

erst einmal super Implementierung. Das Auslesen funktioniert ohne Probleme.

Folgende Herausforderung. Unsere WAGO Automatisierung wurde extern programmiert. Für jede Lampe wurde folgendes angelegt:


_B04_Esszimmertisch_status %MX1010.3 BOOL
_B04_Esszimmertisch_EIN %MX1013.7 BOOL (Beim Drücken 1 senden und beim loslassen 0 senden)
_B04_Esszimmertisch_AUS %MX1013.8 BOOL (Beim Drücken 1 senden und beim loslassen 0 senden)


Sprich Status, Ein und Aus sind voneinander getrennt. Für Ein bzw. Aus wird einmalig "1" geschrieben und danach "0".

Wie lässt sich das in FHEM implementieren?

define _B04_Esszimmertisch_status ModbusCoil wago MX1010.3

Damit wird zwar der Status angezeigt, aber auch der "Ein" und "Aus" button, wobei dieser ja anders funktioniert...
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 07 April 2018, 18:28:05
Hallo,

Du kannst das mit dem Attribut writeMode realisieren:

attr _B04_Esszimmertisch_status writeMode SetReset:MX1013.7:MX1013.8

Damit erzeugt ein Klick auf den Ein-Button einen Impuls auf MX1013.7 und ein Klick auf den Aus-Button einen Impuls auf MX1013.8.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: xha1 am 07 April 2018, 20:21:06
Vielen Dank, hat funktioniert!
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: xha1 am 13 April 2018, 07:44:14
Zwei weitere Fragen:

Zum einen wird jedes Register bzw. Coil nahezu sekundlich ausgelesen. Kann man das für jedes Register/Coil einzeln definieren (z. B. alle 5 Minuten) bzw. für alle zusammen?


Für die Rollos gibt es ebenfalls drei Werte. Lässt sich dies auch in einem Bedienelement kombinieren?
_M01_Kueche_AUF_VISU   %MX1020.7
_M01_Kueche_AB_VISU   %MX1020.8
_M01_EG_Kueche_status_Behang   %MW500   WORD    (1-100 %)
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 13 April 2018, 21:38:15
Hallo,

Du kannst die Abfragezeit pro Coil und Register einzeln mit dem Attribut updateInterval festlegen.

Du kannst auch die Verarbeitung der Daten optimieren indem du das Attribut event-on-change-reading setzt:
attr TYPE=ModbusCoil event-on-change-reading .*
attr TYPE=ModbusRegister event-on-change-reading .*


ZitatFür die Rollos gibt es ebenfalls drei Werte. Lässt sich dies auch in einem Bedienelement kombinieren?
Dafür kannst du readingsGroup verwenden, z.B.:
define rg_M01_Kueche readingsGroup _M01_EG_Kueche_status_Behang:state,<auf>,<ab>
attr rg_M01_Kueche commands { 'rg_M01_Kueche.auf' => 'set _M01_Kueche_AUF_VISU on-for-timer 1', 'rg_M01_Kueche.ab' => 'set _M01_Kueche_AB_VISU on-for-timer 1'}
attr rg_M01_Kueche notime 1


In der Commandref und im Wiki gibt es zusätzliche Informationen zu readingsGroup.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 12 Mai 2018, 08:56:45
...
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: Mic91 am 05 August 2018, 12:39:48
Hi,
Gibt es auch die Möglichkeit einen einfachen Wago Buskoppler einzufügen und dann einzelne Coils (Ausgänge) zu schalten Bzw. Eingänge abzufragen? Ich habe hier einen Wago 750-342 Buskoppler.

Über eine grobe Einrichtung Bzw. Eine Anleitung dazu wäre ich sehr dankbar.

Gruß Michael
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 05 August 2018, 16:03:47
Hallo,

Hier eine kurze ungetestete Anleitung:

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

- Verbindung zum Koppler definieren (IP-Adresse anpassen):
define wago750_342 ModbusTCPServer 192.168.178.89
attr wago750_342 serverType Wago
attr wago750_342 combineReads 20:80


- Eingänge anlegen:
define Eingang_0 ModbusCoil wago IX0.0
attr Eingang_0 event-on-change-reading .*


- Ausgänge anlegen:
define Ausgang_0 ModbusCoil wago QX0.0
attr Ausgang_0 event-on-change-reading .*


Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: Hollo am 17 August 2018, 09:09:00
Zitat von: Mic91 am 05 August 2018, 12:39:48
...Möglichkeit einen einfachen Wago Buskoppler einzufügen...habe hier einen Wago 750-342 Buskoppler...
Dito
Zitat von: ChrisD am 05 August 2018, 16:03:47
Hier eine kurze ungetestete Anleitung:
...
Getestet und für gut befunden; habe aktuell nur ein "Digital Out"-Modul dran, aber das funktioniert einwandfrei.
Digitale Eingänge und Analog-Module folgen in Kürze.
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: bitvilla am 06 November 2018, 16:12:16
Hallo,

in Bezug auf den Beitrag #474 ergeben sich aus meiner Sicht noch Fragen.

Es wurde folgender Beispiel-Code zur Anbindung des Kopplers gepostet:

define wago750_342 ModbusTCPServer 192.168.178.89
attr wago750_342 serverType Wago
attr wago750_342 combineReads 20:80


Genau diese Version habe ich auch seit mehr als zwei Jahren in meiner Config stehen.
Wundere mich aber schon seit längerer Zeit, dass bei jedem Start von FHEM im Logfile die Meldung "ModbusTCPServer_Parse: except (code 2)" erscheint.

Auszug aus dem Logfile:

2018.11.06 12:29:08 1: Including ./log/fhem.save
2018.11.06 12:29:08 3: Opening wago device 192.168.13.240:502
2018.11.06 12:29:08 3: wago device opened
2018.11.06 12:29:08 0: Featurelevel: 5.9
2018.11.06 12:29:08 0: Server started with 175 defined entities (fhem.pl:17652/2018-10-31 perl:5.020002 os:linux user:fhem pid:4952)
2018.11.06 12:29:09 2: ModbusTCPServer_Parse: except (code 2)
2018.11.06 12:29:19 3: telnetForBlockingFn_1541503759: port 33635 opened


Habe mich also mal auf die Suche gemacht und meine Wago-Konfiguration Stück für Stück zerlegt um den vermeintlichen Tippfehler zu finden.
Aber zu meiner Überraschung wurde die Meldung durch das Attribut "attr wago serverType Wago" ausgelöst.
Meine Config habe ich nun wie folgt angepasst:


define wago ModbusTCPServer 192.168.131.24
attr wago combineReads 20:80
attr wago pollInterval 1.6
# attr wago serverType Wago
attr wago verbose 3


Somit stellt sich für mich die Frage ob das Attribut "serverType" noch verwendet werden soll?
In der commandRef ist es zudem auch nicht mehr genannt.


Grüße,

bitvilla
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 06 November 2018, 21:15:12
Hallo,

Das Attribut wird benötigt wenn du statt der Modbus-Adressen direkt Speicher und I/O-Adressen verwenden möchtest.

Wenn das Attribut gesetzt ist, versucht das Modul beim Start den Typ und die Konfiguration der Wago-SPS auszulesen da die I/O-Adressen zum Teil von der Art und Anzahl der Scheiben abhängen. Beim 342 kann es sein dass diese Abfrage nicht funktioniert.

Kannst du verbose beim Server auf 4 setzen und FHEM mit gesetztem Attribut serverType neu starten ?

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: bitvilla am 07 November 2018, 15:50:23
Hallo,

in meinem Fall handelt es sich um eine Wago 750-881 mit folgender IO-Config:

Pos Module Type Mapping
1 750-4xx 2DI PLC
2 750-5xx 2DO PLC
3 750-4xx 8DI PLC
4 750-4xx 8DI PLC
5 750-4xx 8DI PLC
6 750-4xx 8DI PLC
7 750-4xx 8DI PLC
8 750-4xx 8DI PLC
9 750-4xx 8DI PLC
10 750-5xx 8DO PLC
11 750-5xx 8DO PLC
12 750-5xx 8DO PLC
13 750-5xx 8DO PLC
14 750-5xx 8DO PLC
15 750-5xx 8DO PLC
16 750-5xx 8DO PLC
17 750-4xx 8DI PLC
18 750-4xx 8DI PLC
19 750-5xx 8DO PLC
20 750-5xx 8DO PLC
21 750-5xx 8DO PLC
22 750-5xx 8DO PLC


Anbei nochmal die gewünschte FHEM-Config:

define wago ModbusTCPServer 192.168.13.240
attr wago combineReads 20:80
attr wago pollInterval 1.6
attr wago presenceLink wago_presence
attr wago verbose 4
attr wago serverType Wago

define wago_presence PRESENCE lan-ping 192.168.13.240


... und der Auszug aus dem Logfile mit verbose 4:

2018.11.07 15:16:35 3: WagoMD203: I/O device is wago
2018.11.07 15:16:35 3: WagoMD216: I/O device is wago
2018.11.07 15:16:35 3: WagoMD217: I/O device is wago
2018.11.07 15:16:35 3: WagoMW206: I/O device is wago
2018.11.07 15:16:35 3: WagoMW207: I/O device is wago
2018.11.07 15:16:35 1: Including FHEM/fhem_myConfig_allgemein.cfg
2018.11.07 15:16:37 3: SUSV: using I2C Address 15
2018.11.07 15:16:37 3: SUSV: Found firmware 2.61 - Basic
2018.11.07 15:16:37 1: Including ./log/fhem.save
2018.11.07 15:16:37 3: Opening wago device 192.168.13.240:502
2018.11.07 15:16:37 4: AddRQueue [20 10 00 00 00 06] 00 03 20 10 00 05
2018.11.07 15:16:37 4: AddRQueue [10 22 00 00 00 06] 00 03 10 22 00 04
2018.11.07 15:16:37 3: wago device opened
2018.11.07 15:16:37 0: Featurelevel: 5.9
2018.11.07 15:16:37 0: Server started with 176 defined entities (fhem.pl:17652/2018-10-31 perl:5.020002 os:linux user:fhem pid:450)
2018.11.07 15:16:38 3: telnetForBlockingFn_1541600198: port 37881 opened
2018.11.07 15:16:38 2: ModbusTCPServer_Parse: except (code 2)
2018.11.07 15:16:40 4: RQUEUE: 1
2018.11.07 15:16:43 4: AddRQueue [FD E8 00 00 00 06] 00 03 30 C8 00 08
2018.11.07 15:16:43 4: AddRQueue [FD E9 00 00 00 06] 00 03 31 90 00 24
2018.11.07 15:16:43 4: AddRQueue [FA 00 00 00 00 06] 00 01 00 20 00 20
2018.11.07 15:16:43 4: AddRQueue [FA 01 00 00 00 06] 00 01 02 28 00 18
2018.11.07 15:16:43 4: AddRQueue [FA 02 00 00 00 06] 00 01 10 00 00 50
2018.11.07 15:16:43 4: AddRQueue [FA 03 00 00 00 06] 00 01 36 40 00 30
2018.11.07 15:16:43 4: RQUEUE: 5
2018.11.07 15:16:45 4: RQUEUE: 4
2018.11.07 15:16:45 4: RQUEUE: 3
2018.11.07 15:16:45 4: RQUEUE: 2
2018.11.07 15:16:45 4: RQUEUE: 1
2018.11.07 15:16:47 4: AddRQueue [FD EA 00 00 00 06] 00 03 30 C8 00 08
2018.11.07 15:16:47 4: AddRQueue [FD EB 00 00 00 06] 00 03 31 90 00 26
2018.11.07 15:16:47 4: AddRQueue [FA 04 00 00 00 06] 00 01 00 20 00 20
2018.11.07 15:16:47 4: AddRQueue [FA 05 00 00 00 06] 00 01 02 28 00 18
2018.11.07 15:16:47 4: AddRQueue [FA 06 00 00 00 06] 00 01 10 00 00 50
2018.11.07 15:16:47 4: AddRQueue [FA 07 00 00 00 06] 00 01 36 40 00 30
2018.11.07 15:16:47 4: RQUEUE: 5
2018.11.07 15:16:47 4: RQUEUE: 4
2018.11.07 15:16:49 4: RQUEUE: 3
2018.11.07 15:16:49 4: RQUEUE: 2
2018.11.07 15:16:49 4: RQUEUE: 1
... usw. ...


Bei Bedarf kann ich auch gerne verbose 5 setzten und die Detailmeldung senden.

Betreibe die Modbus-Anbindung jetzt seit einigen Tagen ohne "attr wago serverType Wago" und konnte bis keine Fehler feststellen.
Hier noch ein kurzer Auszug aus meiner WAGO-Config:

# SPS-Ausgang DO2_F, Eltern, Deckenlicht
# fhemDO2_F -> WagoDO2_F
define WagoDO2_F ModbusCoil wago QX256.5
attr WagoDO2_F IODev wago
attr WagoDO2_F alias Deckenlicht
attr WagoDO2_F devStateIcon on:on:toggle off:off:toggle set_.*:toggle
attr WagoDO2_F event-on-change-reading .*
attr WagoDO2_F eventMap toggle:Schalten
attr WagoDO2_F group Eltern
attr WagoDO2_F room Obergeschoss
attr WagoDO2_F sortby 1
attr WagoDO2_F webCmd Schalten
attr WagoDO2_F writeMode Impulse:IX256.5:1.0


Freundliche Grüße
bitvilla
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 07 November 2018, 20:54:47
Hallo,

Danke für die Informationen.

Das Auslesen des SPS-Typs scheint nicht zu funktionieren, kannst du testen ob es mit der angehängten Version geht ?

Wenn das Attribut serverType nicht gesetzt ist, wird die I/O-Konfiguration nicht ausgelesen und die Adressierung der Ein- und Ausgänge ist falsch wenn analoge Ein- oder Ausgänge vorhanden sind. Da du nur digitale I/Os hast, gibt es keine Probleme.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: bitvilla am 08 November 2018, 18:33:59
Hallo ChrisD,

habe die angehängte Datei eingespielt und FHEM neu gestartet.
Anbei die Ausgaben im Logfile mit verbose 4:


2018.11.08 18:15:32 3: WagoMD216: I/O device is wago
2018.11.08 18:15:32 3: WagoMD217: I/O device is wago
2018.11.08 18:15:32 3: WagoMW206: I/O device is wago
2018.11.08 18:15:32 3: WagoMW207: I/O device is wago
2018.11.08 18:15:32 1: Including FHEM/fhem_myConfig_allgemein.cfg
2018.11.08 18:15:33 3: SUSV: using I2C Address 15
2018.11.08 18:15:34 3: SUSV: Found firmware 2.61 - Basic
2018.11.08 18:15:34 1: Including ./log/fhem.save
2018.11.08 18:15:34 3: Opening wago device 192.168.13.240:502
2018.11.08 18:15:34 4: AddRQueue [20 10 00 00 00 06] 00 03 20 10 00 01
2018.11.08 18:15:34 4: AddRQueue [20 11 00 00 00 06] 00 03 20 11 00 01
2018.11.08 18:15:34 4: AddRQueue [20 12 00 00 00 06] 00 03 20 12 00 01
2018.11.08 18:15:34 4: AddRQueue [20 13 00 00 00 06] 00 03 20 13 00 01
2018.11.08 18:15:34 4: AddRQueue [20 14 00 00 00 06] 00 03 20 14 00 01
2018.11.08 18:15:34 4: AddRQueue [10 22 00 00 00 06] 00 03 10 22 00 04
2018.11.08 18:15:34 3: wago device opened
2018.11.08 18:15:34 0: Featurelevel: 5.9
2018.11.08 18:15:34 0: Server started with 176 defined entities (fhem.pl:17652/2018-10-31 perl:5.020002 os:linux user:fhem pid:3546)
2018.11.08 18:15:35 3: telnetForBlockingFn_1541697335: port 32961 opened
2018.11.08 18:15:37 4: RQUEUE: 5
2018.11.08 18:15:37 4: RQUEUE: 4
2018.11.08 18:15:37 4: RQUEUE: 3
2018.11.08 18:15:37 4: RQUEUE: 2
2018.11.08 18:15:38 4: RQUEUE: 1
2018.11.08 18:15:42 4: AddRQueue [FD E8 00 00 00 06] 00 03 30 C8 00 08
2018.11.08 18:15:42 4: AddRQueue [FD E9 00 00 00 06] 00 03 31 90 00 26
2018.11.08 18:15:42 4: AddRQueue [FA 00 00 00 00 06] 00 01 00 20 00 20
2018.11.08 18:15:42 4: AddRQueue [FA 01 00 00 00 06] 00 01 02 28 00 18
2018.11.08 18:15:42 4: AddRQueue [FA 02 00 00 00 06] 00 01 10 00 00 50
2018.11.08 18:15:42 4: AddRQueue [FA 03 00 00 00 06] 00 01 36 40 00 30
2018.11.08 18:15:42 4: RQUEUE: 5
2018.11.08 18:15:42 4: RQUEUE: 4
2018.11.08 18:15:42 4: RQUEUE: 3
2018.11.08 18:15:44 4: RQUEUE: 2
2018.11.08 18:15:44 4: RQUEUE: 1


Die Meldung "ModbusTCPServer_Parse: except (code 2)" erscheint jetzt nicht mehr.
Ein Funktionstest der aktuellen Konfiguration war ebenfalls erfolgreich.

Habe aktuell leider keinen Zugriff bzw. keinen Bedarf für eine analoge Schnittstellenkarte.
Sonst könnte ich anbieten den kompletten Datenaustausch zwischen FHEM und WAGO über analoge Werte zu testen.

Vielen Dank für Deine Entwicklungsarbeit!

Freundliche Grüße
bitvilla
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: bitvilla am 15 Dezember 2018, 15:57:43
Hallo ChrisD,

habe die letzte Version von Modbus_TCPServer (#479) nun seit ca. 5 Wochen erfolgreich im Einsatz.
Wollte mal Fragen ob die Version offiziell eingecheckt wird?
Aktuell überschreibt FHEM die angepasste Datei bei jedem Update.

Freundliche Grüße
bitvilla
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 15 Dezember 2018, 16:24:42
Die Meldung

2018.12.15 15:01:13 2: ModbusTCPServer_Parse: except (code 2)

hab ich auch bei jedem neustart, wäre natürlich schön wenn die weg wäre.
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 15 Dezember 2018, 17:31:13
Hallo,

Ich hatte leider vergessen die Module auf Github zu aktualisieren. Ich habe dies jetzt nachgeholt so dass bei einem Update die aktuelle Version heruntergeladen werden sollte.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: WagoAndreas am 27 Dezember 2018, 21:32:10
Hallo Leute,

DANKE für diesen tollen Beitrag hier. Ohne den ich es nicht geschafft hätte eine Kommunikation zwischen FHEM und meiner 750-841 zu erstellen.
Ich hänge gerade leider ein bisschen. Vielleicht hat jemand einen Tipp für mich? Wahrscheinlich habe ich es mindestens 5x überlesen. Aber ich bekomm es nicht hin.

ich habe ein FHZ1300 über den ich Werte von meinen FS20 Temperaturreglern bekomme. Dies funktioniert einwandfrei. Kommunikation zur WAGO SPS steht auch, wie hier beschrieben. Jedoch schaffe ich es nicht EINEN Temperaturwert in das MW21 z.b. zu schreiben.

Bad ist z.b. so deklariert:
-------
FHT_DachBad
   
19.3 °C
   
FHT_DachBad
Internals
CODE
   
4409
DEF    
4409
FHZ_0_MSGCNT
   
150
FHZ_0_RAWMSG
   
810c04f00909a00144090000b63a
FHZ_0_TIME
   
2018-12-27 21:16:15
IODev
   
FHZ_0
LASTInputDev
   
FHZ_0
MSGCNT
   
150
NAME
   
FHT_DachBad
NR
   
30
STATE
   
measured-temp: 19.3
TYPE
   
FHT
Readings
ack
   
30
   
2018-12-27 21:10:32
actuator
   
8%
   
2018-12-27 21:25:53
battery
   
ok
   
2018-12-27 21:10:31
desired-temp
   
19.0
   
2018-12-27 19:09:13
end-xmit
   
30
   
2018-12-27 20:58:58
lowtemp
   
ok
   
2018-12-27 21:10:31
measured-temp
   
19.3
   
2018-12-27 21:10:31
state
   
measured-temp: 19.3
   
2018-12-27 21:10:31
temperature
   
19.3
   
2018-12-27 21:10:31
warnings
   
none
   
2018-12-27 21:10:31
window
   
closed
   
2018-12-27 21:10:31
windowsensor
   
ok
   
2018-12-27 21:10:31
----------------------------------------------------------

Dann ein Wort als INT was zur zeit ein Slider ist um es halt testen zu können ob werte in die SPS übertragen werden mit folgenden
Attributes

Internals
CFGFN
   
CHANGED
   
DEF    
wago MW21
IODev
   
SPS
LASTInputDev
   
SPS
MSGCNT
   
8641
ModbusRegister_lastRcv
   
2018-12-27 21:28:55
NAME
   
MB_T_RolloAuf
NOTIFYDEV
   
global
NR
   
220
NTFY_ORDER
   
50-MB_T_RolloAuf

IODev
   
SPS
   
deleteattr
event-on-change-reading
   
.*
   
deleteattr
plcDataType
   
INT
   
deleteattr
setList
   
state:slider,10,2,30
   
deleteattr
webCmd
   
state
   
deleteattr

-----------------------------------------------

Derzeit schreibt er brav ins MW21 wenn ich etwas an dem slider spiele. So wie kann ich nun diese zwei Variabeln verbinden???

VIELEN DANK FÜR EURE HILFE!!!!!!!!!!!!!!!!!!!!!!
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 28 Dezember 2018, 08:25:41
Hallo,

Du kannst den Wert vom FHT mit Hilfe von 'notify' weitersenden. Informationen zu 'notify' findest du hier (https://wiki.fhem.de/wiki/Notify).

Zum Übertragen der Ist-Temperatur sollte dies funktionieren:
define n_FHT_DachBad_MW21 notify FHT_DachBad:measured-temp.* set MB_T_RolloAuf $EVTPART1
Hiermit wird die Temperatur ohne Nachkommastelle übertragen.

Wenn die Nachkommastelle auch übertragen werden soll gibt es 2 Möglichkeiten:

- die Temperatur wird vor dem Senden mit 10 multipliziert, im SPS-Programm wird dann aus 19.3 der Wert 193:
attr MB_T_RolloAuf conversion 0.1:0

- der Wert wird als Gleitkommazahl übertragen, dazu muss die Definition von MB_T_RolloAuf geändert werden, z.B.:
defmod MB_T_RolloAuf wago MF200
im SPS-Programm muss die Deklaration der Variable auch angepasst werden:
MB_T_RolloAuf AT %MD200 : REAL;

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: WagoAndreas am 29 Dezember 2018, 14:00:45
VIELEN VIELEN DANK funktioniert wunderbar. So jetzt werd ich noch bissl basteln. DANKE!
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: peter.oehlmann@web.de am 16 Januar 2019, 21:32:43
Hallo ,
ich habe meine Wago an FHEM angebunden , um Werte von Sensoren in die Wago einzulesen und FHEM als Gateway für die Wago zu verwenden. Die Kopplung von einzelnen Bits und Messwerten funktioniert eigentlich tadellos.
Problem : das zyklische Schreiben von dem Reading "brightness" auf das Modbus Register wago MF100. In der Komandozeile kann ich eingeben:

set MF100 1234

und der Wert wird wunderbar in die SPS geschrieben.Dafür habe ich nun das Notify mit folgendem Inhalt angelegt:

Motion_Kota:brightness:.* set MF100 $EVENT

Fehlermeldung im Logfile ist :

MF100_NF return value: Unknown argument brightness:, choose one of off on  on-till-overnight on-for-timer off-till-overnight blink off-till off-for-timer on-till toggle intervals

Das Format des Wertes in Reading passt aus meiner Sicht und da ich ja mit der Kommandozeile den Wert schreiben kann,
beweist , dass es geht.
Ich probiere seit Tagen verschiedene Varianten aus und lese Anleitungen , aber das Notify will nicht funktionieren.
Ich hoffe, ihr seid so nett und könnt mir helfen. Der Zeitaufwand vom ersten Gedanken das Gateway FHEM zu nutzen
und alles durch Anlesen zu erlernen ist schon recht hoch. Das hätte ich nicht gedacht. Eine Beschreibung über Modbus
und die Definitionen , die sich aus "wago" ergeben kann ich auch nicht finden. Man muss immer das ganze Forum durchstöbern.
Gibt es da etwas?

Gruß

Peter
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 16 Januar 2019, 21:52:03
Hallo,

Dies ist kein Modbus oder Wago-Problem sondern ein Problem mit deinem notify. $EVENT enthält das gesamte Ereignis, in deinem Fall z.B.
brightness: 160

Damit führt das notify folgenden Befehl aus
set MF100 brightness: 160
was natürlich nicht funktioniert.

In deinem Fall dürfte dies dagegen funktionieren:
Motion_Kota:brightness:.* set MF100 $EVTPART1

Weitere Details zum notify findest du sowohl in der Commandref als auch im Wiki.

ZitatEine Beschreibung über Modbus und die Definitionen , die sich aus "wago" ergeben kann ich auch nicht finden.
Wenn du 'wago' verwendest kannst du die gleichen Adressen wie im Koppler verwenden. Das Modul sorgt intern dafür dass die richtigen Parameter für Modbus-Adresse, Datenlänge und Datentyp gesetzt werden.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: peter.oehlmann@web.de am 16 Januar 2019, 22:39:43
Erstmal vielen Dank,
ich habe $EVTPART1 gerade eingetragen und es kam ein Wert vom Sensor , dann hat es funktioniert.
$EVTPART1 hatte ich vorher schon ohne Erfolg getestet , da kam aber kein echter Wert vom Sensor,
sondern ich habe mit "trigger MF100_NF" das Notify getriggert. Wenn ich das jetzt wieder mache,
passiert wieder nichts. Ist ja eine nützliche Funktion das Triggern , aber wie macht man es richtig?
Jetzt muss ich bis morgen warten , bis der Sensor wieder hell sieht , um sicher zu gehen , dass es
geht.

Gruß

Peter
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 16 Januar 2019, 22:48:56
Hallo,

Du solltest nicht das notify triggern sondern den Auslöser, also z.B.
trigger Motion_Kota brightness: 160

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 13 März 2019, 18:23:28
Hallo ChrisD,
lange war es wieder still - das liegt daran, dass Dein Modbus/Wago Modul absolut störungsfrei arbeitet und keinerlei Probleme auftreten.
Nochmal ein Dickes Lob von mir..!

Ich versuche gerade meine FB_Dim zu erweitern, ich hoffe Du erinnerst Dich das Du mir hiermit so toll geholfen hast.
Weil der Dimmer ja grundsätzlich zu schnell war haben wir noch einen "DimTakt" eingebaut um den Dimmer so zu verlangsamen.

Auch das funktioniert ausgezeichnet. Nun bin ich aber endlich soweit das per Taster die Lautstärke meiner Sonos Speaker angepasst werden soll. Auch hierzu benutze ich den FB_Dim - es funktioniert auch alles wie es soll, nur bei der Lautstärke regelbar von 0-65 fällt auf das der Baustein immernoch zu schnell ist.

Nun habe ich gedacht ich füge den DimTakt als Eingangsvariable hinzu um den Dimmer bei den Sonos Speakern weeiter zu entschleuningen. Wenn ich aber in der Baustein deklaration bei VAR Input Date Time hinzuschreibe wird kein weiterer Eingang des Bausteines erzeugt, ein anderer Eingang des FBs - (VAR_IN_OUT) Lightlevel verschwindet dann. Ich kann es mir nicht erklären...

Den Dimtakt und die Limits würde ich nun gerne noch als Eingänge haben um den Baustein so auch für Sonos nutzen zu können..

Kannst Du helfen? Hab den Baustein an diesen Post angehangen...

Danke im vorraus!



Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 14 März 2019, 21:28:39
Hallo,

Wenn ich die Deklaration von DimTakt nach VAR_INPUT verschiebe werden im Kontaktplan alle Instanzen von FB_Dim um einen zusätzlichen Eingang erweitert.

Was passiert wenn du eine neue Instanz hinzufügst, fehlen dann auch die Eingänge ?

Lässt sich das Projekt noch kompilieren ?

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 16 März 2019, 09:48:24
Danke ChrisD,
keine ahnung was das war - wahrscheinlich hatte sich Codesys irgendwie aufgehangen...
Jetzt hat es funktioniert...
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: WagoAndreas am 22 Juni 2019, 20:56:35
Hallo Leute, Hallo ChrisD,
ich mach mal wieder mit meiner WAGO FHEM Geschichte weiter und hänge nun an den Fensterkontakte. Diese werden, wie man ja in meinem oberen Beitrag sehen kann, nur als open oder closed übergeben. (1 oder 0 wäre wahrscheinlich einfacher)
wie kann ich denn das open oder closed übertragen? Wie wäre mir egal. Entweder ich übertrage open und closed an die SPS und ändere mir das dort in 1 oder 0
oder ich Konvertiere das in FHEM in 1 oder 0 und übertrage es dann an die SPS. Wie es halt einfacher geht.

VIELEN VIELEN DANK FÜR DIE HILFE!!
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 23 Juni 2019, 09:48:22
Guten Morgen Andreas,
im Codesys - unter Ressourcen, Steuerungskonfiguration kannst Du ja festlegen wie die Eingänge innerhalb des SPS Programmes heissen sollen. Hier steht auch die Adresse der Eingangsklemme im Modbus.

Auf diese kannst DU einfach in FHEM lauschen - in meinem Fall liegt der Haustuerkontakt auf %IX13.12

defmod HaustuerGeschlossen ModbusCoil wago IX13.12
attr HaustuerGeschlossen DbLogExclude .*
attr HaustuerGeschlossen IODev WagoController
attr HaustuerGeschlossen event-on-change-reading .*
attr HaustuerGeschlossen group Eingänge
attr HaustuerGeschlossen room 14-Haustuer
attr HaustuerGeschlossen webCmd :
 

Ich hoffe das hilft Dir.

Innerhalb von FHEM kannst Du dann auf open/closed mappen ohne klimmzüge in Codesys zu machen und ohne mehr als ein bit zu belegen.
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 23 Juni 2019, 12:19:20
Hallo,

Du kannst den Zustand des Fenster über ein notify übertragen.

Zuerst benötigst du ein Coil, z.B.:
define mbcFHT_DachBad_Window ModbusCoil wago MX300.0
attr mbcFHT_DachBad_Window event-on-change-reading .*


Anschließend kannst du mit folgendem notify die Fensterstellung übertragen:
define nFHT_DachBad_Window notify FHT_DachBad:window.* { fhem "set mbcFHT_DachBad_Window ".($EVTPART1 eq "closed"?"off":"on")}

Aus 'closed' wird 0, alles andere wird zu '1'.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: WagoAndreas am 23 Juni 2019, 12:20:58
Hallo Lolo,

mhm aber es is ja genau andersherum. Ich möchte ja vom FHT (Conrad System) die Info OPEN oder CLOSED in der SPS haben.
Wie ich meine Temperaturen in die SPS bekommen hat ja Chris oben schon beschrieben - was auch Super funktioniert.
nun ist eigentlich die Frage wie ich die Info der Fensterkontakte elegant in die SPS bekomme.

meine Hauptsteuerung soll die SPS bleiben und das FHEM quasi die Informationen liefern.
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: WagoAndreas am 23 Juni 2019, 12:21:46
DANKE ich werde es später ausprobieren :-) DANKE!!
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: WagoAndreas am 23 Juni 2019, 13:26:03
Hallo Chris,

er setzt das closed nicht um in 0. Wenn ich es manuel als zu setzte geht es.
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 23 Juni 2019, 13:32:05
Ja, Asche auf mein Haupt - ich sollte besser lesen bevor ich antworte...
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: WagoAndreas am 23 Juni 2019, 13:37:47
Ach warum :-) geht mir auch oft so :-) Is ja jetzt nix warum die Welt unter geht.
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: WagoAndreas am 23 Juni 2019, 13:39:19
Funktioniert ja jetzt fast. FHEM checkt noch nicht das closed (hab extra geschaut wird klein geschrieben) auf off gesetzt wird.
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: WagoAndreas am 23 Juni 2019, 14:20:01
Ich hab noch was rausgefunden. Jedes neue Telegramm auch wenn wiederholt closed drinnen steht erkennt er nicht als closed und setzt mir den Merker auf 1. Ich denke fhem erkennt closed nicht als closed und setzt es daher immer auf 1?
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 23 Juni 2019, 16:57:27
Hallo,

Was steht im Event-Monitor wenn 'closed' kommt ?

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: WagoAndreas am 23 Juni 2019, 17:18:59
2019-06-23 17:12:47 ModbusRegister MD201 23.6000003814697
2019-06-23 17:12:47 ModbusRegister MD201 RAW: cccd41bc
2019-06-23 17:12:47 ModbusRegister MR_MW21 200
2019-06-23 17:12:47 ModbusRegister MR_MW21 RAW: 00c8
2019-06-23 17:12:47 ModbusRegister MD200 23.7999992370605
2019-06-23 17:12:47 ModbusRegister MD200 RAW: 666641be
2019-06-23 17:12:47 ModbusRegister MD201 23.6000003814697
2019-06-23 17:12:47 ModbusRegister MD201 RAW: cccd41bc
2019-06-23 17:12:47 ModbusRegister MR_MW21 200
2019-06-23 17:12:47 ModbusRegister MR_MW21 RAW: 00c8
2019-06-23 17:12:48 ModbusRegister MD200 23.7999992370605
2019-06-23 17:12:48 ModbusRegister MD200 RAW: 666641be
2019-06-23 17:12:48 ModbusRegister MD201 23.6000003814697
2019-06-23 17:12:48 ModbusRegister MD201 RAW: cccd41bc
2019-06-23 17:12:48 ModbusRegister MR_MW21 200
2019-06-23 17:12:48 ModbusRegister MR_MW21 RAW: 00c8
2019-06-23 17:12:48 ModbusRegister MD200 23.7999992370605
2019-06-23 17:12:48 ModbusRegister MD200 RAW: 666641be
2019-06-23 17:12:48 ModbusRegister MD201 23.6000003814697
2019-06-23 17:12:48 ModbusRegister MD201 RAW: cccd41bc
2019-06-23 17:12:48 ModbusRegister MR_MW21 200
2019-06-23 17:12:48 ModbusRegister MR_MW21 RAW: 00c8
2019-06-23 17:12:49 FHT FHT_Dachgeschoss actuator: 0%
2019-06-23 17:12:49 ModbusRegister MD200 23.7999992370605
2019-06-23 17:12:49 ModbusRegister MD200 RAW: 666641be
2019-06-23 17:12:49 ModbusRegister MD201 23.6000003814697
2019-06-23 17:12:49 ModbusRegister MD201 RAW: cccd41bc
2019-06-23 17:12:49 ModbusRegister MR_MW21 200
2019-06-23 17:12:49 ModbusRegister MR_MW21 RAW: 00c8
2019-06-23 17:12:49 ModbusRegister MD200 23.7999992370605
2019-06-23 17:12:49 ModbusRegister MD200 RAW: 666641be
2019-06-23 17:12:49 ModbusRegister MD201 23.6000003814697
2019-06-23 17:12:49 ModbusRegister MD201 RAW: cccd41bc
2019-06-23 17:12:49 FHT FHT_Dachgeschoss desired-temp: 23.0
2019-06-23 17:12:49 ModbusRegister MR_MW21 200
2019-06-23 17:12:49 ModbusRegister MR_MW21 RAW: 00c8
2019-06-23 17:12:50 FHT FHT_Dachgeschoss ack: 30
2019-06-23 17:12:50 ModbusRegister MD200 23.7999992370605
2019-06-23 17:12:50 ModbusRegister MD200 RAW: 666641be
2019-06-23 17:12:50 ModbusRegister MD201 23.6000003814697
2019-06-23 17:12:50 ModbusRegister MD201 RAW: cccd41bc
2019-06-23 17:12:50 ModbusRegister MR_MW21 200
2019-06-23 17:12:50 ModbusRegister MR_MW21 RAW: 00c8
2019-06-23 17:12:50 ModbusCoil mbcFHT_Dachgeschoss_Window set_off
2019-06-23 17:12:50 ModbusCoil mbcFHT_Dachgeschoss_Window set_on
2019-06-23 17:12:50 FHT FHT_Dachgeschoss battery: ok
2019-06-23 17:12:50 FHT FHT_Dachgeschoss batteryState: ok
2019-06-23 17:12:50 FHT FHT_Dachgeschoss lowtemp: ok
2019-06-23 17:12:50 FHT FHT_Dachgeschoss window: closed
2019-06-23 17:12:50 FHT FHT_Dachgeschoss windowsensor: ok
2019-06-23 17:12:50 FHT FHT_Dachgeschoss warnings: none
2019-06-23 17:12:50 ModbusCoil mbcFHT_Dachgeschoss_Window off
2019-06-23 17:12:50 ModbusCoil mbcFHT_Dachgeschoss_Window on
2019-06-23 17:12:50 ModbusRegister MD200 23.7999992370605
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: WagoAndreas am 23 Juni 2019, 17:20:56
richtig
2019-06-23 17:12:50 ModbusRegister MR_MW21 RAW: 00c8
2019-06-23 17:12:50 ModbusCoil mbcFHT_Dachgeschoss_Window set_off
2019-06-23 17:12:50 ModbusCoil mbcFHT_Dachgeschoss_Window set_on
2019-06-23 17:12:50 FHT FHT_Dachgeschoss battery: ok
2019-06-23 17:12:50 FHT FHT_Dachgeschoss batteryState: ok
2019-06-23 17:12:50 FHT FHT_Dachgeschoss lowtemp: ok
2019-06-23 17:12:50 FHT FHT_Dachgeschoss window: closed
2019-06-23 17:12:50 FHT FHT_Dachgeschoss windowsensor: ok
2019-06-23 17:12:50 FHT FHT_Dachgeschoss warnings: none
2019-06-23 17:12:50 ModbusCoil mbcFHT_Dachgeschoss_Window off
2019-06-23 17:12:50 ModbusCoil mbcFHT_Dachgeschoss_Window on
2019-06-23 17:12:50 ModbusRegister MD200 23.7999992370605
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 23 Juni 2019, 18:03:58
Hallo,

Das Problem kommt wahrscheinlich vom windowsensor, dieser passt auch auf das notify.

Wenn du im notify hinter window einen Doppelpunkt hinzufügst sollte es funktionieren:

define nFHT_Dachgeschoss_Window notify FHT_Dachgeschoss:window:.* { fhem "set mbcFHT_Dachgeschoss_Window ".($EVTPART1 eq "closed"?"off":"on")}

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: WagoAndreas am 23 Juni 2019, 19:16:01
Funktioniert 1A. Vielen Dank!!
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: Hollo am 24 Juni 2019, 12:46:36
Zitat von: Hollo am 17 August 2018, 09:09:00
DitoGetestet und für gut befunden; habe aktuell nur ein "Digital Out"-Modul dran, aber das funktioniert einwandfrei.
Digitale Eingänge und Analog-Module folgen in Kürze.
Da "in Kürze" schon bald 1 Jahr her ist  :-[ , wolte ich mal kurz ein Update geben.
Seit letztem Wochenende habe ich ein Analog-Eingangsmodul für RTD-Sensoren inkl. 3 PT100-Sensoren am Buskoppler in Betrieb.
Werte kommen korrekt in FHEM an und werden per Userreading (inkl. Anpassung Dezimalstelle und Einheit) an das passende Device gehängt.

Ich bin begeistert.  8)
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: nicom2 am 04 September 2019, 12:39:51
Hallo liebe Forengemeinde,

da man mir ans Herz gelegt hat diese Frage lieber hier anzubringen, hänge ich mich mal an dieses Thema dran, ich hoffe das ist in Ordnung. ;-)

Mein Name ist Lucas und ich nutze seit einigen Jahren problemlos FHEM zur Steuerung meiner Wago SPS (750-841). :-)
Nun ist eine zweite und dritte Wago (750-841 und 750-852) dazugekommen und mir ist eine Merkwürdigkeit bei der Verwendung der ModbusCoils aufgefallen.

Ich habe die 3 Wagos problemlos einbinden können, das Setzten von Ausgängen (Über Merkeradressen) funktioniert auch problemlos auf allen 3 Wagos.
Das lesen von Input's verhält sich allerdings komisch:

Obwohl die IODev Zuordnung bei den Eingängen (auch bei Ausgängen, aber dort scheint es trotzdem "normal" zu funktionieren) korrekt ist, werden wenn die Adressen der Wagos identisch sind, beide (oder gar alle drei) Devices bei den Internals angezeigt. (Siehe Screenshots im Angang)

Wenn nun auf einer beliebigen Wago einer dieser Eingänge geschlossen wird, wird dies sofort in FHEM angezeigt - und zwar auch nur bei dem korrekten Eingang.
Sobald der Kontakt wieder geöffnet wird dauert es teilweise eine Minute (mal mehr, mal weniger) bis die Änderung in Fhem dargestellt wird.
Wenn eine Adresse nur auf einer Wago verwendet wird kommen die Änderungen sofort.

Das Problem tritt nur bei ModbusCoils auf. Bei ModbusRegister wird auch bei gleichen Adressen immer nur das korrekte Device in den Internals angezeigt.

Für die Ausgänge könnte ich nun ja als Workaround einfach unterschiedliche Merkeradressen verwenden, dann wäre die Darstellung korrekt.
Für die Input-Register müsste ich aber alles auf Merkeradressen "ummappen", was zwar das Problem lösen könnte, aber den "Fehler"(?!?) nicht beseitigen würde. ;-)

Hat jemand eine Idee, warum es bei den Registern keine Probleme bei gleichen Adressen, jedoch bei Coils diese "zusätzlichen" Devices angezeigt werden?

Vielen Dank für eure Hilfe!

Gruß von der Mosel,

Lucas Nicolay
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: Wzut am 04 September 2019, 12:43:44
Tipp : Entwickler hassen Screenshots, lieben dafür aber Device lists :)
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 04 September 2019, 21:38:26
Hallo,

Ich kann das Problem reproduzieren, ich muss mir aber überlegen wie ich es beheben kann.

Kannst du mir ein 'list' von Wago2OG, WagoGenerator und WagoEG09 schicken ?

Grüße,

ChrisD


Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: nicom2 am 05 September 2019, 11:39:07
Hallo ChrisD,

vielen Dank für Deine Antwort.
Ich habe Dir die Lists per eMail gesendet.

Zur Info:
Das Problem betrifft übrigens wohl (doch) auch die Ausgänge.
Wenn ein Ausgang durch FHEM ein- oder ausgeschaltet wird, klappt alles reibungslos.
Wenn die SPS einen Ausgang einschaltet, wird die Änderung auch direkt angezeigt.
Beim Ausschalten verhält es sich analog zu den Eingängen mit der entsprechenden Verzögerung.
Betroffen sind auch nur Ausgänge, deren Adressen auf mehrern Wagos verwendet werden.
Die entsprechenden Lists habe ich mitgesendet.

Wenn weitere Informationen benötigt werden, oder ich mich sonst noch irgendwie einbringen kann, geb' bitte kurz bescheid!

Danke!

Gruß,
Lucas
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 06 September 2019, 21:11:49
Hallo,

Ich habe etwas am Server-Modul geändert, kannst du testen ob die neue Version (0023) das Problem löst ?

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: nicom2 am 06 September 2019, 21:49:10
Guten Abend!

Ich habe das Modul gerade aktualisiert...
Was soll ich sagen... Ich freue mich gerade wie ein kleines Kind zu Weihnachten! :-)

Die "zusätzlichen" Einträge in den Device-Lists sind verschwunden und die Aktualisierung der Ein- und Ausgänge klappt jetzt einwandfrei über alle drei Wagos hinweg! :-D

Genial! Wirklich vielen, vielen Dank!
Wenn ich mich irgendwie erkenntlich zeigen kann, schick mir eine PM!

Wünsche noch einen schönen Abend!

Gruß,
Lucas
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 07 September 2019, 08:20:30
Hallo ChrisD,
ein update lief heute morgen bei mir nicht fehlerfrei durch...

2019.09.07 08:17:05 1 : modbus
2019.09.07 08:17:06 1 : UPD FHEM/36_ModbusTCPServer.pm
2019.09.07 08:17:07 1 : Got 510 bytes for FHEM/36_ModbusTCPServer.pm, expected 49003
2019.09.07 08:17:07 1 : aborting.


Vielleicht habe aber ja nur ich ein Problem...
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: monty_burns_007 am 08 September 2019, 11:26:43
habe auch eine fehler update meldung:

2019.09.08 11:20:52 1 : modbustcp
2019.09.08 11:20:52 1 : UPD FHEM/36_ModbusTCPServer.pm
<div class='fhemlog'>2019.09.08 11:20:52 1 : Got 49027 bytes for FHEM/36_ModbusTCPServer.pm, expected 49003</div><div class='fhemlog'>2019.09.08 11:20:52 1 : aborting.</div>2019-09-08 11:20:52 Global global UPDATE
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: bitvilla am 08 September 2019, 13:56:06
Hallo zusammen,

kann den Fehler ebenfalls bestätigen. Update von 36_ModbusTCPServer.pm wurde heute morgen abgebrochen mit der Meldung:

...
UPD FHEM/36_ModbusTCPServer.pm
Got 49027 bytes for FHEM/36_ModbusTCPServer.pm, expected 49003
...


Grüße
bitvilla
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 08 September 2019, 16:33:07
Hallo,

Ich habe den Fehler in der Konfigurationsdatei behoben, das Update sollte jetzt funktionieren.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 09 September 2019, 18:19:22
Danke ChrisD, das Update funktionierte nun einwandfrei -
und ich habe einen tollen nebeneffekt - mein permanenter RAM anstieg ist weg, kann es mit deinen änderungen zusammenhängen..?

https://forum.fhem.de/index.php/topic,84372.msg973250.html#msg973250
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 09 September 2019, 20:32:23
Hallo,

Die Änderung sollte keinen Einfluss auf den Speicherverbrauch haben, sie sorgt nur dafür dass FHEM nicht fälschlicherweise Pakete als Duplikate erkennt und verwirft.

Du könntest aber testen ob der Speicherverbrauch mit der vorherigen Version wieder zunimmt.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 06 Juni 2020, 09:45:15
Guten Morgen ChrisD,
ich hab mal wieder was - an meiner Haustür habe ich einen Induktiven Sensor der erfasst wenn die Tür geschlossen ist, und einen weiteren im Rahmen der erfasst wenn die Tür verriegelt ist. Ich hielt es für eine gute Idee:

Den Sensor der verriegelt meldet zu benutzen um den Sensor der geschlossen meldet als "anzeige" der scharf schaltung meiner selfmade Alarmanlage zu nutzen. Wenn der Verriegelt Sensor geschlossen ist schalte ich also die 24V des geschlossen Sensors 2sekunden weg und 150ms wieder an - somit blinkt die LED des geschlossen Sensors. Problem ist nun das FHEM trotz meiner versuche es zu verhindern alle etwa 4 sekunden den Impuls des geschlossen Sensors erwischt, im Eventmonitor anzeigt und auch im FHEMWEB visualisiert. Ich habe schon versucht das ganze anders zu verknüpfen um zu verhindern das der kurze Impuls zum blinken zu FHEM durchgereicht wird - bekomme es aber nicht hin. Hast DU vielleicht eine Idee wie ich das lösen könnte?


Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: sukram am 06 Juni 2020, 09:54:36
Hallo,

wenn ich dich richtig verstehe, hat die "verriegelt" Meldung Vorrang gegen den "Geschlossen" Sensor. Würde dir eine elektronische Lösung reichen? Dann brauchst du nur 2 Dioden an den DigitalIn Klemmen. In die Leitung vom "geschlossen" Sensor eine Diode zum Input, damit der Sensor nicht rückwärts bestromt wird. Und dann eine Diode vom "verriegelt" Sensor Ausgang zum Input "geschlossen".

Damit sendet der "verriegelt" Sensor immer das "geschlossen" Signal mit.

Eine Skizze kann ich bei Bedarf machen, bin nur grad unterwegs.

MfG
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 06 Juni 2020, 11:42:20
Hallo Sukram - danke für Deine antwort und das mitdenken.
Eigentlich bin ich zufrieden wie es ist.

Die Led des Sensors "geschlossen" leuchtet dauerhaft wenn die Tür geschlossen ist.
Die Led des Sensors "geschlossen" leuchtet nicht wenn die Tür geöffnet ist.
Die Led des Sensors "geschlossen" blinkt wenn die Tür verriegelt ist und die Alarmanlage scharf geschaltet ist.

Problem ist eigentlich nur das auch FHEM dieses blinken auffängt, vielleicht ist es übertrieben - aber ich dachte es wäre besser diese "Eventlast" aus FHEM rauszuhalten...


Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: sukram am 06 Juni 2020, 12:01:01
Eine andere Variante wäre das Hochsetzen des Parameter updateInterval nur für diesen Eingang.

Das habe ich bei einem Analogeingang so gelöst, dass der Wert nur alle 30 Sekunden aktualisiert wird (um das Log zu entlasten).
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 06 Juni 2020, 12:18:18
Das klingt schon eher nach einer Lösung - schau ich mir an, Danke Dir...
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: sukram am 22 Dezember 2020, 00:39:59
Gutten Abend,

Ich muss leider das Thema mit mehreren Wagos noch mal hochholen. Ich habe derzeit 2x 750-342 Koppler im Einsatz und dabei seit kurzem ein seltsames Phänomen entdeckt. Kurz: ModbusCoil Schaltzustände von DO (QX) werden nur beim ersten Modbus Gerät richtig wieder zurückgelesen.

An dem ersten Koppler hängen derzeit nur 8x DI und 4x DO, damit werden Türen und der Gaszähler abgefragt sowie ein Pumpenrelais geschaltet. Das funktioniert soweit, wenn ich die ModbusCoil auf on schalte bleibt der Zustand on.

An dem zweiten Koppler hängt ein ganzes Sammelsurium an Karten (28DO, 38 DI, 2 AO, 4 AI). Die Analogkarten mit ModbusRegister klappen sauber, die Inputs auch (auch wenn die Zählweise der QX-Adressen irritierend anders ist als im Handbuch - der Offset durch Analogkarten "fehlt"). Wenn ich nun einen DO anlege:

define wago02_QX0_0 ModbusCoil wago QX0.0
attr wago02_QX0_0 IODev wago_02
attr wago02_QX0_0 alias LED00
attr wago02_QX0_0 event-on-change-reading .*
attr wago02_QX0_0 room Wago


Dann kann ich den zwar auf on setzen, der Ausgang wird auch aktiviert, aber state hüpft sofort wieder auf off zurück.

Zwischendurch der Hinweis: die Analogkarten waren bisher an der ersten Wago angebaut, dort hat die Adressierung aber auch funktioniert.

Zum Vergleich auch das list zweier Ausgänge. Der Funktioniert:
Internals:
   DEF        wago QX0.0
   FUUID      5fdd21ea-f33f-64c3-c334-af686b68dc32b481
   IODev      wago_01
   LASTInputDev wago_01
   MSGCNT     217780
   ModbusCoil_lastRcv 2020-12-22 00:27:59
   NAME       wago01_QX0_0
   NR         130
   NTFY_ORDER 50-wago01_QX0_0
   STATE      off
   TYPE       ModbusCoil
   lastUpdate Tue Dec 22 00:27:58 2020
   nextUpdate Tue Dec 22 00:27:59 2020
   wago_01_MSGCNT 217780
   wago_01_TIME 2020-12-22 00:27:59
   READINGS:
     2020-12-22 00:27:59   state           off
   helper:
     addr       1 0 512
     address    512
     disableRegisterMapping 1
     lastUpdate 0
     nextUpdate 1608593279.36165
     nread      8
     readCmd    
     register   512
     registerType 1
     unitId     0
     updateIntervall 0.1
     wago       1
     wagoDOOffset 0
     wagoT      Q
Attributes:
   DbLogExclude .*
   IODev      wago_01
   alias      Zirkulationspumpe
   event-on-change-reading .*
   icon       sani_pump
   room       Heizung,Wago


und der nicht:
Internals:
   DEF        wago QX0.0
   FUUID      5fdd4141-f33f-64c3-659b-f794418a96ad37df
   IODev      wago_02
   LASTInputDev wago_02
   MSGCNT     143812
   ModbusCoil_lastRcv 2020-12-22 00:28:42
   NAME       wago02_QX0_0
   NR         166
   NTFY_ORDER 50-wago02_QX0_0
   STATE      off
   TYPE       ModbusCoil
   lastUpdate Tue Dec 22 00:28:42 2020
   nextUpdate Tue Dec 22 00:28:42 2020
   wago_02_MSGCNT 143812
   wago_02_TIME 2020-12-22 00:28:42
   READINGS:
     2020-12-22 00:28:42   state           off
   helper:
     addr       1 0 512
     address    512
     disableRegisterMapping 1
     lastUpdate 0
     nextUpdate 1608593322.76173
     nread      8
     readCmd    
     register   512
     registerType 1
     unitId     0
     updateIntervall 0.1
     wago       1
     wagoDOOffset 0
     wagoT      Q
Attributes:
   IODev      wago_02
   alias      LED00
   event-on-change-reading .*
   room       Wago
   verbose    0


Die beiden ModbusTCPServer sind auch praktisch identisch angelegt:
define wago_01 ModbusTCPServer 10.102.1.211
attr wago_01 DbLogExclude .*
attr wago_01 combineReads 10:20
attr wago_01 pollInterval 0.4
attr wago_01 presenceLink wago01_presence
attr wago_01 room Wago
attr wago_01 serverType Wago

define wago_02 ModbusTCPServer 10.102.1.212
attr wago_02 DbLogExclude .*
attr wago_02 combineReads 10:48
attr wago_02 pollInterval 0.4
attr wago_02 presenceLink wago02_presence
attr wago_02 room Wago
attr wago_02 serverType Wago


Passend dazu auch der ausführliche List:
Internals:
   DEF        10.102.1.212
   DeviceName 10.102.1.212:502
   FD         14
   FUUID      5f26df9a-f33f-64c3-7a6b-51dbfed69d7af17a
   NAME       wago_02
   NOTIFYDEV  global
   NR         101
   NTFY_ORDER 50-wago_02
   PARTIAL   
   STATE      ok
   TYPE       ModbusTCPServer
   server     Wago 750-342
   statistics 433363 / 433363 / 5165662 / 5200356
   READINGS:
     2020-12-20 17:33:59   state           opened
   helper:
     delayNextRead 0
     delayNextWrite 0
     fc         1
     hd_tr_id   64433
     hd_unit_id 0
     lastFrame  SimpleWrite [FB B1 00 00 00 06] 00 01 01 E0 00 10
     lastSimpleWrite ���
     last_fc    1
     last_hd_tr_id 64432
     presence   wago02_presence
     seq        65182
     seqCoils   64434
     state      idle
     Wago:
       AI         4
       AO         2
       DI         38
       DIOffset   64
       DO         28
       DOOffset   32
       INFO_ITEM  342
       INFO_MAJOR 255
       INFO_MINOR 255
       INFO_REVISION 19
       INFO_SERIES 750
       initDone   1
       x          1
     combineReads:
       cfg:
         maxSize    48
         maxSpace   10
       coils:
         ARRAY(0x556e3427ab48)
         ARRAY(0x556e3367f580)
         ARRAY(0x556e342377f0)
         ARRAY(0x556e342b7930)
         ARRAY(0x556e34144e68)
         ARRAY(0x556e341d5a28)
         ARRAY(0x556e33b130b8)
         ARRAY(0x556e33b4c6a0)
         ARRAY(0x556e3414f2e0)
         ARRAY(0x556e340b26e0)
         ARRAY(0x556e2f0bdfe0)
         ARRAY(0x556e33861d60)
         ARRAY(0x556e342c6620)
         ARRAY(0x556e340b2f98)
         ARRAY(0x556e33cb1438)
         ARRAY(0x556e32f25a38)
         ARRAY(0x556e2f0be418)
         ARRAY(0x556e342c65a8)
         ARRAY(0x556e3442ea28)
         ARRAY(0x556e342151a0)
         ARRAY(0x556e33cf0280)
         ARRAY(0x556e342c6980)
         ARRAY(0x556e340c2658)
         ARRAY(0x556e32e9a498)
         ARRAY(0x556e32fd22d0)
         ARRAY(0x556e34439118)
         ARRAY(0x556e33d2f330)
         ARRAY(0x556e33b10730)
         ARRAY(0x556e33b7a130)
         ARRAY(0x556e33ce6890)
       data:
         64058:
           0
           1
           0
           16
         64314:
           0
           1
           0
           16
         65082:
           0
           3
           512
           1
         65338:
           0
           3
           512
           1
       registers:
         ARRAY(0x556e3406d618)
     statistics:
       bytesIn    5165662
       bytesOut   5200356
       pktIn      433363
       pktOut     433363
Attributes:
   DbLogExclude .*
   combineReads 10:48
   pollInterval 0.4
   presenceLink wago02_presence
   room       Wago
   serverType Wago


Was kann man da tun?

Und wenn wir das behoben haben, komme ich mit noch was obskurerem um die Ecke: einen Wago 750-815 Modbus Controller, der über RTU angefahren wird ;D Da kann ich nicht mit ModbusCoil auf die Merker Adressen (ab 12288) zugreifen. Aber das ist scheinbar auch nicht vorgesehen - zumindest steht kein Wort davon im Handbuch zu dem alten Teil...
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 22 Dezember 2020, 23:02:06
Hallo,

Die Konfiguration und Adressen sehen richtig aus. Der 1. digitale Ausgang wird immer über Adresse 512 angesprochen, unabhängig davon wie viele AO vorhanden sind. Da der Ausgang schaltet ist die Adresse richtig. Bleibt der Ausgang geschaltet auch wenn FHEM 'off' anzeigt ?

Welche Version des ModbusTCPServer-Modules hast du ?

Du könntest noch versuchen den DOOffset auf 0 zu setzen
{$defs{wago_02}->{helper}{Wago}{DOOffset}=0}
und dann noch mal zu schreiben.

Dies ist aber nur provisorisch da der Wert bei einem neuen Verbindungsaufbau zur SPS wieder überschrieben wird.

Grüße,

ChrisD



Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: sukram am 22 Dezember 2020, 23:24:43
Hallo,

danke für deine Tips. Der Ausgang selbst bleibt an, es wird nur der state falsch zurückgelesen (steht kurz auf on und springt im nächsten Lesezyklus wieder auf off) womit z.B. die toggle SetExtension nicht funktioniert.

Versionen:
98_Modbus.pm               20182 2019-09-17 12:53:40Z StefanStrobel
98_ModbusAttr.pm           19133 2019-04-06 18:40:30Z StefanStrobel
37_ModbusCoil.pm              14 2017-01-14 16:46:00Z ChrisD
37_ModbusRegister.pm          24 2018-02-06 21:22:00Z CD
36_ModbusTCPServer.pm         23 2019-09-06 21:05:00Z CD


Die Installation ist weitestgehend ,,offiziell" (keine neueren Versionen seitwärts eingepasst), das letzte Update lief am letzten Samstag. Ich könnte noch probeweise die Koppler untereinander tauschen, aber eigentlich habe ich beide auf die aktuellste Firmware (v19) gebracht und auch mit dem Ethernet Settings Tool müssten beide gleich eingestellt sein.
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 23 Dezember 2020, 09:36:14
Hallo,

Setze bitte DOOffset auf 0, damit sollte das Lesen funktionieren. Das Problem kommt durch den Versuch dies zu integrieren:

Zitat(auch wenn die Zählweise der QX-Adressen irritierend anders ist als im Handbuch - der Offset durch Analogkarten "fehlt")

Leider werden dabei die Adressen falsch berechnet. Ich werde diesen Punkt nochmal überarbeiten, das wird aber dazu führen dass die Adressen angepasst werden müssen, aus QX0.0 wird dann bei dir z.B. QX28.0.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: sukram am 29 Dezember 2020, 11:55:02
Hallo Chris,

jetzt nach den Feiertagen habe ich mal Zeit  ;D Also dein Perl-Schnippsel führt zum erwarteten Ergebnis. Die vorhandenen ModbusCoil Instanzen behalten den state richtig.

Das hilft mir erstmal, danke!

Mittelfristig ändert sich da sowieso noch einiges - das Abfragen von Tastern ist ziemlich träge (trotz 0.4 Sek Zyklus) bzw fühlt sich komisch an. Deshalb kommen die 2 Gira SPS Tastsensoren direkt an den 815er Controller, der die Rollos steuert.
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: WagoAndreas am 02 Januar 2021, 20:48:25
Hey Leute. Erstmal ein gutes neues :-)
Naja zwischen den Jahren hat man ja bissl Zeit zum Bastln.

Ich hätte mal wieder eine Frage.
Ich habe PUSHNOTIFIER installiert. Läuft auch alles wunderbar.
Ich kann Puhsnachrichten verschicken usw. Also wenn z.b. In der Heizung die Temperatur zu geringt ist, dann wird das nicht nur an das Panel der SPS übergeben, sondern auch an FHEM und dann eben an einen Pushdienst
Ich hab das Ähnlich aufgebaut:

define mbcALARM1X15 ModbusCoil wago MX351.15
hier frage ich das MX351.15 ab. Das ist mein Test-Alarm
Danach gibt es noch ein Notify:
define nFHT_ALARM1X15 notify mbcALARM1X15 { fhem "set pushmsg message TestAlarm!"}

So normalerweise setzte ich ja beim mbcAlarm1X15 nocht das Attribut event-on-change-reading
Wenn ich das mache bekomm ich KEINE einzige Nachricht Das Bit wird aus der SPS gesetzt und das Icon der Lampe Leuchte in der FHEM Übersicht leuchtet (Aber nur wenn ich die Seite aktualisiere!!)

Wenn ich aber das Attribut event-on-change-reading NICHT setzte, dann bekomme ich im Sekundentakt eine Nachricht. Ob das Bit 1 oder 0 ist - egal.
Hat da jemand einen Tip für mich?
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: sukram am 02 Januar 2021, 21:12:18
Gesundes Neues,

Erweitere mal das Regex in mbcALARM1X15:state:on

Dann sollte das nur bei aktivem Merker losbrüllen.
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: WagoAndreas am 02 Januar 2021, 21:31:22
Danke. aber funzt nicht :-(

CFGFN
   
DEF    
mbcALARM1X15:state:on { fhem "set pushmsg message TestAlarm!"}
NAME
   
nFHT_ALARM1X15
NOTIFYDEV
   
mbcALARM1X15
NR
   
502
NTFY_ORDER
   
50-nFHT_ALARM1X15
REGEXP
   
mbcALARM1X15:state:on
STATE
   
active
TYPE
   
notify

**event on change reading hab ich enfernt (beim mbc) . aber jetzt sendet er gar nichts mehr :-)
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: sukram am 02 Januar 2021, 22:39:44
Ok, da fehlt noch ein .* am Ende.

Hier ein Beispielnotify aus meinem Produktivsystem:

defmod nLichtAn notify wago02_IX0_6:.* set MQTT2_zigbee_group_2 brightness 255

Der zugehörige Eingang aus der Wago:

defmod wago02_IX0_6 ModbusCoil wago IX0.6
attr wago02_IX0_6 IODev wago_02
attr wago02_IX0_6 alias Taster10
attr wago02_IX0_6 devStateIcon .*:
attr wago02_IX0_6 event-on-change-reading .*
attr wago02_IX0_6 room Wago
attr wago02_IX0_6 webCmd :


Das webcmd ist nur da, um die on/off Links auszublenden.
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: WagoAndreas am 03 Januar 2021, 13:08:12
Also mit:
define nFHT_ALARM1X1 notify mbcALARM1X1:on { fhem "set pushmsg....

funktioniert es, wenn das bit 1 das er was sendet. Jedoch sendet er im Sekundentakt dann.
Ich hab es jetzt so programmiert, dass das Bit 2 Sekunden bei einer Störung aktiv ist. Somit sendet er mind. 1 max. jedoch 2 Nachrichten ab. Bissl von hinten durch die Brust. aber es funktioniert. :-)
Vielen Dank

Ich habs gefunden. bei dem event on change reading muss ja am Schluss ein .* hin. Da war bei mir eine 1. Daher hat es nicht funktioniert :-) DANKE für die Hilfe!
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: Thomas Stark am 19 Januar 2021, 08:33:45
Hallo in die Runde.
Ich bin etwas am verzweifeln.
Ich habe eine PCL200 von Wago als Modbus Master laufen.
Es ist ein Register mit 16 Eingängen 32001.0-----32001.15 als Bool Register definiert.
Ebenso ein Register mit 16 Ausgängen 1.0 ------1.15 als Bool Regsiter definiert.
Die Ausgänge möchte ich schreiben können, sondern nur Lesen.
Das funktioniert auch einwandfrei mit folgender Definition in Fhem

define Ausgang_0 ModbusRegister 0 1
attr Ausgang_0 event-on-change-reading .*
attr Ausgang_0 room Wago
attr Ausgang_0 group Output


Ich bekomme einen Dezimalwert zurück, welcer mit das jeweilige Bit wiedergibt.
Hier meine erste Frage
Wie kann ich mir in Fhem das Register als BIT Folge anzeigen lassen, um dann bitweise auf Dummies zu interpretieren?

Die nächste Sorge sind meine Eingänge.
Laut Wago dürfen diese bei der PLC erst bei 32000 beginnen, was ich natürllch berücksichtigt habe und der Übersicht halber mit 32001 begonnen habe.

Hier nun meine Definition in FHEM

define Eingang_0 ModbusRegister 0 32001
attr Eingang_0  registerType Holding
attr Eingang_0  event-on-change-reading .*

Der Versuch auf das Register zu schreiben endet immer mit der Meldung
writing to input registers not allowed

Um nicht ganz zu verzweifeln, habe ich das ganze mit NodeRed parallel aufgebaut.
Hier funktioniert das ganze einwandfrei , was mich darin bestätigt, das es nicht an der Wago Steuerung liegen kann.
Hier nutze ich zum Schreiben den Befehl FC6 Write Single Holding Register.
Zum Laufen lernen habe ich erstmal dezimal geschrieben. Die Finale Lösung soll auch hier sein bit weise mit Dummies zu schreiben 0 oder 1

Ich bin für jede Hilfe Dankbar und würde mich über regen Austausch freuen.

Gruss Thomas




Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: pc1246 am 19 Januar 2021, 09:36:56
Moin
Wieso willst du auf Eingaenge schreiben, das geht doch gar nicht! Kann man auch irgendwo in der Registerbeschreibung nachlesen, da steht ReadOnly, wenn ich mich nach 6ca. 6 Jahren richtig erinnere!
Gruss Christoph
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: Thomas Stark am 19 Januar 2021, 10:19:48
Hallo,
ja ich möchte auch auf Eingänge schreiben um Fehlfunktionen zu vermeiden.
Die Eingänge sind keine physikalischen Eingänge bei mir, sondern globale Variablen die in meine Funktionsbausteine implementiert sind.
Wago lässt dies ja auch explizit zu und mit Nodered kann ich es ja auch einwandfrei tun. FC6 Write Register

Gruss Thomas
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: Hollo am 19 Januar 2021, 21:34:58
Irgendwie passt das alles nicht so recht zusammen.

Wenn Du 3xxxxx er Adressen hast, sind das eigentlich Input Register.
Diese sind read-only und werden mit FC4 gelesen.
Ein Schreibbefehl sollte dementsprechend abgewiesen werden.

Wenn du etwas in Variablen lesen und schreiben willst, nimmst du Holding Register.
Regulär 4xxxxx Adressen, wobei du bei vielen Systemen nur den Offset angibst und die 1. Stelle durch die Art bzw. den Function Code definiert wird.

Wenn du einzelne Bits für Ein- oder Ausgänge willst, musst du (Modbus)Coil und die zugehörigen Function Codes nehmen (z.B. read discrete_inputs oder write single coil); alles andere bezieht sich immer auf 1 bis n Register à 16 Bit.

Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 20 Januar 2021, 09:09:54
Hallo,

Du kannst mit dem Attribut disableRegisterMapping das von von Hollo beschriebene normale Verhalten 'übersteuern':
attr Eingang_0 disableRegisterMapping 1
Damit sollte das Schreiben auf Adresse 32001 funktionieren.

ZitatWie kann ich mir in Fhem das Register als BIT Folge anzeigen lassen...
Dazu kannst du z.B. folgendes userReading verwenden:
attr Eingang_0 userReadings bitstring {unpack('B16', pack('n',ReadingsVal($name,'state',0)))}
Es erstellt ein neues Reading namens bitstring mit den einzelnen Bits, MSB ist links, LSB rechts.

Zitat...um dann bitweise auf Dummies zu interpretieren?
Dies kannst du z.B. mit einem notify machen nachdem du das userReading angelegt hast:
define n_Eingang_0_bits_to_dummies notify Eingang_0:bitstring.* {for (my $i = 0;; $i < 16;; $i++) {fhem("set Eingang_0_$i " . substr($EVTPART1,15-$i,1))}}
Die Dummies Eingang_0_0 bis Eingang_0_15 musst du von Hand anlegen.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: Thomas Stark am 20 Januar 2021, 17:32:33
Hallo zusammen,

vielen Dank für die zahlreichen Infos.
Nach langem Ausprobieren habe ich heute in Bezug auf die PLC200 Steuerung folgendes gelernt.
1.
Die Modbus Registeradressen ab 32000 bis .... sind in der Tat bei Wago als Inputs reserviert und somit auch beschreibbar von aussen.
Meine 16 Bits wiederum über die CoilAdresse von außen einzeln ansprechbar.
Dies aber nicht auf der Adresse 32000 sondern auf Adressen, welche in ECockpit erkundet werden müssen.
Beispiel
Register 32001.0 auf der Adresse 32786
Register 32001.1 auf der Adresse 32787
......
,,,,,,
Register 32001.15 auf der Adresse 32799


2.
Auf diese Adressen kann ich jetzt auch wunderbar aus Fhem heraus steuern.

Beispiel

define Rollo01_hoch ModbusCoil 1 32784

attr Rollo01_hoch IODev wago
attr Rollo01_hoch event-on-change-reading state
attr Rollo01_hoch group Taster
attr Rollo01_hoch room Rolladensteuerung
attr Rollo01_hoch webCmd statusRequest:toggle:on:off


3.
Register welche in ECockpit(Wago) auf nur lesen gesetzt sind , können auch mit dieser Methode nicht beschrieben werden von aussen.
Aber genau das wollte ich ja auch.
Wäre nicht so passend, wenn jemand den Ausgang hoch und runter von ausen gleichzeit mit 1 beschreibt.

Ich werden aber morgen mal weitermachen mit dem TIP von ChrisD

Euch allen vielen Dank und ich werde berichten.

Gruss Thomas
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: witschi87 am 05 April 2021, 10:59:32
Hallo Zusammen,

ich habe scheinbar eine ähnliche Umsetzung wie Thomas (Beitrag vor mir) und dazu ein paar Fragen.
Grundsätzliche Konfiguration ist, dass mein Jalousietaster "hoch" ein Input auf die Wago gibt, und diese den Output für das Hochfahren der Jalousie für 30 sekunden schaltet. Gleiches gilt für den Taster "runter". Ziel soll es nun sein, mit Alexa die Jalousien steuern zu können. Ich bin bereits so weit, dass ich mit "Alexa, mach die Jalousie im Büro an" hochgefahren wird. Immerhin. :-D

Als erstes wäre also die Frage, wie ich in Fhem einen Taster realisieren kann. Es müsste dann vermutlich ein on-for-timer sein?!

Meine bisherige Config sieht so aus:
Zitat
define jalousie_buero_hoch ModbusCoil wago MX0.0
attr jalousie_buero_hoch IODev WAGO_EG
attr jalousie_buero_hoch genericDeviceType switch
attr jalousie_buero_hoch alexaName Jalousie
attr jalousie_buero_hoch alexaRoom Büro
attr jalousie_buero_hoch group Jalousien,
attr jalousie_buero_hoch room Büro
attr jalousie_buero_hoch webCmd on-for-timer 1
attr jalousie_buero_hoch webCmdLabel hoch

Da stellt sich schon die erste Frage, ob der Input direkt schon von Alexa angesprochen werden sollte, oder ob es sinnvoller ist ein Dummy dazwischen zu haben.

Für jegliche Tipps und Tricks bin ich sehr dankbar. Ich komme zwar aus der IT - bin hier aber noch ziemlich am Anfang...

Vielen Dank und frohe Ostern! :-)
Christoph
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: Thomas Stark am 06 April 2021, 17:56:11
Hallo Christof,
ich gehe davon aus, das dein Funktionsbaustein in der Wago die Eingänge gegenseitig verriegelt, sodass sichergestellt ist, das Hoch und Runter zeitgleich nicht gesetzt werden können. Bei mir ist das so und zusätzlich wird immer mit dem gegengesetztem Eingang ein Stop ausgelöst.
Nun zu meiner Lösung in Fhem.
Du brauchst 3 Dinge um in FHEM alles aus der Wago Zeit nah abbilden zu können.
1. Pro Rolladen 2 Eingänge (Modbus)
2. Pro Rolladen 2 Ausgänge um zu zeigen was gerade aktiv ist
3. 2 Dummies pro Rolladen um die Eingänge zeitbehaftet zu steuern.

Die Modbusvariablen sind vom Typ bool und können mit on/off beschrieben werden.
Bei mir ist das ein 16Bit Array für 16 Eingänge. Diese könne dann bitweise gesetzt werden.
Gleiches gilt für die Ausgänge. Hier lese ich dann halt bitweise die Ausgänge.

Die Dummys lassen sich dann auch wunderbar über Fhem Tablet Widgets ansprechen.


Hier meine Auszüge

#Eingänge  1 und 2 für die Rolladensteuerung ModbusAdresse ist anzupassen

define Rollo01_hoch ModbusCoil 1 32784
attr Rollo01_hoch IODev wago
attr Rollo01_hoch event-on-change-reading state
attr Rollo01_hoch group Taster
attr Rollo01_hoch room Rolladensteuerung
attr Rollo01_hoch webCmd statusRequest:toggle:on:off


define Rollo01_runter ModbusCoil 1 32785
attr Rollo01_runter IODev wago
attr Rollo01_runter event-on-change-reading state
attr Rollo01_runter group Taster
attr Rollo01_runter room Rolladensteuerung
attr Rollo01_runter webCmd statusRequest:toggle:on:off


#Ausgänge 1 und 2 für die Rolladensteuerung Modbus Adresse ist anzupassen

define Rollo1_hoch_out ModbusCoil 1 17
attr Rollo1_hoch_out IODev wago
attr Rollo1_hoch_out event-on-change-reading .*
attr Rollo1_hoch_out group Rolladen1
attr Rollo1_hoch_out room Rolladensteuerung

define Rollo1_runter_out ModbusCoil 1 18
attr Rollo1_runter_out IODev wago
attr Rollo1_runter_out event-on-change-reading .*
attr Rollo1_runter_out group Rolladen1
attr Rollo1_runter_out room Rolladensteuerung


####### Ab hier Dummies für hoch und runter
####################Rolladen1 ############################################
define Hoch_R1 dummy
attr Hoch_R1 group Rolladen1
attr Hoch_R1 icon control_arrow_upward
attr Hoch_R1 room Rolladensteuerung
attr Hoch_R1 webCmd on
define Hoch_R1_on notify Hoch_R1:on set Rollo01_hoch on-for-timer 3;; set Hoch_R1 off
attr Hoch_R1_on group Rolladen1
attr Hoch_R1_on room Rolladensteuerung


define Runter_R1 dummy
attr Runter_R1 group Rolladen1
attr Runter_R1 icon control_centr_arrow_down
attr Runter_R1 room Rolladensteuerung
attr Runter_R1 webCmd on
define Runter_R1_on notify Runter_R1:on set Rollo01_runter on-for-timer 3;; set Runter_R1 off
attr Runter_R1_on group Rolladen1
attr Runter_R1_on room Rolladensteuerung



Viel Erfolg.

Gruss Thomas
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: witschi87 am 09 April 2021, 09:44:42
Grundsätzlich liegst du mit deiner Vermutung erst mal richtig: ich habe zwei Inputs für die Taster hoch und runter (die ich natürlich gleichermaßen für den modbus konfiguriert habe). Und zwei Outputs für den Rolladenmotor. Der läuft bei mir jedoch etwas anders: Wenn output 1 gesetzt ist, fährt er hoch. Wenn output 1 und 2 gesetzt sind, fährt er runter.

Im Anhang mal meine Funktionsbausteine.

Nun zu der Fhem Konfiguration:
Die Eingänge haben ein event-on-change-reading state, damit ich von "außen" den Status setzen/ändern kann, richtig?
Wofür definierst du die outputs? Die werden nirgends wieder genutzt, oder? Ich würde auch gerne nur den Taster simulieren (also nur die Inputs ansteuern), den Rest soll die Wago machen. Oder gehe ich damit falsch an die Sache?
Dann ist dort dein webcmd statusRequest - den kennt mein fhem nicht!?

Ansonsten klappt das super, danke. Der Dummy schaltet nun ein on-for-timer und somit bekommt die Wago für eine Sekunde einen Impuls aufs Input. Perfekt! Etappenziel 1 erreicht - Taster lassen sich realisieren. :-D

Das zweite Ziel wäre die Integration in Alexa. Denn ich habe nicht nur für die Jalousien, sondern auch für meine Lichtschalter Taster. Die gehen auf den Stromstoßschalter und schalten somit das Licht. Heißt aber, dass Alexa den Zustand an und aus nicht kennen kann. Zumindest nicht, wenn ich zwischendurch auch auf den Taster drücke.
Lässt sich nun auch in Alexa ein Taster realisieren? Dies gilt natürlich gleichermaßen für die Jalousien, wie auch für das Licht. Schön wäre natürlich, wenn ich am Ende sagen kann "fahre die Jalousie hoch/runter" und "mach das Licht an/aus".
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: Thomas Stark am 09 April 2021, 17:25:58
Hallo,

freut mich das Du das ähnlich gelöst hats wie ich.
Nun zu Deinen Fragen
1. Die Outputs habe ich angelegt um synchron zu sein mit der Wago.
Sprich ich will sehen, was der Ausgang in der Wago macht. Dies lässt sich dann sehr schön in Fhem Tablet dartstellen.

2. Zu Alexa
Ich habe Alexa bei mir auch intergriert. Allerdings mache ich nicht viel mit Alexa
Es gibt im Netz sehr gute Anleitungen um Deine Alexa erstmal mit deiner Fhem bekannt zu machen.

https://wiki.fhem.de/wiki/FHEM_Connector_f%C3%BCr_Amazon_Alexa

Hier der Auszug aus meiner fhem.cfg
Damit kannst Du Alexa erstmal Übersetzungen beibringen für die Kommandos.
Also ein Antriggern der Dummies sollte somit kein Problem sein.
Ich selber schalte damit 3 verschiedene Lichter in der Küche ein und aus.
Wenn ich sage "Alexa schalte Licht Arbeitsplatte an" funktioniert das einwandfrei.
Wenn du Alexa fertig konfiguriert hast, musst du bei deinen Dummies jeweils einen Alexanamen als Attribut definieren.
Auf den kannst du dann  steuern mit Alexa.


define alexa alexa
attr alexa alexaFHEM-config ./alexa-fhem.cfg
attr alexa alexaFHEM-log ./log/alexa-%Y-%m.log
attr alexa alexaMapping #Characteristic=<name>=<value>,...\
On=verb=schalte,valueOn=an;;ein,valueOff=aus,valueToggle=um\
\
Brightness=verb=stelle,property=helligkeit,valuePrefix=auf,values=AMAZON.NUMBER,valueSuffix=prozent\
\
Hue=verb=stelle,valuePrefix=auf,values=rot:0;;grün:128;;blau:200\
Hue=verb=färbe,values=rot:0;;grün:120;;blau:220\
\
Saturation=verb=stelle,property=sättigung,valuePrefix=auf,values=AMAZON.NUMBER\
Saturation=verb=sättige,values=AMAZON.NUMBER\
\
TargetPosition=verb=mach,articles=den;;die,values=auf:100;;zu:0\
TargetPosition=verb=stelle,valuePrefix=auf,values=AMAZON.NUMBER,valueSuffix=prozent\
\
TargetTemperature=verb=stelle,valuePrefix=auf,values=AMAZON.NUMBER,valueSuffix=grad\
\
Volume:verb=stelle,valuePrefix=auf,values=AMAZON.NUMBER,valueSuffix=prozent\
\
#Weckzeit=verb=stelle,valuePrefix=auf;;für,values=AMAZON.TIME,valueSuffix=uhr
attr alexa alexaTypes #Type=<alias>[,<alias2>[,...]]\
light=licht,lampen\
blind=rolladen,rolläden,jalousie,jalousien,rollo,rollos
attr alexa devStateIcon stopped:control_home@red:start stopping:control_on_off@orange running.*:control_on_off@green:stop
attr alexa echoRooms #<deviceId>=<room>\

attr alexa fhemIntents #IntentName=<sample utterance>\
gutenMorgen=guten morgen\
guteNacht=gute nacht
attr alexa persons #<personId>=<name>\

attr alexa room Technik
attr alexa stateFormat alexaFHEM


Viel Erfolg

Gruss Thomas
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: fox-octi am 19 April 2021, 07:01:36
Hi,

leider hab ich mit dem Modul auch ein Problem, ich habe 2 Wagos die ich in Fhem nutzen möchte.

Die erste funktioniert auch problemlos, die zweite leider nicht.

2021.04.19 06:57:50 4: RQUEUE: 1
2021.04.19 06:57:50 5: SimpleWrite [FA C9 00 00 00 06] 00 01 30 A8 00 08
2021.04.19 06:57:50 5: ModbusTCPServer_Parse: received [FA C9 00 00 00 04] 00 01 01 00
2021.04.19 06:57:50 5: wagoGarage: dispatch ModbusCoil:0:12460:1:1:0
2021.04.19 06:57:50 4: AddRQueue [FA CA 00 00 00 06] 00 01 00 00 00 08
2021.04.19 06:57:50 5: SimpleWrite [FA CA 00 00 00 06] 00 01 00 00 00 08
2021.04.19 06:57:50 4: AddRQueue [FA CB 00 00 00 06] 00 01 30 A8 00 08
2021.04.19 06:57:50 5: adding to RQUEUE - 1
2021.04.19 06:57:50 5: ModbusTCPServer_Parse: received [FA CA 00 00 00 04] 00 01 01 00
2021.04.19 06:57:50 5: wagoGarage: dispatch ModbusCoil:0:MX0.6:1:1:0
2021.04.19 06:57:50 2: ModbusCoil_Parse: invalid address 1 0 MX0.6
2021.04.19 06:57:50 2: ModbusCoil_Parse: invalid address 1 0 MX0.6
2021.04.19 06:57:50 3: wagoGarage: Unknown code ModbusCoil:0:MX0.6:1:1:0, help me!

Konfiguration:
DeviceName
172.16.218.5:502
FD
25
NAME
wagoGarage
NOTIFYDEV
global
NR
152
NTFY_ORDER
50-wagoGarage
PARTIAL
STATE
ok
TYPE
ModbusTCPServer
server
Wago 750-841
statistics
354 / 354 / 3562 / 4248
Readings
state
opened
2021-04-19 06:30:17
wagoGarage
room
Haus->Verwaltung->Wago
Attributes
combineReads
20:80
deleteattr
pollInterval
0.4
deleteattr
room
Haus->Verwaltung->Wago
deleteattr
serverType
Wago
deleteattr
verbose
3
deleteattr

Mir ist leider nicht klar, was ich bei der 2. Wago falsch mache, was ich bei der 1. richtig mache.

Würde mich über Hilfe freuen.

Gruß

Chris
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: fox-octi am 19 April 2021, 17:16:23
Hi,

ich weiss nicht wirklich was ich falsch mache, per Symcon kann per Modbus abfragen und setzen der Merker, per Fhem leider nicht.
Habe auch mit einer neuen FHEM Instanz getestet, leider auch ohne Erfolg. Ich bekomme die WAGO 841 nicht zum laufen mit FHEM.

Gruß
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 19 April 2021, 21:03:06
Hallo,

Ist wagoGarage die SPS die nicht funktioniert ?

Wie sieht die Definition von MX0.6 aus ?

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: fox-octi am 20 April 2021, 05:58:27
Hi Chris,

cool dass du hilfst..


define wagoGarage_presence PRESENCE lan-ping 172.16.218.5
attr wagoGarage_presence room Haus->Verwaltung->Wago

define wagoGarage ModbusTCPServer 172.16.218.5

attr wagoGarage combineReads 20:80
attr wagoGarage pollInterval 0.4
attr wagoGarage presenceLink wagoGarage_presence
attr wagoGarage room Haus->Verwaltung->Wago
attr wagoGarage serverType Wago
attr wagoGarage verbose 5


define Wago_M_Output_O_HolzLicht ModbusCoil wagoGarage MX33.5

attr Wago_M_Output_O_HolzLicht IODev wagoGarage
attr Wago_M_Output_O_HolzLicht event-on-change-reading .*
attr Wago_M_Output_O_HolzLicht room hidden
attr Wago_M_Output_O_HolzLicht timestamp-on-change-reading state
attr Wago_M_Output_O_HolzLicht verbose 5

define Wago_SW_M_Output_O_HolzLicht ModbusCoil wagoGarage MX33.6

attr Wago_SW_M_Output_O_HolzLicht IODev wagoGarage
attr Wago_SW_M_Output_O_HolzLicht event-on-change-reading .*
attr Wago_SW_M_Output_O_HolzLicht room Wago,hidden
attr Wago_SW_M_Output_O_HolzLicht timestamp-on-change-reading state
attr Wago_SW_M_Output_O_HolzLicht verbose 5



:::
Internals:
   CFGFN      ./wago.cfg
   DEF        172.16.218.5
   DeviceName 172.16.218.5:502
   FD         25
   FUUID      607da03b-f33f-5d0a-dbf4-1c9a0772bfa1b12e
   NAME       wagoGarage
   NOTIFYDEV  global
   NR         147
   NTFY_ORDER 50-wagoGarage
   PARTIAL   
   STATE      ok
   TYPE       ModbusTCPServer
   server     Wago 750-841
   statistics 111387 / 111387 / 1113890 / 1336644
   READINGS:
     2021-04-19 17:22:37   state           opened
   helper:
     delayNextRead 0
     delayNextWrite 0
     fc         1
     hd_tr_id   64100
     hd_unit_id 0
     lastFrame  SimpleWrite [FA 64 00 00 00 06] 00 01 00 00 00 08
     lastSimpleWrite �d
     last_fc    1
     last_hd_tr_id 64099
     presence   wagoGarage_presence
     seq        65000
     seqCoils   64101
     state      idle
     Wago:
       AI         0
       AO         0
       DI         8
       DIOffset   0
       DO         16
       DOOffset   0
       INFO_ITEM  841
       INFO_MAJOR 4
       INFO_MINOR 1
       INFO_REVISION 21
       INFO_SERIES 750
       initDone   1
       x          1
     combineReads:
       cfg:
         maxSize    80
         maxSpace   20
       coils:
         ARRAY(0x560cef56f390)
       data:
         64058:
           wagoGarage
           1
           0
           8
         64314:
           wagoGarage
           1
           0
           8
     statistics:
       bytesIn    1113890
       bytesOut   1336644
       pktIn      111387
       pktOut     111387
Attributes:
   combineReads 20:80
   pollInterval 0.4
   presenceLink wagoGarage_presence
   room       Haus->Verwaltung->Wago
   serverType Wago
   verbose    5

::::::::::::::
Internals:
   CFGFN      ./wago.cfg
   DEF        wagoGarage MX33.6
   FUUID      607da03b-f33f-5d0a-f94a-508b69071c78cfe8
   IODev      wagoGarage
   NAME       Wago_SW_M_Output_O_HolzLicht
   NR         154
   NTFY_ORDER 50-Wago_SW_M_Output_O_HolzLicht
   STATE      set_on
   TYPE       ModbusCoil
   lastUpdate Tue Apr 20 05:57:17 2021
   nextUpdate Tue Apr 20 05:57:17 2021
   READINGS:
     2021-04-19 16:49:41   state           set_on
   helper:
     addr       1 wagoGarage MX33.6
     address    MX33.6
     disableRegisterMapping 0
     lastUpdate 1618891037.39747
     nextUpdate 1618891037.79754
     nread      8
     readCmd    
     register   MX33.6
     registerType 1
     unitId     wagoGarage
     updateIntervall 0.1
Attributes:
   IODev      wagoGarage
   event-on-change-reading .*
   room       Wago,hidden
   timestamp-on-change-reading state
   verbose    5


Wago:
        M_Output_O_Pumpe AT %MX33.5 :BOOL; (*12292*)
   SW_M_Output_O_Pumpe AT %MX33.6 :BOOL; (*12293*)
   M_Output_O_HolzLicht AT %MX33.7 :BOOL; (*12294*)

Gruß

Chris
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: witschi87 am 20 April 2021, 12:37:53
Zitat von: Thomas Stark am 06 April 2021, 17:56:11
Hallo Christof,
ich gehe davon aus, das dein Funktionsbaustein in der Wago die Eingänge gegenseitig verriegelt, sodass sichergestellt ist, das Hoch und Runter zeitgleich nicht gesetzt werden können. Bei mir ist das so und zusätzlich wird immer mit dem gegengesetztem Eingang ein Stop ausgelöst.
Nun zu meiner Lösung in Fhem.
Du brauchst 3 Dinge um in FHEM alles aus der Wago Zeit nah abbilden zu können.
1. Pro Rolladen 2 Eingänge (Modbus)
2. Pro Rolladen 2 Ausgänge um zu zeigen was gerade aktiv ist
3. 2 Dummies pro Rolladen um die Eingänge zeitbehaftet zu steuern.

Die Modbusvariablen sind vom Typ bool und können mit on/off beschrieben werden.
Bei mir ist das ein 16Bit Array für 16 Eingänge. Diese könne dann bitweise gesetzt werden.
Gleiches gilt für die Ausgänge. Hier lese ich dann halt bitweise die Ausgänge.

Die Dummys lassen sich dann auch wunderbar über Fhem Tablet Widgets ansprechen.


Hier meine Auszüge

#Eingänge  1 und 2 für die Rolladensteuerung ModbusAdresse ist anzupassen

define Rollo01_hoch ModbusCoil 1 32784
attr Rollo01_hoch IODev wago
attr Rollo01_hoch event-on-change-reading state
attr Rollo01_hoch group Taster
attr Rollo01_hoch room Rolladensteuerung
attr Rollo01_hoch webCmd statusRequest:toggle:on:off


define Rollo01_runter ModbusCoil 1 32785
attr Rollo01_runter IODev wago
attr Rollo01_runter event-on-change-reading state
attr Rollo01_runter group Taster
attr Rollo01_runter room Rolladensteuerung
attr Rollo01_runter webCmd statusRequest:toggle:on:off


#Ausgänge 1 und 2 für die Rolladensteuerung Modbus Adresse ist anzupassen

define Rollo1_hoch_out ModbusCoil 1 17
attr Rollo1_hoch_out IODev wago
attr Rollo1_hoch_out event-on-change-reading .*
attr Rollo1_hoch_out group Rolladen1
attr Rollo1_hoch_out room Rolladensteuerung

define Rollo1_runter_out ModbusCoil 1 18
attr Rollo1_runter_out IODev wago
attr Rollo1_runter_out event-on-change-reading .*
attr Rollo1_runter_out group Rolladen1
attr Rollo1_runter_out room Rolladensteuerung


####### Ab hier Dummies für hoch und runter
####################Rolladen1 ############################################
define Hoch_R1 dummy
attr Hoch_R1 group Rolladen1
attr Hoch_R1 icon control_arrow_upward
attr Hoch_R1 room Rolladensteuerung
attr Hoch_R1 webCmd on
define Hoch_R1_on notify Hoch_R1:on set Rollo01_hoch on-for-timer 3;; set Hoch_R1 off
attr Hoch_R1_on group Rolladen1
attr Hoch_R1_on room Rolladensteuerung


define Runter_R1 dummy
attr Runter_R1 group Rolladen1
attr Runter_R1 icon control_centr_arrow_down
attr Runter_R1 room Rolladensteuerung
attr Runter_R1 webCmd on
define Runter_R1_on notify Runter_R1:on set Rollo01_runter on-for-timer 3;; set Runter_R1 off
attr Runter_R1_on group Rolladen1
attr Runter_R1_on room Rolladensteuerung



Viel Erfolg.

Gruss Thomas

Das war schon mal Gold wert! Damit bekomme ich Taster realisiert, großartig!
Kann ich mir damit nun auch ein Dummy für meine Lampen anlegen? Sodass ich in FHEM sehe, ob mein Licht an oder aus ist? Meine Idee war initial davon auszugehen, dass das Licht aus ist und dann den Output zu beobachten. Wenn der geschaltet wird, toggle ich den Zustand des Lichts. Dann weiß auch Alexa, ob das Licht an oder aus ist. Geht das?
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 20 April 2021, 21:56:29
Hallo,

@fox-octi: Ich denke dass die Definition der Coils nicht richtig ist:
ZitatDEF wagoGarage MX33.6

Bei der Definition muss entweder eine Coiladresse oder alternativ der Begriff 'wago' mit einer SPS-Adresse verwendet werden. Es darf nicht der Name der SPS angegeben werden. Die SPS wird über das Attribut IODev festgelegt.

Kannst du versuchen die Definitionen zu ändern ?

defmod Wago_M_Output_O_HolzLicht ModbusCoil wago MX33.5
defmod Wago_SW_M_Output_O_HolzLicht ModbusCoil wago MX33.6


Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: fox-octi am 23 April 2021, 17:40:05
Hi,

erstmal totales Sorry, dass ich erst zu spät geantwortet habe.
Du hattest Recht :)  Konnte es soeben testen.

falsch:define WagoGarage_SW_M_Output_O_Sprenger1 ModbusCoil wagogarage MX2.3
richtig:define WagoGarage_SW_M_Output_O_Sprenger1 ModbusCoil wago MX2.3

Danke dir für die Hilfe, hab es einfach nicht gesehen und dabei sind Stunden drauf gegangen. ....aua...

Gruß

Chris
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 28 Mai 2021, 16:59:45
Hallo Wago User,
habt ihr kürzlich ein update gemacht und so wie ich jetzt Probleme..?
Es äussert sich durch Time Out einträgen im log File..

2021.05.28 15:09:42 3: ModbusTCPServer_Timeout, request: SimpleWrite [FB DA 00 00 00 06] 00 01 30 00 00 48
2021.05.28 15:03:52 3: ModbusTCPServer_Timeout, request: SimpleWrite [FA F0 00 00 00 06] 00 01 30 00 00 48
2021.05.28 14:49:51 3: ModbusTCPServer_Timeout, request: SimpleWrite [FB BE 00 00 00 06] 00 01 30 00 00 48
2021.05.28 14:44:00 3: ModbusTCPServer_Timeout, request: SimpleWrite [FA A4 00 00 00 06] 00 01 00 18 00 08
2021.05.28 14:42:50 3: ModbusTCPServer_Timeout, request: SimpleWrite [FA 12 00 00 00 06] 00 01 30 00 00 48
2021.05.28 14:27:39 3: ModbusTCPServer_Timeout, request: SimpleWrite [FA 2D 00 00 00 06] 00 01 30 00 00 48
2021.05.28 14:18:18 3: ModbusTCPServer_Timeout, request: SimpleWrite [FB 34 00 00 00 06] 00 01 00 18 00 08
2021.05.28 14:17:08 3: ModbusTCPServer_Timeout, request: SimpleWrite [FA A7 00 00 00 06] 00 01 30 00 00 48
2021.05.28 14:07:47 3: ModbusTCPServer_Timeout, request: SimpleWrite [FB E7 00 00 00 06] 00 01 02 40 00 08
2021.05.28 14:00:47 3: ModbusTCPServer_Timeout, request: SimpleWrite [FA 28 00 00 00 06] 00 01 30 00 00 48
2021.05.28 13:52:36 3: ModbusTCPServer_Timeout, request: SimpleWrite [FA 06 00 00 00 06] 00 01 00 18 00 08
2021.05.28 13:49:06 3: ModbusTCPServer_Timeout, request: SimpleWrite [FA 1C 00 00 00 06] 00 01 30 00 00 48
2021.05.28 13:45:35 3: ModbusTCPServer_Timeout, request: SimpleWrite [FA 60 00 00 00 06] 00 01 02 40 00 08
2021.05.28 13:28:04 3: ModbusTCPServer_Timeout, request: SimpleWrite [FB 53 00 00 00 06] 00 01 00 18 00 08
2021.05.28 13:22:14 3: ModbusTCPServer_Timeout, request: SimpleWrite [FA 72 00 00 00 06] 00 01 30 50 00 18
2021.05.28 13:17:34 3: ModbusTCPServer_Timeout, request: SimpleWrite [FB D2 00 00 00 06] 00 01 00 18 00 08
2021.05.28 13:15:14 3: ModbusTCPServer_Timeout, request: SimpleWrite [FA A9 00 00 00 06] 00 01 00 40 00 10
2021.05.28 13:03:33 3: ModbusTCPServer_Timeout, request: SimpleWrite [FA 9A 00 00 00 06] 00 01 30 00 00 48
2021.05.28 13:00:03 3: ModbusTCPServer_Timeout, request: SimpleWrite [FA D2 00 00 00 06] 00 01 00 18 00 08
2021.05.28 12:55:23 3: ModbusTCPServer_Timeout, request: SimpleWrite [FA 81 00 00 00 06] 00 01 30 50 00 18
2021.05.28 12:48:22 3: ModbusTCPServer_Timeout, request: SimpleWrite [FA C6 00 00 00 06] 00 01 00 18 00 08
2021.05.28 12:47:12 3: ModbusTCPServer_Timeout, request: SimpleWrite [FA 3B 00 00 00 06] 00 01 00 18 00 08
2021.05.28 12:44:52 3: ModbusTCPServer_Timeout, request: SimpleWrite [FB 13 00 00 00 06] 00 01 30 00 00 48
2021.05.28 12:41:22 3: ModbusTCPServer_Timeout, request: SimpleWrite [FB 53 00 00 00 06] 00 01 30 00 00 48
2021.05.28 12:23:51 3: ModbusTCPServer_Timeout, request: SimpleWrite [FA 14 00 00 00 06] 00 01 00 18 00 08
2021.05.28 12:20:20 3: ModbusTCPServer_Timeout, request: SimpleWrite [FA 57 00 00 00 06] 00 01 30 00 00 48
2021.05.28 12:11:00 3: ModbusTCPServer_Timeout, request: SimpleWrite [FB 53 00 00 00 06] 00 01 30 50 00 18
2021.05.28 12:06:20 3: ModbusTCPServer_Timeout, request: SimpleWrite [FA F0 00 00 00 06] 00 01 00 18 00 08
2021.05.28 12:02:49 3: ModbusTCPServer_Timeout, request: SimpleWrite [FB 2C 00 00 00 06] 00 01 00 40 00 10
2021.05.28 11:44:08 3: ModbusTCPServer_Timeout, request: SimpleWrite [FB 95 00 00 00 06] 00 01 00 18 00 08
2021.05.28 11:37:07 3: ModbusTCPServer_Timeout, request: SimpleWrite [FB E3 00 00 00 06] 00 01 00 18 00 08
2021.05.28 11:23:07 3: ModbusTCPServer_Timeout, request: SimpleWrite [FA 99 00 00 00 06] 00 01 00 18 00 08
2021.05.28 11:14:57 3: ModbusTCPServer_Timeout, request: SimpleWrite [FA 7E 00 00 00 06] 00 01 30 50 00 18
2021.05.28 11:10:17 3: ModbusTCPServer_Timeout, request: SimpleWrite [FB DA 00 00 00 06] 00 01 00 40 00 10
2021.05.28 11:05:36 3: ModbusTCPServer_Timeout, request: SimpleWrite [FB 84 00 00 00 06] 00 01 00 18 00 08
2021.05.28 11:04:26 3: ModbusTCPServer_Timeout, request: SimpleWrite [FA EA 00 00 00 06] 00 01 00 18 00 08
2021.05.28 11:03:16 3: ModbusTCPServer_Timeout, request: SimpleWrite [FA 55 00 00 00 06] 00 01 00 18 00 08
2021.05.28 10:56:15 3: ModbusTCPServer_Timeout, request: SimpleWrite [FA 98 00 00 00 06] 00 01 30 50 00 18
2021.05.28 10:55:05 3: ModbusTCPServer_Timeout, request: SimpleWrite [FB F4 00 00 00 06] 00 01 00 18 00 08
2021.05.28 10:39:54 3: ModbusTCPServer_Timeout, request: SimpleWrite [FA 09 00 00 00 06] 00 01 30 00 00 48
2021.05.28 10:23:34 3: ModbusTCPServer_Timeout, request: SimpleWrite [FB 77 00 00 00 06] 00 01 00 18 00 08
2021.05.28 10:01:22 3: ModbusTCPServer_Timeout, request: SimpleWrite [FB E0 00 00 00 06] 00 01 00 18 00 08


Ein Problem was ich ausserdem erkenne ist das beim zuweisen der IO sich etwas geändert hat.
Bei einem FHEM neustart habe ich jedes Coil z.b. 3 mal mit dem Controller als IODev.

2021.05.27 21:16:38 1: IO: PSchlafbereichRGB WagoController
2021.05.27 21:16:38 3: PSchlafbereichRGB: I/O device is WagoController
2021.05.27 21:16:38 1: IO: SchlafbereichRGB WagoController
2021.05.27 21:16:38 3: SchlafbereichRGB: I/O device is WagoController
2021.05.27 21:16:38 1: IO: SchlafzimmerRGB WagoController
2021.05.27 21:16:38 3: SchlafzimmerRGB: I/O device is WagoController
2021.05.27 21:16:38 1: IO: Ankleide WagoController
2021.05.27 21:16:38 3: Ankleide: I/O device is WagoController
2021.05.27 21:16:38 1: IO: PAnkleide WagoController
2021.05.27 21:16:38 3: PAnkleide: I/O device is WagoController
2021.05.27 21:16:38 1: IO: Ankleidebereich WagoController
2021.05.27 21:16:38 3: Ankleidebereich: I/O device is WagoController
2021.05.27 21:16:38 1: IO: PSchlafbereich WagoController
2021.05.27 21:16:38 3: PSchlafbereich: I/O device is WagoController
2021.05.27 21:16:38 1: IO: Schlafbereich WagoController
2021.05.27 21:16:38 3: Schlafbereich: I/O device is WagoController
2021.05.27 21:16:38 1: IO: Schlafzimmer WagoController
2021.05.27 21:16:38 3: Schlafzimmer: I/O device is WagoController


2021.05.27 21:16:45 1: IO: SchlafzimmerRGB WagoController
2021.05.27 21:16:45 1: IO: Schlafzimmer WagoController
2021.05.27 21:16:45 1: IO: SchlafbereichRGB WagoController
2021.05.27 21:16:45 1: IO: Schlafbereich WagoController
2021.05.27 21:16:45 1: IO: PSchlafbereichRGB WagoController
2021.05.27 21:16:45 1: IO: PSchlafbereich WagoController


Funktion ist unverändert ok - FHEM web ist gefühlt etwas träger geworden, ein restore des updates hat mir leider nicht geholfen.

Hat jemand eine Idee, kann jemand Probleme bestätigen..?

Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 29 Mai 2021, 21:41:20
Hallo,

Es gab vor Kurzem Änderungen am IODev-System in FHEM. Dies hat bereits bei diversen anderen Modulen zu Problemen geführt. Ich muss mir auf einem Testrechner ansehen wieso es nicht mehr richtig funktioniert.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: sukram am 24 August 2021, 20:54:07
Hallo Chris,

ich bin gerade über meine eigene Blindheit gestolpert  ::)  Würde es dir etwas ausmachen, in die "Device Specific Help" für ModbusRegister einen kurzen, dicken, fetten, Satz reinzuschreiben, dass die "wago XY123" Notation nur funktioniert, wenn der Server auch auf "Servertype Wago" steht?

Ich habe gerade einige Zeit damit verbracht, bis ich dann die verschiedenen Instanzen mal Attributweise verglichen habe  ;D

Die auf der vorhergehenden Seite genannten Timeouts habe ich auch gelegentlich, habe das aber bisher auf mein massiv untermotorisiertes Modbus TCP-RTU Gateway (AVR Netio mit Ethersex Firmware) geschoben.
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 24 August 2021, 21:06:27
Hallo,

Vielen Dank für den Hinweis, ich werde dies zur Dokumentation hinzufügen.

Grüße, ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 10 Juni 2022, 20:19:24
Boah, hier ist es still geworden ;)
Zeugt davon das alles bestens funktioniert!

Ich bin leider wieder, nach ein paar ruhigen Monaten,  Opfer des memory-leaks geworden. Mein Haupt-FHEM muss ich mittlerweile alle 6-8 Stunden neu starten.

Ich bereite derzeit einen "umzug" vor - neuer Host wird mein alter 2010er iMac mit Debian11.

In wie weit kann ich zwei FHEM Instanzen parallel benutzen? Ich habe so viele I/Os das ich den Umzug nicht am einem Tag bewältigen kann, zumal ich alles sauberer definieren möchte. Wie harmoniert das ganze wenn ein zweiter Wago Controller ( 750-842 ) hinzukommt?
Die zweite Wago einheit läuft derzeit an einem Pi als separiertes FHEM. Die FHEM-Instanz wird zwar auch für anderes ( I2C - Messungen, OneWire ) gebraucht, kann mir aber vorstellen das die I/Os ins Haupt-FHEM umziehen.

Wie würdet ihr vorgehen?
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 26 Juni 2022, 20:12:51
Ich nutze gerne ein "set on-for-timer" - gibt es eine möglichkeit die Restlaufzeit im Device darzustellen?
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 27 Juni 2022, 22:10:32
Hallo,

Du kannst versuchen ein userReading dafür zu verwenden, z.B.:

attr mx_1_0 userReadings oftRest {if(defined($defs{mx_1_0}{TIMED_OnOff})) {$defs{mx_1_0}{TIMED_OnOff}{START}+$defs{mx_1_0}{TIMED_OnOff}{DURATION}-time()} else {'-'}}

Wenn on-for-timer aktiv ist ist der Startpunkt und die Dauer im Hash des Gerätes unter {TIMED_OnOff} abgelegt.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 01 Juli 2022, 18:40:40
Wow, cool ChrisD - Danke das klappt auf anhieb!

Mir fällt nur auf das doch recht viele events erzeugt werden - ich brauch das auch nicht sekundengenau, minuten würden ausreichen, ich glaube ich muss mich dringend mal mit der "macht" der userReadings auseinandersetzen.
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 03 Juli 2022, 23:18:40
Ok - event-min-interval ist mein freund ;) Das hat ganz gut geholfen...
Wenn ich jetzt mit on-for-timer starte und via set off schalte läuft der Timer weiter ;) - kann man da was optimieren?

oftRest hätte ich gerne ohne komma un bin unsicher wo ich das bestimmen soll - kannst du nochmal helfen..?
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 06 Juli 2022, 21:00:40
Hallo,

Dies
ZitatoftRest hätte ich gerne ohne komma un bin unsicher wo ich das bestimmen soll - kannst du nochmal helfen..?
kannst du mit einem 'int' lösen:

attr mx_1_0 userReadings oftRest {if(defined($defs{mx_1_0}{TIMED_OnOff})) {int($defs{mx_1_0}{TIMED_OnOff}{START}+$defs{mx_1_0}{TIMED_OnOff}{DURATION}-time())} else {'-'}}

Das Ganze in Minuten (ohne Sekunden):
attr mx_1_0 userReadings oftRest {if(defined($defs{mx_1_0}{TIMED_OnOff})) {int(($defs{mx_1_0}{TIMED_OnOff}{START}+$defs{mx_1_0}{TIMED_OnOff}{DURATION}-time())/60)} else {'-'}}

ZitatWenn ich jetzt mit on-for-timer starte und via set off schalte läuft der Timer weiter ;) - kann man da was optimieren?
Der Timer läuft weiter, set off beendet ihn nicht. Nach der eingestellten Zeit wird der Befehl ausgeführt. Wenn bereits ausgeschaltet war bemerkst du es nur nicht.

Diese Variante blendet in dem Fall die Zeit aus:
attr mx_1_0 userReadings oftRest {if(defined($defs{mx_1_0}{TIMED_OnOff})){if($defs{mx_1_0}{TIMED_OnOff}{NEXTCMD} ne $defs{mx_1_0}{STATE}){int($defs{mx_1_0}{TIMED_OnOff}{START}+$defs{mx_1_0}{TIMED_OnOff}{DURATION}-time())} else {'-'}} else {'-'}}

Da das Ganze etwas groß und unhandlich wird wäre es sinnvoll den Code in eine externe Funktion auszulagern und diese im userReading aufzurufen.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 31 Juli 2022, 11:17:29
Danke für Deine Hilfe beim on-for-timer "Restlaufzeit" auslesen - funktioniert wunderbar!
Nun hätte ich gerne noch eine "Fortschrittsanzeige", vielleicht hast Du eine Idee...
Ich habe im Bereich meiner Pool Steuerung "Belimo" 24V Stellantriebe, die drehen Kugelhähne in entsprechende stellungen ( SolarAN/SolarAus )
Die Laufzeit um den Kugelhahn um 90° zu drehen beträgt etwa 143 sekunden, diese Zeit habe ich fix im Wago Projekt hinterlegt.

Ich hatte mal im Netz gesucht und dieses Beispiel gefunden - siehe Anhang

Die entsprechende bilbliothek habe ich hinzugefügt - ich bekomme es aber leider nicht ans laufen.




Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 01 August 2022, 13:06:46
Hallo,

Das Beispiel sieht eigentlich gut aus.

Was genau funktioniert nicht ?

Lässt sich der Code nicht kompilieren ?

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 01 August 2022, 13:59:52
genau - vielleicht liegt es daran das ich die 0-100 ja dann in einem Register also als Byte Wert zu FHEM übertragen wollte. ( REAL to BYTE )

Gemeldet wurde jedenfalls beim compilieren ein Fehler - ich müsste es nochmal nachstellen um die genaue Meldung zu bekommen.
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: sukram am 11 August 2022, 10:19:50
Zitat von: der-Lolo am 01 August 2022, 13:59:52
genau - vielleicht liegt es daran das ich die 0-100 ja dann in einem Register also als Byte Wert zu FHEM übertragen wollte. ( REAL to BYTE )

Ist denn das Ausgaberegister auch als Byte definiert? "Normalerweise" hat Modbus als Mindestgröße 16 Bit (=Word = Unsigned Int), du müsstest das Register also als Word beschreiben mit REAL_TO_WORD.
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 16 November 2022, 17:04:50
Hallo ChrisD -
ich habe seit ein paar Tagen immer mal wieder sowas hier im Log...

Kannst Du etwas dazu sagen?

2022.11.16 16:33:47 3: EichenheimWago: Unknown code ModbusCoil:0:12547:5:1:65280, help me!
2022.11.16 16:33:47 3: EichenheimWago: Unknown code ModbusCoil:0:12547:5:1:0, help me!
2022.11.16 16:33:49 3: EichenheimWago: Unknown code ModbusCoil:0:12547:5:1:65280, help me!
2022.11.16 16:33:49 3: EichenheimWago: Unknown code ModbusCoil:0:12547:5:1:0, help me!
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 18 November 2022, 21:34:57
Hallo,

Die Meldungen kommen von einem Schreibauftrag auf Adresse 12547. Das Modul versucht die Rückmeldung vom Schreibauftrag einem Coil zuzuordnen welches nicht existiert.

Verwendest du das Attribut writeMode mit dieser Adresse ?

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 19 November 2022, 12:03:20
Ich vermute es handelt sich um diesen Eintrag in FHEM.


Internals:
   CFGFN     
   DEF        wago MX6.3
   EichenheimWago_MSGCNT 1027228
   EichenheimWago_TIME 2022-11-19 11:57:49
   FUUID      63726163-f33f-4532-7fd0-fed52fde9f4d626a
   IODev      EichenheimWago
   LASTInputDev EichenheimWago
   MSGCNT     1027228
   ModbusCoil_lastRcv 2022-11-19 11:57:49
   NAME       validButton
   NOTIFYDEV  global
   NR         14947
   NTFY_ORDER 50-validButton
   STATE      off
   TYPE       ModbusCoil
   eventCount 53
   lastUpdate Sat Nov 19 11:57:49 2022
   nextUpdate Sat Nov 19 11:57:50 2022
   READINGS:
     2022-11-14 16:40:19   IODev           EichenheimWago
     2022-11-19 11:57:49   state           off
   helper:
     addr       1 0 12387
     address    12387
     disableRegisterMapping 1
     lastUpdate 1668855469.65942
     nextUpdate 1668855470.05933
     nread      8
     readCmd    0c
     register   12387
     registerType 1
     unitId     0
     updateIntervall 0.1
     wago       1
     wagoDOOffset 0
     wagoT      M
     writeMode:
       DO         0
       addr       1 0 12547
       address    12547
       impDuration 0.5
       register   MX16.3
       registerType 1
       type       IM
   powerMap:
   readingsDesc:
     energy:
       rtype      whr
     power:
       rtype      w
Attributes:
   DbLogExclude .*
   IODev      EichenheimWago
   alias      validButton (BOOL to wago)
   event-on-change-reading .*
   group      Licht-Schalter
   room       00 - Haus -> 14 - Alarmanlage
   writeMode  Impulse:MX16.3


und im Codesys schaut das so aus...


Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 20 November 2022, 22:18:03
Hallo,

Es ist möglich dass die Meldung davon ausgelöst wird. Das Modul versucht das eigentlich zu verhindern. Wieso es in diesem Fall nicht funktioniert ist mir nicht klar.

Kannst du bitte die angehängte Version ausprobieren. Diese gibt im Log eine Meldung aus ob die Rückmeldung zugeordnet werden konnte.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 22 November 2022, 17:33:10
Hallo ChrisD,
nach einspielen der Datei und betätigen des validButton erscheint nun das hier im Log...

2022.11.22 17:29:24 0: WRITE_SINGLE_COIL: using coil validButton
2022.11.22 17:29:25 0: WRITE_SINGLE_COIL: using coil validButton
2022.11.22 17:29:26 0: WRITE_SINGLE_COIL: using coil validButton
2022.11.22 17:29:26 1: SONOS1: UPnP-Thread gestartet.
2022.11.22 17:29:26 1: SONOS2: LongJobs-Thread gestartet. Prüfe auf LongJobs...
2022.11.22 17:29:26 1: SONOS3: IsAlive-Thread gestartet. Warte 120 Sekunden und pruefe dann alle 30 Sekunden...
2022.11.22 17:29:26 1: SONOS4: Restore-Thread gestartet. Warte auf Arbeit...
2022.11.22 17:29:27 0: WRITE_SINGLE_COIL: using coil validButton


Sonos spuckt leider dazwischen - ich denke aber das stört nicht.

Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 23 November 2022, 07:41:48
Hallo,

Die Meldungen sind in Ordnung, der Fehler dürfte in dem Fall nicht aufzutreten.

Hast du FHEM neu gestartet oder die neue Version des Moduls mit reload neu geladen ?

Um die Log-Einträge zu reduzieren kannst du die Zeile 494 von
Log 0,'WRITE_SINGLE_COIL: using coil ' . $rhash->{$n}->{NAME};
in
Log 5,'WRITE_SINGLE_COIL: using coil ' . $rhash->{$n}->{NAME};
ändern und das Modul mit
reload 36_ModbusTCPServerneu laden.

Grüße,

ChrisD

Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 23 November 2022, 18:11:46
Ich hatte einen Neustart gemacht - Danke für Deine hilfe - das help me! hatte mich ein bisschen nervös gemacht.
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 26 November 2022, 07:57:03
Hallo nochmal ChrisD,
bei meinem wochenend-backup-update durchlauf wird nun ein update vorgeschlagen:
modbus
List of new / modified files since last update:
UPD FHEM/36_ModbusTCPServer.pm

New entries in the CHANGED file:
36_ModbusRTU:
  150314 0008 fixed typo in attribute name pollIntervall
              added ModbusRTU_CalcNextUpdate
              added timeout message
              check if request is already in rqueue
              added combineReads
              added support for coils
36_ModbusTCPServer:
  190906 0023 added (empty) fingerprint
  181107 0022 changed detection of wago plc
37_ModbusCoil:
  210718 0015 small change for modified IOdev handling in FHEM
  170106 0014 added writeMode SetReset
              fixed access to Wago PFC area
              documentation update
              fix Wago DO address calculation
37_ModbusRegister:
  210718 0025 small change for modified IOdev handling in FHEM
  180206 0024 added DATE


Kann ich das update machen ohne das help me! wieder im Log erscheint?
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: ChrisD am 26 November 2022, 09:47:13
Hallo,

Ich habe die aktuelle Version eingechecked, du kannst das Update machen.

Grüße,

ChrisD
Titel: Antw:Wago /SPS über Modbus(TCP/IP) in FHEM steuern
Beitrag von: der-Lolo am 26 November 2022, 10:28:23
Danke.