Logikfunktion übersteuerbares Treppenhauslicht

[nuirgendwer]

Hallo allerseits,

ich bin noch ein relativer KNX Anfänger. Bisher bin ich gut zurechtgekommen, aber bei folgendem Thema stehe ich gerade an:
ich habe mit dem Gira Project Assistant (X1) eine Logik gebaut, mit dem ein Treppenhauslicht nach 5 Minuten das untere Stiegenhaus abschaltet. Außer es ist eine separate Gruppenadresse aktiv, dann bleibt das Stiegenhauslicht an. Funktioniert tadellos für das untere Stiegenhaus.

Jetzt wollte ich 1:1 dieselbe Logik für das Stiegenhaus zum 2. Stock umsetzen. Es funktioniert nicht bzw. nur in der Simulation. Es wird lt. Busdiagnose durchgängig ein AUS Signal auf die Gruppenadresse geschickt sobald ich ein Treppenhauslicht in der Logik baue. Es entsteht ein Loop, aus dem nicht mehr ausgebrochen werden kann. Das Licht für das untere Stiegenhaus ist soweit ich es beurteilen kann komplett gleich umgesetzt (siehe Bild), da gibt es das Problem nicht.


Daher meine Frage, sofern man das von extern einschätzen kann: welche Eigenschaft, die ich beim Abgleich vielleicht noch übersehen habe, könnte dafür sorgen, dass beim oberen Stockwerk mit der Treppenhausfunktion im Logikblatt immer wieder ein Signal geschickt wird, wohingegen beim unteren Stockwerk alles wie gewollt funktioniert?

Schon mal danke vorab!

[DirtyHarry]

Daher meine Frage, sofern man das von extern einschätzen kann:

Wir haben ja nichts zum vergleichen, du gibst uns ja nur ein Bild.
Und sag jetzt nicht, die andere Schaltung ist identisch, sie hat zumindest andere Gruppenadressen.

Und da dürfte auch der Haken sein: Deine Logik triggert sich über die GA selbst, was in der Simu nicht passiert.

[nuirgendwer]

Wir haben ja nichts zum vergleichen, du gibst uns ja nur ein Bild.
Und sag jetzt nicht, die andere Schaltung ist identisch, sie hat zumindest andere Gruppenadressen.

Und da dürfte auch der Haken sein: Deine Logik triggert sich über die GA selbst, was in der Simu nicht passiert.

Das Bild war von der Umsetzung, bei der es trotz Selbstreferenz funktioniert und sollte nur veranschaulichen was ich geschrieben habe. Die Logik im Logikblatt ist bei der nicht funktionierenden Variante ident. Selbst wenn ich nur eine vereinfachte Umsetzung nur mit Treppenhauslicht mache, funktioniert es da nicht.

Siehe neues Bild: Umsetzung oben geht, Umsetzung unten nicht. Die Eigenschaften der einzelnen Bausteine selbst sind abgesehen von den GA ident, daher meine Einschätzung, dass es wo weiter vorne ein Problem gibt.

Ich verstehe die Funktionsweise leider offenbar nicht so tiefgehend, um das Problem weiter einschränken zu können. Soweit ich es beurteilen kann, ist der einzige Unterschied die verwendeten Gruppenadressen, deren Eigenschaften meiner vlcht. zu oberflächigen Prüfung nach analog sein müssten. Dem dürfte ja nicht so sein, sonst würde sich KNX wohl nicht mal so und mal so verhalten. Daher meine Frage, welche generellen Eigenschaften/Einstellungen dafür verantwortlich sein könnten, sofern es sich um einen typischen Anfänger-/Verständnisfehler handelt. Falls weitere Infos/Bilder benötigt werden, kann ich die gerne zur Verfügung stellen. Auch für Alternativvorschläge, wie man sowas besser umsetzt, wäre ich sehr dankbar.

[gbglace]

Hast Du so schlechte Aktoren / PMs/BWMs dass man sowas grundlegendes wie ein Licht im Treppenhaus per Logikserver bauen muss?

[nuirgendwer]

Die Gruppenadressen schalten jeweils mehrere LEDs auf unterschiedlichen Aktoren gemeinsam ein/aus. Für mich als Einsteiger war das (bisher) die einfachste Umsetzungsvariante, um uneingeschränkt verschiedenste Logiken über mehrere Aktoren umzusetzen. Wenn das mit Treppenlicht aus mehreren Aktoren mit gemeinsamer Übersteuerungsmöglichkeit anders viel einfacher geht, bin ich ganz Ohr.

