BWM sperren, falls Licht bereits an ist

[sti87]

Sollte das nicht mit einem simplen UND Gatter lösbar sein?

Danke Micha. Ich habe das nun versucht abzubilden.

In meinem Fall habe ich einen Homeserver als Visu und Logikengine.

Leider hänge ich an folgendem Problem: Ich habe (brauche ja) eine Zentral-Adresse (hörend) um den Zustand (Ein/Aus) des Aktors in der Visu darzustellen.
Wenn nun der PM nun das Licht schaltet, schaltet der HS die GA des Tasters durch die Zentral-Adresse automatisch auf Ein. Somit ist der UND-Gatter ebenso auf "True", quasi wie wenn ich die Taste selbst gedrückt hätte.

Wie kann ich das abfangen, habt ihr da eine Idee?

Danke Euch

[gbglace]

schaltet der HS die GA des Tasters durch die Zentral-Adresse automatisch auf Ein.

dann sollte das besser eine andere GA sein?

besser wird es wohl sein du notierst hier mal was da jetzt bei Dir welche GA geworden ist.

Eine hörende Zentraladresse klingt für mich irgendwie dubios.

[chris42]

Leider hänge ich an folgendem Problem: Ich habe (brauche ja) eine Zentral-Adresse (hörend) um den Zustand (Ein/Aus) des Aktors in der Visu darzustellen.

Das sollte die Gruppenadresse für "Rückmeldung Schalten" sein.

Wenn nun der PM nun das Licht schaltet, schaltet der HS die GA des Tasters durch die Zentral-Adresse automatisch auf Ein. Somit ist der UND-Gatter ebenso auf "True", quasi wie wenn ich die Taste selbst gedrückt hätte.

