Vorstellung Projekt EFH und Anfängerfragen

[vento66]

Doch, mit dem Status kannst Du doch auch die anderen Kanäle schalten. Der eine Kanal macht praktisch die Zeitverzögeung für deinen Zentral Aus. Der Taster schaltet den Kanal, und der Status von dem Kanal ist dann deine Zentral Aus Ga, die jetzt vom Taster kommt.

[FabsiH92]

Puh... Beispiel, ob ichs auch verstanden hab:

Kanal A am Aktor mit Ausschaltverzögerung
1. GA mit Kanal A am Taster
2. GA mit Status Kanal A mit allen benötigten KO Schalten?

muss ich dann noch mit den Flags arbeiten?

Ich bringe nur den Sprung von Status auf Schalten nicht zusammen (sind ja 2 Datentypen?) und wie ich die GA zusammenführe.

[tobiasr]

Status und "Schalten" sind beide vom Datentyp '1 bit' und damit kompatibel. Sie unterscheiden sich nur durch den Untertyp. Damit versucht die ETS eine Kompatibiltiätsprüfung für den Nutzer zu ermöglichen. Diese ist aber nicht binden und auch nicht immer sinnvoll.

[FabsiH92]

Verstanden - aber: in der GA setze ich den Status aber in diesem Fall auf „senden“ und die anderen „Schalten“ auf „lesen“ korrekt?

[tobiasr]

Eine GA kennt diese Zustände (Lesen, Senden, Aktualisieren, etc.) nicht. Nur die KOs am jeweilige Gerät kennen diese Flags. Im Normalfall ändert man diese nicht. Und auch bei dir ist das nicht nötig. Die Bezeichnung ist sehr irreführend. Denn Lesen bedeutet nicht, dass dieses KO Telegramme an die verknüpfte GA auswertet, sondern auf sogenannte Leseanfragen antwortet. In deinem Fall also nicht notwendig.

Senden kann ein KO immer nur auf EINE GA. Konkret immer die erste. Welche dann in der ETS als "sendend" bezeichnet wird. Durch das dedizierte setzen auf "senden" wird quasi umsortiert.

[FabsiH92]

Ok, aber dann verstehe ich es nicht mehr.

meine 2 GA sehen dann wie folgt aus?

1/1/0

1. T1: Alles zeitverzögert aus — Gerät Glastaster
2. Kanal A: Raum 1 - Schalten EIN/AUS — Gerät Universalaktor inkl. Ausschaltverzögerung

1/1/1

1. Kanal A: Raum 1 — Status
2. Kanal B: Raum 2 — Schalten
3. Kanal C: Raum 3 — Schalten
4. usw

ich muss nichts mehr anderes parametrieren?

[TobiHH]

Nein, es sei denn es ist schon ungewöhnlich rumgespielt worden an Parametern und Flags ...

Sobald der Kanal abschaltet (nach der Verzögerung), sendet er ein 1-Bit-Telegram mit dem Wert 0 auf sein Status-Objekt, welches dann die Schalt-Objekte empfangen und als "Aus" interpretieren und umsetzen (Also Abschalten).

Technisch muss dafür das Objekt Status die Flags KÜ besitzen und die Schalt-Objekte KS, was Standardmäßig so sein sollte und manchen Aktoren kann man das Senden eines Status bei Änderung in den Parametern untersagen, was aber standardmäßig nicht der Fall ist, siehe Bild.

Status.jpg

[gbglace]

in der GA setze ich den Status aber in diesem Fall auf „senden“

Da machst Du besser fein nichts, weil Flags und alles andere was Du da liest sind keine Eigenschaften der GA, sowas sind alles Eigenschaften von KO und werden wenn überhaupt notwendig dort verändert. Und warum sollte man da was ändern?
Die Eigenschaft "senden" an der GA zeigt nur, ob an dem KO wo die GA verbunden ist, das KO Telegramme mit jener GA sendet ja /nein, optisch in der ETS auch ob es die erste verbundene GA an dem KO ist.

Und leider machen auch die älteren Foristen hier sprachlich Fehler weswegen Anfänger dann immer im Gedanken verwirrt sind.

Senden kann ein KO immer nur auf EINE GA.

Das auf in dem Satz ist halt einfach falsch, weil eine GA ist kein Objekt im KNX-Bus auf dem was gesendet werden kann, sondern nur eine temporäre Information im Telegram, mit der Lebensdauer wie das Stromsignal im CU zirkuliert.