[DirtyHarry]

Die Frage von Göran ist natürlich berechtigt. Wenn der X1 aus irgendeinem Grund nicht läuft, geht im Treppenhaus gar nichts.
Unabhängig davon, muss es ja trotzdem funktionieren.

Ich finde ich die Logiken des X1 unübersichtlich. Während man beim HS wenigstens noch erklärende Texte an die Ein-/Ausgänge bringen kann, geht hier gar nichts. Wird nur irgendwie automatisch generiert.
Darum frage ich mich auch, kann das sein, dass du am EG-Dauer-Eingang keine GA zugeordnet hast (hier steht nur Text, aber keine GA)?

Wenn das mit Treppenlicht aus mehreren Aktoren mit gemeinsamer Übersteuerungsmöglichkeit anders viel einfacher geht, bin ich ganz Ohr.

Der erste Ansatzpunkt wäre der PM (soweit vorhanden), hier müsste man wissen um welchen es sich handelt und welche Möglichkeiten der bietet.

[knxPaul]

Ich behaupte, dass auch die Umsetzung oben versagen kann, wenn beispielsweise mit dem Gruppenmonitor ein AUS mit der GA = 3/2/85 3/2/88 gesendet wird. In diesem Fall erhält der Steuersignal-Eingang das AUS, sendet selbst ein AUS, welches vom ODER Gatter weitergegeben wird auf die GA = 3/2/88 3/2/85.

Nun heißt es Suchen, ob ein Visu-Element Schalter den Loop schliessen kann.

[nuirgendwer]

Die Frage von Göran ist natürlich berechtigt. Wenn der X1 aus irgendeinem Grund nicht läuft, geht im Treppenhaus gar nichts.
Unabhängig davon, muss es ja trotzdem funktionieren.

Ich finde ich die Logiken des X1 unübersichtlich. Während man beim HS wenigstens noch erklärende Texte an die Ein-/Ausgänge bringen kann, geht hier gar nichts. Wird nur irgendwie automatisch generiert.
Darum frage ich mich auch, kann das sein, dass du am EG-Dauer-Eingang keine GA zugeordnet hast (hier steht nur Text, aber keine GA)?



Der erste Ansatzpunkt wäre der PM (soweit vorhanden), hier müsste man wissen um welchen es sich handelt und welche Möglichkeiten der bietet.

Der Dauer Eingang hat den Datenpunkt 3/2/96, ist im Bild nicht ersichtlich, da ich den Namen des Objektes geändert hatte.
Aktuell ist im oberen Stiegenhaus noch kein PM vorhanden, nur Taster bei Stiege oben und unten.

Ich behaupte, dass auch die Umsetzung oben versagen kann, wenn beispielsweise mit dem Gruppenmonitor ein AUS mit der GA = 3/2/85 gesendet wird. In diesem Fall erhält der Steuersignal-Eingang das AUS, sendet selbst ein AUS, welches vom ODER Gatter weitergegeben wird auf die GA = 3/2/88.

Nun heißt es Suchen, ob ein Visu-Element Schalter den Loop schliessen kann.

Ich verwende den Project Assistant öfters, da hier der Logikaufbau sehr ähnlich zu mir bekannten Programmiersprachen ist (dachte ich zumindest)
Mein bisheriges Verständnis vom Ablauf war:

Block 1:
Hole GA 3/2/85 ab, EIN (1) / AUS (0)
Gibt Wert weiter an Treppenhauslicht
Gibt Wert weiter an ODER
Wert läuft nach 5min ab und geht auf 0 (aus)
Gibt Wert weiter an ODER

Block 2:
Manuell steuerbare GA 3/2/96, EIN (1) / AUS (0)
Gibt Wert weiter an ODER

Block 3:
ODER gibt das Maxium aus Block 1/2 weiter an 3/2/85

Ergebnis:
Falls Block 2 auf 1, dann immer 1
Falls Block 2 von 1 auf 0, dann läuft Block 1 noch 5min nach, dann geht dieser auch auf 0
Falls nur Block 1 auf 1, dann läuft es 5min

