Torstatus Konst./blinken/schnell blinken über Binäreingang

[Robert_Mini]

Hallo zusammen!

Wie kann ich den Status des Schiebetorantriebs über einen Binäreingang auswerten?
Tor zu - Kontakt geschlossen
Tor offen - Kontakt offen
Tor fährt auf - Kontakt schaltet alle 3s
Tor fährt zu - Kontakt schaltet jede 1s

Wie kann ich dies mit möglichst wenig Aufwand als Status am Bus auswerten?
WireGate ist vorhanden, Binäreingang Merten 644592.
Irgendwie sollte das mit Impulszähler, Entprellzeit, ev. 2 Eingänge, etc. und ein wenig Logik zu machen sein, oder?
Was ich nicht machen möchte: alle Statusänderungen am BE auf den Bus schicken und mit dem WG die Zeit auswerten.

Wer hat hier eine gute Idee?

LG Robert

[TRex]

Ich habe das aud die Kontrollampen eines Tasters gelegt, mit dem ich das tor ansteuere. Einfach GA verknüpfen, fertig.

[JuMi2006]

Nur mit dem Wiregate wird es schwieriger, der HS könnte da bestimmt ein bisschen mehr, habe ich aber auch nicht.

Mit dem WG wäre zumindest die zu und auf Auswertung relativ einfach in dem man den Status bei einem Telegramm prüft, für eine gewisse Zeit merkt und danach nochmal prüft. So "überbrückt" man das Blinken.

Wie lange fährt das Tor und was ist die maximal einstellbare Entprellzeit in der Applikation des Binäreingangs?

[Robert_Mini]

Ich habe das aud die Kontrollampen eines Tasters gelegt, mit dem ich das tor ansteuere. Einfach GA verknüpfen, fertig.

Danke - das ist eigentlich eine gute Lösung.

Für die CometVisu werd ich dann die Zeit über das WG auswerten, die (vielen) Telegramme werden ja nur beim Fahren des Tores geschickt, sonst bleibt die Buslast klein.

Entprellzeit ist max. 15ms, aber für die Telegramme kann man Ein- und Ausschaltverzögerungen festlegen, da sind die Merten Applikation vorbildlich (sehr umfangreich).

Wenn ich dann nur Ein-Befehle vom BE am WG auswerten, sollte das mit den vielen Aufrufen auch gehen, im schlimmsten Fall ist mal der Torstatus auf der Visu falsch, wenn gerade einige rrd geschrieben werden.

Was hier beim HS besser sein soll, würd mich auch interessieren. Multitasking geht auch beim HS nicht, oder?

lg
Robert

[JuMi2006]

Die Verzögerungen lösen dann das Problem.

Der Homeserver hat evtl. irgendwo nen Baustein der das "Blinken" auswerten könnte ... nur ne Vermutung.
Das geht schon mit dem Wiregate, wobei 1Pluginaufruf pro Sekunde ja auch nicht ohne ist. Bei 30 Sekunden Tordauer kommt da vllt. was ins rödeln, aber wird schon so gehen.

[mumpf]

Hi,

ich würde an Deiner Stelle für diesen Fall linknx auf dem WG verwenden, vor allem, weil es eine condition (type "time-counter") gibt, die für so einen Fall gedacht ist.

Und Timing-Probleme sollte es da auch nicht geben...

Gruß, Waldemar

[TRex]

bei mir ist das andersrum.
Ich bekomme Tor offen oder zu und die Laufrichtung auf oder zu in einen Binäreingang. Dann erzeuge ich das blinken mittels Telegrammgeneratur und 0,5 hz.

Ich genieße an der Anzeige, daß ich eben erkennen kann ob das Tor zu ist ( grün ), läuft ( blinken rot/grün mit 0,5 Hz ) oder ganz oder teilweise offen ist ( rot ).

Du könntest entweder wie schon geschrieben die Entprellzeit nach oben setzen ( sicher die einfachste Lösung ) oder eben die Aus-Telegramme mittels Binärbaustein "abschneiden". Dann hast Du aber nicht mehr die Kontrolle ob das Tor jetzt offen ist oder eben läuft.

[Robert_Mini]

bei mir ist das andersrum.
Ich bekomme Tor offen oder zu und die Laufrichtung auf oder zu in einen Binäreingang. Dann erzeuge ich das blinken mittels Telegrammgeneratur und 0,5 hz.

Ich genieße an der Anzeige, daß ich eben erkennen kann ob das Tor zu ist ( grün ), läuft ( blinken rot/grün mit 0,5 Hz ) oder ganz oder teilweise offen ist ( rot ).

Danke für eure Antworten.

Ich werde es ähnlich lösen. Der BE liefert bereits das richige für das LED am Taster bei der Haustüre. Mittels WG Plugin werde ich zusätzlich das Timing auswerten und daraus die Telegramme für die CV mit "Zu/Offen/Öffnet/Schließt" generieren.

Auf LinKnx werd ich vorerst verzichten, außer es gebe hierfür Performance-Vorteile oder Probleme mit den Plugins. Ansonsten würde ich auf eine weitere Verteilung der Logiken im Gesamtsystem verzichten.

lg Robert

PS: Ich warte noch auf den Optokoppler zur Umsetzung 12V auf BE pot-frei, dann werde ich hier das Ergebnis posten.

[mumpf]

Auf LinKnx werd ich vorerst verzichten, außer es gebe hierfür Performance-Vorteile oder Probleme mit den Plugins.

Hi Robert,

natürlich hat sich mein Vorschlag auf die Performance bezogen. Die Aktionen in linknx sind voll asynchron und deswegen gibt es kein "ausführen nur jede Sekunde" oder ähnliches.

Auch ich bin der Meinung, man sollte die Logiken nicht zu sehr verteilen. Ich habe mit den WG plugins angefangen und bin dann komplett auf linknx umgeschwenkt. Einfach weil man bei KNX viel mit Timings zu tun hat und man sich da bei WG Plugins doch schwer tut. Und bei linknx haben die Timer eine Auflösung von Millisekunden und ich kann einfach hinschreiben "mach x in 25 Sekunden" oder "wiederhol y 5 mal alle 10 Minuten" .

Ich bin gespannt, wie Deine Erfahrungen mit den Plugins sein werden...

Gruß, Waldemar