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

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

Vorheriges Thema - Nächstes Thema

nicom2

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

Wzut

Tipp : Entwickler hassen Screenshots, lieben dafür aber Device lists :)
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

ChrisD

#512
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



nicom2

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

ChrisD

Hallo,

Ich habe etwas am Server-Modul geändert, kannst du testen ob die neue Version (0023) das Problem löst ?

Grüße,

ChrisD

nicom2

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

der-Lolo

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

monty_burns_007

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

bitvilla

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

ChrisD

Hallo,

Ich habe den Fehler in der Konfigurationsdatei behoben, das Update sollte jetzt funktionieren.

Grüße,

ChrisD

der-Lolo

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

ChrisD

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

der-Lolo

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?



sukram

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

der-Lolo

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