Wenn du für den PM eine eigene Schalt-GA anlegst, ist diese unabhängig von der Taster-GA (nur die Rückmeldung vom Aktor gibt's nur einmal). So habe ich das bei mir umgesetzt.

[sti87]

Also ich habe folgende GA's:

1. Schalten via VISU (3/0/0)

01 GA Schalten Visu.PNG


2. Schalten via BMW (3/0/3)

02 GA Schalten BMW.PNG

3. Rückmelde GA (3/6/0)

03 GA Rückmeldung.PNG



Im Homeserver habe ich die Rückmeldeadresse (3/6/0) als hörende Adresse für den Visu-Schalter (3/0/0) verknüpft.
Nur so bekommt der HS ja mit, dass das Licht an ist, falls ich es ausserhalb steuere.

04 Homeserver KOs.PNG



In der Logik habe ich nun verschieden Ansätze getestet (u.a. den mit dem UND-Gatter von Micha), der letzte ist wie folgt.

Ich habe eine Schalt-GA (2/4/10) welche der Lichtkanal des BWM darstellt. Diese steuert die separate GA (3/0/3), insofern das Licht (3/0/0) nicht schon manuell eingeschalten ist:


05 Homeserver Logik.PNG

Bedingt durch die Verknüpfung der Rückmeldeadresse (3/6/0) als hörenden Adresse an den Visu-Taster (3/0/0), wird nun aber 3/0/0 ebenso auf EIN.
Somit bleibt mein Licht wenn es durch den BWM aktiviert wird, immer AN.

Vielleicht könnt ihr mir helfen den Knopf zu lösen

Danke Euch

[chris42]

sti87

Ich habe zwar keinen Homeserver mehr, aber für mich sieht das so aus als ob du durch den Binär-Auslöser das Aus-Telegramm herausfilterst. Deshalb geht das Licht nicht mehr aus.

Beim "Gleich"-Baustein fehlt der 2. Eingang - ich bin mir nicht sicher ob das so geht.
Wenn du die Sperr-Funktion in der Logik implementieren willst, müsste das meiner Meinung nach so aussehen:

Eingangsbox 3/0/0 -----> Sperre E1
Eingangsbox 2/4/10 -----> Sperre E2 (Signal)

Das führt dazu, dass der BWM so lange gesperrt ist, wie das Licht manuell angeschaltet bleibt.

Wenn du eine Ausschaltverzögerung willst, müsste der Baustein direkt hinter die Eingangs-Box 2/4/10

Der Gleich-Baustein sowie der Binär-Auslöser müssten nach meinem Verständnis nach raus.

Falls der BWM selbst über ein Sperrobjekt verfügt, könnte man die Sperre auch in der Hardware umsetzen.

Zu deiner Aussage

Bedingt durch die Verknüpfung der Rückmeldeadresse (3/6/0) als hörenden Adresse an den Visu-Taster (3/0/0), wird nun aber 3/0/0 ebenso auf EIN.

Wenn ich in der Visu einen Taster mit einer Aktion (in diesem Fall Schalten 3/0/0) belege und als Status die Rückmeldeadresse (3/6/0) anzeigen lasse, sollte das bei einer Statusänderung der Rückmeldeadresse nicht zu einer Aktion auf der 3/0/0 führen.

[gbglace]

Warum haben die GA 3/0/0 und 3/0/3 nur einen Verknüpfungspunkt am Dali-GW. Wenn die 3/0/3 vom BM ausgelöst werden soll, dann müsst es doch auch noch eine Verknüpfung an dem Gerät geben. Und ansonsten für Visus auch mal ein Gerät, wenn auch nur Dummy in der ETS anlegen. So einseitig verbundene GA geben kein stimmiges Funktionsbild.

[chris42]

Warum haben die GA 3/0/0 und 3/0/3 nur einen Verknüpfungspunkt am Dali-GW. Wenn die 3/0/3 vom BM ausgelöst werden soll, dann müsst es doch auch noch eine Verknüpfung an dem Gerät geben.

Er geht vom BWM über den Homeserver auf das Dali-GW...
Ich würde es auch direkt in der Hardware lösen, anstatt über den Homeserver zu gehen. Sofern der BWM über ein Sperrobjekt verfügt.

[gbglace]

Er geht vom BWM über den Homeserver auf das Dali-GW...

Tja und was hindert ihn dann da ein passenden Dummy anzulegen, und wenn der HS am Ende aller Logiken das Licht schaltet, wozu braucht es dann je eine GA für BWM und Visu getrennt? Absender ist doch immer die HS-Logik. Und senden auf zwei GA gleichzeitig entspricht nicht der KNX-Logik. Das kann man sich da nun sicher in so einen HS reinbasteln ob es aber der Nachvollziehbarkeit und dem Verständnis der Funktion dient, wage ich zu bezweifeln.

[chris42]

Tja und was hindert ihn dann da ein passenden Dummy anzulegen,

Nichts

und wenn der HS am Ende aller Logiken das Licht schaltet, wozu braucht es dann je eine GA für BWM und Visu getrennt? Absender ist doch immer die HS-Logik. Und senden auf zwei GA gleichzeitig entspricht nicht der KNX-Logik.

In diesem Fall wegen der BWM Sperre.

Das kann man sich da nun sicher in so einen HS reinbasteln ob es aber der Nachvollziehbarkeit und dem Verständnis der Funktion dient, wage ich zu bezweifeln.

Ja, ich würde es wie gesagt auch eher direkt in den Aktoren/Sensoren umsetzen und nicht in der HS-Logik. Wie du sagst - ist einfacher nachzuvollziehen.

[mawi]

Hmm ... ich habe das ohne UND/ODER Gatter gelöst und zwar über eine GA.

1) Licht bereits ausgeschaltet: Wenn EIN Taster bestätigt wird -> sende "1" -> Licht AN und Präsenzmelder SPERREN
2) Licht bereits ausgeschaltet: Wenn AUS Taster bestätigt wird -> sende "0" -> Licht AUS und Präsenzmelder ENTSPERREN (=keine Änderung)
3) Licht bereits eingeschaltet: Wenn EIN Taster bestätigt wird -> sende "1" -> Licht AN und Präsenzmelder SPERREN (=keine Änderung, Präsenzmelder ist jedoch gesperrt und bleibt aktiv bis AUS Taster wieder betätigt wird)
4) Licht bereits eingeschaltet: Wenn AUS Taster bestätigt wird -> sende "0" -> Licht AUS und Präsenzmelder ENTSPERREN

Im Präsenzmelder muss lediglich die KO Sperre wie folgt eingestellt werden: SPERREN = 1 und ENTSPERREN = 0. Ohne UND/ODER Gatter und Logik-Engine. Dem Schaltaktor ist es wurscht, wenn ich noch mal "1" schicke auch wenn Licht bereits an ist.
Funktioniert zuverlässig + Frau ist zufrieden --> Mission erfüllt

Aber dann benötigst du doch trotzdem 2 GAs. 1xTaster schaltet das Licht und 1xBM schaltet das Licht. Der Aktorkanal hört dann auf beide GAs. Oder habe ich es noch nicht gepeilt

[sti87]

Danke Euch Jungs für Eure Antworten!

Richtig, ich gehe über den Homeserver und habe es nicht direkt in der Hardware abgebildet.
Ich habe hier einige Varianten getestet, zuerst über die HW, nun halt am Homeserver. Hintergrund ist, dass das Sperrobjekt vom BWM folgende Varianten bietet:
1. Schalte AUS
2. Schalte EIN
3. Sperre aktuellen Zustand

Leider aber nicht "tue einfach NICHTS". Nun hatte ich das Problem, dass ich mit diesen Zuständen es nicht lösen konnte.