Neuer Durchlauf, sobald sich Eingang aus Block 1 oder Block 2 wieder ändert.

Was ich bisher etwas nachverlässigt habe: inwiefern spielt hier der Status Rückmeldung eine Rolle? Bisher wär ich davon ausgegangen bei der Erkennung, ob sich der Status von Block 1 geändert hat und damit ein neuer Durchlauf erfolgen soll?

[knxPaul]

Vielen Dank für den Hinweis mit dem Status - ich hatte die beiden GAs in #7 verwechselt und jetzt korrigiert.
Der entscheidende Punkt ist, dass der Eingangsbaustein auf die Status-GA reagiert während der Ausgangsbaustein die Senden-GA sendet. Damit wird normalerweise ein Loop verhindert, es sei denn, irgendwo bewirkt die Senden-GA eine Änderung der Status-GA; einfach ausgedrückt: Ein Aktor schliesst den Loop.

[knxPaul]

Hole GA 3/2/85 ab, EIN (1) / AUS (0)

das ist falsch!
Korrekt ist: Warte auf Telegramme mit der GA = 3/2/88 aus dem Status-Feld bzw hörende Adressen im Datenpunkt und gib den logischen Wert EIN (1) / AUS (0) weiter

Bisher wär ich davon ausgegangen bei der Erkennung, ob sich der Status von Block 1 geändert hat und damit ein neuer Durchlauf erfolgen soll

Jeder LBS reagiert, wenn ein Telegramm an einem Eingang ankommt und sendet ein Telegramm am Ausgang; das kann auch den gleichen Wert haben wie das zuletzt gesendete Telegramm. So etwas wie ein Durchlauf wie bei einer Zustandsmaschine gibt es im Ereignis basierten KNX System nicht, da ist ein gehöriges Umdenken gefordert.

[nuirgendwer]

das ist falsch!
Korrekt ist: Warte auf Telegramme mit der GA = 3/2/88 aus dem Status-Feld bzw hörende Adressen im Datenpunkt und gib den logischen Wert EIN (1) / AUS (0) weiter

Danke, das macht natürlich Sinn.

Jeder LBS reagiert, wenn ein Telegramm an einem Eingang ankommt und sendet ein Telegramm am Ausgang; das kann auch den gleichen Wert haben wie das zuletzt gesendete Telegramm. So etwas wie ein Durchlauf wie bei einer Zustandsmaschine gibt es im Ereignis basierten KNX System nicht, da ist ein gehöriges Umdenken gefordert.

"Durchlauf" hab ich auf die Logikkette im Gira PA bezogen, die durch ein Ereignis gestartet werden muss. Dieses Ereignis ist meinem Verständnis nach das Telegramm, das ausgesendet wird. Genau hier hab ich mein Verständnisproblem: wie wird das seitens KNX ausgelöst? Meinem Verständnis nach wird ein Telegramm ausgesendet, wenn a) eine Zustandsänderung ausgelöst wird (einfachstes Beispiel EIN/AUS) oder b) weil im Aktor z.B. eine gewisse Zeit bis zur nächsten Aktualisierung eingegeben ist (z.B. messe alle 15 Minuten die Temperatur).

Praktisch ausgedrückt: welche Eigenschaft/Einstellung/was auch immer könnte dafür sorgen, dass beim unteren Stiegenhaus wie von mir vorgesehen nur dann ein Telegramm ausgesendet wird, wenn es eine Statusänderung gibt, wohingegen beim oberen Stiegenhaus, sobald es mit dem Treppenhauslicht in Berührung kommt, mehrere Telegramme pro Sekunde ausgeschickt werden?

--

Ich konnte das Problem mit dem oberen Stockwerk inzwischen "lösen". Ich habe dazu beim ersten Ausgang per Rechtsklick die Option Send-by-Change aktiviert. Es fühlt sich zwar nicht 100%ig befriedigend an, dem Hintergrund für die unterschiedlichen Verhaltensweisen nicht auf die Spur gekommen zu sein, aber bis mir meine Behelfslogiken eines Tages um die Ohren fliegen, nehme ich, was ich schaffe. 😅

[knxPaul]

Für die Suche nach der Ursache würde ich im Gruppenmonitor die Telegramme beobachten: Da steht bei jedem Telegramm die PA des Senders; beim X1 ist es die Tunnel-Adresse.