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

[pc1246]

Moin
Man kann auch einfach die positive Flanke des Eingangs auswerten und dann ein Merker-/Datendoppelwort um 1 inkrementieren!
Gruss Christoph

[der-Lolo]

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

Code Auswählen Erweitern

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.

[ChrisD]

Hallo,

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...

Es gibt viele Möglichkeiten dies zu lösen, eine davon ist SEL zu verwenden.

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.

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

[der-Lolo]

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

Wichtig 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?

[ChrisD]

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

[der-Lolo]

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.

[der-Lolo]

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.

[ChrisD]

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

[der-Lolo]

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!

[ChrisD]

Hallo,

Wä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.

Code Auswählen Erweitern

attr out1 writeMode Impulse:MX21.0

In Verbindung mit dem angehängten Code für die SPS solltest du ausschalten können.

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...

Ich würde die Adresse bei abDMX_Values entfernen und ganz am Ende die Daten von MW20x umkopieren (siehe Bild 2).

wü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

[bitvilla]

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

[ChrisD]

Hallo,

Dabei ist mir jedoch aufgefallen, dass sich mit WriteMode nur Merker ansprechen lassen

Es sollte auch mit IX und QX funktionieren, z.B.

Code Auswählen Erweitern

attr mbc_1 writeMode Impulse:QX256.0
Wie lautet die Fehlermeldung genau ?

Beim 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.:

Code Auswählen Erweitern

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

Code Auswählen Erweitern

set MB_T_RolloAuf 06:50
oder

Code Auswählen Erweitern

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.

Des 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.

Gibt 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

Code Auswählen Erweitern

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

[bitvilla]

Hallo ,

Hallo,
Es sollte auch mit IX und QX funktionieren, z.B.

Code Auswählen Erweitern

attr mbc_1 writeMode Impulse:QX256.0
Wie lautet die Fehlermeldung genau ?

Meine Tests ergaben folgendes (Werte angepasst über FHEM -> Edit files):

Code Auswählen Erweitern

attr mbc_1 writeMode Impulse:IX256.0
wird mit der Fehlermeldung "writing to input IX256.0 is not allowed" abgelehnt.
Jedoch funktioniert

Code Auswählen Erweitern

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 

Ich habe diese Datentypen dazu verwendet um Sollwerte an die SPS zu übergeben, z.B.:

Code Auswählen Erweitern

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

Code Auswählen Erweitern

set MB_T_RolloAuf 06:50
oder

Code Auswählen Erweitern

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.

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

Code Auswählen Erweitern

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

[ChrisD]

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

Code Auswählen Erweitern

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.:

Code Auswählen Erweitern

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.

Super 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

Code Auswählen Erweitern

help ModbusCoil
auch direkt angezeigt werden.

Grüße,

ChrisD

[yogi74]

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 .

Code Auswählen Erweitern

define Leistung ModbusRegister wago MF102

angelegt. Auf der Wago entsprechend deklariert.

Code Auswählen Erweitern

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.

Code Auswählen Erweitern

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

Code Auswählen Erweitern

define Temperatur ModbusRegister wago MF103

In der Wago

Code Auswählen Erweitern

multi_temperatur AT %MD103 :REAL;

Dann auslesen:

Code Auswählen Erweitern

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.

Code Auswählen Erweitern

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.

Code Auswählen Erweitern


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.