Optimale "synchronisierung" zwischen verschiedenen KNX-KOs

[givemeone]

Hallo,

wie löst ihr idealerweise das Synchronisieren von verschiedenen KOs?
Damit keine Schleifen entstehen, habe ich verschiedenste Varianten durchprobiert, aber optimal gefallen mag mir keine.

Ich muss zB einfache BIT-KOs in 2 Bit (Priotity) umrechnen und wieder zurück.

Was ich versucht habe ist, um keine Schleife produzieren ist:
# Sperre mit impuls: Nachteil: Es wird schnell komplex und unübersichtlich
tmp2.jpg
# Entprellen: Sieht einfach aus, aktualisiert den Wert jedoch mindestens 2x (siehe Screenshot)
tmp.jpg


Welche besseren Möglichkeiten übersehe ich?
Danke!!

Joe

[coliflower]

Schleifen

... werden hier grundsätzlich mit einem Send-by-Change LBS gelöst ... falls ich dich richtig verstanden habe.

[givemeone]

... werden hier grundsätzlich mit einem Send-by-Change LBS gelöst ...

damit wird jedoch das Quell KO mindestens ein zusätzliches mal geschrieben und somit ein zusazusätzliches Mal getriggert... Genau das will ich habe verhindern.

[jonofe]

Grundsätzlich sollte man bei Logiken in EDOMI Zirkelbezüge verhindern, weil diese ja ohne spezielle Maßnahmen Logikschleifen erzeugen. Kannst Du den Usecase näher erläutern? Insbesondere in welchen Fällen die Logik nicht ausgeführt werden soll, wenn eine GA getriggert wird? Darf die Logik nur von KNX Telegrammen getriggert werden, welche wirklich vom KNX kommen und nicht von EDOMI selbst?

Vielleicht gibt es ja noch andere Lösungen, wenn man den Usecase besser versteht ....

[givemeone]

... Darf die Logik nur von KNX Telegrammen getriggert werden, welche wirklich vom KNX kommen und nicht von EDOMI selbst?

Danke!
Jetzt wird's spannend: Wie kann ich in EDOMI herausfinden, wer der Absender eines Triggers ist? Das wollte ich fast schon wünschen.... ;-)

Ok, kurz zum Hintergrund: Ich habe bei jedem Motorfenster 2 GAs, die jeweils nur auf 1 reagieren. Um den Status in den Tastern ordentlich anzeigen/nutzen zu können, muss ich diese auf eine GA0 mit 0/1 zusammenfassen. Also 0=GA1 auf 1 und GA2 auf 0, 1=GA2 auf 1, GA1 auf 0. Und das habe ich 72 mal. (pro Fensterflügel je ein mal).
Daher die Frage, wie ich dies "optimalerweise" umsetze. Und diese Aktualisierung soll in beide Richtungen gehen, also
Wenn ich an GA1=1 setzte, soll GA0 auf 0 springen.
Damit GA0 nicht wieder GA1 und/oder GA2 auslöst, muss ich beide fürUpdates sperren.

Prinzipiell ist das ja alles möglich, aber SBC hilft mir hier eben nichts, und bei "entprellen" war während eines Reperaturvorgangs der DB auch mal 500ms sperrzeit schon zu kurz, mit der Folge dass die GA 86000 mal getriggert wurde und der Motor des Fensters wegen Überhitzung aufgegeben hat...

[vento66]

Nimm doch eine eigene Staus GA, die nur als Anzeige im Taster dient.
GA 1 -> 1 setze Staus GA „ein“
GA 2 -> 1 setze Staus GA auf „aus“

Und wenn Du das für die Bedienung auch brauchst, dann hänge die Staus GA als hörende Adresse zu der Schalt GA mit dazu.

[jonofe]

Ja, das war auch der Hintergrund meiner Frage, denn genau so macht man es ja auch mit normalen Schaltaktoren. Es gibt ein Schalt-GA und ein Status-GA, dadurch entkoppelt man den Schaltvorgang von der Statusanzeige. Die Logik gibt also dann das Status-GA aus und reagiert am Eingang auf Schalt-GAs.

Das mit der Quelle des Sendens war eine reine Verständnisfrage von mir, denn es ist derzeit nicht möglich z.B. die physikalische Adresse der Quelle einer GA in Edomi zu nutzen.