Der Rest und der Sinn der Aussage stimmt aber.
Ein KO sendet bekanntlich immer nur ein Telegramm und eine GA ist halt Teil der Information die in dem Telegramm gesendet wird. Und wenn es nur ein Telegramm gibt, kann es auch nur eine GA geben die gesendet wird. Ist wie der Adressaufkleber am Briefumschlag, die Adresse ist Teil der gesendeten Information, grob angesprochen fühlen sich im KNX dann aber alle KO die diese GA verbunden haben. Daher jede weitere GA die an ein KO verbunden ist, ist nur ein Filter an dem KO für weitere eingehende Telegramme, was an einem reinen Ausgangs-KO keinen Sinn ergibt.

GA:
1/1/0 GA "zentral AUS direkt" verbunden mit

- x KO's an Tastern / Visu als Bedienteil/e
- x KO's Schalten an Kanälen die direkt reagieren sollen
- 1 KO "Schaltkanal mit Ausschaltverzögerung"

1/1/1 GA "zentral AUS mit Zeitversatz" verbunden mit

- KO Status-Ausgang "Schaltkanal mit Ausschaltverzögerung"
- x KO's Schalten an Kanälen die zeitverzögert reagieren sollen

ch muss nichts mehr anderes parametrieren?

Nöö nur die Verzögerungszeit in dem einen "Hilfskanal" der die Verzögerung macht.

[ppent]

Letztlich missbrauchst du einen Schaltkanal als Logikkanal. "Schalten ein/aus" ist dann wie der Logikeingang und "Status" der Logikausgang.
Von daher sollte das wie von dir beschrieben passen. Der Schaltkanal ist dann aber leider verloren. Wenn es keine andere Möglichkeit der Verzögerung gibt, aber clever gelöst.

[vento66]

Es geht um eine Baustelle….. der Kanal wird ja wieder frei. Ich mach das aber ab un an, wenn keine Logiken sonst zur Verfügung stehen, und Aktorkanäle frei sind.

[TobiHH]

Wenn an dem Kanal eine der zu verzögernden Leuchten angeschlossen ist, ist der Kanal nicht einmal "verloren" - er geht nur vorübergehend nicht unverzöget abzuschalten (wobei das bei den MDT AKU noch relativ Schmerzfrei über die Zwangsführung zu realisieren wäre, falls notwendig ...) und löst immer den Zentral Aus (und Zentral Ein) aus ...

[FabsiH92]

Danke an alle!

Wie wäre es dann später zu realisieren? Benötige ich dann einen Logikbaustein bzw. Nodered/iobroker?

[TobiHH]

Kommt drauf an, was du sonst noch so für Geräte im Projekt hast bzw. planst - Ich habe in letzter Zeit oft insta Universal-Aktoren im Projekt, wie den Jung 23024 1S R und baugleiche Gira, deren integrierte Logik kann u.a. für ein Sperrglied oder Logikgatter auch verzögertes Senden, das reicht für sowas aus ... manchmal reicht auch ein sehr langsamer Soft-Off in den Dimm-Aktoren um noch mit Restlicht aus dem Haus zu kommen ...

Und wenn das auch nicht mehr reicht, haben die meiste Visu-Server eine Logik-Engine an Bord, die sowas hinbekommt. (bei meinen Projekten in letzter Zeit häufig ein Basalte Core S4 ...)

[ppent]

Es geht um eine Baustelle….

Sorry, stimmt. Habe die Info irgendwie ausgeblendet.

[FabsiH92]

Ich habe mich nun etwas intensiver mit der TürKo beschäftigt und werde voraussichtlich auf das System von Gira zählen.

Verbaut soll werden das 106 mit vorerst einem G1, der in das KNX eingebunden werden soll.

Jedoch könnte ich mich schon wieder über mich selber "ärgern": aufgrund des Testboards und Erbsenzählerei habe ich nur in ein IP-Interface investiert. Laut einigen Threads hier benötigt das G1 aber eine IP Linie die ich nur über einen IP Router oder einen Linienkoppler herstellen könnte.

Bevor ich investiere, ist dem so? Zu welcher Gerätschaft würdet ihr dann wechseln? Aktuell ist ein IP Interface von MDT im Einsatz.
Gibt es einen kostengünstigen LK?


PS: gibt es irgendwo ein Lexikon für die ganzen Abkürzungen hier im Forum? Die Sufu bringt mir keinen Erfolg.