Variante 1: Schalte AUS
-> ich betrete den Raum, BWM schaltet Licht an. Ich drücke den Taster um es dauerhaft leuchten zu lassen. Sperre schaltet licht wieder aus, ich stehe im Dunkeln

Variante 2: Schalte EIN
-> ich nutze die Sperren noch für einen "Mückenschutz". D.h. wenn das Fenster geöffnet wird, werden die BWM gesperrt und es soll kein Licht angehen. Öffne ich nun ein Fenster zum Zeitpunkt wo kein Licht an war (zu hell für den BWM), schaltet mir die Sperre das Licht nun dauerhaft ein.

Variante 3: Sperre aktuellen Zustand
-> ich betrete den Raum, der BWM geht auf EIN. Ich drücke den Taster, verlasse später den Raum und betätige den Taster erneut. Taster sendet ein AUS, Licht geht aus. BWM aktiviert vorherigen Zustand (EIN) und schaltet das Licht wieder EIN.


Daher mein Versuch diese Logik über den Homeserver abzubilden.

wozu braucht es dann je eine GA für BWM und Visu getrennt?

Das war eben der Versuch die Logikvorschläge der Vorgänger abzubilden. Ich muss irgendwie unterscheiden ob das Licht vom Taster/Visu oder eben vom BWM geschalten wurde.

Und ansonsten für Visus auch mal ein Gerät, wenn auch nur Dummy in der ETS anlegen. So einseitig verbundene GA geben kein stimmiges Funktionsbild.

Danke, diesen Hinweis hatte ich schon einmal im Forum gelesen. Das Secure Application (Dummy) von GIRA zeigt mir jedoch keine KO's an welche ich verknüpfen könnte.

Wenn ich in der Visu einen Taster mit einer Aktion (in diesem Fall Schalten 3/0/0) belege und als Status die Rückmeldeadresse (3/6/0) anzeigen lasse, sollte das bei einer Statusänderung der Rückmeldeadresse nicht zu einer Aktion auf der 3/0/0 führen.

Du hast grundsätzlich recht Chris. Ich hab es soeben getestet und auf der 3/0/3 ein EIN über ETS sende, auf der 3/0/0 wird ETS seitig nichts gemacht:

GA status.PNG

aaaber, der Homeserver ändert INTERN den Status von 3/0/0 auf EIN. So zumindest sehe ich es im HSMON:

08 Homeserver hsmon.PNG


Habt ihr mir eine Idee wie ich das lösen könnte? Möchte gerne ein "EIB: Ehe ist beendet" vermeiden

Danke Euch

[gbglace]

3. Sperre aktuellen Zustand

Leider aber nicht "tue einfach NICHTS".

Wo sollte da der Unterschied sein? Den aktuellen Zustand belassen und den PM Sperren ist doch tue nichts.

BWM aktiviert vorherigen Zustand (EIN) und schaltet das Licht wieder EIN.

Na das wäre ein Systemverhalten was passiert bei Entsperrung. Ich vermute aber das halt sich durch den Tastendruck entsperrt und Dich als Drücker in dem Moment bewegend im Raum sieht und deswegen nun wieder einschaltet.
Kannst in dem Melder so eine Art Totzeit einstellen?


Wenn es via HS sein muss dann:

Hast Du das mal mit dem UND so wie von Micha in Beitrag #21 vorgeschlagen im HS mal gebaut?

Das mit dem Dimmen lässt sich ja dann noch anbauen, aber erstmal das sollte funktionieren.

[sti87]

Wo sollte da der Unterschied sein? Den aktuellen Zustand belassen und den PM Sperren ist doch tue nichts.

Tue nichts wäre, ignoriere was war. Wenn ich Dich entsperre, respektiere die Totzeit und arbeite dann wieder fleissig :-)

Ich vermute aber das halt sich durch den Tastendruck entsperrt und Dich als Drücker in dem Moment bewegend im Raum sieht und deswegen nun wieder einschaltet.

Das war auch meine Vermutung, habe explizit darauf geachtet und es ist leider nicht so. Der BWM forciert den vorherigen Status und schaltet mir das Licht wieder ein, unabhängig von der Totzeit wo ich eingestellt habe.

Hast Du das mal mit dem UND so wie von Micha in Beitrag #21 vorgeschlagen im HS mal gebaut?

Ja, hatte ich. Kann mich leider nicht mehr erinnern wo dort das Problem war. Offensichtlich hat es nicht geklappt, ansonsten hätte ich nicht weitere Varianten ausprobiert.
Lass mich das nochmal nachbauen und ich teile dann meine Ergebnisse (und die Details der Logik) mit Euch.

Merci

[gbglace]

ja erstmal langsam mit an/aus danach das mit dem Dimmen ergänzen.